jiebi/CodeConvo huggingface dataset:
Change:
Describe the bug fails to compile the anyhow crate because creates a file for a probe in its is copied over the real anyhow so that the probe is compiled instead of the real lib. This second step seems to be performed differently by cargo if at all. I can imagine that this step was inspired by . The corresponding nix source seems to be To Reproduce Steps to reproduce the behavior: Expected behavior The original of anyhow should not be overwritten by the probe. Additional context This is where the is written from the script: This is the original issue where this came up: Metadata Please run and paste the result.
This really seems smells like we should remove the overlaying code. should be all that is required after the script has been run. I'll give this a spin in a bit.
This should have been fixed by

Discussion:
CRATENAME=$(echo ${crateName} | sed -e "s/(.*)-sys$/U1/") grep -P "^cargo:(?!(rustc-|warning=|rerun-if-changed=|rerun-if-env-changed))" target/build/${crateName}.opt  | sed -e "s/cargo:([^=]*)=(.*)/export DEP_$(echo $CRATENAME)_U1E=2/" > target/env set -e <del> if [[ -n "$(ls target/build/${crateName}.out)" ]]; then if [[ -e "${libPath}" ]]; then cp -r target/build/${crateName}.out/* $(dirname ${libPath}) #*/ else cp -r target/build/${crateName}.out/* src #*/ fi fi </del> fi runHook postConfigure ''

}) ]; }; <ins> # Regression test for https://github.com/NixOS/nixpkgs/issues/74071 # Whenevever a build.rs file is generating files those should not be overlayed onto the actual source dir buildRsOutDirOverlay = { src = symlinkJoin { name = "buildrs-out-dir-overlay"; paths = [ (mkLib "src/lib.rs") (mkFile "build.rs" '' use std::env; use std::ffi::OsString; use std::fs; use std::path::Path; fn main() { let out_dir = env::var_os("OUT_DIR").expect("OUT_DIR not set"); let out_file = Path::new(&out_dir).join("lib.rs"); fs::write(out_file, "invalid rust code!").expect("failed to write lib.rs"); } '') ]; }; }; </ins> }; brotliCrates = (callPackage ./brotli-crates.nix {}); in lib.mapAttrs (key: value: mkTest (value // lib.optionalAttrs (!value?crateName) { crateName = key; })) cases // {
Change:
Describe the bug Shell with and will fail to start with a following message: This is an issue because depends on so they would be always included to the shell started by nix-review. I noticed this issue while reviewing . I suspect this is caused by . To Reproduce Steps to reproduce the behavior: This does not reproduce on release-19.09 Expected behavior Shell will start, shell prompt will appear. Metadata Please run and paste the result. Maintainer information: cc
I'm getting "CLASSPATH: unbound variable" since updating master an hour ago from last Sunday, and reports "JAVA_HOME: unbound variable" started happening while working on eleven hours ago.

Discussion:
setupHook = writeText "setupHook.sh" '' addCoqPath () { if test -d "''$1/lib/coq/${coq-version}/user-contrib"; then <del> export COQPATH="''${COQPATH}''${COQPATH:+:}''$1/lib/coq/${coq-version}/user-contrib/" </del> <ins> export COQPATH="''${COQPATH-}''${COQPATH:+:}''$1/lib/coq/${coq-version}/user-contrib/" </ins> fi }
Change:
Describe the bug does not show --branch-name in its help message To Reproduce Steps to reproduce the behavior: Expected behavior I would expect to see a description of the argument. Metadata Maintainer information:
Should be fixed by

Discussion:
--url url       Any url understood by 'git clone'. --rev ref       Any sha1 or references (such as refs/heads/master) --hash h        Expected hash. <ins> --branch-name   Branch name to check out into </ins> --deepClone     Clone the entire repository. --no-deepClone  Make a shallow clone of just the required ref. --leave-dotGit  Keep the .git directories.
Change:
Describe the bug Upstream intel-vaapi-driver removed the --enable-drm ./configure option. It is now turned on by default. Happened in commit To Reproduce Steps to reproduce the behavior: the package and read through compile log Additional context This is a warning, package builds just fine despite this. Metadata Please run and paste the result. Maintainer information: (I don't know if I am dealing with attribute or module. I think attribute, but just to cover all bases.)
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 .

Discussion:
<del> { stdenv, fetchFromGitHub, autoreconfHook, gnum4, pkgconfig, python2 </del> <ins> { stdenv, fetchFromGitHub, autoreconfHook, gnum4, pkg-config, python3 </ins> , intel-gpu-tools, libdrm, libva, libX11, libGL, wayland, libXext , enableHybridCodec ? false, vaapi-intel-hybrid }:

sha256 = "1cidki3av9wnkgwi7fklxbg3bh6kysf8w3fk2qadjr05a92mx3zp"; }; <del> patchPhase = '' patchShebangs ./src/shaders/gpp.py ''; preConfigure = '' sed -i -e "s,LIBVA_DRIVERS_PATH=.*,LIBVA_DRIVERS_PATH=$out/lib/dri," configure ''; </del> <ins> # Set the correct install path: LIBVA_DRIVERS_PATH = "${placeholder "out"}/lib/dri"; </ins> postInstall = stdenv.lib.optionalString enableHybridCodec '' ln -s ${vaapi-intel-hybrid}/lib/dri/* $out/lib/dri/ ''; configureFlags = [ <del> "--enable-drm" </del> "--enable-x11" "--enable-wayland" ] ++ stdenv.lib.optional enableHybridCodec "--enable-hybrid-codec"; <del> nativeBuildInputs = [ autoreconfHook gnum4 pkgconfig python2 ]; </del> <ins> nativeBuildInputs = [ autoreconfHook gnum4 pkg-config python3 ]; </ins> buildInputs = [ intel-gpu-tools libdrm libva libX11 libXext libGL wayland ] ++ stdenv.lib.optional enableHybridCodec vaapi-intel-hybrid;

meta = with stdenv.lib; { homepage = "https://01.org/linuxmedia"; license = licenses.mit; <del> description = "Intel driver for the VAAPI library"; platforms = platforms.unix; maintainers = with maintainers; [ ]; </del> <ins> description = "VA-API user mode driver for Intel GEN Graphics family"; longDescription = '' This VA-API video driver backend provides a bridge to the GEN GPUs through the packaging of buffers and commands to be sent to the i915 driver for exercising both hardware and shader functionality for video decode, encode, and processing. VA-API is an open-source library and API specification, which provides access to graphics hardware acceleration capabilities for video processing. It consists of a main library and driver-specific acceleration backends for each supported hardware vendor. ''; platforms = [ "x86_64-linux" "i686-linux" ]; maintainers = with maintainers; [ primeos ]; </ins> }; }
Change:
Describe the bug appears to be broken due to a Qt version mismatch. To Reproduce <details</detailsExpected behavior Zoom launches successfully. Additional context I'm running the proprietary NVIDIA drivers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Cant reproduce with same zoom-us version and qt5-base.
Hmm, I think we can probably use instead of . Though this shouldn't be happening in general... Hopefully backportable fixes on master.
I know it's not terribly helpful but FWIW I can also confirm zoom works for me on the same 19.09 commit using nvidia proprietary drivers.
Oh, weird. I don't have anything installed with (which is what caused this issue the last time I had it). Perhaps another one of the entries in is conflicting?
Maybe try It looks like it maybe tried to load two different versions of qt plugins in the same process. Shouldn't happen at all with qt wrappers that prefix .
This seems to work for me after that change. I haven't tried a video call yet but it does launch successfully, which it didn't previously.
Update: I can join calls but no video appears.
same issue here on ubuntu 18.04 with kde-neon it works by running it with
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
09 is EOL

Discussion:
inherit (darwin.apple_sdk.frameworks) CoreServices; }; <del> zoom-us = libsForQt59.callPackage ../applications/networking/instant-messengers/zoom-us { }; </del> <ins> zoom-us = libsForQt5.callPackage ../applications/networking/instant-messengers/zoom-us { }; </ins> zotero = callPackage ../applications/office/zotero { };
Change:
Describe the bug The NixOS version number is very long. It's good to know from which nixpkgs commit it was built. Needed for issues here. But a user don't have to know the exact version. One rather uses the release version like used in the when talking about it. The long version also leads to UI breaking. For example in the Pantheon settings about panel: ! That looks broken. I would like to have just "NixOS 19.09 (Loris)" there. I propose to use the release version in end-user facing places and the full version which includes the revision for developers and debug tools. That would mean: nixos version = "19.09" nixos full version = "19.09.1320." Use nixos version in: /etc/os-release lsb-release script Use full nixos version in: nixos-version nix-info What do you think?
Maybe just shorten the field in ?
Yes, that would be enough. is the right place: A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable. If not set, defaults to "PRETTYNAME="Linux"". Example: "PRETTYNAME="Fedora 17 (Beefy Miracle)"". Our lsb-release script uses that too: That should improve Pantheon about panel, Mumble and Steam (and thereby Protondb).

