jiebi/CodeConvo huggingface dataset:
Change:
"11.8" = ./manifests/redistrib_11.8.0.json; "12.0" = ./manifests/redistrib_12.0.1.json; "12.1" = ./manifests/redistrib_12.1.1.json; <ins> "12.2" = ./manifests/redistrib_12.2.0.json; </ins> }; # Function to build a single cudatoolkit redist package

Discussion:
Some cuda packages come with vendored copies of libraries that are already available in nixpkgs. These vendored libraries still require patching their Runpaths, their presence reduces determinism, and breaks "deep replacement" (i.e. nixpkgs' feature allowing to ensure that everything in a package set uses the same revision of a dependency). For instance, ships , which otherwise is available as: Cf. Tasks [ ] Look into deleting these vendored libraries and re-linking their reverse dependencies against nixpkgs alternatives
Change:
buildFHSEnv { name = "dropbox"; <ins> # dropbox-cli (i.e. nautilus-dropbox) needs the PID to confirm dropbox is running. # Dropbox's internal limit-to-one-instance check also relies on the PID. unsharePid = false; </ins> targetPkgs = pkgs: with pkgs; with xorg; [ libICE libSM libX11 libXcomposite libXdamage libXext libXfixes libXrender libXxf86vm libxcb xkeyboardconfig

Discussion:
(or ) checks a PID set by the dropbox daemon to determine if it is running. Because the daemon is now using flatpak's bubblewrap, it sets the PID from within its own namespace. Nautilus therefore thinks the daemon isn't running, and won't perform many commands. This is also likely breaking the dropbox daemon's internal limit-to-one-instance check. See issue report at for more details. Steps to reproduce the behavior: configuration like this and : , observe 'Dropbox isn't running!' message. , confirm dropbox actually is running. To confirm the broken PID behaviour: , confirm it isn't dropbox. is set to correct PID; reports actual status. The suggested solution in the issue linked above is to add as an argument to in the dropbox specification. I'll open a PR that does this.
Change:
, fetchFromGitHub , chafa , cmake <ins> , darwin </ins> , dbus , dconf , ddcutil

Discussion:
Steps to reproduce the behavior: fastfetch log: related: <!-- 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]:
Yeah, this popped up after a staging change... I tried to look into a little bit before but not sure exactly what needs to change for it, yet.
Change:
}; pname = "solc"; <del> version = "0.8.19"; </del> <ins> version = "0.8.21"; </ins> meta = with lib; { description = "Compiler for Ethereum smart contract language Solidity"; homepage = "https://github.com/ethereum/solidity";

Discussion:
Package name: solc Latest released version: 0.8.21Current version on the unstable channel: 0.8.19 Current version on the stable/release channel: 0.8.19 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Change:
packageAliases = { linux_default = if stdenv.hostPlatform.isi686 then packages.linux_5_10 else packages.linux_5_15; # Update this when adding the newest kernel major version! <del> linux_latest = packages.linux_5_17; </del> <ins> linux_latest = packages.linux_5_18; </ins> linux_mptcp = packages.linux_mptcp_95; linux_rt_default = packages.linux_rt_5_4; linux_rt_latest = packages.linux_rt_5_10;

Discussion:
Steps to reproduce the behavior: Tail of the build log The build failure seems related to these unused options. I tried removing the corresponding lines (in a local directory - so I changed my url to the filesystem path). in but it didn't fix anything. It seems that kernel 5.18 phased out some options. Instead of warning us, there's an explicit error. I have no idea how to fix this since is great for adding lines to the kernel config, but not great at removing them. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (I'm not exactly sure who to notify about this so I just kind of scanned s of and . Please let me know if there's someone more appropriate to notify.) Please run and paste the result. Not sure how to do this for this specific package (no ).
Can you check if fixes this?
. But, it still fails:
Should be fixed by
I can confirm that fixes this! Thanks !
Change:
buildGoModule rec { pname = "lnd"; <del> version = "0.18.0-beta"; </del> <ins> version = "0.18.2-beta"; </ins> src = fetchFromGitHub { owner = "lightningnetwork"; repo = "lnd"; rev = "v${version}"; <del> hash = "sha256-LkVlsmL/NjWtKUnerqTiT/jNfxazYw0B0GhBDCTGmao="; </del> <ins> hash = "sha256-qqvLnJlFGeCizm6T9iUwvYLjWpAeZwbuzQlUUopwrjc="; </ins> }; <del> vendorHash = "sha256-T7jPuhAEeQ0U43J9gTQ+0/BdLAn4BOupAkmmmofhHtY="; </del> <ins> vendorHash = "sha256-BxNtZzwmKJ/kZk7ndtEUC4bMGpd8LEhFFu4Z49bKydE="; </ins> subPackages = [ "cmd/lncli" "cmd/lnd" ];

Discussion:
Package name: lnd Latest released version: 0.18.2 Current version on the unstable channel:0.18.0 Current version on the stable/release channel: 0.17.5-beta Notify maintainers I would love to learn how to update a package like this. I will try to figure it out, but here's where I am at so far: I tried changing the version and updated the hashes using sha256sum command. I got incorrect hash errors and running the compiled binary showed that it was still building 0.18.0! Complete and total failure. Here's : Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Replace some random characters in the existing hashes for 0.18.0 and change the version to 0.18.2 The build will tell you which hashes should be used
updated in PR
thanks! I hate to trouble you, but I still seem stuck on why my command is still giving me lnd 0.18.0 instead of 0.18.2, any advice?
not sure how you obtained those hashes ... does it work with hashes from my PR?
Change:
<del> { stdenv, buildPythonPackage, fetchPypi, lib, grpcio}: </del> <ins> { stdenv, buildPythonPackage, fetchPypi, protobuf, grpcio }: </ins> buildPythonPackage rec { pname = "grpcio-tools"; <del> version = "1.18.0"; </del> <ins> version = "1.22.0"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "77ec4d3c92ccbbe3de37c457e3c72962e519c36cafb96abe5842bced8eb926fa"; </del> <ins> sha256 = "b5c0fe51a155625c9d1132ab8deb56b3015e111a6961e48aeb9dd89bd7c670ab"; </ins> }; enableParallelBuilding = true; <del> propagatedBuildInputs = [ grpcio ]; </del> <ins> propagatedBuildInputs = [ protobuf grpcio ]; </ins> # no tests in the package doCheck = false; meta = with stdenv.lib; { description = "Protobuf code generator for gRPC"; <del> license = lib.licenses.asl20; </del> <ins> license = licenses.asl20; </ins> homepage = "https://grpc.io/grpc/python/"; maintainers = with maintainers; [ vanschelven ]; };

Discussion:
Describe the bug grpc doesn't build on macOS. To Reproduce Steps to reproduce the behavior: -shell -p grpc Expected behavior Should have built without errors. Additional context Build log here: Metadata system: host os: multi-user?: sandbox: version: channels(kaali): nixpkgs: Maintainer information:
grpc appears to be pretty out of date , so I'm suspecting that updating all of the pieces would resolve this.
Seems to fail in CI even with an updated version:
That particular package requires manual intervention, as that PR was automatically generated by a bot.
Change:
}) ]; <ins> # Remove INSTALL file to avoid `make` misinterpreting it as an up-to-date # target on case-insensitive filesystems e.g. Darwin preInstall = '' rm -v INSTALL ''; </ins> configureFlags = [ "--disable-wordview" ]; meta = with lib; {

