jiebi/CodeConvo huggingface dataset:
Code change:
<del> { pkgs, lib, stdenv, fetchFromGitHub }: with pkgs.lib; </del> <ins> { lib, stdenv, fetchFromGitHub, makeWrapper, getopt, git, coreutils }: </ins> stdenv.mkDerivation rec { pname = "gitflow";

Related discussion:
text: Describe the bug I need to list the out paths of cross compiled packages beforehand which causes an eval error. To Reproduce Steps to reproduce the behavior: Expected behavior List all out paths like `. Additional context I need this feature for nixpkgs-review when cross compiling. 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 system: host os: multi-user?: sandbox: version: channels(user): nixpkgs: Maintainer information:
I think its because of the lack of splicing for perl-packages. Note however, that when that is fixed, other package sets will fail with the same issue. cc
Probably multiple issues. Have seen that problem with building xwayland for aarch64 too. Removing makeWrapper helps but probably breaks it :(. But the deps don't cross-build anyway so never got that far for now. Was thinking about opening an issue but got caught up trying to find the issue -- to no avail. Not currently at my machine, might post it later.
I marked this as stale due to inactivity. &rarr;
still important to me
Fix in
Code change:
meta = with lib; { homepage = "https://octoprint.org/"; description = "The snappy web interface for your 3D printer"; <del> license = licenses.agpl3; </del> <ins> license = licenses.agpl3Only; </ins> maintainers = with maintainers; [ abbradar gebner WhittlesJr ]; }; };

Related discussion:
text: Octoprint can't build on unstable due to a conflict of the required version for . octoprint , while the dependency requires (due to ) . Octoprint builds successfully I ran a between and (known good) , the first bad commit was I suspect that it's necessary to pin the additional dependencies (and maybe some more), too, but I'm not that experienced with packaging python packages. made the first bad commit Octoprint maintainers: system: host os: multi-user?: sandbox: version: channels(root): channels(richard): nixpkgs: Maintainer information:
Code change:
typing-extensions ]; <del> passthru.optional-dependencies = { </del> <ins> optional-dependencies = { </ins> pandas = [ pandas pyarrow

Related discussion:
text: package lists and as dependencies but upstream uses instead. Steps to reproduce the behavior: dependencies of package it to the dependencies listed by upstream and should not be in the dependencies list, but should n/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]:
That's a bot.
Thank you for the quick turnaround!
Code change:
license = licenses.gpl3; maintainers = with maintainers; [ minijackson doronbehar ]; platforms = platforms.all; <del> broken = true; </del> <ins> broken = stdenv.targetPlatform.isDarwin; </ins> }; }

Related discussion:
text: Describe the bug See https://nix- The particular cases that fail are I believe rust was updated recently (was that in the release?). It doesn't appear upstream has made a release recently, so perhaps if this report is forwarded to them they can direct us to which patches could fix the test failures etc. cc
According to and bug reports, this seems like a ulimit issue. An interesting workaround for hydra could be using , as suggested in but it's certainly isn't necessary on my machine because I've tested the build and it passed it.
sounds like it would make an already long checkPhase longer :rofl: How about we try ?
We can try this indeed. The question is, what are the default limits of a build user on hydra? Are we sure this might make a difference?
I noticed you've marked sequoia as broken in . Even if a package fails to build on hydra butt doesn't fail locally, does it mean we mark it as broken in its ? Doesn't sound right to me..
That's was the motivation for the issue being opened. If we bump in preCheck and unmark it as broken I think we should be good. ofborg can serve as testing perhaps similar to hydra.
The point is, that we haven't even tried playing with these settings. I would have tried doing it my self but since I know nothing nor I have any effect on Hydra's deployment etc., I wouldn't even know how to test it. What bothers me is the fact it was marked as broken without any attempts by someone with more influence then me to debug it's failure to build only on hydra. Are we even sure this wasn't a failure that happened only once?
Should we close this issue with the PR?
No, it's still failing , at least for hydra, it runs out of file handles
A bit off-topic maybe but I generated a Nix expression for sequoia using , as build times for sequoia where around hours for me. It works now like a charm, as every crate got its own derivation. It can be found here, as a flake: Maybe repackaging with could be an option?
This may be an option, but unpleasant as the generated deps file usually is 1-10k+ of generated noise.
Code change:
license = licenses.gpl3; maintainers = with maintainers; [ minijackson doronbehar ]; platforms = platforms.all; <del> broken = true; </del> <ins> broken = stdenv.targetPlatform.isDarwin; </ins> }; }

Related discussion:
text: (for local building, this works great)
Yeah, that noise is a bummer. Sometimes I dream of having all of packaged the way we do it with , but I guess that would blow up Nixpkgs indefinitely. But maybe someday when Nix flakes are ready? …
I'm not sure I have enough time to have a good view on this. What's most important about specifically, is the fact we use upstream's to install many other files that should be part of the package's output - files such as libraries, ZSH/Bash completion files and headers. So I'm not sure how will this go together with the approach.
If anyone is interested in a sequoia flake which is built incrementally (vs. everything built in a single derivation), I try to maintain one here:
sequoia , but it hasn't tried 0.16.0 yet - .
Yep, we need to fix it for python 38 though
Code change:
owner = "spotDL"; repo = "spotify-downloader"; rev = "refs/tags/v${version}"; <del> hash = "sha256-SmyUoMOlBJZTJH19NwTKbz/vo7Oh4tGHCQrW5DVZQWQ="; </del> <ins> hash = "sha256-I/53JapzTo6VXss82/F0qO/Etwd4i6ZP9FPjaFRHwV0="; </ins> }; nativeBuildInputs = with python.pkgs; [

Related discussion:
text: Failure happens locally as well when trying to build spotdl on the nixos-23.05 branch. this the tail of the log: The last line is apparently unrelated: (maintainer) (recent bumps)
This test doesn't fail if spotdl is built using version from this nixpkgs commit , I'm not sure if this is an upstream issue with spotdl while using newer yt-dlp versions (newer than ).
Code change:
extensionPortalSlug = "pop-shell"; }; <ins> postPatch = '' for file in */main.js; do substituteInPlace $file --replace "gjs" "${gjs}/bin/gjs" done ''; preFixup = '' chmod +x $out/share/gnome-shell/extensions/pop-shell@system76.com/*/main.js ''; </ins> meta = with lib; { description = "Keyboard-driven layer for GNOME Shell"; license = licenses.gpl3Only;

Related discussion:
text: In 's tray menu the options "Floating Window Exceptions" & "Active Hint Color" don't work. Steps to reproduce the behavior: & enable pop-shell in GNOME (Wayland). pop-shell's tray menu and try clicking the mentioned options. Further dialogs should open for the respective features.
I found the problem: the compiled (g)js are not executible in filesystem. I do not know a solution yet. Most beautiful solution, fix chmod in pop-shell (but how ...). Or after compiling with an workaround in nix. Other solutions are set path to gjs during patching. Till fixing, you can run this features in your in, with calling it per gjs ...
Code change:
# WARN: configure silently disables ld.gold if it's unsupported, so we need to # make sure that intent matches result ourselves. <del> assert enableGold -> execFormatIsELF stdenv.targetPlatform; </del> <ins> assert enableGold -> withGold stdenv.targetPlatform; </ins> let

Related discussion:
text: Despite the bintools for riscv64-linux advertises the existence of , it is actually missing. Steps to reproduce the behavior: , returns the output, there is only , no the same process for , is both advertised and available. Either evaluates to , or is available in <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Looking at ;a=blob;;h=;hb=HEAD is not supported on riscv64. tracks it upstream. I don't expect progress implementing the support any time soon.
Then we should accept the second solution: mark as false, we should also double check the availability of gold on other ELF platforms.
Code change:
eigen boost glew opencsg cgal mpfr gmp glib harfbuzz lib3mf libzip double-conversion freetype fontconfig qtbase qtmultimedia qscintilla <del> ] ++ lib.optionals stdenv.isLinux [ libGLU libGL ] </del> <ins> ] ++ lib.optionals stdenv.isLinux [ libGLU libGL wayland wayland-protocols qtwayland ] </ins> ++ lib.optional stdenv.isDarwin qtmacextras ++ lib.optional spacenavSupport libspnav ;

Related discussion:
text: The 'select file' dialog works fine, but I cant actually open or edit anything. Steps to reproduce the behavior: Either: via the GUI, then a design or a design via the command line: A edit window with a preview should appear. Please run and paste the result.
Judging by the error message, this might be as simple as compiling with wayland in the deps like ?
Omg it worked! Can I leave it with the maintainers or do you want me to file a PR?
If you submit the PR yourself then you automatically get ownership/credit for your work :-)
Code change:
kovirobi = "Kovacsics Robert <kovirobi@gmail.com>"; kragniz = "Louis Taylor <kragniz@gmail.com>"; ktosiek = "Tomasz Kontusz <tomasz.kontusz@gmail.com>"; <ins> lassulus = "Lassulus <lassulus@gmail.com>"; </ins> lethalman = "Luca Bruno <lucabru@src.gnome.org>"; lhvwb = "Nathaniel Baxter <nathaniel.baxter@gmail.com>"; linquize = "Linquize <linquize@yahoo.com.hk>";

Related discussion:
text: I don't know much more than this: and but I don't know how to fix this.
I was bit by this as well. It fails on other key for me -- looks like it would fail on any.
How did you solve this issue?
Can someone tell me where this "keydir" should be located? I cannot find it in my !
The keydir should be in your gitolite datadir, which is /var/lib/gitolite in the default settings.
Okay. My shows:
oh it should be in "/var/lib/gitolite/.gitolite/keydir", my bad.
Okay, everything is there. How to check why it fails?
It failed for me for every key on v3.6.2. So, besides upgrading gitolite to v3.6.3, there is not really much you can do.
Update solved the issue.
Code change:
<ins> { lib, stdenvNoCC, fetchzip }: stdenvNoCC.mkDerivation rec { pname = "jigmo"; version = "20230816"; src = fetchzip { url = "https://kamichikoichi.github.io/jigmo/Jigmo-${version}.zip"; hash = "sha256-wBec7IiUneqCEyY704Wi6F6WG0Z1KK7gBGcJhRjrRDc="; }; installPhase = '' runHook preInstall install -Dm644 *.ttf -t $out/share/fonts/truetype/ runHook postInstall ''; meta = with lib; { description = "Japanese Kanji font set which is the official successor to Hanazono Mincho"; homepage = "https://kamichikoichi.github.io/jigmo/"; license = licenses.cc0; maintainers = [ maintainers.marsam ]; platforms = platforms.all; }; } </ins>

Related discussion:
text: Project description Continuation (rebranding) of Hanazono font (nixpkg: hanazono). Supports a lot more Unicode glyphs (141,457 glyphs, mostly CJK). English README: Metadata homepage URL: source URL: license: CC0 platforms: N/A (TTF binary) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
<ins> --- souper-1be75fe6a96993b57dcba038798fe6d1c7d113eb-src/CMakeLists.txt.orig     2017-01-20 13:55:14.783632588 -0600 +++ souper-1be75fe6a96993b57dcba038798fe6d1c7d113eb-src/CMakeLists.txt  2017-01-20 13:55:20.505728456 -0600 @@ -33,7 +33,10 @@ OUTPUT_VARIABLE LLVM_SYSTEM_LIBS OUTPUT_STRIP_TRAILING_WHITESPACE ) -set(LLVM_LIBS "${LLVM_LIBS} ${LLVM_SYSTEM_LIBS}") + +if (LLVM_SYSTEM_LIBS) +  set(LLVM_LIBS "${LLVM_LIBS} ${LLVM_SYSTEM_LIBS}") +endif() execute_process( COMMAND ${LLVM_CONFIG_EXECUTABLE} --ldflags </ins>

Related discussion:
text: was recently updated to use LLVM 4.0, which is rather good news for my use cases. Can we update our version to use this? It also seems they now so perhaps we should switch to using that as well? (maintainer)--LMK your thoughts and if you want to tackle it or want me to (I'd probably get to it this weekend). Thanks!
I'm pretty busy these days but if you're interested in updating it feel free :+1:
Sure thing! Although actually we'll need to actually add LLVM 4.0 first, forgot that wasn't in-tree yet :innocent:. Maybe I'll give that a go as well :+1: (cc )
Code 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>

Related discussion:
text: Steps to reproduce the behavior:  nixos-unstable Noticed when setting and rebuilding &lt;!-- 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]:
You won't get a reply if you leave that empty.
I'm having the same issue I didn't notice when it happened, but I also have sambaFull
Same error whit the package .
This seems related to
That turned out not to be the issue. The actual error: In colour so that one can actually make sense of C++ error messages: ! One potential problem here: This is because of having: Switching to : Builds Removing entirely (which swiches to ): Fails on new related errors (see below) Removing and : Fails because Ceph requires lua = 5.3 and nixpkgs's default is still 5.2: CMake saysCould NOT find Lua (missing: LUAINCLUDEDIR) (Required is at least version "5.3")` Build failure with : <details</detailsI noticed Arch . But we can just use to fix the build.
PR for the
Code change:
mv nextstep/Emacs.app $out/Applications ''; <del> # https://github.com/NixOS/nixpkgs/issues/13573 doCheck = false; </del> meta = with stdenv.lib; { description = "GNU Emacs 25 (pre), the extensible, customizable text editor"; homepage    = http://www.gnu.org/software/emacs/;

Related discussion:
text: When adding to and running , emacs 25 builds and fails with 4 unexpected TRAMP mode test errors: The full output contains null bytes and weird control characters that don't let me paste this into a gist easily. Is that part of the test or indicative of the problem? cc
ok... i think this will contain the build output? again if i open it in emacs there are lots of control characters. had to zip so github wouldn't complain.
I disabled for emacs25pre, for now, on my system. I hope this will be resolved upstream before next release ...
It's quite possible that tramp-related tests fail because there is no proper networking support in the build chroot, i.e. it's not possible to resolve host names or service names. Another source of trouble could be the lack of an UTF-8 capable locale in our default build environment. Anyhow, it would be really good to report those errors upstream to make sure that the next Emacs release has them fixed in one way or another.
I've been working with the Tramp author for the past several days about these failures, and we've identified that the problem is somewhere in the environment that the tests are presented with, but we don't yet know what exactly. I'm still digging into it.
Code change:
auth_request /oauth2/auth; error_page 401 = @redirectToAuth2ProxyLogin; <del> # pass information via X-User and X-Email headers to backend, # requires running with --set-xauthrequest flag </del> <ins> # set variables being used in locations."/".extraConfig </ins> auth_request_set $user   $upstream_http_x_auth_request_user; auth_request_set $email  $upstream_http_x_auth_request_email; <del> proxy_set_header X-User  $user; proxy_set_header X-Email $email; # if you enabled --cookie-refresh, this is needed for it to work with auth_request </del> auth_request_set $auth_cookie $upstream_http_set_cookie; <del> add_header Set-Cookie $auth_cookie; </del> ''; }; }) cfg.virtualHosts)));

Related discussion:
text: OAuth2 Proxy's Nginx plugin used to forward and headers to downstream programs. This stopped working after I updated on unstable channel, which is potentially related to or . Steps to reproduce the behavior: up OAuth2 Proxy + Nginx up of header name . does not recognize the session More simply: up OAuth2 Proxy + Nginx or something similar the headers — and used to be present, but not anymore and are passed to downstream servers under Nginx. I have I went on upgrade of nixpkgs unstable from sometime late January to a few hours ago, which is what led me to the two PRs mentioned above. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
are you able to play around a bit and confirm if the changes mentioned introduced this regression?
yes. I can't really pin-point to what exactly since there were a lot of changes. Instead, I just have a local fork from (prior to the changes mentioned in the PRs above).
I have a pretty good idea what it could be.
Can you give a try? I didn't test it yet, so it could completely break everything and be completely insecure, just as warning.
fantastic work please let us know how it goes ‍
Sorry for the late reply, I haven't been able to have time to test it out. Now that I do, it seems like has been converted to . This won't be an easy find-and-replace for me to try in my setup, so I will have to find some time to do proper cleanup.
Code change:
"test_preload_song" "test_song_from_search_term" "test_song_from_url" <ins> "test_yt_search" </ins> ]; makeWrapperArgs = [

Related discussion:
text: Failure happens locally as well when trying to build spotdl on the nixos-23.05 branch. this the tail of the log: The last line is apparently unrelated: (maintainer) (recent bumps)
This test doesn't fail if spotdl is built using version from this nixpkgs commit , I'm not sure if this is an upstream issue with spotdl while using newer yt-dlp versions (newer than ).
Code change:
# "lift" packages like curl from the final stdenv for Linux to # all-packages.nix for that platform (meaning that it has a line # like curl = if stdenv ? curl then stdenv.curl else ...). <del> // extraAttrs; in stdenv) </del> <ins> // extraAttrs ); in stdenv-overridable </ins>

Related discussion:
text: I tried to build a package with debug symbols today and failed. NixOS wiki and nixpkgs repository comments say the following should work: Please run and paste the result.
It worked in Aug 2018: Bisected down to breakage at : Looks like it stems from the fact that does not expose anymore, only . /cc
Woah. master and both work for me with nix stable.
That's surprising. Here is my attempt at current master checkout: I tried removing and seeing the same failure. I wonder why it works for you. Might be a different stdenv?
Does it mean and are the same object?
i can reproduce
I can also reproduce with stable Nix (2.3.14):
Hmm, the issue is that / slaps the on after is defined, closing over the old . In Smalltalk paralance, this would be an issue of insufficiently "late binding".
Still reproducible on current master ()
I ran into this.
Bump, ran into this while updating the Nixpkgs pin on a project of mine.
There should be a test for this :)
Gonna spend next hour or two trying to fix this.
Things that are also missing:
So, this function is not executed on passed through stdenv. Not yet sure why.
Yeah, I've fixed it (thanks, for being there :heart:)
Post-mortem: always read threads. Solution was kinda already provided in , but I delved right in without knowing that)
atleast you now know more about stdenv :slightlysmilingface:
How is the PR looking? I've been waiting on this for a couple of weeks to debug an intermittent crash I'm having with xfce4-sesion :)
Code change:
https://github.com/slashmili/alchemist.vim/,, https://github.com/dense-analysis/ale/,, https://github.com/vim-scripts/align/,, <ins> https://github.com/goolord/alpha-nvim/,HEAD, </ins> https://github.com/Olical/aniseed/,, https://github.com/pearofducks/ansible-vim/,, https://github.com/ckarnell/antonys-macro-repeater/,,

Related discussion:
text: Project description describe the project a little is a highly configurable dashboard for Neovim. It's an alternative to Metadata homepage URL: source URL: license: MIT platforms: Anything that can run Neovim, I would assume
Code change:
patches = [ ./make-paths-configurable.patch ]; configurePhase = '' <del> pixiePath="${pixie}/bin/pixie-vm"  </del> <ins> pixiePath="${pixie}/bin/pixie"  </ins> basePath="$out/share/dust"  <ins> rlwrapPath="${rlwrap}/bin/rlwrap"  </ins> substituteAll dust.in dust chmod +x dust '';

Related discussion:
text: Running reports: To Reproduce on NixOS 19.09. . Metadata I ran but got .
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
I had this same problem today.
I marked this as stale due to inactivity. &rarr;
Not stale; this is still a problem on a flakes based NixOS system using