Discussion:
release announcement</link> for more information. </para> </listitem> <ins> <listitem> <para> <literal>PRETTY_NAME</literal> in <literal>/etc/os-release</literal> uses the release now instead of full version to be more suitable for presentation to the user </para> </listitem> </ins> </itemizedlist> </section> </section>

VERSION="${cfg.version} (${cfg.codeName})" VERSION_CODENAME=${toLower cfg.codeName} VERSION_ID="${cfg.version}" <del> PRETTY_NAME="NixOS ${cfg.version} (${cfg.codeName})" </del> <ins> PRETTY_NAME="NixOS ${cfg.release} (${cfg.codeName})" </ins> LOGO="nix-snowflake" HOME_URL="https://nixos.org/" DOCUMENTATION_URL="https://nixos.org/nixos/manual/index.html"
Change:
As in the title. At the moment ls colors orphaned symbolic links just as normal symbolic links per default. As symbolic links are really ubiquitous in nix or nixos, is it a good a idea to change that default setting? (From reading the comments in the source, the idea is not following symbolic links, if it isn't really necessary, to avoid the work. Coloring orphaned links different per default, all the effort not to follow symbolic links, wouldn't be used usually.) It's a one line change, I could happily provide a pr (or is it mr) for. In a directory without the files and . ln -s a b LS_COLORS="" ls --color=always
I like this idea. After playing with it a little bit I went ahead and created a PR, since I think it deserves more than a 1-liner. There are bound to be those who want it toggleable.

Discussion:
fi ''; <ins> lsColors = optionalString cfg.enableLsColors '' eval "$(${pkgs.coreutils}/bin/dircolors -b)" ''; </ins> bashAliases = concatStringsSep "n" ( mapAttrsFlatten (k: v: "alias ${k}=${escapeShellArg v}") (filterAttrs (k: v: v != null) cfg.shellAliases)

type = types.bool; }; <ins> enableLsColors = mkOption { default = true; description = '' Enable extra colors in directory listings. ''; type = types.bool; }; </ins> }; };

${cfg.promptInit} ${bashCompletion} <ins> ${lsColors} </ins> ${bashAliases} ${cfge.interactiveShellInit}
Change:
Cc (PowerShell maintainer) Describe the bug Powershell uses telemetry unless explicitly told not to do it. In addition to its own environment variable (already set in the wrapper), it should require another one to disable telemetry from the underlying .NET platform, i.e. should be set to To Reproduce Steps to reproduce the behavior: powershell with (assumes you have the unstable channel installed) it with and verify that it's not set (i.e. no output) Expected behavior should be set to : Additional context Example of PowerShell's own CI config that disables telemetry on Linux: This should be fairly easy to change here: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: Maintainer information:

Discussion:
mkdir -p $out/share/powershell cp -r * $out/share/powershell makeWrapper $out/share/powershell/pwsh $out/bin/pwsh --prefix ${platformLdLibraryPath} : "${stdenv.lib.makeLibraryPath libraries}"  <del> --set TERM xterm --set POWERSHELL_TELEMETRY_OPTOUT 1 </del> <ins> --set TERM xterm --set POWERSHELL_TELEMETRY_OPTOUT 1 --set DOTNET_CLI_TELEMETRY_OPTOUT 1 </ins> ''; dontStrip = true;
Change:
Tried to update my unstable installation and it fails on evdi compliation: Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(hyper): channels(root): nixpkgs:
got any idea?
There seems to be a fix with latest git: I tried to apply it but I keep failing:
What fails is you build script if you use the all in one patch. You'll need to adjust your install phase. With the patch applied you can install normally. EG: make PREFIX=/something DESTDIR=... install, which now installs and symlinks the lib the right way. If you still want to do it manually, the library name is not

