jiebi/CodeConvo huggingface dataset:
Code change:
installPhase = '' mkdir -p $out/bin <del> cp git-open $out/bin </del> <ins> mv git-open $out/bin </ins> installManPage git-open.1 wrapProgram $out/bin/git-open  <del> --prefix PATH : "${lib.makeBinPath [ git gnugrep ]}"  </del> <ins> --prefix PATH : "${lib.makeBinPath [ gnugrep ]}"  </ins> --suffix PATH : "${lib.makeBinPath [ xdg-utils ]}" '';

Related discussion:
text: Package name: git-open Latest released version: 3.0.0 <!-- Search your package here: --- Current version on the unstable channel: 2.1.0 Current version on the stable/release channel: 2.1.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.
The latest version of listed on the project's is (Dec 3, 2018), however was released on the project's (Jul 18, 2022).
Code change:
defaultBuildInputs = extraBuildInputs; <ins> stdenv = (stdenv-overridable argsStdenv); </ins> # The stdenv that we are producing. <del> stdenv = </del> <ins> in </ins> derivation ( lib.optionalAttrs (allowedRequisites != null) { allowedRequisites = allowedRequisites

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:
++ optionals (versionAtLeast version "11.0.0") [ "aarch64-darwin" ] ++ optionals (versionOlder version "19.0.0") [ "i686-linux" ]; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; <del> knownVulnerabilities = optional (versionOlder version "15.0.0") "Electron version ${version} is EOL"; </del> <ins> knownVulnerabilities = optional (versionOlder version "18.0.0") "Electron version ${version} is EOL"; </ins> }; fetcher = vers: tag: hash: fetchurl {

Related discussion:
text: Electron is a security-critical component for several desktop applications and we shouldn't be keeping EOL versions around. Please remove all versions older than 18 if possible. The latest version is 21. via cc
There are at least 14 packages that require Electron < 18, should we drop them as well? Isn't it better to just mark Electron < 18 packages as insecure via ?
That is a start, ideally we could move those packages off older Electron versions, but I don't know how feasible that is.
Code change:
# TODO(@Ericson2314): Build bionic libc from source bionic = if stdenv.hostPlatform.useAndroidPrebuilt <del> then pkgs."androidndkPkgs_${stdenv.hostPlatform.androidNdkVer}".libraries </del> <ins> then pkgs."androidndkPkgs_${stdenv.hostPlatform.androidNdkVersion}".libraries </ins> else callPackage ../os-specific/linux/bionic-prebuilt { }; boolstuff = callPackage ../development/libraries/boolstuff { };

Related discussion:
text: Steps to reproduce the behavior: to build (required by ) fail Full trace (libxml2): Doesn't happen on , before I have no idea if this happens on any other platforms, needs triage. I also have no idea why python for linux needs something darwin?!? This also breaks the evaluation of , but not Python team <!-- You know a bunch about splicing --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
buildPythonPackage rec { pname = "pex"; <del> version = "2.1.137"; </del> <ins> version = "2.1.141"; </ins> format = "flit"; disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; <del> hash = "sha256-ywzmz2R1fdW6TzTEYHq0hfeQnmwkzUecoozlIgXw7es="; </del> <ins> hash = "sha256-EsIurZNgWslUciz5Pc2hj2F4tAJ8hQydRWnVIWdryDc="; </ins> }; nativeBuildInputs = [

Related discussion:
text: fails to run most basic commands when installed via nix, due to an error seemingly related to it's vendoring of some dependencies. On a NixOS machine or Darwin with Nix installed, run: <details<summaryPEXVERBOSE=9 nix shell -c pex</summary</detailsA pex-managed python repl should open, same behavior as in a venv. For comparision: <details<summarynix shell nixpkgs#python3 -c sh -c "python -m venv ./venv; ./venv/bin/pip install pex; ./venv/bin/pex"</summary</detailsthe site-packages path where pex lies is in the /nix/store, so read-only. however, the the vendored dependencies are included in the closure; exists and includes attrs, pip, etc. maybe could help us interpret the error and/or how to debug this efficiently? :) some simple commands such as do work. same commands run fine in a venv on the same machines using the same python intepreter. same symptoms on NixOS and when installed via nixpkgs unstable on darwin. the tempdir path mentioned in the error message is writeable, but non existent or cleaned up. the alternative script/entrypoint shows similar symptoms: <details<summaryPEX_VERBOSE=9 nix shell -c pex3 lock create requests</summary</detailsHope you don't mind the pings (maintainer) (done multiple recent updates) (pex developer)
NixOS is pretty exotic in my world. Can you confirm that I can use a container to emulate this? I assume I can, but just to check. I'll be back at a keyboard August 3rd to repro, but I expect the workaround for now is to set PEX_ROOT somewhere writable. Pex does try to detect the default is unwritable and fall back to tmp, but perhaps all these measures are foiled in this environment.
wow, that was fast! :) Should be able to emulate in a container or almost anywhere you can get a recent nix with flakes enabled running. Let me know if can assist you with that!
Code change:
buildPythonPackage rec { pname = "pex"; <del> version = "2.1.137"; </del> <ins> version = "2.1.141"; </ins> format = "flit"; disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; <del> hash = "sha256-ywzmz2R1fdW6TzTEYHq0hfeQnmwkzUecoozlIgXw7es="; </del> <ins> hash = "sha256-EsIurZNgWslUciz5Pc2hj2F4tAJ8hQydRWnVIWdryDc="; </ins> }; nativeBuildInputs = [

Related discussion:
text: (contact info in profile) Many environment variables like and are different when run via nix (symlinks to /nix/store), but "~/" and other filesystems are not namespaced or sandboxed in any way here. is writable by my user. I've tried with PEXROOT set, but that didn't incfluence the output. Going to have another look tomorrow, but it's quite late already here in CEST.
I don't think notifications are sent for linked issues; think I found a fix in Thanks to for pointing me into the right direction
Ok, this works perfectly fine in nixos (N.B.: I 1st used the vanilla image which is not sandboxed and everything worked fine; so I went through a bit of extra effort below to enable sandboxing in the image and prove it out to see if the sandboxing behavior was relevant to repro): So I'll try to repro using .
Ok, after following the multi-user install instructions for the command here: and enabling flakes, etc - I do repro: So, for someone with knowledge of nixos vs nix shell vs flakes, this would presumably mean something. I'll continue to dig in my shell to see what's up.
Alright, Pex 2.1.141 should fix. Please let me know either way
Sandboxed builds do not work inside Docker as we can't create required namespaces from an unprivileged container.
I've tested a build against your tag and that works just fine on NixOS (with sandboxing enabled).
Ok, great. I used in addition to mounting in that custom nix config.
Code change:
python2Full = python2.override{x11Support=true;}; python27Full = python27.override{x11Support=true;}; python3Full = python3.override{x11Support=true;}; <del> python35Full = python35.override{x11Support=true;}; </del> python36Full = python36.override{x11Support=true;}; python37Full = python37.override{x11Support=true;}; python38Full = python38.override{x11Support=true;};

Related discussion:
text: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.
Code change:
<ins> { stdenv , lib , fetchFromGitHub , pkg-config , autoreconfHook , autoconf-archive , guile , texinfo , rofi }: stdenv.mkDerivation rec { pname = "pinentry-rofi"; version = "2.0.3"; src = fetchFromGitHub { owner = "plattfot"; repo = pname; rev = version; sha256 = "sha256-EzbeMAhdn9SuSmE+aMHeyuje3s74isIKRDTrFO3bX04="; }; nativeBuildInputs = [ autoconf-archive autoreconfHook pkg-config texinfo ]; buildInputs = [ guile ]; propagatedBuildInputs = [ rofi ]; meta = with lib; { description = "Rofi frontend to pinentry"; homepage = "https://github.com/plattfot/pinentry-rofi"; license = licenses.gpl3Plus; platforms = platforms.unix; maintainers = with maintainers; [ seqizz ]; }; } </ins>

Related discussion:
text: Project description It's a pinentry app, using rofi. I , but failed with (pls ignore metadata on that derivation, was testing): Metadata homepage URL: source URL: license: gpl-3+ platforms: linux
I just gave it try and quickly hacked together the following (based on ): Please feel free to use this as a base for a pr.
Code change:
owner = "OctoPrint"; repo = "OctoPrint"; rev = version; <del> hash = "sha256-SYN/BrcukHMDwk70XGu/pO45fSPr/KOEyd4wxtz2Fo0="; </del> <ins> hash = "sha256-71uE8JvcS++xH8WSVWj5x0+9s3XIwf3A64c6YtxpSRc="; </ins> }; propagatedBuildInputs = with self; [

Related discussion:
text: Steps to reproduce the behavior: also yields the "got" hash. The hash was last changed in nixpkgs @
we just hit the same issue in Alpine - it looks like the upstream uses format specifiers for that change depending on the state of the repo: (found by [here][1]) in your case it might help to do instead ( provided that doesn't just do on the remote URL, but fetches the repo in some other way ): [1]:
thanks for the new upstream issue and the infos!
Code change:
LDFLAGS = "-Wl,-rpath,${placeholder "out"}/lib/${binaryName}"; }; <ins> # workaround for clang statically linking against libstdc++ NIX_LDFLAGS = lib.optionals stdenv.cc.isGNU [ "-L${stdenv.cc.cc.lib}/lib" ]; </ins> # tests were disabled in configureFlags doCheck = false;

Related discussion:
text: After the recent update of nixos-23.05 from to (which included , updating Firefox from 119.0.1 to 120.0) Firefox started crashing, apparently when WebGL gets used. Steps to reproduce the behavior: 120.0 with a clean profile. a crash. Some crash reports: https://crash- https://crash- These crash reports point to , which shows a matching backtrace: The underlying problem might be somewhat different though, because the offending option is not present in any Hydra build logs ( is present though). system: host os: multi-user?: sandbox: version: nixpkgs:
You can disable WebGL temporarily while the bug is being fixed. about:config webgl.disabled set to true
also works without crashing even with WebGL enabled.
Hydra build log: This is the same root cause as described in (originally for Ubuntu Firefox Beta PPA for 18.04 LTS). This is caused by building in such a way that and (and ) embed and export their own version of the code from libstdc++ (in particular ) instead of using dynamic linking to call into the code that is exported by . It is unsafe to do that because of the flag that is used to compile these binaries, and starting with Firefox 120 that results in a WebGL crash. For the Ubuntu Firefox Beta PPA this was caused by compiling with but we do not understand why this situation occurs for the NixOS 23.05 build at the moment. But it does occur (see screenshot below). <img width="399" alt="Commands showing that indeed firefox, and all export std::locale::Sinitialize with this build" src=""If someone knows how to ensure that and (and ) do not embed and export code for , that should fix the crash (we should not see a for when using on these binaries, in fact we should not see it at all because this function is internal to the implementation).
Also apparently the problem is specific to the branch:
Comparing the “good” build log () with the “bad” one () shows the difference in clang versions (and the extra option for the build, which uses clang-15): And the difference is indeed in the compiler behavior.
Code change:
LDFLAGS = "-Wl,-rpath,${placeholder "out"}/lib/${binaryName}"; }; <ins> # workaround for clang statically linking against libstdc++ NIX_LDFLAGS = lib.optionals stdenv.cc.isGNU [ "-L${stdenv.cc.cc.lib}/lib" ]; </ins> # tests were disabled in configureFlags doCheck = false;

Related discussion:
text: Using the test file from the Mozilla bug report: With the new compiler from : With the old compiler from : Apparently the important difference here is that the compiler from passes the option to , and the directory contains , therefore the linker uses the definitions from the shared library as intended. However, the compiler from passes the option, which refers to a nonexistent directory ( actually exists, and there is the symlink, but these directories are not mentioned in the parameters), therefore the linker does not see and uses only from , so the resulting shared library contains copies of all libstdc++ functions, which breaks things when is also specified. So apparently the real problem is that in the branch uses wrong library paths for the GCC libraries.
I'm currently building with the following patch, thanks to trofi. This approach fails, as it overrwrites all previously accumulated flags. This was apparently fixed on master in
This will most likely be resolved through , but I'm still testing a solution that would be more localized to firefox and thus arrive quicker.
The workaround is part of the latest release-23.05 evaluation. You can follow its progress here:
Code change:
{ stdenv, fetchurl, libgpgerror, gnupg, pkgconfig, glib, pth, libassuan , file, which, ncurses <del> , autoreconfHook </del> <ins> , autoreconfHook, fetchpatch </ins> , git , texinfo , qtbase ? null

Related discussion:
text: (this is a qt specific test): Loc: [t-(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 1047ms This seems to affect master too, but for some reason it's been built successfully once. The aarch64 build started failing when updating qt5 from 5.11 to 5.12 making it the likely root cause: Edit: the cause was expired testing keys: cc maintainer cc as you've been active in keeping plasma/kde up to date lately. ping staging next:
Did you found ? Sounds very similar and should be fixed...
No didn't find that, but yeah, that sure looks exactly like the same issue. I'm guessing the qt issue were never actually fixed: Blame on the test gives no change at least:
And applying the suggested patch does fix the test: diff +++ gpgme-1.10.0/lang/qt/tests/t- -455,7 +455,7 private Q_SLOTS: QVERIFY(result.numSignatures() == 1); auto sig = result.signatures()[0]; QVERIFY(sig.validity() == Signature::Marginal); QVERIFY(sig.validity() == Signature::Marginal sig.validity() == Signature::Unknown); auto stats = ().userID(0).tofuInfo(); QVERIFY(!stats.isNull());
So, what are we want to do? Do you maybe want to comment on the upstream issue?
Hmm, strange, I'm getting the same failure on master (using ), forcing single core does not fix the problem though, so probably not a race condition. I've reported the failure as you suggested:
The cause is most likely qt 5.11 to 5.12 upgrade, as the aarch64 build started failing the test then:
So the keys used in this test expired on 2019-01-06, which explains why we suddenly saw this without any apparent reason. :
Thanks for fixing this and sorry for my late reply... (Edit: And of course also thanks
Code change:
<del> { lib </del> <ins> { stdenv , lib </ins> , buildPythonPackage , fetchpatch , fetchPypi

Related discussion:
text: Describe the bug Tensorflow binary builds don't work on mac os. (neither do the source build, but that's a separate issue) To Reproduce $ nix-build '<nixpkgs' --show-trace -A python37Packages.tensorflow-bin_2 this derivation will be built: /nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow- building '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-'... Sourcing python-recompile-bytecode- Sourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing wheel setup hook Using wheelUnpackPhase Sourcing pip-install-hook Using pipInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook unpacking sources Executing wheelUnpackPhase Finished executing wheelUnpackPhase patching sources configuring /private/tmp/nix-build-python3.7-tensorflow- /private/tmp/nix-build-python3.7-tensorflow- Unpacking to: unpacked/tensorflow-2.1.0...OK substitute(): ERROR: file '--replace' does not exist error: --- Error
--------------------------------------------------------------------------- nix-build builder for '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-' failed with exit code 1 host os: multi-user?: sandbox: version: channels(noah): nixpkgs: yaml attribute: module:
Code change:
<del> { lib </del> <ins> { stdenv , lib </ins> , buildPythonPackage , fetchpatch , fetchPypi

Related discussion:
text: Describe the bug tensorflow-bin_2 wants gast-3.2.0 due to but gast has been updated to 3.3.0 so tensorflow refuses to install: To Reproduce Notify maintainers Metadata Maintainer information:
There are also other dependencies that fail the version checks: scipy==1.4.1 and tensorflow-estimator<2.2.0,=2.1.0rc0.
This compiles i'll test it, any feedback appreciated
Got some issues
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Related .
It looks like fixes this.
Code change:
gsound gtk3 json-glib <del> libsoup </del> <ins> libsoup # referenced in js/ui/environment.js </ins> libstartup_notification libXtst libXdamage

Related discussion:
text: I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. 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.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.
Code change:
gsound gtk3 json-glib <del> libsoup </del> <ins> libsoup # referenced in js/ui/environment.js </ins> libstartup_notification libXtst libXdamage

Related discussion:
text: I have user-installed Cinnamon applets, desklets, extensions, themes, which have been installed in the home folder by a different OS (as far as i remember). Many of them work under NixOS (some do not: ). However, i cannot update them. When i try, i get the message: The same happens if i try to install a new applet. Steps to reproduce the behavior: up Cinnamon desktop on NixOS and log in. to install an applet. Should be able to install and update user-installed applets, desklets, extensions, themes. ! I am just beginning to switch over to Cinnamon from GNOME 3 (having been fed up with GNOME, especially under NixOS).
Installing [][gettext] that provided solved the issue. Shouldn't be a dependency of Cinnamon desktop then? [gettext]:
Code change:
with stdenv.lib; stdenv.mkDerivation rec { <del> name = "corosync-2.4.3"; </del> <ins> pname = "corosync"; version = "2.4.5"; </ins> src = fetchurl { <del> url = "http://build.clusterlabs.org/corosync/releases/${name}.tar.gz"; sha256 = "15y5la04qn2lh1gabyifygzpa4dx3ndk5yhmaf7azxyjx0if9rxi"; </del> <ins> url = "http://build.clusterlabs.org/corosync/releases/${pname}-${version}.tar.gz"; sha256 = "0pxs18vci9kq3qnqsg5i1h35jrxxiccwbm0mzja3g8j3izdsyvmb"; </ins> }; nativeBuildInputs = [ makeWrapper pkgconfig ];

Related discussion:
text: , CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
merged
Need to keep open for 20.09
Merged to 20.09 too. Closing.
Code change:
viw = callPackage ../applications/editors/viw { }; <ins> virter = callPackage ../applications/virtualization/virter { }; </ins> virt-viewer = callPackage ../applications/virtualization/virt-viewer { }; virt-top = callPackage ../applications/virtualization/virt-top { };

Related discussion:
text: Project description Virter is a command line tool for simple creation and cloning of virtual machines based on libvirt Metadata homepage URL: source URL: Blogs: , license: Apache v2 platforms: Linux only written in: go Thanks a ton!
Code change:
iperf3 = callPackage ../tools/networking/iperf/3.nix { }; iperf = iperf3; <ins> ipfetch = callPackage ../tools/networking/ipfetch { }; </ins> ipfs = callPackage ../applications/networking/ipfs { buildGoModule = buildGo116Module; };

Related discussion:
text: Project description Neofetch like tool that can lookup IPs. :earth_americas: Metadata homepage URL: source URL: license: gpl3 platforms: posix shell
I'll do this myself.