jiebi/CodeConvo huggingface dataset:
Change:
done popd <ins> # Linux needs 'aplay' for notification sounds, 'libpulse' for meeting sound, and 'libpipewire' for screen sharing </ins> makeWrapper '${electron}/bin/electron' "$out/bin/teams-for-linux"  <del> --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath [ libpulseaudio pipewire ]}  </del> <ins> ${lib.optionalString stdenv.isLinux '' --prefix PATH : ${lib.makeBinPath [ alsa-utils ]}  --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath [ libpulseaudio pipewire ]}  ''}  </ins> --add-flags "$out/share/teams-for-linux/app.asar"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}"

Discussion:
Audio notifications in do not play and a pop-up appears with a JavaScript error. The error raised is quoted below: A screenshot of the error is also provided which references the store path pointing to . Steps to reproduce the behavior: . a notification from either a direct message, or the start of a meeting. with error appears. Notifications play an audio tone and do not create a Javascript error. If applicable, add screenshots to help explain your problem. ! NixOS configuration using flakes. version is 1.0.45. Other notifications in my system work fine such as Slack and Firefox. Running Hyprland, Gnome is also installed. Issue is not dependent on desktop environment as it occurs in both Gnome and Hyprland. Using for audio. Config below: <!-- 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.
Hmm, I'm surprised I haven't had this issue (and I also use sway/pipewire). I'll look into it some time in the next few days if no one else figures it out first I also planned to update the package to 1.0.49 which may fix it, but that update is waiting on because of changes to the that need newer parsing for lockfile fixup
it seems like this might be fixed by . Do you think you could give that PR a try?
I still get it using the PR.
Can you try it again? I think I found the issue and just made another push to that PR
What's the best way to test PRs? Sorry, still fairly new to NixOS. I've tried building from a tarball with but I'm getting an error as follows: I also tried the method of using a tarball in my as per but I got a different error about .
The easiest method to test is probably when the teams-for-linux client isn't already running. That builds and runs the package from that PR
I'm no longer getting the error.
Also no longer getting the error. Thanks
Change:
cmakeFlags = [ <ins> "-DMaterialX_DIR=${python3Packages.materialx}/lib/cmake/MaterialX" </ins> "-DPYTHON_INCLUDE_DIR=${python3}/include/${python3.libPrefix}" "-DPYTHON_LIBPATH=${python3}/lib" "-DPYTHON_LIBRARY=${python3.libPrefix}"

Discussion:
makes blender crash on start on my machine with Nvidia GPU running Hyprland I think it's a Nvidia issue because I can't repro on Intel iGPU machine blender from current built channel (which is also my system's channel; note that I rebooted after , so probably not a gl driver mismatch issue): blender built from slightly older commit works (which is also blender 4.2.1): According to , the first bad commit is . That merge seems to include some wayland change and I'm using wayland, maybe it's related? Don't have time to bisect further (as it needs to rebuild the whole world) <!-- 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]:
Can reproduce. Some initial triage notes: UI on non-Nvidia is okay Any use of Nvidia GPU seems to fail, including just rendering Crashes with Running with also crashes, so doesn’t seem to be a Wayland issue (GPU rendering also failing suggests the same) CPU rendering is fine I don’t have non-Nvidia GPUs capable of Blender GPU rendering to test those Initial search through upstream issues is not enlightening Runs okay with upstream’s compiled binary
Have identified a fix, will PR shortly.
Thanks! I think should go to BTW. I tested it locally and it fixes the issue
PR:
Change:
#define SHA512_DIGEST_LENGTH		64 diff --git a/src/hash/sha512c.c b/src/hash/sha512c.c <del> index b3c8d5e..4fade0f 100644 </del> <ins> index b3c8d5e..f69013d 100644 </ins> --- a/src/hash/sha512c.c +++ b/src/hash/sha512c.c <del> @@ -25,7 +25,11 @@ </del> <ins> @@ -25,7 +25,13 @@ </ins> */ #include <sys/cdefs.h> <ins> +__FBSDID("$FreeBSD$"); + </ins> +#if defined(darwin) || defined(__APPLE__) || defined(MACOSX) +#include <machine/endian.h> +#else

Discussion:
cc system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
Thanks!

Not sure how difficult it'd be to fix this, but thought I'd note it somewhere. We recently bumped to 0.8.5 but I don't see any reason that would make the patch apply again (although I can't confirm this myself :)). If it can't be resolved reasonably perhaps the patch should be dropped and "darwin" removed from ? EDIT: Looks like libbsd has a separate "port" for OSX: which I've filed an issue on (like was done previously, apparently): Try to build libbsd on Darwin; look at Hydra/Travis build failures. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
Yeah, I have just been manually updating the patch since v0.8.3. The "correct" thing to do would be to get the patch applied upstream in libbsd. Perhaps freedesktop doesn't want it though. /cc
Change:
substituteInPlace src/tss2-tcti/tctildr-dl.c  --replace '@PREFIX@' $out/lib/ substituteInPlace ./test/unit/tctildr-dl.c  <del> --replace ', "libtss2' ", "$out/lib/libtss2"  --replace ', "foo' ", "$out/lib/foo"  --replace ', TEST_TCTI_NAME' ", "$out/lib/"TEST_TCTI_NAME" </del> <ins> --replace '@PREFIX@' $out/lib </ins> ''; configureFlags = [

Discussion:
tpm2-tss is unable to resolve the tabrmd loader located in the tpm2-abrmd package throwing this error when Steps to reproduce the behavior: the abrmd daemon and set the tcti environment interface to tabrmd tool or package using the tpm2-tss library It resolves the loader dynamically and works. I have narrowed down the cause to this commit making the dynamic loader only resolve locally from the library output. Reverting this in an overlay seems to have fixed the issue, but I am unsure if this would cause regressions as I am unsure why the dynamic loading got patched in the first place.
I patched the tpm2-tss because when using tpm2 as a library, the modules would not be up in the dlopen load path which would break modules loading. A couple more details here:
This was a bit more tricky than I expected, while other python packages gets the dlopen library name patched with the exact path this is not possible in this case due to tpm2-tss doing the loading as far I understand. Unless I remember wrong I think it might be possible to dlopen with the exact path in python before calling tpm2-tss init and ld might be able to resolve the already library loaded library, but I might remember wrong. But this would also be undesirable since you cannot dynamically resolve loaders this way I assume.
Ha! So the issue would be that tabmd tries to look up libtss2-tcti- and this is provided by tpm2-abrmd. I completely missed that.
Change:
podiff = callPackage ../tools/text/podiff { }; <del> podman = callPackage ../applications/virtualization/podman { }; </del> <ins> podman = callPackage ../applications/virtualization/podman/wrapper.nix { }; podman-unwrapped = callPackage ../applications/virtualization/podman { }; </ins> podman-compose = python3Packages.callPackage ../applications/virtualization/podman-compose {};

