jiebi/CodeConvo huggingface dataset:
Change:
gccApple = throw "gccApple is no longer supported"; <ins> libstdcxxHook = makeSetupHook { substitutions = { gcc = gcc-unwrapped; }; } ../development/compilers/gcc/libstdc++-hook.sh; </ins> # Can't just overrideCC, because then the stdenv-cross mkDerivation will be # thrown away. TODO: find a better solution for this. crossLibcStdenv = buildPackages.makeStdenvCross {

Discussion:
The clang stdenv (e.g., ) on recent unstable channel no longer seems able to find the C++ headers when used as the stdenv for a build. yields Curiously the libcxxStdenv does work: and just for sanity, it does work on 17.03 and usually works otherwise O:) System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc and since they were tracking down a similar problem in the Darwin clang stdenv recently.
This only happens on linux, it looks like the -isystem flags from gcc used to leak into the clang stdenv somehow.
This works, we could fix the clang stdenv to include those by default. Unless there's a reason to use the gcc headers, but using libcxx makes more sense I would think.
cc
Is this significantly different than using ? IMO it's an important use case, using clang w/gcc's libstdc++, it's the most "compatible" with Linux things and is the default way to use clang (for now, anyway).
This have something to do with ?
From the name I wouldn't expect to still use the gcc libstc++, but the use case makes sense. The condition for  looks good, not sure why it's not working.
noticed that the logic would only apply if that variable was undefined, not empty. But now ensures that it is defined (and empty if not otherwise defined). The best solution would be to handle the default in so there's no empty fallback at any point.
I'll do this for 17.09
appears to be a victim of this issue as well
seems to be defined before. I currently test the following patch: this is not a good fix though, but if this the root cause, I can come up with a better patch.
That would break or make it behave incorrectly.
i know
Is this supposed to work now? At least I am having the same problem on unstable(18.03); g++ works but clang fails and does not find the headers. I might have missed something though, rather new to nix.
Maybe you need instead of ? Edit: nevermind, I can also reproduce your issue
After some testing, I found that using without will cause the c++ header not found error.

(I guess this is not a bug?) To successfully compile a simple file, I need
See
Indeed it works in nix-shell, thanks.
There's probably a bigger issue here of people wanting our tools to work normally outside of Nix builds and shells, but that's a much bigger endeavor.
Yeah we'd need like a , which would easiest to accomplish if we did less dependency stuff in bash.
Change:
sha256 = "0bw5wivswwh7vx897q8xc2cqgkqhdzk8gh6fnav2kf34sngigiah"; }; <del> buildInputs = [ ncurses asciidoc xmlto docbook_xsl readline git makeWrapper ]; </del> <ins> buildInputs = [ ncurses asciidoc xmlto docbook_xsl readline git makeWrapper ] ++ stdenv.lib.optionals stdenv.isDarwin [ libiconv ]; </ins> preConfigure = '' export XML_CATALOG_FILES='${docbook_xsl}/xml/xsl/docbook/catalog.xml ${docbook_xml_dtd_45}/xml/dtd/docbook/catalog.xml'

Discussion:
After a bit of googling I get the impression that people think this may be a flaw in ncurses, but I haven't managed to pin it down. Something to do with tig trying to create windows that are 0 lines high, which the ncurses api claims to allow but the code doesn't, maybe? This happens in the unstable channel as well as master as of . I also verified that it's not fixed upstream in the tig source.
Can you provide more information? GDB logs, etc? I'm not able to test on darwin, but I try to help whereever I can...
I'll see if I can produce more debugging info later, once I'm back home where my mac is.
I also get this error when I installed tig from nix-env. I installed tig from the Git repo (), and it works fine.
Did you install the very same release or did you use latest master (or something) from the repo?
I just did a , so it's , as of now.
But how did you install it from the git repo?
I followed the instructions here:
Can you try to checkout the tag for 2.1.1 in your tig clone and from there? Does it fail like when installing via ?
Just tested the tag and it works just fine.
Okay, so it is an issue with the package definition. Someone with a darwin machine has to investigate, I cannot as I do not have a darwin machine, sorry. The information posted in this issue should be helpful anyways.
Change:
"--with-out-ext=tk" # on yosemite, "generating encdb.h" will hang for a very long time without this flag "--with-setjmp-type=setjmp" <ins> # silence linker warnings after upgrading darwin.cctools to 949.0.1, # which ruby treats as problem with LDFLAGS # https://github.com/NixOS/nixpkgs/issues/101330 "LDFLAGS=-Wl,-w" </ins> ] ++ op (stdenv.hostPlatform != stdenv.buildPlatform) "--with-baseruby=${buildRuby}";

