jiebi/CodeConvo huggingface dataset:
Change:
url = "https://github.com/fmtlib/fmt/commit/78f041ab5b40a1145ba686aeb8013e8788b08cd2.patch"; sha256 = "hjE6Q/ubA4UhvuJXgcsA3wiGoDK031P19njQRL9JF8M="; }) <ins> # Fix cmake config paths. (fetchpatch { url = "https://github.com/fmtlib/fmt/pull/1702.patch"; sha256 = "18cadqi7nac37ymaz3ykxjqs46rvki396g6qkqwp4k00cmic23y3"; }) </ins> ]; nativeBuildInputs = [ cmake ];

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:
EOF moveToOutput "bin" "$bin" <del> '' + lib.optionalString (enableX11 || enableGL) '' </del> <ins> '' + (lib.optionalString (stdenv.isDarwin) '' for exe in $bin/bin/*; do install_name_tool -change build/shared-release/libmupdf.dylib $out/lib/libmupdf.dylib "$exe" done '') + (lib.optionalString (enableX11 || enableGL) '' </ins> mkdir -p $bin/share/icons/hicolor/48x48/apps cp docs/logo/mupdf.png $bin/share/icons/hicolor/48x48/apps <del> '' + (if enableGL then '' </del> <ins> '') + (if enableGL then '' </ins> ln -s "$bin/bin/mupdf-gl" "$bin/bin/mupdf" '' else lib.optionalString (enableX11) '' ln -s "$bin/bin/mupdf-x11" "$bin/bin/mupdf"

Discussion:
On my M1 macbook pro, a executing will complain with the following: Steps to reproduce the behavior: Version information is outputted, as dyn libs are found. Affects the package, which other packages depend on, like . Discovered when creating Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Ah hell, I don't know how I missed this. Thank you for the report! I'll have a fix prepared imminently
Please test if fixes the issue for you Thanks again!
Thanks for the fix!! I'll test as soon as I'm able -- likely tomorrow morning CT.
Works for me!
Has this fix been pushed into stable channel? As the version has been bumped to 1.23.6, I guess the fix () is already applied, but it still fails on my computer.
No, the fix is still in staging-next (in ) You can see progress to channels a bit more easily at
is now in nixos-unstable and nixpkgs-unstable I'm waiting on the backport PR () to make it to nixos-23.11 and then I'll close this issue
Fix should be on all supported channels now, closing
Change:
HZ = freeform "1000"; HZ_1000 = yes; } // lib.optionalAttrs (isLqx) { <del> # Google's BBRv2 TCP congestion Control TCP_CONG_BBR2 = yes; DEFAULT_BBR2 = yes; DEFAULT_TCP_CONG = freeform "bbr2"; </del> <ins> # Google's BBRv3 TCP congestion Control TCP_CONG_BBR = yes; DEFAULT_BBR = yes; DEFAULT_TCP_CONG = freeform "bbr"; </ins> # PDS Process Scheduler SCHED_ALT = yes;

Discussion:
Steps to reproduce the behavior: At the end of the logs - Introduced at Suspected offender - (pointed out by on Matrix) where the options were removed on and <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I'm working on a PR.
Change:
programs.chromium = { enable = mkEnableOption (lib.mdDoc "{command}`chromium` policies"); <ins> enablePlasmaBrowserIntegration = mkEnableOption (lib.mdDoc "Native Messaging Host for Plasma Browser Integration"); plasmaBrowserIntegrationPackage = mkPackageOption pkgs "plasma5Packages.plasma-browser-integration" { }; </ins> extensions = mkOption { <del> type = types.listOf types.str; </del> <ins> type = with types; nullOr (listOf str); </ins> description = lib.mdDoc '' List of chromium extensions to install. For list of plugins ids see id in url of extensions on

Discussion:
Describe the bug addon in chromium does not work. After install addon show errors: "Failed to connect to the main process." "Verify the installation of the plasma-browser-integration package. The running environment of the Plasma desktop environment must be at least version 5.13." "Specified native messaging host not found." Manually run from console not help. To Reproduce Steps to reproduce the behavior: Add to : Expected behavior No errors. Additional context I found issue Everything looks like the same problem but in chromium Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run nix-shell -p nix-info --run "nix-info -m" and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Try adding the following line to your configuration:
now And also does not work. Maybe I need to reboot?
That issue is actually unrelated, it has to do with a patch only in our source build of firefox.
I make test with: in . The same error.
I can't reproduce this issue. I just tested in a vm using with this configuration: Are you using plasma5?
Yes plasma5. Looks like it worked for me too. Now all errors are gone. Thanks !
Why are we adding to systemPackages when using the chromium program module? It does this for you.
Just an oversight on my part. You're right, adding chromium to systemPackages is not necessary.
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 .
Thanks - the fix worked for me! Can you please comment on what's the role of package that you install?
I marked this as stale due to inactivity. &rarr;
Proposed fix in
Change:
a corporation. ''; license = licenses.gpl3; <del> platforms = platforms.all; maintainers = with maintainers; [ codyopel ]; </del> <ins> maintainers = with maintainers; [ ]; </ins> inherit branch knownVulnerabilities; }; }

Discussion:
, CVSSv3=5.5 (nixos-21.11, nixos-unstable) An integer overflow vulnerability was found in FFmpeg 5.0.1 and in previous versions in g729parse() in llibavcodec/g729parser.c when processing a specially crafted file. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc
fixed by
Change:
<del> source 'https://rubygems.org' gem "fusuma", ">=3.0.0" gem "fusuma-plugin-appmatcher" gem "fusuma-plugin-keypress" gem "fusuma-plugin-sendkey" gem "fusuma-plugin-wmctrl" # I've not activated the following plugins for the reasons given below. # tap has been archived by upstream # gem "fusuma-plugin-tap" # touchscreen needs specific h/w support I don't have access to, so I can't confirm # if it's problem free.  A quick check didn't reveal any problems. #gem "fusuma-plugin-touchscreen" # thumbsense pulls in remap, and at best remap requires further configuration to allow the use access to event devices. #gem "fusuma-plugin-thumbsense" #gem "fusuma-plugin-remap" </del>

Discussion:
Package name: fusuma Latest released version: 3.5.0 <!-- Search your package here: --- Current version on the unstable channel: 3.3.1 Current version on the stable/release channel: 3.3.1 <!-- 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]. By the way, fusuma now use yml file instead of yaml file as config file. now when I use HM , it will generate a yaml file in .config, please update it to change it to a yml file. and when I use = true; it wont be installed. [reaction]: [issues you find important]:
I guess that this should be addressed at home-manager repository as nixpkgs does not offer a fusuma service, as far as I rembember
you are right
Already fixed in home-manager:
sorry, I don't understand. if it has been fixed, why I still have the same issue? I just installed yesterday.
Are you perhaps not on ?
ah, right. I use stable nixos and HM, install some new software with pkgs-unstable. But this is a service, how do I change the package to unstable version? I tried = pkgs- But the result is still same.
It's fixed on master branch of Home Manager and not have been backported to release-23.11. Home manager master always follows the NixOS unstable branch, so I won't suggest switching to master branch of HM unless you upgrade your system to nixos-unstable.
Change:
, xclip , xdotool , makeWrapper <ins> , stdenv , AppKit , Cocoa , Foundation </ins> }: rustPlatform.buildRustPackage rec {

Discussion:
Trying to install espanso on osX, there are missing libraries, even after trying to install and Steps to reproduce the behavior: tries to compile fails with The build should work on osX n/a latest osX with nixpkgs 21.15 and nix-darwin Please run and paste the result.
You cannot install libraries (), they need to be to the package definition.
I tried adding them as dependencies, but the build still fails with the same error
I marked this as stale due to inactivity. &rarr;
Change:
nixui = callPackage ../tools/package-management/nixui { node_webkit = nwjs_0_12; }; <del> nix-prefetch-scripts = callPackage ../tools/package-management/nix-prefetch-scripts { }; </del> <ins> inherit (callPackages ../tools/package-management/nix-prefetch-scripts { }) nix-prefetch-bzr nix-prefetch-cvs nix-prefetch-git nix-prefetch-hg nix-prefetch-svn nix-prefetch-zip nix-prefetch-scripts; </ins> nix-template-rpm = callPackage ../build-support/templaterpm { inherit (pythonPackages) python toposort; };

Discussion:
It's frustrating to have to build all the version control systems (in master or another development branch without binary caches) when I just need to prefetch git :frowning:
Make the expression modular so you can disable those?
Implementation at:
Change:
tests = { inherit (nixosTests) mpv; <del> version = testers.testVersion { package = finalAttrs.finalPackage; }; </del> <ins> version = testers.testVersion { package = finalAttrs.finalPackage; }; </ins> pkg-config = testers.hasPkgConfigModules { package = finalAttrs.finalPackage; moduleNames = [ "mpv" ];

Discussion:
Steps to reproduce the behavior: mpv-unwrapped on x86_64-darwin Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Unless I got confused this is still a problem on nixos-unstable, but according to the fix was merged there
It looks like not a same error?
You're right. This one seems like it's originating in swift.
I was also confused because I have the same error when building mpv, but yeah looks like a swift error. Any solutions?
The build-failure reported in this issue seems to be unrelated to the recent swift breakage on Darwin. Where swift-dependent packages like mpv are currently broken on Darwin. I suggest opening a separate issue to track mpv's build-failure due to swift on Darwin. There is an open-issue for the swift build failure at .
Change:
buildInputs = with gnome3; [ gsettings_desktop_schemas gnome_keyring gnome-menus glib gcr json_glib accountsservice <del> libcroco intltool libsecret pkgconfig python3 libsoup polkit libcanberra gdk_pixbuf librsvg </del> <ins> libcroco intltool libsecret pkgconfig python3 python3Packages.pygobject3 libsoup polkit libcanberra gdk_pixbuf librsvg </ins> clutter networkmanager libstartup_notification telepathy_glib docbook_xsl docbook_xsl_ns libXtst p11_kit networkmanagerapplet gjs mutter libpulseaudio caribou evolution_data_server libical libtool nss gobjectIntrospection gtk gstreamer makeWrapper gdm

Discussion:
System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:
Change:
sha256 = "12fra2fdwqj6ilv9wdkc33rkj343rdcf5jyff4yiwywlrwaa2l1p"; }; <ins> patches = [ ./001-darwin-fixes.patch ]; </ins> configureFlags = optional (!sslSupport) "--disable-ssl"; <del> buildInputs = [ ncurses zlib ] ++ optional sslSupport openssl; </del> <ins> buildInputs = [ ncurses zlib ] ++ optional sslSupport openssl; </ins> # Workaround build failure on -fno-common toolchains like upstream # gcc-10. Otherwise build fails as:

Discussion:
Steps to reproduce the behavior: tinyfugue on aarch64-darwin command: full log: <!-- 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]:
Willing to contribute, but I don't know exactly how tinyfugue is built. I can also help with testing on MacOS if needed.
I think it's fixed, works on my , if you could have a look it would be great: or if you don't have checked out:
Change:
fetchSubmodules = true; }; <del> buildInputs = [ wayland-protocols wlroots pixman libxkbcommon pixman udev libevdev libX11 libGL </del> <ins> nativeBuildInputs = [ zig wayland xwayland scdoc pkg-config ]; buildInputs = [ wayland-protocols wlroots pixman libxkbcommon pixman udev libevdev libX11 libGL </ins> ]; dontConfigure = true;

Discussion:
Describe the bug Running river on nixos unstable results in this error: which is caused by this instruction: It is an , and i'm using AMD FX 6350, which only supports regular AVX It seems that zig basically uses something like by default, which is questionable to say at least. I couldn't find an easy way to fix it, so i will leave this as an issue. All other zig packages are possibly affected too, needs verification. To Reproduce Steps to reproduce the behavior: Expected behavior Doesn't use AVX2, build is reproducible. Notify maintainers Metadata Maintainer information:
What I have to do with it if it's not just river but Zig itself? You can ask zig maintainer (creator itself) about it. I will also ask community and river developers.
This is correct, zig builds for the current host by default. If a cross-compile should be performed, a target triple should be given () for example, assuming glibc/GNU abi is used. This is usually passed by to a build script or via on a normal build command line. The code here only builds for the local machine, so it might not be shared with other machines:
So one person on NixOS discord server suggested one simple solution. To eleminate problems like this, user will build river on own hardware, this will prevent problems like this to happen as pointed above Zig takes everything from host e.g libc, ABI, cpu architecture so building it on user's hardware will use those attrinutes according to their hardware, ABI amd libc. Building river doesn't take more then 20s at least on my old 2 core CPU and I don't think bulding it locally is big problem
This is exactly what the creator of the issue is pointing at as a problem, and the only good solution (at least in the Nix way) is to make all programs compiled with Zig target baseline x86_64 (or ultimately whichever features the Nixpkgs pipeline allows in C/C++ derivations) The idea of packaging with Nix is not just "being able to compile and done" but rather being able to compile deterministically.
Indeed, passing to is the correct solution here, and will produce a binary for baseline x86_64.

After the next zig release (planned for ~2 weeks from now) passing will be an even better way of doing this, allowing the target to be entirely detected from the host system and allowing specific cpu features to be enabled/disabled.
Change:
# Do a full repack. Must run single-threaded, or else we lose determinism. clean_git config pack.threads 1 clean_git repack -A -d -f <del> rm -f .git/config </del> <ins> rm -f "$dotgit_dir/config" </ins> # Garbage collect unreferenced objects. # Note: --keep-largest-pack prevents non-deterministic ordering of packs

Discussion:
fails when using and with repositories that contain submodules. A checked-out repository that contains modules will have files pointing to . git uses files to "link" submodules gitdirs to the root path. I'm not sure if this is new git behavior and thus it broke . See below in the reproduction section. () tries to list directories and get their parent paths with , but finds files and fails. , it fails silently and won't return an error to the parent shell (and won't trigger ), so in these cases is called and fails with "not a git repository" errors. A possible fix is to use to filter directories. I believe this option/value is portable. This will only give directory paths and avoid the very subtly error. Checked-out repository with submodule: Emulating the branch: Expected to correctly fetch a repository with submodules and leave directories intact when is true. I'm not sure who are owners. I'm tagging the last 3 who touched :
Could be triggered by , if you revert it does it work?
I can't test right now, but from a cursory reading, I think it indeed does, because it changed behavior from A) manually getting all submodules urls and manually cloning the repos, which will result in directories, to B) , which generates files, like I described above.
Sounds good, can you make a PR? This also means that probably the hash is now different.
I tried adding to both of these instances: But I ended up with a non-deterministic hash for some reason - every run would result in a different hash. Reverting does fix the issue though. should we revert that commit until this is sorted out?
I can help fix it if you find a good example within nixpkgs repo to test with.
there are only a few cases where both flags are used in nixpkgs. At least from searching with . Only one I could find was : But for some reason it doesn't reproduce this issue. I'm not sure we currently have a derivation in nixpkgs that reproduces this. I've been able to reproduce this easily with a derivation which uses this :
I can reproduce this issue in the following case:
Could you test
I tested with and it worked. The repository in question and even , which triggers the bug in .

I wasn't sure what's the best practice when dealing with projects relying on git to build correctly and since it's hardcoded in that project's build script with no trivial solution (like setting an env var or passing a CLI flag), I was actually trying to build it as-is. Now that I see landed, my question was answered: just patch it out. Anyway, the bug still exists and it seems works for this specific repository, even with all the shenanigans at build time. Thanks
Change:
{ stdenv, fetchurl, lib, iasl, dev86, pam, libxslt, libxml2, libX11, xproto, libXext , libXcursor, libXmu, qt5, libIDL, SDL, libcap, zlib, libpng, glib, lvm2 , libXrandr, libXinerama <del> , which, alsaLib, curl, libvpx, gawk, nettools, dbus , xorriso, makeself, perl, pkgconfig </del> <ins> , pkgconfig, which, docbook_xsl, docbook_xml_dtd_43 , alsaLib, curl, libvpx, gawk, nettools, dbus , xorriso, makeself, perl </ins> , javaBindings ? false, jdk ? null , pythonBindings ? false, python2 ? null , enableExtensionPack ? false, requireFile ? null, patchelf ? null, fakeroot ? null

Discussion:
virtualbox in headless mode currently doesn't compile on nixpkgs-unstable. results.
Seems they forget one file when converting from use of NOREF to their new RTNOREF[n] You could fix it like this (worked for me YMMV) mv src/VBox/HostServices/SharedClipboard/x11- src/VBox/HostServices/SharedClipboard/x11-; sed -e '/^[ ]NOREF([^,)]{1,})/ s/NOREF/RTNOREF1/' src/VBox/HostServices/SharedClipboard/x11- sed -e '/^[ ]NOREF([^,)]{1,},[^,)]{1,},[^,)]{1,},[^,)]{1,})/ s/NOREF/RT_NOREF4/' src/VBox/HostServices/SharedClipboard/x11-; diff -w src/VBox/HostServices/SharedClipboard/x11- src/VBox/HostServices/SharedClipboard/x11-;
Change:
services.prometheus.exporters.minio.minioAddress  = mkDefault "http://localhost:9000"; services.prometheus.exporters.minio.minioAccessKey = mkDefault config.services.minio.accessKey; services.prometheus.exporters.minio.minioAccessSecret = mkDefault config.services.minio.secretKey; <del> })] ++ [(mkIf config.services.rspamd.enable { services.prometheus.exporters.rspamd.url = mkDefault "http://localhost:11334/stat"; </del> })] ++ [(mkIf config.services.prometheus.exporters.rtl_433.enable { hardware.rtl-sdr.enable = mkDefault true; })] ++ [(mkIf config.services.nginx.enable {

Discussion:
current version: unstable-2017-10-06 desired version: 0.2.0 maintainers:
An option in the service definition to overwrite the package would be nice, too! :smile:
Why is this needed? -options are usually implemented if modifying the package in question with an overlay is a bad idea because it would mean that a lot of leaf-packages would require a rebuild as well. An example for that would be .
Ah, okay.
could you please update this package?
Oh sure, thank you for the ping :)
Change:
{ lib , stdenv , fetchFromGitLab <del> , fetchpatch </del> , meson , ninja , pkg-config

Discussion:
With merged we want to eventually drop . That'll take at least a couple of months though and we still have around as well. I'll just open this issue so that we don't forget about it. The affected packages should switch to the latest wlroots release when possible (usually a new upstream release). There's no hurry but let's use this issue to track the current progress. Packages: TODO (currently all packages that depend on wlroots -I'll update this when we're getting closer) Previous issue:
need rebuild [x] waybar [x] mpvpaper [x] qt-video-wlr [x] wl-gammactl [x] hyprpicker TODO [ ] hikari [x] waybox: [x] pywlroots: 0.16 has been released and adapted to wlroots 0.16, but qtile need pywlroots 0.15 [x] qtile [x] phoc [x] cage: [x] cagebreak
Change:
konversation = callPackage ../applications/networking/irc/konversation { }; <del> ktikz = callPackage ../applications/graphics/ktikz { }; </del> kvirc = callPackage ../applications/networking/irc/kvirc { }; krename = callPackage ../applications/misc/krename/kde4.nix {

Discussion:
KtikZ development continues , but retaining the older KDE 4-based package obstructs removal of its dependencies. Attn.
I have a patch working for qtikz with qt5. We can live without KDE integration and temporarily drop ktikz.