Discussion:
Describe the bug Podman's packaging isn't following the spirit of Nix, as far as I can tell. It seems to pull in a bunch of run-time executable dependencies via PATH resolution instead of build-time resolution. To Reproduce nix-shell -p podman --run podman based on the module, it looks like several run-time executables are referenced through PATH resolution instead of build-time pinning: Expected behavior Nix's build products should have stable references to their run-time dependencies whenever possible. Given podman's rootless container support, I doubly expected to give a usable podman.
Maintainer cc
Hmm im not sure how I feel about this. Podman is agnostic of container runtime for example. So it not having a path to either runc or crun is a feature. But conmon should probably be referenced by nix path yes. And utillinux too. We could perhaps default to runc runtime and let people opt to crun?
check out this PR from
I see the issue here. We could also discuss if it generally would make sense to have a build-time config feature for podman. Having strong defaults without configuration could be achieved that way for NixOS, too.
Is this expected to work without registry and policy files in ?
I would like it to, and it sounds like there is upstream work to make that possible.
This already works with rootless podman if you have the appropriate subuib/subgids set up. If is merged will work out of the box on NixOS.
Change:
makeFlags = [ "INSTALLPREFIX=$(out)" ]; <ins> postFixup = '' chmod +x $out/lib/* ''; </ins> meta = with lib; { homepage = "http://miniupnp.free.fr/libnatpmp.html"; description = "NAT-PMP client";

Discussion:
Recently, introduced libnatpmp as a dependency for Transmission. But for some reason the file is not executable (not on unstable, nor on nixos-21.05). This makes transmission-daemon fail to load the library at startup on my server with the "hardened" profile. Steps to reproduce the behavior: with being: as root, and observe failing to start due to libnatpmp is executable and can start without issues. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --For For libnatpmp: For transmission-daemon: system: host os: multi-user?: sandbox: version: channels(root): channels(minijackson): nixpkgs: Maintainer information:
NixOS tests also broke with the same error:
fedora does this either chmod or patch the install command in Makefile
Change:
Example: ```nix <del> tests.fetchgit = invalidateFetcherByDrvHash fetchgit { </del> <ins> tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit { </ins> name = "nix-source"; url = "https://github.com/NixOS/nix"; rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";

Discussion:
The example from the manual: Literally all instances in nixpkgs use : The manual and nixpkgs should be consistent. As a contributor, i should be able to use examples from the manual (it does not even work).
To make the example from the manual work, you have to add: which adds 3 lines instead of i think it is more readable, idiomatic and elegant, but also clutters the derivation... so the version used in nixpkgs seems to be pragmatic. i suggest we update the manual to reflect nixpkgs. do you agree? we should have a general decision for ONE style. inherit vs
I would prefer the version. Inherits in a let block should only be used, when the attribute is need many times and is a common well known attribute, e.g. lib, version, ...
used to be it's own attribute before it got moved to , I'm guessing the manual was just forgotten to be updated.
Opened a PR that updates the documentation:
yup I forgot
Change:
installFlags = [ "prefix=${placeholder "out"}" <ins> "sysconfdir=${placeholder "out"}/etc" </ins> "moduledir=${placeholder "out"}/lib/modules" "INSTALL=install" ];

Discussion:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.
Change:
</listitem> <listitem> <para> <ins> ZFS module will not allow hibernation by default, this is a safety measure to prevent data loss cases like the ones described at <link xlink:href="https://github.com/openzfs/zfs/issues/260">OpenZFS/260</link> and <link xlink:href="https://github.com/openzfs/zfs/issues/12842">OpenZFS/12842</link>. Use the <literal>boot.zfs.allowHibernation</literal> option to configure this behaviour. </para> </listitem> <listitem> <para> </ins> The Redis module now disables RDB persistence when <literal>services.redis.servers.&lt;name&gt;.save = []</literal> instead of using the Redis default.

Discussion:
Describe the bug Suspend to disk / hibernation in combination with ZFS may lead to filesystem corruption. To Reproduce The problem only shows up occasionally about once on every 30 startups. I had been using suspend to disk on my laptop without problem for several years. After changing from BTRFS to ZFS the import of the ZFS pool occasionally stalls when resuming from hibernate. A message says that the pool is corrupted and gets reconstructed. Once the pool was corrupted irreparably. Root cause ZFS does not support filesystem freeze and thaw under Linux at the moment. (see ) The problem is that when resuming from hibernation the initrd tries to import the pool (it also tries to fix a corrupted pool and effectively modifies the pool/partition). This happens before checks for a possible resume from hibernation and before the system returns to the state in which it had been suspended. Expected behavior It may be possible to fix the problem by reordering the sequence of actions in initrd. Unless there is a fix for this NixOS should disable the combination of ZFS and hibernation. (More precisely, initrd should either contain the setup scripts for ZFS or the scripts for return-from-hibernate). At least there should be a warning.
BTRFS is native to Linux, so its suspension mechanism and Linux's were (presumably) always set up to work with each other. On the other hand, ZFS's suspension code has not yet been hooked up to Linux's properly: I agree that— One potential problem seems to be that there seem to be multiple packages that can cause suspension. In my NixOS configuration, I tell and not to suspend, but I don't know whether that's everything that might cause suspension.
Thanks for adding the link. I've a corresponding line of warning here:
Do you suspend to disk with a zvol swap? Because I'm running with root on ZFS on my laptop and I have never encountered problems with suspend to disk, but I'm also using a separate regular swap partition.
I for one use a regular swap partition. I recall hearing that swap-on-ZVOL is dangerous independently of hibernation.
I marked this as stale due to inactivity. &rarr;
Would it make sense to automatically add in cases where zfs is in use?
This.

A note in wiki or manual will be good too. EDIT: Done ().
I marked this as stale due to inactivity. &rarr;
Let's see if we can close this with
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
stdenvNoCC.mkDerivation rec { inherit pname; <del> version = "2022-07-18"; </del> <ins> version = "2022.11.11"; </ins> src = fetchFromGitHub { owner = "vinceliuice"; repo = pname; rev = version; <del> hash = "sha256-dWYRTwfQRMBdg+htxpWatF325rToaovF/43LxX6I1GI="; </del> <ins> hash = "sha256-3uiQYiseNEKDahjurjnDj9pakx1p94BfsR3LBO2dd/s="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: colloid-gtk-theme Latest released version: 2022-11-11 <!-- Search your package here: --- Current version on the unstable channel: 2022-07-18 Current version on the stable/release channel: 2022-07-18 <!-- 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.
Change:
npmDepsHash = "sha256-KPBKUjCxva11w/E+Qhlx+1vikpCL7Hr9MiKenYHEVSU="; <ins> npmBuildFlags = [ "--production" ]; passthru.tests.help = runCommand "${pname}-tests" { } '' ${web-ext}/bin/web-ext --help touch $out ''; </ins> meta = { description = "A command line tool to help build, run, and test web extensions"; homepage = "https://github.com/mozilla/web-ext";

Discussion:
It looks like , so the program crashes on every run. See . No crash. system: host os: multi-user?: sandbox: version: channels(root): channels(username): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
python3Packages = python37Packages; }; <ins> cqrlog = callPackage ../applications/radio/cqrlog { }; </ins> crun = callPackage ../applications/virtualization/crun {}; csdp = callPackage ../applications/science/math/csdp { };

Discussion:
Project description CQRLOG is an advanced ham radio logger based on MySQL database. Provides radio control based on hamlib libraries (currently support of 140+ radio types and models), DX cluster connection, online callbook, a grayliner, internal QSL manager database support and a most accurate country resolution algorithm based on country tables created by OK1RR. CQRLOG is intended for daily general logging of HF, CW & SSB contacts and strongly focused to easy operation and maintenance. Metadata homepage URL: source URL: license: GPL-2.0 License platforms: unix, linux
Change:
<ins> { lib , stdenv , fetchFromGitHub , cmake , qt6 , fmt , shaderc , vulkan-headers , wayland }: stdenv.mkDerivation (finalAttrs: { pname = "gpt4all-chat"; version = "2.6.2"; src = fetchFromGitHub { fetchSubmodules = true; hash = "sha256-BQE4UQEOOUAh0uGwQf7Q9D30s+aoGFyyMH6EI/WVIkc="; owner = "nomic-ai"; repo = "gpt4all"; rev = "v${finalAttrs.version}"; }; sourceRoot = "${finalAttrs.src.name}/gpt4all-chat"; postPatch = '' substituteInPlace CMakeLists.txt  --replace 'set(CMAKE_INSTALL_PREFIX ''${CMAKE_BINARY_DIR}/install)' "" ''; nativeBuildInputs = [ cmake qt6.wrapQtAppsHook ]; buildInputs = [ fmt qt6.qtwayland qt6.qtquicktimeline qt6.qtsvg qt6.qthttpserver qt6.qtwebengine qt6.qt5compat shaderc vulkan-headers wayland ]; cmakeFlags = [ "-DKOMPUTE_OPT_USE_BUILT_IN_VULKAN_HEADER=OFF" "-DKOMPUTE_OPT_DISABLE_VULKAN_VERSION_CHECK=ON" "-DKOMPUTE_OPT_USE_BUILT_IN_FMT=OFF" ]; postInstall = '' rm -rf $out/include rm -rf $out/lib/*.a mv $out/bin/chat $out/bin/${finalAttrs.meta.mainProgram} install -m 444 -D $src/gpt4all-chat/flatpak-manifest/io.gpt4all.gpt4all.desktop $out/share/applications/io.gpt4all.gpt4all.desktop install -m 444 -D $src/gpt4all-chat/icons/logo.svg $out/share/icons/hicolor/scalable/apps/io.gpt4all.gpt4all.svg substituteInPlace $out/share/applications/io.gpt4all.gpt4all.desktop  --replace 'Exec=chat' 'Exec=${finalAttrs.meta.mainProgram}' ''; meta = { description = "A free-to-use, locally running, privacy-aware chatbot. No GPU or internet required"; homepage = "https://github.com/nomic-ai/gpt4all-chat"; license = lib.licenses.mit; mainProgram = "gpt4all-chat"; maintainers = with lib.maintainers; [ drupol polygon ]; }; }) </ins>

Discussion:
Project description Open-source assistant-style large language models that run locally on your CPU GPT4All is an open-source ecosystem that allows you to integrate Large Language Models (LLMs) into applications without the need for a platform or hardware subscription. Metadata homepage URL: source URL: license: mit platforms: linux, windows, darwin
Change:
### R ### radare2-cutter = cutter; # Added 2021-03-30 <ins> railway-travel = diebahn; # Added 2024-04-01 </ins> rambox-pro = rambox; # Added 2022-12-12 rarian = throw "rarian has been removed as unused"; # Added 2023-07-05 rccl = throw "'rccl' has been replaced with 'rocmPackages.rccl'"; # Added 2023-10-08

Discussion:
how Steps to reproduce the behavior: ... ... ... alias diebahn to railway-travel or vice versa If applicable, add screenshots to help explain your problem. Add any other context about the problem here. you two fight Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
any way for ci to detect double packages perhaps through source? are there more duplicates in nixpkgs?
MB, I did not realize that it was packaged already , it didn't occurred to me to search for the name of the binary instead of the project name. If is fine with it, we could put an alias in place and treat it like a refactoring to pkgs/by-name. Otherwise I will remove my package.
Please remove your package Feel free to add yourself to diebahn's maintainers.
Alright, will do. Should I add an alias for railway-travel that points to diebahn?
You can if you think it helps people find the package in the future.
Change:
<ins> { stdenv, fetchFromGitHub, autoreconfHook, pkgconfig, file, libuv }: stdenv.mkDerivation rec { pname = "raft-canonical"; version = "0.9.6"; src = fetchFromGitHub { owner = "canonical"; repo = "raft"; rev = "v${version}"; sha256 = "083il7b5kw3pc7m5p9xjpb9dlvfarc51sni92mkgm9ckc32x9vpp"; }; nativeBuildInputs = [ autoreconfHook file pkgconfig ]; buildInputs = [ libuv ]; preConfigure = '' substituteInPlace configure --replace /usr/bin/ " " ''; doCheck = false; # Due to #io_uv_recv/success/first                                    [ ERROR ] #Error: test/lib/dir.c:97: No such file or directory #Error: child killed by signal 6 (Aborted) outputs = [ "dev" "out" ]; meta = with stdenv.lib; { description = '' Fully asynchronous C implementation of the Raft consensus protocol ''; longDescription = '' The library has modular design: its core part implements only the core Raft algorithm logic, in a fully platform independent way. On top of that, a pluggable interface defines the I/O implementation for networking (send/receive RPC messages) and disk persistence (store log entries and snapshots). ''; homepage = "https://github.com/canonical/raft"; license = licenses.asl20; maintainers = [ maintainers.wucke13 ]; }; } </ins>

Discussion:
Describe the bug I'm not able to start any (freshly created) container in lxd. To Reproduce Steps to reproduce the behavior: Expected behavior Container starts without issues. Additional context Log gathered via Regarding the not enough space, I'm quiet sure that the report is wrong: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs: Maintainer information:
Maybe updating helps? I started working on a PR, though I depend on a which fails to build.
tested with merged on top inside a nogui VM
Wrong commit?
yip