jiebi/CodeConvo huggingface dataset:
Change:
<del> { lib , stdenvNoCC , fetchFromGitHub , gitUpdater , gnome-themes-extra , gtk-engine-murrine , jdupes , sassc , themeVariants ? [] # default: blue , colorVariants ? [] # default: all , sizeVariants ? [] # default: standard , tweaks ? [] }: let pname = "fluent-gtk-theme"; in lib.checkListOfEnum "${pname}: theme variants" [ "default" "purple" "pink" "red" "orange" "yellow" "green" "teal" "grey" "all" ] themeVariants lib.checkListOfEnum "${pname}: color variants" [ "standard" "light" "dark" ] colorVariants lib.checkListOfEnum "${pname}: size variants" [ "standard" "compact" ] sizeVariants lib.checkListOfEnum "${pname}: tweaks" [ "solid" "float" "round" "blur" "noborder" "square" ] tweaks stdenvNoCC.mkDerivation (finalAttrs: { inherit pname; version = "2024-04-28"; src = fetchFromGitHub { owner = "vinceliuice"; repo = "fluent-gtk-theme"; rev = finalAttrs.version; hash = "sha256-0zf3fHtWcrbT26jgwgsPEDDhBWErOkgXyvGwSWV8rGs="; }; nativeBuildInputs = [ jdupes sassc ]; buildInputs = [ gnome-themes-extra ]; propagatedUserEnvPkgs = [ gtk-engine-murrine ]; postPatch = '' patchShebangs install.sh ''; installPhase = '' runHook preInstall name= HOME="$TMPDIR" ./install.sh  ${lib.optionalString (themeVariants != []) "--theme " + builtins.toString themeVariants}  ${lib.optionalString (colorVariants != []) "--color " + builtins.toString colorVariants}  ${lib.optionalString (sizeVariants != []) "--size " + builtins.toString sizeVariants}  ${lib.optionalString (tweaks != []) "--tweaks " + builtins.toString tweaks}  --icon nixos  --dest $out/share/themes jdupes --quiet --link-soft --recurse $out/share runHook postInstall ''; passthru.updateScript = gitUpdater { }; meta = { description = "Fluent design gtk theme"; homepage = "https://github.com/vinceliuice/Fluent-gtk-theme"; license = lib.licenses.gpl3Only; platforms = lib.platforms.unix; maintainers = with lib.maintainers; [ romildo ]; }; }) </del>

Discussion:
Package name: fluent-gtk-theme Latest released version: 2024-06-12 <!-- Search your package here: --- Current version on the unstable channel: 2024-04-28 Current version on the stable/release channel: 2024-04-28 <!-- 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:
options.programs.ydotool = { enable = lib.mkEnableOption '' <del> ydotoold system service and install ydotool. Add yourself to the 'ydotool' group to be able to use it. </del> <ins> ydotoold system service and {command}`ydotool` for members of {option}`programs.ydotool.group`. </ins> ''; <ins> group = lib.mkOption { type = lib.types.str; default = "ydotool"; description = '' Group which users must be in to use {command}`ydotool`. ''; }; </ins> }; <del> config = lib.mkIf cfg.enable { users.groups.ydotool = { }; </del> <ins> config = let runtimeDirectory = "ydotoold"; in lib.mkIf cfg.enable { users.groups."${config.programs.ydotool.group}" = { }; </ins> systemd.services.ydotoold = { description = "ydotoold - backend for ydotool"; wantedBy = [ "multi-user.target" ]; partOf = [ "multi-user.target" ]; serviceConfig = { <del> Group = "ydotool"; RuntimeDirectory = "ydotoold"; </del> <ins> Group = config.programs.ydotool.group; RuntimeDirectory = runtimeDirectory; </ins> RuntimeDirectoryMode = "0750"; <del> ExecStart = "${lib.getExe' pkgs.ydotool "ydotoold"} --socket-path=/run/ydotoold/socket --socket-perm=0660"; </del> <ins> ExecStart = "${lib.getExe' pkgs.ydotool "ydotoold"} --socket-path=${config.environment.variables.YDOTOOL_SOCKET} --socket-perm=0660"; </ins> # hardening

Discussion:
This would allow users to configure and the like by referring to this setting rather than indirect references like or magic strings like .
Change:
hash = "sha256-50OIFUtcGXtLfuQvDc6MX7vd1NNhCT74jU+zA+M9pf4="; }; <ins> patches = [ ./tracker-landlock-nix-store-permission.patch ]; </ins> nativeBuildInputs = [ asciidoc docbook-xsl-nons

Discussion:
GNOME Music appears empty, but there are music files in my music folder. Steps to reproduce the behavior: NixOS with flake in. music files in music folder. GNOME Music. Music shows up. ! One new line of those appears every time I drop a music file on the music folder. <!-- 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]:
Sounds like this error is still happening: Probably will want to open a new upstream issue.
Have the same issue
Opened
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Wondering what's the plan given the upstream findings.
No plan currently. Basically waiting for someone to be sufficiently annoyed to fix this. Suggested action in
Change:
Please be informed that this pseudo-package is not the only part of Nixpkgs that fails to evaluate. You should not evaluate entire Nixpkgs without some special measures to handle failing <del> packages, like using pkgs/top-level/release-attrpaths.nix. </del> <ins> packages, like using pkgs/top-level/release-attrpaths-superset.nix. </ins> ''; tests = callPackages ../test { };

Discussion:
is a nonexistent file. Steps to reproduce the behavior: the outputted error message probably should point to the file that exists, . additionally, i can't actually find where is defined in nixpkgs. if i could find the file, this would likely be a trivial text fix. i can't find the relevant file, so i don't know who to ping. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
nvm, i found i guess github doesn't search large files?
Feel free to create a PR (and ping me for instant approval and merging).
isn't AAAAAASomeThingsFailToEvaluate deliberate ? what is proposed fix ?
Replace with in the definition of .
so it's just to update message ?
Exactly, and that's what the title means too.
ok, thank you for explaining. my brain for some reason was trying to look for a more complex problem :-)
As the original drafter of the attribute code, I really hope the throw will keep using a string constant thus not leaving any space for more complex problems — or sollutions! (If I notice CI-passed patch to this before I will also quick-merge it of course)
nope, it's marked as trivial for a reason :)
Change:
{ lib <del> , stdenv </del> , python3 , fetchFromGitHub <del> , fetchpatch </del> , fetchPypi , nix-update-script , runtimeShell

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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 It would be great to get this updated as introduces the ability to manage python versions. Will require: to be updated to to be to dependencies to be packaged and to dependencies <!-- 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]:
Also pinging since it seems you have provided the most recent updates.
Change:
httpretty pytest-mock pytest-xdist <ins> ] ++ lib.optionals stdenv.isDarwin [ darwin.ps </ins> ]; preCheck = (''

Discussion:
Steps to reproduce the behavior: poetry on macOS ARM64 from current master (so that is fixed) with fails It boils down to: Building works on Linux ARM64. Don't know about macOS x64. ? Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
~duplicate~ Sorry, I misread.
Change:
stdenv.mkDerivation (finalAttrs: { pname = "gtksourceview"; <del> version = "5.12.0"; </del> <ins> version = "5.12.1"; </ins> outputs = [ "out" "dev" "devdoc" ]; <del> src = let inherit (finalAttrs) pname version; in fetchurl { url = "mirror://gnome/sources/${pname}/${lib.versions.majorMinor version}/${pname}-${version}.tar.xz"; hash = "sha256-2vMv9dMVDWOFkX01A6hbngR7oViysDB5MUycAIE/oB8="; </del> <ins> src = fetchurl { url = "mirror://gnome/sources/gtksourceview/${lib.versions.majorMinor finalAttrs.version}/gtksourceview-${finalAttrs.version}.tar.xz"; hash = "sha256-hMgqrZhcWq2ufOp4BJBKdjQeyCsmjUZZTBpHjzm0LB8="; </ins> }; patches = [

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:
export CUPS_DATADIR="${cups}/share/cups" ''; <ins> postConfigure = '' # don't save timestamp, in order to improve reproducibility substituteInPlace Makefile  --replace "GZIP_ENV = --best" "GZIP_ENV = --best -n" ''; </ins> enableParallelBuilding = true; #

Discussion:
I expect all of these to not return "No such file or directory" and I expect the "bad interpreter" to be patched. I think it still "works", but compilation output should be clean such that when debugging something in the future there is not first a mess of other warnings to go through. Multiple issues: system: host os: multi-user?: sandbox: version: nixpkgs:
cc maintainers
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 .
The build currently complains that is missing: This program comes from ; I believe needs in .
I marked this as stale due to inactivity. &rarr;
As above, I think this is just a matter of adding the right .
I marked this as stale due to inactivity. &rarr;
Change:
owner = "vlasovskikh"; repo = pname; rev = version; <del> sha256 = "sha256-YfcboKjyc5ASzrp0duu2R6psf51MGZIeZ0owo5QNSnU="; </del> <ins> sha256 = "sha256-moWaOzyF/yhDQCLEp7bc0j8wNv7FM7cvvpCwon3j+gI="; </ins> }; nativeBuildInputs = [

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 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: <!-- The current version can be found easily with the same process as 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: desired version: <!-- 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:
<del> { stdenv, fetchFromGitHub, autoreconfHook, coreutils, pkgconfig </del> <ins> { stdenv, autoreconfHook, coreutils, fetchFromGitHub, fetchpatch, pkgconfig </ins> # pyflame needs one python version per ABI # are currently supported # * 2.6 or 2.7 for 2.x ABI # * 3.4 or 3.5 for 3.{4,5} ABI <del> # * 3.6        for 3.6+ ABI # if you want to disable support for some ABI, make the corresponding argument null , python2, python35, python36, python3 </del> <ins> # * 3.6        for 3.6 ABI # * 3.7        for 3.7+ ABI # to disable support for an ABI, make the corresponding argument null , python2, python35, python36, python37, python3 </ins> }: stdenv.mkDerivation rec { pname = "pyflame";

Discussion:
fails to build if there are ptrace scope restrictions (e.g. when using the hardened profile.) to configuration (or add to ) already built, modify something in to change the hash build failure on failing tests: <details<summaryLog</summary</detailsPlease run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
doesn't fix this problem because the pyflame build's tests still fail on a NixOS with the hardened profile enabled:
Change:
, SDL2 , libGL , withSDL2 ? false <del> , withPipewire ? false </del> <ins> , withPipewire ? true </ins> }: stdenv.mkDerivation rec {

Discussion:
Cava does not react to any system audio. Steps to reproduce the behavior: cava it is no response to any audio Cava working D: If applicable, add screenshots to help explain your problem. I am on Fedora Silverblue (Kinoite) 38, using Pipewire There is some reports that cava may accidentally pick up microphone audio instead of playback (on pipewire), this is not the issue I built from source inside a distrobox and it behaved correctly (but only when i specified release 0.8.3, pulling directly from master gave me the same result. <!-- 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.
Change:
glibPreFixupPhase() { # Move gschemas in case the install flag didn't help <del> if [ -d "${!outputLib}/share/glib-2.0/schemas" ]; then </del> <ins> if [ -d "$prefix/share/glib-2.0/schemas" ]; then </ins> mkdir -p "${!outputLib}/share/gsettings-schemas/$name/glib-2.0" <del> mv "${!outputLib}/share/glib-2.0/schemas" "${!outputLib}/share/gsettings-schemas/$name/glib-2.0/" </del> <ins> mv "$prefix/share/glib-2.0/schemas" "${!outputLib}/share/gsettings-schemas/$name/glib-2.0/" </ins> fi addToSearchPath GSETTINGS_SCHEMAS_PATH "${!outputLib}/share/gsettings-schemas/$name"

Discussion:
In , I a output to nm-applet. This caused the glib setup hook to no longer apply, since it expects the gsettings schemas in output: I wonder when this is applicable, since the schemas will only go to when install flags set by the hook apply, but then they will already be in the correct directory. cc
Here's the relevant discussions when that change was made.
I see the change from to ${!outputLib}` here:
Fixed in
Change:
NIX_LDFLAGS = stdenv.lib.optionalString stdenv.isLinux "-lgcc_s"; <del> preFixup = stdenv.lib.optionalString stdenv.isLinux '' </del> <ins> configureFlags = stdenv.lib.optional (!enableSystemd) "--disable-udev"; preFixup = stdenv.lib.optionalString enableSystemd '' </ins> sed 's,-ludev,-L${stdenv.lib.getLib systemd}/lib -ludev,' -i $out/lib/libusb-1.0.la '';

Discussion:
Describe the bug After the PR is merged, as , fails to evaluate on . This is quite annoying because is a dependency of , which makes a sizable chunk of fail to evaluate on . I encountered this issue when trying to build . To Reproduce Steps to reproduce the behavior: Expected behavior , therefore to evaluate and run successfully on . cc
I believe should change the error message, but not fix the problem. Now the trace should go like hidapi -systemd, instead of hidapi -libusb -systemd. I don't really know where the infinite recursion comes from as that doesn't happen with nixos-19.09, however even if that didn't happen it wouldn't matter because systemd doesn't work with musl. If you want to fix this you'd have to look into getting the systemd dependency out of the hidapi nix expression. I'm not really sure why it's there in the first place, glancing at the hidapi , it seems like it depends on udev, which depends on util-linux which depends on systemd, but not on systemd directly and util-linux can be build without systemd. The utillinux nix expression already accounts for that possibility, you'd just have to make it actually do that for pkgsMusl. You could take the libusb nix expression as a template on how to achieve this. Disclaimer: I have virtually no experience with these low-level things, so I may be wrong.
Change:
in map (x: "${mountPoint x}.mount") (getPoolFilesystems pool); <del> getKeyLocations = pool: if isBool cfgZfs.requestEncryptionCredentials then "${cfgZfs.package}/sbin/zfs list -rHo name,keylocation,keystatus ${pool}" else "${cfgZfs.package}/sbin/zfs list -Ho name,keylocation,keystatus ${toString (filter (x: datasetToPool x == pool) cfgZfs.requestEncryptionCredentials)}"; </del> <ins> getKeyLocations = pool: if isBool cfgZfs.requestEncryptionCredentials then { hasKeys = cfgZfs.requestEncryptionCredentials; command = "${cfgZfs.package}/sbin/zfs list -rHo name,keylocation,keystatus ${pool}"; } else let keys = filter (x: datasetToPool x == pool) cfgZfs.requestEncryptionCredentials; in { hasKeys = keys != []; command = "${cfgZfs.package}/sbin/zfs list -Ho name,keylocation,keystatus ${toString keys}"; }; </ins> createImportService = { pool, systemd, force, prefix ? "" }: nameValuePair "zfs-import-${pool}" {

Discussion:
When multiple ZFS filesystems are present and configured to import, each individual attempts to load the keys for ALL pools/datasets, instead of just its own. A clear and concise description of what the bug is. Steps to reproduce the behavior: encrypted zfs filesystems in your NixOS configuration. & Reboot All targets complete successfully The below snippet from the services's script. It's 'ing, and just looping over all pools/datasets. Instead, it should just specify the name directly in the command. (Generated in ) Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs:
Can you post the relevant Nix config you used? Do you have set to anything?
Yep, here's my zfs config. uses (unlocked at boot) is unencrypted and have on-disk
Ok, I think this is fundamentally the same issue as . Basically, when there are multiple pools and is a list, we accidentally run with no dataset argument in the import service for pools that have no datasets in the list. So those services end up iterating over all datasets on all pools instead of none.

Steps to reproduce the behavior: to a list. (in my case, these are backup pools to which I raw-send encrypted datasets, none of their content is expected to be mounted under normal circumstances). boot process still requests the keys for datasets that are not in the list from step 1. I should only ever see decryption prompts for datasets that I want decrypted. system: host os: multi-user?: sandbox: version: channels(novenary): channels(root): nixpkgs:
Change:
, readline , which , musl-fts <ins> , pcre </ins> # options , conf ? null , withIcons ? false , withNerdIcons ? false , withEmojis ? false <ins> , withPcre ? false , extraMakeFlags ? [ ] </ins> }: # Mutually exclusive options

Discussion:
It would be great to have option to fetch nnn plugins with nxpkgs or with additional package instead of manually fetching it like developer advise. And second is it possible to implement some option to include icons support from nerdfont to nnn binary file instead of recompiling it? Thanks.
I think this issue was closed preemptively by the line in the PR, there doesn't seem to be any way to include plugins as of now
nnn seems to expect plugins in . This might work better as a home-manager module, maybe with the plugins themselves as an output of nixpkgs. I might take a look at this next week.
I marked this as stale due to inactivity. &rarr;
I've recompiled nnn with icons, by using unstable branch and overriding nnn-package:
I marked this as stale due to inactivity. &rarr;
Change:
bootFlash=$out/bios.bin ${qemu}/bin/qemu-img create -f qcow2 $diskImage "40M" ${if cfg.useEFIBoot then '' <del> cp ${pkgs.OVMF-CSM}/FV/OVMF.fd $bootFlash </del> <ins> cp ${pkgs.OVMF-CSM.fd}/FV/OVMF.fd $bootFlash </ins> chmod 0644 $bootFlash '' else '' ''}

Discussion:
In , I introduced support in libvirtd for UEFI VM creation. rightfully remarked that this brings closure-size up too much. Looking into OVMF shows that only 1MB out of the 114MB install size is needed to enable said UEFI VM creation. I think that we should look into splitting out OVMF_(CODE|VARS) from the rest package.
Change:
''; }; <del> prunePaths = mkOption { type = listOf path; </del> <ins> prunePaths = lib.mkOption { type = lib.types.listOf lib.types.path; </ins> default = [ "/tmp" "/var/tmp"

Discussion:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.