Discussion:
I'm not at all familiar with catdoc, but I was building a bunch of random stuff (on macOS) to test some tooling I'm working on and it coincidentally broke because the catdoc output in my store is empty. I took a peek at hydra and it confirms that it produces output on Linux, but not on macOS: The only packages I see that consume catdoc are and , so they may both be subtly broken on macOS? catdoc doesn't have a listed maintainer, so I'm mentioning maintainers of catdocx and recoll in case they have a sense of whether it should work and just needs a fix, or should maybe get marked broken? recoll: catdocx:
Change:
--transform 'flags=rSh;s|/nix/store/||'  --files-from ${hostPkgs.closureInfo { rootPaths = [ config.system.build.toplevel regInfo ]; }}/store-paths  | ${hostPkgs.erofs-utils}/bin/mkfs.erofs  <ins> --quiet  </ins> --force-uid=0  --force-gid=0  -L ${nixStoreFilesystemLabel} 

Discussion:
Build log: Update PR: Revert PR: This blocked the channel. It seems most likely to be an upstream regression. There’s nothing obvious in . Probably we’ll have to report it upstream and/or peruse the . cc
I cannot parse the log in the link above or reproduce locally, could someone give some hints what happens or a reproducable way?
Hi, sorry about that! If you have Nix installed on a Linux machine, or a NixOS VM handy, should reproduce the test failure. However, I realize that’s not terribly convenient. The , (Sorry, no, that’s of course part of , so I really don’t have any idea why the erofs-utils upgrade caused us issues. I know we use erofs inside our VM and testing machinery, but I don’t know exactly where. Most likely whatever is hanging actually comes after the call.) We don’t currently have any idea why this happens for this specific test, but we know that it happens reliably and across multiple platforms. None of this is very digestible or easy to debug for someone who isn’t experienced with Nix(OS), so I was hoping one of our contributors would be able to make a more minimal reproducer to be able to send upstream, or even figure out the bug. I just put this issue up as we were having to revert the upgrade in a hurry to unblock updates for users and I didn’t want it to be forgotten about. I don’t have the time myself to try and make a minimal reproducer, but please let me know if there’s anything else I could do that would be helpful.
It almost certainly comes from this invocation of : I'll hopefully have time to look at this in more detail soon.
The log doesn’t contain “Creating Nix store image...”, FWIW. Not sure if that’s relevant to whether that code is being invoked or not.
I haven't pinpointed what is to blame, but it appears the way prints progress may have changed between 1.7.1 and 1.8.1, which is causing the issues. When telling the tooling to not print any progress, image creation occurs much more quickly (though still quite slow as the machine closures with gitlab are large).

I assume it's something on our side that's to blame since I don't actually see the progress being printed during the timeouts, so I assume something is eating the output.
Oh, I know. Since erofs-utils 1.8, we unify and the usual mkfs logic, so also prints progress too. And yes, if that is not expected, is preferred to match erofs-utils 1.7.1...
thank you for tracking this!
Change:
zuluVersion = "22.28.91"; jdkVersion = "22.0.0"; hash = <del> if enableJavaFX then "sha256-Y6PSNQjHRXukwux2sVbvpTIqT+Cg+KeG1C0iSEwyKZw=" </del> <ins> if enableJavaFX then "sha256-QkFwbc2YFEWb5rddhH4a+zmtsrXxUBSuS8yg9qUb728=" </ins> else "sha256-Y6PSNQjHRXukwux2sVbvpTIqT+Cg+KeG1C0iSEwyKZw="; };

Discussion:
The are incorrect for builds with JavaFx enabled - the hashes are identical to the non-JavaFx builds, which produces a hash error when used. Steps to reproduce the behavior: Should download Zulu with the proper hashes <!-- 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]:
Change:
<ins> { lib , buildGo122Module , fetchFromGitHub , openssl }: buildGo122Module rec { pname = "ssh-tpm-agent"; version = "0.3.1"; src = fetchFromGitHub { owner = "Foxboron"; repo = "ssh-tpm-agent"; rev = "v${version}"; hash = "sha256-8CGSiCOcns4cWkYWqibs6hAFRipYabKPCpkhxF4OE8w="; }; proxyVendor = true; vendorHash = "sha256-zUAIesBeuh1zlxXcjKSNmMawZGgUr9z3NzT0XKn/YCQ="; buildInputs = [ openssl ]; meta = with lib; { description = "SSH agent with support for TPM sealed keys for public key authentication"; homepage = "https://github.com/Foxboron/ssh-agent-tpm"; license = licenses.mit; platforms = platforms.linux; maintainers = with maintainers; [ sgo ]; mainProgram = "ssh-tpm-agent"; }; } </ins>

Discussion:
Project description ssh-tpm-agent is a ssh-agent compatible agent that allows keys to be created by the Trusted Platform Module (TPM) for authentication towards ssh servers. Metadata homepage URL: source URL: license: MIT platforms: unix (at least) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
ah, thanks i promise i did search but somehow didn't get any relevant results. probably PEBKAC.
Change:
owner = "gitlabhq"; repo = "gitlabhq"; rev = "v${version}"; <del> sha256 = "1yyyn2j0a457q2xbcxz6b33r23myr8kxbm9whj2dwrrbp4p273hr"; </del> <ins> sha256 = "041ld3na8m42akqpljipid984d0mv0wzk2p1630fncc1w3iaq06d"; </ins> }; patches = [

Discussion:
Following the NixOS manual () to setup Gitlab on a new NixOS server, I got the following error: Consulting the IRC channel #nixos on , I got the diagnosis of the problem that they put their own copy of ksu into the package, setuid'd and nix doesn't allow setuid files. a new NixOS install, update with a minimal Gitlab configuration or System: 17.03.1700. (Gorilla) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: "17.03.1700." Sandboxing enabled: build-use-sandbox = false
cc (maintainer)
Change:
meta = with stdenv.lib; { description = "Drum sample player LV2 plugin dedicated to Glen MacArthur's AVLdrums"; homepage = https://x42-plugins.com/x42/x42-avldrums; <del> maintainers = with maintainers; [ orivej ]; </del> <ins> maintainers = with maintainers; [ magnetophon orivej ]; </ins> license = licenses.gpl2Plus; platforms = platforms.linux; };

Discussion:
Recently a second version of avldrums got merged: We already had
cc
How many of these kind of plugins do we have? Does it make sense to put them in a package set?
What do you mean by these kind of plugins? LV2 in general? Might make sense. Not sure what the advantages and disadvantages are. avldrums? There is only one, but it's packaged twice. (just in case you missed that). :)
Yes, lv2 in general. We should do this
So by package set you mean just move them next to each other in all-packages? BTW, not all of the above are plugins: lv2: the library lv2bm: an lv2 benchmarker faust2lv2: a compiler to make lv2s with There are also more lv2 plugins in nixpkgs.
Unfortunately x42 stuff has two names, sometimes distantly related (x42-autotune is aka fat1.lv2). It seems that x42 names are better because they are more recognizable (as belonging to x42-), they are used in URLs (https://x42-) and as the names of packages (https://x42-). It would be useful to be able to find all packaged lv2 plugins at a glance. However, since some lv2 plugins come with a standalone application, sometimes it will be difficult to decide whether a package should be classified as a plugin or not. (I would classify x42-plugins as plugins despite their programs in bin/, but qmidiarp as a non-plugin despite its lib/lv2/.)
I propose the same approach as in Python. In case its plugins, put them in the plugin set. In case its only application, put them in top-level, if both, put them in plugins and offer a top-level reference.
I agree it would be useful to be able to find all packaged lv2 plugins at a glance.
OK. I would propose to name the package set audioPlugins and put the definitions in applications/audio/plugins/ . They should comprise DAW plugins (lv2, ladspa, dssi, vst), but not e.g. media player plugins (gst-plugins-good).

It does not seem useful to subdivide plugins further, because audio hosts support many types of plugins (Ardour and Carla support lv2, ladspa, vst) and some packages provide many types of plugins at once (zam-plugins has lv2, ladspa, vst; wolf-shaper has lv2, dssi, vst).
I'm not familiar with DAWs but that sounds reasonable! Maybe then so its clear its not about and such?
Change:
# TODO(@connorbaker): This should be handled by having CMakeLists.txt install them, but such a patch is # out of the scope of the PR which introduces the `test` output: https://github.com/NixOS/nixpkgs/pull/283777. # See https://github.com/NixOS/nixpkgs/pull/283777#discussion_r1482125034 for more information. <ins> # Such work is tracked by https://github.com/NixOS/nixpkgs/issues/296286. </ins> '' install -Dm755 ../testing/run_{tests,summarize}.py -t "$test/bin/" ''

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.torchvision maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags: - -
Will be closed by
Change:
<ins> { stdenvNoCC, lib, fetchurl, autoPatchelfHook, cups, e2fsprogs, krb5, libxcrypt-legacy, unzip, }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "cups-idprt-sp900"; version = "1.4.0"; src = fetchurl { name = "idprt_sp900_printer_linux_driver.zip"; url = "https://www.idprt.com/prt_v2/files/down_file/id/176/fid/498.html"; # NOTE: This is NOT an HTML page, but a ZIP file hash = "sha256-+YVQTrqpi16xX+d/ulMtffpA9X7hwtWRiS/mIAw13n8="; }; sourceRoot = "idprt_sp900_printer_linux_driver_v${finalAttrs.version}/idprt_sp900_printer_linux_driver_v${finalAttrs.version}"; # >:| buildInputs = [ cups e2fsprogs krb5 libxcrypt-legacy ]; nativeBuildInputs = [ autoPatchelfHook unzip ]; installPhase = let arch = builtins.getAttr stdenvNoCC.hostPlatform.system { x86_64-linux = "x64"; x86-linux = "x86"; }; in '' runHook preInstall mkdir -p $out/share/cups/model $out/lib/cups/filter cp -r filter/${arch}/. $out/lib/cups/filter cp -r ppd/. $out/share/cups/model chmod +x $out/lib/cups/filter/* runHook postInstall ''; meta = { description = "CUPS driver for the iDPRT SP900"; platforms = [ "x86_64-linux" "x86-linux" ]; license = lib.licenses.unfree; sourceProvenance = with lib.sourceTypes; [ binaryNativeCode ]; maintainers = with lib.maintainers; [ pandapip1 ]; }; }) </ins>

Discussion:
Project description CUPS drivers for iDPRT label printers Metadata homepage URL: source URL: / license: proprietary platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
There is no need to create an issue for a software you are packaging. Create the package right away.
I wasn't planning on packaging the software. I opened this issue last week. About an hour ago I decided to bite the bullet and do it myself.
No problem.
Change:
</listitem> </itemizedlist> </listitem> <ins> <listitem> <para> <literal>services.uptimed</literal> now uses <literal>/var/lib/uptimed</literal> as its stateDirectory instead of <literal>/var/spool/uptimed</literal>. Make sure to move all files to the new directory. </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="sec-release-21.11-notable-changes">

Discussion:
Despite beeing installed for a few days now: it seems like the uptimed service does not find its database properly and prints just the current uptime. I guess this is because the database file gets recreated every boot. But that's only a shot into the blue guess. System: 17.03pre99626. (Gorilla) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: "17.03pre99626."
Some logs from the journal: Pinging maintainers of the service (there is no maintainer in the pkg):
Probably a permission problem or the said directory does not exists.
Yep, looks like it,... though I have no time to investigate, so I'll just leave this here and hope it gets fixed.
In the meantime you can use this one instead:
:smile:
Still no love for this?
Still no love for this?
Does the following (untested) code help?
Tried yours and but fails with: tested on System: 18.03pre124015. (Impala) Nix version: nix-env (Nix) 1.11.16 Nixpkgs version: "18.03pre124015." Sandboxing enabled: build-use-sandbox = true (diff applied on )
It seems that it did not saved my updated change (I forgot to prefix first)
I know nothing about , sorry.
close as unresolved?
Closed as unresolved.
The issue is still present under 18.09 and (I presume) as  does not seem to contain any of the changes proposed here. Why is this issue closed?
Because I do not care anymore and nobody else seems to care either. Do you want me to reopen?
I probably do. I have some extra details on the issue: So it seems that the user cannot write to the directory even though it owns it.
It seems that is a workaround. Not sure about its safety though.
So now it works, but in a roundabout way: The next steps are making the directory world-readable and bringing into user scope.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me".

This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
As people seemed to interested in this and it is a bug: still important to me
Should be made a tmpfiles rule or if possible changed to /var/lib/uptime, in which case we can set .
I marked this as stale due to inactivity. &rarr;
Change:
mesonFlags = [ "-Dsystemd=true" "-Dcompositor=${phoc}/bin/phoc" ]; <ins> patches = [ # build: Adjust to polkit version changes (fetchpatch { url = "https://gitlab.gnome.org/World/Phosh/phosh/-/commit/16b46e295b86cbf1beaccf8218cf65ebb4b7a6f1.patch"; sha256 = "sha256-Db1OEdiI1QBHGEBs1Coi7LTF9bCScdDgxmovpBdIY/g="; }) # polkit-auth-agent: Scope cleanup function for PolkitAgentListener (fetchpatch { url = "https://gitlab.gnome.org/World/Phosh/phosh/-/commit/b864653df50bfd8f34766fc6b37a3bf32cfbdfa4.patch"; sha256 = "sha256-YCw3tGk94NAa6PPTmA1lCJVzzi9GC74BmvtTcvuHPh0="; }) ]; </ins> postPatch = '' chmod +x build-aux/post_install.py patchShebangs build-aux/post_install.py

Discussion:
Fixed upstream in . We're awaiting a release that contains that commit, likely 0.20 (soon?), or perhaps we could patch that commit in.
Change:
# very useful. # Flag added in Agda 2.6.4.1, was always enabled before (enableCabalFlag "debug") <ins> # Split outputs to reduce closure size enableSeparateBinOutput </ins> ]; # ats-format uses cli-setup in Setup.hs which is quite happy to write

Discussion:
With the standard library, cubical and categories, agdaWithPackages has a closure size of about 4.9 GiB (): Among the larger culprits are 600 MiB of libHSAgda-[...].a and GHC itself. Personally I'm using where I zero out the dependence on GHC and just fetch the Agda binary. I've been using this for years and never encountered any problems. Should we incorporate something like this in nixpkgs?
I currently have a number of parallel installations of Agda on my machines, and I'd like to see a reduction of closure size. I think there are two separate space hogs: Haskell library. The mentions two helpers to reduce closure size: (removes references to libraries and docs) and (installs binaries in a separate output). I tried setting , but it breaks .<supSee below</supattribute passed to : I don't use Agda's GHC backend, so I provide a "fake GHC" to reduce closure size: Maybe could be changed so that disables compilation via GCH. E.g. we could pass and to the wrapped binary. I applied to the Haskell package . Running results in the following output: Result of run on x86_64-linux <details<summary2 packages marked as broken and skipped:</summary<ul<licedille</li<liemacsPackages.cedille</li</ul</details<details<summary1 package failed to build:</summary<ul<liemacsPackages.agda2-mode</li</ul</details<details<summaryBuild log of <codeemacsPackages.agda2-mode</code</summary</details