jiebi/CodeConvo huggingface dataset:
Change:
# perf refers both to newt and slang # binutils is required for libbfd. nativeBuildInputs = [ asciidoc xmlto docbook_xsl docbook_xml_dtd_45 libxslt flex bison ]; <del> buildInputs = [ elfutils python perl newt slang pkgconfig libunwind binutils ] ++ </del> <ins> buildInputs = [ python perl newt slang pkgconfig libunwind binutils ] ++ </ins> stdenv.lib.optional withGtk gtk; <del> NIX_CFLAGS_COMPILE = "-Wno-error=cpp"; </del> <ins> # Note: we don't add elfutils to buildInputs, since it provides a # bad `ld' and other stuff. NIX_CFLAGS_COMPILE = "-I${elfutils}/include -Wno-error=cpp"; NIX_CFLAGS_LINK = "-L${elfutils}/lib"; </ins> installFlags = "install install-man ASCIIDOC8=1";

Discussion:
I am failing to install on right now: What more details should I provide?
perf fails on kernel 4.1 and 4.2 only
for an (arguably hacky) fix.
Change:
<del> { stdenv, lib, fetchFromGitHub, pkg-config, python3, autoreconfHook , libuuid, sqlite, glib, libevent, libsearpc, openssl, fuse, libarchive, which , vala, cmake, oniguruma, nixosTests }: </del> <ins> { stdenv , lib , fetchFromGitHub , pkg-config , python3 , autoreconfHook , libuuid , sqlite , glib , libevent , libsearpc , openssl , fuse , libarchive , libjwt , curl , which , vala , cmake , oniguruma , nixosTests }: </ins> let # seafile-server relies on a specific version of libevhtp.

Discussion:
I upgraded to NixOS 23.11 from 23.05 and I didn't touch seafile configuration files. Now Seahub doesn't start anymore. Steps to reproduce the behavior: to NixOS 23.11 fails Seahub should start normally, the same as NixOS 23.05. <!-- 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]:
After searching more about this issue, I found , which should solve this once merged.
Change:
}: let <del> date = "20180220"; rev = "47849be3a900c546cf92066849be0806f4e611d9"; </del> <ins> date = "20190310"; rev = "b6ffe28a21c53a0946d95751c905d9e0b6c3b630"; </ins> in stdenv.mkDerivation {

Discussion:
We use ipxe based on clever's setup () like this: This causes the following build failure on 19.03: Googling around for "Unrecognised relocation type 4" and ipxe returns , indicating it's fixed upstream (it is, I have a PR coming). See the override above system: host os: multi-user?: sandbox: version: channels(root): channels(atu): nixpkgs:
Change:
}) ]; <del> nativeBuildInputs = [ cmake extra-cmake-modules pkg-config python3Packages.sip makeWrapper ]; </del> <ins> nativeBuildInputs = [ cmake extra-cmake-modules pkg-config python3Packages.sip ]; </ins> buildInputs = [ karchive kconfig kwidgetsaddons kcompletion kcoreaddons kguiaddons

Discussion:
Krita 5 complains that it cannot find the G'Mic plugin. Steps to reproduce the behavior: Krita and the G'Mic plugin by adding and to in Krita a new image the menu item Filter→Start G'MIC-Qt will complain, via a modal dialog, that it cannot load the plugin. the menu item Settings→Configure Krita… should be a "G’Mic plugin" section in the left-hand sidebar, but there is not. For there to be a Krita setting to specify the path to the G'Mic plugin. The explains the correct behaviour.
Starting from the package won't work with Krita. Krita team forked and Krita will only work with that fork: It would take some effort to implement the build process mentioned in the README since cmake and make need to be invoked multiple times. (Probably need to manually write the whole and )
Is it possible to maintain a separate krita-gmic package like arch linux does?
It is possible but making it a separate package probably wouldn't make it easier to implement. We just need someone to implement the build process I linked above in nix (sorry I don't have time to do it)
Making some minor changes to you can build the krita plugin: I've not yet been able to have krita load the plugin though. I've tried creating a symlinkJoin'ed version with the plugin, that does not work :confused: Krita is not logging enough information about where it tried to load the plugin for me to be able to deduce what is going wrong.
Do you think the Krita fork of gmic-qt should be integrated in the definition at ? I was originally afraid modifying it now would not be worth it because the two versions might deviate too much from one another.
If you want to remove the original gmic-qt and change it to krita's fork, I believe it will conflict with the previous one, and I would therefore vote against it If you want to keep the fork along with the original, it's fine! You can use overrideAttrs magic in order to reuse the previous expression. Look at as an example for inspiration.
Option 1 is terrible, I'd never ask for that :smiley:.

