jiebi/CodeConvo huggingface dataset:
Change:
, hugin , gnumake <ins> , breeze-icons </ins> , oxygen }:

Discussion:
Main problem: no icons in digikam. Digikam requires breeze icons. I've noticed in other bug reports that I need to do something like this: But when I run , there are no icon themes available to choose. Thanks!
Using: And searching for I see it looking in these two locations: But not in the nix store path where the icons reside. I can link that and see the icons in digikam: How is the icon location intended to be communicated?
Those links in my previous comment were created in the directory.
should look in each entry of for icon themes. Does your include ? That is where icon themes installed with will go. If that entry is not present in , then I think your shell is probably not configured correctly. If that entry is present, then there is probably a bug in if it isn't respecting that variable.
Indeed, does allow to see the icons. Next I'll investigate the setup. Thank you.
How should nixpkgs users know to include in ? isn't mentioned in , and it isn't configured automatically when sources . A carefully reading of suggests writing to create a derivation to fix up missing manual/info pages. I guess this would work for the missing icons too. In the short term, maybe XDGDATADIRS should be mentioned in one of these sections of the manuals. Am I overlooking a better mechanism?
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Change:
if [[ ${old_version} == "${version}" && ${force} != 1 && -z ${vendorSha256} && ${old_vendor_sha256} != "${vendorSha256}" ]]; then echo_provider "already at version ${version}" exit <del> else echo_provider "updating from ${old_version} to ${version}" </del> fi <ins> if [[ ${version} =~ (alpha|beta|pre) && ${force} != 1 ]]; then echo_provider "not updating to unstable version ${version}" exit fi echo_provider "updating from ${old_version} to ${version}" </ins> update_attr version "${version}" provider_source_url="$(jq -r '.source' <<<"${registry_response}")"

Discussion:
Right now, the list of providers contains a provider which is an alpha version (: ). Terraform treats these specially, and requires you to opt-in by explicitly specifying the version of the provider, which makes configurations using brittle. Steps to reproduce the behavior: a terraform configuration that requires the provider the following error: and rerun success I'd expect for the script to not commit this non-stable version so that updating Nixpkgs (and thus potentially the provider(s)) does not break terraform configurations. N/A. N/A. <!-- 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): channels(vin): nixpkgs:
Change:
<ins> { pkgs, stdenv, lib, fetchFromGitHub, makeBinaryWrapper, makeDesktopItem, copyDesktopItems, nodejs, electron, python3, ... }: let nodeComposition = import ./node-composition.nix { inherit pkgs nodejs; inherit (stdenv.hostPlatform) system; }; in nodeComposition.package.override rec { pname = "open-stage-control"; inherit (nodeComposition.args) version; src = fetchFromGitHub { owner = "jean-emmanuel"; repo = "open-stage-control"; rev = "v${version}"; hash = "sha256-q18pRtsHfme+OPmi3LhJDK1AdpfkwhoE9LA2rNenDtY="; }; nativeBuildInputs = [ copyDesktopItems makeBinaryWrapper ]; buildInputs = [ python3.pkgs.python-rtmidi ]; dontNpmInstall = true; postInstall = '' # build assets npm run build # copy icon install -Dm644 resources/images/logo.png $out/share/icons/hicolor/256x256/apps/open-stage-control.png install -Dm644 resources/images/logo.svg $out/share/icons/hicolor/scalable/apps/open-stage-control.svg # wrap electron and include python-rtmidi makeWrapper '${electron}/bin/electron' $out/bin/open-stage-control  --inherit-argv0  --add-flags $out/lib/node_modules/open-stage-control/app  --prefix PYTHONPATH : "$PYTHONPATH"  --prefix PATH : '${lib.makeBinPath [ python3 ]}' ''; installCheckPhase = '' XDG_CONFIG_HOME="$(mktemp -d)" $out/bin/open-stage-control --help ''; doInstallCheck = true; desktopItems = [ (makeDesktopItem { name = "open-stage-control"; exec = "open-stage-control"; icon = "open-stage-control"; desktopName = "Open Stage Control"; comment = meta.description; categories = [ "Network" "Audio" "AudioVideo" "Midi" ]; startupWMClass = "open-stage-control"; }) ]; meta = with lib; { description = "Libre and modular OSC / MIDI controller"; homepage = "https://openstagecontrol.ammd.net/"; license = licenses.gpl3Only; maintainers = with maintainers; [ lilyinstarlight ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description Libre and modular OSC / MIDI controller Metadata homepage URL: source URL: license: GPLv3 platforms: electron
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Still would be cool.
I marked this as stale due to inactivity. &rarr;
still relevant
I marked this as stale due to inactivity. &rarr;
Still relevant
I've opened a PR to add this package! See
Change:
openssl, pkg-config, cli11 <del> }@args: </del> <ins> }: </ins> <del> # Note that this requires clang < 9.0 to build, and currently # clangStdenv provides clang 7.1 which satisfies the requirement. let stdenv = if cudaSupport then clangStdenv else args.stdenv; in stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "ethminer"; version = "0.19.0";

