jiebi/CodeConvo huggingface dataset:
Code change:
'"request":"$request",' '"http_referer":"$http_referer",' '"upstream_addr":"$upstream_addr"}'; <ins> ''; services.nginx.virtualHosts."0.my.test" = { extraConfig = '' access_log syslog:server=unix:/dev/log,facility=user,tag=mytag,severity=info ceeformat; location /favicon.ico { allow all; access_log off; log_not_found off; } </ins> ''; <del> services.nginx.virtualHosts."0.my.test" = { extraConfig = '' access_log syslog:server=unix:/dev/log,facility=user,tag=mytag,severity=info ceeformat; location /favicon.ico { allow all; access_log off; log_not_found off; } ''; }; </del> }; <ins> services.nginx.virtualHosts.localhost = { root = pkgs.runCommand "testdir" {} '' mkdir "$out" echo hello world > "$out/index.html" ''; }; }; in { webserver = commonConfig; newwebserver = { pkgs, lib, ... }: { imports = [ commonConfig ]; services.nginx.virtualHosts.localhost = { root = lib.mkForce (pkgs.runCommand "testdir2" {} '' mkdir "$out" echo hello world > "$out/index.html" ''); }; }; </ins> }; <del> testScript = '' startAll; </del> <ins> testScript = { nodes, ... }: let newServerSystem = nodes.newwebserver.config.system.build.toplevel; switch = "${newServerSystem}/bin/switch-to-configuration test"; in '' my $url = 'http://localhost/index.html'; sub checkEtag { my $etag = $webserver->succeed( 'curl -v '.$url.' 2>&1 | sed -n -e "s/^< [Ee][Tt][Aa][Gg]: *//p"' ); $etag =~ s/r?n$//; my $httpCode = $webserver->succeed( 'curl -w "%{http_code}" -X HEAD -H 'If-None-Match: '.$etag.'' '.$url ); chomp $httpCode; die "HTTP code is not 304" unless $httpCode == 304; return $etag; } </ins> $webserver->waitForUnit("nginx"); $webserver->waitForOpenPort("80"); <ins> subtest "check ETag if serving Nix store paths", sub { my $oldEtag = checkEtag; $webserver->succeed('${switch}'); my $newEtag = checkEtag; die "Old ETag $oldEtag is the same as $newEtag" if $oldEtag eq $newEtag; }; </ins> ''; })

Related discussion:
text: So this approach is completely useless without external caching. I'll investigate further and see if I can come up with a solution.
Here is a patch: If real path (after dereferencing symlinks) of is in Nix store, it will use path's hash as ETag. For example: I'll take some time to double check everything and only then send a PR. However, feel free to test: nix { pkgs, ... }: { = { enable = true; package = with pkgs; nginx.overrideAttrs (super: { patches = (super.patches or []) ++ [(fetchpatch { url = ; sha256 = "16pa1vwcm7kibkjsxpk3szaa2vnxdinml6v0fp4038i2qaav113k"; })]; }); }; }
This is really great! or anyone, do you have a moment to write an explanation of this new feature and its practical ramifications for anyone configuring an nginx server? Since it isn't typical nginx behavior, I think the nixos manual should explain it somewhere so it doesn't catch people by surprise.
I think is a good explanation, just needs to be put into the manual.
Cool, submitted .
Code change:
bin = "${getBin provider}/bin/${cmd}"; manpage = "${getOutput "man" provider}/share/man/man1/${cmd}.1.gz"; in runCommand "${cmd}-${version}" { <del> meta.platforms = map (n: { kernel.name = n; }) (attrNames providers); </del> <ins> meta = { priority = 10; platforms = map (n: { kernel.name = n; }) (attrNames providers); }; </ins> passthru = { inherit provider; }; preferLocalBuild = true; } ''

Related discussion:
text: I have installed a very barebones server with NixOS. Whenever I run it shows the following warnings: I get that it does not matter that much which of these are used, but it makes these commands not very transparent. Why is being used from and not , while is apparently part of ? Should we make sure these packages will not both be part of or should we make sure the files are only available in one of the two packages? up a minimal version of NixOS. the log
These are usually fixable by just setting priority values. coreutils should probably have a lower priority as they are usually cross platform but not as many supported features. The getconf and getent are interesting because they are actually symlinks to glibc. But we might as well make unixtools lower priority as well.
Is this something we should do nixpkgs-wide? Will that avoid the warning messages? I was thinking why these are providing the same files and why both packages are being used. For instance, do we really need openresolv or is that included unintentionally? The priorities is a way to solve this safely, but I feel like there shouldn't be any conflicts for the base packages at all.
Maybe openresolv we can leave out of systemPackages. But, some of these collisions are kind of unavoidable. We need both procps and coreutils even though they both provide kill bunary. It might be interesting to see which other distros use but IIRC they are almost identical
For coreutils, ArchLinux seems to leave out the kill binary: This also feels a bit wrong, as it isn't the original package anymore. Changing the priority does indeed sound like a better option. Coreutils should have a lower priority.
I tried giving coreutils a lower priority, but it doesn't seem to have made a difference for those warnings.
oh it already has lowprio: but it doesn't really work when everything has the same priority.
systemd-resolved is not enable by default so resolvconf shouln't be really pointing to resolvectl. I think the dummy command provided for compatibility doesn't work correctly if resolved is not running and dhcpcd needs it to configure interfaces.
Should we just give openresolv a higher priority than systemd?
Yes, correct.
Code change:
bin = "${getBin provider}/bin/${cmd}"; manpage = "${getOutput "man" provider}/share/man/man1/${cmd}.1.gz"; in runCommand "${cmd}-${version}" { <del> meta.platforms = map (n: { kernel.name = n; }) (attrNames providers); </del> <ins> meta = { priority = 10; platforms = map (n: { kernel.name = n; }) (attrNames providers); }; </ins> passthru = { inherit provider; }; preferLocalBuild = true; } ''

Related discussion:
text: The dhcpcd resolvconf hook check if resolvconf is installed and, because the command is in the PATH, it won't fall back to writing directly but will attempt to execute something like this: echo 'nameserver 10.0.1.1' | resolvconf -a wlan0 Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
Reproducible way to see these collisions: With a file set to I ran in the (the latest commit on the branch), and I get these collision messages:
ping
Hi all nixos-version 03. (Koi) I have the same collision on kill gnutar resolvconf but also on collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.
Code change:
bin = "${getBin provider}/bin/${cmd}"; manpage = "${getOutput "man" provider}/share/man/man1/${cmd}.1.gz"; in runCommand "${cmd}-${version}" { <del> meta.platforms = map (n: { kernel.name = n; }) (attrNames providers); </del> <ins> meta = { priority = 10; platforms = map (n: { kernel.name = n; }) (attrNames providers); }; </ins> passthru = { inherit provider; }; preferLocalBuild = true; } ''

Related discussion:
text: 0/share/icons/hicolor/48x48/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/48x48/apps/phonon-'
This seems to include many more collisions than related to this issue.
Maybe rather than changing the nix-env priority, a better solution is to remove some of these programs (e.g. delete in util-linux's ).
That seems hacky to me. What if you want util-linux's version of kill? Presumably if the maintainer thinks it's worth including, someone has a use for it. Nixpkgs shouldn't be making these decisions at the derivation level. Something like meta seems ideal because you can change it without effecting the derivation.
Since and were merged, does that mean this issue can be closed now?
I think so, I don't see these collisions anymore.
Let me know if this isn't fixed after all.
sorry, but i see these collisions.
Code change:
bin = "${getBin provider}/bin/${cmd}"; manpage = "${getOutput "man" provider}/share/man/man1/${cmd}.1.gz"; in runCommand "${cmd}-${version}" { <del> meta.platforms = map (n: { kernel.name = n; }) (attrNames providers); </del> <ins> meta = { priority = 10; platforms = map (n: { kernel.name = n; }) (attrNames providers); }; </ins> passthru = { inherit provider; }; preferLocalBuild = true; } ''

Related discussion:
text: it's a different issue: it seems you're installing both the wrapped and unwrapped version of the same packages. I'd say there's something wrong with your configuration, but if you think otherwise open a new issue.
Code change:
python3Packages.buildPythonApplication rec { pname = "bottles-unwrapped"; <del> version = "51.9"; </del> <ins> version = "51.11"; </ins> src = fetchFromGitHub { owner = "bottlesdevs"; repo = "bottles"; rev = version; <del> sha256 = "sha256-iZUszwVcbVn6Xsqou6crSp9gJBRmm5vEqxS87h/s3PQ="; </del> <ins> sha256 = "sha256-uS3xmTu+LrVFX93bYcJvYjl6179d3IjpxLKrOXn8Z8Y="; </ins> }; patches = [

Related discussion:
text: Package name: bottles Latest released version: 51.11 <!-- Search your package here: --- Current version on the unstable channel: 51.9 Current version on the stable/release channel: 51.9 <!-- 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! --- Old/incorrect PR Notify maintainers (for last modified) <!-- 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]:
Code change:
<del> { lib, bundlerEnv, bundlerUpdateScript, ruby, perl, autoconf }: bundlerEnv { name = "chef-dk-4.13.3"; # Do not change this to pname & version until underlying issues with Ruby # packaging are resolved ; see https://github.com/NixOS/nixpkgs/issues/70171 inherit ruby; gemdir = ./.; buildInputs = [ perl autoconf ]; passthru.updateScript = bundlerUpdateScript "chefdk"; meta = with lib; { description = "A streamlined development and deployment workflow for Chef platform"; homepage    = "https://downloads.chef.io/chef-dk/"; license     = licenses.asl20; maintainers = with maintainers; [ offline nicknovitski ]; platforms   = platforms.unix; badPlatforms = [ "aarch64-linux" ]; }; } </del>

Related discussion:
text: ChefDK is deprecated and no longer maintained by Chef. This package is currently maintained by and I believe ChefDK should be dropped and replaced by Chef Workstation (see issue ). This has been deprecated since 2021.
Code change:
"haiku/_src/integration/jax2tf_test.py" ]; <ins> disabledTests = [ # See https://github.com/deepmind/dm-haiku/issues/366. "test_jit_Recurrent" ]; </ins> meta = with lib; { description = "Haiku is a simple neural network library for JAX developed by some of the authors of Sonnet."; homepage = "https://github.com/deepmind/dm-haiku";

Related discussion:
text: Build of failed on x86_64-linux as of . Maintainer cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
Code change:
python3Packages = python3.pkgs; pythonInterpreters = callPackage ./../development/interpreters/python {}; <del> inherit (pythonInterpreters) python27 python35 python36 python37 python38 python39 python3Minimal pypy27 pypy36; </del> <ins> inherit (pythonInterpreters) python27 python36 python37 python38 python39 python3Minimal pypy27 pypy36; </ins> # Python package sets. python27Packages = lib.hiPrioSet (recurseIntoAttrs python27.pkgs); <del> python35Packages = python35.pkgs; </del> python36Packages = python36.pkgs; python37Packages = recurseIntoAttrs python37.pkgs; python38Packages = recurseIntoAttrs python38.pkgs;

Related discussion:
text: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.
Code change:
## It's also a loopback device to test exporting /dev/... systemd.services.create-priv-file = mkCreateSmallFileService { path = "/vault-priv.disk"; loop = true; }; <ins> ## `aaa.disk` is just here because "[aaa]" sorts before ## "[generic]" lexicographically, and nbd-server breaks if ## "[generic]" isn't the first section. systemd.services.create-aaa-file = mkCreateSmallFileService { path = "/aaa.disk"; }; </ins> # Needed only for nbd-client used in the tests. environment.systemPackages = [ pkgs.nbd ];

Related discussion:
text: Configuration snippet like this: yield a configuration like: However nbd-server expects section to always appear before export sections, otherwise it complains about not being able to find general section. I'd say this is upstream's fault because this order should not matter, but here we are. section to always appear before export sections. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
This looks like it should be easy to fix. I'll probably get around to it tomorrow morning.
For reference, the error looks like this:
Code change:
, numba , numpy , pillow <del> , scipy </del> , pytestCheckHook <del> , </del> <ins> , scipy , setuptools </ins> }: buildPythonPackage rec { pname = "pymatting"; version = "1.1.10"; <del> format = "setuptools"; </del> <ins> pyproject = true; </ins> src = fetchFromGitHub { owner = "pymatting";

Related discussion:
text: Steps to reproduce the behavior: python311Packages.pymatting Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
psutil-home-assistant python-kasa sqlalchemy <del> ]; # missing inputs: python-kasa.optional-dependencies.speedups </del> <ins> ] ++ python-kasa.optional-dependencies.speedups; </ins> "tplink_lte" = ps: with ps; [ ]; # missing inputs: tp-connected "tplink_omada" = ps: with ps; [

Related discussion:
text: python-kasa recently updated to 0.6.x from 0.5.x. The home-assistant project does not yet support 0.6.x, as a result kasa functionality is degraded. Using HomeAsisstant from latest nixpkgs, attempt to get emeter data from kasa devices. I reported this issue upstream and they advised on the version issue. There are more logs visible there. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I guess that if we would run the unit tests then the issue with 0.6.0 would have been detected.
Code change:
url = "https://github.com/google/snappy/pull/142/commits/658cb2fcf67b626fff2122a3dbf7a3560c58f7ee.patch"; sha256 = "1kg3lxjwmhc7gjx36nylilnf444ddbnr3px1wpvyc6l1nh6zh4al"; }) <ins> # Re-enable RTTI, without which other applications can't subclass # snappy::Source (this breaks Ceph, as one example) # https://tracker.ceph.com/issues/53060 # https://build.opensuse.org/package/show/openSUSE:Factory/snappy (fetchpatch { url = "https://build.opensuse.org/public/source/openSUSE:Factory/snappy/reenable-rtti.patch?rev=a759aa6fba405cd40025e3f0ab89941d"; sha256 = "sha256-RMuM5yd6zP1eekN/+vfS54EyY4cFbGDVor1E1vj3134="; }) </ins> ]; outputs = [ "out" "dev" ];

Related discussion:
text: All ceph tests are currently broken on release-21.11 and master. First broken in ( to ), likely due to a snappy update, like ). Steps to reproduce the behavior: -build -A etc. Tests should complete. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
Code change:
<ins> ## `invalidateFetcherByDrvHash` {#sec-pkgs-invalidateFetcherByDrvHash} Use the derivation hash to invalidate the output via name, for testing. Type: `(a@{ name, ... } -> Derivation) -> a -> Derivation` Normally, fixed output derivations can and should be cached by their output hash only, but for testing we want to re-fetch everytime the fetcher changes. Changes to the fetcher become apparent in the drvPath, which is a hash of how to fetch, rather than a fixed store path. By inserting this hash into the name, we can make sure to re-run the fetcher every time the fetcher changes. This relies on the assumption that Nix isn't clever enough to reuse its database of local store contents to optimize fetching. You might notice that the "salted" name derives from the normal invocation, not the final derivation. `invalidateFetcherByDrvHash` has to invoke the fetcher function twice: once to get a derivation hash, and again to produce the final fixed output derivation. Example: tests.fetchgit = invalidateFetcherByDrvHash fetchgit { name = "nix-source"; url = "https://github.com/NixOS/nix"; rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a"; sha256 = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY="; }; </ins>

Related discussion:
text: Fetchers are hard to test because when the output sha is verified, Nix won't download it again. This leads to confusion and PRs that are effectively untested because the others do not realize that they need to remove the store path before testing. Examples: Steps to reproduce the behavior: a fetcher -build the fetcher -build "success" but the fetcher is broken a PR effort The fetcher runs every time. This is expected but not realistic, because Nix can not guess what to re-fetch. Instead, we can make fetcher testing easier by adding fetcher tests following the pattern: So this uses IFD which is probably ok for ofborg? Regarding ; instead of somewhere, we'll have to use to set on the fetchers because they're functions. The salt may need to be passed externally in case of pure evaluation. We could make it a Nixpkgs parameter that defaults to . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Workaround: Use followed by
Or we can just put the salt in the parameter. Nix isn't clever enough to find same-hash renames in the store :)
And the salt can be derived from the unsalted drv path, which is exactly what we want. See
Code change:
sha256 = "sha256-L1j1lXPxy9nWMeED9uzQHV5y7XTE6+DB57rDnXa4kMo="; }; <del> cargoSha256 = "sha256-zNLU9QnBGna5qb+iu2imOUvCIw3ZWRFsQlpFo5ECtKo="; </del> <ins> cargoHash = "sha256-r1yIPV2sW/EpHJpdaJyi6pzE+rtNkBIxSUJF+XA8kbA="; cargoPatches = [ # Update dependencies (needed for the below patch to merge cleanly) (fetchpatch { name = "Update-dependencies-1"; url = "https://github.com/timvisee/ffsend/commit/afb004680b9ed672c7e87ff23f16bb2c51fea06e.patch"; hash = "sha256-eDcbyi05aOq+muVWdLmlLzLXUKcrv/9Y0R+0aHgL4+s="; }) # Disable unused features in prettytable-rs crate (needed for the below patch to merge cleanly) (fetchpatch { name = "Disable-unused-features"; url = "https://github.com/timvisee/ffsend/commit/9b8dee12ea839f911ed207ff9602d929cab5d34b.patch"; hash = "sha256-6LK1Fqov+zEbPZ4+B6JCLXtXmgSad9vr9YO2oYodBSM="; }) # Update dependencies (needed for the below patch to merge cleanly) (fetchpatch { name = "Update-dependencies-2"; url = "https://github.com/timvisee/ffsend/commit/fd5b38f9ab9cbc5f962d1024f4809eb36ba8986c.patch"; hash = "sha256-BDZKrVtQHpOewmB2Lb6kUfy02swcNK+CYZ3lj3kwFV4="; }) # Fix seg fault (fetchpatch { name = "Fix-segfault"; url = "https://github.com/timvisee/ffsend/commit/3c1c2dc28ca1d88c45f87496a7a96052f5c37858.patch"; hash = "sha256-2hWlFXDopNy26Df74nJoB1J8qzPEOpf61wEOEtxOVx8="; }) ]; </ins> nativeBuildInputs = [ installShellFiles ] ++ lib.optionals stdenv.isLinux [ pkg-config ];

Related discussion:
text: When using ffsend from nixpkgs, after uploading a file, the program segfaults. Using Nix on macOS with an M1 chip, but also tested it in a NixOS VM (arm64). Don't know if it works on x86. Steps to reproduce the behavior: The link to the file should be shown. Using the version from homebrew on macOS works. It even works when compiling it from source using cargo through nixpkgs (on macOS): only changed the version last time and last edit was four years ago Please run and paste the result. macOS: NixOS:
What version of rustc are you using to compile ffsend outside of nix?
I'm not familiar with Rust, I just ran in the ffsend git directory and it "just worked" so whichever version is currently in nixpkgs (at least on macOS). I haven't installed Rust on my machine.
Thanks, I have performed a bisection on nixpkgs and the regression was introduced in , so I just wanted to check that it could work with the latest rustc
Code change:
</para> <xi:include href="special/fhs-environments.section.xml" /> <xi:include href="special/mkshell.section.xml" /> <ins> <xi:include href="special/invalidateFetcherByDrvHash.section.xml" /> </ins> </chapter>

Related discussion:
text: Fetchers are hard to test because when the output sha is verified, Nix won't download it again. This leads to confusion and PRs that are effectively untested because the others do not realize that they need to remove the store path before testing. Examples: Steps to reproduce the behavior: a fetcher -build the fetcher -build "success" but the fetcher is broken a PR effort The fetcher runs every time. This is expected but not realistic, because Nix can not guess what to re-fetch. Instead, we can make fetcher testing easier by adding fetcher tests following the pattern: So this uses IFD which is probably ok for ofborg? Regarding ; instead of somewhere, we'll have to use to set on the fetchers because they're functions. The salt may need to be passed externally in case of pure evaluation. We could make it a Nixpkgs parameter that defaults to . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Workaround: Use followed by
Or we can just put the salt in the parameter. Nix isn't clever enough to find same-hash renames in the store :)
And the salt can be derived from the unsalted drv path, which is exactly what we want. See