jiebi/CodeConvo huggingface dataset:
Change:
owner = "fmtlib"; repo = "fmt"; rev = version; <del> sha256 = "1vr08a8q94j66gas7ddbpdbq72b2ikd0mkgd5zd3l63610n8qajs"; </del> <ins> sha256 = "1i6nfxazq4d05r3sxyc3ziwkqq7s8rdbv9p16afv66aqmsbqqqic"; </ins> }; patches = [

Discussion:
Describe the bug The files shipped in the output of the library refer to invalid include paths. This prevents building software with the library if they trying finding it using cmake (instead of pkg-config). To Reproduce Steps to reproduce the behavior: to of the package (currently it's falling back on its vendored copy). the package. Expected behavior builds. Additional context In : The include directory is invalid, looking up in the default output. Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(delroth): nixpkgs:
(Seems like a variant of -- cc as well)
The file seems to be generated here: Maybe it is a CMake bug? I do not understand CMake enough to be able to tell for sure.

Describe the bug fmt has two derivations, out and dev. The cmake file ends up with a path that contains the incorrect/missing path to the 'out' derivations 'include' folder. It should be the 'dev' folder'. The eventual error you get when you end up with package A depending on package B and package B depending on fmt is: when the INTERFACEINCLUDEDIRECTORIES should be /nix/store/...-fmt-6.2.0-dev/include`. To Reproduce Steps to reproduce the behavior: fmt package cmake files for fmt path Expected behavior fmt- should point to fmt-dev....: Additional context Looks like the bug is resolved but is stalled since 2019. That stack of diffs is exactly what I was doing when i ran into this bug, building fbthrift+rsocket-cpp. and the solution i came up with locally to get 'expected behavior' is the same as well. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(sheenobu): channels(root): nixpkgs: Maintainer information:
This effects the latest upstream releases of yuzu, packaged in . Currently can't update the package because of it.
Change:
platforms = lib.platforms.unix; license = lib.licenses.lgpl21Plus; maintainers = [ lib.maintainers.atry ]; <ins> inherit knownVulnerabilities; </ins> }; }

Discussion:
The following security vulnerability in libdwarf has been published. We have two vulnerable versions: 0.4.0 The patch we need to apply is: Maintainer: Please reference the CVE id with in the commit message.
PTAL.
We cannot easily apply the patch provided by the upstream to the default version because the code base directory layout changes
Could you take a look at , please?
, I wonder how you noticed this vulnerability. Is there certain vulnerability workflow that ensures that every CVE in any package would be addressed or at least marked as .
I tried to find out how I first heard of this vulnerability, but I can't find the source anymore. It was neither an email nor on IRC. We have a coordination channel for security issue triage on Matrix. It's .
Thank you for the information.
Change:
for path in paths: path = pathlib.Path(path) <del> files = itertools.chain([path], path.rglob("*")) </del> <ins> if path.is_symlink(): files = [path] else: files = itertools.chain([path], path.rglob("*")) </ins> for filename in sorted(files): ti = append_root(tar.gettarinfo(filename))

Discussion:
Describe the bug Please see for a more thorough investigation than this. ~I'm not sure I'd really classify this as a bug, but it is a least surprising behaviour on some docker storage backends, so I'd like to document this. I'm not sure whether docker really has any formal semantics with respect to the loading process.~ The TL;DR: Some s may be usable on some storage backends but not on others when symlinked paths are involved. To Reproduce Consider: This image fails to load on an ext4/overlayfs setup: But succeeds on a zfs-backed docker setup: I imagine this is because of the storage backend's behaviour wrt. earlier layers' files. Expected behavior Image loads the same on all backends. Additional context This was discovered because our docker images became unpullable on some hosts (overlay) but not others (zfs) after crate2nix started using symlinks for tested builds: might find this interesting. :smile_cat:
docker.. sounds like an upstream issue, no? What happens if you do the equivalent in a Dockerfile?
Yes, I tend to agree, both backends should behave the same, but I'm afraid "overlay" is the de facto standard, so the functioning version is probably the buggy one. I may report this upstream, but it's at least surprising that can produce unpullable images (never happened to me before!) :grinning: Uh, that would require a working memory on how to make Dockerfiles... Stand by. :stuckouttongue:
I can't seem to reproduce this with Dockerfiles. I suspect it does some logic to avoid having symlink breakage across layers, but I haven't checked the source. Maybe we should do the same.
Scratch the above, my assumptions were wrong. Here's what I now think is going on, seen only from the perspective of an overlayfs setup (forget about zfs, I've no idea what process the clone/snapshot mechanism uses to make this magically "work" and to what extent it actually "works") Given the snippet: We get an image which has a layer containing: This, I think, is the main culprit.