I was asking if krita's gmic-qt should be included as a "variant" in , effectively does the same as option 2 <details<summaryLike this</summary</detailsI think it's best to keep it as a completely separate package, because both packages will never have matching versions.
So close! I got the "Q'MIC-qt for Krita" window to open by manipulating : ! Unfortunately it segfaults the moment I try to use any of the filters: Progress at
Change:
''; downloadPage = "https://github.com/flyway/flyway"; homepage = "https://flywaydb.org/"; <ins> changelog = "https://documentation.red-gate.com/fd/release-notes-for-flyway-engine-179732572.html"; </ins> sourceProvenance = with sourceTypes; [ binaryBytecode ]; license = licenses.asl20; platforms = platforms.unix; maintainers = [ maintainers.cmcdragonkai ]; }; <del> } </del> <ins> }) </ins>

Discussion:
The application has been broken since version 9.21.0. The previous and last working version was 9.18.0 (). Steps to reproduce the behavior: Simply call , and you will be greeted with the error message: . For the current version (9.21.2) run: Full output: To get the correct version output of <!-- 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.
Thank you for the extremely quick response! :o Sorry that I didn't catch that a couple of files weren't correctly copied :facepalm: Do you have a buymeacoffe link or similar? :hugs:
Change:
inherit (cudaPackages) cudatoolkit cudnn cutensor nccl; in buildPythonPackage rec { pname = "cupy"; <del> version = "11.1.0"; </del> <ins> version = "11.2.0"; </ins> disabled = !isPy3k; src = fetchPypi { inherit pname version; <del> sha256 = "sha256-4TtvmQrd172HCQWvQp+tUQhNCFf4YA3TIGod9aRoTt0="; </del> <ins> sha256 = "sha256-wzNh8RejR6Y/aZbql0RtF/HAOPGh9TPlAkZCNQdpI+I="; </ins> }; # See https://docs.cupy.dev/en/v10.2.0/reference/environment.html. Seting both

Discussion:
From what I could tell this was only mentioned in some comment of a closed PR. This is blocking me from wrapping up a flake for Invoke AI (a Stable Diffusion webui). Any help/advice would be appreciated. This was described on Discourse by :
What commit of nixpkgs are you using? I might have some cycles this weekend to spend on this.
Looks like the cause is an outdated version of cutensor. It appears cupy is the only dependent of that so hopefully an upgrade is simple. I am working on a patch now.
Change:
<ins> { lib , fetchPypi , fetchpatch , buildPythonPackage , setuptools-scm , attrs , packaging , pyparsing , semantic-version , semver , commoncode , pytestCheckHook , saneyaml }: buildPythonPackage rec { pname = "univers"; version = "30.7.0"; src = fetchPypi { inherit pname version; sha256 = "sha256-yM0SDBpkiZEbaZ0ugjiMwwUFKqZGbmh1JNlv5qvPAYo="; }; patches = [ # Make tests work when not using virtualenv, can be dropped with the next version # Upstream PR (already merged): https://github.com/nexB/univers/pull/77 (fetchpatch { url = "https://github.com/nexB/univers/commit/b74229cc1c8790287633cd7220d6b2e97c508302.patch"; sha256 = "sha256-i6zWv9rAlwCMghd9g5FP6WIQLLDLYvp+6qJ1E7nfTSY="; }) ]; nativeBuildInputs = [ setuptools-scm ]; propagatedBuildInputs = [ attrs packaging pyparsing semantic-version semver ]; checkInputs = [ commoncode pytestCheckHook saneyaml ]; dontConfigure = true; # ./configure tries to setup virtualenv and downloads dependencies disabledTests = [ "test_codestyle" ]; pythonImportsCheck = [ "univers" ]; meta = with lib; { description = "Library for parsing version ranges and expressions"; homepage = "https://github.com/nexB/univers"; license = with licenses; [ asl20 bsd3 mit ]; maintainers = with maintainers; [ armijnhemel sbruder ]; }; } </ins>

Discussion:
Project description Python project to parse and compare package versions and ranges. Metadata homepage URL: source URL: license: Apache-2.0 platforms: linux
Change:
hash = "sha256-+F+PHAd1+FmdAlQkjYDBsUYCUzKXG19ZUEorfvBUEg0="; }; <del> nativeBuildInputs = [ gradle jdk imagemagick makeWrapper copyDesktopItems ] ++ lib.optionals stdenv.hostPlatform.isDarwin [ desktopToDarwinBundle ]; </del> <ins> nativeBuildInputs = [ gradle jdk imagemagick makeWrapper copyDesktopItems ] ++ lib.optionals stdenv.hostPlatform.isDarwin [ desktopToDarwinBundle ]; </ins> # Otherwise, Gradle fails with `java.net.SocketException: Operation not permitted` __darwinAllowLocalNetworking = true;

Discussion:
Package name: jadx Latest released version: 1.5.0 Current version on the unstable channel: 1.4.7 Current version on the stable/release channel: 1.4.7 <!-- 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 affects 1.4.7 - I would generally bump this myself but the packaging appears to have quirks that look like they need adaptation. 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:
inherit ruby; name = "${gemName}-${version}"; gemName = "tmuxinator"; <del> version = "3.0.1"; source.sha256 = "1vm96iyzbcy1388b3zyqivfhs4p63v87mp5qwlr4s8i2haq62xyf"; </del> <ins> version = "3.0.5"; source.sha256 = "1ycsx9mvl0jsds4igi6avxclsyl5lndh1mpj2ykvzfz26wdddg6p"; </ins> erubis = buildRubyGem rec { inherit ruby;

Discussion:
name: tmuxinator current version: 3.0.1 desired version: 3.0.5 (latest) maintainers: Please tag this issue in your PR.
This looks simple enough for me to have a go at doing it.
Change:
, curl , gimp ? null , gmic <del> , cimg </del> , qtbase , qttools , writeShellScript

Discussion:
We broke gmic-qt during the bump. After contacting upstream, it seems like the cmake build is not maintained anymore: They migrated to . We should align with them and rewrite a qmake derivation for gmic-qt. Edit: jtojnar advise not to migrate to qmake but instead fix the cmake issue.
Any idea what I can do so I can build my system while this is a WIP?
Install the build from an older version of nixpkgs where the package you want still builds properly. The version in branch should be building properly. For Flakes: For Non-Flake:
Thank you so much!! That section of the wiki described exactly what I was trying to do!
I just posted an upstream PR to fix this:
I've opened with a proper fix if anyone here would like to do some testing (it works for me now)

Steps to reproduce the behavior: Full log: Package built successfully in . Package failed in . I assume package failed to built somewhere in between these two pull request. Please run and paste the result.
Possibly needs update like
tried but had a compilation issue: Error:
Change:
<ins> { lib , buildPythonPackage , fetchFromGitHub , graphviz , stdlib-list , pytestCheckHook , pythonOlder , pyyaml }: buildPythonPackage rec { pname = "pydeps"; version = "1.10.17"; format = "setuptools"; disabled = pythonOlder "3.7"; src = fetchFromGitHub { owner = "thebjorn"; repo = pname; rev = "v${version}"; hash = "sha256-V0LgHFvGvJqDHmyXJNb0sJjRuqGGDZpV467XDmdFg5k="; }; buildInputs = [ graphviz ]; propagatedBuildInputs = [ graphviz stdlib-list ]; checkInputs = [ pytestCheckHook pyyaml ]; postPatch = '' # Path is hard-coded substituteInPlace pydeps/dot.py  --replace "dot -Gstart=1" "${lib.makeBinPath [ graphviz ]}/dot -Gstart=1" ''; disabledTests = [ # Would require to have additional modules available "test_find_package_names" ]; pythonImportsCheck = [ "pydeps" ]; meta = with lib; { description = "Python module dependency visualization"; homepage = "https://github.com/thebjorn/pydeps"; license = licenses.bsd2; maintainers = with maintainers; [ fab ]; }; } </ins>

Discussion:
Project description Python module dependency visualization. Given a python project it can produce a graph of the dependencies, exported in the graphviz dot language.  Metadata homepage URL: source URL: license: bsd2 platforms: unix
Change:
makeWrapper, python3, nix, <ins> nix-prefetch-git, </ins> }: <ins> let binPath = lib.makeBinPath [ nix nix-prefetch-git ]; in </ins> runCommand "dub-to-nix" { nativeBuildInputs = [ makeWrapper ];

Discussion:
fails to build a lockfile with dependencies in the format (). Here's the error: any repository whose contains a dependency that fetches from Git, e.g. , e.g. . a few moments, then see error. A generated lockfile containing the Git dependency. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for reporting this bug, I'll try to extend the lockfile logic later today, (the current one is pretty primitive, as you might have seen)
Change:
buildGoModule rec { pname = "symfony-cli"; <del> version = "5.5.6"; vendorHash = "sha256-AfgDsd4W8wV0GeymD9SLeHtOeFP9qbFy+GTdMxQSkDA="; </del> <ins> version = "5.5.7"; vendorHash = "sha256-OXV/hTSHJvYfe2SiFamkedC01J/DOgd8I60yIpQToos="; </ins> src = fetchFromGitHub { owner = "symfony-cli"; repo = "symfony-cli"; rev = "v${version}"; <del> sha256 = "sha256-lE8RBjBXucL0DJjEnBLbHqOVE6g358rwmaEUqU6QhOw="; </del> <ins> hash = "sha256-LC6QQIVHllBRu8B6XfV8SuTB3O+FmqYr+LQnVmLj2nU="; </ins> }; ldflags = [

Discussion:
Given you have PHP installed on your host and one installed in your Nix shell + symfony-cli, eg. with these packages , running will always prefer PHP installed by host. This is not an issue with Nix per se but symfony-cli, but I suggest here that symfony-cli package should be patched so that this does not happen. Steps to reproduce the behavior: Terminal 1 terminal 2 Curl statement should return PHP/8.2.5, as that's the one installed by Nix. Not 8.1.2. Current workaround is replacing symfony-cli with which strips out everything {php}/bin Please run and paste the result.
That does not make sense. Why does Symfony not use the correct PHP from PATH? I would expect any proper PATH respecting program to return the same thing as .
I agree after making a couple of tests, I believe that wrapping the binary with the PHP path is not necessary... Check the screenshot in
I don't know, but this is what they use for discovery of php versions I've not dig depeer than having a brief looks though. And I have to remind that this is about command. command does look to be honoring $PATH correctly.
Does this means that does not employ the same mechanism for locating in the and commands? which seems totally uncommon. It would be nice to have the confirmation from one of the maintainers ( ?)
I've prepared a patch at I hope they will merge it soon. Otherwise we should consider adding a patch for this here.
I think this issue can be closed now.
Yup, thanks again!
After thinking twice, the issue will be definitely fixed as soon as you publish a new tag and we provide an update in Nix, I'll leave it open in the meantime.
7 has been released now.
PR is made, I'll wait for the CI to be done before merging and closing this issue.
Change:
homepage = "https://github.com/pauldmccarthy/indexed_gzip"; license = licenses.zlib; maintainers = with lib.maintainers; [ mxmlnkn ]; <del> platforms = platforms.all; </del> }; }

Discussion:
Steps to reproduce the behavior: python3Packages.ratarmountcore This first occurs after updates to and itself. The failure is not actually in a test, and occurs after the tests run. This indicates that some difference in the way the derivation is executing tests compared to upstream's CI is causing the error. Please run and paste the result. Not relevant; the log is on Hydra. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems that only the rapidgzip backend got updated but not ratarmountcore. Either downgrade rapidgzip or update ratarmountcore to 0.6.3 if possible. I'll have to see to get the latter update merged, it seems the auto-update bot does not work for ratarmountcore. This should fix the and output. I have no idea about the last 2 error lines. I cannot reproduce it with nix 2.16.1 on Ubuntu. The command runs fine:
Change:
in stringAfter [ "users" ] '' if [ -e ${lingerDir} ] ; then cd ${lingerDir} <ins> for user in ${lingerDir}/*; do if ! id "$user" >/dev/null 2>&1; then rm --force -- "$user" fi done </ins> ls ${lingerDir} | sort | comm -3 -1 ${lingeringUsersFile} - | xargs -r ${pkgs.systemd}/bin/loginctl disable-linger ls ${lingerDir} | sort | comm -3 -2 ${lingeringUsersFile} - | xargs -r ${pkgs.systemd}/bin/loginctl  enable-linger fi

Discussion:
nixpkgs input: cc
since this is broken to a degree that it puts a system in a state where it cannot be updated if any user is removed and no one has addressed this in the two months since i brought it up i think it might be a good idea to simply revert the PR - any thoughts on that?
Can we fix this with a three line change or not? Can we check if the user exists in and then skip the disable? If the fix is not trivial, we should at least mark it properly.
Wouldn't a quick and acceptable fix be to not fail when disabling lingering fails because the user doesn't exist, and still clean up the dangling linger file? It does seem like a preferable fix to wholesale reverting this, and one that should hopefully be relatively minor.
great so is someone able to take this on?
This is hopefully a quick fix, but I don't have the brainwidth right now to implement and properly test it, and likely won't until sometime next week at the earliest. I know there's been some work on a more comprehensive overhaul over in ; I don't know what that's waiting for to be mergeable, but unless it's ready to go now, my preference would be to simply roll back to stop causing problems for people, then roll forward with that change later.
- thanks for the reply, i appreciate just hearing back from you on the issue - don't worry about scheduling, if you're busy you're busy :heart: if anyone has capacity to look at this, awesome, and if not i'll see what i can do... but i also would take me a few weeks to get around to this i appreciate that there is engagement in this thread, thanks everyone!
I think I can fix this if I understand it correctly, which is that it is failing to disable linger for a user that no longer exists on the system.
that's correct i recently had to remove a user from a number of systems and if i recall correctly the systems in which the user had logged into, thereby activating lingering, would no longer activate until the lingering file under had been removed i would greatly appreciate if you fixed this thank you!
I've opened to fix this.
thank you so much everyone!
Change:
githubId = 7435854; name = "Victor Calvert"; }; <ins> cameronfyfe = { email = "cameron.j.fyfe@gmail.com"; github = "cameronfyfe"; githubId = 21013281; name = "Cameron Fyfe"; }; </ins> cameronnemo = { email = "cnemo@tutanota.com"; github = "cameronnemo";

Discussion:
Project description is a command output timestamper similar to in moreutils. Primary advantages over are the non-conflicting command name and its handling of progress bars. See "Comparison to moreutils ts" section in source repo for more complete comparison. Metadata homepage URL: source URL: license: mit platforms: linux, darwin
Change:
<del> { stdenv, kmod, modules, buildEnv }: </del> <ins> { stdenv, kmod, modules, buildEnv, name ? "kernel-modules" }: </ins> buildEnv { <del> name = "kernel-modules"; </del> <ins> inherit name; </ins> paths = modules;

Discussion:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.
Change:
stdenv.mkDerivation rec { pname = "brlcad"; <del> version = "7.34.2"; </del> <ins> version = "7.38.2"; </ins> src = fetchFromGitHub { owner = "BRL-CAD"; <del> repo = pname; </del> <ins> repo = "brlcad"; </ins> rev = "refs/tags/rel-${lib.replaceStrings [ "." ] [ "-" ] version}"; <del> hash = "sha256-oafu255xElEIk8p4yvNyR2maykUfxQui/L5MkicA+JA="; </del> <ins> hash = "sha256-23UTeH4gY2x/QGYZ64glAkf6LmsXBAppIOHgoUdxgpo="; </ins> }; <ins> patches = [ # This commit was bringing an impurity in the rpath resulting in: # RPATH of binary /nix/store/rq2hjvfgq2nvh5zxch51ij34rqqdpark-brlcad-7.38.0/bin/tclsh contains a forbidden reference to /build/ (fetchpatch { url = "https://github.com/BRL-CAD/brlcad/commit/fbdbf042b2db4c7d46839a17bbf4985cdb81f0ae.patch"; revert = true; hash = "sha256-Wfihd7TLkE8aOpLdDtYmhhd7nZijiVGh1nbUjWr/BjQ="; }) ]; </ins> nativeBuildInputs = [ cmake ];

Discussion:
Package name: brlcad Latest released version: 7.38.0 Current version on the unstable channel: 7.34.2 Current version on the stable/release channel: 7.34.2 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]:
Change:
}; maintainers = with maintainers; [ emilytrau onedragon ]; platforms = [ "x86_64-linux" ] ++ platforms.darwin; <ins> hydraPlatforms = []; </ins> mainProgram = "vncviewer"; }; in

Discussion:
Steps to reproduce the behavior: 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. -- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
there is now a captcha on the page at "" <img width="381" alt="image" src=""
Looks like it's the original website request captcha, I've submitted a PR to prompt it.
The captcha seems to have been removed.
Change:
''; }; }; <ins> mgmt = (serviceOptions "mgmt") // { enable = mkOption { type = types.bool; default = isEnabled "static"; defaultText = lib.literalExpression "config.services.frr.static.enable"; description = '' Whether to enable the Configuration management daemon. The Configuration management daemon is automatically enabled if needed, at the moment this is when staticd is enabled. ''; }; }; </ins> }; } { options.services.frr = (genAttrs services serviceOptions); }

Discussion:
using frr-9.0.1 from nixos-23.11 results in failure of staticd.service: = true systemctl status staticd staticd used to work with option see Quick fix see below. maybe / want to insert themselves kindly into maintainers :-) system: host os: multi-user?: sandbox: version: channels(fd): channels(root): nixpkgs:
No, sorry. I'm a BIRD user, and I like it that way. Me writing that test and getting FRR over the finish line was some morbid curiosity. My only interest in FRR was bgp-evpn signaling fwiw.
Thanks even more for contributing! My quickfix for this issue is so far It seems, config file location with mgmtd is now instead of mgmtd is needed for staticd to get configured.
also mentions
yes, all daemons have as default config file, I'll try to adapt the nixos service accordingly to get rid of in all service definitions.
Please also test with: (should not have changed this).