jiebi/CodeConvo huggingface dataset:
Code change:
stdenv.mkDerivation rec { pname = "snappy"; <del> version = "1.1.8"; </del> <ins> version = "1.1.9"; </ins> src = fetchFromGitHub { owner = "google"; repo = "snappy"; rev = version; <del> sha256 = "1j0kslq2dvxgkcxl1gakhvsa731yrcvcaipcp5k8k7ayicvkv9jv"; </del> <ins> sha256 = "sha256-JXWl63KVP+CDNWIXYtz+EKqWLJbPKl3ifhr8dKAp/w8="; </ins> }; <del> patches = [ ./disable-benchmark.patch ]; </del> outputs = [ "out" "dev" ]; nativeBuildInputs = [ cmake ];

Related discussion:
text: Describe the bug Because snappy does not install a pkgconfig file, you can't take snappy as a buildInput, packages will never find it. To Reproduce Expected behavior Metadata system: host os: multi-user?: sandbox: version: channels(seb): nixpkgs: Maintainer information: cc
I have opened a PR on the snappy codebase: It is waiting for review and then nixpkgs will need to be updated. Note how the PR has to handle the absolute path being configured in cmake by nix
has decided not to take the patch upstream, so I will work on adding the pkg-config file as part of the nix installation
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 .
Code change:
pinentry-bemenu = callPackage ../tools/security/pinentry-bemenu { }; <ins> pinentry-rofi = callPackage ../tools/security/pinentry-rofi { }; </ins> pingtcp = callPackage ../tools/networking/pingtcp { }; pinnwand = callPackage ../servers/pinnwand { };

Related discussion:
text: Project description It's a pinentry app, using rofi. I , but failed with (pls ignore metadata on that derivation, was testing): Metadata homepage URL: source URL: license: gpl-3+ platforms: linux
I just gave it try and quickly hacked together the following (based on ): Please feel free to use this as a base for a pr.
Code change:
pytest-httpx pytest-mock pytest-rerunfailures <del> pytest-xdist </del> pytestCheckHook ];

Related discussion:
text: Package name: paperless-ngx Latest released version: 2.12.1 <!-- Search your package here: --- Current version on the unstable channel: 2.11.6 <!-- 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. --
Code change:
"treat_warnings_as_errors=false" "v8_enable_i18n_support=true" "use_gold=false" <del> "use_system_xcode=true" </del> <ins> "init_stack_vars=false" </ins> # ''custom_toolchain="//build/toolchain/linux/unbundle:default"'' ''host_toolchain="//build/toolchain/linux/unbundle:default"'' ''v8_snapshot_toolchain="//build/toolchain/linux/unbundle:default"'' ] ++ lib.optional stdenv.cc.isClang ''clang_base_path="${stdenv.cc}"''; NIX_CFLAGS_COMPILE = "-O2"; <del> nativeBuildInputs = [ gn ninja pkg-config python ] ++ lib.optionals stdenv.isDarwin [ xcbuild darwin.DarwinTools ]; </del> <ins> FORCE_MAC_SDK_MIN = stdenv.targetPlatform.sdkVer or "10.12"; nativeBuildInputs = [ gn ninja pkg-config python ] ++ lib.optionals stdenv.isDarwin [ xcbuild darwin.DarwinTools pythonPackages.setuptools ]; </ins> buildInputs = [ glib icu ]; ninjaFlags = [ ":d8" "v8_monolith" ];

