jiebi/CodeConvo huggingface dataset:
Change:
openpyxl tables xlwt <del> ] ++ optional isDarwin darwin.locale; # provides the locale command </del> <ins> ]; </ins> # For OSX, we need to add a dependency on libcxx, which provides # `complex.h` and other libraries that pandas depends on to build.

Discussion:
fails to install because tests fail. The failing test is the clipboard test that is meant to be disabled on darwin through . This is not actually disabling the test but rather forcing it to fail, but this can be fixed with a small change. Then we reach a different failing test: I'm not sure if this is darwin specific, nixpkgs specific, or a known bug in . System: OSX Sierra 10.12.4 (16E195) Nix version: 1.11.6 Nixpkgs version: 17.03.1052.
I can't reproduce the issue on NixOS, and I didn't find an issue on the pandas tracker about it either. I did see some similar issues when ran against numpy 1.12 or a different version of numexpr.
From the environment I can see that the version of numpy is 1.11.3.
This may be related to a bug in numpy (numpy/numpy) that was fixed in numpy 1.12.1. I'm trying to build again against that version and I'll see if that fixes it.
I needed to fix pytables first to get to the error you are describing:

Probably only broken when darwin build sandbox is enabled.
Similar as before?
Looks familiar. I recall fixing it last time, but that was before support for expression / derivation specific sandbox profiles was .
is this still the problem in current master?
This is broken, because yields . I couldn't actually find in darwin-nixpkgs. Is there none? Is this the missing command?
The test states: Perhaps we can just skip this test in nixpkgs too?
Change:
and uses locking internally to keep writers from trampling on each other. TDB is also extremely small. ''; <del> homepage = https://tdb.samba.org/; </del> <ins> homepage = "https://tdb.samba.org/"; </ins> license = licenses.lgpl3Plus; platforms = platforms.all; };

Discussion:
Describe the bug build of failed. To Reproduce Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(gtgteq): nixpkgs: Maintainer information:
Looks like regression in . We need to build talloc with Python 3 too.
It might also need
Change:
<ins> { lib, buildPythonPackage, fetchFromGitHub, pytestCheckHook, pythonOlder, beautifulsoup4, fiona, geodatasets, geopandas, numpy, packaging, pandas, platformdirs, requests, scikit-learn, scipy, setuptools-scm, shapely, }: buildPythonPackage rec { pname = "libpysal"; version = "4.10"; pyproject = true; disabled = pythonOlder "3.10"; src = fetchFromGitHub { owner = "pysal"; repo = "libpysal"; rev = "v${version}"; hash = "sha256-jzSkIFSIXc039KR4fS1HOI/Rj0mHwbArn2hD+zfAZDg="; }; build-system = [ setuptools-scm ]; propagatedBuildInputs = [ beautifulsoup4 fiona geopandas numpy packaging pandas platformdirs requests scikit-learn scipy shapely ]; nativeCheckInputs = [ geodatasets pytestCheckHook ]; preCheck = '' export HOME=$TMPDIR ''; # requires network access disabledTestPaths = [ "libpysal/cg/tests/test_geoJSON.py" "libpysal/examples/tests/test_available.py" "libpysal/graph/tests/test_base.py" "libpysal/graph/tests/test_builders.py" "libpysal/graph/tests/test_contiguity.py" "libpysal/graph/tests/test_kernel.py" "libpysal/graph/tests/test_matching.py" "libpysal/graph/tests/test_plotting.py" "libpysal/graph/tests/test_triangulation.py" "libpysal/graph/tests/test_utils.py" "libpysal/graph/tests/test_set_ops.py" "libpysal/weights/tests/test_contiguity.py" "libpysal/weights/tests/test_util.py" ]; pythonImportsCheck = [ "libpysal" ]; meta = { description = "A library of spatial analysis functions"; homepage = "https://pysal.org/libpysal/"; license = lib.licenses.bsd3; maintainers = lib.teams.geospatial.members; }; } </ins>

Discussion:
Project description mapclassify is an open-source python library for Choropleth map classification. It is part of the Python Spatial Analysis Library. Metadata homepage URL: source URL: license: BSD-3-Clause license
Even nicer if we could get pysal itself - there are some QGIS plugins that depend on it.
Change:
<ins> { lib , stdenv , fetchFromGitHub , meson , cmake , ninja , pkg-config , gtk2 , gtk3 , gtk4 }: let distorm-src = fetchFromGitHub { owner = "gdabah"; repo = "distorm"; rev = "3.5.2b"; hash = "sha256-2ftEV3TMS3HT7f96k+Pwt3Mm31fVEXcHpcbbz05jycU="; }; pname = "gtkclipblock"; version = "0.2.2"; src = fetchFromGitHub { owner = "notpeelz"; repo = "gtkclipblock"; rev = "v${version}"; hash = "sha256-ok/D7M0KekN8zf8AzhcOLtedbYVRHHv3m9zEHsJfcPM="; fetchSubmodules = true; }; in stdenv.mkDerivation { inherit pname version src; nativeBuildInputs = [ meson cmake ninja pkg-config ]; buildInputs = [ gtk2 gtk3 gtk4 ]; postPatch = '' substituteInPlace subprojects/funchook-helper/subprojects/funchook/CMakeLists.txt  --replace "GIT_REPOSITORY https://github.com/gdabah/distorm.git" "SOURCE_DIR ${distorm-src}" ''; dontUseCmakeConfigure = true; meta = with lib; { description = "A LD_PRELOAD hack to prevent GTK programs from interacting with the primary clipboard"; license = licenses.lgpl3Only; maintainers = with maintainers; [ uartman ]; platforms = [ "x86_64-linux" ]; }; } </ins>

Discussion:
Project description Most useful if this can be to 's ld preload, so wayland users on kde who disabled paste with middle click are able to copy links from the search bar. Metadata homepage URL: source URL: license: lgpl3 platforms: unix Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
agda-categories = callPackage ../development/libraries/agda/agda-categories { }; cubical = callPackage ../development/libraries/agda/cubical { }; <ins> generic = callPackage ../development/libraries/agda/generic { }; </ins> }; in mkAgdaPackages Agda

