jiebi/CodeConvo huggingface dataset:
Change:
A clear and concise description of what the bug is. Steps to reproduce the behavior: Note: I'm on the channel. NixOS config, add to . into qtile. . I expected qtile to check the configuration file. If applicable, add screenshots to help explain your problem. Maintainer information:
Do you mind trying ? Should expose mypy commands to qtile

Discussion:
<del> { lib, fetchFromGitHub, python3, glib, cairo, pango, pkg-config, libxcb, xcbutilcursor }: </del> <ins> { lib, fetchFromGitHub, python3, mypy, glib, cairo, pango, pkg-config, libxcb, xcbutilcursor }: </ins> let enabled-xcffib = cairocffi-xcffib: cairocffi-xcffib.override {

xkbcommon ]; <ins> # for `qtile check`, needs `stubtest` and `mypy` commands makeWrapperArgs = [ "--suffix PATH : ${lib.makeBinPath [ mypy ]}" ]; </ins> doCheck = false; # Requires X server #TODO this can be worked out with the existing NixOS testing infrastructure. meta = with lib; {
Change:
systemd seems to use the term split-usr to refer to an attribute of a system, where: is a mount point. is not mounted "at boot". Since systemd v248, support for a split-usr system is deprecated: While don't seem to mention a formal removal of support of split-usr, it seems that . According to : It seems that if is a mount point, this unit calls with on it, regardless of whether it is already mounted — making the assumption that it had already been mounted "at boot". When I installed my first NixOS on my workstation, I made a filesystem for each path under . This let me customize options per directory as I wished, both at install and later on. ZFS's sharing of storage space between filesystems in the same zpool takes the cost out of being "generous" with the number of filesystems. I didn't know that is merely that happens to be generated at boot. I also didn't know that systemd deprecated split-usr. So I did not mark as . The system built successfully and booted successfully. Except for an error in the logs: The failure seems to be due to the attempt to remount using with the option a non-mounted filesystem — . is later successfully mounted along with the rest of the filesystems. Since systemd seems to expect that if is a mount point it would have already been mounted "at boot", I would expect NixOS to: 's to by default, . to build when 's is (that could be ). Understanding this error took around three hours of collaborative debugging with the tremendous help of A workaround is to set for , or to not have a mount point at all. The suggested solution (expected behavior) is with the goal of sparing all future users an investigation of this error. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Not sure who to mention. Please ignore if you no longer wish to be involved. If you happen to know who should be mentioned here and is not, please comment mentioning them. Please run and paste the result. Maintainer information:
gentoo notes this in their wiki as well
ping a couple people who might care: and probably others.

Discussion:
# Check whenever fileSystem is needed for boot.  NOTE: Make sure # pathsNeededForBoot is closed under the parent relationship, i.e. if /a/b/c # is in the list, put /a and /a/b in as well. <del> pathsNeededForBoot = [ "/" "/nix" "/nix/store" "/var" "/var/log" "/var/lib" "/var/lib/nixos" "/etc" ]; </del> <ins> pathsNeededForBoot = [ "/" "/nix" "/nix/store" "/var" "/var/log" "/var/lib" "/var/lib/nixos" "/etc" "/usr" ]; </ins> fsNeededForBoot = fs: fs.neededForBoot || elem fs.mountPoint pathsNeededForBoot; # Check whenever `b` depends on `a` as a fileSystem
Change:
When building an interactive test driver with and running the generated binary, the test just runs without an interactivity. Steps to reproduce the behavior: that the test just starts instead of displaying the interactive prompt. I'd expect to be dropped into the interactive prompt. cc as someone who's touched a lot.
Mostly reviews and minor additions though. Maybe broke it, but that's just a guess. Probably best to bisect with if going back to before that doesn't fix the problem.
Ah, it was broken by

Discussion:
```ShellSession $ nix-build . -A nixosTests.login.driverInteractive <del> $ ./result/bin/nixos-test-driver --interactive </del> <ins> $ ./result/bin/nixos-test-driver </ins> [...] >>> ```

