jiebi/CodeConvo huggingface dataset:
Change:
Similar to Hydra now, I'm having issues with with i686 This is used for x86_64 to get the drivers to run Steam and other older games. Building from as I have for months while I wait for + because I need to turn off the broken build flag. Maybe one day it will get reviewed and merged in and I can go back to unstable. Please run and paste the result.
I bisected it to commit
What is "it"? I'm not sure what you mean or what I should do/try with .
That was just a note that introduced that regression. builds fine before that commit, but does not build with that commit. It would probably build if you revert that commit, but you’d have to rebuild the world, so I can’t recommend that. So, no fix at this point. You can switch to a commit before , if you need a working 32-bit amdvlk. cc
I don't know enough about amdvlk to be able to do anything with this information.
The comment in gpurt doesn't help much: LTO is disabled by default in directx-shader-compiler, and the other cmake option is already set. I noticed that at least in my case is segfaulting when building 32-bit : I don't understand graphic drivers plumbing or what's going on in that build, but thanks to bisect I tried to just build 32-bit directx-shader-compiler with older gcc and it builds now (it also builds gcc11, but it's still better than a failing build). Here's the overlay:
I experience the same problem:
amdvlk is enabled by default if you're using nixos-hardware AMD modules, and figuring that out isn't entirely obvious for newer NixOS users.
Not since
Not sure what exactly you are talking about, but this problem only happens with 32-bit amdvlk. The 64-bit one builds/works just fine.
Steam enables 32bit support here
Overriding the compiler is no longer necessary .
32-bit is broken again now for me.
's overlay is working however
Weird; I tested building without the overlay and that worked for me, and passed as well. Do you have any idea where the difference might come from?
I can’t say I know what the differences are but I can tell you that I pulled the latest unstable into my and when I ran tried to build, and then failed. If we peek Hydra, we can see it’s failing up there too: toastal ไข่ดาว | PGP: 7944 74B7 D236 DAB9 C9EF E7F9 5CCE 6F14 66D4 7C9E

Discussion:
directx-headers = callPackage ../development/libraries/directx-headers {}; <del> directx-shader-compiler = callPackage ../tools/graphics/directx-shader-compiler {}; </del> <ins> directx-shader-compiler = callPackage ../tools/graphics/directx-shader-compiler { # https://github.com/NixOS/nixpkgs/issues/216294 stdenv = if stdenv.cc.isGNU && stdenv.isi686 then gcc11Stdenv else stdenv; }; </ins> dkimproxy = callPackage ../servers/mail/dkimproxy { };
Change:
When building the resulting binary contains in the shebang line. This causes the binary to fail to execute. The bug was introduced between 22.05 and 22.11: The binary runs and doesn't die on a broken shebang. <!-- 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.
This looks fun
I wonder if this was a regression from me making node2nix manually handle bin stuff instead of letting npm (not) handle it I can maybe make a quick patch to node2nix's node-env to dos2unix all bin scripts with shebangs in a line right after this one:
I've opened with a fix

Discussion:
then ln -s $out/lib/node_modules/.bin $out/bin <del> # Patch the shebang lines of all the executables </del> <ins> # Fixup all executables </ins> ls $out/bin/* | while read i do file="$(readlink -f "$i")" chmod u+rwx "$file" <del> patchShebangs "$file" </del> <ins> if isScript "$file" then sed -i 's/r$//' "$file"  # convert crlf to lf fi </ins> done fi

}; nativeBuildInputs = [ pkgs.buildPackages.makeWrapper ]; postInstall = let <del> # Needed to fix Node.js 16+ - PR svanderburg/node2nix#302 npmPatch = fetchpatch { name = "emit-lockfile-v2-and-fix-bin-links-with-npmv7.patch"; url = "https://github.com/svanderburg/node2nix/commit/375a055041b5ee49ca5fb3f74a58ca197c90c7d5.patch"; hash = "sha256-uVYrXptJILojeur9s2O+J/f2vyPNCaZMn1GM/NoC5n8="; }; </del> <ins> patches = [ # Needed to fix Node.js 16+ - PR svanderburg/node2nix#302 (fetchpatch { name = "emit-lockfile-v2-and-fix-bin-links-with-npmv7.patch"; url = "https://github.com/svanderburg/node2nix/commit/375a055041b5ee49ca5fb3f74a58ca197c90c7d5.patch"; hash = "sha256-uVYrXptJILojeur9s2O+J/f2vyPNCaZMn1GM/NoC5n8="; }) # Needed to fix packages with DOS line-endings after above patch - PR svanderburg/node2nix#314 (fetchpatch { name = "convert-crlf-for-script-bin-files.patch"; url = "https://github.com/svanderburg/node2nix/commit/91aa511fe7107938b0409a02ab8c457a6de2d8ca.patch"; hash = "sha256-ISiKYkur/o8enKDzJ8mQndkkSC4yrTNlheqyH+LiXlU="; }) ]; </ins> in '' <del> patch -d $out/lib/node_modules/node2nix -p1 < ${npmPatch} </del> <ins> ${lib.concatStringsSep "n" (map (patch: "patch -d $out/lib/node_modules/node2nix -p1 < ${patch}") patches)} </ins> wrapProgram "$out/bin/node2nix" --prefix PATH : ${lib.makeBinPath [ pkgs.nix ]} ''; };
Change:
is undocumented. Add it to the manual. <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]:
Here you can find the source: So basically it runns on your package with some .

