jiebi/CodeConvo huggingface dataset:
Change:
{ lib, buildPythonPackage, fetchPypi , pytest, pytest-cov, pytest-xdist <del> , six, numpy, scipy, pyyaml, h5py </del> <ins> , six, numpy, scipy, pyyaml, h5py, optree </ins> , keras-applications, keras-preprocessing }:

Discussion:
Project description Optimized pytree utilities Metadata homepage URL: source URL: license: apache-2.0 platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
name= HOME="$TMPDIR"  ./install.sh --dest $out/share/themes <del> mkdir -p $out/share/sddm/themes </del> <ins> mkdir -p $sddm/share/sddm/themes </ins> cd sddm source install.sh runHook postInstall ''; <ins> postFixup = '' # Propagate sddm theme dependencies to user env otherwise sddm # does not find them. Putting them in buildInputs is not enough. mkdir -p $sddm/nix-support printWords ${kdeclarative.bin} ${plasma-framework} ${plasma-workspace}  >> $sddm/nix-support/propagated-user-env-packages ''; </ins> passthru.updateScript = gitUpdater { }; meta = with lib; {

Discussion:
shouldn't install KDE Plasma as a dependency, it can be used with Kvantum Steps to reproduce the behavior: dependencies with Kvantum and KDE Plasma should be optional dependencies of . I recently noticed that KDE Plasma was installed on my system for no reason, after some research I found the culprit, Colloid-kde installs the entire desktop environment as a dependency. I use this theme with and so I don't need KDE.
It is not a bug. Without the dependencies the sddm theme does not work.
Maybe one solution in order to avoid those kde dependencies needed only for the sddm theme is to have a separate output for the sddm theme, and keep the dependencies only for it. Something like what is already done for (the nordic sddm theme).
Change:
serviceConfig = { Type = "notify"; <del> ExecStart = "${pkgs.etcd}/bin/etcd"; </del> <ins> ExecStart = "${pkgs.etcd.bin}/bin/etcd"; </ins> User = "etcd"; PermissionsStartOnly = true; };

