jiebi/CodeConvo huggingface dataset:
Code change:
wrap ${prefix}ld.bfd ${preWrap ./ld-wrapper.sh} ${binutils_bin}/bin/${prefix}ld.bfd fi <del> export real_cc=${prefix}cc export real_cxx=${prefix}c++ </del> <ins> # We export environment variables pointing to the wrapped nonstandard # cmds, lest some lousy configure script use those to guess compiler # version. export named_cc=${prefix}cc export named_cxx=${prefix}c++ </ins> export default_cxx_stdlib_compile="${default_cxx_stdlib_compile}" if [ -e $ccPath/${prefix}gcc ]; then wrap ${prefix}gcc ${preWrap ./cc-wrapper.sh} $ccPath/${prefix}gcc ln -s ${prefix}gcc $out/bin/${prefix}cc <del> export real_cc=${prefix}gcc export real_cxx=${prefix}g++ </del> <ins> export named_cc=${prefix}gcc export named_cxx=${prefix}g++ </ins> elif [ -e $ccPath/clang ]; then wrap ${prefix}clang ${preWrap ./cc-wrapper.sh} $ccPath/clang ln -s ${prefix}clang $out/bin/${prefix}cc <del> export real_cc=clang export real_cxx=clang++ </del> <ins> export named_cc=${prefix}clang export named_cxx=${prefix}clang++ </ins> fi if [ -e $ccPath/${prefix}g++ ]; then

Related discussion:
text: gcc5 and the dependant gfortran5 packages are failing as of 31 July Failures: ] ] Building either package using or fails. System: (MacOS 10.11.6 and MacOS 10.12.6, both nix-multiuser install) Nix version: (1.11.13) Nixpkgs version: (17.09pre-git) Sandboxing enabled: (relaxed)
has been looking into this but it seems pretty mysterious so far
git-bisect is pretty neat
cc
This is also needed to fix things that depend on gcc
Code change:
./patchinstall.sh DESTDIR="$PWD/.." --all cd .. ''; <del> }) </del> <ins> })) // { meta = wineUnstable.meta // { description = wineUnstable.meta.description + " (with staging patches)"; }; } </ins>

Related discussion:
text: Describe the bug repology reports some issues with the package name and version. It should end with the version, not "staging". So we could just call the package . But we should be consistent here! All the wine versions and attribute names are messed up. wine-4.0.2 | wine wine-4.0.2 | wine-4.14 | winePackages.unstable wine-4.14-staging | wine-staging wine-4.14-staging | winePackages.staging Why is "staging" in the package name but "unstable" not? Is there even a difference? So i would remove "staging" from "wine-4.14-staging". Metadata master Maintainer information:
Adding to this: I locally built and without issues with the current packages but I'm not sure what's actually required for a PR here. Seems odd that it was so easy and nobody else already PRed it.
Mind doing the PR then? :)
I'm not sure what's actually required for a PR here. I also don't know what the wine maintainers want. My motivation is to get the repology error fixed. So i would remove "staging" from "wine-4.14-staging". Seems odd that it was so easy and nobody else already PRed it. There is a lot that can be improved in nixpkgs that is quiet easy! For example i'm currently fixing package versions that produce errors in repology. There are 586 known problems left to fix: There are 4997 outdated packages in nixpkgs unstable: Most of them probably quiet easy to update, but someone has to invest the time. Maybe there is already a PR that is not merged yet. A review can help to speed it up! But we are already the best distro when it comes to up-to-date packages! And we might supersede AUR in the future with total number of packages. But at the same time, many common packages are not in nixpkgs...
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".
Code change:
./patchinstall.sh DESTDIR="$PWD/.." --all cd .. ''; <del> }) </del> <ins> })) // { meta = wineUnstable.meta // { description = wineUnstable.meta.description + " (with staging patches)"; }; } </ins>

Related discussion:
text: 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 .
issue still exists cc maintainers
There is a difference between unstable and staging. Staging is the staging patches on top of unstable.
That makes sense. Can we add it to Long description? Repology seem to recognise the version now: !
Added to description, but if you think longDescription is better, or think the wording is not clear — please comment or PR.
Code change:
, xkeyboard_config , udisks2 <ins> , waylandSupport ? false, wayland-protocols, xwayland </ins> , bluetoothSupport ? true, bluez5 , pulseSupport ? !stdenv.isDarwin, libpulseaudio }:

Related discussion:
text: I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
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 .
It would be nice to hear about the recent progress.
Code change:
<ins> { stdenv, fetchFromGitHub }: stdenv.mkDerivation rec { name = "gradle-completion-${version}"; version = "1.3.1"; src = fetchFromGitHub { owner = "gradle"; repo = "gradle-completion"; rev = "v${version}"; sha256 = "02vv360r78ckwc6r4xbhmy5dxz6l9ya4lq9c62zh12ciq94y9kgx"; }; # we just move two files into $out, # this shouldn't bother Hydra. preferLocalBuild = true; dontBuild = true; installPhase = '' runHook preInstall mkdir -p $out install -Dm0644 ./_gradle $out/share/zsh/site-functions/_gradle install -Dm0644 ./gradle-completion.bash $out/share/bash-completion/completions/gradle runHook postInstall ''; meta = with stdenv.lib; { description = "Gradle tab completion for bash and zsh"; homepage = https://github.com/gradle/gradle-completion; license = licenses.mit; maintainers = with maintainers; [ ma27 ]; }; } </ins>

Related discussion:
text: It would be nice if we are able to have , in the same way we have , and the other completion siblings. I know it's easy to just and store in , but doing that we have to allow the user in question to write to that location (I don't really know the repercussions of any) and really defeats the purpose, somehow, of Nix Packages.
as the modules (at least for bash and zsh) are fairly advanced it shouldn't be too hard. I'll try to have a look at it tonight %)
Hi, I installed on Arch Linux , but whenever I go into any Gradle-based project it doesn't work – as it works in macOS when I install it using Brew. It just doesn't discover, nor auto-completes any of the (currently available) tasks. Maybe it's not getting sourced into the shell? I do have also installed, not sure if that's an impediment (or not):
I actually confirmed that the package is doing its job, however it can be possible that I screwed something up (e.g. something in my system config made it work). I don't think that I'll have sufficient time to look at this tonight, by I'll definetely keep this in mind and have a deeper look at this as soon as I have time to.
I rechecked with the following vm config (which is basically the same as the settings I posted in my commit message): It seems to work perfectly fine with , however the validation breaks with (didn't test this, mostly use as it's easier to type :sweat_smile:) It shouldn't be too hard to fix this, I'll ping you when it's done.
For me, even if I try to use alone, when I hit (auto-complete) on the shell (), it does auto-complete what I have in the directory, which is fine, but I guess at some point the script(s) should take over the "normal" shell auto-completion.
I'm fairly confused, are you sure that it's not caused by something else? I tested it with a VM from master and inside and work perfectly fine: What I suspect now is that it could be caused by your user profile. I'm not sure if actually pulls completion scripts from . Would you mind checking this with a VM or by adding to in your ?
Hi I'm using Arch Linux and the Bash shell.
Code change:
<ins> { stdenv, fetchFromGitHub }: stdenv.mkDerivation rec { name = "gradle-completion-${version}"; version = "1.3.1"; src = fetchFromGitHub { owner = "gradle"; repo = "gradle-completion"; rev = "v${version}"; sha256 = "02vv360r78ckwc6r4xbhmy5dxz6l9ya4lq9c62zh12ciq94y9kgx"; }; # we just move two files into $out, # this shouldn't bother Hydra. preferLocalBuild = true; dontBuild = true; installPhase = '' runHook preInstall mkdir -p $out install -Dm0644 ./_gradle $out/share/zsh/site-functions/_gradle install -Dm0644 ./gradle-completion.bash $out/share/bash-completion/completions/gradle runHook postInstall ''; meta = with stdenv.lib; { description = "Gradle tab completion for bash and zsh"; homepage = https://github.com/gradle/gradle-completion; license = licenses.mit; maintainers = with maintainers; [ ma27 ]; }; } </ins>

Related discussion:
text: I searched within my "home" directory for this file: and I couldn't find any. I did find a , but couldn't find on it. My Bash shell is the one that comes by default with Arch Linux. I did the same on a virtual machine with Ubuntu . Let me know if you want more info.
Ah good to know! I've been testing on NixOS, usually which defines the system's entire state. But I'm fairly certain that this is related to living in , please give me som etime to investigate, but this sounds like a bug in the bash packages themselves...
It might be a bug because right now that I'm on it, I should also have auto-completion for Git commands (due to the fact that I have ), and it doesn't work either. I even to , but still, nothing going on there: Thanks for the effort!
I see... Unfortunately I don't use the user profile for this so I might lack the required knowledge. I'd recommend to look for related tickets (or open a new one) as I'm fairly certain now that this is related to the integration of into .
Code change:
githubId = 84968; name = "Florian Paul Schmidt"; }; <ins> fptje = { email = "fpeijnenburg@gmail.com"; github = "FPtje"; githubId = 1202014; name = "Falco Peijnenburg"; }; </ins> fragamus = { email = "innovative.engineer@gmail.com"; github = "fragamus";

Related discussion:
text: Proprietary HTML5 videos break the whole site Workaround is to disable . Steps to reproduce the behavior: Vivaldi package with the package in your Configuration (home-manager) YouTube YouTube should display and the video should play. !
I hit this issue myself yesterday as well. I had reported it to Vivaldi before I realized it was indeed an outdated chromium-ffmpeg dependency. See . I wrote a PR at to fix this. For a quick fix, here's the code I have in my overlay to work around this straight away:
I just saw it. Thanks a lot! I will close this issue now as you already created an issue for discussion.
Code change:
{ stdenv, buildPythonApplication, fetchFromGitHub, isPyPy, lib <del> , future, psutil, setuptools </del> <ins> , defusedxml, future, psutil, setuptools </ins> # Optional dependencies: , bottle, pysnmp , hddtemp

Related discussion:
text: , CVSSv3=9.8 (nixos-21.05) The package glances before 3.2.1 are vulnerable to XML External Entity (XXE) Injection via the use of Fault to parse untrusted XML data, which is known to be vulnerable to XML attacks. Scanned versions: nixos-21.05: . Cc Cc Cc
This was resolved by
Code change:
freeformType = settingsFormat.type; options = { source_directories = mkOption { <del> type = nullOr (listOf str); default = null; </del> <ins> type = listOf str; default = []; </ins> description = '' List of source directories and files to backup. Globs and tildes are expanded. Do not backslash spaces in path names.

Related discussion:
text: I've set up a borgmatic backup script using the borgmatic service. I can run the backup manually by running as root, but fails with the following error: Here is the service definition I used: I then tried to pass an absolute path to cat, by replacing with and got the following similar error: Steps to reproduce the behavior: one of the service definitions above and observe that running it manually works. the output in No errors, as both and are present on the system, and I can run I also noticed that borgmatics default value for , , causes an error when the borgmatic service is run. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
As I know, NixOS package doesn't use your settings, which mean what you can use in your shell environment doesn't mean the package can use. User can use and whatever command they like in , I can't put everything in . So my suggestion is to use the format when using a command provided by other packages. As for your pgdump command not found, I suggest change it into Good caught, I will file a PR to change the default value.
This works, but I'm curious why it's not the default? As is, the service doesn't work for postgres dumps?
If we make this default, I think it will add those packages (pkgs.{mysql,postgresql,mariadb}) to nix store even the user doesn't need it. And I prefer to keep the package in minimal. Personally, I use the following code to use mysqldump
That's fair. Thanks for the feedback :-) Do we leave this issue open until has been merged?
You can keep it open, it will auto close once merged.
Code change:
callHackageDirect = {pkg, ver, sha256}@args: let pkgver = "${pkg}-${ver}"; in self.callCabal2nix pkg (pkgs.fetchzip { <del> url = "http://hackage.haskell.org/package/${pkgver}/${pkgver}.tar.gz"; </del> <ins> url = "mirror://hackage/${pkgver}/${pkgver}.tar.gz"; </ins> inherit sha256; });

Related discussion:
text: During Hackage downtime, nix builds are needlessly broken. There are mirrors available; we should use them. See: Mirrors include: http://objects-us-east- I'm a third party reporting errors I've heard of, so I don't have precise repro steps. Do certain Haskell-related build stuff during Hackage downtime, I guess?
Mirror list is available at E. g. https://objects-us-east-
Code change:
ln -s --force "$emulator" /run/${dirName}/nix-emulators/ done <del> for helper in libexec/qemu-bridge-helper bin/qemu-pr-helper; do </del> <ins> for helper in bin/qemu-pr-helper; do </ins> ln -s --force ${cfg.qemu.package}/$helper /run/${dirName}/nix-helpers/ done

Related discussion:
text: When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.
Code change:
ln -s --force "$emulator" /run/${dirName}/nix-emulators/ done <del> for helper in libexec/qemu-bridge-helper bin/qemu-pr-helper; do </del> <ins> for helper in bin/qemu-pr-helper; do </ins> ln -s --force ${cfg.qemu.package}/$helper /run/${dirName}/nix-helpers/ done

Related discussion:
text: I sometimes create a qemu VM in libvirt in "session mode", meaning that the libvirt daemon is running as my non-root user, and the system-wide libvirtd does not need to be running (). This VM has a network bridge, which libvirt apparently creates by calling , which in turn uses . The problem is that doesn't get fully populated until the system libvirtd gets started. Previously, in nixpkgs (from February), this wasn't noticeable because libvirtd.service was WantedBy libvirt-guests.service (which is WantedBy multi-), so libvirtd would always be started on boot to populate that directory. Now, with , this is no longer the case, and libvirtd.service does not get started (presumably, if libvirt-guests.service actually needed to start a VM, then libvirtd.service would be socket-activated, but for me this is not the case). As a result, doesn't get populated and my session-mode libvirt can't find . python: The VM's XML file defines a network bridge, which is why gets involved. the following output: The libvirt user session should be usable without first starting the system-wide libvirtd. If you start (and optionally stop) the system libvirtd.service before following the steps to reproduce, everything works fine, because the directory gets populated. Probably, should be put somewhere else, where session-mode daemons can use it without needing to have previously started system-mode libvirtd. (The same may be true of other stuff in too.) libvirt maintainers: Okay, but I'm using flakes and that channel looks old. See relevant commit hashes above.
Oof, happy to find this, it would have taken me a long time to figure out I needed to run first. Can't the sudo wrapper point to the file in the nix store?
Code change:
<del> { pkgs }: self: super: { rmfuse = super.rmfuse.overridePythonAttrs ( _: { src = pkgs.fetchgit { url = "https://github.com/rschroll/rmfuse.git"; rev = "3796b8610c8a965a60a417fc0bf8ea5200b71fd2"; sha256 = "03qxy95jpk741b81bd38y51d4a0vynx2y1g662bci9r6m7l14yav"; }; } ); } </del>

Related discussion:
text: The version of pillow rmfuse uses is vulnerable to CVE-2022-.
Since rmfuse is packaged using poetry2nix you are basically the only one willing to update it or its dependencies. That's problematic given that you don't do so even two weeks after being notified of a vulnerability.
I don't think interacting in this way is very constructive. There are different points of view regarding packaging Python packages, that's it. That an issue like this does not get picked up is not strange, people are typically busy. If you like to I suppose you could add the CVE to the expression. Whether the CVE can be considered a security issue in case of rmfuse should be considered as well.
Why not? I'm just articulating a problem with the way rmfuse is packaged right now that is obviously an actual problem. It's not technical though, just organizational.
Code change:
pname = commonDerivationAttrs.pname + "-frontend"; nativeBuildInputs = [ <del> wasm-pack wasm-bindgen-cli binaryen which rustc-wasm rustc-wasm.llvmPackages.lld </del> <ins> wasm-pack wasm-bindgen-84 binaryen which rustc-wasm rustc-wasm.llvmPackages.lld </ins> ]; buildPhase = ''

Related discussion:
text: Package name: wasm-bindgen-cli Latest released version: 0.28.4 Current version on the unstable channel: 0.2.84 Current version on the stable/release channel: 0.2.84 Notify maintainers and I'd really appreciate an update it's causing me problems with a trunk build similar to Note for maintainers: Please tag this issue in your PR.
Code change:
postPatch = lib.optionalString stdenv.isAarch64 '' substituteInPlace build/toolchain/linux/BUILD.gn  --replace 'toolprefix = "aarch64-linux-gnu-"' 'toolprefix = ""' <ins> '' + lib.optionalString stdenv.isDarwin '' substituteInPlace build/config/compiler/compiler.gni  --replace 'strip_absolute_paths_from_debug_symbols = true'  'strip_absolute_paths_from_debug_symbols = false' substituteInPlace build/config/compiler/BUILD.gn  --replace 'current_toolchain == host_toolchain || !use_xcode_clang'  'false' </ins> ''; gnFlags = [

Related discussion:
text: Describe the bug Since upgrading v8 to 8.4 () it no longer builds on darwin (at least on my 11.2.3 machine) To Reproduce Steps to reproduce the behavior: Expected behavior A successful v8 build Additional context By default it fails when trying to find the macos sdk, which I patched around with: This then gets as far as , which is avoidable with: which then produces ... and I had to admit defeat. Notify maintainers Metadata Maintainer information:
Hi! Thanks for reporting this! I've opened which I hope fixes this - at least it builds fine for me on 10.15. Please give it a try on your machine too.
Yep, looks good!
Code change:
echo "Checking tor-browser wrapper ..." TBB_HOME=$(mktemp -d)  $out/bin/tor-browser --version >/dev/null <ins> runHook postBuild ''; installPhase = '' runHook preInstall # Install distribution customizations install -Dvm644 ${distributionIni} $out/share/tor-browser/distribution/distribution.ini install -Dvm644 ${policiesJson} $out/share/tor-browser/distribution/policies.json runHook postInstall </ins> ''; meta = with lib; {

Related discussion:
text: When you try to connect to the Tor network using the Tor browser you get the error message ! When you try to visit a website after being shown the big red error message your get the error message ! This problem appeared between one and two weeks ago. ; can't find an existing Nixpkgs issue. Steps to reproduce the behavior: the Tor browser from Nixpkgs the Tor browser on error message to go to a website When clicking on the browser should connect to the Tor network and be able to browse. The . browsers says that it can detect my internet connection. ! Tor logs doesn't seem to indicate any problems (from what I can interpret) I live in Sweden and this issue has appeared both when I've connected to the internet using my home connection (Sunet) and when I've connected over a VPN. I.e. no fuckery by an oppressive government. The timeline match up-ish with when would have become available in the binary caches. Unsure if the error appeared before or after updating around that time. After checking the original PR I see that this problem was noticed, but a workaround was applied. Doesn't seem to work for me :-/ The value is for me. I'm using root on tmpfs, and nothing under is persistently saved between boots. ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- and because you seem to have actually researched the problem. The system is fully up-to-date as of 2023-03-05 22:15 CEST.
The red error message indicates that Tor cannot find the tor socket. Everything else is bound to not work unless it goes over the normal internet. Please see and for the underlying problem and please check if the firefox setting points to the right socket file.
I tested to set to , but that didn't help.
Setting to also doesn't work.
Just to avoid ambiguities, did you set to (with file name part)? TBB is still working fine for me with the workaround. Likewise for me, is a tmpfs. Have you modified (and forgotten about it) your torrc, e.g. to use a different control port/mechanism? What is your XDGSESSIONTYPE?