`--keep-vm-state` flag. ```ShellSession <del> $ ./result/bin/nixos-test-driver --interactive --keep-vm-state </del> <ins> $ ./result/bin/nixos-test-driver --keep-vm-state </ins> ``` The machine state is stored in the `$TMPDIR/vm-state-machinename`

</para> <programlisting> $ nix-build . -A nixosTests.login.driverInteractive <del> $ ./result/bin/nixos-test-driver --interactive </del> <ins> $ ./result/bin/nixos-test-driver </ins> [...] &gt;&gt;&gt; </programlisting>

the <literal>--keep-vm-state</literal> flag. </para> <programlisting> <del> $ ./result/bin/nixos-test-driver --interactive --keep-vm-state </del> <ins> $ ./result/bin/nixos-test-driver --keep-vm-state </ins> </programlisting> <para> The machine state is stored in the

"-I", "--interactive", help="drop into a python repl and run the tests interactively", <del> action="store_true", </del> <ins> action=argparse.BooleanOptionalAction, </ins> ) arg_parser.add_argument( "--start-scripts",

, enableOCR ? false , skipLint ? false , passthru ? {} <ins> , interactive ? false </ins> }: let # Reifies and correctly wraps the python test driver for

wrapProgram $out/bin/nixos-test-driver  --set startScripts "''${vmStartScripts[*]}"  --set testScript "$out/test-script"  <del> --set vlans '${toString vlans}' </del> <ins> --set vlans '${toString vlans}'  ${lib.optionalString (interactive) "--add-flags --interactive"} </ins> ''); # Make a full-blown test

testName = name; qemu_pkg = pkgs.qemu; nodes = nodes pkgs.qemu; <ins> interactive = true; </ins> }; test =
Change:
It got a huge closure size. Jump happened here: 91.1.0: 0.5 G 91.1.1: 3+ G On a quick glance, it's mainly due to dragging lots of toolchain packages, rustc in particular: /cc other likely interested people:
and don't suffer from this, by the way.
This may be relating to ().

Discussion:
<ins> Remove about:buildconfig.  If used as-is, it would add unnecessary runtime dependencies. --- a/comm/mail/base/jar.mn +++ b/comm/mail/base/jar.mn @@ -119,9 +119,6 @@ messenger.jar: % override chrome://mozapps/content/profile/profileDowngrade.js chrome://messenger/content/profileDowngrade.js % override chrome://mozapps/content/profile/profileDowngrade.xhtml chrome://messenger/content/profileDowngrade.xhtml -*   content/messenger/buildconfig.html              (content/buildconfig.html) -% override chrome://global/content/buildconfig.html chrome://messenger/content/buildconfig.html - # L10n resources and overrides. % override chrome://mozapps/locale/profile/profileDowngrade.dtd chrome://messenger/locale/profileDowngrade.dtd % override chrome://global/locale/netError.dtd chrome://messenger/locale/netError.dtd </ins>

