jiebi/CodeConvo huggingface dataset:
Change:
, fetchFromGitHub }: <del> buildNpmPackage rec { </del> <ins> buildNpmPackage { </ins> pname = "immich-cli"; <del> version = "0.41.0"; </del> <ins> version = "2.0.6"; </ins> src = fetchFromGitHub { owner = "immich-app"; <del> repo = "CLI"; rev = "v${version}"; hash = "sha256-BpJNssNTJZASH5VTgTNJ0ILj0XucWvyn3Y7hQdfCEGQ="; </del> <ins> repo = "immich"; # Using a fixed commit until upstream has release tags for cli. rev = "014adf175ad50a61f92804666940e267ab329064"; hash = "sha256-MK3Watq5/Zp+rymCIfWxAXSgBPDE13g23uDnW7A5x9g="; </ins> }; <del> npmDepsHash = "sha256-GOYWPRAzV59iaX32I42dOOEv1niLiDIPagzQ/QBBbKc="; </del> <ins> npmDepsHash = "sha256-ssxOXKE1t/bSb972w/cBeK61IrqPLmx9ODMn6D+2Ezw="; postPatch = '' cd cli ''; </ins> meta = { <del> changelog = "https://github.com/immich-app/CLI/releases/tag/${src.rev}"; </del> description = "CLI utilities for Immich to help upload images and videos"; <del> homepage = "https://github.com/immich-app/CLI"; </del> <ins> homepage = "https://github.com/immich-app/immich"; </ins> license = lib.licenses.mit; mainProgram = "immich"; <del> maintainers = with lib.maintainers; [ felschr ]; </del> <ins> maintainers = with lib.maintainers; [ felschr pineapplehunter ]; </ins> }; }

Discussion:
Package name: immich-cli Latest released version: 2.0.4 <!-- Search your package here: --- Current version on the unstable channel: 0.41.0 Current version on the stable/release channel: 0.41.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! --- has since been migrated from a (now archived) . I'm actually not entirely sure if this was a migration, or a new app from scratch, in which case perhaps the current package should be marked as legacy, and a new one created? 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:
pgbouncer = callPackage ../servers/sql/pgbouncer { }; <ins> pgcat = callPackage ../servers/sql/pgcat {}; </ins> pgpool = callPackage ../servers/sql/pgpool { }; tang = callPackage ../servers/tang {

Discussion:
Project description PostgreSQL pooler and proxy (like PgBouncer) with support for sharding, load balancing, failover and mirroring. Metadata homepage URL: source URL: license: mit platforms: unix
Change:
masterpdfeditor4 = libsForQt5.callPackage ../applications/misc/masterpdfeditor4 { }; <ins> foxitreader = libsForQt512.callPackage ../applications/misc/foxitreader { }; </ins> aeolus = callPackage ../applications/audio/aeolus { }; aewan = callPackage ../applications/editors/aewan { };

Discussion:
Project description Foxit Reader goes beyond a PDF viewer, it's ConnectedPDF Powered. ConnectedPDF is leading edge technology that powers cloud-based services for PDF files. The issue with this package is that it has a UI installer which makes it harder to package and the source is not open. Metadata homepage URL: source URL: license: platforms: unix, linux, darwin
Arch package for reference (though it seems rather old):
After viewing the archlinux package I came up with this bash script: But when I try to create a derivation with nix, for some reason breaks the loop. When I commented out the and '7z` command it iterates through the loop with no issues.
Change:
runHook postInstall ''; <ins> passthru.updateScript = unstableGitUpdater { }; </ins> meta = with lib; { description = "Kernel module that exposes the Framework Laptop (13, 16)'s battery charge limit and LEDs to userspace"; homepage = "https://github.com/DHowett/framework-laptop-kmod"; license = licenses.gpl2Only; maintainers = with maintainers; [ gaykitty ]; platforms = platforms.linux; <ins> broken = lib.versionOlder kernel.version "6.1"; </ins> }; }

Discussion:
Steps to reproduce the behavior: framework-laptop-kmod with linuxPackagestesting Wanted to try the 6.11 Kernel cause there is a bug fixed in 'crosec' module which pings in kde wrong battery state <!-- 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]:
The same problem is present in 6.11.0:
Seems to be fixed now. Awesome!
Change:
# python function with default python interpreter buildPythonPackage = pythonPackages.buildPythonPackage; <ins> buildPythonApplication = pythonPackages.buildPythonApplication; </ins> # `nix-env -i python-nose` installs for 2.7, the default python. # Therefore we do not recurse into attributes here, in contrast to

Discussion:
Most python packages seem to use a versioned prefix, e.g. python2.7-. Some modules don't, e.g. python-tkinter, python-pyaudio. I think all packages should use a versioned prefix (in contrast to apps, that should not use a prefix, see ). Having all packages use a versioned prefix we could also enable recursion for python2.6 and python3.2 though this might be a separate discussion.
This is still somewhat undocumented, packages in are versioned and others are not. I agree - all packages should be versioned and separatation should be based on app/module use case (which is also not always easy to determine)
Is this (mostly?) handled by the upcoming stuff?
Change:
rustPlatform.buildRustPackage rec { pname = "sqlx-cli"; <del> version = "0.5.5"; </del> <ins> version = "0.5.6"; </ins> src = fetchFromGitHub { owner = "launchbadge"; repo = "sqlx"; rev = "v${version}"; <del> sha256 = "1051vldajdbkcxvrw2cig201c4nm68cvvnr2yia9f2ysmr68x5rh"; </del> <ins> sha256 = "sha256-Ir9n2Z3+dKCe2GLrVLV1dnxeKKtPJk/kd5wbtsKHtbw="; </ins> }; <del> cargoSha256 = "1ry893gjrwb670v80ff61yb00jvf49yp6194gqrjvnyarjc6bbb1"; </del> <ins> cargoSha256 = "sha256-MfLxzulcQSEcNGmer8m2ph2+lK2M3MN1PwAHDGzn3NQ="; </ins> doCheck = false; cargoBuildFlags = [ "-p sqlx-cli" ];

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 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: sqlx-cli <!-- The current version can be found easily with the same process than 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.5.5 desired version: 0.5.6 <!-- 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:
}: let <del> config_ = config; in let </del> inherit (lib) hasAttr getAttr optional optionals optionalString optionalAttrs maintainers platforms;

Discussion:
Building powerpc kernels (I only tested pkgsCross.powernv, but examination of the kernel source code suggests to me that 32-bit powerpc, and well as big-endian 64-bit will be the same) is broken since This happens because on powerpc, the kernel target we install is vmlinux, rather than any derivative of it like zImage. The kernel build system will strip when creating such a derivative image, but because we install vmlinux directly, we get an unstripped image. This means the kernel contains references to its build directory, which since that PR will be the $dev output. AIUI, 64-bit POWER boots via kexec, and a zImage is a self-extracting kernel ELF image, so hopefully the fix would just be to switch the kernel target for powerpc to zImage, and things will work again, and POWER users will get smaller kernel images as a bonus. I'm not sure about 32-bit PowerPC, but this might be helpful. If we can't use an *Image target for any powerpc targets, there is also a target called that we could fall back to, but let's take the opportunity to evaluate whether anything else is more suitable first, when we're changing this stuff anyway. Apart from powerpc, the only we have that uses vmlinux as its kernel target is a MIPS machine called the Fuloong 2.0. I don't know how it boots.
I'll handle this. I don't have big-endian POWER hardware, but pointed out that qemu can probably boot a BE kernel under emulation at full hardware speeds. So if that works I can take care of the 32-bit POWER (which is mostly BE) too.
For reference, I managed to get a working kernel derivation for Power9 with Just setting building a zImage without fully stripping it afterwards wasn't enough. There still was a reference to in the debug info somewhere.
Yep, very plausible that there are other references as well. We had for x86 and RISC-V, although that specific issue didn't apply to other architectures.
I'll dig into this this evening. thank you for the tip! Also putting this link here so I don't lose it:
Verified (after fixing a bunch of other things) that is affected too. Thanks again for the heads up Working on a fix.
Edit: I meant to post this .
Fixed by
Change:
dontDisableStatic = stdenv.buildPlatform != stdenv.hostPlatform; <ins> postInstall = '' ln -s $out/bin/flex $out/bin/lex ''; </ins> meta = with lib; { homepage = "https://github.com/westes/flex"; description = "A fast lexical analyser generator";

Discussion:
On most linux distributions, is provided by the package as a symlink to . This is not the case on NixOS, which makes building some software that expects a binary difficult. NixOS should change the package to provide in addition to the and that it currently provides.
Here are several instances of people running into this problem on IRC: ; ; ;
Closing since it sounds like it should've closed when merged. Happy to reopen if I'm mistaken.
Change:
buildPythonPackage rec { pname = "google-auth-oauthlib"; <del> version = "1.1.0"; format = "setuptools"; </del> <ins> version = "1.2.0"; pyproject = true; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> hash = "sha256-g+qMOwiB5FN5C6/0RI6KYRKsh3jR3p2gtoAQuEOTevs="; </del> <ins> hash = "sha256-KS0tN4M0nysHNKCgIHseHjIqwZPCwJ2PfGE/t8xQHqg="; </ins> }; <ins> nativeBuildInputs = [ setuptools ]; </ins> propagatedBuildInputs = [ google-auth requests-oauthlib ]; <ins> passthru.optional-dependencies = { tool = [ click ]; }; </ins> nativeCheckInputs = [ <del> click </del> mock pytestCheckHook <del> ]; </del> <ins> ] ++ passthru.optional-dependencies.tool; </ins> disabledTests = lib.optionals stdenv.isDarwin [ # This test fails if the hostname is not associated with an IP (e.g., in `/etc/hosts`).

Discussion:
Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.21.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 <!-- 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]:
Change:
(enableFeature (experimentalSpatialSvcSupport || experimentalFpMbStatsSupport || experimentalEmulateHardwareSupport) "experimental") <del> ] ++ optionals (stdenv.isBSD || stdenv.hostPlatform != stdenv.buildPlatform) [ "--force-target=${stdenv.hostPlatform.parsed.cpu.name}-${kernel}-gcc" </del> <ins> ] ++ optionals (target != null) [ "--target=${target}" </ins> (lib.optionalString stdenv.hostPlatform.isCygwin "--enable-static-msvcrt") ] # Experimental features ++ optional experimentalSpatialSvcSupport "--enable-spatial-svc"

Discussion:
Steps to reproduce the behavior: sure that the system is set up for cross-compiling (extra-platforms). The following patch fixes the cross-build I am looking for (but it might break other builds, I don't know): Issue seems to be that the configure script of libvpx does not know the target (as a result, we need to force it), which results in a mess. By using instead of , the target is understood and everything works for me. Please run and paste the result.
I'm experiencing this issue as well, I'll test your patch in ExpidusOS and I'll reply back with whether or not it works.
After applying your patch, I wasn't able to build it. I'm going to look into what wants it to be so it could compile.
I was able to successfully cross compile , I'll work on bundling into a PR later.
still an issue, and it seems like the fix for armv7l really is as simple as described in this bug report (i.e. change the target flag from "armv7l-linux-gcc" to "armv7-linux-gcc"). if you get a chance to upstream that patch, i'd be happy to test it for cross aarch64-multiplatform and armv7l-hf-multiplatform.
Done. Fixed by .
Change:
<ins> { lib , stdenv , fetchFromGitHub , substituteAll , python3 , installShellFiles , makeWrapper , wrapQtAppsHook , advancecomp , jpegoptim , optipng , pngcrush }: let pythonEnv = python3.withPackages (ps: with ps; [ pyqt5 ]); binPath = lib.makeBinPath [ advancecomp jpegoptim optipng pngcrush ]; in stdenv.mkDerivation { pname = "trimage"; version = "1.0.7-dev"; src = fetchFromGitHub { owner = "Kilian"; repo = "Trimage"; rev = "ad74684272a31eee6af289cc59fd90fd962d2806"; hash = "sha256-jdcGGTqr3f3Xnp6thYmASQYiZh9nagLUTmlFnJ5Hqmc="; }; nativeBuildInputs = [ installShellFiles makeWrapper wrapQtAppsHook ]; dontWrapQtApps = true; installPhase = '' runHook preInstall mkdir $out cp -R trimage $out installManPage doc/trimage.1 install -Dm444 desktop/trimage.desktop -t $out/share/applications install -Dm444 desktop/trimage.svg -t $out/share/icons/hicolor/scalable/apps makeWrapper ${pythonEnv}/bin/python $out/bin/trimage  --add-flags "$out/trimage/trimage.py"  --prefix PATH : ${binPath}  "''${qtWrapperArgs[@]}" runHook postInstall ''; meta = { description = "A cross-platform tool for optimizing PNG and JPG files"; homepage = "https://github.com/Kilian/Trimage"; license = lib.licenses.mit; mainProgram = "trimage"; maintainers = with lib.maintainers; [ tomasajt ]; }; } </ins>

Discussion:
Project description A cross-platform tool for optimizing PNG and JPG files. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
Change:
hash = "sha256-RM6QM/iR00ymg0FBUtaWAtxPHIX4u9U/t5N/UT/T6sc="; }; <ins> patches = [ # replace use of imp module for Python 3.12 # https://github.com/xmendez/wfuzz/pull/365 (fetchpatch2 { url = "https://github.com/xmendez/wfuzz/commit/f4c028b9ada4c36dabf3bc752f69f6ddc110920f.patch?full_index=1"; hash = "sha256-t7pUMcdFmwAsGUNBRdZr+Jje/yR0yzeGIgeYNEq4hFE="; }) ]; </ins> postPatch = '' substituteInPlace setup.py  --replace "pyparsing>=2.4*" "pyparsing>=2.4" <ins> # fix distutils use for Python 3.12 substituteInPlace src/wfuzz/plugin_api/base.py  --replace-fail "from distutils import util" "from setuptools._distutils import util" </ins> ''; propagatedBuildInputs = [

Discussion:
wfuzz installation returns the following error: Steps to reproduce the behavior: <!-- 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]:
There is PR upstream that supposedly fixes compatibility with python 3.12 (removed imp module): so it may be as simple as getting that patch into nixpkgs
Change:
stdenv.mkDerivation (finalAttrs: { pname = "gdm"; <del> version = "46.0"; </del> <ins> version = "46.2"; </ins> outputs = [ "out" "dev" ]; src = fetchurl { url = "mirror://gnome/sources/gdm/${lib.versions.major finalAttrs.version}/${finalAttrs.pname}-${finalAttrs.version}.tar.xz"; <del> hash = "sha256-jWy1IXbspItrvxz+L9rgjZZ3taDyvKYA3uRgTeDdHvw="; </del> <ins> hash = "sha256-TuNFQioWU3FQzYQkUM2lKyyoaYS8Ue4gzcAl3PS9Jos="; </ins> }; mesonFlags = [

Discussion:
Package name: Latest released version: 46.0 <!-- Search your package here: --- Current version on the unstable channel: 46.0 Current version on the stable/release channel: 46.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 <!-- 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]: Fixes very annoying bug for users with nvidia dGPU notebooks on gnome using external displays. Reports of the Bug:
Change:
stdenv.mkDerivation rec { pname = "libnbd"; <del> version = "1.7.5"; </del> <ins> version = "1.7.7"; </ins> src = fetchurl { url = "https://download.libguestfs.org/libnbd/${lib.versions.majorMinor version}-development/${pname}-${version}.tar.gz"; <del> sha256 = "sha256-UxQx/wnKnCB3uC9xEfq1F0l3kHAJjp9GzbeRugKyFsk="; </del> <ins> hash = "sha256-fNeu1qx+EbKitv2I8nJAmGMF5jxN2RZGPR/LJYnOjG8="; </ins> }; nativeBuildInputs = [

Discussion:
, CVSSv3=2.7 (nixos-unstable) Scanned versions: nixos-unstable: . Cc

, CVSSv3=5.5 (nixos-unstable) Scanned versions: nixos-unstable: . Cc
Change:
]; executableToolDepends = [ emacs ]; postInstall = '' <del> $out/bin/agda -c --no-main $(find $out/share -name Primitive.agda) </del> <ins> # Separate loops to avoid internal error files=($out/share/*-ghc-*/Agda-*/lib/prim/Agda/{Primitive.agda,Builtin/*.agda}) for f in "''${files[@]}" do $out/bin/agda $f done for f in "''${files[@]}" do $out/bin/agda -c --no-main $f done </ins> $out/bin/agda-mode compile ''; homepage = "http://wiki.portal.chalmers.se/agda/"; description = "A dependently typed functional programming language and proof assistant"; license = "unknown"; <del> maintainers = with stdenv.lib.maintainers; [ abbradar ]; </del> <ins> maintainers = with stdenv.lib.maintainers; [ abbradar mudri ]; </ins> }) {inherit (pkgs) emacs;}; "Agda-executable" = callPackage

Discussion:
As of Agda 2.5.1 (which comes on the latest nixos-unstable release), both nixpkgs' agda-stdlib (from git nominally at version 2.4.2.3) and an updated version (v0.12, the most recent release) fail to build. Some modules are checked successfully, but it gets stuck at (the first builtin module it finds). For this module only, it tries to write to . Output: System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: ""
has the same issue, meaning that there has probably been some change in Agda. The problem seems to be that writes a file for each file it checks, and some files it's checking are in the Nix store (specifically, in ). I think it's to do with . Maybe it would work if these were checked when building .
Current status: .
Fixed by .
Let's keep this open until the fix lands in master.
Change:
ruby_2_5_0 = throw "ruby_2_5_0 was deprecated on 2018-02-13: use a newer version of ruby"; rubyPackages_2_4 = throw "rubyPackages_2_4 was deprecated in 2019-12: use a newer version of rubyPackages instead"; rubygems = throw "rubygems was deprecated on 2016-03-02: rubygems is now bundled with ruby"; <ins> rubyMinimal = throw "rubyMinimal was removed due to being unused"; </ins> rxvt_unicode-with-plugins = rxvt-unicode; # added 2020-02-02 rxvt_unicode = rxvt-unicode-unwrapped; # added 2020-02-02 urxvt_autocomplete_all_the_things = rxvt-unicode-plugins.autocomplete-all-the-things; # added 2020-02-02

Discussion:
Describe the bug I'm hunting down packages that reference gcc. One of them is (maintainers: & ). Here's why: The fault is the fact that the build flag doesn't remove all references, as one might expect (EDIT, see: ). I'm up to including this feature, but I was wondering perhaps it'd be legit to disable this feature for the derivation? I opened a PR at (EDIT).
But that would mean gems that require a compiler would no longer work.
The suggestion is for , not . Isn't the derivation that's used to build the gems? According to:
It still has support for gems, so some will fail with gcc. What exactly is the use case for ?
Technically it's not used anywhere, according to .
I'd like to make my - with an overlay. The goal is to make the 1 or 2 pure ruby scripts I have on my system not pull , as they do today.
But what is the reason? You're likely to have a version of ruby that includes gcc on your system anyway, so you don't really save any space. And the use-case would be plain ruby scripts with only the gems that don't require system libraries. We have no users in nixpkgs of presumably because it's rather pointless. And while of course we can strip gcc from rubyMinimal (there's no harm), I'd rather say drop instead.
Not If I'll apply and this overlay: This allows me to not need GCC for for example - which is the only ruby gem I use. For example, run with this PR and that overlay applied: And you should get: And without , (and without the overlay because it would fail) you should get: is the only derivation that needs ruby that I actually use. I've updated the 1st comment in to exemplify this overlay as a possible usecase. Well I tend to agree - even for asciidoctor which should be pretty much a pure ruby gem, it still required and which aren't enabled in current . Hence I tend to agree. OK so I've updated to include a drop to , including release notes and an alias. Waiting for your review :crossed_fingers: .
This issue has been mentioned on NixOS Discourse. There might be relevant details there: