jiebi/CodeConvo huggingface dataset:
Change:
let version = "0.7.07.1"; <del> inherit (python2Packages) boto ecdsa lockfile paramiko pycrypto python setuptools; </del> <ins> inherit (python2Packages) boto cffi cryptography ecdsa enum idna ipaddress lockfile paramiko pyasn1 pycrypto python setuptools six; </ins> in stdenv.mkDerivation { name = "duplicity-${version}";

Discussion:
When running duply with the sftp backend it throws the error BackendException: Could not initialize backend: No module named 09:42:15.986 Task 'BKP' failed with exit code '23'. System: 16.09pre89501. (Flounder) Nix version: 1.11.2 Nixpkgs version: 16.09pre89501.
is the backend missing or is it using wrong version of cryptography?
if cryptography isn't as a buildInput I'm not surprised it won't work. could you test cc maintainer
well, I accidentally merged it already, so you can try master as well.
Using FRidh/nixpkgs like this nix-shell --pure -p duply --run 'duply test create; mkdir -p source; mkdir -p target; echo SOURCE="$PWD/source TARGET=sftp://localhost/$PWD/target TARGET_PASS=''" ; duply test backup' -I still gives the same error I'm afraid.
I suppose it is duplicity that needs this library.
cc maintainers
FTR, as a workaround I tried installing older versions of duply/duplicity using but still got the same error. (Which of course is weird because it worked for me until days ago.)
Sorry, must have mixed something up yesterday - I was able to install duplicity-0.7.06/duply-1.9.2 from nixpkgs just now and backup is running. Meaning I have a workaround for now.
Sounds like this has been fixed.
How? Where?
I don't see how this is fixed. The nix-shell invocation from the description still throws the same error.
Any ideas here? With a pointer or to I would be willing to try and fix it myself, but I'm not sure where to start.
If I am correct, calls , so the error we're seeing is in , and not in (therefore my fix in didn't work). The package doesn't seem to have , only , so I imagine that to be the problem.
Thanks! That was the right direction. There were a couple more missing dependencies but I managed to sort them out.
Change:
<ins> { config, pkgs, lib, ... }: let cfg = config.programs.kubeswitch; in { options = { programs.kubeswitch = { enable = lib.mkEnableOption (lib.mdDoc "kubeswitch"); commandName = lib.mkOption { type = lib.types.str; default = "kswitch"; description = "The name of the command to use"; }; package = lib.mkOption { type = lib.types.package; default = pkgs.kubeswitch; defaultText = lib.literalExpression "pkgs.kubeswitch"; description = "The package to install for kubeswitch"; }; }; }; config = let shell_files = pkgs.stdenv.mkDerivation rec { name = "kubeswitch-shell-files"; phases = [ "installPhase" ]; installPhase = '' mkdir -p $out/share for shell in bash zsh; do ${cfg.package}/bin/switcher init $shell | sed 's/switch(/${cfg.commandName}(/' > $out/share/${cfg.commandName}_init.$shell ${cfg.package}/bin/switcher --cmd ${cfg.commandName} completion $shell > $out/share/${cfg.commandName}_completion.$shell done ''; }; in lib.mkIf cfg.enable { environment.systemPackages = [ cfg.package ]; programs.bash.interactiveShellInit = '' source ${shell_files}/share/${cfg.commandName}_init.bash source ${shell_files}/share/${cfg.commandName}_completion.bash ''; programs.zsh.interactiveShellInit = '' source ${shell_files}/share/${cfg.commandName}_init.zsh source ${shell_files}/share/${cfg.commandName}_completion.zsh ''; }; } </ins>

Discussion:
Kubeswitch requires both the binary and a script Steps to reproduce the behavior: kubeswitch to use Kubeconfig is set as intended only adds the binary, not the script itself. On the other hand, I'm not using nix directly but via fleek.
Hey happy first issue! About the kubeswitch, indeed, I did make this mistake as I am using it on my work machine which is not NixOS and I had done the standard installation in the past, so I got the binary from Nix, but not the script. Honestly, I need time and a little bit of searching on how to handle scripts, as I have only messed with Go or Python packages (which have a nice interface, BTW).
This will help fix it.
I did not test, but thanks. are you willing to do fix it?
Hi, sorry I want to but do not have much time recently.
Change:
<ins> { lib, fetchFromGitHub, rustPlatform }: rustPlatform.buildRustPackage rec { pname = "autotiling-rs"; version = "0.1.3"; src = fetchFromGitHub { owner = "ammgws"; repo = pname; rev = "v${version}"; sha256 = "sha256-LQbmF2M6pWa0QEbKF770x8TFLMGrJeq5HnXHvLrDDPA="; }; cargoHash = "sha256-wot5GKBA2TBrA/jnWD0eypPRqUodmk/TJlYJMl3/gm4="; meta = with lib; { description = "Autotiling for sway (and possibly i3)"; homepage = "https://github.com/ammgws/autotiling-rs"; license = licenses.mit; platforms = platforms.linux; maintainers = with maintainers; [ dit7ya ]; }; } </ins>

Discussion:
Project description Autotiling for sway (and possibly i3) Metadata homepage URL: source URL: license: platforms: linux
Change:
stdenv.mkDerivation rec { pname = "vaultwarden-webvault"; <del> version = "2022.10.0"; </del> <ins> version = "2022.12.0"; </ins> src = fetchurl { url = "https://github.com/dani-garcia/bw_web_builds/releases/download/v${version}/bw_web_v${version}.tar.gz"; <del> hash = "sha256-Sf1YnOikjZmloTQvdrFH/UAevQqKQEkNNrCRUhvNZfA="; </del> <ins> hash = "sha256-QC3/aqIF2NdJPHmwUbvJR62wsUGBrgsHJCyqBJ/0gMc="; </ins> }; buildCommand = ''

Discussion:
Package name: VaultWarden Latest released version: 1.27.0 Current version on the unstable channel: 1.27.0 Current version on the stable/release channel: 1.26.0 The currently packaged version of VaultWarden in 22.11 is out of date enough as to be incompatible with officially released BitWarden clients. As I understand it, the latest release has no drawbacks and is server backwards compatible but is compatible with the latest clients. Given that the expectation of the stable channel is to be inter-compatible with the world generally, I would expect the most currently compatible server to be present there. That is not the case presently. I think we should simply backport 1.27.0 from unstable to 22.11. Notify maintainers Note for maintainers: Please tag this issue in your PR.
Change:
machine.succeed("! test -e /run/current-system/dry-activate") machine.succeed("! test -e /run/current-system/bin/switch-to-configuration") <ins> # Ensure units with multiline values work out = switch_to_specialisation("${machine}", "unitWithMultilineValue") assert_lacks(out, "NOT restarting the following changed units:") assert_lacks(out, "reloading the following units:") assert_lacks(out, "restarting the following units:") assert_lacks(out, "the following new units were started:") assert_contains(out, "starting the following units: test.service") </ins> # Ensure  works in unit names out = switch_to_specialisation("${machine}", "unitWithBackslash") <del> assert_contains(out, "stopping the following units: test.servicen") </del> assert_lacks(out, "NOT restarting the following changed units:") assert_lacks(out, "reloading the following units:") assert_lacks(out, "nrestarting the following units:")

Discussion:
See title. It also may fail to correctly parse comments within such blocks as well, but unsure. a systemd unit in config e.g. to switch configuration (though this might only happen on the second switch, trying to parse existing config?) with Per , this is valid syntax: The value of should thus be parsed to (I may have gotten the spaces wrong there) If applicable, add screenshots to help explain your problem. Patch for failing example test case (may not be perfect): also due to authoring Please run and paste the result. I was running dry-activate to a config using nixpkgs @ Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for the report! I've looked a little into this so far and switch-to-configuration doesn't actually use that much of the unit file contents, which could be fine considering that systemd's DBus interface exposes almost all of their unit properties as DBus properties. However, since NixOS uses some custom unit properties (think ), these aren't exposed as DBus properties. So instead I've gone the route of adding support for multi-line values in the INI parser used for switch-to-configuration-ng, with the eventual goal of upstreaming this support to that crate. This isn't going to be something that's immediately ready though, I should have a PR for review within the coming days. For now, I would recommend opting out of the switch-to-configuration-ng implementation with the following config until it's fixed:
The problem with INI in general is that there is no standard. The systemd syntax, after all, “is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files”.
Change:
''; # Add 2023-07-29 wcm = throw "'wcm' has been renamed to/replaced by 'wayfirePlugins.wcm'"; # Add 2023-07-29 webkitgtk_5_0 = throw "'webkitgtk_5_0' has been superseded by 'webkitgtk_6_0'"; # Added 2023-02-25 <del> wio = throw "wio has been removed from nixpkgs, it was unmaintained and required wlroots_0_14 at the time of removal"; # Added 2023-04-28 </del> wineWayland = wine-wayland; win-qemu = throw "'win-qemu' has been replaced by 'virtio-win'"; # Added 2023-08-16 win-virtio = virtio-win; # Added 2023-10-17

Discussion:
Project description Wayland compositor similar to Plan 9's rio (mirror). Note that the upstream for this software was due to being unmaintained and depending on an outdated wlroots. I am proposing that this fork of that software is to pkgs and the entry for the original in is amended to point to the fork. Note also that the only changes made from the original wio derivation to build the software (other then changing ) is the addition of . I am pinging because they where the maintainer of the deprecated software that this addition will posthumously replace. Metadata homepage URL: source URL: license: BSD 3-Clause platforms: linux
I am happy to know!
Change:
buildPythonPackage rec { pname = "tensorboard"; <del> version = "2.15.1"; </del> <ins> version = "2.16.0"; </ins> format = "wheel"; <del> disabled = pythonOlder "3.6"; </del> <ins> disabled = pythonOlder "3.9"; </ins> src = fetchPypi { inherit pname version format; dist = "py3"; python = "py3"; <del> hash = "sha256-xGwdHPE6RYxCmGiniyUx2P9faCBY1p7AhAsLx6OPHA8="; </del> <ins> hash = "sha256-JjuQmiAJyzp52qar5kwXhcwxfCWlTk2y/stkKf/FTFg="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.21.0 <!-- 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:
url = "https://lists.gnu.org/archive/html/bug-mailutils/2020-11/txtiNjqcNpqOk.txt"; sha256 = "0ghzqb8qx2q8cffbvqzw19mivv7r5f16whplzhm7hdj0j2i6xf6s"; }) <ins> # https://github.com/NixOS/nixpkgs/issues/223967 # https://lists.gnu.org/archive/html/bug-mailutils/2023-04/msg00000.html ./don-t-use-descrypt-password-in-the-test-suite.patch </ins> ]; enableParallelBuilding = true;

Discussion:
Steps to reproduce the behavior: Please run and paste the result.
The relevant output is this failure in the test suite: I'm trying to bisect it to find what causes to error. Will report back.
is the first bad commit. It makes sense that password checks in the test suite stop working after this change.
/cc The test are failing since I think I'd opt for building mailutils with libxcrypt-legacy for compatibility, rather than disabling tests, but I'm not sure.
Maybe we can have our (non-legacy) cake and eat it too .
Change:
<ins> commit 08dbad8552ecca85d3e38072f94eb864b143d218 Author: Niklas Hambüchen <mail@nh2.me> Date:   Mon Jan 22 12:52:06 2024 +0000 Cherry-pick fix for CVE-2023-49083 Cherry-Picked-From: f09c261ca10a31fe41b1262306db7f8f1da0e48a Cherry-Picked-By: Niklas Hambüchen <mail@nh2.me> diff --git a/src/cryptography/hazmat/backends/openssl/backend.py b/src/cryptography/hazmat/backends/openssl/backend.py index a3fe1bce4..58e7207c4 100644 --- a/src/cryptography/hazmat/backends/openssl/backend.py +++ b/src/cryptography/hazmat/backends/openssl/backend.py @@ -2383,9 +2383,12 @@ class Backend: _Reasons.UNSUPPORTED_SERIALIZATION, ) +        certs: list[x509.Certificate] = [] +        if p7.d.sign == self._ffi.NULL: +            return certs + sk_x509 = p7.d.sign.cert num = self._lib.sk_X509_num(sk_x509) -        certs = [] for i in range(num): x509 = self._lib.sk_X509_value(sk_x509, i) self.openssl_assert(x509 != self._ffi.NULL) diff --git a/tests/hazmat/primitives/test_pkcs7.py b/tests/hazmat/primitives/test_pkcs7.py index 4e61c5ef5..d8170bfb9 100644 --- a/tests/hazmat/primitives/test_pkcs7.py +++ b/tests/hazmat/primitives/test_pkcs7.py @@ -89,6 +89,12 @@ class TestPKCS7Loading: mode="rb", ) +    def test_load_pkcs7_empty_certificates(self, backend): +        der = b"x30x0Bx06x09x2Ax86x48x86xF7x0Dx01x07x02" + +        certificates = pkcs7.load_der_pkcs7_certificates(der) +        assert certificates == [] + # We have no public verification API and won't be adding one until we get # some requirements from users so this function exists to give us basic </ins>

