jiebi/CodeConvo huggingface dataset:
Change:
buildGoPackage rec { pname = "lxd"; <del> version = "3.13"; </del> <ins> version = "3.18"; </ins> goPackagePath = "github.com/lxc/lxd"; src = fetchurl { url = "https://github.com/lxc/lxd/releases/download/${pname}-${version}/${pname}-${version}.tar.gz"; <del> sha256 = "1kasnzd8hw9biyx8avbjmpfax1pdbp9g543g8hs6xpksmk93hl82"; </del> <ins> sha256 = "1p8g2gbwgn3kln5rxddpc2fxk8bvf026wjiqip2b0vvpi7h3955h"; </ins> }; preBuild = '' # unpack vendor pushd go/src/github.com/lxc/lxd <del> rm dist/src/github.com/lxc/lxd cp -r dist/src/* ../../.. rm -r dist </del> <ins> rm _dist/src/github.com/lxc/lxd cp -r _dist/src/* ../../.. </ins> popd '';

Discussion:
Describe the bug I'm not able to start any (freshly created) container in lxd. To Reproduce Steps to reproduce the behavior: Expected behavior Container starts without issues. Additional context Log gathered via Regarding the not enough space, I'm quiet sure that the report is wrong: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs: Maintainer information:
Maybe updating helps? I started working on a PR, though I depend on a which fails to build.
tested with merged on top inside a nogui VM
Wrong commit?
yip
Change:
sha256 = "1fyxfrzdcs6blxhkw3bcgkksaf3byrsj4cbyrqgb4869k3ynap96"; }; <ins> patches = [ ./CVE-2019-19451.patch ]; </ins> buildInputs = [ gtk2 libxml2 gettext python libxml2Python docbook5 libxslt docbook_xsl libart_lgpl ]

Discussion:
, CVSSv3=5.5 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
cc
Change:
# Hardcode absolute paths to libraries so that consumers # do not need to set LD_LIBRARY_PATH themselves. ./hardcode-paths.patch <ins> # Replace references to udevadm with an absolute paths, so programs using # umockdev will just work without having to provide it in their test environment # $PATH. (substituteAll { src = ./substitute-udevadm.patch; udevadm = "${systemdMinimal}/bin/udevadm"; }) </ins> ]; nativeBuildInputs = [