Discussion:
}; ``` <ins> ::: {.tip} A common pattern is to use the [`nix-update-script`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/common-updater/nix-update.nix) attribute provided in Nixpkgs, which runs [`nix-update`](https://github.com/Mic92/nix-update): ```nix passthru.updateScript = nix-update-script { }; ``` For simple packages, this is often enough, and will ensure that the package is updated automatically by [`nixpkgs-update`](https://ryantm.github.io/nixpkgs-update) when a new version is released. The [update bot](https://nix-community.org/update-bot) runs periodically to attempt to automatically update packages, and will run `passthru.updateScript` if set. While not strictly necessary if the project is listed on [Repology](https://repology.org), using `nix-update-script` allows the package to update via many more sources (e.g. GitHub releases). ::: </ins> ##### How update scripts are executed? {#var-passthru-updateScript-execution} Update scripts are to be invoked by `maintainers/scripts/update.nix` script. You can run `nix-shell maintainers/scripts/update.nix` in the root of Nixpkgs repository for information on how to use it. `update.nix` offers several modes for selecting packages to update (e.g. select by attribute path, traverse Nixpkgs and filter by maintainer, etc.), and it will execute update scripts for all matched packages that have an `updateScript` attribute.
Change:
Steps to reproduce the behavior: spotify It was building with a few commits behind, but there were no updates to the package, so I'm not sure why it fails now. Please run and paste the result.

Discussion:
ln -s ${nspr.out}/lib/libnspr4.so $libdir/libnspr4.so ln -s ${nspr.out}/lib/libplc4.so $libdir/libplc4.so <del> ln -s ${ffmpeg.out}/lib/libavcodec.so* $libdir ln -s ${ffmpeg.out}/lib/libavformat.so* $libdir </del> <ins> ln -s ${ffmpeg.lib}/lib/libavcodec.so* $libdir ln -s ${ffmpeg.lib}/lib/libavformat.so* $libdir </ins> rpath="$out/share/spotify:$libdir"

]); RENPY_DEPS_INSTALL = lib.concatStringsSep "::" (map (path: path) [ <del> SDL2 SDL2.dev libpng ffmpeg.out freetype glew.dev libGLU libGL fribidi zlib </del> <ins> SDL2 SDL2.dev libpng ffmpeg.lib freetype glew.dev libGLU libGL fribidi zlib </ins> ]); enableParallelBuilding = true;
Change:
Steps to reproduce the behavior: opensnitch against nixos-unstable Probably related to the recent bump to gcc 12. Please run and paste the result.

Discussion:
openfortivpn = callPackage ../tools/networking/openfortivpn { }; <del> opensnitch = callPackage ../tools/networking/opensnitch/daemon.nix { }; </del> <ins> opensnitch = callPackage ../tools/networking/opensnitch/daemon.nix { # Build currently fails on Go > 1.18 # See https://github.com/evilsocket/opensnitch/issues/851 buildGoModule = buildGo118Module; }; </ins> opensnitch-ui = libsForQt5.callPackage ../tools/networking/opensnitch/ui.nix { };
Change:
After scanning an image in skanlite, the app crashes when trying to save the image. The error message is: Steps to reproduce the behavior: an image (either using a scanner or webcam) to save the image crashes A dialog should pop up to select the path to save the image. Using startx and qtile as the window manager I've submitted a PR to fix this issue (see ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --

Discussion:
{ mkDerivation, lib, <ins> wrapGAppsHook, </ins> extra-cmake-modules, kdoctools, kio, libksane }:

maintainers = with maintainers; [ polendri ]; }; <del> nativeBuildInputs = [ extra-cmake-modules kdoctools ]; </del> <ins> nativeBuildInputs = [ wrapGAppsHook extra-cmake-modules kdoctools ]; </ins> buildInputs = [ kio libksane ]; }
Change:
Vaultwarden is able to retrieve the latest version of the software but unable to determine its own version. This does however work for the web vault. Go to https://your-vaultwarden-instance/admin/diagnostics. !
This is due to vaultwarden getting it's version information from the env variable during build, which is somehow unset on Nixpkgs. It also causes the mobile clients to crash, as they depend on that information for feature detection, see Should be fixed in next vaultwarden release, but as a workaround you can use overrideAttrs to inject the variable:
Do you want to submit that workaround as a PR? I guess it won't be needed anymore to make mobile clients work but it would still fix the admin panel I assume?
Should be fixed in next vaultwarden release, but as a workaround you can use overrideAttrs to inject the variable: I still needed the workaround in nixos 23.11 with vaultwarden 1.30.1.

Discussion:
cargoHash = "sha256-K0T0uTERjxlI3bGG/Tz6sJ0A08J0ROAhpppdZcdQPB8="; <ins> # used for "Server Installed" version in admin panel env.VW_VERSION = version; </ins> nativeBuildInputs = [ pkg-config ]; buildInputs = with lib; [ openssl ] ++ optionals stdenv.isDarwin [ libiconv Security CoreServices SystemConfiguration ]
Change:
When trying to copy a file with extended attributes, the attributes don't get copied. When forcing to copy the attributes, it reports: The issue was probably introduced with multiple outputs support. Previously, would find libs&headers while building, propagated through . But now, only the libs propagate and not , so can't find the header and disables support. Not sure if coreutils should just list as a (when is) or if should somehow signal that its output should propagate too. System: Nix version: Nixpkgs version:
By default, the output should be propagated and it should propagate libs and some others in turn. I'll re-check all this later (if noone else is faster).
Hmm, as far as I can tell from the git logs, at least explicitly didn't propagate .
When I tested 16.03 it doesn't have xattr support there either. But anyway, enables it.
I'm pretty sure it used to work at some point, but it might have been a few years ago :) Thanks!

Discussion:
coreutilsMinimal = (pkgs.coreutils.override (args: { <del> # We want coreutils without ACL support. </del> <ins> # We want coreutils without ACL/attr support. </ins> aclSupport = false; <ins> attrSupport = false; </ins> # Our tooling currently can't handle scripts in bin/, only ELFs and symlinks. singleBinary = "symlinks"; })).crossDrv;

coreutilsMinimal = coreutils.override (args: { <del> # We want coreutils without ACL support. </del> <ins> # We want coreutils without ACL/attr support. </ins> aclSupport = false; <ins> attrSupport = false; </ins> # Our tooling currently can't handle scripts in bin/, only ELFs and symlinks. singleBinary = "symlinks"; });

{ lib, stdenv, fetchurl, perl, xz, gmp ? null , aclSupport ? false, acl ? null <ins> , attrSupport ? false, attr ? null </ins> , selinuxSupport? false, libselinux ? null, libsepol ? null , autoconf, automake114x, texinfo , withPrefix ? false

buildInputs = [ gmp ] ++ optional aclSupport acl <ins> ++ optional attrSupport attr </ins> ++ optionals stdenv.isCygwin [ autoconf automake114x texinfo ]   # due to patch ++ optionals selinuxSupport [ libselinux libsepol ]; crossAttrs = { buildInputs = [ gmp.crossDrv ] ++ optional aclSupport acl.crossDrv <ins> ++ optional attrSupport attr.crossDrv </ins> ++ optionals selinuxSupport [ libselinux.crossDrv libsepol.crossDrv ] ++ optional (stdenv.ccCross.libc ? libiconv) stdenv.ccCross.libc.libiconv.crossDrv;

makeFlags = optionalString stdenv.isDarwin "CFLAGS=-D_FORTIFY_SOURCE=0"; <del> postFixup = ""; # FIXME: remove on next mass rebuild </del> meta = { homepage = http://www.gnu.org/software/coreutils/; description = "The basic file, shell and text manipulation utilities of the GNU operating system";

coreutils = callPackage ../tools/misc/coreutils { aclSupport = stdenv.isLinux; <ins> attrSupport = stdenv.isLinux; </ins> }; coreutils-prefixed = coreutils.override { withPrefix = true; singleBinary = false; };
Change:
This version of CVXPY supports Python 3.7 through 3.11, and is our first release that supports Python 3.11. The update should fix it. See full build log with color in terminal: Steps to reproduce the behavior: successful building package nixpkgs master at See also this update PR: It works with python310. do you want to have a look? system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:

Discussion:
buildPythonPackage rec { pname = "cvxpy"; <del> version = "1.2.3"; </del> <ins> version = "1.3.0"; </ins> format = "pyproject"; disabled = pythonOlder "3.5"; src = fetchPypi { inherit pname version; <del> hash = "sha256-IaeUtv0vdgqddm1o++SUZTT2Xom3Pom4icVQOYVVi4Y="; </del> <ins> hash = "sha256-Zszme9xjW5spBmUQR0OSwM/A2V24rdpAENyM3Y4EYlA="; </ins> }; postPatch = ''
Change:
Project description kaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes cluster Metadata homepage URL: source URL: license: platforms: Linux
Please test. And provide feedback. You can use tool for that:
Next time you request something certify to follow up. Issue is now closed without you having tested it.
FYI you can do the following to build a container with kaniko in it. Use the kaniko executor on your host system (outside of containers) Note that you may need to build a container with kaniko/executor + credential helpers

Discussion:
<ins> { stdenv , lib , fetchFromGitHub , buildGoModule , installShellFiles , testers , kaniko }: buildGoModule rec { pname = "kaniko"; version = "1.9.1"; src = fetchFromGitHub { owner = "GoogleContainerTools"; repo = "kaniko"; rev = "v${version}"; hash = "sha256-sPICsDgkijQ7PyeTWQgT553toc4/rWPPo7SY3ptX82U="; }; vendorHash = null; ldflags = [ "-s" "-w" "-X github.com/GoogleContainerTools/kaniko/pkg/version.version=${version}" ]; nativeBuildInputs = [ installShellFiles ]; doCheck = false; # requires docker, container-diff (unpackaged yet) postInstall = lib.optionalString (stdenv.hostPlatform == stdenv.buildPlatform) '' for shell in bash fish zsh; do $out/bin/executor completion $shell > executor.$shell installShellCompletion executor.$shell done ''; passthru.tests.version = testers.testVersion { package = kaniko; version = version; command = "${kaniko}/bin/executor version"; }; meta = { description = "A tool to build container images from a Dockerfile, inside a container or Kubernetes cluster"; homepage = "https://github.com/GoogleContainerTools/kaniko"; license = lib.licenses.asl20; platforms = lib.platforms.unix; maintainers = [ lib.maintainers.superherointj ]; mainProgram = "executor"; }; } </ins>

kakoune-cr = callPackage ../tools/misc/kakoune-cr { crystal = crystal_1_2; }; <ins> kaniko = callPackage ../applications/networking/cluster/kaniko { }; </ins> katana = callPackage ../tools/security/katana { }; katriawm = callPackage ../applications/window-managers/katriawm { };
Change:
Steps to reproduce the behavior: or Still works around - but has been broken for at least 3 days in nixos-unstable Please run and paste the result.
Yup, here is the associated hydra build: Interestingly this looks like a compiler bug. It does build flawlessly with the and some OpenCL module seems to be responsible. If I disable the OpenCL support in OpenMM everything works fine also with gcc. Unfortunately I couldn't find any good candidate between and that would be obvious. Also does not work with older GCC versions (e.g. gcc9Stdenv), while it does on aarch64 as is. I will build all the commit between and and see which one breaks OpenMM. The worst case scenario would be disabling OpenCL for the moment.
OK, it is specifically that breaks it. Not too surprising, its the update from GCC 11 -GCC 12. The best fix for the moment seems to be to use the GCC 11 until OpenCL and vectorisation problems are resolved. Very much to my surprise (and all lower gccXStdenv versions) still give me the GCC 12. do you know why this does not work?
It seems to be connected to the Fortran compiler. This works:
Good catch - does it make sense to do a PR to fix it or investigate the failure upstream?
Nice that this works. Still I am surprised, as using without replacing the gfortran was enough. However, gfortran also seems to include gcc and g++ in PATH. For now I will make a nixpkgs PR with the gfortran11 and gcc11Stdenv to get it working here again. I will try to reproduce this on Debian with the GCC12 to see if this is purely a Nix problem or not.
This is probably a bug in the gfortran compiler wrappers? Pulling in gfortran should not override the c compiler from stdenv.
Hm, I am pretty the gfortran wrapper does. Simply doing gives me g++ and gcc. But I am afraid to touch anything involving the compiler wrappers in nixpkgs :sweat_smile: But this would explain something. The compilation error happens definitely in the cpp files, not in Fortran sources.
This even happens on Debian Sid with the GCC12 and OpenCL from the Debian repos. Thus, I would agree, this is probably an upstream bug. I am not sure whether this is a GCC bug or a OpenMM bug ... At least it also still happens on OpenMM's master branch.
The build failure with GCC 12 is certainly an upstream bug which, I assume, will be fixed sooner or later. However, the bug that gfortran overrides c compilers is most likely a problem on our end (probably in the compiler wrapper).
I am not sure about this one. clang and g++ < 12 works flawless and a vectorisation pass of g++ calls this an compiler bug itself.

Discussion:
open-policy-agent = callPackage ../development/tools/open-policy-agent { }; <del> openmm = callPackage ../development/libraries/science/chemistry/openmm { }; </del> <ins> openmm = callPackage ../development/libraries/science/chemistry/openmm { stdenv = if stdenv.targetPlatform.isAarch64 then gcc9Stdenv else gcc11Stdenv; gfortran = if stdenv.targetPlatform.isAarch64 then gfortran9 else gfortran11; }; </ins> openshift = callPackage ../applications/networking/cluster/openshift { };
Change:
Steps to reproduce the behavior: Breaks since it depends on <!-- 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.
Possibly running an outdated version of TBB. Current release is 2021.7.0, the version in unstable is 2020.3. Of course, this could be on purpose.
This is very likely fallout from (more precisely, commit ). See also (broken in a similar fashion) See the following Hydra failures: embree: openimagedenoise: FYI

Discussion:
cmakeFlags = [ "-DEMBREE_TUTORIALS=OFF" "-DEMBREE_RAY_MASK=ON" <ins> "-DTBB_ROOT=${tbb}" "-DTBB_INCLUDE_DIR=${tbb.dev}/include" </ins> ];

nativeBuildInputs = [ cmake python3 ispc ]; buildInputs = [ tbb ]; <ins> cmakeFlags = [ "-DTBB_ROOT=${tbb}" "-DTBB_INCLUDE_DIR=${tbb.dev}/include" ]; </ins> meta = with lib; { homepage = "https://openimagedenoise.github.io"; description = "High-Performance Denoising Library for Ray Tracing";
Change:
This also breaks the build of which relies on this package. () Please run and paste the result.
Are you using ihatemoney on unstable? I was considering dropping it as very often breaks with the new versions of its dependencies.
I wouldn't mind using ihatemoney from stable, but I'm using unstable by default on my system, and didn't manage to create a working overlay for overriding ihatemoney's version (a python-specific overlay is required, and then IIRC I got an error because ihatemoney is not a python module).
tbh I'm only maintaining it on stable. Overlaying all dependencies to make it work is time consuming so I'm only doing just before a release. If you want to have a try, here is how it can look like:

Discussion:
, mock , sqlalchemy , pytestCheckHook <ins> , pythonOlder </ins> }: buildPythonPackage rec { <del> pname = "Flask-SQLAlchemy"; version = "3.0.2"; </del> <ins> pname = "flask-sqlalchemy"; version = "3.0.3"; </ins> format = "pyproject"; <ins> disabled = pythonOlder "3.9"; </ins> src = fetchPypi { <del> inherit pname version; hash = "sha256-FhmfWz3ftp4N8vUq5Mdq7b/sgjRiNJ2rshobLgorZek="; </del> <ins> pname = "Flask-SQLAlchemy"; inherit version; hash = "sha256-J2QzXzydfr3J7WBEr6+Yqun6UNegdM71Xd4wfslZA+w="; </ins> }; nativeBuildInputs = [

"test_persist_selectable" ]; <ins> pythonImportsCheck = [ "flask_sqlalchemy" ]; </ins> meta = with lib; { description = "SQLAlchemy extension for Flask"; homepage = "http://flask-sqlalchemy.pocoo.org/"; <ins> changelog = "https://github.com/pallets-eco/flask-sqlalchemy/blob/${version}/CHANGES.rst"; </ins> license = licenses.bsd3; maintainers = with maintainers; [ gerschtli ]; };

psycopg2 pymysql pytestCheckHook <del> ] ++ passthru.optional-dependencies.flask ++ passthru.optional-dependencies.flask-login ++ passthru.optional-dependencies.flask-sqlalchemy ++ passthru.optional-dependencies.flexmock ++ passthru.optional-dependencies.i18n; </del> <ins> ] ++ lib.flatten (builtins.attrValues passthru.optional-dependencies); </ins> <del> # indicate tests that we don't have a database server at hand </del> <ins> # Indicate tests that we don't have a database server at hand </ins> DB = "sqlite"; <ins> disabledTestPaths = [ # Test doesn't support latest SQLAlchemy "tests/plugins/test_flask.py" ]; </ins> pythonImportsCheck = [ "sqlalchemy_continuum" ];