jiebi/CodeConvo huggingface dataset:
Change:
extraPackages = [ self.libcxx self.libcxxabi ]; }; <del> stdenv = overrideCC stdenv self.clang; </del> <ins> stdenv = stdenv.override (drv: { allowedRequisites = null; cc = self.clang; # Use the gcc libstdc++ when targeting linux. extraBuildInputs = if stdenv.cc.isGNU then [ libstdcxxHook ] else drv.extraBuildInputs; }); </ins> libcxxStdenv = overrideCC stdenv self.libcxxClang;

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:
# Remove any site.py files generated by easy_install as these # cause collisions. If pth files are to be processed a # corresponding site.py needs to be included in the PYTHONPATH. <del> # # leave them until we have a better solution: see #209 #rm -f "$out/lib/${python.libPrefix}"/site-packages/site.py* </del> <ins> rm -f "$out/lib/${python.libPrefix}"/site-packages/site.py* </ins> ${postInstall} '';

Discussion:
We need to propagate the pth loader so packages using us process our pth files, but it makes no sense to have the pth loader itself in a pth file.
Change:
### Helper functions. inherit lib config overlays; <del> inherit (lib) lowPrio hiPrio appendToName makeOverridable; </del> <ins> # do not import 'appendToName' to get consistent package-names with the same set of package-parameters: https://github.com/NixOS/nixpkgs/issues/68519 inherit (lib) lowPrio hiPrio makeOverridable; </ins> inherit (lib) recurseIntoAttrs;

Discussion:
As noticed in , some packages use in to distinguish variants by . We should move that modification to the package expression itself so that the package name is always the same when doing . cc
If you want to ensure it is kept it needs to be part of the derivation, which means it triggers a rebuild (which I think is typically fine for the use case).
The vast majority that I quickly checked should simply use or, in line with my previous comment, we should use in .
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Still.
I marked this as stale due to inactivity. &rarr;
This can still be seen in some places:
I marked this as stale due to inactivity. &rarr;
Change:
{ lib <del> , gcc12Stdenv </del> <ins> , stdenv </ins> , fetchFromGitHub , fetchpatch <ins> , copyDesktopItems </ins> , pkg-config <ins> , wrapGAppsHook , unzip </ins> , curl , glib , gtk3

Discussion:
For FreeFileSync, add a desktop file to $out/share/applications so that the application can be found in an app launcher. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Change:
<ins> { lib , buildPythonPackage , fetchPypi }: buildPythonPackage rec { pname = "types-colorama"; version = "0.4.15"; format = "setuptools"; src = fetchPypi { inherit pname version; hash = "sha256-/RKLHjLz/s7F8J30Nm0hSY7obqMfz4tOjxrebQu/mDI="; }; # Module has no tests doCheck = false; meta = with lib; { description = "Typing stubs for colorama"; homepage = "https://github.com/python/typeshed"; license = licenses.asl20; maintainers = with maintainers; [ fab ]; }; } </ins>

Discussion:
Project description From the website : "This program takes upon itself the hard task of beautifying Bash scripts" Metadata homepage URL: source URL: license: MIT platforms: any
Change:
environment.etc = mapAttrs' (name: options: nameValuePair "keyd/${name}.conf" { <del> source = pkgs.runCommand "${name}.conf" { ids = '' [ids] ${concatStringsSep "n" options.ids} ''; passAsFile = [ "ids" ]; } '' cat $idsPath <(echo) ${settingsFormat.generate "keyd-${name}.conf" options.settings} >$out </del> <ins> text = '' [ids] ${concatStringsSep "n" options.ids} ${generators.toINI {} options.settings} ${options.extraConfig} </ins> ''; }) cfg.keyboards;

Discussion:
Composite layers in keyd MUST always be defined after regular layers (see ) Currently it seems to be impossible to keep the settings order
Hello. I didn't know about these possibilities (composite layers and ), thanks for showing them. Unforntunately in nix, there is no easy way to preserve the order of attributes. See: The simplest solution I can see is to add option. E.g: Will this solution satisfy you?
Yep, that would work. Though, I think that it's possible to preserve the order by using arrays instead of dictionaries. E.g.
At this point, I think I'll add . Why? will want to save their config (except section) in raw string format (when moving from another OS). your suggestion looks fine to me, it's breaking changes anyway. Maybe in the future, if there are more advantages in your syntax, we will rewrite the module.
Change:
'' + lib.optionalString buildTests '' mkdir -p $test/bin mv bin/test_* $test/bin <del> patchelf $test/bin/test_* --shrink-rpath --allowed-rpath-prefixes /nix/store </del> <ins> patchelf $test/bin/test_* --shrink-rpath --allowed-rpath-prefixes "$NIX_STORE" </ins> ''; passthru.updateScript = rocmUpdateScript {

Discussion:
Steps to reproduce the behavior: on nixos-unstable I believe this is related to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
It'll need a similar fix like the ones in Wasn't caught in staging because it's marked insecure
Change:
jeepney = callPackage ../development/python-modules/jeepney { }; <ins> jello = callPackage ../development/python-modules/jello { }; </ins> jellyfin-apiclient-python = callPackage ../development/python-modules/jellyfin-apiclient-python { }; jellyfish = callPackage ../development/python-modules/jellyfish { };

Discussion:
jello: Filter JSON and JSON Lines data with Python syntax jello is similar to jq in that it processes JSON and JSON Lines data except jello uses standard python dict and list syntax. JSON or JSON Lines can be piped into jello via STDIN or can be loaded from a JSON file or JSON Lines files (JSON Lines are automatically slurped into a list of dictionaries). Once loaded, the data is available as a python list or dictionary object named ‘_’. Processed data can be output as JSON, JSON Lines, bash array lines, or a grep-able schema. Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, windows (anything with Python)
Change:
, withManual ? true , pythonSupport ? true , sendEmailSupport <ins> , darwin </ins> }: let

Discussion:
Git includes a number of credential storage systems. On OS X there's a Keychain-based store that uses the encrypted login keychain to keep track of sensitive credentials. https://git- The implementation is written in C, and can be found in . If we could change the git expression to , and install the credential helper on OS X that would be amazing! Install git on OS X. Set your credential helper to use the built-in osxkeychain method included with git. Try pushing or pulling from an HTTPS GitHub repo where authentication is required. System: Darwin 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASEX8664 x86_64 i386 MacBookPro11,5 Darwin Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.09pre-git"
Change:
widelands = callPackage ../games/widelands { }; <ins> wolfstoneextract = callPackage ../games/wolfstoneextract { }; </ins> worldofgoo = callPackage ../games/worldofgoo { }; xboard =  callPackage ../games/xboard { };

Discussion:
Project description Buried inside the game files for and is game data for two new -engine games, . WolfstoneExtract allows you to convert the embedded Wolfstone 3D and Elite Hans: Die Neue Ordnung game data into a format that’s usable by . Metadata homepage URL: URL: GPLv3 and various permissive free licenses platforms: Linux
Change:
<del> {lib, stdenv, fetchurl, libpng, perl, gettext }: </del> <ins> {lib, stdenv, fetchpatch, fetchurl, libpng, perl, gettext }: </ins> stdenv.mkDerivation rec { pname = "xcftools";

Discussion:
, CVSSv3=8.8 (nixos-20.03, nixos-unstable) CVSSv3=8.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
Change:
"https://download.nomachine.com/download/${versionMajor}/Linux/nomachine_${version}_${versionBuild_x86_64}_x86_64.tar.gz" "https://web.archive.org/web/https://download.nomachine.com/download/${versionMajor}/Linux/nomachine_${version}_${versionBuild_x86_64}_x86_64.tar.gz" ]; <del> sha256 = "1b6r9bwkr8mhaljma19ikxpkmlx8iy5r1vf5hlv27bja2zz1r8xr"; </del> <ins> sha256 = "1dqsqwxbd77g6gc0hvjmmg4flm3vwwv5y98m8d9wxyybp37vkmgd"; </ins> } else if stdenv.hostPlatform.system == "i686-linux" then fetchurl {

Discussion:
Describe the bug the package nomachine-client cannot build trying % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 138 100 138 0 0 8 0 0:00:17 0:00:15 0:00:02 30 100 142k 0 142k 0 0 7033 0 --:--:-- 0:00:20 --:--:-- hash mismatch in fixed-output derivation '/nix/store/qgm0ps149dm4n0z76rhyl647mvg52qar-': wanted: sha256:1b6r9bwkr8mhaljma19ikxpkmlx8iy5r1vf5hlv27bja2zz1r8xr got: sha256:1jpyp2z2qy1dh8w40qbid7yjffq6gp940krxsfd3d7n4pr9a268w cannot build derivation '/nix/store/q4wkpnggxd0y0g4drjib6g1swxawfp1w-nomachine-client-': 1 dependencies couldn't be built cannot build derivation '/nix/store/zzsga5l3qh8anqymvcbxl8az92ka6jy9-system-': 1 dependencies couldn't be built cannot build derivation '/nix/store/plvdk8jn20k891hrkxcb9kvr8685wnvi-nixos-system-Bach-': 1 dependencies couldn't be built error: build of '/nix/store/plvdk8jn20k891hrkxcb9kvr8685wnvi-nixos-system-Bach-' failed running on 20.03 To Reproduce Steps to reproduce the behavior: environment.systemPackages = with pkgs; [ nomachine-client ]; Notify maintainers Metadata these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.

4-p23-dev copying path '/nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev' from ''. system: host os: multi-user?: sandbox: version: nixpkgs:
May be fixed by
This needs to be backported as well
Backported in and .
Change:
{ lib , ocamlPackages <ins> , stdenv , overrideSDK </ins> , fetchFromGitHub , python3 , dune_3 <ins> , makeWrapper , pandoc , poppler_utils , testers , docfd </ins> }: <del> ocamlPackages.buildDunePackage rec { </del> <ins> let # Needed for x86_64-darwin buildDunePackage' = ocamlPackages.buildDunePackage.override { stdenv = if stdenv.isDarwin then overrideSDK stdenv "11.0" else stdenv; }; in buildDunePackage' rec { </ins> pname = "docfd"; <del> version = "3.0.0"; </del> <ins> version = "4.0.0"; </ins> minimalOCamlVersion = "5.1";

Discussion:
Steps to reproduce the behavior: on x8664-darwin Package is a dependency of . Builds fine on linux and aarch64-darwin, just fails on x86_64-darwin. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
if you submit a patch, I will review it, but I don’t own any Darwin hardware to test…
Pinging to see if anyone can help on this issue as it's outside my area of expertise. Otherwise will mark which depends on this as broken for darwin x86_64. Many thanks!
Can test later, but it looks like there is a workaround for this exact error at
Thanks. I tried that flag earlier, which turns the error into a warning and allows to build (with warnings). But then when I try and build which depends on this I get linker errors,
and were in 11.0. It should use to override the stdenv to use the 11.0 SDK with an 11.0 deployment target. Edit: It uses , so probably something like (untested):
Many thanks, that worked! Much appreciated.

nix shell nixpkgs#docfd Wanted to try out but it failed to build. I noticed the package is not on the . Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi thanks for the report. I currently have a PR for version 4.0.0, but this same build error occurs there too, so it's unrelated to version. Strangely docfd builds fine on aarch64-darwin. The problem is with x8664-darwin, and specifically with the ocaml dependency which fails to build as your error message shows. I'm going to open an issue for that an ping the maintainer.
Change:
serviceConfig = { ExecStartPre = "${cfg.package}/bin/xmrig --config=${configFile} --dry-run"; ExecStart = "${cfg.package}/bin/xmrig --config=${configFile}"; <del> DynamicUser = true; </del> <ins> # https://xmrig.com/docs/miner/randomx-optimization-guide/msr # If you use recent XMRig with root privileges (Linux) or admin # privileges (Windows) the miner configure all MSR registers # automatically. DynamicUser = lib.mkDefault false; </ins> }; }; };

Discussion:
When setting up the xmrig service, It displays the message . Steps to reproduce the behavior: the output. Not show this message. I've tried the following: the attribute of the service; both and Please run and paste the result.
Do you have any idea on this problem?
After a quick look I found the following relevant spots: I think you should create an issue upstream and link here so we could work together to figure this out. I don't even know what MSR is :man_shrugging:
I've got it working I'll open a PR with the fix in a minute!
Change:
<del> { lib, stdenv, fetchFromGitHub , cmake, pkg-config , libva, libpciaccess, intel-gmmlib , enableX11 ? stdenv.isLinux, libX11 </del> <ins> { lib , stdenv , fetchFromGitHub , fetchpatch , cmake , pkg-config , libva , libpciaccess , intel-gmmlib , enableX11 ? stdenv.isLinux , libX11 </ins> }: stdenv.mkDerivation rec {

Discussion:
The build of fails on i686. Fails with: Found with Please run and paste the result. Maintainer information:
if you don't ping any maintainer likely nothing will happen ping
I think I never tried compiling intel-media-driver on i686 but only fixed an eval error in nixGL. The problem seems to be that it compiles 64 bit code on 32 bit.
I did a quick look what other distros do and found this helpful Debian patch () at least fixes. There are still some other compile errors that need fixing. Edit1: and with it compiles
Change:
] ++ optionals stdenv.isDarwin [ libiconv gmp <ins> Carbon AppKit </ins> ]; preConfigure =

Discussion:
Found in It does build on and . Refs ZHF <!-- 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. Maintainer information:
Is there a general fix for the error? I'm seeing this with (this issue was the only one in nixpkgs that matched that string, sorry if I'm completely off base, I just have no idea where to go on this)
Change:
pname = "grub"; inherit version; <del> src = fetchgit { url = "git://git.savannah.gnu.org/grub.git"; rev = "${pname}-${version}"; sha256 = "1vkxr6b4p7h259vayjw8bfgqj57x68byy939y4bmyaz6g7fgrv0f"; </del> <ins> src = fetchurl { url = "mirror://gnu/grub/grub-${version}.tar.xz"; sha256 = "sha256-t56kSvkbk9F80/6Ava5u1DdwZ4qaWuGSzOqAPrtlfuE="; </ins> }; patches = [

Discussion:
After upgrading to 21.05, when running , I get the following warning: Everything else seems to work fine, but it's unclear what has gone wrong here, or if I should be worried. Metadata Maintainer information:
discussed here a bit you can safely ignore it to hide it we could add to the or to
Not sure if my case is related, but I had the same error after : The overall install didn't error. Attempting to reboot, it would be unable to boot:
My boot got fixed after converting my MBR to GPT and creating an ESP partition and setting it to use systemd-boot instead of GRUB. If GRUB continues to work with people that see this warning, it's unlikely that my boot problems are related. (But, still, a different bug; if MBR got deprecated, there should have been an announcement.)
But the issue is quite severe (I just lost hours on it because it happened on a remote server which boots very slowly on a web-mounted rescue iso), and I could only get my system running again by reverting to . I'd propose to throw out the new version () for now. I can't do GPT, because the system only has a legacy BIOS (no UEFI), it appears that this is the reason this issue has flown under the radar? Same error referenced , it appears to be an issue with the grub package itself. EDIT: since OP defined a "parallel" but much less severe bug, I made a new report here:
Change:
[global] security = ${cfg.securityType} passwd program = /run/wrappers/bin/passwd %u <del> pam password change = ${smbToString cfg.syncPasswordsByPam} </del> invalid users = ${smbToString cfg.invalidUsers} ${cfg.extraConfig}

Discussion:
I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:
Change:
${cfg.loginShellInit} <del> # and leave a note to our children to spare them the same work set -gx __fish_nixos_login_config_sourced 1 </del> <ins> # and leave a note so we don't source this config section again from # this very shell (children will source the general config anew) set -g __fish_nixos_login_config_sourced 1 </ins> end <del> # if our parent shell didn't source the interactive config, do it </del> <ins> # if we haven't sourced the interactive config, do it </ins> status --is-interactive; and not set -q __fish_nixos_interactive_config_sourced and begin ${fishAliases}

Discussion:
Fish usually has available, but the aliases are now missing, when the shell is not a login shell (presumably because of ). Have Then launch as a not-login shell. Try to use . System: 17.09pre107265. (Hummingbird)
Agh, what a mess. Thanks for raising this issue.
I think this issue is a little subtler than one would think: aliases are sourced, but only when the parent shell has not already sourced the interactive configuration. This is out of line with the behavior of the other shells on NixOS. I have a fix which I've tested with your example here. I will post a link to the relevant PR momentarily (after I put it up).
So apparently outgoing SSH is blocked from the WiFi on this cruise ship, so I can't push commits with the remotes I have set up, and my sister is nagging me to get off the computer so we can go out. If you need a quick fix on your own machine (I will be back later today, while I still have internet access, to submit the new PR), just change the lines in the NixOS module for fish () to and your aliases will get sourced every time the shell starts, so changes will be reflected without a reboot or manually unsetting the relevant variable before starting a new shell (). (The latter will do the trick if you want a quick fix without any changes to your Nixpkgs tree.)
there's a fix in this commit:
Thanks!

It looks like PR messed something up with fish environment as now connecting to a server with mosh fails giving fish: Unknown command 'mosh-server new -c 256 -s -l LANG=enUS.UTF-8 -l LCALL=enUS.UTF-8' fish: mosh-server 'new' '-c' '256' '-s' '-l' 'LANG=enUS.UTF-8' '-l' 'LCALL=enUS.UTF-8' I reverted the commit (it was mistakenly merged into 17.03) and mosh started working again. the system
I will likely not get a chance to really look into this until next week, but I will definitely figure out what went wrong here. Sorry about this! :-(
Don't worry too much, it's not something critical (hopefully it's the only thing affected). I'll try to sort this out though I have little experience here.
there's a fix in this commit: