jiebi/CodeConvo huggingface dataset:
Change:
--replace /sbin/ip ${iproute2}/sbin/ip wrapProgram "$out/sbin/dhclient-script" --prefix PATH :  "${nettools}/bin:${nettools}/sbin:${iputils}/bin:${coreutils}/bin:${gnused}/bin" <ins> '' + lib.optionalString (!withClient) '' rm $out/sbin/{dhclient,dhclient-script,.dhclient-script-wrapped} '' + lib.optionalString (!withRelay) '' rm $out/sbin/dhcrelay </ins> ''; preConfigure =

Discussion:
Was announced multiple times, now it is EOL with release 4.2.3 We should remove it before branching 22.05.
Change:
# Always run steamcmd in the user's Steam root. STEAMROOT=@steamRoot@ <ins> # Add coreutils to PATH for mkdir, ln and cp used below PATH=$PATH${PATH:+:}@coreutils@/bin </ins> # Create a facsimile Steam root if it doesn't exist. if [ ! -e "$STEAMROOT" ]; then mkdir -p "$STEAMROOT"/{appcache,config,logs,Steamapps/common}

Discussion:
I tried to create a Docker file using Nix which, in its , just calls . This fails because contains , which, apparently, isn't put into the Docker image. system: host os: multi-user?: sandbox: version: channels(philipp): channels(root): nixpkgs:
Change:
stdenv.mkDerivation rec { pname = "junction"; <del> version = "1.5.0"; </del> <ins> version = "1.6"; </ins> src = fetchFromGitHub { owner = "sonnyp"; repo = "junction"; rev = "v${version}"; <del> sha256 = "sha256-jS4SHh1BB8jk/4EP070X44C4n3GjyCz8ozgK8v5lbqc="; </del> <ins> sha256 = "sha256-95lKap0VKLxX5Vax2tK0cAcJ/XgQddoN46tXHo+MtYc="; fetchSubmodules = true; </ins> }; nativeBuildInputs = [ appstream-glib <ins> blueprint-compiler </ins> desktop-file-utils gobject-introspection meson

Discussion:
running from displays a transparent window which is only drawn after 40 seconds (I timed it, it's not an exaggeration). Similarly, clicking the menu button takes about 20s to display the menu. Only the close button is "fast". Steps to reproduce the behavior: 's slow ... it displays fast on the right is the transparent window and my wallpaper. ! I'm not running gnome, but xfce+i3+picom if it's relevant. But as junction eventually works, something is probably not missing. cc system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): nixpkgs:
Opens within a few seconds here with LXQt on a twelve-year old CPU... tested with:
I'm using plasma on unstable and I experience normal app delay. (1-2 seconds). (Maybe one or two iterations old). There is ; however, I do not know how applicable it is. I tried to follow the steps using a shell based on the derivation (plus blueprint-compiler) but I encounter the following error (will try again tomorrow) PS: Also thanks, I didnt realize that I needed to update junction to 1.6 (I'll try to do it soon, .... but its a javascript dependency)
Note: the issue does not happen with the flatpak.
it's actually caused by setting to 1, a workaround to
Change:
<del> {   lib, buildPythonApplication, fetchPypi , altair, astor, base58, blinker, boto3, botocore, click, enum-compat , future, pillow, protobuf, requests, toml, tornado_5, tzlocal, validators, watchdog , jinja2, setuptools </del> <ins> { # Nix lib, buildPythonApplication, fetchPypi, # Build inputs altair, astor, base58, blinker, boto3, botocore, click, cachetools, enum-compat, future, GitPython, jinja2, pillow, pyarrow, pydeck, pympler, protobuf, requests, setuptools, toml, tornado, tzlocal, validators, watchdog, </ins> }: <del> buildPythonApplication rec { </del> <ins> let click_7 = click.overridePythonAttrs(old: rec { version = "7.1.2"; src = old.src.override { inherit version; sha256 = "d2b5255c7c6349bc1bd1e59e08cd12acbbd63ce649f2588755783aa94dfb6b1a"; }; }); in buildPythonApplication rec { </ins> pname = "streamlit"; <del> version = "0.50.2"; </del> <ins> version = "1.2.0"; </ins> format = "wheel"; # the only distribution available src = fetchPypi { inherit pname version format; <del> sha256 = "1wymv7qckafs0p2jdjlxjaf1xrhm3iyd185jkldanbb0na5n3ndz"; </del> <ins> sha256 = "1dzb68a8n8wvjppcmqdaqnh925b2dg6rywv51ac9q09zjxb6z11n"; </ins> }; propagatedBuildInputs = [ <del> altair astor base58 blinker boto3 botocore click enum-compat future pillow protobuf requests toml tornado_5 tzlocal validators watchdog jinja2 setuptools </del> <ins> altair astor base58 blinker boto3 botocore cachetools click_7 enum-compat future GitPython jinja2 pillow protobuf pyarrow pydeck pympler requests setuptools toml tornado tzlocal validators watchdog </ins> ]; postInstall = ''

Discussion:
name: current version: desired version: latest version: maintainers: Please tag this issue in your PR.
You'll have to package pydeck as well
Here's my hack to get things working: And WIP:
I can PR this for you if you accept maintaining the dependency.
ping
Change:
]) etc'} ''; <del> etcHardlinks = filter (f: f.mode != "symlink") etc'; </del> <ins> etcHardlinks = filter (f: f.mode != "symlink" && f.mode != "direct-symlink") etc'; </ins> build-composefs-dump = pkgs.runCommand "build-composefs-dump.py" {

Discussion:
Locale module is the only place in nixpkgs that mentions etc entry type: overlay generation code acknowledges the existence only of the type (). The provided system configuration builds. Mentioning since they committed the overlay code. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Simply replacing with in the locale module makes the build succeed. reports the correct timezone, and the symlink correctly points to the selected timezone within the .
Ah, it's much more complicated than that. The reason why exists is because some apps try to read the timezone name directly from the symlink path itself (, ). While the solution above makes the provided system configuration build, Java applications will fallback to using UTC because they are unable to parse the timezone name from the generated symlink.
Change:
]) etc'} ''; <del> etcHardlinks = filter (f: f.mode != "symlink") etc'; </del> <ins> etcHardlinks = filter (f: f.mode != "symlink" && f.mode != "direct-symlink") etc'; </ins> build-composefs-dump = pkgs.runCommand "build-composefs-dump.py" {