Discussion:
Describe the bug Ruby configure step has been failing on darwin since with the following error: This appears to be due to the new linker warning , as adding to ruby allows it to build successfully. git bisect log: <details</detailsSee for the offending code in cctools. Hydra build Notify maintainers cctools: ruby:
Diff if someone needs it quickly. I couldn't find the root cause and it is breaking a lot for darwin so we maybe should just take this fix.
I think this is also causing haskellPackages.trifecta to fail which is blocking the unstable channel It seems to me that there is a deeper issue here involving the new cctools and how they are being invoked: Why are two min versions being passed? Can we avoid that? If not, is it feasible going forward to keep patching this warning out of cctools?
I think the correct ping is but I don't seem to have the clearance ;)
cc
I'm currently testing out this patch to disable the warning - ruby is working, haskellPackages.trifecta also works. Not sure if this is the right solution though, if the multiple versions being passed in the first place are the root problem.
Seems that the root cause is mentioned in the PR:
I guess I'm still not really clear on who's in the wrong here. Is cctools being overly strict by adding this warning? Or is clang overstepping its role by auto-adding extra flags?
I think means that this is the problem as clang is also adding the args:
oops forgot the ping cc
Ok, here's a patch to skip clang's . Ruby is working under this as well. Haven't gotten to trifecta yet but probably works.
May as well keep this open until the main problem is resolved.
Another option that seems to work: removing our extra -macosxversionmin from bintools-wrapper since it is already by clang. Builds ruby and haskellPackages.trifecta. So to recap, the options that have been tested to work so far are remove warning from cctools remove extra min-version arg from clang remove extra min-version arg from our bintools wrapper
Also encountering this issue when building pyobjc.
I tested the bintool option which caused a rebuilt of literally everything.

I think this is maybe the best approach in the long term but it is totally unsuitable for local rebuilds. Next I tried the cctools patch which only caused the Darwin Frameworks, perl and some others to rebuild which could work locally. Same with the clang.
Pinging again, also who may be able to help?
Opened a PR:
This is also breaking
Merged to , I'll keep this open until it lands in master as needs to be reverted.
Reverting in
Change:
]) ++ (lib.optionals nvidiaPatches [ (fetchpatch { <del> url = "https://aur.archlinux.org/cgit/aur.git/plain/nvidia.patch?h=hyprland-nvidia-git&id=757614af7729352fda534abe9eb1a88fe77dfe04"; </del> <ins> url = "https://aur.archlinux.org/cgit/aur.git/plain/0001-nvidia-format-workaround.patch?h=hyprland-nvidia-screenshare-git&id=2830d3017d7cdd240379b4cc7e5dd6a49cf3399a"; </ins> sha256 = "A9f1p5EW++mGCaNq8w7ZJfeWmvTfUm4iO+1KDcnqYX8="; }) ]);

Discussion:
Steps to reproduce the behavior: Enable Broken nix config : <!-- 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.
cc
Change:
dugong = callPackage ../development/python-modules/dugong { }; <ins> dukpy = callPackage ../development/python-modules/dukpy { }; </ins> dulwich = callPackage ../development/python-modules/dulwich { inherit (pkgs) gnupg; };

Discussion:
Project description Python package: Simple JavaScript interpreter for Python Metadata source URL: license: mit platforms: wherever Python runs Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
psychrolib = callPackage ../development/python-modules/psychrolib { }; psycopg = callPackage ../development/python-modules/psycopg { }; <ins> psycopg-pool = psycopg.pool; psycopg-c = psycopg.c; </ins> psycopg2 = callPackage ../development/python-modules/psycopg2 { };

