jiebi/CodeConvo huggingface dataset:
Change:
handleEvalIssue = { meta, attrs }: { reason , errormsg ? "" }: let msg = if inHydra <del> then "Failed to evaluate ${getName attrs}: «${reason}»: ${errormsg}" </del> <ins> then "Failed to evaluate ${getNameWithVersion attrs}: «${reason}»: ${errormsg}" </ins> else '' <del> Package ‘${getName attrs}’ in ${pos_str meta} ${errormsg}, refusing to evaluate. </del> <ins> Package ‘${getNameWithVersion attrs}’ in ${pos_str meta} ${errormsg}, refusing to evaluate. </ins> '' + (builtins.getAttr reason remediation) attrs;

Discussion:
When running it fails due to an insecure package. To resolve this the output of recommends adding to the file (in my case for electron) This is incorrect as the correct line that should be must contain the package name and ver sion instead of just the package name (eg: instead of ) Steps to reproduce the behavior: while having an insecure package the instructions in the output The output must specify instead of in the sample code. This is the current (wrong) full output
Change:
++ buildInputs; #name = builtins.trace (attrs.name or "no attr.name" ) "${namePrefix}${gemName}-${version}"; <del> name = attrs.name or "${namePrefix}${gemName}-${version}"; </del> <ins> name = attrs.name or "${namePrefix}${gemName}-${suffix}"; </ins> inherit src;