Discussion:
If I try to make my system perlless, my system rebuild fails. Steps to reproduce the behavior: the following module to your system configuration: The command succeeds. Commands: succeeds. I use flakes. <!-- 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]:
Odd, thought was meant to fix this. Perhaps more digging is needed.
What is the revision of nixpkgs that you are trying to build your system with? is merged without a 24.05 backport.
Per nix-info they're on 24.05 not unstable, so that makes sense. Is it backportable?
The PR itself is backportable, but I'm not sure if it complies with nixpkgs' .
Right, that's what I meant to ask - is it a breaking change? (i.e. is it possible for someone to rely on the old behaviour?) or simply a bugfix with low chance of regressions?
Is it not a breaking change because the option is marked as experimental (and also because the behavior before the PR was erroneous in the first place).
Fixed in .
Change:
./programs/autojump.nix ./programs/bandwhich.nix ./programs/bash/bash.nix <ins> ./programs/bash/bash-completion.nix ./programs/bash/ls-colors.nix ./programs/bash/undistract-me.nix </ins> ./programs/bash-my-aws.nix ./programs/bcc.nix ./programs/browserpass.nix

Discussion:
Project description A bash utility; "Notifies you when long-running terminal commands complete." Metadata homepage URL: license: "All of undistract-me, including this file, is made available with the Expat license. See LICENSE for details."
Change:
x@{builderDefsPackage , gnome, gtk, glib, libxml2, pkgconfig, libvirt, gtkvnc, cyrus_sasl, libtasn1 <del> , gnupg, libgcrypt, perl, nettle, yajl </del> <ins> , gnupg, libgcrypt, perl, nettle, yajl, libcap_ng </ins> , ...}: builderDefsPackage (a :

Discussion:
A clear and concise description of what the bug is. Steps to reproduce the behavior: Mac Silicon, Utilizing with nix-darwin, i've the folllowing : always get qemu-system-aarch64 as qemu binary and then an aarch64 linux builder uname -a should give x86-64_linux Qemu binary program in () should not be forced to hostPlatform system for this linux builder case If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Did not find any issues related to this qemu program choice.
I think the qemu binary is set correctly in the builders, in this file: I was also having this problem, and found this issue while looking into it. But I realized the result is being caused by these lines in nix-darwin: () That looks fine, but the builder package we're trying to use is also created using override! So the in nix-darwin is overriding the in nixpkgs, making the resulting package have the default hostPlatform. You can work around this by setting that value in your nix darwin config, like this: I've opened a pull request to make this work the way we expected it to: Thank you for this issue, it confirmed that I wasn't the only person having this problem, and led me to find the cause.
Thanks a lot !
Change:
stdenv.mkDerivation { pname = "libvterm-neovim"; <del> version = "2019-08-28"; </del> <ins> version = "2019-10-08"; </ins> src = fetchFromGitHub { owner = "neovim"; repo = "libvterm"; <del> rev = "1aa95e24d8f07a396aa80b7cd52f93e2b5bcca79"; sha256 = "0vjd397lqrfv4kc79i5izva4bynbymx3gllkg281fnk0b15vxfif"; </del> <ins> rev = "7c72294d84ce20da4c27362dbd7fa4b08cfc91da"; sha256 = "111qyxq33x74dwdnqcnzlv9j0n8hxyribd6ppwcsxmyrniyw9qrk"; </ins> }; buildInputs = [ perl ];

Discussion:
Describe the bug Neovim crashes when resizing windows under some circumstances. To Reproduce There are many different ways to repro, these are some reliable steps to reproduce the behavior: to create a split to open a terminal to go to other window to maximize window Expected behavior Windows should resize and there should be no crash. Additional context Originally filed at but it seems to only be affecting NixOS. The crashes only started since I upgraded from NixOS 19.03 to 19.09. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information: cc
If you have a known-good nixos revision and a known-bad nixos revision you could try the issue.
The earliest local generation on which this happens is from . The latest known-good generation is from . I'm not sure these are accurate though, I'd have expected this to have happened later.
narrowed it down to which was part of
That looks helpful. Maybe you can report upstream that the libvterm update is responsible, and ask if someone on non-nixos can reproduce it with that version of libvterm (or report which version they use).
Thanks for guiding me in the right path I opened a PR with a fix. :point_up:
Thanks for fixing this :)
Change:
"asciidoctor-latex" "asciidoctor-pdf" "asciidoctor-safe" <del> "asciidoctor-mathematical" </del> ]; gemConfig = {

Discussion:
After a today, asciidoctor fails to install: I am afraid I have not spent time debugging, but this seemed worth reporting since the installation process itself fails which seems like it might be an infrastructure issue rather than a bug in the package? Ubuntu 17.10: WARNING removes any other packages (just to show it happens regardless of other packages installed):
Change:
/usr/local/nvidia/lib64. ''; }; <ins> package = lib.mkPackageOption pkgs "nvidia-container-toolkit" { }; </ins> }; };

