jiebi/CodeConvo huggingface dataset:
Code change:
sha256 = "sha256-kPjS+otVZ8aJmDDd7ywD88J5YLEayiIvoXqnrGE8KJA="; }; <ins> # https://github.com/svaarala/duktape/issues/2464 LDFLAGS = [ "-lm" ]; </ins> nativeBuildInputs = [ validatePkgConfig ]; <del> postPatch = '' substituteInPlace Makefile.sharedlibrary  --replace 'gcc' '${stdenv.cc.targetPrefix}cc'  --replace 'g++' '${stdenv.cc.targetPrefix}c++' substituteInPlace Makefile.cmdline  --replace 'gcc' '${stdenv.cc.targetPrefix}cc'  --replace 'g++' '${stdenv.cc.targetPrefix}c++' ''; </del> buildPhase = '' make -f Makefile.sharedlibrary make -f Makefile.cmdline ''; installPhase = '' install -d $out/bin install -m755 duk $out/bin/

Related discussion:
text: Steps to reproduce the behavior: The regression is directly caused by , and the root cause is the library is not properly linked, upstream issue: <!-- 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.
Code change:
owner = "ful1e5"; repo = "clickgen"; rev = "refs/tags/v${version}"; <del> hash = "sha256-qDaSfIeKCbyl3C2iKz9DYQc1oNwTe5xDlGg/yYhakSw="; </del> <ins> hash = "sha256-mSaltlX2eNRLJ09zN5Tim8mW8mnjPi10W4QIEpiBQvI="; </ins> }; <del> propagatedBuildInputs = [ pillow toml numpy ]; </del> <ins> propagatedBuildInputs = [ pillow toml numpy pyyaml ]; </ins> nativeCheckInputs = [ pytestCheckHook ];

Related discussion:
text: Package name: clickgen Latest released version: 2.1.9 <!-- Search your package here: --- Current version on the unstable channel: 2.1.3 Current version on the stable/release channel: 2.1.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 <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR.
Code change:
swapview = callPackage ../os-specific/linux/swapview { }; <ins> swc = callPackage ../development/tools/swc { }; </ins> swtpm = callPackage ../tools/security/swtpm { }; svnfs = callPackage ../tools/filesystems/svnfs { };

Related discussion:
text: Project description swc is the "speedy web compiler" fast alternative to tsc, to compile typescript to javascript without type-checking swc is mentioned in a different context in adds 150 MByte to node_modules so it makes sense to factor-out swc to a global package example use: () on a 2x2GHz machine, swc is 10x faster than tsc = 2 minutes vs 20 minutes is a lightweight wrapper (1 MByte or so) but has as peer-dependency, so npm will install both Metadata homepage URL: source URL: license: apl2 platforms: all
Code change:
/pkgs/top-level/stage.nix                        @nbp @Ericson2314 @matthewbauer /pkgs/top-level/splice.nix                       @Ericson2314 @matthewbauer /pkgs/top-level/release-cross.nix                @Ericson2314 @matthewbauer <del> /pkgs/stdenv/generic                             @Ericson2314 @matthewbauer </del> <ins> /pkgs/stdenv/generic                             @Ericson2314 @matthewbauer @cab404 </ins> /pkgs/stdenv/cross                               @Ericson2314 @matthewbauer /pkgs/build-support/cc-wrapper                   @Ericson2314 @orivej /pkgs/build-support/bintools-wrapper             @Ericson2314 @orivej

Related discussion:
text: I tried to build a package with debug symbols today and failed. NixOS wiki and nixpkgs repository comments say the following should work: Please run and paste the result.
It worked in Aug 2018: Bisected down to breakage at : Looks like it stems from the fact that does not expose anymore, only . /cc
Woah. master and both work for me with nix stable.
That's surprising. Here is my attempt at current master checkout: I tried removing and seeing the same failure. I wonder why it works for you. Might be a different stdenv?
Does it mean and are the same object?
i can reproduce
I can also reproduce with stable Nix (2.3.14):
Hmm, the issue is that / slaps the on after is defined, closing over the old . In Smalltalk paralance, this would be an issue of insufficiently "late binding".
Still reproducible on current master ()
I ran into this.
Bump, ran into this while updating the Nixpkgs pin on a project of mine.
There should be a test for this :)
Gonna spend next hour or two trying to fix this.
Things that are also missing:
So, this function is not executed on passed through stdenv. Not yet sure why.
Yeah, I've fixed it (thanks, for being there :heart:)
Post-mortem: always read threads. Solution was kinda already provided in , but I delved right in without knowing that)
atleast you now know more about stdenv :slightlysmilingface:
How is the PR looking? I've been waiting on this for a couple of weeks to debug an intermittent crash I'm having with xfce4-sesion :)
Code change:
buildInputs = [ bzip2 libxml2 libzip boost lua luabind tbb expat ]; <ins> patches = [ ./darwin.patch ]; </ins> env.NIX_CFLAGS_COMPILE = toString [ # Needed with GCC 12 "-Wno-error=stringop-overflow"

Related discussion:
text: Steps to reproduce the behavior: FWIW: my fix is here, - but it is using a fork of . If somebody has the time to create a minimal patch on top of the current source, please feel free to. Please run and paste the result.
Looks like you are on a good path. Unfortunately I have no access to Apple hardware at all, but would be happy to merge a PR.
Yes, is working on it. There is a more active fork of luabind here: - how about we switch to using it? It'll obviate a bunch of patches as well.
I agree, sounds sensible.
Code change:
libnotify libX11 libXcomposite <ins> libunity </ins> libuuid libXcursor libXdamage

Related discussion:
text: I never really noticed this until today, but apparently the discord task bar icon (if you have one, I am on KDE) is supposed to have a notification badge, I have included a screenshot. The discord task bar icon should include a badge for the number of unread notifications ! Today I was setting up a system for someone else who was new to Linux, I installed Discord via flatpak, and then they asked me about the badge (since it is present on Windows but not on the ). From a little searching, it seems that Discord needs to ba available in the system, so on Kubuntu this was fixed by doing . Since is already in , it might just be a matter of adding it to the ?
Huh. I don't think I ever knew one was supposed to be there either. I see an unread indicator (red circle in the top corner, no number), so that works fine, but I don't think I've ever seen a number. Assuming that would be all it would take, sounds like a pretty simple PR that would be a good addition.
I have made a clone of and it does seem that all that was need was to add the library to . I found it to be a bit ugly myself since I had over 1000 unread notifications, and it seems disabling it is only possible outside the application. On for example, you have to go to and tick off "Show notification badges". Running the current from afterwords does not remove the badges, it only freezes them in place, as in marking notifications as read will not update the number, so this is also cached somewhere outside , meaning this couldn't be a toggleable functionality via an .
Code change:
, closureInfo , coreutils , e2fsprogs <del> , fakechroot </del> <ins> , proot </ins> , fakeNss , fakeroot , go

Related discussion:
text: Relevant snippet while building it fails with I copied over the for debugging, this is the full output: Steps to reproduce the behavior: snippet as flake default output Build should succeed and images should be loadable via Patching the as follows: fixes the problem, but would probably hide other cp errors. Maybe the behavior of coreutils/cp changed in the recent versions. At least the current manual states it will fail silently. I'm using a linux-builder on my machine.
Thank you for reporting this. I’ll try to replicate this locally. The lines do not look like errors to me. It looks like is informing that those files already exist in the output and thus are skipped (--no-clobber). However, if the build is failing there’s something going wrong.
Thank you for linking the manual. It looks like will exit with a non-zero status code in case of files that are already present now. The coreutils changelog states that now reproduces the behavior had at the time I wrote the mergeImages script. I was able to build by changing to . I don't know how to best go about obtaining the behavior everywhere, should the flag be dependent on the version of somehow? Maybe we can just assume that in will be a new version from now so that we can use everywhere? Given that all files that are present in both docker images apart from the and repositories files should be content addressed the only issue with removing is that time is spent unnecessarily writing content that's already present, so removing the flag altogether might make sense.
Thanks for investigating! I'm not familiar with the backward compatibility policy of the nix ecosystem, but I would assume that the most recent version of can assume most recent coreutils. Might happen that someone is overlaying old coreutils but then you might just need to overlay the old too, if you can pinpoint it down to coreutils cp.
True, but then apparently they have a legacy software problem, in which case they should use overrides only where it is necessary, instead of a blanket override in an overlay. It is not realistic to expect all of Nixpkgs to work with arbitrary changes. The cost of such compat logic isn't worth it; certainly not in this case, until proven otherwise. If they contribute a full time maintainer it is worth it, and if they have a legacy software problem they probably can.
Code change:
{ stdenv, lib, buildPackages <del> , fetchurl, zlib, autoreconfHook </del> <ins> , fetchurl, zlib, autoreconfHook, gettext </ins> # Enabling all targets increases output size to a multiple. , withAllTargets ? false, libbfd, libopcodes , enableShared ? true

Related discussion:
text: I'm not really sure why this would happen or how to go about dealing with this. Any tips?
(triage) still a problem?
Unsure, I don't use nix on my mac anymore.
This was a coreutil, right? If so, it’s probably fixed by now.
Probably safe to assume so.
I'm actually hitting the same thing right now.
Code change:
done ''; <del> doInstallCheck = true; </del> <ins> doInstallCheck = !stdenv.hostPlatform.isAarch64; # tests are flaky for aarch64-linux on hydra </ins> installCheckTarget = "testall"; preInstallCheck = ''

Related discussion:
text: Steps to reproduce the behavior: I came up with the idea of building julia19 for that platform as a possible resort as the binary artifact does not work as is on my hardware, causing a , see also . <!-- 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.
The failure is also reproducible on hydra: , looks like the flaky tests that have been plaguing us for a long time.
Code change:
, target ? null # Select whether DYNAMIC_ARCH is enabled or not. , dynamicArch ? null <ins> # enable AVX512 optimized kernels. # These kernels have been a source of trouble in the past. # Use with caution. , enableAVX512 ? false </ins> , enableStatic ? stdenv.hostPlatform.isStatic , enableShared ? !stdenv.hostPlatform.isStatic }:

Related discussion:
text: Describe the bug In the AVX512 support was turned back on in openblas, allowing for the use of dynamic, AVX512 optimized compute kernels. started to discover problems with AVX512 while working on the and I can confirm that this problem affects multiple packages that are built against openblas. The problem already manifest itself in that packages fail their unit tests, when build on an AVX512 enabled machine (see for a detailed list). The tests either fail due to a wrong result or time out. I could indentify 5 different packages which are affected by this bug, leading to the conclusions this very likely affects many more packages. Affected versions of openblas, which I have tested, are 0.3.13 (master/release-21.05) and 0.3.15 (in staging at the moment). The problem disappears when: is complied with in is injected into the test phase or just set at runtime. Note that any core type that does not use AVX512 works fine here (tested: , or , but , which uses AVX512 fails). is turned off at openblas build time and is set to a non-AVX512 target (see point 2). you seem to be making use AVX512 optimizations. Did you notice any problems? I suggest to revert and thus re-introduce the makeFlag in openblas. To Reproduce an affected program which is linked against openblas on an Intel CPU that supports AVX512 instructions (e.g. Xeon Scalable) and check the results. In nixpkgs it is at least that is affected (delivers wrong results). , for example, on an Intel CPU with AVX512: the self tests/unit tests never finish in this case. external packages fail to run their tests on and AVX512 enabled machine: Notify maintainers CC Metadata This should affect since (~January 2021) and . The tests I have carried out were run with versions from the ~last week.
Sorry to hear that :(. Then we should indeed revert that change again.
Can this be closed?
The PR has been merged into staging. Should we wait to close the issue until the fix reaches master?
Code change:
stdenv.mkDerivation rec { pname = "spirv-tools"; <del> # Update spirv-headers rev in lockstep according to DEPs file version = "2021.3"; </del> <ins> version = "1.2.198.0"; </ins> src = fetchFromGitHub { owner = "KhronosGroup"; repo = "SPIRV-Tools"; <del> rev = "v${version}"; sha256 = "sha256-skpsxpgl6hR5uiKfphKFQJfh+LJvhGvDW/t2u5AhXzk="; </del> <ins> rev = "sdk-${version}"; sha256 = "sha256-8EJbTPY5dvsqx32POf2HcCV3j2fA68GtGZA66l9V4TI="; </ins> }; nativeBuildInputs = [ cmake python3 ];

Related discussion:
text: name: All packages in current version: 1.2.189.1 desired version: 1.2.200 maintainers: Please tag this issue in your PR.
Code change:
<del> { config, lib, ... }: </del> <ins> { config, pkgs, lib, ... }: </ins> with lib; let

Related discussion:
text: Describe the bug Most of my programs is unable resolve DNS after I updated my system to (from the last time nixos-ustables was updated which is approximately 14 days ago). This includes curl, chrome, resolvectl and nix which basically makes my system unusable. One really weird exception is the tool which is actually able to query both a remote server (such as 8.8.8.8) and the local systemd-resolved server to resolve DNS (which indicates that this is probably not the fault of systemd). There's also a error message in systemd-resolved's that said "Failed to escape hostname: Invalid argument". I also tried to edit my file to change the nameserver to 8.8.8.8 and that didn't change anything. here are some examples of the errors returned by those programs: To Reproduce I don't really know how to reproduct this issue Expected behavior DNS should be working properley on all programs Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:
Programs which are broken are using the libc calls to resolve the hostname, looks like the nss module from systemd-resolved can't resolve the hostname either. This looks to be some kind of failure within systemd-resolved, since systemd-resolve on the CLI fails with . We should also open an upstream bug unless we find some evidence that this is caused by NixOS.
This bug affects me too. Same error and same logs.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Same bug on my end.
I think I figured out what's the problem here. I opened an upstream issue: Can you try if the following patch works around the issue?
that worked! (though I have to manually edit the service file since automatic GC kicked in and I cannot rebuild my system:facepalm:) Also, I feel like there should be a basic network connectivity test to prevent bugs like this from being merged into the unstable channel.
And thanks for the quick action ! I agree, but I thought we actually have them for unstable?
Code change:
<del> { config, lib, ... }: </del> <ins> { config, pkgs, lib, ... }: </ins> with lib; let

Related discussion:
text: I've the following to my : and I can confirm systemd-resolved works again. Now, how do you get to rebuild your system if like you don't have a working system to rollback to? I did (as root): to force using that file in order to be able to run .
aw man I did not know that if you stop systemd-resolved it will resolve normally. I removed the symlink and created a new directory there, copied everything from to there, manually edited systemd-resolved.service, and ran and after that restarted systemd-resolved. method is definitely more superior.
So... for now we push this workaround to nixpkgs master?
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I'd say yes. Especially if there's no quick upstream fix in perspective. Hopefully this problem only affects users following unstable.
Stable doesn't get systemd updates, so it shouldn't be affected (based on flokli's analysis).
PR at
Code change:
url = "https://code.qt.io/cgit/qt/qtwayland.git/patch/?id=6fe83f6076423068b652fa4fcb0b5adbd297f2a8"; hash = "sha256-TlZozKezpYm90B9qFP9qv76asRdIt+5bq9E3GcmFiDc="; }) <ins> # Fix potential crash issues when some submenus are expanded # https://codereview.qt-project.org/c/qt/qtwayland/+/519344/ (fetchpatch { url = "https://code.qt.io/cgit/qt/qtwayland.git/patch/?id=aae65c885d8e38d8abc2959cded7b5e9e5fc88b3"; hash = "sha256-FD1VaiTgl9Z1y+5EDpWYShM1ULoFdET86FoFfqDmjyo="; }) </ins> ]; }

Related discussion:
text: Submenus (rendered as popups) in some qt apps (happens a lot in telegram-desktop) can make the app crash if one clicks outside while they are shown. It's a bug in qt6.6 that is foxed by this patch: Other distros (Arch at least) include the patch already.
Code change:
let ss = opt.type.getSubOptions opt.loc; in if ss != {} then optionAttrSetToDocList' opt.loc ss else []; in <del> [ docOption ] ++ subOptions) (collect isOption options); </del> <ins> [ docOption ] ++ optionals docOption.visible subOptions) (collect isOption options); </ins> /* This function recursively removes all derivation attributes from

Related discussion:
text: Describe the bug When renaming a submodule, the makes the child options reappear in the docs at the old location. This did not happen before (ping I've encountered the problem in the arion docs when its tooling to nixpkgs 20.03. The move is -. The regression makes the docs start with a mountain of legacy options comprising just under half of all options. Reverting fixes the problem. To Reproduce Steps to reproduce the behavior: an option to is in the docs, despite Expected behavior The option docs should have at most one entry per renamed option. Any suboptions should be omitted. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
Code change:
jobs = recursiveUpdateMany [ (mapTestOn { haskellPackages = packagePlatforms pkgs.haskellPackages; <del> haskell.compiler = packagePlatforms pkgs.haskell.compiler; </del> <ins> haskell.compiler = packagePlatforms pkgs.haskell.compiler // (lib.genAttrs [ "ghcjs" "ghcjs810" ] (ghcjsName: { # We can't build ghcjs itself, since it exceeds 3GB (Hydra's output limit) due # to the size of its bundled libs. We can however save users a bit of compile # time by building the bootstrap ghcjs on Hydra. For this reason, we overwrite # the ghcjs attributes in haskell.compiler with a reference to the bootstrap # ghcjs attribute in their bootstrap package set (exposed via passthru) which # would otherwise be ignored by Hydra. bootGhcjs = (packagePlatforms pkgs.haskell.compiler.${ghcjsName}.passthru).bootGhcjs; })); </ins> tests.haskell = packagePlatforms pkgs.tests.haskell;

Related discussion:
text: As a fallout of the migration to GHC 9.0.2 got marked as broken, as it failed to build with GHC 9.0.2 and the Stackage LTS 19 package set we now have. It would be necessary to investigate if survived this (i.e. if it still builds) and if not to get it to work again. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc
should compile again. The bootstrap is additionally built by Hydra, so only the GHC bundled libraries will need to be compiled (which is an improvement to before at least).
Code change:
''; nativeBuildInputs = [ <del> pythonRelaxDepsHook </del> which ]; <del> pythonRelaxDeps = [ "pyre-extensions" ]; </del> propagatedBuildInputs = [ numpy torch <del> pyre-extensions </del> ]; pythonImportsCheck = [ "xformers" ];

Related discussion:
text: Package name: Latest released version: 0.0.22.post7 <!-- Search your package here: --- Current version on the unstable channel: (This version never existed but whatever!) Current version on the stable/release channel: None <!-- 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 Note for maintainers: Please tag this issue in your PR. Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
let me know if you have time to test
Code change:
certifi, cffi, charset-normalizer, <ins> cryptography, </ins> cython, <del> fetchPypi, </del> <ins> fetchFromGitHub, </ins> filelock, idna, keyring, <del> oscrypto, </del> packaging, pandas, platformdirs, pyarrow, <del> pycryptodomex, </del> pyjwt, pyopenssl, <ins> pytest-xdist, pytestCheckHook, </ins> pythonOlder, pytz, requests,

Related discussion:
text: package lists and as dependencies but upstream uses instead. Steps to reproduce the behavior: dependencies of package it to the dependencies listed by upstream and should not be in the dependencies list, but should n/a <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
That's a bot.
Thank you for the quick turnaround!
Code change:
# These assertions can be removed in NixOS 24.11, when all users have been # warned once. { <del> assertion = (cfg.settings ? replication_factor || cfg.settings ? replication_mode) || lib.versionOlder cfg.package.version "1.0.0"; </del> <ins> assertion = (cfg.settings ? replication_factor || cfg.settings ? replication_mode) || lib.versionOlder cfg.package.version "1.0.0"; </ins> message = '' Garage 1.0.0 requires an explicit replication factor to be set. Please set replication_factor to 1 explicitly to preserve the previous behavior.

Related discussion:
text: Steps to reproduce the behavior: -rebuild test on settings.datadir = "/mnt/garage0"; resolves fine Tested on nixos24.05 but code of the module is unchanged in nixos_unstable. I'm using flakes as well Please run and paste the result.
Looks like doesn't apply, maybe should tinker a bit on my own
It looks like the option type was adjusted, but not the other code in the module that checks that value. Shouldn't be too hard to fix.
Code change:
./programs/light.nix ./programs/mosh.nix ./programs/mininet.nix <ins> ./programs/msmtp.nix </ins> ./programs/mtr.nix ./programs/nano.nix ./programs/nm-applet.nix

Related discussion:
text: The ssmtp program is dead/unmaintained. The commonly suggested substitute is msmtp. While [home-manager has a module for msmtp][1], NixOS lacks one. [1]: Let's: [x] Done in We should probably also: [x] Remove the ssmtp NixOS module and add migration instructions to the release notes () [x] Remove the ssmtp package ()
I marked this as stale due to inactivity. &rarr;
The module works really well. Thanks for the module