Related discussion:
text: Describe the bug Since upgrading v8 to 8.4 () it no longer builds on darwin (at least on my 11.2.3 machine) To Reproduce Steps to reproduce the behavior: Expected behavior A successful v8 build Additional context By default it fails when trying to find the macos sdk, which I patched around with: This then gets as far as , which is avoidable with: which then produces ... and I had to admit defeat. Notify maintainers Metadata Maintainer information:
Hi! Thanks for reporting this! I've opened which I hope fixes this - at least it builds fine for me on 10.15. Please give it a try on your machine too.
Yep, looks good!
Code change:
<del> { fetchurl, stdenv, lib, buildFHSUserEnv, appimageTools, writeShellScript, anki, undmg }: </del> <ins> { fetchurl, stdenv, lib, buildFHSUserEnv, appimageTools, writeShellScript, anki, undmg, zstd }: </ins> let pname = "anki-bin"; # Update hashes for both Linux and Darwin! <del> version = "2.1.49"; </del> <ins> version = "2.1.51"; </ins> sources = { linux = fetchurl { <del> url = "https://github.com/ankitects/anki/releases/download/${version}/anki-${version}-linux.tar.bz2"; sha256 = "sha256-uG39g9CXnquArFsxtFHWWoDaNwu8y2KKh+SqGt8aqi0="; </del> <ins> url = "https://github.com/ankitects/anki/releases/download/${version}/anki-${version}-linux-qt6.tar.zst"; sha256 = "sha256-ZKVc+TvkNu5mGgibhRIuoLuIfvyoVDy+c4h+Apz9P+0="; </ins> }; <del> darwin = fetchurl { url = "https://github.com/ankitects/anki/releases/download/${version}/anki-${version}-mac.dmg"; sha256 = "sha256-sEVWZQpICL7RYrOuPm1Y5XhzPxCwNk1WGP1rctTtE4Y="; </del> <ins> # For some reason anki distributes completely separate dmg-files for the aarch64 version and the x86_64 version darwin-x86_64 = fetchurl { url = "https://github.com/ankitects/anki/releases/download/${version}/anki-${version}-mac-intel-qt6.dmg"; sha256 = "sha256-wZMJEbcpezVAuBSKlwNTHlqjp0FfmyDB7XD6BBuJhyA="; }; darwin-aarch64 = fetchurl { url = "https://github.com/ankitects/anki/releases/download/${version}/anki-${version}-mac-apple-qt6.dmg"; sha256 = "sha256-6RDTYKoisX5DJ9VPWrP9VH9DCABabb9MB3nG4S8jtR0="; </ins> }; }; unpacked = stdenv.mkDerivation { inherit pname version; <ins> nativeBuildInputs = [ zstd ]; </ins> src = sources.linux; installPhase = ''