Discussion:
<del> { stdenv, fetchFromGitHub, kernel, libdrm }: </del> <ins> { stdenv, fetchFromGitHub, fetchpatch, kernel, libdrm }: </ins> stdenv.mkDerivation rec { pname = "evdi"; <del> version = "1.6.4"; </del> <ins> version = "-unstable-20190116"; </ins> src = fetchFromGitHub { owner = "DisplayLink"; repo = pname; <del> rev = "v${version}"; sha256 = "1yrjm8lvvz3v4h5af6m9qzq6z4lbgd7qbvq5rz7sjhdsh7g6qibd"; </del> <ins> rev = "391f1f71e4c86fc18de27947c78e02b5e3e9f128"; sha256 = "147cwmk57ldchvzr06lila6av7jvcdggs9jgifqscklp9x6dc4ny"; </ins> }; nativeBuildInputs = kernel.moduleBuildDependencies; buildInputs = [ kernel libdrm ]; <ins> patches = [ (fetchpatch { url    = "https://crazy.dev.frugalware.org/evdi-all-in-one-fixes.patch"; sha256 = "03hs68v8c2akf8a4rc02m15fzyp14ay70rcx8kwg2y98qkqh7w30"; }) ]; </ins> makeFlags = [ <del> "KDIR=${kernel.dev}/lib/modules/${kernel.modDirVersion}/build" </del> "KVER=${kernel.modDirVersion}" <ins> "KDIR=${kernel.dev}/lib/modules/${kernel.modDirVersion}/build" </ins> ]; hardeningDisable = [ "format" "pic" "fortify" ]; installPhase = '' install -Dm755 module/evdi.ko $out/lib/modules/${kernel.modDirVersion}/kernel/drivers/gpu/drm/evdi/evdi.ko <del> install -Dm755 library/libevdi.so $out/lib/libevdi.so </del> <ins> install -Dm755 library/libevdi.so.1.6.4 $out/lib/libevdi.so </ins> ''; meta = with stdenv.lib; { description = "Extensible Virtual Display Interface"; <del> homepage = "https://www.displaylink.com/"; license = with licenses; [ lgpl21 gpl2 ]; </del> platforms = platforms.linux; <ins> license = with licenses; [ lgpl21 gpl2 ]; homepage = "https://www.displaylink.com/"; </ins> broken = versionOlder kernel.version "4.9" || stdenv.isAarch64; }; }
Change:
When building chromium through nixos-rebuild off of the latest nixpkgs master: Not sure what changed, I don't see any recent updates to heimdal or pthreads, but I may have missed something.
I updated nixpkgs and this issue seemed to disappear. I'll reopen if I encounter this again.
I got this today on master ():
Ah, I see (I assume because of patch dependencies). Testing with that commit reverted now.
It worked. Pushed to master.

Discussion:
buildGoPackage rec { pname = "nomad"; <del> version = "0.10.5"; </del> <ins> version = "0.11.0"; </ins> rev = "v${version}"; goPackagePath = "github.com/hashicorp/nomad";

owner = "hashicorp"; repo = pname; inherit rev; <del> sha256 = "0i9104anf3qaydm1izlwrzvpzizd6p1zy651hsynscnnxa56cmyk"; </del> <ins> sha256 = "0jg7h52wlgd2aslx13fs97j3b8g5xfgil3p2jsc4j95l7lmqn7bv"; </ins> }; # ui:

noip = callPackage ../tools/networking/noip { }; <del> nomad = callPackage ../applications/networking/cluster/nomad { buildGoPackage = buildGo112Package; }; </del> <ins> nomad = callPackage ../applications/networking/cluster/nomad { }; </ins> notable = callPackage ../applications/misc/notable { };
Change:
Describe the bug Since the commit this package does not build. It fails with the following output: To Reproduce Steps to reproduce the behavior: Expected behavior Package should be building without errors. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Can reproduce, strange. Good news is bumping (as I happened to do locally earlier today for other reasons, haha) seems to fix things-- can you confirm that moving to 0.8.1 as in fixes this?
I can confirm that bump to 0.8.1 fixes the build. (However we have 0.7.3 already in master, so the change from does not apply cleanly). I sent the PR in where I also add myself as a maintainer.