Discussion:
Steps to reproduce the behavior: ceph via Happening on current (currently at ), as well as on and . Do note that while this looks like a build failure for , is the one overriding the package version to something incompatible. The unaltered package builds fine. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
See also , which I think should fix this.
Trying to build samba4Full and it errors on the same package. Just for any info for anyone.
I have addressed further review comments in Please somebody review.
Same error today with 'github:nixos/nixpkgs/' (2024-08-18)'
Change:
let major = "14"; <del> update = ".0.1"; </del> <ins> update = ".0.2"; </ins> build = "-ga"; openjdk = stdenv.mkDerivation rec {

Discussion:
Describe the bug building the package fails. To Reproduce Steps to reproduce the behavior: and wait Expected behavior Successfully building jdk14. Notify maintainers Metadata Error
Please reopen. The build still fails for me.
2 fails differently for me, but it fails. So maybe let's open a new issue?
Change:
flutterPackages-source = recurseIntoAttrs (callPackage ../development/compilers/flutter { useNixpkgsEngine = true; }); flutterPackages = flutterPackages-bin; flutter = flutterPackages.stable; <ins> flutter324 = flutterPackages.v3_24; </ins> flutter323 = flutterPackages.v3_23; flutter322 = flutterPackages.v3_22; flutter319 = flutterPackages.v3_19;

Discussion:
Package name: flutter Latest released version: 3.24.1 <!-- Search your package here: --- Current version on the unstable channel: 3.22.2 Current version on the stable/release channel: 3.22.2 <!-- 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]:
CC
Already being done