Discussion:
The service will ask docker to mount the binary which is not provided by the Nvidia driver v470. Using NixOS 24.05 with nixpkgs . Steps to reproduce the behavior: should not be mounted when the binary is missing. <img width="1234" alt="image" src=""<img width="854" alt="image" src="" Edited: a workaround Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thank you for the report You can also set in the meantime. I'll open a PR as soon as possible.
Change:
libXext, wayland, libGL, makeWrapper }: let <del> version = "1.0.61.1"; </del> <ins> version = "1.1.70.0"; </ins> src = fetchFromGitHub { owner = "KhronosGroup"; repo = "Vulkan-LoaderAndValidationLayers"; rev = "sdk-${version}"; <del> sha256 = "043kw6wnrpdplnb40x6n9rgf3gygsn9jiv91y458sydbhalfr945"; </del> <ins> sha256 = "1a7xwl65bi03l4zbjq54qkxjb8kb4m78qvw8bas5alhf9v6i6yqp"; </ins> }; in

Discussion:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:
Change:
stdenv.mkDerivation rec { pname = "janet"; <del> version = "1.29.1"; </del> <ins> version = "1.30.0"; </ins> src = fetchFromGitHub { owner = "janet-lang"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-waBOPrcZ1mNsvb2PrivYUmbUKv1mxD/rMFOCZXslyKA="; </del> <ins> hash = "sha256-tkXEi8m7eroie/yP1kW0V6Ld5SCLA0/KmtHHI0fIsRI="; </ins> }; postPatch = ''

Discussion:
Steps to reproduce the behavior: on an apple silicon darwin machine. Obtained via I know this wasn't an issue a month ago, but haven't bisected this to be able to pinpoint when this started happening. <!-- 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.
Change:
wayland libxkbcommon fcft <ins> utf8proc </ins> ]; # recommended build flags for performance optimized foot builds

Discussion:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.
Change:
sha256 = "633c2f89481d8ebc55639b59216f7d16d07b44a94758850c0b887006967214f3"; }; <ins> patches = [ ./ZODB-5.3.0-fix-tests.patch ]; </ins> propagatedBuildInputs = [ manuel transaction

Discussion:
I tried to build and but without success. Relevant part of the error message: Tried to do it on current master. nix-build -I nixpkgs=. -A System: Local nixpkgs checkout on Gentoo Nix version: 1.11.15 Nixpkgs version: 17.09.1880. Sandboxing enabled: true
Same problem on a native NixOS machine.
Change:
++ lib.optional systemdSupport "--with-fpm-systemd" ++ lib.optional valgrindSupport "--with-valgrind=${valgrind.dev}" ++ lib.optional ztsSupport "--enable-maintainer-zts" <ins> # Sendmail ++ [ "PROG_SENDMAIL=${system-sendmail}/bin/sendmail" ] </ins> ; hardeningDisable = [ "bindnow" ];

Discussion:
Describe the bug A clear and concise description of what the bug is. If I try to use the function in from the command line I get an error: To Reproduce Steps to reproduce the behavior: is printed to console Expected behavior A clear and concise description of what you expected to happen. should define so works. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Currently NixOS modules (, ) handle this for the most part, but it would be nice to avoid duplication and have this defined once - in the package instead of modules. 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. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
{ autoPatchelfHook , blas , cmake <ins> , cudaPackages_11 ? null </ins> , cudaPackages , cudaSupport ? config.cudaSupport , fetchurl , gfortran <del> , cudaCapabilities ? cudaPackages.cudaFlags.cudaCapabilities </del> , gpuTargets ? [ ] # Non-CUDA targets, that is HIP , rocmPackages , lapack

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.torchvision maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags: - -
Will be closed by
Change:
stdenv.mkDerivation rec { pname = "vimix-gtk-themes"; <del> version = "2020-11-28"; </del> <ins> version = "2021-04-25"; </ins> src = fetchFromGitHub { owner = "vinceliuice"; repo = pname; rev = version; <del> sha256 = "1m84p4cs9dfwc27zfjnwgkfdnfmlzbimq3g5z4mhz23cijm178rf"; </del> <ins> sha256 = "0ak763vs27h5z2pgcqpz1g1hypn5gl0p0ylffawc9zdi1wp2mpxb"; </ins> }; buildInputs = [ gtk_engines ];

Discussion:
<!-- 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: vimix-gtk-themes <!-- 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: 2020-11-28 desired version: 2021-04-25 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: the install Phase currently doesn't install all the variations of the theme, only the "doder", you must pass the parameter "-a" or "--all" to "" Please tag this issue in your PR.
Change:
in buildPythonApplication rec { pname = "lutris-original"; <del> version = "0.5.8.4"; </del> <ins> version = "0.5.9.1"; </ins> src = fetchFromGitHub { owner = "lutris"; repo = "lutris"; rev = "v${version}"; <del> sha256 = "sha256-5ivXIgDyM9PRvuUhPFPgziXDvggcL+p65kI2yOaiS1M="; </del> <ins> sha256 = "sha256-ykPJneCKbFKv0x/EDo9PkRb1LkMeFeYzTDmvE3ShNe0="; </ins> }; nativeBuildInputs = [ wrapGAppsHook ];

Discussion:
<!-- 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: lutris-unwrapped <!-- 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: 0.5.8.4 desired version: 0.5.9 <!-- 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.
Change:
mode="0777", payload=source, ) <ins> elif os.path.isdir(source): composefs_path = ComposefsPath( attrs, size=4096, filetype=FileType.directory, mode=mode, payload=source, ) </ins> else: <del> if os.path.isdir(source): composefs_path = ComposefsPath( attrs, size=4096, filetype=FileType.directory, mode=mode, payload=source, ) else: composefs_path = ComposefsPath( attrs, size=os.stat(source).st_size, filetype=FileType.file, mode=mode, # payload needs to be relative path in this case payload=target.lstrip("/"), ) </del> <ins> composefs_path = ComposefsPath( attrs, size=os.stat(source).st_size, filetype=FileType.file, mode=mode, # payload needs to be relative path in this case payload=target.lstrip("/"), ) </ins> paths[target] = composefs_path add_leading_directories(target, attrs, paths)

Discussion:
Locale module is the only place in nixpkgs that mentions etc entry type: overlay generation code acknowledges the existence only of the type (). The provided system configuration builds. Mentioning since they committed the overlay code. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Simply replacing with in the locale module makes the build succeed. reports the correct timezone, and the symlink correctly points to the selected timezone within the .
Ah, it's much more complicated than that. The reason why exists is because some apps try to read the timezone name directly from the symlink path itself (, ). While the solution above makes the provided system configuration build, Java applications will fallback to using UTC because they are unable to parse the timezone name from the generated symlink.
Change:
mode="0777", payload=source, ) <ins> elif os.path.isdir(source): composefs_path = ComposefsPath( attrs, size=4096, filetype=FileType.directory, mode=mode, payload=source, ) </ins> else: <del> if os.path.isdir(source): composefs_path = ComposefsPath( attrs, size=4096, filetype=FileType.directory, mode=mode, payload=source, ) else: composefs_path = ComposefsPath( attrs, size=os.stat(source).st_size, filetype=FileType.file, mode=mode, # payload needs to be relative path in this case payload=target.lstrip("/"), ) </del> <ins> composefs_path = ComposefsPath( attrs, size=os.stat(source).st_size, filetype=FileType.file, mode=mode, # payload needs to be relative path in this case payload=target.lstrip("/"), ) </ins> paths[target] = composefs_path add_leading_directories(target, attrs, paths)

Discussion:
If I try to make my system perlless, my system rebuild fails. Steps to reproduce the behavior: the following module to your system configuration: The command succeeds. Commands: succeeds. I use flakes. <!-- 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]:
Odd, thought was meant to fix this. Perhaps more digging is needed.
What is the revision of nixpkgs that you are trying to build your system with? is merged without a 24.05 backport.
Per nix-info they're on 24.05 not unstable, so that makes sense. Is it backportable?
The PR itself is backportable, but I'm not sure if it complies with nixpkgs' .
Right, that's what I meant to ask - is it a breaking change? (i.e. is it possible for someone to rely on the old behaviour?) or simply a bugfix with low chance of regressions?
Is it not a breaking change because the option is marked as experimental (and also because the behavior before the PR was erroneous in the first place).
Fixed in .
Change:
nativeBuildInputs = [ hatchling <ins> makeWrapper </ins> ]; propagatedBuildInputs = [ more-itertools click ]; postFixup = '' <del> wrapProgram $out/bin/hyprshade --set HYPRSHADE_SHADERS_DIR $out/share/hyprshade/shaders </del> <ins> wrapProgram $out/bin/hyprshade  --set HYPRSHADE_SHADERS_DIR $out/share/hyprshade/shaders  --prefix PATH : ${lib.makeBinPath [ hyprland ]} </ins> ''; meta = with lib; {

Discussion:
Hyprshade works as expected, but the systemd service provided by fails to run due to an inability to find . hyprland and hyprshade shader (eg. blue light filtering) to run at certain times. to generate a user service to automatically run in the background with hyprshade.service and to enable the generated user service. for failure at the time designated in your hyprshade configuration. Hyprshade should have access to and call appropriately. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: