jiebi/CodeConvo huggingface dataset:
Change:
"-Ddvb=disabled" "-Dfbdev=disabled" "-Duvch264=disabled" # requires gudev <ins> "-Dv4l2codecs=disabled" # requires gudev </ins> "-Dladspa=disabled" # requires lrdf "-Dwebrtc=disabled" # requires libnice, which as of writing doesn't work on Darwin in nixpkgs "-Dwildmidi=disabled" # see dependencies above

Discussion:
Describe the bug Building gst-plugins-bad-1.18.0 errors out on Darwin with: To Reproduce On master: Expected behavior should compile Additional context Version bump from 1.16.2 -1.18.0 in includes new dependencies libmicrodns and libva that might be incompatible for macOS Notify maintainers Metadata
has tags on the right so chances are that isn't true and that it works on Darwin. Could you try in there?
leads to continuing down this rabbit hole leads to libpciaccess is pulled in by libdrm, which is pulled in by libva, which is pulled in by gst-plugins-bad as mentioned above. Since the cited attribute is in I don't suppose it is feasible for Darwin.
Thanks, I hadn't found that override, that's what I needed to know. This might fix it, give it a try: PR
build continues as expected, yet leads to
gist of meson-
Probably needs in on Darwin, looking at:
so disabling v4l2codecs solved the problem. Complete diff:
just noticed your comment. Yes, indeed, that was the last piece. Thx.
Change:
buildFishPlugin rec { pname = "autopair"; <del> version = "1.0.3"; </del> <ins> version = "1.0.4"; </ins> src = fetchFromGitHub { owner = "jorgebucaran"; repo = "autopair.fish"; rev = version; <del> sha256 = "sha256-l6WJ2kjDO/TnU9FSigjxk5xFp90xl68gDfggkE/wrlM="; </del> <ins> sha256 = "sha256-s1o188TlwpUQEN3X5MxUlD/2CFCpEkWu83U9O+wg3VU="; </ins> }; meta = with lib; { description = "Auto-complete matching pairs in the Fish command line"; homepage = "https://github.com/jorgebucaran/autopair.fish"; license = licenses.mit; <del> maintainers = with maintainers; [ kidonng ]; </del> <ins> maintainers = with maintainers; [ figsoda kidonng thehedgeh0g ]; </ins> }; }