If we go to the prior commit (the commented nixpkgs revision) the problem does not exist, and the corresponding layer looks like this: Which looks much more correct and doesn't have more than one entry for with one being a symlink (correct) and the other (implicitly) a directory. In other words, I believe this is a bug and was introduced in specifically in and relates to how disparate entries are somehow created because of some wonky symlink traversal. :smile_cat: cc
Change:
hdf5 libxml2 mpi <del> ]; </del> <ins> bzip2 libzip zstd ] ++ lib.optional szipSupport szip; </ins> passthru = { inherit mpiSupport mpi;

Discussion:
While rebuilding on this system that requires the package a failure while building has been occurring since NixOS 22.11. One of the tests fails.
I am not the maintainer of this package. Maybe can help? also have a look at:
Silly me for not checking and just the current release, disabling tests is a hell of a workaround but definitely works!
I'm also not a maintainer of the package, but I'm happy to fix it nonetheless :) There's an issue in that we don't have a good way of setting HDF5PLUGINPATH appropriately. Maybe I'll come back and fix this at some point, but for now this will do...
Change:
services.xmr-stak = { enable = mkEnableOption (lib.mdDoc "xmr-stak miner"); openclSupport = mkEnableOption (lib.mdDoc "support for OpenCL (AMD/ATI graphics cards)"); <del> cudaSupport = mkEnableOption (lib.mdDoc "support for CUDA (NVidia graphics cards)"); </del> extraArgs = mkOption { type = types.listOf types.str;

Discussion:
When attempting to enable the 'xmr-stak' service in the NixOS configuration by setting and then running , an error is encountered. This issue aims to report the error and seek resolution. Steps to reproduce the behavior: to the NixOS configuration. : . The 'xmr-stak' service should be able to install its required files and binaries into the system, and the rebuild process should proceed without encountering any errors. The error message received during the execution is as follows:
The error tells you that something passes parameter to . That parameter does not exist there. I removed the parameter in when noticed it was broken for a while. is still passing the option. Let's remove it as well. Meanwhile try to disable the option explicitly as:
Also /cc who the initial module.
Ah, sorry. It does not work as it tries to hass non-existent . I'll send a PR to rip out the option entirely.
Proposed the fix as
Change:
"--sysconfdir=/etc" "--libdir=$(lib)/lib" "--with-system-tzdata=${tzdata}/share/zoneinfo" <ins> "--enable-debug" </ins> (lib.optionalString enableSystemd "--with-systemd") (if stdenv.isDarwin then "--with-uuid=e2fs" else "--with-ossp-uuid") ] ++ lib.optionals icuEnabled [ "--with-icu" ];

Discussion:
It would be great to be able to obtain a version of postgres including debug symbols. (For people actually getting segfaults to properly report a backtrace for example. I know it doesn't seem like there are many bugs in postgres, but I'm actually running into on on version 13) It's a matter of passing the flags when building from source. so It seems that it should be another configure flag to add here However I'm not sure what's the best way to go about it, since each version should have a dbgsym version associated. perhaps just like version is inherited for every single package, add a attribute that would be defined in each package and add a new dbgsym version of each package? So far it seems to be what makes the most sense to me. I'm curious to have your opinion when you have a moment. Let me know if I'm missing anything. homepage URL: PS: completely unrelated, but it seems there is a typo here postgreql -postgresql
Change:
# will be omitted. ${if c.dbname != null then "--database-name" else null} = ''"${c.dbname}"''; ${if c.dbhost != null then "--database-host" else null} = ''"${c.dbhost}"''; <del> ${if c.dbport != null then "--database-port" else null} = ''"${toString c.dbport}"''; </del> ${if c.dbuser != null then "--database-user" else null} = ''"${c.dbuser}"''; "--database-pass" = ""$${dbpass.arg}""; "--admin-user" = ''"${c.adminuser}"'';

Discussion:
The configuration is ignored by when setting up the database as it is a configuration no longer used in the latest versions of See Steps to reproduce the behavior: up "dbhost" to "/run/postgresql", and "dbport" to anything else than 5432 (default pgsql port), let's say 5435 for example -setup.service will fail saying the file is not found In , the value should be set as instead, any field is ignored (and should then be deleted)
FYI
Change:
githubId = 6391776; name = "Nikita Voloboev"; }; <ins> niklaskorz = { name = "Niklas Korz"; email = "niklas@niklaskorz.de"; matrix = "@niklaskorz:korz.dev"; github = "niklaskorz"; githubId = 590517; }; </ins> NikolaMandic = { email = "nikola@mandic.email"; github = "NikolaMandic";

Discussion:
crashes during startup with: Judging by this upstream issue which has the same stack trace, the crash is caused by using an incompatible version of the dependency with . specifies but currently in nixpkgs it's provided with as a dependency. It seems that an older version should be used to fix the crash. Steps to reproduce the behavior: might somehow be specific to my (judging by the stack trace, it might be related to e2ee), so here's mine: in parts in the provided mautrix-signal No crash Please run and paste the result.
Hello I've learned that the mautrix-signal python package is no longer going to receive any updates as they are currently rewriting it in Go, so a fix from them (to use newer mautrix) will not happen soon (I mean never, just that the go port wont have that particular issue) Until the go port is ready to be used, I've made the below override for myself, which effectively undoes commit for the mautrix dependency
Change:
inherit rev sha256; }; <del> patches = [ ./BACKPORT-Linux-5.8-compat-__vmalloc.patch ] ++ extraPatches; </del> <ins> patches = extraPatches; </ins> postPatch = optionalString buildKernel '' patchShebangs scripts # The arrays must remain the same length, so we repeat a flag that is # already part of the command and therefore has no effect. <del> substituteInPlace ./module/zfs/zfs_ctldir.c --replace '"/usr/bin/env", "umount"' '"${utillinux}/bin/umount", "-n"'  --replace '"/usr/bin/env", "mount"'  '"${utillinux}/bin/mount", "-n"' </del> <ins> substituteInPlace ./module/${optionalString isUnstable "os/linux/"}zfs/zfs_ctldir.c  --replace '"/usr/bin/env", "umount"' '"${utillinux}/bin/umount", "-n"'  --replace '"/usr/bin/env", "mount"'  '"${utillinux}/bin/mount", "-n"' </ins> '' + optionalString buildUser '' substituteInPlace ./lib/libzfs/libzfs_mount.c --replace "/bin/umount"             "${utillinux}/bin/umount"  --replace "/bin/mount"              "${utillinux}/bin/mount" <del> substituteInPlace ./lib/libshare/nfs.c        --replace "/usr/sbin/exportfs"      "${ </del> <ins> substituteInPlace ./lib/libshare/${optionalString isUnstable "os/linux/"}nfs.c --replace "/usr/sbin/exportfs" "${ </ins> # We don't *need* python support, but we set it like this to minimize closure size: # If it's disabled by default, no need to enable it, even if we have python enabled # And if it's enabled by default, only change that if we explicitly disable python to remove python from the closure nfs-utils.override (old: { enablePython = old.enablePython or true && enablePython; }) }/bin/exportfs" substituteInPlace ./config/user-systemd.m4    --replace "/usr/lib/modules-load.d" "$out/etc/modules-load.d" <del> substituteInPlace ./config/zfs-build.m4       --replace "$sysconfdir/init.d"     "$out/etc/init.d" </del> <ins> substituteInPlace ./config/zfs-build.m4       --replace "$sysconfdir/init.d"     "$out/etc/init.d"  --replace "/etc/default"            "$out/etc/default" </ins> substituteInPlace ./etc/zfs/Makefile.am       --replace "$(sysconfdir)"          "$out/etc" substituteInPlace ./cmd/zed/Makefile.am       --replace "$(sysconfdir)"          "$out/etc"

Discussion:
Hello! I'd like to know whether, as the title says, it would be possible to update the ZFS derivation to the latest release candidate, , as it allows for compression, and I am exceptionally eager to try it out; if not, how could I update the derivation in my own configuration? Thank you kindly for your consideration on the matter!
Crosspost:
Change:
typos = callPackage ../development/tools/typos { }; <ins> typst = callPackage ../tools/typesetting/typst { }; </ins> tz = callPackage ../tools/misc/tz { }; u9fs = callPackage ../servers/u9fs { };

Discussion:
Project description Metadata homepage URL: source URL: license: Apache 2.0 platforms: unix, linux, darwin
Change:
<del> { mkDerivation, lib, fetchurl, fetchsvn , pkgconfig, cmake, ninja, python3, wrapGAppsHook, wrapQtAppsHook </del> <ins> { mkDerivation, lib, fetchurl, callPackage , pkgconfig, cmake, ninja, python3, wrapGAppsHook, wrapQtAppsHook, removeReferencesTo </ins> , qtbase, qtimageformats, gtk3, libsForQt5, enchant2, lz4, xxHash , dee, ffmpeg, openalSoft, minizip, libopus, alsaLib, libpulseaudio, range-v3 , tl-expected, hunspell

Discussion:
, CVSSv3=2.4 (nixos-20.09) Scanned versions: nixos-20.09: . Cc Cc
Fixed by .
Change:
addDriverRunpath cudaPackages.cuda_nvcc ] <del> ++ lib.optionals waylandSupport [ pkg-config ]; </del> <ins> ++ lib.optionals waylandSupport [ pkg-config wayland-scanner ]; </ins> buildInputs = [

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:
repo = "Floorp"; fetchSubmodules = true; rev = "v${packageVersion}"; <del> hash = "sha256-PhI+hIypPF6W5RJIXhCAXblSJNwgYavfCgdQozDSXG0="; </del> <ins> hash = "sha256-LRuts3O3Rj5e6rT9gKTTwAIsY0oSziuiZ3rzE7wHa7o="; </ins> }; extraConfigureFlags = [

Discussion:
Steps to reproduce the behavior: floorp or floorp-unwrapped The important bit at the end of the log: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yep, got the same.
It probably needs something like For now, I've just this overlay:
Yep, seems like the cause/fix. I'll send the update to v11.15.0 soon anyway and include this fix as necessary. The package in the binary cache is fine though, so if you just pull it from there instead of rebuilding this massive thing you'd be just fine too.
Change:
# build-tools , bootPkgs , autoconf, autoreconfHook, automake, coreutils, fetchurl, fetchpatch, perl, python3, sphinx <ins> , bash </ins> , runCommand , libiconv ? null, ncurses

Discussion:
The shebang line for is using instead of a path from the nix store. Here is a minimal example, showing the problem appearing between and : By using , I landed on , and I think the problematic commit is This commit reverts a previous reversal, The initial reversal mentions problems with shebangs for packages using bootstrap . cc who both worked on the pull request and did the various reversals.
Thank you and for the speedy fix.
Change:
meta.license = lib.licenses.lgpl3Only; }; <ins> sourcery.sourcery = callPackage ./sourcery.sourcery { }; </ins> spywhere.guides = buildVscodeMarketplaceExtension { mktplcRef = { name = "guides";

Discussion:
Add to packages <!-- Describe the project a little: -- is a non free package for Python which is available from this . Or it can be made available for VScode via this . Similar for Vim, Command Line, PyCharm, Emacs or Sublime. I tried to add this this to my within a vsocde section: { name = "sourcery.sourcery"; publisher = ""; version = "1.6.0"; sha256 = "0000000000000000000000000000000000000000000000000000"; } But result: Cant install sourcery for vscode: home-manager build switch produces building '/nix/store/ag5i8qpv0wkpayjvnkdi0dnwdmhrqa12-'... trying % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 400 error: cannot download from any mirror error: builder for '/nix/store/ag5i8qpv0wkpayjvnkdi0dnwdmhrqa12-' failed with exit code 1; last 7 log lines: For full logs, run 'nix log /nix/store/ag5i8qpv0wkpayjvnkdi0dnwdmhrqa12-'.

error: 1 dependencies of derivation '/nix/store/z62dqgjxbm3v3p4hj62bf4aa9nv8y1ix-vscode-extension-' failed to build error: 1 dependencies of derivation '/nix/store/y3rmcb7pcc9j03j0408dsn6g5cnzkvw5-' failed to build error: 1 dependencies of derivation '/nix/store/ixfc6bjhprz4n88zk6rsgzs8kas925xi-home-manager-' failed to build error: 1 dependencies of derivation '/nix/store/qfxzn9qqbzpq5mmsk1py6ni9lw70zhgk-home-manager-' failed to build` When I visit the link in browser I get: I note that searching Nix packages for sourcery produces a result for Code Sourcery C++ ABI, which is unrelated, hence the name should be distinctive. Metadata homepage URL: source URL: and and and license: mit platforms: linux, darwin
PR available.

Project description Automatically review and improve your Python code. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Analysis Naively installing the package with python works, but at runtime this error is shown most likely because it is a generic linux binary and we need to patchelf it. Is this analysis correct? Pointers Ideally the associated VS Code should be available as well. Related PR is .
Change:
) webserver.wait_for_open_port(80) webserver.succeed("curl http://localhost | grep hello") <ins> with subtest("explicit configFile"): webserver.succeed( "${explicitConfigFile}/bin/switch-to-configuration test >&2" ) webserver.wait_for_open_port(80) webserver.succeed("curl http://localhost | grep hello") </ins> ''; })

Discussion:
I wanted to configure caddy with my own config file, setting as documented in the option. Steps to reproduce the behavior: above snippet how caddy does not start, as does not exist. at the filesystem, observe there's a directory with a inside, while sets Possibly introduced in Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Looks like a regression to me. Will investigate further. Thanks for your report and the commit you suggested that might have introduced it :)
I don't think it's that commit. Can you try ?
I am pretty sure this documentation error has been introduced all the way back in . The option docs simply switched from to , but forgot to wrap add a at the end. And now we are somewhat stuck with behavior that expects it that way... sigh.
I think this in combination with introduced the breaking change, since we now always pass as the arg, but expect a basename of to enable the adapter.
It works if you do as demonstrated here: But it's ugly.
Alternatively do and explicitly set .
I tried with too, it doesn't work. I extended with an example (at least I think I did), and it fails. It's pushed to , if someone does a PR fixing the issue feel free to cherry-pick it in ;-)
With you also need to explicitly set .
Fixed it in (when using )
Can you also fix the writeTextDir case? That's what the documentation recommends to use...
I adjusted the documentation to use (which it used to be before )
I could also instead fix the case, if you have strong opinions, but this was a bit easier.
I think fixing the writeTextDir case makes more sense. That's what people might have in their configs, and getting everyone to notice they now need to write it like this, and update configs is worse UX than fixing the usage that was documented. Assuming it worked with 23.05 for example, but regressed with 23.11 again. That is, if this ever worked like this before. If it was broken all the time, no one could have a working config so it doesn't matter much :laughing:
Both and (without ) have been broken since , which landed in .
Ok, in that case, it's been broken for an entire release, so this is not just a regression when upgrading to 23.11. then it's probably ok.
Change:
csv2latex = callPackage ../tools/misc/csv2latex { }; <ins> csvq = callPackage ../development/tools/csvq { }; </ins> csvs-to-sqlite = callPackage ../tools/misc/csvs-to-sqlite { }; cucumber = callPackage ../development/tools/cucumber {};

Discussion:
csvq From the homepage: Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, bsd, netbsd, openbsd, (windows) Note I'm just getting started with nix and don't have a lot of experience with the nix DSL. If I find time I could look into this myself but some pointers where to start when submitting new packages are appreciated. If someone else is interested in doing this, that's also fine for me (and will probably be a lot quicker :smile:)
I beat you to it! The PR is .