Package name: flutter (stable, but also beta) Latest released version: 3.24.0 <!-- Search your package here: --- Current version on the unstable channel: 3.22.2 (beta version: 3.23.0) Current version on the stable/release channel: 3.22.0 <!-- 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 Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
CC has been a blocker for updates since it affects the update script but it is close to being ready.
Hmm, hopefully this can be resolved soon, as it's quite critical for my work.
Yeah, I hope to have it done soon. It's close. Unfortunately, I just don't always have enough time.
Yeah, of course! Take your time :)
Hey, since the blocker is merged, how is it looking with updating the flutter version? :) No worries, if you're too busy right now
I plan on doing that on my next day off work which will be Thursday.
Change:
] ++ lib.optionals stdenv.isLinux [ qtwayland gtk3 <ins> glib-networking </ins> fmt libdbusmenu alsa-lib

Discussion:
The webkit integration of telegram-desktop is broken, resulting in bots using to not work properly. Steps to reproduce the behavior: a chat with the demo bot . the "Order Food" button telegram-desktop crashes, or the webview fails to render the webpage The webkit integration works as shown in Reference:
Arch Linux related issue closed today: , telegram-desktop now works on Arch Linux since 5.0.2.
There is also improvement on our front, it now shows "tls support is not available" in stead of straight crashing. Edit: which can be fixed by adding glib-networking.
Change:
configureFlags = [ "--shared-openssl" "--shared-http-parser" "--shared-zlib" "--shared-libuv" ]; <del> buildInputs = [ python openssl http-parser zlib libuv ] ++ (optional stdenv.isLinux utillinux); </del> <ins> # iojs has --enable-static but no --disable-static. Automatically adding --disable-static # causes configure to fail, so don't add --disable-static. dontDisableStatic = true; buildInputs = [ python openssl_1_0_2 http-parser zlib libuv ] ++ (optional stdenv.isLinux utillinux); </ins> setupHook = ../nodejs/setup-hook.sh; passthru.interpreterName = "iojs";

Discussion:
I cannot install/build anything at this moment. A dir that is created, for example: Here's an example of a full dir structure I am on nix 1.10, nixpkgs commit-id , on the staging branch, as per the fix that was introduced for the permissions flags in . I am running OSX 10.11 public beta 6 (15A278b)
I'm running OSX 10.11 GM, using master with cherry-picked from staging, and I'm having the same problem with findutils. This is really bad. I can't even delete the affected build directory because the path is too long.
This does not appear to be related to . I just reproduced it running OS X 10.11 GM on master with reverted, and I'm running into the same problem, now with coreutils instead of findutils. It's possible this is a 10.11 bug.
Yep, same problem building findutils-4.4.2 from the tarball with Xcode tools. Many of the GNU utilities have an M4 macro that checks for getcwd problems during the configure process, and that's breaking. Anyway, this appears to be an upstream/vendor issue and not related to Nix.
I've filed a Radar with Apple. Here's the Open Radar.
As a workaround, you can skip the configure test that triggers the bug: export glcvfuncgetcwdabort_bug="no" I've hacked this into preHook in in my local tree.
Thanks a lot. I'll try this straight away.
How to remove ?
I've tried all the command-line tricks I know and I still haven't been able to delete it. No word from Apple on my Radar submission, either, unfortunately.
Holy...I got the same deep directory when trying to bootstrap a Gentoo Prefix...
Finally find the solution:
Can anyone confirm this issue still exists?
I believe it was fixed in one of the El Cap updates. I haven't experienced it building Nix on Darwin recently.
Change:
url = "ftp://ftp.gnustep.org/pub/gnustep/core/${pname}-${version}.tar.gz"; sha256 = "05vjz19v1w7yb7hm8qrc41bqh6xd8in7sgg2p0h1vldyyaa5sh90"; }; <ins> outputs = [ "out" "dev" "lib" ]; </ins> nativeBuildInputs = [ pkg-config ]; propagatedBuildInputs = [ aspell audiofile

Discussion:
As the subject says on latest unstable.
I marked this as stale due to inactivity. &rarr;
These dependencies are also creeping into , so for example , a simple CLI pulls in 1.4 gigs of dependencies.
Preemptive anti stale-bot strike. Pinging people contributing to gnustep-base package:
I was about to report the same bug; the application also pulls in unnecessary stuff via and :
It's not unar as such, but instead that pulls in a bunch of stuff that doesn't belong there. I'm wondering if maybe or have some insights?
Fix in
Change:
<del> { lib, stdenv, buildGoModule, fetchFromGitHub, installShellFiles }: buildGoModule rec { pname = "steampipe"; version = "0.22.1"; src = fetchFromGitHub { owner = "turbot"; repo = "steampipe"; rev = "v${version}"; hash = "sha256-Oz1T9koeXnmHc5oru1apUtmhhvKi/gAtg/Hb7HKkkP0="; }; vendorHash = "sha256-jC77z/1EerJSMK75np9R5kX+cLzTh55cFFlliAXASEw="; proxyVendor = true; patchPhase = '' runHook prePatch # Patch test that relies on looking up homedir in user struct to prefer ~ substituteInPlace pkg/steampipeconfig/shared_test.go  --replace 'filehelpers "github.com/turbot/go-kit/files"' ""  --replace 'filepaths.SteampipeDir, _ = filehelpers.Tildefy("~/.steampipe")' 'filepaths.SteampipeDir = "~/.steampipe"'; runHook postPatch ''; nativeBuildInputs = [ installShellFiles ]; ldflags = [ "-s" "-w" ]; # panic: could not create backups directory: mkdir /var/empty/.steampipe: operation not permitted doCheck = !stdenv.isDarwin; postInstall = '' INSTALL_DIR=$(mktemp -d) installShellCompletion --cmd steampipe  --bash <($out/bin/steampipe --install-dir $INSTALL_DIR completion bash)  --fish <($out/bin/steampipe --install-dir $INSTALL_DIR completion fish)  --zsh <($out/bin/steampipe --install-dir $INSTALL_DIR completion zsh) ''; meta = with lib; { homepage = "https://steampipe.io/"; description = "select * from cloud;"; license = licenses.agpl3Only; maintainers = with maintainers; [ hardselius ]; changelog = "https://github.com/turbot/steampipe/blob/v${version}/CHANGELOG.md"; }; } </del>

Discussion:
Steps to reproduce the behavior: steampipe Occurred after a and a . <!-- 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]:
It seems that the is invalid: I’ll open a PR to fix this.
The same problem happened to the package last week: They merged the r-ryantm auto-update PR for hugo package, and then the build fails on Hydra with an invalid . Explaination: has been updated to (2 weeks ago) targeting the branch: -ryantm opened the auto-update PR for package compiled with : the staging-next PR was merged with as default: the steampipe auto-update PR was merged with an outdated because Go has been upgraded to 1.22 and the being outdated.
My fault, sorry. Just a question for the explanation, Should it then be supposed that a large proportion of Go packages have hash mismatches on master, but are not detected because go-modules are fixed-output derivations?
No problem, thanks for the help :) I'm not sure if this is already the case on master, but what I do know is that this has happened to other packages like , and . All PRs (not just those of the r-ryantm bot), created before this merge on staging-next (for Go 1.21) and merged now without having a updated for Go 1.22 are potentially impacted. Because :
Change:
pkgs.poetry2nix.cli pkgs.pkg-config pkgs.libvirt <del> pkgs.poetry </del> <ins> pkgs.python39Packages.poetry </ins> ]; }

Discussion:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)