jiebi/CodeConvo huggingface dataset:
Code change:
#!${pkgs.runtimeShell} diff <(echo 'hi') <(${pkgs.rclone}/bin/rclone cat nextcloud:test-shared-file) ''; <ins> findInClosure = what: drv: pkgs.runCommand "find-in-closure" { exportReferencesGraph = [ "graph" drv ]; inherit what; } '' test -e graph grep "$what" graph >$out || true ''; nextcloudUsesImagick = findInClosure "imagick" nodes.nextcloud.config.system.build.vm; nextcloudWithoutDoesntUseIt = findInClosure "imagick" nodes.nextcloudWithoutMagick.config.system.build.vm; </ins> in '' <del> start_all() </del> <ins> assert open("${nextcloudUsesImagick}").read() != "" assert open("${nextcloudWithoutDoesntUseIt}").read() == "" nextcloud.start() client.start() </ins> nextcloud.wait_for_unit("multi-user.target") # This is just to ensure the nextcloud-occ program is working nextcloud.succeed("nextcloud-occ status")

Related discussion:
text: Ouch, decisions based purely on a file ext is a behavior that sounds pretty broken to me :/ Optiobally disabling imagemagick and adjusting the config accordingly sounds reasonable to me, so feel free to file a PR. You can ping me for a review or if you need assistance with modifying the module :)
It's ok for what they do with it. It won't do double duty as a mitigation but I guess that was never intended. Thanks. Any suggestions on a name for the new option? Simply ? Should I add any tests for that? The existing tests only test three different configurations so adding one just for imagick seems like overkill. It should be quite easy though. If we want to test that previews actually aren't generated... Well, that's a different story. We would have to automate the web interface, for that. I think the existing tests are only testing the service, CLI and WebDAV.
As imagemagick enabled will remain the default, I'd suggest . Yes, adding a fourth VM test just for imagemagick is indeed an overkill IMHO since those tend to be fairly expensive. I'd suggest to write a testcase in , other integrations such as are also tested there. Right that could be a non-trivial thing to solve. Maybe check if there's a REST API or a way to implement this with the CLI of . But I don't think it'd be worth spending too much time on this if there's no reasonable way to test :)
I think we still want to test the default option in so we will need a second configuration that disables imagick. We don't have to start that VM if we only want to check whether imagick is in its closure. As there isn't any test helper for that, we probably don't want to do that though ;-) see Unfortunately, qemu on ARM is too unreliable for the automatic tests because qemu crashes when started on one of the little cores (i.e. 4 out of 6 times). I have done some interactive testing of the above commit but not an automated run. I will have to find some system that is not ARM, not high-security, not already virtualized...
Qemu/KVM does work if a kernel build or stress-ng is hogging the big cores :) is ready for review.
Code change:
config = mkIf config.services.kerberos_server.enable { <del> environment.systemPackages = [ heimdal ]; </del> <ins> environment.systemPackages = [ heimdalFull ]; </ins> services.xinetd.enable = true; services.xinetd.services = lib.singleton

Related discussion:
text: I to and I return I got:
cc (I had to look through essentially old SVN history to find a reference -- this service is untouched for a long time).
I don't use this service anymore. BTW I've fixed its evaluation in the PR .
Let's not close this unless fix hits master.
can you please test the fix and see if there are any more problems with the service?
Code change:
description = "Hex Editor for Reverse Engineers, Programmers and people who value their retinas when working at 3 AM"; homepage = "https://github.com/WerWolv/ImHex"; license = with licenses; [ gpl2Only ]; <del> maintainers = with maintainers; [ kashw2 cafkafk ]; </del> <ins> maintainers = with maintainers; [ kashw2 cafkafk ]; </ins> platforms = platforms.linux; }; }

Related discussion:
text: Imhex on unstable and nixos-24.05 crashes. Output from the above command: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same as pending to merge
Ah, sorry, I only searched in opened issues.
Code change:
description = "Hex Editor for Reverse Engineers, Programmers and people who value their retinas when working at 3 AM"; homepage = "https://github.com/WerWolv/ImHex"; license = with licenses; [ gpl2Only ]; <del> maintainers = with maintainers; [ kashw2 cafkafk ]; </del> <ins> maintainers = with maintainers; [ kashw2 cafkafk ]; </ins> platforms = platforms.linux; }; }