Discussion:
Project description Generics library for agda Metadata homepage URL: source URL: license: ? () platforms: All I guess CC:
Is this 2.6.1 compatible?
That's a good question. I haven't tried yet.
The license is MIT, and there was a recent release compatible with 2.6.1.
(See )
Change:
in <del> stdenvNoCC.mkDerivation { </del> <ins> stdenv.mkDerivation { </ins> name = "osquery-toolchain-bin"; inherit version; <del> src = fetchzip dist.${stdenvNoCC.hostPlatform.system}; </del> <ins> src = fetchzip dist.${stdenv.hostPlatform.system}; </ins> <del> nativeBuildInputs = [ autoPatchelfHook ]; </del> <ins> nativeBuildInputs = [ file ]; </ins> installPhase = '' mkdir $out cp -r * $out ''; <ins> # autoPatchelfHook cannot be used here because of https://github.com/NixOS/nixpkgs/issues/333710 postFixup = '' read -r interpreter < "$NIX_BINTOOLS"/nix-support/dynamic-linker for file in $(find "$out"/usr/bin -type f -executable); do if [[ $(file "$file") == *ELF*dynamically* ]]; then patchelf --interpreter "$interpreter" "$file" patchelf --set-rpath "$out/usr/lib" "$file" fi done ''; </ins> meta = with lib; { description = "A LLVM-based toolchain for Linux designed to build a portable osquery"; homepage = "https://github.com/osquery/osquery-toolchain";

Discussion:
The package contains compiler toolchain binaries (like ) and libc libraries to be used by the compiler outputs. When is run on the package, it incorrectly adds the internal libc directory to the rpath of the compiler binaries. This causes the compiler binaries to break with an error message like this: This problem was introduced in / This was done because the systemd package wanted to use to add dependencies to its rpath. But using to do this had an undesired side effect of removing glibc from the rpath (for a reason I don't yet understand). So s previous behavior to ignore libc dependencies was changed. a flag to autoPatchelfHook telling it to leave libc in the rpath if it's found. Enable this only on systemd. the libc change to autoPatchelfHook altogether, and instead modify findLibs and make-initrd-ng to automatically check libc. Either solution would restore the old libc behavior of autoPatchelfHook for everyone else. The former would then add different code for systemd, and the latter would change a couple other programs to account for lacking this new behavior
Fixed by
Change:
description = "GTK3-based panel for Sway window manager"; license = licenses.mit; platforms = platforms.linux; <del> maintainers = with maintainers; [ ]; </del> <ins> maintainers = with maintainers; [ ludovicopiero ]; mainProgram = "nwg-panel"; </ins> }; }

Discussion:
package-name: nwg-panel nwg-panel latest verison: 0.9.11 nixpkg unstable: 0.7.17 nixpkg stable: 0.7.17 Notify mainters; no maintainers
Change:
<ins> { lib, buildNpmPackage, fetchFromGitHub }: buildNpmPackage rec { pname = "twspace-crawler"; version = "1.11.13"; src = fetchFromGitHub { owner = "HitomaruKonpaku"; repo = "twspace-crawler"; rev = "v${version}"; hash = "sha256-MGFVIQDb++oVbTQubl7CNYwT/ofTNFQfFiveXcNgQpA="; }; npmDepsHash = "sha256-zKy/DngBwnfUqG6JfCULoDIrg1V16hX0Q4zNz45z888="; meta = with lib; { description = "Script to monitor & download Twitter Spaces 24/7"; homepage = "https://github.com/HitomaruKonpaku/twspace-crawler"; changelog = "https://github.com/HitomaruKonpaku/twspace-crawler/raw/v${version}/CHANGELOG.md"; license = licenses.isc; maintainers = [ maintainers.marsam ]; }; } </ins>

Discussion:
Project description twspace-crawler is a command-line app to automatically monitor & download Twitter Spaces. Metadata homepage URL: source URL: license: ISC platforms: unix
Change:
buku = callPackage ../applications/misc/buku { }; <del> bukut = callPackage ../applications/misc/bukut { }; </del> byzanz = callPackage ../applications/video/byzanz { }; algolia-cli = callPackage ../development/tools/algolia-cli { };

Discussion:
do you still use bukut ? I just noticed the project was archived . If the software is useful I wouldn't mind keeping it but the value looks think compared to buku or rofi-buku etc. Do you still use it/should we remove it
I don't use it anymore. I would appreciate its removal. If not, I can remove it.
this (fig)soda is lethal ! well done
Change:
pam_mysql = callPackage ../os-specific/linux/pam_mysql { }; <del> pam_p11 = callPackage ../os-specific/linux/pam_p11 { openssl = openssl_1_1; }; </del> <ins> pam_p11 = callPackage ../os-specific/linux/pam_p11 { }; </ins> pam_pgsql = callPackage ../os-specific/linux/pam_pgsql { };

Discussion:
pam_p11 causes login segfault in NixOS 22.11. GDM and Gnome lock screen are also affected. Steps to reproduce the behavior: to log in on the console or run `: Bug was not present in 22.05.
Reverting does not help.
Fixed by: Can someone with commit access apply this patch?
Can you open a pull request with that patch?
I hope that NixOS can be unbureaucratic enough that PRs are not required for this kind of patch.
It's generally preferred to do basically everything through PRs, so some basic CI checks can run & maintainers can be pinged automatically. We can just self-merge though. I created containing your diff and adding a comment for explanation.
This seems to be whats causing my 22.11-beta19 install on an Alder Lake 12700H (no gpu) to not boot into GDM. This is a pretty heinous issue that should be tested for. The graphical installer doesn't install Vim, WPA_Supplicant or anything useful for figuring out what went wrong, despite having Vim and WPA Supplicant available on the installation media/calamares.
Well I just did - you're welcome. That's what beta releases are for, aren't they?
Change:
{ stdenv, lib, buildPackages, fetchurl , enableStatic ? false , enableMinimal ? false <del> , useMusl ? stdenv.hostPlatform.libc == "musl", musl </del> <ins> , useMusl ? stdenv.hostPlatform.libc == "musl" </ins> , extraConfig ? "" }:

Discussion:
On Nixpkgs , does not build. The seems fine and the issue seems to be in the . system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
/cc
Yeah what's happening is that the musl hacks get in the way of an actual musl build. I think the solution is just to remove the musl hacks and use whenever this is needed.
This should work:
The can also removed. All that is what we did and if worked!
The buildInputs thing would still be needed if you are building static with glibc (see ).
Fair. But now that is merged, isn't that again not needed?
Should this be made a PR? Still fails to build, FWIW.
For anyone looking, this seems to work:
Change:
<ins> # Gomplate 3.x does not build with go > 1.20. # Version 4 of gomplate (yet unreleased) should not have this issue. # # see https://github.com/hairyhenderson/gomplate/issues/1872 </ins> { lib <del> , buildGoModule </del> <ins> #, buildGoModule , buildGo120Module </ins> , fetchFromGitHub }: <del> buildGoModule rec { </del> <ins> # buildGoModule rec { buildGo120Module rec { </ins> pname = "gomplate"; version = "3.11.5";

Discussion:
Gomplate build currently fails (version 3.11.5). The devs say to upgrade to v4, which seems not to have been released yet. (see ) I'm the package maintainer. I'm creating this to keep track of the issue.
Less than ideal workaround:
Good point, thanks: I guess that's the best we can do (short of patching the sources). I'm fixing it now.
Change:
pyialarmxr = pyialarmxr-homeassistant; # added 2022-06-07 pyialarmxr-homeassistant = throw "The package was removed together with the component support in home-assistant 2022.7.0"; # added 2022-07-07 PyICU = pyicu; # Added 2022-12-22 <del> pyjson5 = json5; # added 2022-08-28 </del> pyhs100 = throw "pyhs100 has been removed in favor of python-kasa."; # added 2024-01-05 pylibgen = throw "pylibgen is unmaintained upstreamed, and removed from nixpkgs"; # added 2020-06-20 PyLD = pyld; # added 2022-06-22

Discussion:
is currently an alias for , which is on PyPI. However, there's another completely unrelated package named on PyPI, which Nixpkgs doesn't package at the moment. I think should refer to that one (or be removed to avoid confusion). Steps to reproduce the behavior: The import succeeds and can be used to access the module. If applicable, add screenshots to help explain your problem. I ran into this while trying to package something that depends on pyjson5 (), and was very confused why pyjson5 wasn't being found even though it was in my . <!-- 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:
<ins> { lib, buildGoModule, fetchFromGitHub, installShellFiles }: buildGoModule rec { pname = "glooctl"; version = "1.10.6"; src = fetchFromGitHub { owner = "solo-io"; repo = "gloo"; rev = "v${version}"; sha256 = "sha256-t63tK0hwbVnUP9UxS8g3uzL3rBvKR10vu1E85mNV3E0="; }; subPackages = [ "projects/gloo/cli/cmd" ]; vendorSha256 = "sha256-IBuAUKbX1esx2p4Q/b3UxQH9S3VVNYZcn5vRKtmhO0A="; nativeBuildInputs = [ installShellFiles ]; postInstall = '' mv $out/bin/cmd $out/bin/glooctl export HOME=$TMP installShellCompletion --cmd glooctl  --bash <($out/bin/glooctl completion bash)  --zsh <($out/bin/glooctl completion zsh) ''; ldflags = [ "-s" "-w" "-X github.com/solo-io/gloo/pkg/version.Version=${version}" ]; meta = with lib; { description = "glooctl is the unified CLI for Gloo"; homepage = "https://docs.solo.io/gloo-edge/latest/reference/cli/glooctl/"; license = licenses.asl20; maintainers = with maintainers; [ nelsonjeppesen ]; }; } </ins>

Discussion:
add glooctl is the official cli tool to manage it Metadata homepage URL: source URL: license: Apache-2.0 License platforms: linux, darwin
Change:
<ins> { lib , stdenv , fetchFromGitHub , pkg-config , cmake , ninja , cairo , fribidi , libdatrie , libjpeg , libselinux , libsepol , libthai , pango , pcre , utillinux , wayland , wayland-protocols , wayland-scanner , wlroots , libXdmcp , debug ? false }: stdenv.mkDerivation { pname = "hyprpicker" + lib.optionalString debug "-debug"; version = "unstable-2023-03-09"; src = fetchFromGitHub { owner = "hyprwm"; repo = "hyprpicker"; rev = "234c2da51a71941c0cd2ee380f42de365f90dd6f"; hash = "sha256-wb1oXsaM0AkThPJGjn0Ytxt8vbBQG+mg2AGY0uxhUJ0="; }; cmakeFlags = lib.optional debug "-DCMAKE_BUILD_TYPE=Debug"; nativeBuildInputs = [ cmake ninja pkg-config ]; buildInputs = [ cairo fribidi libdatrie libjpeg libselinux libsepol libthai pango pcre wayland wayland-protocols wayland-scanner wlroots libXdmcp utillinux ]; configurePhase = '' runHook preConfigure make protocols runHook postConfigure ''; buildPhase = '' runHook preBuild make release runHook postBuild ''; installPhase = '' runHook preInstall mkdir -p $out/{bin,share/licenses} install -Dm755 build/hyprpicker -t $out/bin install -Dm644 LICENSE -t $out/share/licenses/hyprpicker runHook postInstall ''; meta = with lib; { description = "A wlroots-compatible Wayland color picker that does not suck"; homepage = "https://github.com/hyprwm/hyprpicker"; license = licenses.bsd3; maintainers = with maintainers; [ fufexan ]; platforms = wayland.meta.platforms; }; } </ins>

Discussion:
Project description A wlroots-compatible Wayland color picker that does not suck. Metadata homepage URL: source URL: license: platforms: linux Just because you made available on NixOS, I wanted to point you on hyprpicker, too - if you're interested to have a look into this(?)
I'll take a look into packaging this.
Change:
bbox = callPackage ../development/python-modules/bbox { }; <ins> bcc = toPythonModule (pkgs.bcc.override { python3Packages = self; }); </ins> bc-detect-secrets = callPackage ../development/python-modules/bc-detect-secrets { }; bc-jsonpath-ng = callPackage ../development/python-modules/bc-jsonpath-ng { };

Discussion:
Mentioned in , the bcc package can also be used as from python. This currently doesn't seem to work? If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
bcc doesn't depend on kernel anymore, so the second half of the comment you linked at isn't required and we can just move the package & add a compat alias. Technically you should already be able to use bcc as by magic'ing the correct site path, but I agree it's better to move it - patch welcome!
Change:
xf86videodummy = callPackage ./xf86videodummy { }; in buildPythonApplication rec { pname = "xpra"; <del> version = "2.5.3"; </del> <ins> version = "3.0.5"; </ins> src = fetchurl { url = "https://xpra.org/src/${pname}-${version}.tar.xz"; <del> sha256 = "1ys35lj28903alccks9p055psy1fsk1nxi8ncchvw8bfxkkkvbys"; </del> <ins> sha256 = "1zy4q8sq0j00ybxw3v8ylaj2aj10x2gb0a05aqbcnrwp3hf983vz"; </ins> }; patches = [

Discussion:
Describe the bug NixOS currently has Xpra 2.5.3. Metadata Maintainer information:
cc
please test
Change:
<ins> { lib, buildGoModule, fetchFromGitHub }: buildGoModule rec { pname = "xcaddy"; version = "0.4.1"; subPackages = [ "cmd/xcaddy" ]; src = fetchFromGitHub { owner = "caddyserver"; repo = pname; rev = "v${version}"; hash = "sha256-xEPSRKrQC9hb+G9/rV9/k4btvZxXZkcsxmaxWcgl2fk="; }; patches = [ ./inject_version_info.diff ./use_tmpdir_on_darwin.diff ]; ldflags = [ "-s" "-w" "-X github.com/caddyserver/xcaddy/cmd.customVersion=v${version}" ]; vendorHash = "sha256-7yd/6h1DKw7X/1NbHtr2vbpyapF81HPmDm7O4oV5nlc="; meta = with lib; { homepage = "https://github.com/caddyserver/xcaddy"; description = "Build Caddy with plugins"; mainProgram = "xcaddy"; license = licenses.asl20; maintainers = with maintainers; [ tjni emilylange ]; }; } </ins>

Discussion:
Caddy fails to build for riscv64 Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. 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]:
(please fill out more parts of the bug report template next time) Assuming this is , likely an instance of . Pinging maintainers:
Hi, thanks for the ping :) The fix for this is fairly trivial. Either skip the shell completions/man pages[^1], or use something like But I am upset that you ( didn't even care enough to do the bare minimum and fill out the issue template. [^1]: Technically only the kills the build, not the , because bash pipefail defaults.
i'm sorry for the issue template, it was more of a quick note to myself. i'll do it right next time
Change:
propagatedBuildInputs = [ colorama funcparserlib <del> rply # TODO: remove on the next release ] ++ lib.optionals (pythonOlder "3.9") [ </del> <ins> ] ++ lib.optionals (pythonOlder "3.9") [ </ins> astor <del> ] # for backwards compatibility with removed pkgs/development/interpreters/hy # See: https://github.com/NixOS/nixpkgs/issues/171428 ++ (hyDefinedPythonPackages python.pkgs); </del> <ins> ]; </ins> checkInputs = [ pytestCheckHook ]; <ins> preCheck = '' # For test_bin_hy export PATH="$out/bin:$PATH" ''; </ins> disabledTests = [ <del> # Don't test the binary "test_bin_hy" "test_hystartup" "est_hy2py_import" </del> <ins> "test_circular_macro_require" "test_macro_require" </ins> ]; pythonImportsCheck = [ "hy" ];

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
--set-default DEPS_CLJ_TOOLS_DIR $out/clojure_tools  --set-default JAVA_HOME ${jdkBabashka} <ins> '' + lib.optionalString withRlwrap '' </ins> substituteInPlace $out/bin/bb  --replace '"${unwrapped-bin}"' '"${rlwrap}/bin/rlwrap" "${unwrapped-bin}"' '';

Discussion:
The latest PR on introduced babashka and babashka-unwrapped. However it introduced rlwrap as default for babashka, this caused compatibility issues. Example: Running with babashka-unwrapped/bin/bb Note: one empty line Running with babashka/bin/bb Note: two empty lines As discussed with Michiel Borkent, upstream assumed the bb is shipped without rlwrap, that's the only bb supported by upstream. So, this case we cannot introduce the default bb with rlwrap, which will cause all kinds of weird bugs and compatibility issues aroud io if upstream and all other distributions assume bb is without rlwrap. Propose: now simply revert or remove rlwrap from don't mind having a rlwrap version of bb, as long as the binary in bin called something else, maybe . Since upstream hasn't standardized naming conventions like clj/clojure. But bottom line is, rlwrapped one's binary should NOT be bb! cc
I agree with the revert course of action. I never pipe to babashka, which is why I didn't consider that use-case.
IMO it's better to only remove rlwrap, that's the only part causing issues
I think the best option would be to add as an option of the wrap, and set it to false by default.
see