Discussion:
The latest version of exposes a new dependency on . We have an existing python3Packages.psycopg that builds psycopg-pool but doesn't appear to export it. Out of an abundance of caution, I want to ask: should I duplicate the existing setup to build psycopg-pool standalone (and make it a dependency of the psycopg build), or is there something else I should do? your thoughts please? P.S. This is a blocker for Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
You can just referene .
You are a rock star. Thank you so much.
And no we have attributes for and as well.
Change:
+        // Nix Directories +        "--ro-bind", "@storeDir@", "@storeDir@", +        "--ro-bind", "/run/current-system", "/run/current-system", <ins> +        "--ro-bind", "/run/opengl-driver", "/run/opengl-driver", </ins> }; // We would have to parse ld config files for more info. bindPathVar(sandboxArgs, "LD_LIBRARY_PATH");

Discussion:
Describe the bug Since GNOME 3.36 (which enabled sandboxing in epiphany) I would often see this crash in epiphany and I can still reproduce this in GNOME 3.38. Quite honestly epiphany in NixOS is broken. And it seems to be related to sandboxing and probably an issue in webkitgtk itself. To Reproduce Steps to reproduce the behavior: epiphany for a period of time a certain amount of activity on any sites it will crash Notify maintainers Maintainer information:
IIRC this was always broken , I do not see how sandboxing could make it any worse :smirk_cat:
Interesting, when I first used epiphany in NixOS it actually worked fine (I stick to intel and amd graphics). I believe it was in 3.36 that I noticed that it became unusable. Though, the issue you mentioned seems to show the same output, but it was just for NVIDIA users (with the time gap between ). I think it might be reasonable to assume that crash outputs in that bug report and this one are just red herrings. And epiphany doesn't give any useful output without extra switches? I will look at , though.
Maybe it actually is the acceleration
I tried toggling different values that are supposed to change it in epiphany (with the wrapper exports dumped into the terminal env) and it didn't seem to prove a difference.
It seemed that, at the time of gnome 3.36 it was these bugs that were the issues (the bugs in webkitgtk that got reported got commit fixes though). I guess I should try to get a trace, though with and how exactly do I get all the symbols?
IIRC, you need to add to the library in the closure of Epiphany, and then also install the same library to for the debug info to be picked up by gdb.
Able to reproduce pretty reliably just by going to (not logged in).
Yay, found a way to confirm this is a NixOS specific issue. I installed epiphany with flatpak and it works without this crash.
Still the same issue after Gnome 3.38 upgrade.
I just opened which solves this issue for me. I've only tested with the mesa driver, but it should theoretically solve the issue for all mesa drivers; it would be nice if someone with access to nvidia hardware could check whether this works with their proprietary drivers too.
Change:
mscgen = callPackage ../tools/graphics/mscgen { }; <del> msf = callPackage ../tools/security/metasploit { }; </del> <ins> metasploit = callPackage ../tools/security/metasploit { }; msf = metasploit; </ins> ms-sys = callPackage ../tools/misc/ms-sys { };

Discussion:
The metasploit package no longer builds. I've updating it myself, but I haven't been very successful. If someone could point out my mistake I would gladly correct it and submit a PR.
Is this issue still relevant? , (pinging you because you are able to close this if necessary)
Looks relevant to me, as there was no commit to metasploit that updates or fixes it. Why do you think I isn't relevant anymore?
Current version: 3.3.1 Last stable version: 4.12 We definitely need a maintainer. is there a tag for ?
Change:
touch /etc/udev/hwdb.bin # to shut up udev touch /etc/initrd-release <del> # Function for waiting a device to appear. </del> <ins> # Function for waiting for device(s) to appear. </ins> waitDevice() { local device="$1" <ins> # Split device string using ':' as a delimiter as bcachefs # uses this for multi-device filesystems, i.e. /dev/sda1:/dev/sda2:/dev/sda3 local IFS=':' </ins> # USB storage devices tend to appear with some delay.  It would be # great if we had a way to synchronously wait for them, but # alas...  So just wait for a few seconds for the device to # appear. <del> if test ! -e $device; then echo -n "waiting for device $device to appear..." try=20 while [ $try -gt 0 ]; do sleep 1 # also re-try lvm activation now that new block devices might have appeared lvm vgchange -ay # and tell udev to create nodes for the new LVs udevadm trigger --action=add if test -e $device; then break; fi echo -n "." try=$((try - 1)) done echo [ $try -ne 0 ] fi </del> <ins> for dev in $device; do if test ! -e $dev; then echo -n "waiting for device $dev to appear..." try=20 while [ $try -gt 0 ]; do sleep 1 # also re-try lvm activation now that new block devices might have appeared lvm vgchange -ay # and tell udev to create nodes for the new LVs udevadm trigger --action=add if test -e $dev; then break; fi echo -n "." try=$((try - 1)) done echo [ $try -ne 0 ] fi done </ins> } # Mount special file systems.

Discussion:
is obviously not a valid device in most cases, so it times out and then mounts anyway. Ideally, we would skip the timer for bcachefs and just mount anyway. Steps to reproduce the behavior: a multi-device bcachefs root Not having to wait for timeout to mount. Likely need to add a condition check if the mount/unlock we're waiting on is a colon-seperated line and/or bcachefs, and just skip waiting. (eg:)
Before skip, need to check if constituent devices exist.
Change:
preBuild = '' export buildFlagsArray+=("-tags" "noupgrade release") ''; <ins> meta = { knownVulnerabilities = [ "CVE-2017-1000420" ]; homepage = https://www.syncthing.net/; description = "Open Source Continuous File Synchronization"; license = stdenv.lib.licenses.mpl20; platforms = with stdenv.lib.platforms; linux ++ freebsd ++ openbsd ++ netbsd; }; </ins> }

Discussion:
Currently we provide packages for the syncthing versions 0.14, 0.12 and 0.13. The versions 0.12 and 0.13 are known to be an security issue (CVE-2017-) but not marked as such. Is there still a need for them or can we a) mark them as insecure, or b) remove them? In any way I would at least vote for having them marked as insecure. CC current syncthing maintainers:
The reason for keeping multiple versions around is due to the fairly rapid pace of development where new versions are not backwards compatible. We should definitely at least mark them as insecure. Feel like a PR?
I can provide that PR. What is a sensible timeline to remove the old versions then? Most if not all relevant distributions ship 0.14 already:
the PR has been created.
Merged. I'll post a notice on the ML. Let's target 1st Feb for removal.
Thanks!
Change:
owner = "smallstep"; repo = "cli"; rev = "refs/tags/v${version}"; <del> hash = "sha256-B0LGedExlk9XllWilZ0QAwQHNyISAI2WJ48P2STbxSY="; </del> <ins> hash = "sha256-fxBWYz95yxNa7xotmId2SHLAIymJIBOJumYzAPB3Ias="; </ins> }; ldflags = [

Discussion:
Did upstream edit their tag? Steps to reproduce the behavior: unstable -shell -p step-cli It should install <!-- 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. system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
r-ryantm is a bot, you might tag the maintainer instead
Oh :( I didn't know that. Thanks hah.
Change:
url = "https://git.taler.net/merchant.git"; rev = "v${version}"; fetchSubmodules = true; <del> sha256 = "sha256-HewCqyO/7nnIQY9Tgva0k1nTk2LuwLyGK/UUxvx9BG0="; </del> <ins> hash = "sha256-8VpoyloLpd/HckSIRU6IclWUXQyEHqlcNdoJI9U3t0Y="; </ins> }; postUnpack = '' ln -s ${taler-wallet-core}/spa.html $sourceRoot/contrib/

Discussion:
Package name: gnunet Latest released version: 0.21.0 Current version on the unstable channel: 0.20.0 Current version on the stable/release channel: 0.20.0 Notify maintainers Changelog: 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:
# Multi-arch "drivers" which we want to build for i686. driversi686Linux = recurseIntoAttrs { inherit (pkgsi686Linux) <ins> amdvlk </ins> mesa vaapiIntel libvdpau-va-gl

Discussion:
Project description introduced amdvlk to nixos already, but afaict this only works with 64bit application, but since a lot of especially games are still 32bit it really would be nice to also be able to run those with amdvlk. I currently have this: In my nixos configuration to make sure that if possible amdvlk is used but also to make sure 32bit applications can still run Metadata should be the same
What would be the right way to do this with nix? The possibilities I see are: with the nix i686 toolchain (working amdvlk here: , can be used as ) A disadvantage of 2. is that it does not support lto.
Change:
sha256 = "0vids7sxk8w5vr73xdnf8xdci71a7syl6cd35aiisppbqyyfmykx"; }; <ins> dontUseCmakeConfigure = true; </ins> nativeBuildInputs = with pkgs; [ swig qmake cmake ];