Discussion:
Describe the bug I'm not sure what's exactly going on here, but it looks like the build is attempting to use gcc10 includes from somewhere, while the default nvcc from cudatoolkit only supports gcc9 at best. Maybe someone better versed with how cmake works on NixOS could take a look? To Reproduce Steps to reproduce the behavior: to build from nixpkgs (). Expected behavior The package builds successfully with CUDA support. Additional context Persists after version bump Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Maintainer information:
Change:
version = "stig version ${version}"; }; <ins> # https://github.com/rndusr/stig/issues/214#issuecomment-1995651219 dontUsePytestCheck = true; </ins> meta = with lib; { description = "TUI and CLI for the BitTorrent client Transmission"; homepage = "https://github.com/rndusr/stig"; license = licenses.gpl3Plus; <del> # Too many broken tests, and it fails to launch broken = true; </del> maintainers = with maintainers; [  ]; }; }

Discussion:
Steps to reproduce the behavior: stig If I try to install it from my config, I get . If I try to run it by nix-shell: is the nixpkgs commit I'm currently using to get a working version of this program. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The different experience you get with vs is a problem in your Nix environment - probably an old version of nixpkgs you use for vs how you build "your config". However the test failing mark this package is now completely broken. See also discussion with upstream at: . I opened that marks stig as broken, and it will close this issue when merged.
stig works for me with this overlay: I think since addresses
It'd be great if you'd share this in a PR.
Opened at !
Change:
<ins> { stdenvNoCC, lib, fetchFromGitHub }: stdenvNoCC.mkDerivation rec { pname = "distrobox"; version = "1.2.13"; src = fetchFromGitHub { owner = "89luca89"; repo = pname; rev = version; sha256 = "047mrhsfi88mgwylnnyxg6xa7hjjrajn2pf7vfmb6161myqybvfy"; }; dontConfigure = true; dontBuild = true; installPhase = '' runHook preInstall mkdir -p $out/bin ./install -p $out/bin runHook postInstall ''; meta = with lib; { description = "Wrapper around podman or docker to create and start containers"; longDescription = '' Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with ''; homepage = "https://distrobox.privatedns.org/"; license = licenses.gpl3Only; platforms = platforms.all; maintainers = with maintainers; [ atila ]; }; } </ins>