Discussion:
Currently, there are two almost identical packages for in nixpkgs. They were merged in CC
Change:
flat-remix-gtk = callPackage ../data/themes/flat-remix-gtk { }; flat-remix-gnome = callPackage ../data/themes/flat-remix-gnome { }; <del> fluent-gtk-theme = callPackage ../data/themes/fluent-gtk-theme { }; </del> fluent-icon-theme = callPackage ../data/icons/fluent-icon-theme { }; font-awesome_4 = (callPackage ../data/fonts/font-awesome { }).v4;

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:
<ins> { network = { description = "Legacy Network using <nixpkgs> and legacy state."; # NB this is not really what makes it a legacy network; lack of flakes is. storage.legacy = { }; }; server = { lib, pkgs, ... }: { deployment.targetEnv = "none"; imports = [ ./base-configuration.nix (lib.modules.importJSON ./server-network.json) ]; environment.systemPackages = [ pkgs.hello pkgs.figlet ]; }; } </ins>

Discussion:
Describe the bug introduced a change that breaks NixOps. When we have a test, something like this will be detected faster and not depend on users running into an issue. That would increase the quality. To Reproduce Steps to reproduce the behavior: nixops complain :grimacing:
I marked this as stale due to inactivity. &rarr;
Tests would still be nice. has been more broken than I expected...
I marked this as stale due to inactivity. &rarr;
Change:
# nscd needs libgcc, and we don't want it dynamically linked # because we don't want it to depend on bootstrap-tools libs. echo "LDFLAGS-nscd += -static-libgcc" >> nscd/Makefile <ins> '' # FIXME: find a solution for infinite recursion in cross builds. # For now it's hopefully acceptable that IDN from libc doesn't reliably work. + lib.optionalString (stdenv.hostPlatform == stdenv.buildPlatform) '' </ins> # Ensure that libidn2 is found. patch -p 1 <<EOF

Discussion:
Describe the bug Cross-compilation is broken since we bumped to glibc 2.30. To Reproduce Maintainer information:
I opened a workaround PR :arrow_up: Cross (boot) is probably best known by &ndash; in case you know pointers how to fix this better. (Possibly later; I don't expect we want to wait long with this PR.)
Change:
<ins> { stdenvNoCC, lib, linuxPackages }: stdenvNoCC.mkDerivation { pname = "rtw89-firmware"; inherit (linuxPackages.rtw89) version src; dontBuild = true; installPhase = '' runHook preInstall mkdir -p $out/lib/firmware/rtw89 cp *.bin $out/lib/firmware/rtw89 runHook postInstall ''; meta = with lib; { description = "Driver for Realtek 8852AE, an 802.11ax device"; homepage = "https://github.com/lwfinger/rtw89"; license = licenses.unfreeRedistributableFirmware; maintainers = with maintainers; [ tvorog ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux
Change:
graph-easy = callPackage ../tools/graphics/graph-easy { }; <del> mangal = callPackage ../applications/misc/mangal { }; </del> mermaid-filter = callPackage ../tools/misc/mermaid-filter { }; graphw00f = callPackage ../tools/security/graphw00f { };

Discussion:
Steps to reproduce the behavior: mangal Add any other context about the problem here. <!-- 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]:
Change:
ln -s ${hwi}/bin/hwi $out/modules/com.sparrowwallet.sparrow/native/linux/x64/hwi ''; }; <del> # To use the udev rules for connected hardware wallets, # add "pkgs.sparrow" to "services.udev.packages" and add user accounts to the user group "plugdev". udev-rules = stdenv.mkDerivation { name = "sparrow-udev"; src = let version = "2.0.2"; in fetchurl { url = "https://github.com/bitcoin-core/HWI/releases/download/${version}/hwi-${version}.tar.gz"; sha256 = "sha256-di1fRsMbwpHcBFNTCVivfxpwhUoUKLA3YTnJxKq/jHM="; }; installPhase = '' mkdir -p $out/etc/udev/rules.d cp -a hwilib/udev/* $out/etc/udev/rules.d rm $out/etc/udev/rules.d/README.md ''; }; </del> in stdenv.mkDerivation rec { inherit pname version src;

Discussion:
Steps to reproduce the behavior: sparrow Add any other context about the problem here. <!-- 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.
TLDR; This was caused by and is fixed in Upstream bundles a JDK/JRE with sparrow. Our sparrow package does not use the bundled JDK and instead replaces it with a JDK from Nixpkgs. Since the sparrow bundle contains the JDK and the sparrow code in a single JIMAGE, the sparrow package compares the files in the JIMAGE with the files provided by the JDK in Nixpkgs in order to determine which files in the JIMAGE are part of the JDK. Those files are then excluded from the sparrow derivation. When disabled JavaFX by default it changed the output of the aforementioned comparison, leaving behind some files which belong to the JDK as part of the sparrow derivation; The files which are part of JavaFX. This in turn causes the patchelf procedure to fail because the sparrow package is only expected to patch sparrow-specific dependencies, not the JDK.
Change:
, python3Packages , gtk3 , poppler_gi <ins> , libhandy </ins> }: python3Packages.buildPythonApplication rec { pname = "pdfarranger"; version = "1.10.1"; <ins> pyproject = true; </ins> src = fetchFromGitHub { <del> owner = pname; repo = pname; </del> <ins> owner = "pdfarranger"; repo = "pdfarranger"; </ins> rev = "refs/tags/${version}"; hash = "sha256-l//DeaIqUl6FdGFxM8yTKcTjVNvYMllorcoXoK33Iy4="; };

Discussion:
In pdfarranger 1.10.1 (from 23.11 stable branch) the option to change the theme in the preferences is greyed out and doesn't respect the globally set dark mode in GNOME. The program offers the hint "(Libhandy missing)" next to the greyed out setting (see image below). Steps to reproduce the behavior: pdfarranger preferences changing the theme setting The drop-down menu is clickable and offers several different options to choose from. ! Manually adding the package libhandy in environment.systemPackages doesn't work. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for your quick reply, . I'm new to Git and GitHub, do I have to do something now, like close this issue manually or will it be closed automatically after the changes are merged? Thanks again!
Don't worry issue will be closed automatically when the changes are merged into master (usually by the person who does the merge).
Change:
{ lib , buildPythonPackage , fetchFromGitHub <ins> , python </ins> , regex <del> # Test inputs , pytestCheckHook </del> }: buildPythonPackage rec { pname = "lark-parser"; <del> version = "0.11.2"; </del> <ins> version = "0.11.3"; </ins> src = fetchFromGitHub { owner = "lark-parser"; repo = "lark"; rev = version; <del> sha256 = "1v1piaxpz4780km2z5i6sr9ygi9wpn09yyh999b3f4y0dcz20pbd"; </del> <ins> sha256 = "1ggvlzpdzlrxl46fgi8cfq2rzlwn21shpdkm4pknnhfjlsinv913"; </ins> }; <ins> # Optional import, but fixes some re known bugs & allows advanced regex features </ins> propagatedBuildInputs = [ regex ]; <del> checkInputs = [ pytestCheckHook ]; disabledTestPaths = [ "tests/test_nearley" # requires Js2Py package (not in nixpkgs) ]; disabledTests = [ "test_override_rule"  # has issue with file access paths ]; </del> <ins> checkPhase = '' runHook preCheck # Official way to run the tests. Runs unittest internally. # pytest produces issues with some test resource paths (relies on __main__) ${python.interpreter} -m tests runHook postCheck ''; </ins> meta = with lib; { description = "A modern parsing library for Python, implementing Earley & LALR(1) and an easy interface"; <del> homepage = "https://github.com/lark-parser/lark"; </del> <ins> homepage = "https://lark-parser.readthedocs.io/"; changelog = "https://github.com/lark-parser/lark/releases/tag/${version}"; </ins> license = licenses.mit; maintainers = with maintainers; [ fridh drewrisinger ]; };

Discussion:
Describe the bug gremlinpython (a dependency of cassandra-driver, but otherwise no idea how important it is) fails to build. To Reproduce Steps to reproduce the behavior: a recent checkout of nixpkgs -build -I nixpkgs=. -p python3Packages.gremlinpython how attempts to fetch something from the interwebs Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(cmm): nixpkgs: Maintainer information:
Should be fixed by .
Change:
rmdir $out/usr/bin || true mv $out/usr/share $out/ <ins> rm -f $out/opt/SpiderOakONE/lib/libz* </ins> patchelf --set-interpreter ${stdenv.glibc.out}/lib/${interpreter}  "$out/opt/SpiderOakONE/lib/SpiderOakONE"

Discussion:
Spideroak GUI does not work in NixOS unstable. When running , I get this error: As far as I am able to tell, headless mode runs fine. Install spideroak and try to run . System: 17.09pre102667. (Hummingbird) Nix version: nix-env (Nix) 1.11.7 Nixpkgs version: "17.09pre102667."
Python uses the default zlib which is currently 1.2.11. I see the following options: override Python expression and use an older version of zlib let spideroak use our version of libpng. cc
Well the package's approach is strange to me. It installs private versions of libs that depend on libs not installed (e.g. freetype), and at the same time, some of the missing libs naturally depend on libs that are also installed privately (on zlib, for example). You can try such tweaks to find what will work now, but I'm afraid it's likely to remain fragile.
Change:
<del> { stdenv , cmake , python3 , writeTextFile , protobuf , src , version </del> <ins> { stdenv, cmake, python3, writeTextFile, protobuf, src, version, </ins> }: let pyproject_toml = writeTextFile { name = "pyproject.toml";

Discussion:
Steps to reproduce the behavior: nanopb, nanopbMalloc Add any other context about the problem here. <!-- 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]:
Change:
<del> { lib , buildPythonPackage , fetchFromGitHub , pam }: buildPythonPackage rec { pname = "python-pam"; version = "1.8.4"; src = fetchFromGitHub { owner = "FirefighterBlu3"; repo = pname; rev = "v${version}"; sha256 = "0gp7vzd332j7jwndcnz7kc9j283d6lyv32bndd1nqv9ghzv69sxp"; }; buildInputs = [ pam ]; postPatch = '' sed "s|find_library("pam")|"${pam}/lib/libpam.so"|g" -i pam.py ''; meta = with lib; { description = "Python pam module supporting py3 (and py2)"; homepage = "https://github.com/FirefighterBlu3/python-pam"; license = licenses.mit; maintainers = with maintainers; [ mkg20001 ]; }; } </del>

Discussion:
Describe the bug , which provides the "pam" namespace to everything in python-packages. This is fine, except this also broke the definition of , which packages the same library at the same version. To Reproduce Steps to reproduce the behavior: build result/lib/python3.8/site- points at a non-existent SO in the "pam" Python package Expected behavior Only one, working definition of this Python package. Additional context Add any other context about the problem here. 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 and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
The problem is that the python-pam probably is referencing the pam python package from the current scope, which I solved in my package by inheriting from the parent scope. The reason why pam was created in the first place is because I got confused because of the name and I imagine the reason it was named python-pam by the original author is to solve the inherit issue in another way, namely renaming it. I'd be in favour of the name "pam" because that's how the module is being called (unless both modules do have differences, then we need both)
I'm not particularly fussed about which one "wins", just that we should probably only have one of them. I agree that "pam" is probably a better name - it's just a little unergonomic to use in the tree.
Thanks for reporting. See
Change:
(rWrapper.override { packages = with rPackages; [ data_table <ins> jsonlite </ins> parallel BiocManager ];

Discussion:
relies on MRAN mirror, which at the end of this month. Could we switch to another mirror such as CRAN/posit package manager?
We do need to switch, not just the update script but currently CRAN packages are fetched from MRAN. Official CRAN mirrors would be preferable but the organisation is not ideal as the archive tarballs are at a different path to the latest release.
is a similar service. I'm not sure if it's equivalent to MRAN. or could work
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
assertions = [ { assertion = cfg.enableSSL <del> -> cfg.certFile != null && cfg.keyFile != null && cfg.caFile != null; message = "SSL is enabled for ttyd, but no certFile, keyFile or caFile has been specified."; } </del> <ins> -> cfg.certFile != null && cfg.keyFile != null; message = "SSL is enabled for ttyd, but no certFile or keyFile has been specified."; } </ins> { assertion = cfg.writeable != null; message = "services.ttyd.writeable must be set"; } { assertion = ! (cfg.interface != null && cfg.socket != null);

Discussion:
has an assertion on enableSSL that requires certFile, keyFile, and caFile, but caFile is optional with SSL and only used for client certificate validation. ttyd is able to serve over SSL with valid certificates Steps to reproduce the behavior: builds with the provided options Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I've committed a fixed file to my own flake that fixes the assertion (as well as adding the "--ssl" flag, which was missing)
please view
Change:
glib gdk-pixbuf libadwaita <ins> python3Packages.libpwquality.dev # Use python-enabled libpwquality </ins> ]; propagatedBuildInputs = with python3Packages; [

Discussion:
When trying to start gnome-secrets it fails with the message: Steps to reproduce the behavior: -shell -p gnome-secrets --run "secrets" Please run and paste the result.
Also gnome-secrets 6.4 is available. Updating it to the latest version doesn't solve the issue :(
Fixed by
Thank you for your work!
Change:
overrideWith = newArgs: origArgs // (if builtins.isFunction newArgs then newArgs origArgs else newArgs); in if builtins.isAttrs ff then (ff // { <del> overridePythonAttrs = newArgs: makeOverridable f (overrideWith newArgs); </del> <ins> overridePythonAttrs = newArgs: makeOverridablePythonPackage f (overrideWith newArgs); </ins> }) else if builtins.isFunction ff then { <del> overridePythonAttrs = newArgs: makeOverridable f (overrideWith newArgs); </del> <ins> overridePythonAttrs = newArgs: makeOverridablePythonPackage f (overrideWith newArgs); </ins> __functor = self: ff; } else ff;

Discussion:
The currently recommended way of overriding Python packages seem to be using . Yet, was overridable. Am I missing something? Would it be hard to make overridable? Works with import &lt;nixpkgs{}; ((old: { name = "pillow-override"; })).overrideDerivation(old: { }) Does not with import &lt;nixpkgs{}; ((old: { name = "pillow-override"; })).overridePythonAttrs(old: { })
I tried to look into how this is done for, but this seem be still beyond my Nix skills.
Could you test
Change:
enableParallelBuilding = true; <ins> postInstall = '' for prog in rootbrowse rootcp rooteventselector rootls rootmkdir rootmv rootprint rootrm rootslimtree; do wrapProgram "$out/bin/$prog"  --prefix PYTHONPATH : "$out/lib" done ''; </ins> setupHook = ./setup-hook.sh; meta = with stdenv.lib; {

Discussion:
Describe the bug I think this is another problem: After installing root (I'm using ), when I launch , I got the following error: I managed to find an improper workaround: First I located the installation directory of : Then I manually specify the location of the Python library that comes with : Now can launch properly. To Reproduce Steps to reproduce the behavior: in in terminal Expected behavior It should run without problem. Metadata Please run and paste the result. Maintainer information:
It is worth noting that if I manually source the supplied , can run without problem, and I can import in a Python 3 interpreter. I think a (not the) reasonable approach would be: globally usable, since it really is an utility the Python moduel as-is (not available unless explicitly sourced by user) Arch linux takes the approach above, and they copy the module to global Python library path. But I'm not sure on how to do this sanely in nix. For example, in my overlay, I have Python defined as: But I don't know how to include ---a Python library provided by package---globally.
Alternatively, I can just source in my login shell. Which is actually not too bad.
Yes, you are right about needing to source This is done automatically in our for , so everything works when is used in other nix builds and in nix-shell: nix-env does not run setupHook, so you would need to source it yourself, the way ROOT was intended to be used. In nixpkgs we usually make sure that all of the binaries are wrapped or patched to be able to find their libraries in any environment, so this is considered to be a bug.
Change:
let outputs = drv.outputs or [ "out" ]; <del> commonAttrs = drv // (builtins.listToAttrs outputsList) // </del> <ins> commonAttrs = (removeAttrs drv [ "outputUnspecified" ]) // (builtins.listToAttrs outputsList) // </ins> ({ all = map (x: x.value) outputsList; }) // passthru; outputToAttrListElement = outputName:

Discussion:
when installing only one output of a python package, eg with , all output of the package are installed. this seems to be limited to python packages (and possibly other users of ?) and can be fixed by overriding the output in question to set so that buildEnv does not ignore the request, so it seems that maybe installing everything all the time is not entirely expected behaviour? system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
cc seems to be mostly your code involved here? no idea who else to ping, sorry
the root cause seems to be that python calls extendDerivation on something that already had extendDerivation called on in. the first call introduces the attributes (by propagating from the builtin derivation) for every output and sets outputUnspecified. the second call propagates outputUnspecified to the individual outputs, which in turn causes buildEnv to install every output available even when asking for a specific output. seeing how extendDerivation and buildEnv work together using outputUnspecified it seems like the proper fix would be to filter outputUnspecified from the attributes of specific outputs. we can open a PR for that, but would it be correct at all?
Change:
{ lib , perlPackages , fetchFromGitHub <del> , makeWrapper </del> <ins> , wrapGAppsHook </ins> , gobject-introspection , perl , clamav

Discussion:
When executing with , it complains that . Maybe the package needs to be wrapped with some environment variables set or patched against hard-coding or something. Steps to reproduce the behavior: ClamTk runs with . ! ]() Add any other context about the problem here. <!-- 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.
I can't seem to reproduce this. Have run both on nixos and nix on another linux. Can you give me some more info? Does the program work and run correctly? Is it missing any icons (screenshot?). What desktop are you running? Many thanks.
It exits with exit status 2 right after the command being invoked inside the terminal emulator and the error message printed out. No window is shown. The desktop environment I use is LxQt, which inherently doesn't come with the KDE breeze icons. The screenshot and the Asciinema cast is updated into the issue description.
I switched my DE over to LxQt and everything worked for me. Basically the error is between the program logic (it shouldn't crash if it can't find icon files) and your DE set-up (it should provide the correct icon files). It's not a packaging error as far as I can tell. So you could try either: 1. messing around with your DE settings, 2. trying another DE and / or 3. filing a bug report upstream to clamtk. !
p.s. I wonder if this could just be fixed by installing some icons? You could try installing and / or on your system and see if that helps.
Change:
pytestCheckHook ]; <del> disabledTests = [ # numpy.core._exceptions._UFuncNoLoopError "test_sparse_nn_descent_query_accuracy_angular" "test_nn_descent_query_accuracy_angular" "test_alternative_distances" # scipy: ValueError: Unknown Distance Metric: wminkowski # https://github.com/scikit-learn/scikit-learn/pull/21741 "test_weighted_minkowski" ]; </del> pythonImportsCheck = [ "pynndescent" ];

Discussion:
Steps to reproduce the behavior: pythonPackages.pynndescent Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: