jiebi/CodeConvo huggingface dataset:
Code change:
exit 1 fi <del> nm -an "$libblas" | cut -f3 -d' ' > symbols </del> <ins> $NM -an "$libblas" | cut -f3 -d' ' > symbols </ins> for symbol in ${toString blasFortranSymbols}; do grep "^$symbol_$" symbols || { echo "$symbol" was not found in "$libblas"; exit 1; } done

Related discussion:
text: Describe the bug I'd like to build the python numpy package on an x86 machine for the armv7 architecture. numpy requires liblapack and blas, which require gfortran I already fixed one issue which is that liblapack couldn't find the gfortran compiler (see the overlay below) I'm trying to use the 20.03 release, latest commit. Here's what I'm running exactly: To Reproduce Steps to reproduce the behavior: -build here's the error I get Expected behavior The derivation builds Metadata Please run and paste the result. Maintainer information:
Maybe related to: ?
I'm not getting this in NixOS. It looks like a sandboxing issue. Can you try running this:
Thanks for responding! I launched this build on NixOs using an AMI on EC2 and I get the same result as in the issue report, here are the system details:
A similar issue exists on unstable when building for x86. Currently on: system: host os: multi-user?: sandbox: version: channels(root): channels(swflint): nixpkgs:
Code change:
in python.pkgs.buildPythonApplication rec { pname = "paperless-ngx"; <del> format = "other"; </del> <ins> pyproject = false; </ins> inherit version src; <ins> postPatch = '' # pytest-xdist makes the tests flaky substituteInPlace src/setup.cfg  --replace-fail "--numprocesses auto --maxprocesses=16" "" ''; </ins> nativeBuildInputs = [ gettext xorg.lndir ]; <del> propagatedBuildInputs = with python.pkgs; [ </del> <ins> dependencies = with python.pkgs; [ </ins> bleach channels channels-redis

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:
{ lib <ins> , stdenv </ins> , mkDerivation , fetchurl , fetchFromGitHub

Related discussion:
text: Describe the bug When adding to the NixOS configuration the udev rules do not get installed. To Reproduce Steps to reproduce the behavior: mixxx with a DJ controller plugged in. controller is not recognized by mixxx Expected behavior The udev rules are in the correct folder i.e. or and therefore the udev service does not recognizes them. Additional context The fix in worked for me after a little modification (the rules file got renamed). Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Originally, mixxx did the right thing = install udev files to - see Later they changed the behaviour and they install to - see Sigh.
Code change:
cython grpcio-tools mypy-protobuf <ins> pythonRelaxDepsHook </ins> ]; propagatedBuildInputs = [

Related discussion:
text: Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags:
Code change:
config = mkIf cfg.enable { services.xserver.displayManager.lightdm.enable = <del> let dmconf = cfg.displayManager; default = !(dmconf.gdm.enable || dmconf.sddm.enable || dmconf.xpra.enable ); in mkIf (default) true; </del> <ins> let dmConf = cfg.displayManager; default = !(dmConf.gdm.enable || dmConf.sddm.enable || dmConf.xpra.enable || dmConf.sx.enable || dmConf.startx.enable); in mkIf (default) (mkDefault true); # so that the service won't be enabled when only startx is used systemd.services.display-manager.enable  = let dmConf = cfg.displayManager; noDmUsed = !(dmConf.gdm.enable || dmConf.sddm.enable || dmConf.xpra.enable || dmConf.lightdm.enable); in mkIf (noDmUsed) (mkDefault false); </ins> hardware.opengl.enable = mkDefault true;

Related discussion:
text: I believe that this prevents the use of other display managers -Don't force it?
if you enable a another dm you wouldn't get this error i submitted a pr so that this error does not happen when lightdm is disabled but a another dm isn't enabled
Code change:
buildInputs = [ glib <ins> glib-networking # see #311066 </ins> gtk3 json-glib libappindicator

Related discussion:
text: Gives this error: , yet installing doesn't fix the problem. Steps to reproduce the behavior: Meteo That the Maps section works. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have this exact issue. Hoping for some clarity.
should be here:
Code change:
{ <ins> # Note: do not use Hydra as a source URL. Ask a member of the # infrastructure team to mirror the job. </ins> busybox = import <nix/fetchurl.nix> { <del> url = https://hydra.nixos.org/build/112609103/download/2/busybox; sha256 = "566a469dac214b31e4abdb0a91d32550bab1be5858d329e1b6074eef05370ca3"; </del> <ins> # from job: https://hydra.nixos.org/job/nixpkgs/cross-trunk/bootstrapTools.armv7l.dist/latest # from build: https://hydra.nixos.org/build/114203060 url = "http://tarballs.nixos.org/stdenv-linux/armv7l/0eb0ddc4dbe3cd5415c6b6e657538eb809fc3778/busybox"; # note: the following hash is different than the above hash, due to executable = true sha256 = "18qc6w2yykh7nvhjklsqb2zb3fjh4p9r22nvmgj32jr1mjflcsjn"; </ins> executable = true; }; bootstrapTools = import <nix/fetchurl.nix> { <del> url = https://hydra.nixos.org/build/112609103/download/1/bootstrap-tools.tar.xz; sha256 = "79fa2d7722aeb856c7c9b62a3fd64b6d261fd6f6bcbac486f0a2a7d823210550"; </del> <ins> # from job: https://hydra.nixos.org/job/nixpkgs/cross-trunk/bootstrapTools.armv7l.dist/latest # from build: https://hydra.nixos.org/build/114203060 url = "http://tarballs.nixos.org/stdenv-linux/armv7l/0eb0ddc4dbe3cd5415c6b6e657538eb809fc3778/bootstrap-tools.tar.xz"; sha256 = "cf2968e8085cd3e6b3e9359624060ad24d253800ede48c5338179f6e0082c443"; </ins> }; }

Related discussion:
text: Describe the bug doesn't work, either on or . It works on and I have a bisect running at the moment (on some slow hardware, so the results might take some time). It fails with this log: To Reproduce Metadata Maintainer information:
The first bad commit could be any of: jfsutils: fix build with glibc=2.28 ppp: fix build with glibc=2.28 oathToolkit: fix build with glibc=2.28 postfix: fix build w/glibc 2.30 libffi: only run tests on musl targets stdenv: rebuild aarch64 bootstrap files with gcc8 expect: remove hack for aarch64 build expect: fix aarch64 build seasocks: fix build w/glibc-2.30 bzip2: fix aarch64 build xnbd: fix build w/glibc-2.30 glibc: remove outdated patches rr: 5.2.0 -5.3.0, fix build w/glibc-2.30 diod: fix build w/glibc-2.30 libunistring: disable tests distrho: fix build w/glibc-2.30 glibc: depend on libidn2 (and libunistring, transitively) stdenv bootstrap: disable dejagnu tests gcal: fix build w/glibc-2.30 sharutils: fix build with glibc=2.28 drbd: fix build w/glibc-2.30 gnum4: fix build with glibc=2.28 xen48: fix build w/glibc-2.30 gnulib: - mono: fix build w/glibc-2.30 glibc: 2.27 -2.30 foundationdb61: fix build w/glibc-2.30 spaceFM: fix build w/glibc-2.30 cpython: fetch darwin- to nixpkgs xen48-{light,
Code change:
{ <ins> # Note: do not use Hydra as a source URL. Ask a member of the # infrastructure team to mirror the job. </ins> busybox = import <nix/fetchurl.nix> { <del> url = https://hydra.nixos.org/build/112609103/download/2/busybox; sha256 = "566a469dac214b31e4abdb0a91d32550bab1be5858d329e1b6074eef05370ca3"; </del> <ins> # from job: https://hydra.nixos.org/job/nixpkgs/cross-trunk/bootstrapTools.armv7l.dist/latest # from build: https://hydra.nixos.org/build/114203060 url = "http://tarballs.nixos.org/stdenv-linux/armv7l/0eb0ddc4dbe3cd5415c6b6e657538eb809fc3778/busybox"; # note: the following hash is different than the above hash, due to executable = true sha256 = "18qc6w2yykh7nvhjklsqb2zb3fjh4p9r22nvmgj32jr1mjflcsjn"; </ins> executable = true; }; bootstrapTools = import <nix/fetchurl.nix> { <del> url = https://hydra.nixos.org/build/112609103/download/1/bootstrap-tools.tar.xz; sha256 = "79fa2d7722aeb856c7c9b62a3fd64b6d261fd6f6bcbac486f0a2a7d823210550"; </del> <ins> # from job: https://hydra.nixos.org/job/nixpkgs/cross-trunk/bootstrapTools.armv7l.dist/latest # from build: https://hydra.nixos.org/build/114203060 url = "http://tarballs.nixos.org/stdenv-linux/armv7l/0eb0ddc4dbe3cd5415c6b6e657538eb809fc3778/bootstrap-tools.tar.xz"; sha256 = "cf2968e8085cd3e6b3e9359624060ad24d253800ede48c5338179f6e0082c443"; </ins> }; }

Related discussion:
text: slim}: fix build bootstrap-files: bump WIP Merge branch 'staging' into glibc230 Ignoring 'fix build with glibc' commits libffi: only run tests on musl targets stdenv: rebuild aarch64 bootstrap files with gcc8 expect: remove hack for aarch64 build expect: fix aarch64 build bzip2: fix aarch64 build glibc: remove outdated patches libunistring: disable tests glibc: depend on libidn2 (and libunistring, transitively) stdenv bootstrap: disable dejagnu tests gnulib: - glibc: 2.27 -2.30 cpython: fetch darwin- to nixpkgs xen48-{light,slim}: fix build bootstrap-files: bump WIP Merge branch 'staging' into glibc230
stdenv bootstrapping of 32-bit ARMs is (hopefully) being fixed right now:
Thanks for the hard work
Code change:
, meson , ninja , systemd <del> , enableSystemd ? true </del> , pkg-config , docutils , doxygen

Related discussion:
text: Steps to reproduce the behavior: for the pipewire package, e.g.: building it This can be fixed by either making sure that flag controls the Meson option in addtion to the , or by exposing a new option to control the directly. ping let me know which of the options above you guys prefer and I can open up a PR to fix as well. <!-- 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]:
Can we just remove that option instead?
Sorry do you mean set the to always be false or completely remove the as an option? Because I prefer the abilitiy to turn as many unnecessary dependencies as practically possible on my system (better stability and security).
Remove the option, yes, because we can't realistically maintain the exponential explosion of possible flag combinations.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I made two PRs: and Feel free to pick whichever PR looks better to you
arg removed in
How much maintenance burden does this actually cause? IMO the package options are one of Nixpkgs strengths (one of the things that attracted me, after I stopped working on Homebrew because package options started to be removed entirely), and they're critical for people working on systems where size matters.
To expand a bit, I don't think that package maintainers should generally be expected to support all combinations of options, but I also don't think they should block people who want to from doing so. Just having the flags there shouldn't cause any problems for package maintainers that don't want to maintain the flags, and it's fine IMO to respond to issues about flags not working by asking people to adopt the flag and send a patch.
No one's blocking people from overriding. It's just a bad idea to have some flags we haven't even looked at in months and pretend we support them by including them in the expression. Or in other words, keeping the flags is shipping broken code if people don't maintain them.
The enableSystemd flag had clearly been looked at recently, because there was a commit from me fixing it, and yet it was removed anyway.
Code change:
}; logLevel = mkOption { <del> type = types.enum ([ "error" "warn" "info" "debug" "trace" ]); </del> <ins> type = types.enum ([ "error" "warn" "info" "debug" "trace" ]); </ins> default = "info"; example = "debug"; description = "Garage log level, see <https://garagehq.deuxfleurs.fr/documentation/quick-start/#launching-the-garage-server> for examples.";

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:
runHook preInstall <del> ${if stdenv.isDarwin then '' mkdir -p $out/Applications </del> <ins> ${ if stdenv.isDarwin then '' mkdir -p $out/Applications </ins> <del> cp -R packages/bruno-electron/out/**/Bruno.app $out/Applications/ '' else '' mkdir -p $out/opt/bruno $out/bin </del> <ins> cp -R packages/bruno-electron/out/**/Bruno.app $out/Applications/ '' else '' mkdir -p $out/opt/bruno $out/bin </ins> <del> cp -r packages/bruno-electron/dist/linux*-unpacked/{locales,resources{,.pak}} $out/opt/bruno </del> <ins> cp -r packages/bruno-electron/dist/linux*-unpacked/{locales,resources{,.pak}} $out/opt/bruno </ins> <del> makeWrapper ${lib.getExe electron} $out/bin/bruno  --add-flags $out/opt/bruno/resources/app.asar  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}"  --set-default ELECTRON_IS_DEV 0  --inherit-argv0 </del> <ins> makeWrapper ${lib.getExe electron} $out/bin/bruno  --add-flags $out/opt/bruno/resources/app.asar  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}"  --set-default ELECTRON_IS_DEV 0  --inherit-argv0 </ins> <del> for s in 16 32 48 64 128 256 512 1024; do size=${"$"}{s}x$s install -Dm644 $src/packages/bruno-electron/resources/icons/png/$size.png $out/share/icons/hicolor/$size/apps/bruno.png done ''} </del> <ins> for s in 16 32 48 64 128 256 512 1024; do size=${"$"}{s}x$s install -Dm644 $src/packages/bruno-electron/resources/icons/png/$size.png $out/share/icons/hicolor/$size/apps/bruno.png done '' } </ins> runHook postInstall '';

Related discussion:
text: Attempt to build on Sample This is on an M2 chip, and it seems the issue is with node-canvas not being able to install due to missing giflib. Building with: Fixes this. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
hash = "sha256-cjmXKUGcrZ8RLDBmoS0AANpFCkVq3XsJTYkVUGnWgh4="; }; <del> nativeBuildInputs = [ pkg-config python3 glib ]; </del> <ins> nativeBuildInputs = [ copyDesktopItems pkg-config python3 glib ]; </ins> buildInputs = [ gtk2 readline ];

Related discussion:
text: Package name: gnubg Latest released version: 1.07.001 <!-- Search your package here: --- Current version on the unstable channel: 1.06.002 Current version on the stable/release channel: 1.06.002 <!-- 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.
I packaged this in 2015 and I have no idea why.
Code change:
Legacy options have been mapped to the corresponding options under under <link xlink:href="options.html#opt-nix.settings">nix.settings</link> <del> but may be deprecated in the future. </del> <ins> and will be deprecated when NixOS 21.11 reaches end of life. </ins> </para> </listitem> <listitem>

Related discussion:
text: The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors
Code change:
in stdenv.mkDerivation rec { <del> name = "mwprocapture-1.2.${version}-${kernel.version}"; version = "4177"; </del> <ins> name = "mwprocapture-1.3.0.${version}-${kernel.version}"; version = "4236"; </ins> src = fetchurl { <del> url = "http://www.magewell.com/files/drivers/ProCaptureForLinux_${version}.tar.gz"; sha256 = "1nf51w9yixpvr767k49sfdb9n9rv5qc72f5yki1mkghbmabw7vys"; </del> <ins> url = "https://www.magewell.com/files/drivers/ProCaptureForLinux_${version}.tar.gz"; sha256 = "1mfgj84km276sq5i8dny1vqp2ycqpvgplrmpbqwnk230d0w3qs74"; </ins> }; <del> nativeBuildInputs = [ kernel.moduleBuildDependencies ]; </del> <ins> nativeBuildInputs = kernel.moduleBuildDependencies; </ins> preConfigure = ''

Related discussion:
text: I'm trying to use the mwprocapture nixos module (which uses the mwprocapture kernel package) on 20.09 (linuxPackageslatest), and I get the following: Is this known and/or already fixed somewhere? (Also, is it safe to use it anyways?) I'd love to try and fix it further myself, but I don't know how to splice in a local/development nix file into my for development purposes :sweatsmile: (also CC
Looks like upgrading the package version resolved things. Will create a PR soon.
Thanks for the heads up.
Code change:
postInstall = '' for f in lesspipe.sh lesscomplete; do <del> wrapProgram "$out/bin/$f" --prefix-each PATH : "${lib.makeBinPath [ file gnused procps ]}" </del> <ins> wrapProgram "$out/bin/$f" --prefix-each PATH : "${lib.makeBinPath [ binutils file gnused procps ]}" </ins> done '';

Related discussion:
text: According to documentation of the app: there's a dozen dependencies we don't explicitly have a dependency on, so there's multitude of bugs that might appear depending on what's on $PATH.
Do we need a new maintainer of to move this issue forward?
We should pull the package from NixOS core...absolutely no reason to have such a bloated less ship by default.
Code change:
<del> { lib, stdenv, fetchFromGitHub, cmake, libminc }: stdenv.mkDerivation rec { pname = "EBTKS"; version  = "unstable-2017-09-23"; src = fetchFromGitHub { owner  = "BIC-MNI"; repo   = pname; rev    = "67e4e197d8a32d6462c9bdc7af44d64ebde4fb5c"; sha256 = "1a1qw6i47fs1izx60l1ysabpmyx9j5sjnbdv8b47wi2xcc9i3hpq"; }; # error: use of undeclared identifier 'finite'; did you mean 'isfinite'? postPatch = '' substituteInPlace templates/EBTKS/SimpleArray.h  --replace "#define FINITE(x) finite(x)" "#define FINITE(x) isfinite(x)" ''; nativeBuildInputs = [ cmake ]; buildInputs = [ libminc ]; cmakeFlags = [ "-DLIBMINC_DIR=${libminc}/lib/cmake" ]; meta = with lib; { homepage = "https://github.com/BIC-MNI/${pname}"; description = "Library for working with MINC files"; maintainers = with maintainers; [ bcdarwin ]; platforms = platforms.unix; license   = licenses.free; }; } </del>

Related discussion:
text: For x8664-darwin, aarch64-darwin: build .#EBTKS x8664-darwin: aarch64-darwin:
Code change:
--replace-fail 'if [ "$1" == "snap" ]; then' 'exit 0; if [ "$1" == "snap" ]; then' ''; <del> ELECTRON_SKIP_BINARY_DOWNLOAD=1; </del> <ins> ELECTRON_SKIP_BINARY_DOWNLOAD = 1; # remove giflib dependency npmRebuildFlags = [ "--ignore-scripts" ]; preBuild = '' substituteInPlace node_modules/canvas/binding.gyp  --replace-fail "'with_gif%': '<!(node ./util/has_lib.js gif)'" "'with_gif%': 'false'" npm rebuild ''; </ins> dontNpmBuild = true; postBuild = ''

Related discussion:
text: Attempt to build on Sample This is on an M2 chip, and it seems the issue is with node-canvas not being able to install due to missing giflib. Building with: Fixes this. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
wrap ${prefix}ld.bfd ${preWrap ./ld-wrapper.sh} ${binutils_bin}/bin/${prefix}ld.bfd fi <del> export real_cc=${prefix}cc export real_cxx=${prefix}c++ </del> <ins> # We export environment variables pointing to the wrapped nonstandard # cmds, lest some lousy configure script use those to guess compiler # version. export named_cc=${prefix}cc export named_cxx=${prefix}c++ </ins> export default_cxx_stdlib_compile="${default_cxx_stdlib_compile}" if [ -e $ccPath/${prefix}gcc ]; then wrap ${prefix}gcc ${preWrap ./cc-wrapper.sh} $ccPath/${prefix}gcc ln -s ${prefix}gcc $out/bin/${prefix}cc <del> export real_cc=${prefix}gcc export real_cxx=${prefix}g++ </del> <ins> export named_cc=${prefix}gcc export named_cxx=${prefix}g++ </ins> elif [ -e $ccPath/clang ]; then wrap ${prefix}clang ${preWrap ./cc-wrapper.sh} $ccPath/clang ln -s ${prefix}clang $out/bin/${prefix}cc <del> export real_cc=clang export real_cxx=clang++ </del> <ins> export named_cc=${prefix}clang export named_cxx=${prefix}clang++ </ins> fi if [ -e $ccPath/${prefix}g++ ]; then

Related discussion:
text: Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.