Discussion:
Project description Use any Linux distribution inside your terminal. Distrobox uses or to create containers using the Linux distribution of your choice. The created container will be tightly integrated with the host, allowing sharing of the HOME directory of the user, external storage, external USB devices and graphical apps (X11/Wayland), and audio. Metadata homepage URL: source URL: license: GPL-3.0-only platforms: linux
Correction: homepage URL is
I make it properly work as system package i based it off and removed shebang patches for export and init to avoid nix paths in podman containers I don't know how to deal with xhost part proper way
Change:
serialization/tests/TestSerializeIntegrator.cpp ''; <del> nativeBuildInputs = [ cmake gfortran swig doxygen python3Packages.python ]; </del> <ins> nativeBuildInputs = [ cmake gfortran swig doxygen python3Packages.python ] ++ lib.optional enableCuda addOpenGLRunpath; </ins> buildInputs = [ fftwSinglePrec ] ++ lib.optionals enableOpencl [ ocl-icd opencl-headers ] <del> ++ lib.optional enableCuda cudatoolkit; </del> <ins> ++ lib.optional enableCuda cudaPackages.cudatoolkit; </ins> propagatedBuildInputs = lib.optionals enablePython (with python3Packages; [ python

Discussion:
The build fails in the test phase when CUDA is enabled with errors like this: Note that the did not have this problem. Steps to reproduce the behavior:
I've played around a little bit and couldn't get it working. The problems is that the CUDA drivers are available at runtime in but not in the cudatoolkit. I've symlinked and then the library is found but CUDA is not running properly in the sandbox (). I've looked around somewhat and neither Torch, nor Tensorflow, nor Numba, ... have CUDA tests running in their respective expressions. I would assume for exactly this reasons. I suggest to just disable the CUDA tests and have them running for CPU only.
That sounds reasonable.
Change:
hardening_unsupported_flags+=" stackprotector" '' <ins> + optionalString (libc != null && targetPlatform.isAvr) '' for isa in avr5 avr3 avr4 avr6 avr25 avr31 avr35 avr51 avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7 tiny-stack; do echo "-B${getLib libc}/avr/lib/$isa" >> $out/nix-support/libc-crt1-cflags done '' </ins> + optionalString stdenv.targetPlatform.isDarwin '' echo "-arch ${targetPlatform.darwinArch}" >> $out/nix-support/cc-cflags ''

Discussion:
Steps to reproduce the behavior: on any platform () n/a Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Broken by .
Ping (author), (committer).
might fix it? Will test when I'm home tonight.
Can confirm that it will fix this.
Yes, because part of is reverting the offending commit.
Change:
<ins> { config, lib, pkgs, ... }: with lib; let cfg = config.security.dhparams; in { options = { security.dhparams = { params = mkOption { description = '' Diffie-Hellman parameters to generate. The value is the size (in bits) of the DH params to generate. The generated DH params path can be found in <filename><replaceable>security.dhparams.path</replaceable>/<replaceable>name</replaceable>.pem</filename>. Note: The name of the DH params is taken as being the name of the service it serves: the params will be generated before the said service is started. ''; type = with types; attrsOf int; default = {}; example = { nginx = 3072; }; }; path = mkOption { description = '' Path to the directory in which Diffie-Hellman parameters will be stored. ''; type = types.str; default = "/var/lib/dhparams"; }; }; }; config.systemd.services = { dhparams-init = { description = "Cleanup old Diffie-Hellman parameters"; wantedBy = [ "multi-user.target" ]; # Clean up even when no DH params is set serviceConfig.Type = "oneshot"; script = # Create directory '' if [ ! -d ${cfg.path} ]; then mkdir -p ${cfg.path} fi '' + # Remove old dhparams '' for file in ${cfg.path}/*; do if [ ! -f "$file" ]; then continue fi '' + concatStrings (mapAttrsToList (name: value: '' if [ "$file" == "${cfg.path}/${name}.pem" ] &&  ${pkgs.openssl}/bin/openssl dhparam -in "$file" -text | head -n 1 | grep "(${toString value} bit)" > /dev/null; then continue fi '' ) cfg.params) + '' rm $file done # TODO: Ideally this would be removing the *former* cfg.path, though this # does not seem really important rmdir -p --ignore-fail-on-non-empty ${cfg.path} ''; }; } // mapAttrs' (name: value: nameValuePair "dhparams-gen-${name}" { description = "Generate Diffie-Hellman parameters for ${name} if they don't exist yet"; after = [ "dhparams-init.service" ]; before = [ "${name}.service" ]; wantedBy = [ "multi-user.target" ]; serviceConfig.Type = "oneshot"; script = '' mkdir -p ${cfg.path} if [ ! -f ${cfg.path}/${name}.pem ]; then ${pkgs.openssl}/bin/openssl dhparam -out ${cfg.path}/${name}.pem ${toString value} fi ''; }) cfg.params; } </ins>

Discussion:
Manually generating for services like nginx is error-prone and undermines the beautify of declarative configuration. It would be very helpful if services like nginx could generate their own on first initialization. This is especially helpful in the context of large deployments (with nixops, for example) where generating separate params for each server is very tedious. cc
Change:
# the file should be executable but it isn't so our wrapper doesn't run preFixup = '' chmod 555 $out/bin/puddletag <ins> wrapQtApp $out/bin/puddletag </ins> ''; doCheck = false; # there are no tests

Discussion:
Recently, we fixed : However, on , still fails to run on my machine throughing the dreaded: Steps to reproduce the behavior: run nixpkgs#puddletag The application seems to be correctly wrapped: but still, it does not work. and myself. Please run and paste the result.
There’s definitely an impurity somewhere - it’s working perfectly fine here. I hadn’t used it in a while, but it runs with nixos-unstable` currently on this machine.
This is interesting. The command definitely fails for me. (I was incorrectly saying , but I am also using ). I have trouble debugging this. I had a look at the wrapper shell script, and all looks fine. The paths are ok and do exist.
That seems to indicate an impurity then.
This is also happening on nixos-22.11, not just unstable. A friend is having this issue, so I tested it out for myself and got the same thing. For what it's worth, we both use i3, so the impurity may be related to things a DE would normally set up.
runs fine for me.
So definitely a purity thing then. Care to do a PR?
Sure, I suppose. Just a minute.
Hi! Thanks for looking into this! I could not test the PR directly because the review process starts to build Python Pandas an whatnot. However, I could start using the fix of Some remarks: The wrapper without the fix is: The file with the fix (adding the Qt wrapper line): So there is a substantial difference, and wrapping doesn't seem to work properly without the extra line, even though it should work. Further, when opening on using the fix, the program crashes when clicking with the following error: I do not think this is related to the wrapping, but it should definitely also be fixed. Somehow, is not found.
My version wraps twice, so the original wrapper and all its settings are still there, in , while the real puddletag script is now in . There's a note at the bottom of which says that doesn't wrap scripts, only ELF binaries. I don't know what the reasoning for that is, but apparently invoking the wrapping manually is "what you're supposed to do". At least as far as I could tell.
Ok I see.

So the first wrapper handles the python dependencies, and the second one the qt dependencies. Is that so?
Counting the layers outward from the core (rather than, say, in execution order), yes, that's correct.
Then we should modify the wrapper args instead to avoid double-wrapping.
Well, to do that, I believe you'd need to reimplement either the python wrapping or the qt wrapping systems, which seems prone to breakage.
Change:
plugins = []; }; <del> pidginlatex = callPackage ../applications/networking/instant-messengers/pidgin-plugins/pidgin-latex { imagemagick = imagemagickBig; }; </del> <ins> pidginlatex = callPackage ../applications/networking/instant-messengers/pidgin-plugins/pidgin-latex { }; </ins> <del> pidginlatexSF = builderDefsPackage (import ../applications/networking/instant-messengers/pidgin-plugins/pidgin-latex/pidgin-latex-sf.nix) { inherit pkgconfig pidgin texLive imagemagick which glib gtk; }; </del> <ins> pidginlatexSF = pidginlatex; </ins> pidginmsnpecan = callPackage ../applications/networking/instant-messengers/pidgin-plugins/msn-pecan { };

Discussion:
This, and "meta" should probably be filled to enable Hydra builds.
, maybe you can look at this?
The project is on now, and our version looks outdated for years.
I've dropped one version of a plugin and updated and cleaned up another.

Describe the bug After switching my NixOS configuration to use the rebuild failed at rebuilding . Trying to rebuild again (continuing at again) caused the same issue. Tried after setting in my local nixpkgs clone, and that has worked without errors. I've uploaded the log of to . ~The has triggered a rebuild of other packages so I don't have a failing log available (yet).~ EDIT: gist updated with nixos-rebuild log. Looks like there is a difference / error in the detection. has been able to reproduce this (non-deterministically), so I'm curious what his easy reproducer is. To Reproduce Steps to reproduce the behavior: reproducer TBD Expected behavior Package should build. Additional context Add any other context about the problem here. Metadata Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I’m not sure of why exactly this causes the subsequent errors, but is a direct consequence of . My reproducer is simply (where the flake is with ). The reason why it wasn’t deterministic for me is that the second machine in which I tried to build it had the first one as a substituter, so the derivation hadn’t been built locally but had been fetched − and as such wasn’t affected by NixOS/nix .
Didn't realize there was a targeted fix in the nix repo yet, but I've attempted to rebuild my system again with and without any substituters. Took about 36h, but rebuilding the world worked this time.
Change:
]; projectFile = "Ryujinx.sln"; <del> testProjectFile = "Ryujinx.Tests/Ryujinx.Tests.csproj"; </del> <ins> testProjectFile = "src/Ryujinx.Tests/Ryujinx.Tests.csproj"; </ins> doCheck = true; dotnetFlags = [

Discussion:
Package name: ryujinx Latest released version: 1.1.747 <!-- Search your package here: --- Current version on the unstable channel: 1.1.743 Current version on the stable/release channel: 1.1.327 Notify maintainers Note for maintainers: Please tag this issue in your PR. Finally, for anyone who stumbles upon this issues, and wants an overlay to get them to 1.1.747 without waiting for the package to be updated:
An update to this package will require updating using the script (a process I'm unfamiliar with) and changing the testProjectFile attribute because all of the source was moved into the src/ directory. Other than that and updating the source, no other changes to the derivation should be necessary
Updating a package with an update script (if it's written correctly) should be as simple as: Thanks for detailing the testProjectFile change, that's super helpful. I'm in the process of updating now.
Change:
owner = "johnwhitington"; repo = "cpdf-source"; rev = "v${version}"; <del> sha256 = "sha256:0ps6d78i5mp1gcigxfp9rxmjr1k00nkr37vllhr0rdyph97w41s1"; </del> <ins> sha256 = "sha256:1qmx229nij7g6qmiacmyy4mcgx3k9509p4slahivshqm79d6wiwl"; </ins> }; buildInputs = [ ocaml findlib ncurses ];

Discussion:
I'm getting a hash mismatch error trying to add . I suppose this is due to . Can you please check the sha256 hash?
It seems that the given hash (the one in ) corresponds to at commit . Did the author move the tag from this commit to a more recent one?
I'm not sure what is causing the error. Maybe this sha256 = "sha256:0ps6d78i5mp1gcigxfp9rxmjr1k00nkr37vllhr0rdyph97w41s1"; shouldn't have "sha256:" in it. gives me this info: As a workarround, I manage to add the package by overriding . In it looks like this:
Change:
let collected = collectModules (specialArgs.modulesPath or "") (modules ++ [ internalModule ]) <del> ({ inherit lib options config; } // specialArgs); </del> <ins> ({ inherit lib options config specialArgs; } // specialArgs); </ins> in mergeModules prefix (reverseList collected); options = merged.matchedOptions;

Discussion:
Describe the bug Example config gives me this . To Reproduce Steps to reproduce the behavior: your nixos-config while using nix flakes recursion Additional context Code in nixos
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I think it's because of . This patch works, though I'm not sure how robust it is:
any chance this patch will be upstreamed?
Just for information to everyone who comes here because they try to create specialised configs in flakes, if you use (I did to inject home-manager) then it should be possible to replace it with an inline module like explained here: Using will result in an "attributes missing" error
Change:
shab = callPackage ../tools/text/shab { }; <del> sheldon = callPackage ../tools/misc/sheldon { }; </del> <ins> sheldon = callPackage ../tools/misc/sheldon { inherit (darwin.apple_sdk.frameworks) Security; }; </ins> shell-hist = callPackage ../tools/misc/shell-hist { };

Discussion:
Project description Sheldon is a fast, configurable, command-line tool to manage your shell plugins. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
Change:
stdenv.mkDerivation rec { pname = "exim"; <del> version = "4.96.1"; </del> <ins> version = "4.96.2"; </ins> src = fetchurl { url = "https://ftp.exim.org/pub/exim/exim4/${pname}-${version}.tar.xz"; <del> hash = "sha256-k6wHVcMX4f276ozLcKhoh2vfMUhpKJHHKtD+gWdnAz0="; </del> <ins> hash = "sha256-A44yfo0ek9AFusm7Bv0irsRNUCiTDW2+iBetRLv8HeY="; </ins> }; enableParallelBuilding = true;

Discussion:
Another security release for Exim: 4.96.2. See CC maintainers:
Part of the report also concerns libspf2. (For some reason, it has been filed against Exim instead...) The patch(es) should probably be cherry-picked as well onto helsinki-systems/libspf2 (the fork that we're using).