Discussion:
<del> { lib, buildPythonPackage, fetchPypi , six, cryptography , mock, pyfakefs </del> <ins> { lib , buildPythonPackage , fetchPypi , six , cryptography , mock , pyfakefs </ins> }: buildPythonPackage rec { pname = "fido2"; <del> version = "0.7.3"; </del> <ins> version = "0.8.1"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "8b592ec0e51348f29636706fe3266423a0e41c35c9df63a259a91488450c1285"; </del> <ins> sha256 = "1hzprnd407g2xh9kyv8j8pq949hwr1snmg3fp65pqfbghzv6i424"; </ins> }; propagatedBuildInputs = [ six cryptography ];

meta = with lib; { description = "Provides library functionality for FIDO 2.0, including communication with a device over USB."; <del> homepage = https://github.com/Yubico/python-fido2; license = licenses.mpl20; </del> <ins> homepage = "https://github.com/Yubico/python-fido2"; license = licenses.bsd2; maintainers = with maintainers; [ prusnak ]; </ins> }; }
Change:
Describe the bug gitea fails to start due to a too restrictive systemd setup To Reproduce Looks like is a bit too restrictive. :smile:
ping
Removing the blacklist of and gets us past the test, I think, but there's still problems with the socket.
Judging from this error output: it looks like it fails in prescript during in Interestingly enough, there is a right underneath that, in which does not seem to be the issue. This does not look like an issue with Gitea itself, since it fails during the service pre script. Since the and will only be run if the configuration is managed by nix, the tests pass if I set in the test config. (unfortunatly I don't know much about systemd services and especially systemd sanboxing, so I'm not sure if the information from above is useful or not)
Any chance the service is broken too? I recently updated and service failed to start. I haven't dug into it yet... I may have seen something about a database permission issue.
Temporary fix for someone who using bleeding-edge Gitea:
This doesn't solve the issue for me. I get the following output:
Pretty strange. It works for me (). You can try to disable it at all () and if it'll still not work then just change in the same way all other parameters to default values that were introduced in . p.s. probably there's must be something like a mkForceRemove, but I haven't found anything in manual.
Ok the fix is actually working, I just had an own AmbientCapabilities definition in my configuration which didn't play nicely with the new options.

Discussion:
Restart = "always"; # Filesystem <del> ProtectSystem = "strict"; </del> ProtectHome = true; <del> PrivateTmp = true; </del> PrivateDevices = true; ProtectKernelTunables = true; ProtectKernelModules = true;

PrivateMounts = true; PrivateUsers = true; MemoryDenyWriteExecute = true; <del> SystemCallFilter = "~@chown @clock @cpu-emulation @debug @keyring @memlock @module @mount @obsolete @privileged @raw-io @reboot @resources @setuid @swap"; </del> <ins> SystemCallFilter = "~@clock @cpu-emulation @debug @keyring @memlock @module @mount @obsolete @raw-io @reboot @resources @setuid @swap"; </ins> SystemCallArchitectures = "native"; RestrictAddressFamilies = "AF_UNIX AF_INET AF_INET6"; };

timerConfig.OnCalendar = cfg.dump.interval; }; }; <ins> meta.maintainers = with lib.maintainers; [ srhb ]; </ins> }
Change:
Describe the bug Error during a system update A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: -channel --update ; nixos-rebuild switch Expected behavior Update the NixOs Additional context Normal update no changes to Metadata Please run and paste the result.
The issue it seems related to compiling Nvdia 435.21 under Linux Kernel latest 5.4.1
Not sure if we are supposed to be reverting the kernel bump. I pushed the driver update for now.
Can we expect soon the fix for the nvidia drv for new kernel?
The channel should will update once the tests [1] finish running. I see now, there is only one test left currently, so it should be very soon. [1]
Can you try now?
Thank you, just sync up and update and all woked fine

Discussion:
# Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}
Change:
I can't install virtualbox, because the kernel drivers fail to build (see below). Googeling around, I found something mildly relevant (the cause seems to be a fix for a dual build error by the OpenSUSE maintainer, see ). Set .
I think this one is similar to and is related to kernel update from 5.3.13 to 5.4.1
Seems like this LKML thread is related to this problem:
Is there a work around for this? I've tried using an pinned older commit but getting an error of:
My workaround is not to use the latest kernel packages:
Resolved in master thanks to . I'll cherry-pick the changes to release-19.09 tomorrow unless any opposition arises.
Finally in the 19.09 channel now so I'll close. Re-open if the issue remains after updating.

Discussion:
# Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}