Discussion:
Describe the bug -- Build files have been written to: /build/source/build cmake: enabled parallel building building Executing setuptoolsBuildPhase Traceback (most recent call last): File "nixrunsetup", line 8, in <moduleexec(compile(getattr(tokenize, 'open', open)(file).read().replace('rn', 'n'), file, 'exec')) File "/nix/store/qyv5ffskmq8fv9yf5mb6fr5yracavid4-python3-", line 392, in open buffer = builtinopen(filename, 'rb') FileNotFoundError: [Errno 2] No such file or directory: '' error: --- Error --- nix-daemon builder for '/nix/store/chqprbhksn9fj60g8kpgbpvyi59sz7j0-python3.8-pivy-' failed with exit code 1; last 10 log lines: -- Build files have been written to: /build/source/build cmake: enabled parallel building building Executing setuptoolsBuildPhase Traceback (most recent call last): File "nixrunsetup", line 8, in <moduleexec(compile(getattr(tokenize, 'open', open)(file).read().replace('rn', 'n'), file, 'exec')) File "/nix/store/qyv5ffskmq8fv9yf5mb6fr5yracavid4-python3-", line 392, in open buffer = builtinopen(filename, 'rb') FileNotFoundError: [Errno 2] No such file or directory: '' error: --- Error
------------------------- nix-build 1 dependencies of derivation '/nix/store/dh92r05bpsj49fk2kwrwq49kiy5ry1d2-freecad-unstable-2020-12-' failed to build yaml attribute: module:
Thanks!
Change:
qrcode camelot uharfbuzz <ins> lxml </ins> ]; disabledTestPaths = [

Discussion:
Package name: python312Packages.fpdf2 Latest released version: 2.7.7 <!-- Search your package here: --- Current version on the unstable channel: 2.7.6 Current version on the stable/release channel: N/A <!-- 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:
<del> { lowPrio, newScope, stdenv, cmake, libxml2, python2, isl, fetchurl, overrideCC, wrapCC, darwin, ccWrapperFun }: </del> <ins> { lowPrio, newScope, stdenv, targetPlatform, cmake, libstdcxxHook , libxml2, python2, isl, fetchurl, overrideCC, wrapCC, ccWrapperFun , darwin }: </ins> let callPackage = newScope (self // { inherit stdenv cmake libxml2 python2 isl release_version version fetch; });

Discussion:
The clang stdenv (e.g., ) on recent unstable channel no longer seems able to find the C++ headers when used as the stdenv for a build. yields Curiously the libcxxStdenv does work: and just for sanity, it does work on 17.03 and usually works otherwise O:) System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc and since they were tracking down a similar problem in the Darwin clang stdenv recently.
This only happens on linux, it looks like the -isystem flags from gcc used to leak into the clang stdenv somehow.
This works, we could fix the clang stdenv to include those by default. Unless there's a reason to use the gcc headers, but using libcxx makes more sense I would think.
cc
Is this significantly different than using ? IMO it's an important use case, using clang w/gcc's libstdc++, it's the most "compatible" with Linux things and is the default way to use clang (for now, anyway).
This have something to do with ?
From the name I wouldn't expect to still use the gcc libstc++, but the use case makes sense. The condition for  looks good, not sure why it's not working.
noticed that the logic would only apply if that variable was undefined, not empty. But now ensures that it is defined (and empty if not otherwise defined). The best solution would be to handle the default in so there's no empty fallback at any point.
I'll do this for 17.09
appears to be a victim of this issue as well
seems to be defined before. I currently test the following patch: this is not a good fix though, but if this the root cause, I can come up with a better patch.
That would break or make it behave incorrectly.
i know
Is this supposed to work now? At least I am having the same problem on unstable(18.03); g++ works but clang fails and does not find the headers. I might have missed something though, rather new to nix.
Maybe you need instead of ? Edit: nevermind, I can also reproduce your issue
After some testing, I found that using without will cause the c++ header not found error.

(I guess this is not a bug?) To successfully compile a simple file, I need
See
Indeed it works in nix-shell, thanks.
There's probably a bigger issue here of people wanting our tools to work normally outside of Nix builds and shells, but that's a much bigger endeavor.
Yeah we'd need like a , which would easiest to accomplish if we did less dependency stuff in bash.