Related discussion:
text: After upgrading to the current version of nixpgs (nixos-unstable) anki starts up to a blank main window. According to the documentation () that is because of the system glibc having changed to a version not compatible with anki. Their suggested fix is that users move to using the beta package instead. Steps to reproduce the behavior: -shell -p Anki working as usual Add any other context about the problem here. Please run and paste the result. Excerpt from
Can confirm the behaviour.
Code change:
<del> { stdenv, fetchurl, makeWrapper, glibc, readline, ncurses, utillinux }: </del> <ins> { stdenv, lib, fetchurl, utillinux, makeWrapper , enableReadline ? true, readline, ncurses }: </ins> <del> with stdenv.lib; let makeFlags = '' INCDIR=${glibc.dev}/include  BINDIR=$out/bin LIBDIR=$out/lib CALC_INCDIR=$out/include/calc CALC_SHAREDIR=$out/share/calc MANDIR=$out/share/man/man1  USE_READLINE=-DUSE_READLINE READLINE_LIB=-lreadline READLINE_EXTRAS='-lhistory -lncurses'  TERMCONTROL=-DUSE_TERMIOS  ''; in </del> stdenv.mkDerivation rec { name = "calc-${version}"; version = "2.12.6.6"; src = fetchurl { <del> url = "https://github.com/lcn2/calc/releases/download/${version}/${name}.tar.bz2"; </del> <ins> urls = [ "https://github.com/lcn2/calc/releases/download/${version}/${name}.tar.bz2" "http://www.isthe.com/chongo/src/calc/${name}.tar.bz2" ]; </ins> sha256 = "03sg1xhin6qsrz82scf96mmzw8lz1yj68rhj4p4npp4s0fawc9d5"; }; <del> buildInputs = [ makeWrapper readline ncurses utillinux ]; configurePhase = '' sed -i 's/all: check_include/all:/' Makefile ''; buildPhase = '' make ${makeFlags} ''; installPhase = '' make install ${makeFlags} wrapProgram $out/bin/calc --prefix LD_LIBRARY_PATH : $out/lib </del> <ins> patchPhase = '' substituteInPlace Makefile  --replace 'all: check_include' 'all:'  --replace '-install_name ''${LIBDIR}/libcalc''${LIB_EXT_VERSION}' '-install_name ''${T}''${LIBDIR}/libcalc''${LIB_EXT_VERSION}'  --replace '-install_name ''${LIBDIR}/libcustcalc''${LIB_EXT_VERSION}' '-install_name ''${T}''${LIBDIR}/libcustcalc''${LIB_EXT_VERSION}' </ins> ''; <del> # Hack to avoid TMPDIR in RPATHs. preFixup = ''rm -rf "$(pwd)" ''; meta = { </del> <ins> buildInputs = [ utillinux makeWrapper ] ++ lib.optionals enableReadline [ readline ncurses ]; makeFlags = [ "T=$(out)" "INCDIR=${lib.getDev stdenv.cc.libc}/include" "BINDIR=/bin" "LIBDIR=/lib" "CALC_SHAREDIR=/share/calc" "CALC_INCDIR=/include" "MANDIR=/share/man/man1" # Handle LDFLAGS defaults in calc "DEFAULT_LIB_INSTALL_PATH=$(out)/lib" ] ++ lib.optionals enableReadline [ "READLINE_LIB=-lreadline" "USE_READLINE=-DUSE_READLINE" ]; meta = with lib; { </ins> description = "C-style arbitrary precision calculator"; homepage = http://www.isthe.com/chongo/tech/comp/calc/; license = licenses.lgpl21; <del> maintainers = [ ]; </del> <ins> maintainers = with maintainers; [ matthewbauer ]; </ins> platforms = platforms.all; }; }

Related discussion:
text: The package won't install on macOS. It triggers an assertion in : . macOS run system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Awesome, thanks!
Code change:
sundials = callPackage ../development/libraries/sundials { }; <ins> sundials_2 = callPackage ../development/libraries/sundials/2.x.nix { python = python3; }; </ins> sutils = callPackage ../tools/misc/sutils { }; svrcore = callPackage ../development/libraries/svrcore { };

Related discussion:
text: I'm trying to build octave with QT5 and with GUI (of course, when I try to build it with GUI, right?). Unfortunately, after the build: Apply this patch: and then system: host os: multi-user?: sandbox: version: channels(m): nixpkgs:
I just noticed that I do not even get the GUI feature when building octave from nixpkgs (neither nor has a GUI).
Pinging: touched the package recently, is the maintainer of the package.
I’ll try to have a look when I have some time. I’ll let you know what I can achieve.
Here is what the configure script says:
yes, I got that and I fixed it. See for my attempt to build with Qt5 (which succeeds, but starting octave with gui fails - see PR).
Code change:
proxy_pass_request_body           off; ''; }; "@redirectToAuth2ProxyLogin" = { return = "307 https://${cfg.domain}/oauth2/start?rd=$scheme://$host$request_uri"; extraConfig = ''

Related discussion:
text: OAuth2 Proxy's Nginx plugin used to forward and headers to downstream programs. This stopped working after I updated on unstable channel, which is potentially related to or . Steps to reproduce the behavior: up OAuth2 Proxy + Nginx up of header name . does not recognize the session More simply: up OAuth2 Proxy + Nginx or something similar the headers — and used to be present, but not anymore and are passed to downstream servers under Nginx. I have I went on upgrade of nixpkgs unstable from sometime late January to a few hours ago, which is what led me to the two PRs mentioned above. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
are you able to play around a bit and confirm if the changes mentioned introduced this regression?
yes. I can't really pin-point to what exactly since there were a lot of changes. Instead, I just have a local fork from (prior to the changes mentioned in the PRs above).
I have a pretty good idea what it could be.
Can you give a try? I didn't test it yet, so it could completely break everything and be completely insecure, just as warning.
fantastic work please let us know how it goes ‍
Sorry for the late reply, I haven't been able to have time to test it out. Now that I do, it seems like has been converted to . This won't be an easy find-and-replace for me to try in my setup, so I will have to find some time to do proper cleanup.
Code change:
<del> { lib, stdenv, fetchFromGitLab, rustPlatform, pkg-config, openssl </del> <ins> { lib, stdenv, fetchFromGitLab, fetchpatch, rustPlatform, pkg-config, openssl </ins> , installShellFiles , Security, AppKit

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:
tinyscheme = callPackage ../development/interpreters/tinyscheme { }; <ins> tbox = callPackage ../development/libraries/tbox { }; </ins> inherit (nodePackages) typescript; bupc = callPackage ../development/compilers/bupc { };

Related discussion:
text: Project description A lightweight cross-platform build utility based on Lua Metadata homepage URL: source URL: license: asl20 platforms: unix
Code change:
}; postPatch = '' <del> patchelf --set-rpath ${libXxf86vm}/lib lib/java3d-1.6/linux/amd64/libnativewindow_awt.so patchelf --set-rpath ${libXxf86vm}/lib lib/java3d-1.6/linux/amd64/libnativewindow_x11.so patchelf --set-rpath ${libXxf86vm}/lib lib/java3d-1.6/linux/i586/libnativewindow_awt.so patchelf --set-rpath ${libXxf86vm}/lib lib/java3d-1.6/linux/i586/libnativewindow_x11.so </del> <ins> addAutoPatchelfSearchPath ${jre8}/lib/openjdk/jre/lib/ autoPatchelf lib # Nix cannot see the runtime references to the paths we just patched in # once they've been compressed into the .jar. Scan for and remember them # as plain text so they don't get overlooked. find . -name '*.so' | xargs strings | { grep '/nix/store' || :; } >> ./.jar-paths </ins> ''; <del> nativeBuildInputs = [ makeWrapper unzip ]; buildInputs = [ ant jdk8 p7zip gtk3 gsettings-desktop-schemas ]; </del> <ins> nativeBuildInputs = [ makeWrapper unzip autoPatchelfHook ]; buildInputs = [ ant jdk8 p7zip gtk3 gsettings-desktop-schemas libXxf86vm ]; </ins> buildPhase = '' runHook preBuild

Related discussion:
text: Describe the bug I copied a closure from one system (19.03) to a USB thumb drive and from that to another system (19.09), but the program don't work. I think nix packages should be pure and work also on another system running a different NixOS channel. (Right?) To Reproduce Steps to reproduce the behavior: sweethome3d installed in thumb drive thumb drive (i use pantheons files app and open a terminal from there, then ) a folder on the thumb drive. mine is "nixpkgs" to that folder: the nix store path of the program: the usb drive into another system and mount it, get the path the nix store path to your system: you can install it for the current user if you like: or just open a nix shell: run the program: Expected behavior Program just work. Additional context I moved to a new flat with most of my computers and want to plan where to put my furniture. I installed sweethome3d on my notebook, but it is not powerfull enough. So i want to copy the program to my iMac. I have internet from my tethered mobile phone, so i can't just install it from the internet! sweethome3d is about 500 MB, that would be 1/4 of my data plan!!! Metadata X230: system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs: imac: system: host os: hangs after that Maintainer information:
Looks like this problem again: cc
When i run the package from unstable on stable, i get the same error: (but it will hopefully work on the imac when i copy it there again)
I get the same error when i run the package from unstable on my 19.09 branch. So it might be generally broken on unstable.
Yes, looks like be some kind of impurity. It runs on my NixOS 19.03 system, both from the stable and unstable channels. And I did the "nix run" thing you said and it works there too (I'm not sure how much isolation gives, apparently not enough).
Code change:
}; postPatch = '' <del> patchelf --set-rpath ${libXxf86vm}/lib lib/java3d-1.6/linux/amd64/libnativewindow_awt.so patchelf --set-rpath ${libXxf86vm}/lib lib/java3d-1.6/linux/amd64/libnativewindow_x11.so patchelf --set-rpath ${libXxf86vm}/lib lib/java3d-1.6/linux/i586/libnativewindow_awt.so patchelf --set-rpath ${libXxf86vm}/lib lib/java3d-1.6/linux/i586/libnativewindow_x11.so </del> <ins> addAutoPatchelfSearchPath ${jre8}/lib/openjdk/jre/lib/ autoPatchelf lib # Nix cannot see the runtime references to the paths we just patched in # once they've been compressed into the .jar. Scan for and remember them # as plain text so they don't get overlooked. find . -name '*.so' | xargs strings | { grep '/nix/store' || :; } >> ./.jar-paths </ins> ''; <del> nativeBuildInputs = [ makeWrapper unzip ]; buildInputs = [ ant jdk8 p7zip gtk3 gsettings-desktop-schemas ]; </del> <ins> nativeBuildInputs = [ makeWrapper unzip autoPatchelfHook ]; buildInputs = [ ant jdk8 p7zip gtk3 gsettings-desktop-schemas libXxf86vm ]; </ins> buildPhase = '' runHook preBuild

Related discussion:
text: It looks like the program copies some so files to on start-up: Two of the programs match to libraries in the but I could not match the other two; also I do not have the same filenames as you. Not sure what libraries’ RPATH should be patched but perhaps adding the following to wrapper would work as well:
For the reference, the libraries loaded are listed here:
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 . on the on .
Code change:
for line in f: result = line result = re.sub( <del> fr'^    version = ".+"; #{variant}', f'    version = "{version}"; #{variant}', </del> <ins> fr'^      version = ".+"; #{variant}', f'      version = "{version}"; #{variant}', </ins> result) result = re.sub( <del> fr'^    suffix = ".+"; #{variant}', f'    suffix = "{suffix}"; #{variant}', </del> <ins> fr'^      suffix = ".+"; #{variant}', f'      suffix = "{suffix}"; #{variant}', </ins> result) result = re.sub( <del> fr'^    sha256 = ".+"; #{variant}', f'    sha256 = "{sha256}"; #{variant}', </del> <ins> fr'^      sha256 = ".+"; #{variant}', f'      sha256 = "{sha256}"; #{variant}', </ins> result) print(result, end='')

Related discussion:
text: Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
libsecret ]; <del> preBuild = '' </del> <ins> # FIXME add back once upstream moves to Electron >= 26 # we use electron_26 because electron_25 is EOL /*preBuild = '' </ins> if [[ $(jq --raw-output '.devDependencies.electron' < package.json | grep -E --only-matching '^[0-9]+') != ${lib.escapeShellArg (lib.versions.major electron.version)} ]]; then echo 'ERROR: electron version mismatch' exit 1 fi <del> ''; </del> <ins> '';*/ </ins> postBuild = '' pushd apps/desktop

Related discussion:
text: Steps to reproduce the behavior: bitwarden Please run and paste the result.
Will be fixed by
Code change:
<ins> diff --git a/networkd-dispatcher b/networkd-dispatcher index ef877ce..8c341f2 100755 --- a/networkd-dispatcher +++ b/networkd-dispatcher @@ -171,6 +171,8 @@ def check_perms(path, mode=0o755, uid=0, gid=0): if not os.path.exists(path): raise FileNotFoundError +    if re.search('^/nix/store/.*', str(path)): +        return True st = os.stat(path, follow_symlinks=False) st_mode = st.st_mode & 0x00FFF if st.st_uid == uid and st.st_gid == gid and st_mode == mode: </ins>

Related discussion:
text: refuses to work since it requires the directories containing the scripts to have mode 755, but the nixos module creates them with mode 750. Steps to reproduce the behavior: (re)-configure an interface (for example by unplugging and replugging a network cable) something like in the journal and that does not exist, i.e. the hook was never run. networkd-dispatcher works. <!-- 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.
Thank you for the report! I'm thinking about adding a rules option to the networkd-dispatcher module so this might solve your issue
Code change:
let <del> requiredPackages = map lib.lowPrio </del> <ins> requiredPackages = map (pkg: setPrio ((pkg.meta.priority or 5) + 3) pkg) </ins> [ config.nix.package pkgs.acl pkgs.attr

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.