Discussion:
Describe the bug fails to build when the gem configured in the is pointing to a git repository. <details<summaryGemfile</summary</details<details</summary</details<details</summary</details<details<summarynix-build output</summary</detailsTo Reproduce Run with the configuration posted above. Expected behavior The package should build like it does when the gem is pointed to a released version. Metadata Maintainer information:
Can confirm this, I have the same issue trying to package
I ran into this issue today. Both in my scenario and the recipe above the issue happens bundlerApp tries to of the gem. The directory find is call with doesn't exist. While I don't know the proper way to fix bundlerApp, a work around is to set the installManpages attributes to false. ej.
I'm having issue as well, is there any temporal fix atleast? Its annoying, and making my setup not-so-reproducible, I'm bundling puppet and it says: Its actually been created with rev: at and haven't been copied over.
Seems like you're right not installing manpages did somehow fix it, but not sure how you figured out... What I find post trying that is that the problem resides exactly in these lines:
I figured out the workaround by reading the error from nix log . Seeing the call to find being the error and looking for the expression responsible for making the call. Found it was the the installManpages option as you linked above. However I'm not familiar enough with the process to know what is the proper way to fix this. It seems the reason it fails is because in only has the dependencies of the gem we are building, not the gem itself. Should the man page installation happen in a latter phase? Should it look for the gem man pages in a different place? In what phase it is running?
I started a PR for the fix, can you please try building packages from this PR branch?
Change:
{ stdenv, fetchzip }: let <del> version = "3.1.1"; </del> <ins> version = "3.2.0"; </ins> in fetchzip { name = "emacs-all-the-icons-fonts-${version}";

Discussion:
In current master branch pythonPackages.mysqlclient fails to build. Checkout nixpkgs on revision and run: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Most likely caused by . Unfortunately, the config-tools are not very configuration friendly. Until is resolved, I would add to the package.
Unfortunately this does not change anything, still failing with the same error message..
Hmm, apparently just hardcodes the path without the ability to override it from the attrset passed to : Is that intentional, Until this is resolved, you can use :
Change:
systemd.services.systemd-networkd = { wantedBy = [ "multi-user.target" ]; restartTriggers = map (f: f.source) (unitFiles); <ins> # prevent race condition with interface renaming (#39069) requires = [ "systemd-udev-settle.service" ]; after = [ "systemd-udev-settle.service" ]; </ins> }; systemd.services.systemd-networkd-wait-online = {

Discussion:
When using together with predictable interface names, there seems to be a race condition between activating the interfaces and renaming them, resulting in non-deterministic failure of interface renaming and setup. For an example, see these hydra builds: and Issue occurs on 18.03 and current master (i.e. with systemd 237 and 238). It is probably an upstream bug (but has not confirmed this yet). I found two similar reports: and Since the corresponding test is part of the jobs for the and channels, the sporadically failing test can delay the channels. I suggest removing this test from the jobs for the time being until this is fixed. Although the issue seems non-deterministic in nature (see hydra builds), I can quite reliably reproduce it running the test on my local machine: nixos or master
Note that our udev rules for network interfaces are not in sync with what systemd upstream uses. So that bugs in our system are probably different from what other linux distributions report.
The only relevant change to rules that I found so far is that we use a custom version of when predictable interface names are enabled. Not sure why the built-in upstream solution doesn't work for us.
After some tests, here's what I think is happening: Stage 1 discovers and adds the network interfaces with their original names. Renaming doesn't happen until stage 2. But tries to configure all interfaces it finds, so there's a race condition between stage 2 and . This can be (sort of) "solved" by an ugly hack: Add to to allow time for renaming. Fixes the test but slows down the boot and still does not guarantee success. A better solution might be to let stage 1 rename the interfaces. I tried but haven't quite figured out how to do this. We might try to go back to the upstream way of predictable interface names controlled by the kernel boot option. maybe you can help? (I found your from a long time ago, which was reverted after a few days)
Hmm not sure here, sorry!
Fixed by applying predictable interface names in stage 1 already.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
{ stdenv, fetchgit , cmake, pkgconfig, git , boost, miniupnpc, openssl, unbound, cppzmq <del> , zeromq, pcsclite, readline </del> <ins> , zeromq, pcsclite, readline, libsodium </ins> , CoreData, IOKit, PCSC }:

Discussion:
Monero is hardforking and changing the proof of work. xmr-stak must be upgraded to v2.5.0 before the 18th of Oct (Thu), or it will stop working Thanks
Thanks & .. When can we expect this to land ? Thanks
It should be ready to merge already.
Change:
genericName = "Video Conference"; categories = "Network;Application;"; mimeType = "x-scheme-handler/zoommtg;"; <del> }).buildCommand; </del> <ins> }).buildCommand + '' ln -s $out/share/zoom-us/zoom $out/bin/zoom-us ''; qtWrapperArgs = [ ''--prefix PATH : ${makeBinPath [ coreutils glib.dev pciutils procps qttools.dev utillinux ]}'' ''--prefix LD_PRELOAD : ${libv4l}/lib/libv4l/v4l2convert.so'' ]; </ins> passthru.updateScript = ./update.sh;

Discussion:
Describe the bug zoom-us appears to be broken. Caused by a change between .... To Reproduce Steps to reproduce the behavior: Expected behavior Success Additional context Logs: Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(mbauer): nixpkgs: Maintainer information: /cc
I'll try using the new Qt infrastructure and see how it interacts with binaries, I guess.
Just using doesn't change anything, but removing from allows it to build. I had to replace with as well. Unfortunately, the application doesn't create a window, but the terminal output is normal. Still investigating.
Fix incoming.
Change:
rm $outd/xapian-lite.cc $outd/emacs-module.h $outd/emacs-module-prelude.h $outd/demo.gif $outd/Makefile ''; }); <ins> # native compilation for tests/seq-tests.el never ends # delete tests/seq-tests.el to workaround this seq = super.seq.overrideAttrs (old: { dontUnpack = false; postUnpack = (old.postUnpack or "") + "n" + '' local content_directory=$(echo seq-*) rm --verbose $content_directory/tests/seq-tests.el src=$PWD/$content_directory.tar tar --create --verbose --file=$src $content_directory ''; }); </ins> }; elpaDevelPackages = super // overrides;

Discussion:
When on tries to open magit on 23.11 you get the in the output and the commands aren’t working as expected. Steps to reproduce the behavior: to 23.11 Emacs and Magit in a Git repo of your choice. to select a commit for example. The commit diff should be shown. ! The issue is already fixed upstream but requires some changes in Nixpkgs: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can't repro this using nix-shell -p ' (ep: [ ])' -I nixpkgs=flake:github:NixOS/nixpkgs/nixos-23.11 and then running emacs via emacs -Q on aarch64-darwin.
I tried that and it's happening as well. The screenshot is from WSL but the initial finding is from NixOS. !
I reproduced the error here - with the same seq-keep error message. try to call it with then and finally .
That's what I did; I wouldn't know how to do it differently with my example. Though note that this is on aarch64-darwin. I don't have access to GUI Linux right now. An issue as obvious as this should happen here aswell though. Does the same happen inside a terminal frame?
Have you tested it inside an already-existing local Git repo? And yes, I have tested it here and now in a XTerm via . (Of course I am using my AMD machine.)
This is still broken.
It would require updating elisp-packages on stable.
I know, isn’t that approapriate when such an important package is broken?
It became a bit too hard recently, since Emacs triggers a mass rebuild.
FYI, I proposed a fix for this:
Ah okay, makes sense.
If I understood this correctly we need this to have it working in 24.05? Going to test it then.
Fixed by and Not sure why this issue is not closed by them though.
Change:
]; nativeCheckInputs = <del> with python3.pkgs; </del> <ins> with python3Packages; </ins> [ binary git

Discussion:
The nixpkgs version of fails to build a project created with . Steps to reproduce the behavior: The following expected behavior was seen on Ubuntu 24.04. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
No need to create an empty project. Running anywhere gives
Change:
<ins> { xunit-viewer, runCommand, ... }: runCommand "test-xunit-viewer" { nativeBuildInputs = [ xunit-viewer ]; } '' mkdir $out xunit-viewer -r ${./example.junit.xml} -o $out/index.html ( set -x grep '<body' $out/index.html # Can't easily grep for parts of the original data, because it ends up # embedded as base64 encoded data (and slightly modified?). # We'd have to really dissect it or render it with a browser. # Fortunately, we've already caught the most severe packaging problems # with just this. ) '' </ins>

Discussion:
Project description xunit-viewer is an node package that formats JUnit/xunit test results into HTML reports. Metadata homepage URL: source URL: license: mit platforms: - no native dependencies
Change:
substituteInPlace $out/etc/nvidia-container-runtime/config.toml  --subst-var-by glibcbin ${lib.getBin glibc} <del> ln -s $out/bin/nvidia-container-{toolkit,runtime-hook} </del> <ins> # See: https://gitlab.com/nvidia/container-toolkit/container-toolkit/-/blob/03cbf9c6cd26c75afef8a2dd68e0306aace80401/packaging/debian/nvidia-container-toolkit.postinst#L12 ln -s $out/bin/nvidia-container-runtime-hook $out/bin/nvidia-container-toolkit </ins> wrapProgram $out/bin/nvidia-container-toolkit  --add-flags "-config ${placeholder "out"}/etc/nvidia-container-runtime/config.toml"

Discussion:
Project description The NVIDIA Container Toolkit CLI provides a number of utilities that are useful for working with the NVIDIA Container Toolkit. Metadata homepage URL: source URL: license: Apache License platforms: linux More Info Looks some of the related tools for the container runtime. Have already been included. But not . Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

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. -- Latest nvidia driver , which is linked against. for inclusion of into a container. Without it, OpenGL inside container is broken. Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
As a workaround, I mount into the container explicitly.
Change:
conf = format.generate "vector.toml" cfg.settings; validateConfig = file: pkgs.runCommand "validate-vector-conf" { <del> nativeBuildInputs = [ pkgs.buildPackages.vector ]; </del> <ins> nativeBuildInputs = [ pkgs.vector ]; </ins> } '' vector validate --no-environment "${file}" ln -s "${file}" "$out"

Discussion:
Derivations defined with pkgs are not compatible with cross compilation as defined in Nixpkgs manual. This is the case for all derivation defined in NixOS modules. Following derivation fails to build, since pkgs is used: Following dervation builds, since splicedPackages is used: The NixOS module system uses not splicedPackages and therefor all derivations defined with pkgs which depends on nativeBuildInputs will fail to cross compile. Select the package by hand and do not use stdenv cross compilation automatism: Derivations defined in NixOS modules can be cross compiled.
for splicing to work has to be used the following works
That's true, but not all parts in nixos uses and I did not expect this behavior. I created a PR to fix this issue.
(linking a related issue )
Change:
{ deps = [ autoconf264 automake111x gettext libtool ]; } ../build-support/setup-hooks/autoreconf.sh; <del> autoPatchelfHook = makeSetupHook { name = "auto-patchelf-hook"; deps = [ file ]; } </del> <ins> autoPatchelfHook = makeSetupHook { name = "auto-patchelf-hook"; } </ins> ../build-support/setup-hooks/auto-patchelf.sh; ensureNewerSourcesHook = { year }: makeSetupHook {}

Discussion:
determines which executables it should patch via: However, PIEs have a type of , as in: Questions: Should also patch PIEs? An alternative is to just call manually, but I'm having trouble finding out how to run it in the correct phase. Is there even a reliable way to distinguish between shared libraries and PIEs? I know in general, shared libs don't have an section, but is this a reliable enough assumption? cc
Actually, executables can also be shared libraries at the same time (eg. and I'm doing exactly that in my as well), so the only thing that distinguishes them is an section (except if statically linked of course). So I guess it's a better idea to just look for in instead of what we currently do. At least if I don't miss something, this should be the most reliable way, after all what we want to do with executables is to patch the section. If nobody else sends a PR in the meantime, I'm going to fix this next week. As for it's a bit more difficult, because it needs to be run after the normal hook, so it might be necessary to add .
Change:
{ stdenv, fetchFromGitHub, pkgconfig, autoreconfHook, makeWrapper , zimg, libass, python3, libiconv <del> , ApplicationServices, nasm </del> <ins> , ApplicationServices </ins> , ocrSupport ?  false, tesseract ? null , imwriSupport? true,  imagemagick7 ? null }:

Discussion:
Vapoursynth in nixpkgs is still version R47 which is affected by serious (crashes on some CPUs, artifacts) bugs that were fixed in R49 (Audio support was also merged since then). Moreover R47 is the first vapoursynth version to not require nasm anymore (all asm was removed in favor of intrinsics). For details, the last few articles on the are a good read. It'd be nice to have an upgraded package for it. It's my first issue so I'm not sure I did this correctly.
Tested and backported to 20.03 in .
Change:
stdenv.mkDerivation rec { pname = "mutt"; <del> version = "1.14.3"; </del> <ins> version = "1.14.4"; </ins> src = fetchurl { url = "http://ftp.mutt.org/pub/mutt/${pname}-${version}.tar.gz"; <del> sha256 = "0wd4cv1c9hqymvml979g607nh3xxmlyx1ifc4r4qf39v6grnsmdi"; </del> <ins> sha256 = "1hykkq3m7kqic5r7vzg45xaww7415fv5i2d03slzykqb47w5d3na"; </ins> }; patches = optional smimeSupport (fetchpatch {

Discussion:
, CVSSv3=5.9 (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives. Cc
Change:
owner = "zen-kernel"; repo = "zen-kernel"; inherit rev; <del> sha256 = "sha256-A0QrY1REbRODnHtmyNqVaiLhDgYCECevfHZCxtoQ9kU="; </del> <ins> sha256 = "sha256-LCLfLE85NifuskYl2dxLOJEsUNHLegF8ecYyU4xOCtY="; </ins> }; structuredExtraConfig = with lib.kernel; { ZEN_INTERACTIVE = yes; <ins> # TODO: Remove once #175433 reaches master # https://nixpk.gs/pr-tracker.html?pr=175433 WERROR = no; </ins> }; extraMeta = {

Discussion:
The Zen kernel is failing to build for me since the update to 5.18, and so I thought I'd open an issue since I can't seem to find any existing info about it. Bisected to system: host os: multi-user?: sandbox: version: channels(root): channels(alex): nixpkgs:
Looks like it didn't build even in the CI of : But, we already have a new version: Cc (since you're always the one to bump it)
Unfortunately 5.18.1 doesn't seem to build either for me. :( Given that the file in question hasn't been touched in months, I'm wondering if this has something to do with the move to C11 for the 5.18 kernel. But that's just a guess. I can think of two possible quick solutions: Include a patch that adds a comment Ignore that warning everywhere in the kernel
Staging recently got change to avoid Werror-style failures.
Given that that change will take a bit to get to master, do you think it would make sense to set for just the zen kernel in the meantime? Or even just revert and move it to staging so that it gets merged when the change does? I'm asking because—while it's not too much trouble to add patches to my personal NixOS configuration—right now the zen kernel is broken for everyone, and so it might be a good idea to get it back to a working state in the meantime. I'm not sure how many people use the zen kernel though, it seems to be not very many, and so if it's better to just leave it as-is for a bit that's fine too; I don't really know how such things are usually handled in nixpkgs and am trying to learn. :)
I'd say setting for zen kernel is perfectly fine. Should be a matter of adding it to Do you want to give it a try and propose a PR? AFAIU you already run that kernel version and have a chance to validate it if still boots. You could also add a TODO to remove it once staging is merged.
should've gone to master and/or be merged with the next kernel bump or something if the rebuilds were that critical which I don't think they are. We could cherry-pick it if we need it now.

I made , but it's late here so I don't have time to test it properly and am waiting to open a PR until I can do so. It at least builds though. I figured while I was at it I should also bump the version to 5.18.1-zen1, but in hindsight maybe I should wait until the mainline kernel is updated to 5.18.1 in nixpkgs? Anyway, I'll test it when I have time tomorrow evening, make any necessary changes, and open a PR, unless we decide to cherry-pick ? That seems like a nicer solution to me personally, but I don't really have a strong preference.
I finally got around to testing this and opened a PR: :). I'm personally in favor of cherry-picking , though.
Change:
desktopItems = [ (makeDesktopItem { comment = meta.description; <del> name = "JabRef %U"; </del> <ins> name = "JabRef"; </ins> desktopName = "JabRef"; genericName = "Bibliography manager"; categories = [ "Office" ]; icon = "jabref"; <del> exec = "JabRef"; </del> <ins> exec = "JabRef %U"; </ins> startupWMClass = "org.jabref.gui.JabRefMain"; mimeTypes = [ "text/x-bibtex" ]; })

Discussion:
Regression: File open dialog again results in crash due to missing GSettings schema path. This was previously reported in and fixed in . Steps to reproduce the behavior: on "Open library" icon File open dialog opens. Please run and paste the result.
Change:
, qt5compat , wrapQtAppsHook , nix-update-script <ins> , pkg-config </ins> }: stdenv.mkDerivation (finalAttrs: { pname = "albert"; <del> version = "0.22.4"; </del> <ins> version = "0.22.9"; </ins> src = fetchFromGitHub { owner = "albertlauncher"; repo = "albert"; rev = "v${finalAttrs.version}"; <del> sha256 = "sha256-M5wMi/yH5c08Y7tpHpOulcz0utnnduGsR5z3EHeBecM="; </del> <ins> sha256 = "sha256-MhZHklb//VH2GkAzK46P7EwCIa50l5y+2VssrgpTlWA="; </ins> fetchSubmodules = true; }; nativeBuildInputs = [ cmake <ins> pkg-config </ins> wrapQtAppsHook ];

Discussion:
Package name: albert Latest released version: 0.22.9 <!-- Search your package here: --- Current version on the unstable channel: 0.22.4 Current version on the stable/release channel: 0.20.13 <!-- 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.