jiebi/CodeConvo huggingface dataset:
Change:
postPatch = '' substituteInPlace setup.py --subst-var out <ins> patchShebangs bin/ulauncher-toggle substituteInPlace bin/ulauncher-toggle  --replace wmctrl ${wmctrl}/bin/wmctrl </ins> ''; # https://github.com/Ulauncher/Ulauncher/issues/390

Discussion:
the ulauncher-toggle script fails with The script just seems to be missing the fix shebang step. ulauncher is installed globally. Steps to reproduce the behavior: ulauncher-toggle The script should run. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
Change:
"eliqonline" = ps: with ps; [ ]; # missing inputs: eliqonline "elkm1" = ps: with ps; [ ]; # missing inputs: elkm1-lib "elv" = ps: with ps; [ ]; # missing inputs: pypca <del> "emby" = ps: with ps; [ ]; # missing inputs: pyemby </del> <ins> "emby" = ps: with ps; [ pyemby ]; </ins> "emoncms" = ps: with ps; [ ]; "emoncms_history" = ps: with ps; [ ]; "emulated_hue" = ps: with ps; [ aiohttp-cors ];

Discussion:
Describe the bug esniper is broken, because ebay changed the login. they are not sure if they can and want to fix it. maybe we have to deprecate the package like To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata Please run and paste the result. Maintainer information:
Change:
ln -s $out/bin/QMPlay2 $out/bin/qmplay2 ''; <del> meta = with lib; { </del> <ins> meta = { </ins> homepage = "https://github.com/zaps166/QMPlay2/"; description = "Qt-based Multimedia player"; longDescription = ''

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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.
Change:
<del> { lib, stdenv, fetchurl, p7zip }: </del> <ins> { lib, stdenv, fetchurl, libarchive }: </ins> stdenv.mkDerivation rec { pname = "win-virtio"; <del> version = "0.1.196-1"; dontUnpack = true; </del> <ins> version = "0.1.229-1"; </ins> src = fetchurl { url = "https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-${version}/virtio-win.iso"; <del> sha256 = "1zj53xybygps66m3v5kzi61vqy987zp6bfgk0qin9pja68qq75vx"; </del> <ins> hash = "sha256-yIoN3jRgXq7mz4ifPioMKvPK65G130WhJcpPcBrLu+A="; </ins> }; <del> buildPhase = '' runHook preBuild ${p7zip}/bin/7z x $src runHook postBuild ''; </del> <ins> nativeBuildInputs = [ libarchive ]; unpackCmd = "mkdir source; bsdtar -xf $curSrc -C source"; </ins> <del> installPhase = let copy = arch: version: {input, output}: "mkdir -p $out/${arch}/${output}; cp ${input}/${version}/${arch}/* $out/${arch}/${output}/."; virtio = [{input="Balloon"; output="vioballoon";} {input="NetKVM"; output="vionet";} {input="vioscsi"; output="vioscsi";} {input="vioserial"; output="vioserial";} {input="viostor"; output="viostor";} {input="viorng"; output="viorng";} ]; in '' runHook preInstall ${lib.concatStringsSep "n" ((map (copy "amd64" "w10") virtio) ++ (map (copy "x86" "w10") virtio))} runHook postInstall ''; </del> <ins> installPhase = '' runHook preInstall mkdir -p $out cp -R ./. $out/ runHook postInstall ''; </ins> meta = with lib; { description = "Windows VirtIO Drivers"; <del> homepage = "https://fedoraproject.org/wiki/Windows_Virtio_Drivers"; </del> <ins> homepage = "https://docs.fedoraproject.org/en-US/quick-docs/creating-windows-virtual-machines-using-virtio-drivers/index.html"; </ins> license = [ licenses.bsd3 ]; maintainers = [ ]; platforms = platforms.linux;

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 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: win-virtio <!-- The current version can be found easily with the same process as 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.1.196-1 desired version: 0.1.221-1 <!-- 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:
gnome-connections = callPackage ../desktops/gnome/apps/gnome-connections { }; <ins> gnome-extensions-cli = python3Packages.callPackage ../desktops/gnome/misc/gnome-extensions-cli { }; </ins> gnome-text-editor = callPackage ../desktops/gnome/apps/gnome-text-editor { }; gnome-tour = callPackage ../desktops/gnome/core/gnome-tour { };

Discussion:
Project description Allows you to manage GNOME extensions from CLI Metadata homepage URL: source URL: license: apache 2 platforms: linux
Change:
firmware-manager = callPackage ../os-specific/linux/firmware/firmware-manager { }; <del> firmware-updater = callPackage ../os-specific/linux/firmware/firmware-updater { }; </del> <ins> firmware-updater = callPackage ../os-specific/linux/firmware/firmware-updater { flutter = flutterPackages.v3_22; }; </ins> fwts = callPackage ../os-specific/linux/fwts { };

Discussion:
Package name: flutter Latest released version: 3.24.1 <!-- Search your package here: --- Current version on the unstable channel: 3.22.2 Current version on the stable/release channel: 3.22.2 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
CC
Already being done

Package name: flutter (stable, but also beta) Latest released version: 3.24.0 <!-- Search your package here: --- Current version on the unstable channel: 3.22.2 (beta version: 3.23.0) Current version on the stable/release channel: 3.22.0 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
CC has been a blocker for updates since it affects the update script but it is close to being ready.
Hmm, hopefully this can be resolved soon, as it's quite critical for my work.
Yeah, I hope to have it done soon. It's close. Unfortunately, I just don't always have enough time.
Yeah, of course! Take your time :)
Hey, since the blocker is merged, how is it looking with updating the flutter version? :) No worries, if you're too busy right now
I plan on doing that on my next day off work which will be Thursday.
Change:
# fix reproducibile output, in particular in the grub2 build # https://savannah.gnu.org/bugs/index.php?59658 ./0001-msginit-Do-not-use-POT-Creation-Date.patch <del> ] ++ lib.optional stdenv.hostPlatform.isWindows (fetchpatch { url = "https://aur.archlinux.org/cgit/aur.git/plain/gettext_formatstring-ruby.patch?h=mingw-w64-gettext&id=e8b577ee3d399518d005e33613f23363a7df07ee"; name = "gettext_formatstring-ruby.patch"; sha256 = "sha256-6SxZObOMkQDxuKJuJY+mQ/VuJJxSeGbf97J8ZZddCV0="; }); </del> <ins> ]; </ins> outputs = [ "out" "man" "doc" "info" ];

Discussion:
mingw32 build support for gettext is broken. There are conditionals within the gettext derivation that leads me to believe that mingw32 builds should be working. Steps to reproduce the behavior: The package to be built with not error If applicable, add screenshots to help explain your problem. Here is the error that I get Looks like the changes for one of the patches was upstreamed. If I remove the patch (this is okay because it is now in the source code), I will get the following error. <!-- 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]:
Change:
<del> { lib, stdenv, fetchFromGitHub, fetchpatch, cmake, curl, openssl, s2n-tls, zlib </del> <ins> { lib , stdenv , fetchFromGitHub , cmake , curl , openssl , s2n-tls , zlib </ins> , aws-crt-cpp <del> , aws-c-cal, aws-c-common, aws-c-event-stream, aws-c-io, aws-checksums , CoreAudio, AudioToolbox </del> <ins> , aws-c-cal , aws-c-common , aws-c-event-stream , aws-c-io , aws-checksums , CoreAudio , AudioToolbox </ins> , # Allow building a limited set of APIs, e.g. ["s3" "ec2"]. apis ? ["*"] , # Whether to enable AWS' custom memory management.

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking maintainers cc: aws-sdk-cpp maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag: -
Managed to bisect this down to would you mind taking a look?
Sure thing
There are commits between the release on nixpkgs (1.9.150) and the latest release (1.9.238) that fixes gcc11 / c++17 issues. : Testing building latest release; if it isn't something that can be considered (incompatibilities?) then adding them as patches should work.
Change:
else throw "Unknown QEMU serial device for system '${pkgs.stdenv.hostPlatform.system}'"; qemuBinary = qemuPkg: { <del> x86_64-linux = "${qemuPkg}/bin/qemu-kvm -cpu max"; </del> <ins> x86_64-linux = "${qemuPkg}/bin/qemu-kvm -cpu qemu64"; </ins> armv7l-linux = "${qemuPkg}/bin/qemu-system-arm -enable-kvm -machine virt -cpu host"; aarch64-linux = "${qemuPkg}/bin/qemu-system-aarch64 -enable-kvm -machine virt,gic-version=host -cpu host"; powerpc64le-linux = "${qemuPkg}/bin/qemu-system-ppc64 -machine powernv";

Discussion:
Describe the bug On NixOS and some other Linux distributions like Fedora is world-read-writable: This is not the case on other systems like Ubuntu and others from the Debian family, which instruct their users to get access to by adding user accounts to the group: When building a derivation that uses , like for example NixOS Tests or on such systems with Multi-User Nix and KVM installed, the build fails with an error message similar to this when booting the VM: To fix this users might try to add the users to the group, which has no effect because of the build sandbox. The only effective fix seems to be changing the permissions for to be world-read-writable: This fix is difficult to find for users that are not already very familiar with KVM (like me). Proposed fix Nix should detect the situation where a build is run in the sandbox and the permissions for are going to lead to a failure and emit a warning or build error that points people towards a working fix they can manually run. Potentially it would even be possible/desirable for the build to proceed without KVM/hardware acceleration, but I'm not sure because of the terrible performance impact. To Reproduce Steps to reproduce the behavior: a system that supports hardware virtualization ubuntu or another affected distro KVM (see for example ) Multi-User Nix a derivation that uses You can also manually change the permissions to to reproduce the issue. Expected behavior A more user-friendly failure mode, like what I wrote under proposed fix. Additional context There are also documented examples of other users running into this: and maybe also There is some relevant discussion here about the security impact of that permission change: Notify maintainers There are a lot of other people in git blame. I you two for now. Hope that's OK. Maintainer information:
VMs already proceed without hardware acceleration if KVM is not installed at all. I tested this with NixOS Tests on with NixOS. At least for that case the relevant code I found is this: I will submit a PR which fixes this check so that VMs also proceed without KVM in the scenario described above.

I am not 100 % sure if that is the best fix and if it should close this issue, because firstly I think it would be good to make users aware when KVM is not enabled, when the hardware/software support would allow it: because it's not installed or because the permissions are broken. What would be a good way to emit such warnings? Secondly I am also a bit confused about there being flags for hardware acceleration here as well: This makes it seem like is treated inconsistently with other architectures and I don't understand why.
Change:
<ins> diff --git i/prnt/hpcups/HPCupsFilter.cpp w/prnt/hpcups/HPCupsFilter.cpp index 5b282d8..153ee3a 100644 --- i/prnt/hpcups/HPCupsFilter.cpp +++ w/prnt/hpcups/HPCupsFilter.cpp @@ -31,7 +31,6 @@ *****************************************************************************/ #include "HPCupsFilter.h" -#include "ImageProcessor.h" #include <signal.h> #include <sys/wait.h> @@ -637,16 +636,10 @@ int HPCupsFilter::processRasterData(cups_raster_t *cups_raster) sprintf(hpPreProcessedRasterFile, "%s/hp_%s_cups_SwapedPagesXXXXXX",CUPS_TMP_DIR, m_JA.user_name); -    image_processor_t* imageProcessor = imageProcessorCreate(); while (cupsRasterReadHeader2(cups_raster, &cups_header)) { -        IMAGE_PROCESSOR_ERROR result = imageProcessorStartPage(imageProcessor, &cups_header); -        if (result != IPE_SUCCESS){ -            dbglog("DEBUG: imageProcessorStartPage failed result = %dn", result); -        } - current_page_number++; if (current_page_number == 1) { @@ -745,11 +738,6 @@ int HPCupsFilter::processRasterData(cups_raster_t *cups_raster) color_raster = rgbRaster; black_raster = kRaster; -            result = imageProcessorProcessLine(imageProcessor, m_pPrinterBuffer, cups_header.cupsBytesPerLine); -            if (result != IPE_SUCCESS){ -                dbglog("DEBUG: imageProcessorProcessLine failed result = %dn", result); -            } - if ((y == 0) && !is_ljmono) { //For ljmono, make sure that first line is not a blankRaster line.Otherwise printer @@ -780,11 +768,6 @@ int HPCupsFilter::processRasterData(cups_raster_t *cups_raster) } }  // for() loop end -        result = imageProcessorEndPage(imageProcessor); -        if (result != IPE_SUCCESS){ -                dbglog("DEBUG: imageProcessorEndPage failed result = %dn", result); -        } - m_Job.NewPage(); if (err != NO_ERROR) { @@ -800,8 +783,6 @@ int HPCupsFilter::processRasterData(cups_raster_t *cups_raster) rgbRaster = NULL; } -    imageProcessorDestroy(imageProcessor); - unlink(hpPreProcessedRasterFile); return ret_status; } </ins>

Discussion:
Printing with a HP Color LaserJet printer fails due to a crash in the filter when using the driver "hpcups 3.19.1" With the "CUPS+Gutenprint v5.2.14" driver printing works. Try to print anything, a test page would do Please run and paste the results. oops.. let's try again:
I'm having the same problem, and made some observations: hplip 3.18.5 (used in release-18.09) works, even if compiled with pkgs from release-19.03 Here's a bug report with a proposed patch: is probably here: I didn't come around to test any of those patches thoug as I have only very limited access to my HP printer.
Change:
passthru = { inherit version; <ins> inherit python; # to be able to test our overridden packages above individually with `nix-build -A` </ins> tests = { inherit (nixosTests) ceph-multi-node

Discussion:
Steps to reproduce the behavior: ceph via Happening on current (currently at ), as well as on and . Do note that while this looks like a build failure for , is the one overriding the package version to something incompatible. The unaltered package builds fine. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
See also , which I think should fix this.
Trying to build samba4Full and it errors on the same package. Just for any info for anyone.
I have addressed further review comments in Please somebody review.
Same error today with 'github:nixos/nixpkgs/' (2024-08-18)'
Change:
pname = "trezord-go"; version = "2.0.27"; <del> # Fixes Cgo related build failures (see https://github.com/NixOS/nixpkgs/issues/25959 ) hardeningDisable = [ "fortify" ]; </del> goPackagePath = "github.com/trezor/trezord-go"; src = fetchFromGitHub {

Discussion:
Using go + I am unable to build a simple Go program that makes use of C bindings. The program is a testcase from the Go compiler repository ( ) . The build fails with an error message like this: Another example is geth, the go ethereum client, in version 1.6.1: Switching to clang instead seems to be a workaround for the problem: This last command builds successfully. System: (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: Sandboxing enabled: false
I think this has to do with how Go handles GOROOT. It expects to be able to write to $GOROOT even though it's a read-only path. Could you try the buildCommand in go-ethereum:
Aw, I was wondering how to get rid of that warning. The warning is gone, but it doesn't seem to have helped: I originally ran into this issue when I tried to upgrade that linked Nix expression. Version 1.4.7 of go-ethereum compiles just fine, but 1.6.1 doesn't, because now one of the dependencies makes use of some kind of C bindings. While playing around with it I also switched over to using in the Nix expression, but that also didn't help. Switching to clang helped in the end. That version can be found here: But that's just a workaround and I would assume that other Go packages will at some point also run into this problem when they just use or .
I ran into this problem adding seccomp support to the docker package. It's caused by the -O2 optimization flag which is being by the fortify hardening flag. A possible fix would be to add hardeningDisable = [ "fortify" ]; to the buildGoPackage.
I can't no longer reproduce this on my system so I guess the issue is fixed? I created a PR to get rid of the workarounds:
I can confirm that I also cannot reproduce this anymore on my system. I am closing this - thanks!
Change:
<del> { version, javaVersion, platforms, hashes ? import ./hashes.nix }: { stdenv, lib, fetchurl, autoPatchelfHook, setJavaClassPath, makeWrapper # minimum dependencies , Foundation, alsa-lib, fontconfig, freetype, glibc, openssl, perl, unzip, xorg </del> <ins> { version , javaVersion , platforms , hashes ? import ./hashes.nix , useMusl ? false }: { stdenv , lib , autoPatchelfHook , fetchurl , makeWrapper , setJavaClassPath , writeShellScriptBin # minimum dependencies , alsa-lib , fontconfig , Foundation , freetype , glibc , openssl , perl , unzip , xorg </ins> , zlib <del> # runtime dependencies </del> <ins> # runtime dependencies , binutils </ins> , cups <del> # runtime dependencies for GTK+ Look and Feel , gtkSupport ? true, cairo, glib, gtk3 }: </del> <ins> , gcc , musl # runtime dependencies for GTK+ Look and Feel , gtkSupport ? stdenv.isLinux , cairo , glib , gtk3 }: assert useMusl -> stdenv.isLinux; </ins> let platform = {

Discussion:
Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
Change:
patches = [ ./compiler-rt-codesign.patch # Revert compiler-rt commit that makes codesign mandatory ./find-darwin-sdk-version.patch # don't test for macOS being >= 10.15 <del> ];# ++ stdenv.lib.optional stdenv.hostPlatform.isMusl ./sanitizers-nongnu.patch </del> <ins> ]# ++ stdenv.lib.optional stdenv.hostPlatform.isMusl ./sanitizers-nongnu.patch ++ stdenv.lib.optional stdenv.hostPlatform.isAarch32 ./compiler-rt-armv7l.patch; </ins> # TSAN requires XPC on Darwin, which we have no public/free source files for. We can depend on the Apple frameworks # to get it, but they're unfree. Since LLVM is rather central to the stdenv, we patch out TSAN support so that Hydra

Discussion:
Describe the bug A clear and concise description of what the bug is. Same issue as or , but on armv7l Additional context Add any other context about the problem here. On hydra, the clang build first started failing with this error after going from to . I diffed the range and found to be the most likely culprit. It enabled some cmakeFlags globally which used to only be enabled on darwin and useLLVM systems. I don't know what exactly these do but, I was able to build on my rpi2 by disabling them on aarch32: Since I have no idea why this works and what would be affected, I'd rather have someone look over this. 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:
we probably need to add armv7l here:
I tried but it fails with this error now: I guess it can't find a default target for armv7l somehow? Not really familiar with cmake unfortunately
I made some progress, it seems to be taking the target arch from the triplet given to , even if you override the target arch with a flag. Printf debugging showed me that it does this halfway through the configure phase, it's armhf in the beginning if I set the flag. Setting the compiler target to instead of makes it find its target and compile successfully. Does have any importance outside the build process?
I don't think it does. It's possible it sets in compiler calls, but that is considered equivalent to .