sha512 = "4938f676ddeeba37da1f2086d76a2ef2c870738169f7e10b35b83e4ed772df634825ee25c28232df1ac1e3a18a9466e97dc7ee318abbf43f1f4ce6479a13975b"; }; patches = [ <ins> # The file to be patched is different from firefox's `no-buildconfig-ffx90.patch`. ./no-buildconfig.patch </ins> ]; meta = with lib; {
Change:
System: recent NixOS, sandboxed Nixpkgs version: current master, e.g. ; it used to build on Example output:
Unfortunately, updating didn't help. (/cc with that)
Sadly, I can reproduce that. Maybe we want to downgrade the compiler here?
Additionally, build doesn't work too.
Oh, truly, I didn't realize that last working version I referenced was using gcc-4.9. I switched nixpkgs versions on our hydra instance at that point.
Found the bug: And corresponding compiler bug:

Discussion:
{ system, stdenv, stdenv_32bit, lib, pkgs, pkgsi686Linux, callPackage, callPackage_i686, <ins> overrideCC, wrapCCMulti, gcc49, </ins> pulseaudioSupport, wineRelease ? "stable" }:

wine64 = callPackage ./base.nix { name = "wine64-${version}"; inherit src version pulseaudioSupport; <ins> # FIXME: drop this when GCC is updated to >5.3. # Corresponding bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 stdenv = overrideCC stdenv gcc49; </ins> pkgArches = [ pkgs ]; geckos = [ gecko64 ]; monos =  [ mono ];

wineWow = callPackage ./base.nix { name = "wine-wow-${version}"; inherit src version pulseaudioSupport; <del> stdenv = stdenv_32bit; </del> <ins> # FIXME: see above. stdenv = overrideCC stdenv_32bit (wrapCCMulti gcc49); </ins> pkgArches = [ pkgs pkgsi686Linux ]; geckos = [ gecko32 gecko64 ]; monos =  [ mono ];

gcc = gcc5; <del> gcc_multi = </del> <ins> wrapCCMulti = cc: </ins> if system == "x86_64-linux" then lowPrio ( let extraBuildCommands = '' echo "dontMoveLib64=1" >> $out/nix-support/setup-hook ''; <del> in wrapCCWith (callPackage ../build-support/cc-wrapper) glibc_multi extraBuildCommands (gcc.cc.override { stdenv = overrideCC stdenv (wrapCCWith (callPackage ../build-support/cc-wrapper) glibc_multi "" gcc.cc); </del> <ins> in wrapCCWith (callPackage ../build-support/cc-wrapper) glibc_multi extraBuildCommands (cc.cc.override { stdenv = overrideCC stdenv (wrapCCWith (callPackage ../build-support/cc-wrapper) glibc_multi "" cc.cc); </ins> profiledCompiler = false; enableMultilib = true; })) <del> else throw "Multilib gcc not supported on ‘${system}’"; </del> <ins> else throw "Multilib ${cc.name} not supported on ‘${system}’"; gcc_multi = wrapCCMulti gcc; </ins> gcc_debug = lowPrio (wrapCC (gcc.cc.override { stripped = false;
Change:
When trying to start an environment containing , l get this error: Use this : Run . Notice that you get an error about a collision. Please run and paste the result.
This was fixed in master by and should hit unstable shortly. Can you confirm?

Discussion:
buildPythonPackage rec { pname = "nbclient"; <del> version = "0.5.8"; </del> <ins> version = "0.5.9"; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "sha256-NPUsycuDGl2MzXAxU341THXcYaJEh/mYcS0Sid4yCiU="; </del> <ins> sha256 = "sha256-meRt2vrNC4YSk78kb+2FQKGErfo6p9ZB+JAx7AcHAeA="; </ins> }; inherit doCheck; checkInputs = [ pytest xmltodict nbconvert ipywidgets ]; propagatedBuildInputs = [ async_generator traitlets nbformat nest-asyncio jupyter-client ]; <del> postFixup =  '' # Remove until fixed by upstream # https://github.com/jupyter/nbclient/pull/173#issuecomment-968760082 rm $out/bin/.jupyter-run-wrapped rm $out/bin/jupyter-run ''; </del> meta = with lib; { homepage = "https://github.com/jupyter/nbclient"; description = "A client library for executing notebooks";
Change:
The new scheme introduced in confuses the script. latest plan9port from unstable as of writing to use from within an environment spawned by gets moved from the front of to the back Here is a session using unmodified p9p: ylh ~ PATH ylh ~ $ 9 zsh ylh ~ PATH /nix/store/d4iwcgqwgk8whxjxgmhh20ykni7flkb2-plan9port-0.pre+date=2021-10- ylh ~ $ u zsh ylh ~ PATH /nix/store/d4iwcgqwgk8whxjxgmhh20ykni7flkb2-plan9port-0.pre+date=2021-10- After applying the following overlay: self: { lib, plan9port, ... }: let lastby = sep: x: (lib.splitString sep x); in { plan9port = plan9port.overrideAttrs (old pname, ... }: { version = lastby "=" (lastby "+" old.version); name = "{version}"; }); } the desired result is achieved: ylh ~ PATH ylh ~ $ 9 zsh ylh ~ PATH /nix/store/zh1iaayjg7baqvgh1g645k4wzxjrmfzx-plan9port-2021-10- ylh ~ $ u zsh ylh ~ PATH Amusingly, is left unaffected; the tool calls out to , which, in a environment (why else would you be calling ), is p9p sed, which interprets as a metacharacter without the need for . In any case, RFC 0107 clearly needs work, and this should hopefully demonstrate why enacting it (self-merging, no less) pre-approval is somewhat irresponsible. system: host os: multi-user?: sandbox: version: channels(root): channels(ylh): nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs Maintainer information:
This obsession with arbitrary versioning formatting standards is getting annoying.

Discussion:
stdenv.mkDerivation { pname = "plan9port"; <del> version = "0.pre+date=2021-10-19"; </del> <ins> version = "2021-10-19"; </ins> src =  fetchFromGitHub { owner = "9fans";

kovirobi ]; platforms = platforms.unix; <ins> broken = stdenv.isDarwin; </ins> }; } # TODO: investigate the mouse chording support patch
Change:
The iterm2 package () does not build on aarch64-darwin. I'm getting the following error message: Steps to reproduce the behavior: installing/building . the build failure. The package to build. n/a Complete logs are available 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. Maintainer information:
Hi Unfortunately, it was/is not possible to build item in a pure and reproducible way from source because it depends on your installed Xcode toolchain. It is therefore not an ideal candidate for nixpkgs and I didn't update the version of it either. Do you see any benefit in having iterm2 in nixpkgs compared to just downloading it from their website?
Hi thanks for packaging this! I generally have a slight preference to installing things via nix so that I can put them in my home-manager config, but at the end of the day it doesn't make a huge difference to me. It sounds like iterm2 is kind of a pain to package in general... Do you think it should be marked as broken or removed from nixpkgs?

Discussion:
<del> { lib, stdenv, fetchFromGitHub }: </del> <ins> { lib, stdenvNoCC, fetchFromGitHub }: </ins> /* This derivation is impure: it relies on an Xcode toolchain being installed

option set to `relaxed` or `false`. */ <del> stdenv.mkDerivation rec { </del> <ins> stdenvNoCC.mkDerivation rec { </ins> pname = "iterm2"; <del> version = "3.4.0"; </del> <ins> version = "3.4.13"; </ins> src = fetchFromGitHub { owner = "gnachman"; repo = "iTerm2"; rev = "v${version}"; <del> sha256 = "09nhrmi25zxw3vp0wlib9kjr3p1j6am2zpwimdzqn0c80fq1lwvi"; </del> <ins> sha256 = "sha256-GOUdXBQCvM0oJ2/3zgKqDpfyCkHNwd1Qdopg5Mpyekg="; </ins> }; patches = [ ./disable_updates.patch ];
Change:
After update can't properly reload zram module. Reproducible only with . journalctl -eu zram-reloader.service Steps to reproduce the behavior: zram and switch to ; ; switch to ; the logs. Successful module reload. None. None. Maintainer information:
i assume a reboot fixed this? its probably because the booted kernel and the updated kernel versions mismatched i suspect that this line may be causing it it was in this pr but it states that extra info at
Yes, after reboot everything works fine.
is different from what it was in nix-info ?
No. The system has already been rebooted after the update.
I can't find in paths: It is there where the kernel is:
find doesn't work with symlinks fd with -L does
i got this same issue and before rebooting i tested changing the path order in kmod expr and it worked
Progress of the pr can be tracked at

Discussion:
}: let <del> systems = [ "/run/current-system/kernel-modules" "/run/booted-system/kernel-modules" "" ]; </del> <ins> systems = [ "/run/booted-system/kernel-modules" "/run/current-system/kernel-modules" "" ]; </ins> modulesDirs = lib.concatMapStringsSep ":" (x: "${x}/lib/modules") systems; in stdenv.mkDerivation rec {

changelog = "https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/plain/NEWS?h=v${version}"; license = with licenses; [ lgpl21Plus gpl2Plus ]; # GPLv2+ for tools platforms = platforms.unix; <ins> maintainers = with maintainers; [ artturin ]; </ins> }; }
Change:
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!

Discussion:
}; config = mkIf cfg.enable { <ins> boot.kernelModules = [ "msr" ]; </ins> systemd.services.xmrig = { wantedBy = [ "multi-user.target" ]; after = [ "network.target" ];

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> }; }; };
Change:
The latest heisenbridge version doesn't build on nixpkgs-unstable (). Steps to reproduce the behavior: error: This repro's on darwin and on linux, using this nixpkgs revision. I believe this may be due to , where mautrix was bumped to version 0.11.3, but heisenbridge requires 0.10.x. build success. Please run and paste the result. Maintainer information:
The requirement is adjusted in heisenbridge 1.7.0:

Discussion:
python3Packages.buildPythonApplication rec { pname = "heisenbridge"; <del> version = "1.6.0"; </del> <ins> version = "1.7.0"; </ins> src = fetchFromGitHub { owner = "hifi"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-Q7xqKjAUBHh87VAgsgDOCPDINDh0yUdr3UoUlLqJr5k="; </del> <ins> sha256 = "sha256-rN+qoBS9zIy5EHlFQxgAlcz9haoYJNMKJ2wlS46UOi0="; </ins> }; postPatch = '' echo "${version}" > heisenbridge/version.txt <del> substituteInPlace setup.cfg  --replace "mautrix >=0.10.5, <0.11" "mautrix >=0.10.5, <0.12" </del> ''; propagatedBuildInputs = with python3Packages; [
Change:
System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:

Discussion:
{ fetchurl, stdenv, pkgconfig, gnome3, json_glib, libcroco, intltool, libsecret <del> , python3, libsoup, polkit, clutter, networkmanager, docbook_xsl, docbook_xsl_ns, at_spi2_core , libstartup_notification, telepathy_glib, telepathy_logger, libXtst, p11_kit, unzip , sqlite, libgweather, libcanberra_gtk3 , libpulseaudio, libical, libtool, nss, gobjectIntrospection, gstreamer, makeWrapper , accountsservice, gdk_pixbuf, gdm, upower, ibus, networkmanagerapplet, librsvg }: </del> <ins> , python3, python3Packages, libsoup, polkit, clutter, networkmanager , docbook_xsl , docbook_xsl_ns, at_spi2_core, libstartup_notification , telepathy_glib, telepathy_logger, libXtst, p11_kit, unzip, sqlite, libgweather , libcanberra_gtk3 , libpulseaudio, libical, libtool, nss, gobjectIntrospection , gstreamer, makeWrapper , accountsservice, gdk_pixbuf, gdm, upower, ibus , networkmanagerapplet, librsvg }: </ins> # http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/gnome-base/gnome-shell/gnome-shell-3.10.2.1.ebuild?revision=1.3&view=markup

buildInputs = with gnome3; [ gsettings_desktop_schemas gnome_keyring gnome-menus glib gcr json_glib accountsservice <del> libcroco intltool libsecret pkgconfig python3 libsoup polkit libcanberra gdk_pixbuf librsvg </del> <ins> libcroco intltool libsecret pkgconfig python3 python3Packages.pygobject3 libsoup polkit libcanberra gdk_pixbuf librsvg </ins> clutter networkmanager libstartup_notification telepathy_glib docbook_xsl docbook_xsl_ns libXtst p11_kit networkmanagerapplet gjs mutter libpulseaudio caribou evolution_data_server libical libtool nss gobjectIntrospection gtk gstreamer makeWrapper gdm

--prefix XDG_DATA_DIRS : "${gnome_themes_standard}/share:$out/share:$XDG_ICON_DIRS"  --suffix XDG_DATA_DIRS : "$GSETTINGS_SCHEMAS_PATH" <ins> wrapProgram "$out/bin/gnome-shell-extension-tool"  --prefix PYTHONPATH : "${python3Packages.pygobject3}/lib/python3.4/site-packages:$PYTHONPATH" </ins> wrapProgram "$out/libexec/gnome-shell-calendar-server"  --prefix XDG_DATA_DIRS : "${evolution_data_server}/share:$out/share:$XDG_ICON_DIRS:$GSETTINGS_SCHEMAS_PATH"
Change:
System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:

Discussion:
{ fetchurl, stdenv, pkgconfig, gnome3, json_glib, libcroco, intltool, libsecret <del> , python3, libsoup, polkit, clutter, networkmanager, docbook_xsl, docbook_xsl_ns, at_spi2_core , libstartup_notification, telepathy_glib, telepathy_logger, libXtst, p11_kit, unzip , sqlite, libgweather, libcanberra_gtk3 , libpulseaudio, libical, libtool, nss, gobjectIntrospection, gstreamer, makeWrapper , accountsservice, gdk_pixbuf, gdm, upower, ibus, networkmanagerapplet, librsvg }: </del> <ins> , python3, python3Packages, libsoup, polkit, clutter, networkmanager , docbook_xsl , docbook_xsl_ns, at_spi2_core, libstartup_notification , telepathy_glib, telepathy_logger, libXtst, p11_kit, unzip, sqlite, libgweather , libcanberra_gtk3 , libpulseaudio, libical, libtool, nss, gobjectIntrospection , gstreamer, makeWrapper , accountsservice, gdk_pixbuf, gdm, upower, ibus , networkmanagerapplet, librsvg }: </ins> # http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/gnome-base/gnome-shell/gnome-shell-3.10.2.1.ebuild?revision=1.3&view=markup

buildInputs = with gnome3; [ gsettings_desktop_schemas gnome_keyring gnome-menus glib gcr json_glib accountsservice <del> libcroco intltool libsecret pkgconfig python3 libsoup polkit libcanberra gdk_pixbuf librsvg </del> <ins> libcroco intltool libsecret pkgconfig python3 python3Packages.pygobject3 libsoup polkit libcanberra gdk_pixbuf librsvg </ins> clutter networkmanager libstartup_notification telepathy_glib docbook_xsl docbook_xsl_ns libXtst p11_kit networkmanagerapplet gjs mutter libpulseaudio caribou evolution_data_server libical libtool nss gobjectIntrospection gtk gstreamer makeWrapper gdm

--set GDK_PIXBUF_MODULE_FILE "$GDK_PIXBUF_MODULE_FILE"  --suffix XDG_DATA_DIRS : "${gnome_themes_standard}/share:$out/share:$XDG_ICON_DIRS:$GSETTINGS_SCHEMAS_PATH" <ins> wrapProgram "$out/bin/gnome-shell-extension-tool"  --prefix PYTHONPATH : "${python3Packages.pygobject3}/lib/python3.4/site-packages:$PYTHONPATH" </ins> wrapProgram "$out/libexec/gnome-shell-calendar-server"  --prefix XDG_DATA_DIRS : "${evolution_data_server}/share:$out/share:$XDG_ICON_DIRS:$GSETTINGS_SCHEMAS_PATH"
Change:
The wrapper script created by clang-tools is broken again. Previous issue: clang-tools should be built correctly so that it (, etc.) can be started/used. I briefly looked at the llvmPackages v12 and v13 Nix expressions () since the last clang-tools fix was in the v12 package. There are enough changes that I'm unable to mentally cherry-pick the fix for v12 onto v13. I'm not sure why/when v13 diverged enough from v12 to break the package.
This seems to fix it for me, care to give it a try? I think we'd need to do the same for llvm git as well:
Thanks! That seems to work. Will you make a PR? Suggestion: change to to fail as early as possible if "tools" is missing.
And yes, we'd need it for too (good catch!).
I'm listed as the maintainer of , but unfortunately I no longer use it and no longer have time to maintain it. Would someone here be willing to take over maintainership for this package?
yes, I'd love to ; one sec, I'll prepare a merge request
Can we get this fix backported to 21.11? Not sure what the policy is for mass-rebuilds of a release branch. If that's acceptable I can prepare the PR.
Sure, I think we can make that happen. Each release has its own staging branch for mass rebuilds, and this is a regression bugfix so I think it qualifies for a backport.
This issue should be closed, it works now.

Discussion:
]; postPatch = '' <ins> (cd tools && ln -s ../../clang-tools-extra extra) </ins> sed -i -e 's/DriverArgs.hasArg(options::OPT_nostdlibinc)/true/'  -e 's/Args.hasArg(options::OPT_nostdlibinc)/true/'  lib/Driver/ToolChains/*.cpp