Discussion:
NixOS services that depend on binaries are now broken (eg ) after This is because the attribute path for binaries has now changed. For example should now be .
I can do it tomorrow.
Change:
, gtest , doxygen , fixDarwinDylibNames <ins> , useAVX2 ? stdenv.hostPlatform.avx2Support </ins> }: stdenv.mkDerivation rec {

Discussion:
The latest libtiledb package for x86_64-linux results in an 'Illegal instruction (core dumped)' Steps to reproduce the behavior: journalctl for systemd-coredump logs: No crash. <!-- 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.
As additional info, this issue does not happen on all machines. We encountered this mainly on VMs. One deployment was in a VMWare cluster and the other in an OpenStack environment of a public cloud. Furthermore, we did not have this issue with NixOS 22.11. We hit this issue while trying to upgrade to 23.05.
It seems that the version of tiledb that is provided in the nixpkgs cache was build with AVX instructions. The version from nixos 22.11: The version from nixos 23.05:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Running gdb on gdalinfo gives:
Yeah, it's a global constructor for from . Adding clearly shows that gets to every source file in , not just one. Probably caused by looks off.
Looks like you should be able to it to force not passing .
I can confirm that adding to in the derivation does the trick. However, this then removes all AVX code from the library. So any will then also no longer work. Unless anyone has any better ideas, I would propose to introduce a option to the derivation and then use:
Change:
postInstall = '' installManPage texlab.1 <ins> # Remove generated dylib of human_name dependency. TexLab statically # links to the generated rlib and doesn't reference the dylib. I # couldn't find any way to prevent building this by passing cargo flags. # See https://github.com/djudd/human-name/blob/master/Cargo.toml#L43 rm "$out/lib/libhuman_name${stdenv.hostPlatform.extensions.sharedLibrary}" rmdir "$out/lib" </ins> ''; passthru.updateScript = nix-update-script {

Discussion:
To Reproduce Expected behavior No rustc reference Notify maintainers & myself. Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I marked this as stale due to inactivity. &rarr;
Checked and it's still an issue.
This is no longer a problem with the fix applied in :
Reopening now since the update to 4.0.0 at .
Change:
# # I've chosen to import Alpine Linux, because its image is turbo-tiny and, # generally, sufficient for our tests. <del> alpine-meta = pkgs.fetchurl { </del> <ins> alpine-meta-x86 = pkgs.fetchurl { </ins> url = "https://tarballs.nixos.org/alpine/3.12/lxd.tar.xz"; hash = "sha256-1tcKaO9lOkvqfmG/7FMbfAEToAuFy2YMewS8ysBKuLA="; }; <ins> alpine-meta-for = arch: pkgs.stdenv.mkDerivation { name = "alpine-meta-${arch}"; version = "3.12"; unpackPhase = "true"; buildPhase = '' runHook preBuild </ins> <del> alpine-rootfs = pkgs.fetchurl { url = "https://tarballs.nixos.org/alpine/3.12/rootfs.tar.xz"; hash = "sha256-Tba9sSoaiMtQLY45u7p5DMqXTSDgs/763L/SQp0bkCA="; </del> <ins> tar xvf ${alpine-meta-x86} sed -i 's/architecture: .*/architecture: ${arch}/' metadata.yaml runHook postBuild ''; installPhase = '' runHook preInstall tar czRf $out * runHook postInstall ''; </ins> }; <ins> alpine-meta = { x86_64-linux = alpine-meta-x86; aarch64-linux = alpine-meta-for "aarch64"; }.${pkgs.system} or (throw "Unsupported system: ${pkgs.system}"); alpine-rootfs = { x86_64-linux = pkgs.fetchurl { url = "https://tarballs.nixos.org/alpine/3.12/rootfs.tar.xz"; hash = "sha256-Tba9sSoaiMtQLY45u7p5DMqXTSDgs/763L/SQp0bkCA="; }; aarch64-linux = pkgs.fetchurl { url = "https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/aarch64/alpine-minirootfs-3.15.4-aarch64.tar.gz"; hash = "sha256-9kBz8Jwmo8XepJhTMt5zilCaHHpflnUH7y9+0To39Us="; }; }.${pkgs.system} or (throw "Unsupported system: ${pkgs.system}"); </ins> lxd-config = pkgs.writeText "config.yaml" '' storage_pools: - name: default

Discussion:
For example This test has always been failing: From the logs: /cc
Whoopsie! Maybe instead of keeping hard-coded URL to x86-64's Alpine we could build something dynamically? (this way the test would automatically work on all architectures) I'll try to take a look over the weekend, but feel free to take a shot at it, if you want
Hmm that is a cool idea. Though OTOH it is currently nice that when this test fails it is clear it is a problem with running the image, and not with creating it. Did you get that from somewhere or did you create it? Is it the 'mini root fs' from ?
Yeah, that's the one;
Change:
<del> { stdenv, lib, buildPythonPackage, fetchFromGitHub, python, pythonOlder </del> <ins> { stdenv , lib , buildPythonPackage , fetchFromGitHub , pythonOlder </ins> , cython , eventlet , futures ? null

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:
"test_subprocess_print" "test_subprocess_error" "test_ipython_start_kernel_no_userns" <ins> # https://github.com/ipython/ipykernel/issues/506 "test_unc_paths" </ins> ] ++ lib.optionals (pythonOlder "3.8") [ # flaky test https://github.com/ipython/ipykernel/issues/485 "test_shutdown"

Discussion:
Describe the bug Ipykernel 5.2.1 (via ) introduced a test for UNC paths on windows which fail on darwin. To Reproduce Steps to reproduce the behavior: Expected behavior Build of ipykernel for python 3.7 to succeed. Logs Additional context Adding the test to solves this Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
#[cfg(test)] mod tests { use super::{ <del> get_initial_url, to_new_packages, Hash, HashCollection, OldPackage, Package, UrlOrString, </del> <ins> get_initial_url, packages, to_new_packages, Hash, HashCollection, OldPackage, Package, UrlOrString, </ins> }; use std::{ cmp::Ordering,

Discussion:
Lily and I talked about this in Matrix, this is the requested issue. Basically it all narrows down to this package lock: Steps to reproduce the behavior: it it hangs forever lock it works It should either give an error or just work. If it helps narrowing the npm version down, the package- was created in September of 2020 and was last changed in September of 2021.
To clarify a bit, this isn't something specific to older lockfiles, it just looks like there is a version spec format that our fetcher does not currently support, but probably should
Change:
--replace '$$PROTOBUF/lib/libprotobuf-lite.a' '${protobuf}/lib/libprotobuf-lite.dylib' ''; <del> # error: 'path' is unavailable: introduced in macOS 10.15 qmakeFlags = lib.optionals stdenv.isDarwin [ "CONFIG+=c++17" "QMAKE_MACOSX_DEPLOYMENT_TARGET=10.15" ]; </del> meta = with lib; { description = "Qt image plugin for displaying Mapbox vector tiles"; longDescription = ''

Discussion:
Steps to reproduce the behavior: The regression is due to , which forgot to maintain the guard on darwin. While it is straightforward to fix the aarch64-darwin build, it isn't enough for x86_64-darwin due to . <!-- 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.
Change:
libqalculate = callPackage ../development/libraries/libqalculate { }; <ins> libqt5pas = callPackage ../development/compilers/fpc/libqt5pas.nix { }; </ins> libroxml = callPackage ../development/libraries/libroxml { }; librsvg = callPackage ../development/libraries/librsvg { };

Discussion:
Cross-platform text editor, written in Lazarus From: Repository: Mirror: Development seems very active (last commit 15 minutes ago). Might be a nice open source alternative to SublimeText.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me.
Change:
buildInputs = [ hidapi libftdi1 libusb1 ] ++ lib.optional stdenv.isLinux libgpiod; <del> patches = [ # Patch is upstream, so can be removed when OpenOCD 0.12.0 or later is released. (fetchpatch { url = "https://github.com/openocd-org/openocd/commit/cff0e417da58adef1ceef9a63a99412c2cc87ff3.patch"; sha256 = "Xxzf5miWy4S34sbQq8VQdAbY/oqGyhL/AJxiEPRuj3Q="; }) ]; </del> configureFlags = [ "--disable-werror" "--enable-jtag_vpi"

Discussion:
v0.11.0 of OpenOCD is over a year old, does anyone have time to update or add an unstable branch?
v0.11.0 seems to be the latest release (). I suggest asking upstream for a new release.
We don't update to unstable unless there is a good reason to do so. Do you have any?
Yes - there is no sign of a 0.12.0 release that I can see, and the software has been actively developed since the 0.11.0 release. There is currently open to update ElmerFEM for similar purposes. I’m not convinced that it should be on users or maintainers to ask upstream for a release number in cases like this.
That's a different case, since the person opening the PR indicated there is something they need from the unreleased version of the software. So let me repeat and rephrase my question: Do you have any reason why you want us to update OpenOCD to unstable? Any bug fixes, any features you are missing from the latest stable release?
Now that v0.12.0 is out, would you take action to update this? I want to see if any of the changes related to allow me to flash an atsamc21g18 that drives it’s SWD pins from a rpi.
Can you test
Change:
python3.pkgs.buildPythonApplication rec { pname = "radicale"; <del> version = "3.2.1"; </del> <ins> version = "3.2.0"; </ins> pyproject = true; src = fetchFromGitHub { owner = "Kozea"; repo = "Radicale"; rev = "v${version}"; <del> hash = "sha256-OUwznn71xl8oWkw90fT1NYYZOuD83k+B5zLhygp1VQQ="; </del> <ins> hash = "sha256-RxC8VOfdTXJZiAroDHTKjJqGWu65Z5uyb4WK1LOqubQ="; </ins> }; postPatch = ''

Discussion:
Steps to reproduce the behavior: radicale at quick glance I think they rereleased tarballs with more changes, files inside are from today Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yeah, looks like upstream changed the release afterwards. I didn't even know you can do that on GitHub.
You can just delete the tag, create a new one with the same name and do a force push. Some projects do this, some don't.
I suggest any that do be removed from Nixpkgs. It's unacceptable.
Can someone revert for now?
Change:
./dont_create_privsep_path.patch ./ssh-keysign.patch <ins> # See https://github.com/openssh/openssh-portable/pull/206 ./ssh-copy-id-fix-eof.patch </ins> ] ++ optional withGssapiPatches (assert withKerberos; gssapiPatch);

Discussion:
Describe the bug Fixed upstream in . Running results in the following output from Bash: This problem prevents from copying keys to the remote system. To Reproduce Ensure you've got an SSH keypair, then attempt to copy it to a remote system with : Expected behavior I would expect to exit with status and without issuing any error output. Notify maintainers Ping -- happy to submit a PR for this, though I'm not sure about the best approach. It looks like hasn't landed in an OpenSSH release yet; the Arch Linux folks and have . Metadata
Closing as this appears to have been fixed with and backported to 20.09 in , please comment if something is still missing.
Change:
programs.zsh.vteIntegration = mkDefault true; # Systemd services <del> systemd.packages = with pkgs.xfce; [ </del> <ins> systemd.packages = utils.removePackagesByName (with pkgs.xfce; [ </ins> xfce4-notifyd <del> ]; </del> <ins> ]) excludePackages; </ins> security.pam.services.xfce4-screensaver.unixAuth = cfg.enableScreensaver; };

Discussion:
Describe the bug lacks an option to exclude some packages. Expected behavior xfce service should provide an option like in GNOME3 service. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I marked this as stale due to inactivity. &rarr;
Change:
diff --git a/distrobuilder/lxc.generator b/distrobuilder/lxc.generator <del> index 0ad81d1..69dbfe7 100644 </del> <ins> index 0ad81d1..21ddb39 100644 </ins> --- a/distrobuilder/lxc.generator +++ b/distrobuilder/lxc.generator @@ -25,16 +25,6 @@ is_incus_vm() {

Discussion:
not working in lxc containers. But sysctl command works fine and /proc/sys/ is writable. This nix option seems to finally take effect via . And the look like this: This looks fine, So I tried to manually run the command in , and it takes effect! But this looks even weirder. Through , I got: There is an unusual . It looks like this: Obviously, there is not is NixOS. So won't run at all. I looked it up on the internet and found out it's from distrobuilder: So maybe we should just patch it? Steps to reproduce the behavior: a privilege container with NixOS in it. something to and rebuild the system , and there is no effect should run and takes effect. <!-- 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]:
Are you able to you reproduce this with unstable? There are some improvements post 23.11 to the use of the lxc generator.
Yes, I'm already on latest unstable channel. The channel information in metadata tab is incorrect because I'm using flakes. There are many hard-coded FHS paths in distrobuilder. Such as this line, that causes this problem:
can you test this change?
It works fine for me. But I don’t know if there are any problems caused by other hard-coded paths in distrobuilder. And I don’t know whether using sysctl on an unprivileged container will cause the service to fail to start, and whether the startup failure will cause problems. But it seems that sets , so there should be no problem?
Thanks for testing! There shouldn't be, since we patch and wrap the distrobuilder lxc generator. I audited it again after updating the patch for this fix. You can always see the resulting file by building . The PR has tests which should cover unprivileged containers. I've just updated them to add a check verifying systemd-sysctl successfully started.
Change:
+fontconfig = _dlopen(ffi, '@fontconfig@') +pangoft2 = _dlopen(ffi, '@pangoft2@') <del> gobject.g_type_init() </del> <ins> gobject.g_type_init() </ins>  No newline at end of file

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: 54.3 desired version: 57.0 <!-- 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:
rev = "v${version}"; hash = "sha256-LVLEn+e7c8013pwiLzJiiIObyrlbBHYaioO/SWbItPQ="; }; <del> }); </del> <ins> }); onnx = fetchFromGitHub { owner = "onnx"; repo = "onnx"; rev = "refs/tags/v1.14.1"; hash = "sha256-ZVSdk6LeAiZpQrrzLxphMbc1b3rNUMpcxcXPP8s/5tE="; }; </ins> in stdenv.mkDerivation rec { pname = "onnxruntime"; <del> version = "1.15.1"; </del> <ins> version = "1.16.3"; </ins> src = fetchFromGitHub { owner = "microsoft"; repo = "onnxruntime"; <del> rev = "v${version}"; sha256 = "sha256-SnHo2sVACc++fog7Tg6f2LK/Sv/EskFzN7RZS7D113s="; </del> <ins> rev = "refs/tags/v${version}"; hash = "sha256-bTW9Pc3rvH+c8VIlDDEtAXyA3sajVyY5Aqr6+SxaMF4="; </ins> fetchSubmodules = true; }; <ins> patches = [ # If you stumble on these patches trying to update onnxruntime, check # `git blame` and ping the introducers. # Context: we want the upstream to # - always try find_package first (FIND_PACKAGE_ARGS), # - use MakeAvailable instead of the low-level Populate, # - use Eigen3::Eigen as the target name (as declared by libeigen/eigen). ./0001-eigen-allow-dependency-injection.patch ]; </ins> nativeBuildInputs = [ cmake pkg-config python3Packages.python protobuf_21 ] ++ lib.optionals pythonSupport (with python3Packages; [ <del> setuptools wheel </del> pip <ins> python </ins> pythonOutputDistHook <ins> setuptools wheel </ins> ]); buildInputs = [ <ins> eigen </ins> libpng zlib nlohmann_json <del> nsync re2 </del> microsoft-gsl <del> ] ++ lib.optionals pythonSupport [ python3Packages.numpy python3Packages.pybind11 python3Packages.packaging ] ++ lib.optionals stdenv.isDarwin [ </del> <ins> ] ++ lib.optionals pythonSupport (with python3Packages; [ numpy pybind11 packaging ]) ++ lib.optionals stdenv.isDarwin [ </ins> Foundation iconv ];

Discussion:
Meaningful errors Full logs: system: host os: multi-user?: sandbox: version: channels(root): channels(jarrod): nixpkgs: Source file with issue:  I tried to locate where is defined, but was unable to.
Edited the issue and I'm not sure if GitHub retroactively sends notifications, so pardon the double-mention:
Will be fixed by .
Change:
setuptools ] ++ runtimeDeps; postPatch = '' substituteInPlace src/ocrmypdf/leptonica.py  --replace "ffi.dlopen(find_library('lept'))" 

Discussion:
Describe the bug ocrmypdf doesn't work until I also install . To Reproduce Steps to reproduce the behavior: 't have installed or in PATH. one of: Additional context Running nixpkgs master Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): channels(play): nixpkgs: Maintainer information: cc
I'm really swamped right now but I do need to do some updates that were requested to be in the PR before it got merged. I was half expecting someone to find problems anyway (it was really, really difficult to even get it to work at all). I'll try to get around to fixing it ASAP... which might be in a few days... if nobody does it sooner. Sorry about it not working!
No, thank you for packaging it! I successfully used it today :-)
This should be fixed as of the upgrade I did to 9.0.3. would you mind testing it to confirm it truly is fixed? It's in nixos-unstable now. After that we can close this! :D
Thanks! This does look fixed in master.
Change:
<ins> { cabal }: cabal.mkDerivation (self: { pname = "concatenative"; version = "1.0.1"; sha256 = "05xwqvcdnk8bsyj698ab9jxpa1nk23pf3m7wi9mwmw0q8n99fngd"; meta = { homepage = "https://patch-tag.com/r/salazar/concatenative/snapshot/current/content/pretty"; description = "A library for postfix control flow"; license = self.stdenv.lib.licenses.bsd3; platforms = self.ghc.meta.platforms; }; }) </ins>

Discussion:
Kdenlive build fails because CMake can't find QtConcurrent. Error: It appears to have been broken by some changes made to qtbase but I am not familiar enough with it to know what specifically. Changes between success and first failure: Latest Hydra failure: cc Attempt to install Kdenlive System: NixOS: 17.09pre107928. (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: "17.09pre107928." Sandboxing enabled: build-use-sandbox = true
You need to modify the to We should send a patch upstream. This must be a required change since QT5.8.
Fixed by:
Change:
pytest-localserver pytestCheckHook responses <del> urllib3 </del> ] ++ passthru.optional-dependencies.aiohttp # `cryptography` is still required on `aarch64-darwin` for `tests/crypt/*` ++ (if (stdenv.isDarwin && stdenv.isAarch64) then [ cryptography ] else passthru.optional-dependencies.enterprise_cert)

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags: -
Hmm I'm not quite sure if urllib3 should be to on or on