Discussion:
Steps to reproduce the behavior: with enabled <!-- 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]:
This is not really a bug or a build failure, more of a feature request. The expression in nixpkgs doesn't set , as the build with it being set would fail. Someone needs to sit down and figure out why. I propose starting with the code of the two failed tests, seeing if something is missing from nativeCheckInputs. Happy to review a PR, but I don't have the bandwidth to drive this.
It's an indication that the packaging is incorrect. Incorrect packaging sounds like a packaging bug to me. See for the main tracking issue. If it's better categorised as a "bug" than a "build failure", then so be it, but it's absolutely not a "feature request." If you don't have time, that's a totally different topic, that could be just stated as is without the rest of it.
and the test for both use to get information about devices, which is not currently provided by any input. Adding (which provides ) to the check inputs makes this build without errors, even with . Since (a binary output) needs , should probably also be in the regular build inputs. (just stumbled across this randomly and thought I'd try to find out what's up)
Oh, very nice! Wondering how is currently sneaking in then :-) In any case, I'll try to add this to a PR and see how it goes!
I opened that does this, thanks!
The PR has been merged, this can be closed.
Change:
stdenv.mkDerivation rec { pname = "vulkan-tools"; <del> version = "1.2.189.1"; </del> <ins> version = "1.2.198.0"; </ins> # It's not strictly necessary to have matching versions here, however # since we're using the SDK version we may as well be consistent with

Discussion:
vulkan-tools fails with an assertion error from vulkan-headers Steps to reproduce the behavior: the nixos-unstable-small channel vulkan-tools being installed # nix-shell -p vulkan-tools --show-trace error: assertion '(version == (vulkan-headers).version)' failed at /nix/store/cqbcz8k1wq604f8b8nc8khamyh2cl6dl-nixos-22.05pre348006./nixos/pkgs/tools/graphics/vulkan- 10| # the rest of nixpkgs. 11| src = (assert version == vulkan-headers.version; | ^ 12| fetchFromGitHub { … while evaluating the attribute 'src' of the derivation 'vulkan-tools-1.2.189.1' at /nix/store/cqbcz8k1wq604f8b8nc8khamyh2cl6dl-nixos-22.05pre348006./nixos/pkgs/stdenv/generic/make- 204 (attrs ? pname && attrs ? version)) { 205| name = | ^ 206| let … while evaluating the attribute 'buildInputs' of the derivation 'shell' at /nix/store/cqbcz8k1wq604f8b8nc8khamyh2cl6dl-nixos-22.05pre348006./nixos/pkgs/stdenv/generic/make- 204 (attrs ? pname && attrs ? version)) { 205| name = | ^ 206| let
Fix at , thanks for the report. I thought we had tests for this stuff...
fixed it for me. Thanks!
Change:
inherit (import ./libgenerated.nix lib self) melpaDerivation; super = lib.listToAttrs (map (melpaDerivation variant) (lib.importJSON archiveJson)); <del> generic = import ./melpa-generic.nix; </del> overrides = rec { shared = { # Expects bash to be at /bin/bash

Discussion:
To Reproduce Steps to reproduce the behavior: install the irony emacs package with allowBroken Expected behavior The package builds and works Additional context It has been introduced by Metadata Maintainer information: I tried to debug this but couldn't figure it out :(
Seeing this too. Not sure what is happening though /cc
It doesn't work because of what seems to be an upstream bug in tar-mode. Here's how to reproduce outside of nix: open the tar file from with emacs You'll get: According to my experimentations, it only happens when the length of the package description file name length is 32 characters (so when the version is 13 characters long). An horrific fix is to patch the version so that it's always not 13 characters long. I spent quite a bit of time trying to debug this, but it turned out being way too intense as a first common lisp experience. what do you think ?
It looks like irony- is missing from that .tar file, which is causing the error. But it does show up when I extract it with gnutar!
Change:
let python = python3; buildType = "release"; <del> # Remember to change the extpackRev and version in extpack.nix and # guest-additions/default.nix as well. main = "59f8f5774473f593e3eb5940e2a337e0674bcd9854164b2578fd43f896260c99"; version = "6.1.4"; </del> <ins> # Use maintainers/scripts/update.nix to update the version and all related hashes or # change the hashes in extpack.nix and guest-additions/default.nix as well manually. version = "6.1.6"; </ins> iasl' = iasl.overrideAttrs (old: rec { inherit (old) pname;

Discussion:
Describe the bug Virtualbox kernel drivers don't build with latest kernel. To Reproduce Steps to reproduce the behavior: on latest master, channel hasn't updated yet d=(import /home/maciej/Projekte/nix { configuration = {pkgs, ...}: { boot.kernelPackages = pkgs.linuxPackageslatest; = true; }; }).vm Expected behavior Builds Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(maciej): nixpkgs: Maintainer information:
Hi sorry for the duplicate bug report. You may find some useful information in this other issue trackers: Upstream tracker: Related to this issue: [Patch available]
Virtualbox 6.1.6 was released last week, which fixes the Linux 5.6 issues. I opened a PR with a fix for , which needs to be merged into to
Change:
path = makeBinPath [ pkgs.jq nixos-enter <ins> pkgs.util-linuxMinimal </ins> ]; };

Discussion:
nixos-install script calls and but does not depend on them On some systems, nixos-install will fail to find the mount and umount binaries on the system and therefore the install will get in a undesirable state. And the root password will not be prompted to the user. suggested to use Please run and paste the result.
Ah. If we're talking about host system executables, I'm not sure resholve is going to be much help. It'll complain about the missing commands and rewrite them to absolute paths if provided. We'd either have to prebuild for different systems or bring resholve to the system. If the problem is just weird/inconsistent user paths, and if and are in ~normal locations, using to discover and set the ~normal system PATH may help?
nixos-install is always installed with Nix, or at least should be, so we can (and should!) make it use Nix provided tools.
if it helps, on host was both in and in , but I think we should not rely on host having/providing
I don't really know, but I at least found two sources that make me think the specific uses of mount/umount here will work without a setuid wrapper: I decided to see how a naive attempt at using resholve would work but stopped when it was obvious that there's some dynamic behavior in the script (stringly-inlining other scripts). resholve won't be able to see through stuff like that without some changes to script source. If you just want to get mount/umount in with minimal effort, I'd just add them to the existing makeBinPath. Note that also appears in nixos-enter. If you're curious, I pushed up my ~starter on resholving it: ()
Change:
, useSteamRun ? true }: let <del> rev = "1.0.9"; </del> <ins> rev = "1.1.0"; </ins> in buildDotnetModule rec { pname = "XIVLauncher";

Discussion:
Package name: xivlauncher Latest released version: Current version on the unstable channel: 1.0.8 Current version on the stable/release channel: 1.0.8 <!-- 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]:
9 also released yesterday but I don't see a PR or issue for it. Quite likely there will be sever more releases as they work on fixes for the new expansion that dropped today.
9 (which is recent enough to successfully download and play Dawntrail) was merged to master yesterday, and 24.05 today; we're at the mercy of Hydra for that to show up in the release channels. Hopefully that will be fairly soon. I'll get around to 1.1.0 at some point – it fixes repair, but that's it, and I'm currently enjoying the new expansion.
Ah! I didn't see 1.0.9 got in when I search! Enjoy Dawntrail!
Change:
buildInputs = lib.optionals stdenv.isLinux [ zlib ]; installPhase = '' <ins> runHook preInstall </ins> mkdir -p $out/share/sbt $out/bin cp -ra . $out/share/sbt ln -sT ../share/sbt/bin/sbt $out/bin/sbt ln -sT ../share/sbt/bin/sbtn-x86_64-${ if (stdenv.isDarwin) then "apple-darwin" else "pc-linux" } $out/bin/sbtn <del> ''; doInstallCheck = true; installCheckPhase = '' ($out/bin/sbt --offline --version 2>&1 || true) | grep 'getting org.scala-sbt sbt ${version}  (this may take some time)' </del> <ins> runHook postInstall </ins> ''; meta = with lib; {

Discussion:
Describe the bug As of this commit the package no longer allows overriding the JRE without failing to build. It still worked as of this commit To Reproduce Note that is the content of the in the above commit. note it also fails when overriding with however which is the current java15 version works. Expected behavior Successful build of SBT Additional context Non Debug output Notify maintainers Metadata Maintainer information:
Change:
strictDeps = true; <del> nativeBuildInputs = [ cmake pkg-config makeWrapper go ninja ] ++ lib.optionals withCups [ cups.dev ]; </del> <ins> nativeBuildInputs = [ cmake pkg-config makeWrapper go ninja ] ++ lib.optionals withCups [ cups.dev ]; </ins> # bash is only used to rewrite shebangs <del> buildInputs = [ bash curl jemalloc json_c libuv zlib libyaml lm_sensors ] ++ lib.optionals stdenv.isDarwin [ CoreFoundation IOKit libossp_uuid ] ++ lib.optionals (!stdenv.isDarwin) [ libcap libuuid ] </del> <ins> buildInputs = [ bash curl jemalloc json_c libuv zlib libyaml ] ++ lib.optionals stdenv.isDarwin ( with darwin.apple_sdk.frameworks; [ CoreFoundation IOKit libossp_uuid ] ) ++ lib.optionals (stdenv.isLinux) [ libcap libuuid lm_sensors ] </ins> ++ lib.optionals withCups [ cups ] ++ lib.optionals withDBengine [ lz4 ] ++ lib.optionals withIpmi [ freeipmi ] <del> ++ lib.optionals withNetfilter [ libmnl libnetfilter_acct ] ++ lib.optionals withConnPubSub [ google-cloud-cpp grpc ] </del> <ins> ++ lib.optionals withNetfilter [ libmnl libnetfilter_acct ] ++ lib.optionals withConnPubSub [ google-cloud-cpp grpc ] </ins> ++ lib.optionals withConnPrometheus [ snappy ] <del> ++ lib.optionals withEbpf [ libelf libbpf ] </del> <ins> ++ lib.optionals withEbpf [ libelf libbpf ] </ins> ++ lib.optionals (withCloud || withConnPrometheus) [ protobuf ] ++ lib.optionals withSystemdJournal [ systemd ] ++ lib.optionals withSsl [ openssl ];

Discussion:
Steps to reproduce the behavior: netdata 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Created a PR to fix the build, can you try it out ?
Change:
let <ins> inherit (lib) escapeShellArgs toList ; </ins> mkDbExtraCommand = contents: let contentsList = if builtins.isList contents then contents else [ contents ];

Discussion:
Describe the bug When using and and I get a failure that I think is unexpected. To Reproduce Steps to reproduce the behavior: With the following files: and the following : I get the following error when building like so: Note that everything works fine if I simply don't have the as an entry in the list to . Expected behavior The build to succeed and to be able to see a 'doomed' file created by the root user! Notify maintainers Can't find any: But perhaps the maintainers are good: <!-- 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. Maintainer information:
I guess it has to do somehow with the fact that this command is running in a virtual machine. A "workaround" is to wrap the folder in a derivation: I don't quite know enough nix to know if this is committing some major crime of misunderstanding or something.
and I are in the "CODEOWNERS" file, and and I are in the test. Did you think of another place where maintainers could be listed? We don't have a standard attribute for attrsets or functions.
Change:
<ins> { stdenv, fetchFromGitHub, pkgconfig }: with stdenv.lib; stdenv.mkDerivation rec { pname = "libco-canonical"; version = "19.1"; src = fetchFromGitHub { owner = "canonical"; repo = "libco"; rev = "v${version}"; sha256 = "03a0fq8f8gc4hjzcf0zsjib4mzag47rxrrg9b5r6bx53vj5rhj78"; }; nativeBuildInputs = [ pkgconfig ]; makeFlags = [ "PREFIX=${placeholder "out"}" ]; outputs = [ "dev" "out" ]; meta = { description = "A cooperative multithreading library written in C89"; homepage = "https://github.com/canonical/libco"; license = licenses.isc; maintainers = with maintainers; [ wucke13 ]; }; } </ins>

Discussion:
Describe the bug I'm not able to start any (freshly created) container in lxd. To Reproduce Steps to reproduce the behavior: Expected behavior Container starts without issues. Additional context Log gathered via Regarding the not enough space, I'm quiet sure that the report is wrong: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs: Maintainer information:
Maybe updating helps? I started working on a PR, though I depend on a which fails to build.
tested with merged on top inside a nogui VM
Wrong commit?
yip
Change:
# and exit. This is gonna be used to configure calibre-web declaratively, as most of its configuration parameters # are stored in the DB. ./db-migrations.patch <ins> # environ in tornado.wsgi.WSGIContainer no longer a static method from 6.3 version ./static_environ.patch </ins> ]; # calibre-web doesn't follow setuptools directory structure. The following is taken from the script

Discussion:
calibre-web failed to start Steps to reproduce the behavior: -rebuild switch -u calibre-web The service start successfully, and no error occurs. If applicable, add screenshots to help explain your problem. 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.
Change:
}; <del> wombat256 = buildVimPluginFrom2Nix { # created by nix#NixDerivation name = "wombat256"; src = fetchurl { url = "http://www.vim.org/scripts/download_script.php?src_id=13400"; name = "wombat256mod.vim"; sha256 = "1san0jg9sfm6chhnr1wc5nhczlp11ibca0v7i4gf68h9ick9mysn"; </del> <ins> wombat256-vim = buildVimPluginFrom2Nix { # created by nix#NixDerivation name = "wombat256-vim-2010-10-17"; src = fetchgit { url = "git://github.com/vim-scripts/wombat256.vim"; rev = "8734ba45dcf5e38c4d2686b35c94f9fcb30427e2"; sha256 = "2feb7d57ab0a9f2ea44ccd606e540db64ab3285956398a50ecc562d7b8dbcd05"; </ins> }; <del> buildInputs = [ unzip ]; </del> dependencies = []; <del> meta = { url = "http://www.vim.org/scripts/script.php?script_id=2465"; }; </del> }; }

Discussion:
nixpkgs version: nixos-unstable (rev: ) configuration: steps: error: If I remove the wombat256 plugin from my configuration, then vim-env builds fine. Currently, wombat256 seems to be the only plugin in nixpkgs affected by this issue. However, I have auto-generated another plugin which is also affected. What these two plugins have in common is that they are both using , and are downloading files rather than archives. cc
Isn't it a better idea to download those plugins from github? And add them to as ? Because I personally don't like fetching from vim site. I can change the behavior to load them from vim-scripts repo.
Yes, downloading from github works well and is better I think. I'll update wombat256 and use github when adding plugins from now on.
Change:
version = "22.8.12"; src = fetchzip { <del> url = "https://downloads.exodus.io/releases/${pname}-linux-x64-${version}.zip"; </del> <ins> url = "https://downloads.exodus.com/releases/${pname}-linux-x64-${version}.zip"; </ins> sha256 = "sha256-jNzHh4zYhFzpFZAC9rHmwjTdFkbpROSEN3qpL7geiOU="; };

Discussion:
Steps to reproduce the behavior: exodus They filter requests based on User-Agent: The URL they redirect to does not have the User-Agent filter, so this could be used directly instead:
Seems something very similar is happening again:
Change:
linux_testing = packagesFor kernels.linux_testing; linux_testing_bcachefs = recurseIntoAttrs (packagesFor kernels.linux_testing_bcachefs); <del> linux_hardened = recurseIntoAttrs (hardenedPackagesFor packageAliases.linux_default.kernel { }); </del> <ins> linux_hardened = recurseIntoAttrs (packagesFor kernels.linux_hardened); </ins> <del> linux_4_14_hardened = recurseIntoAttrs (hardenedPackagesFor kernels.linux_4_14 { stdenv = gcc10Stdenv; buildPackages = buildPackages // { stdenv = buildPackages.gcc10Stdenv; }; }); linux_4_19_hardened = recurseIntoAttrs (hardenedPackagesFor kernels.linux_4_19 { stdenv = gcc10Stdenv; buildPackages = buildPackages // { stdenv = buildPackages.gcc10Stdenv; }; }); linux_5_4_hardened = recurseIntoAttrs (hardenedPackagesFor kernels.linux_5_4 { stdenv = gcc10Stdenv; buildPackages = buildPackages // { stdenv = buildPackages.gcc10Stdenv; }; }); linux_5_10_hardened = recurseIntoAttrs (hardenedPackagesFor kernels.linux_5_10 { }); linux_5_15_hardened = recurseIntoAttrs (hardenedPackagesFor kernels.linux_5_15 { }); linux_6_1_hardened = recurseIntoAttrs (hardenedPackagesFor kernels.linux_6_1 { }); </del> <ins> linux_4_14_hardened = recurseIntoAttrs (packagesFor kernels.linux_4_14_hardened); linux_4_19_hardened = recurseIntoAttrs (packagesFor kernels.linux_4_19_hardened); linux_5_4_hardened = recurseIntoAttrs (packagesFor kernels.linux_5_4_hardened); linux_5_10_hardened = recurseIntoAttrs (packagesFor kernels.linux_5_10_hardened); linux_5_15_hardened = recurseIntoAttrs (packagesFor kernels.linux_5_15_hardened); linux_6_1_hardened = recurseIntoAttrs (packagesFor kernels.linux_6_1_hardened); </ins> linux_zen = recurseIntoAttrs (packagesFor kernels.linux_zen); linux_lqx = recurseIntoAttrs (packagesFor kernels.linux_lqx);

Discussion:
Steps to reproduce the behavior: linuxKernel.kernels.linux54hardened (with ) This causes many failure in Hydra (one per module). The non-hardened version works fine. Other kernel versions work fine. (for previous ZHF discussion) ZHF: Please run and paste the result.
This is linked with commit (Feb 21 23:41:34 2023): "use , not assert"
linuxKernel.kernels.linux54_hardened was introduced in and seems to build fine at this commit. I am going to from this point.
The commit breaking linuxKernel.kernels.linux54_hardened is (found via bisect).
Could this be the same as ? Since the build failure is actually in , not the actual kernel build.
I confirm that the build failure is linuxKernel.kernels.linux54hardened.configfile. It seems that specifies that uses gcc10: but adding in outputs . There is definitely something off in these Nix expressions. I don't understand why the derivation sees gcc12 rather than gcc10.
: It looks like there is another definition here which doesn't override the stdenv: But since the failures are happening in the kernel package-set, I don't believe the kernel with the missing stdenv is related.