Related discussion:
text: Imhex failed to start. Steps to reproduce the behavior: -shell -p imhex --run imhex Shows the following errors: Imhex start up normally. Adding -v, --verbose doesn't give more information. I don't know how to either.
Maintainer ping:
Can repro on master, but can't repro if I checkout and build from it, it should be possible to bisect and find out at what point this broke.
First bad commit: <details<summarygit bisect log</summary</details
Seems there's a bunch of upstream reports of breakage with glfw 3.4
This might be fixed with The PR was merged into 1.90.6, but 1.33.2 contains a vendored 1.90.4, which doesn't contain the fix. My guess is that updating from the current 1.33.2 in nixpkgs to the latest version upstream (1.35.3 as of today) should fix the issue, as the latter contains a vendored updated to version 1.90.8, which should contain the fix.
Looks like the PR was closed, are you talking about instead?
Yes, sorry. I got the PR reference from: ... which also references the commit you mentioned.
Still crashes on imhex 1.35.3, which I more or less expected.
After applying both PRs and , finally works on my system with the current . Note: both PRs were needed, either one alone didn't fix all the issues for me.
Solved, marking as closed.
Code change:
extensions = { enabled, all }: (with all; enabled <del> ++ [ imagick ] # Always enabled </del> <ins> ++ optional (!cfg.disableImagemagick) imagick </ins> # Optionally enabled depending on caching settings ++ optional cfg.caching.apcu apcu ++ optional cfg.caching.redis redis

Related discussion:
text: There is about the use of imagemagick in NextCloud due to . Admins may want to disable it unless they are certain that users won't upload untrusted files (which can easily happen by accident if folder sync is active). NextCloud is only passing certain file types to imagemagick but it is doing so based on the file extension. Therefore, an attacker can pass any file type to imagemagick. I have tested this with a PNM image (not supported by NextCloud) that I have renamed to . doesn't get a preview image but does, i.e. NextCloud thinks it is HEIF and passes it to ImageMagick, which processes it as PNM. There are several ways to disable imagick: in the NextCloud config. This will not only disable imagick but also previews for PNG and JPEG (which do not use imagick). in the NextCloud config. This may need manual adjustment after a NextCloud update. the extension for PHP. This also disables it for NextCloud plugins. Option 1 and 2 can already be used by an admin if the drawbacks are acceptable. However, I think 3 is the best option in most cases. has options that disable the other PHP extensions that used to be by default. I think we should do the same for imagick. If imagick is disabled, NextCloud will automatically disable the preview generators that need it. It will also show a warning about that (which is subject to debate in the issue linked above) and there may be some implications for the themes app (which I don't use). Therefore, I think we should keep imagick enabled by default and leave the decision to the admin. We could also add a suitable policy for ImageMagick and thereby disable any file formats or features that are considered insecure. I don't think I could write such a policy and be sure that it is secure (or even "secure enough"). In addition, we will have to keep it up-to-date with newer versions and CVEs. That is why I recommend that we only add a simple off switch. The above information is based on NextCloud 20. I will wait until and NextCloud 21 have landed in nixos-unstable (and on my server) and then test again and create a PR if there is any interest in having this upstream.
Code change:
extensions = { enabled, all }: (with all; enabled <del> ++ [ imagick ] # Always enabled </del> <ins> ++ optional (!cfg.disableImagemagick) imagick </ins> # Optionally enabled depending on caching settings ++ optional cfg.caching.apcu apcu ++ optional cfg.caching.redis redis

Related discussion:
text: Ouch, decisions based purely on a file ext is a behavior that sounds pretty broken to me :/ Optiobally disabling imagemagick and adjusting the config accordingly sounds reasonable to me, so feel free to file a PR. You can ping me for a review or if you need assistance with modifying the module :)
It's ok for what they do with it. It won't do double duty as a mitigation but I guess that was never intended. Thanks. Any suggestions on a name for the new option? Simply ? Should I add any tests for that? The existing tests only test three different configurations so adding one just for imagick seems like overkill. It should be quite easy though. If we want to test that previews actually aren't generated... Well, that's a different story. We would have to automate the web interface, for that. I think the existing tests are only testing the service, CLI and WebDAV.
As imagemagick enabled will remain the default, I'd suggest . Yes, adding a fourth VM test just for imagemagick is indeed an overkill IMHO since those tend to be fairly expensive. I'd suggest to write a testcase in , other integrations such as are also tested there. Right that could be a non-trivial thing to solve. Maybe check if there's a REST API or a way to implement this with the CLI of . But I don't think it'd be worth spending too much time on this if there's no reasonable way to test :)
I think we still want to test the default option in so we will need a second configuration that disables imagick. We don't have to start that VM if we only want to check whether imagick is in its closure. As there isn't any test helper for that, we probably don't want to do that though ;-) see Unfortunately, qemu on ARM is too unreliable for the automatic tests because qemu crashes when started on one of the little cores (i.e. 4 out of 6 times). I have done some interactive testing of the above commit but not an automated run. I will have to find some system that is not ARM, not high-security, not already virtualized...
Qemu/KVM does work if a kernel build or stress-ng is hogging the big cores :) is ready for review.
Code change:
stdenv.mkDerivation rec { pname = "gvm-libs"; <del> version = "21.4.2"; </del> <ins> version = "21.4.3"; </ins> src = fetchFromGitHub { owner = "greenbone"; repo = pname; rev = "v${version}"; <del> sha256 = "14v7z8ynd20s4pkhp2nc19n6gbmbh8yrn39yi2fbfm7gj28b52sx"; </del> <ins> sha256 = "sha256-1NVLGyUDUnOy3GYDtVyhGTvWOYoWp95EbkgTlFWuxE8="; </ins> }; nativeBuildInputs = [

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: gvm-libs <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.4.2 desired version: 21.4.3 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Code change:
netdata = handleTest ./netdata.nix {}; networking.scripted = handleTest ./networking/networkd-and-scripted.nix { networkd = false; }; networking.networkd = handleTest ./networking/networkd-and-scripted.nix { networkd = true; }; <ins> networking.networkmanager = handleTest ./networking/networkmanager.nix {}; </ins> netbox_3_6 = handleTest ./web-apps/netbox.nix { netbox = pkgs.netbox_3_6; }; netbox_3_7 = handleTest ./web-apps/netbox.nix { netbox = pkgs.netbox_3_7; }; netbox-upgrade = handleTest ./web-apps/netbox-upgrade.nix {};

Related discussion:
text: Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Bleh.
I marked this as stale due to inactivity. &rarr;
consequences of our inactions
Code change:
{ lib, stdenv, fetchurl <del> , pkg-config, python3, sphinx </del> <ins> , pkg-config, sphinx </ins> , zstd , acl, attr, e2fsprogs, libuuid, lzo, udev, zlib , runCommand, btrfs-progs , gitUpdater , udevSupport ? true <del> , enablePython ? true </del> }: stdenv.mkDerivation rec {

Related discussion:
text: Python module, corresponding to the package and exposing its functionality in Python programs, fails to import, despite being included in . module is imported successfully. n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- (as maintainer) (as the one who exposed the Python bindings) Please run and paste the result.
Note: it seems like the module doesn't work even on commits that introduced it properly... To verify, run in a Nixpkgs checkout:
Yeah, I screwed up testing this. btrfs-progs doesn't propagate python, so I was using my system (non-NixOS) Python installation without noticing. should fix it.
Code change:
# - Set up the directory structure by creating the necessary symlinks. ExecStartPre = let <del> # Wrapper script which expects the full path of the state, runtime and logs </del> <ins> # Wrapper script which expects the full path of the state, working and logs </ins> # directory as arguments. Overrides the respective systemd variables to provide # unambiguous directory names. This becomes relevant, for example, if the # caller overrides any of the StateDirectory=, RuntimeDirectory= or LogDirectory=

Related discussion:
text: Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here:
Code change:
passthru.tests.version = testers.testVersion { package = gummy; }; meta = with lib; { <del> homepage = "https://github.com/Fushko/gummy"; </del> <ins> homepage = "https://codeberg.org/fusco/gummy"; </ins> description = "Brightness and temperature manager for X11"; longDescription = '' CLI screen manager for X11 that allows automatic and manual brightness/temperature adjustments, via backlight (currently only for embedded displays) and gamma. Multiple monitors are supported. ''; license = licenses.gpl3Only; <del> maintainers = [ maintainers.ivar ]; </del> <ins> maintainers = with maintainers; [ ivar ]; </ins> }; }

Related discussion:
text: Package name: gummy Latest released version: 0.6.0 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- There is an open pull request () by from October 2023, but it has not been merged and later versions of the program have been released since then. I think it is also worth noting that the source code repository of the is no longer available on GitHub. as the repository has moved to Codeberg (see ). Notify maintainers (last updated the package) <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I updated my linked PR to the latest version.
Thank you for updating it so quickly! Is there a time frame in which we can expect the pull request to be merged by someone?
Code change:
passthru.tests.version = testers.testVersion { package = gummy; }; meta = with lib; { <del> homepage = "https://github.com/Fushko/gummy"; </del> <ins> homepage = "https://codeberg.org/fusco/gummy"; </ins> description = "Brightness and temperature manager for X11"; longDescription = '' CLI screen manager for X11 that allows automatic and manual brightness/temperature adjustments, via backlight (currently only for embedded displays) and gamma. Multiple monitors are supported. ''; license = licenses.gpl3Only; <del> maintainers = [ maintainers.ivar ]; </del> <ins> maintainers = with maintainers; [ ivar ]; </ins> }; }

Related discussion:
text: Package name: gummy Latest released version: 0.5.4 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers I've tried to bump the version to 0.5.4. <details<summaryThe build fails when downloading json-poputlate</summary</details<!-- If the result shows no maintainers, tag the person that last updated the package. --
Code change:
export PATH=$PATH:$CERN_ROOT/bin ''; <ins> FFLAGS = lib.optionals (lib.versionAtLeast gfortran.version "10.0.0") [ # Fix https://github.com/vmc-project/geant3/issues/17 "-fallow-invalid-boz" # Fix for gfortran 10 "-fallow-argument-mismatch" ]; makeFlags = [ "FORTRANOPTIONS=$(FFLAGS)" ]; </ins> buildPhase = '' cd $CERN_ROOT mkdir -p build bin lib cd $CERN_ROOT/build $CVSCOSRC/config/imake_boot <del> make -j $NIX_BUILD_CORES bin/kuipc make -j $NIX_BUILD_CORES scripts/Makefile </del> <ins> make -j $NIX_BUILD_CORES $makeFlags bin/kuipc make -j $NIX_BUILD_CORES $makeFlags scripts/Makefile </ins> pushd scripts <del> make -j $NIX_BUILD_CORES install.bin </del> <ins> make -j $NIX_BUILD_CORES $makeFlags install.bin </ins> popd <del> make -j $NIX_BUILD_CORES </del> <ins> make -j $NIX_BUILD_CORES $makeFlags </ins> ''; installPhase = ''

Related discussion:
text: () is an old unmaintained software from 2006. Currently fails to build on due to typing changes: And also on that will need an fix: WDYT of removing instead of patching it? Is it still useful? CC Maintainer information:
Thank you for reporting!
Code change:
librsvg ]; <del> cargoBuildFlags = [ "--bin" "eww" ]; </del> <ins> cargoBuildFlags = [ "--bin" "eww" ]; </ins> cargoTestFlags = cargoBuildFlags;

Related discussion:
text: After upgrading to eww 0.6.0 from unstable I've got problems showing some strings in some of my widgets, one that shows the hour and another the minutes using two digits each one, i.e. : "09 : 10". When using eww 0.6.0 the string shown is like this: "... : ..." In eww's github repo I can see that there is a commit after version 0.6.0: And cloning eww repo with that commit, compiling it and using a local eww executable the problem explained before disappears for me. There's also another problem, asking eww-0.6.0 for version number shows it's 0.5.0: unstable eww 0.6.0 some string truncation (I think this is the problem) see "..." where a two char string with the hour should appear. eww should work as expected. Cloning eww repo with latest commit after v0.6.0 was published solves the problem for me.
~The current package for eww is . How did you install 0.6.0 from nixpkgs?~ ~As for the outdated 0.5.0 version in nixpkgs, there are three maintainers for eww in nixpkgs so it probably will be updated shortly, perhaps fetching a commit with the solution to the string truncation problem you describe.~ EDIT: i was wrong, see comment below.
I got it installed today from unstable when upgrading my system: But, as you say, if I look for it into unstable () it shows version 0.5.0...I can't understand very well this...I'm relatively new to nixos. Ok, I'll wait then. Thanks for your interest in this.
Oh sorry, you're right! There is eww 0.6.0 in master, although it didn't make it into unstable yet. I built the package and, indeed, truncation is broken the version is incorrectly reported So the truncation was fixed, as you mention, after the release, and the reported version . That . If you can't wait, for it, i'd recommend you use the package output from the eww flake.