jiebi/CodeConvo huggingface dataset:
Change:
<del> {lib, stdenv, fetchurl}: </del> <ins> { lib, stdenv, fetchFromGitHub }: </ins> stdenv.mkDerivation rec { pname = "ncompress"; version = "5.0"; <del> builder = ./builder.sh; src = fetchurl { url = "mirror://sourceforge/project/ncompress/${pname}-${version}.tar.gz"; sha256 = "004r086c11sw9vg2j3srgxpz98w8pycjl33bk3pgqnd0s92igrn4"; </del> <ins> src = fetchFromGitHub { owner = "vapier"; repo = "ncompress"; rev = "v${version}"; sha256 = "sha256-Yhs3C5/kR7Ve56E84usYJprxIMAIwXVahLi1N9TIfj0="; </ins> }; <del> meta = { </del> <ins> makeFlags = [ "PREFIX=$(out)" ]; installTargets = "install_core"; postInstall = '' mv $out/bin/uncompress $out/bin/uncompress-ncompress ''; meta = with lib; { </ins> homepage = "http://ncompress.sourceforge.net/"; <del> license = lib.licenses.publicDomain; </del> <ins> license = licenses.publicDomain; </ins> description = "A fast, simple LZW file compressor"; <del> platforms = lib.platforms.unix; </del> <ins> platforms = platforms.unix; </ins> }; }

Discussion:
The and packages both provide an implementation of that is incompatible. This is leading to some trouble when having both packages installed and executing shell scripts that expect to be present in the path. Since isn't that widely used I would recommend to either remove from (it is a symbolic link anyway) or to rename it to . Steps to reproduce the behavior: and on a gzip compressed file (example: some ) There might be valid use cases where from is used, for example for very old shell scripts dating back to the early 1990s or earlier. These days the default is expected to be from and other distributions (like Fedora) do not seem to be creating the symlink for .
Change:
makeRustPlatform = callPackage ../development/compilers/rust/make-rust-platform.nix { }; <del> buildRustCrate = callPackage ../build-support/rust/build-rust-crate ({ } // lib.optionalAttrs (stdenv.hostPlatform.libc == null) { stdenv = stdenvNoCC; # Some build targets without libc will fail to evaluate with a normal stdenv. }); </del> <ins> buildRustCrate = let # Returns a true if the builder's rustc was built with support for the target. targetAlreadyIncluded = lib.elem stdenv.hostPlatform.rust.rustcTarget (lib.splitString "," (lib.removePrefix "--target=" ( lib.elemAt (lib.filter (f: lib.hasPrefix "--target=" f) pkgsBuildBuild.rustc.unwrapped.configureFlags) 0 ))); in callPackage ../build-support/rust/build-rust-crate ({ } // lib.optionalAttrs (stdenv.hostPlatform.libc == null) { stdenv = stdenvNoCC; # Some build targets without libc will fail to evaluate with a normal stdenv. } // lib.optionalAttrs targetAlreadyIncluded { inherit (pkgsBuildBuild) rustc cargo; } # Optimization. ); </ins> buildRustCrateHelpers = callPackage ../build-support/rust/build-rust-crate/helpers.nix { }; cargo2junit = callPackage ../development/tools/rust/cargo2junit { };

Discussion:
I'm running an issue with overriding the rust toolchain since , I pass the following to crate2nix: to set the toolchain when building something, since I don't want to override the toolchain globally. But after this PR it doesn't work because it uses the toolchain in instead of the one I'm passing in. Now I don't really know how to override the rust toolchain to the version I want. is a nightly version I got from This problem is caused by this optimization: Another issue is that the attribute is missing in rust-overlay:
I'm having this issue as well. I've overridden my input to my flake to as a workaround for now.
Hi, sorry for the delay, I'm back home now from "holiday". Can any of you give me a minimal flake that reproduces the issue so I can experiment and find the best way to fix it?
I'm also hitting this. I don't have a minimal flake but I can at least offer the error message which seems to be missing from the OP.
Let me know if this fixes it.
unfortunately it does not, because it still defaults to for the rustc compiler. I've created a reproduction here: As you can see in I'm overriding rustc and cargo to the specific nightly version I want, but when I run I get the following output: This is the rustc version that's current in nixpkgs, not the nightly I specified. Thanks a lot for looking into this
One problem with your reproducer is that it uses the for which takes an arg called not . I think that still wouldn't have solved it. I made some changes in the PR that would allow passing a custom toolchain via the but also using . I did some refactoring to get rid of the and variables.
Change:
<del> { lib , stdenv , fetchFromGitHub , gtk3 , meson , ninja , json_c , pkg-config , gtk-layer-shell , libpulseaudio , libmpdclient , libxkbcommon , alsa-lib , makeWrapper , }: stdenv.mkDerivation rec { pname = "sfwbar"; version = "1.0_beta13"; src = fetchFromGitHub { owner = "LBCrion"; repo = pname; rev = "v${version}"; hash = "sha256-7oiuTEqdXDReKdakJX6+HRaSi1XovM+MkHFkaFZtq64="; }; buildInputs = [ gtk3 json_c gtk-layer-shell libpulseaudio libmpdclient libxkbcommon alsa-lib ]; nativeBuildInputs = [ meson ninja pkg-config makeWrapper ]; postFixup = '' wrapProgram $out/bin/sfwbar  --suffix XDG_DATA_DIRS : $out/share ''; meta = with lib; { homepage = "https://github.com/LBCrion/sfwbar"; description = "Flexible taskbar application for wayland compositors, designed with a stacking layout in mind"; mainProgram = "sfwbar"; platforms = platforms.linux; maintainers = with maintainers; [ NotAShelf ]; license = licenses.gpl3Only; }; } </del>

Discussion:
Package name: sfwbar Latest released version: 1.0beta14 <!-- Search your package here: --- Current version on the unstable channel: 1.0beta13 Current version on the stable/release channel: 1.0_beta13 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers NotAShelf <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
users.groups."${cfg.group}" = { }; systemd.tmpfiles.rules = [ <del> "d '${cfg.stateDir}' - ${config.users.users.gollum.name} ${config.users.groups.gollum.name} - -" </del> <ins> "d '${cfg.stateDir}' - ${cfg.user} ${cfg.group} - -" </ins> ]; systemd.services.gollum = {

Discussion:
Steps to reproduce the behavior: or to anything. to build. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hey thank you very much for reporting!
Thank you for such a rapid fix!
Change:
buildPythonApplication rec { pname = "archivy"; <del> version = "1.6.1"; </del> <ins> version = "1.7.1"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "sha256-nwpH3V6hkPC8G3df+0hTZqvIbvT1Z796uOI/iKnXS1w="; </del> <ins> sha256 = "sha256-UNGl5Dl/E3+uQ4HIxzHYliHF4lqD3GYdeoL+DtqUwCo="; </ins> }; # Relax some dependencies

Discussion:
, CVSSv3=4.3 (nixos-21.11) archivy is vulnerable to Cross-Site Request Forgery (CSRF) Scanned versions: nixos-21.11: . Cc
Change:
(fetchNuGet { pname = "System.Text.Encoding.CodePages"; version = "6.0.0"; sha256 = "0gm2kiz2ndm9xyzxgi0jhazgwslcs427waxgfa30m7yqll1kcrww"; }) (fetchNuGet { pname = "System.Text.Encoding.CodePages"; version = "7.0.0"; sha256 = "0sn6hxdjm7bw3xgsmg041ccchsa4sp02aa27cislw3x61dbr68kq"; }) (fetchNuGet { pname = "System.Text.Encodings.Web"; version = "6.0.0"; sha256 = "06n9ql3fmhpjl32g3492sj181zjml5dlcc5l76xq2h38c4f87sai"; }) <ins> (fetchNuGet { pname = "System.Text.Encodings.Web"; version = "7.0.0"; sha256 = "1151hbyrcf8kyg1jz8k9awpbic98lwz9x129rg7zk1wrs6vjlpxl"; }) </ins> (fetchNuGet { pname = "System.Text.Json"; version = "6.0.5"; sha256 = "12fg196sdq3gcjcz365kypfkkmdrprpcw2fvjnww9jqa4yn8v99l"; }) <ins> (fetchNuGet { pname = "System.Text.Json"; version = "7.0.3"; sha256 = "0zjrnc9lshagm6kdb9bdh45dmlnkpwcpyssa896sda93ngbmj8k9"; }) </ins> (fetchNuGet { pname = "System.Threading.Channels"; version = "6.0.0"; sha256 = "1qbyi7yymqc56frqy7awvcqc1m7x3xrpx87a37dgb3mbrjg9hlcj"; }) (fetchNuGet { pname = "System.Threading.Tasks.Dataflow"; version = "6.0.0"; sha256 = "1b4vyjdir9kdkiv2fqqm4f76h0df68k8gcd7jb2b38zgr2vpnk3c"; }) <ins> (fetchNuGet { pname = "System.Threading.Tasks.Dataflow"; version = "7.0.0"; sha256 = "0ham9l8xrmlq2qwin53n82iz1wanci2h695i3cq83jcw4n28qdr9"; }) </ins> (fetchNuGet { pname = "System.Threading.Tasks.Extensions"; version = "4.5.4"; sha256 = "0y6ncasgfcgnjrhynaf0lwpkpkmv4a07sswwkwbwb5h7riisj153"; }) (fetchNuGet { pname = "System.Windows.Extensions"; version = "7.0.0"; sha256 = "11r9f0v7qp365bdpq5ax023yra4qvygljz18dlqs650d44iay669"; }) (fetchNuGet { pname = "YoloDev.Expecto.TestSdk"; version = "0.14.2"; sha256 = "1877gr3f8wl1x3njhgss9psxm21xpqv6cpg625f2mvvak79fzrra"; })

Discussion:
Package name: fsautocomplete Latest released version: Current version on the unstable channel: 0.67.0 Current version on the stable/release channel: nil <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Change:
# configuration. echo "finalising the installation..." if [ -z "$noBootLoader" ]; then <del> NIXOS_INSTALL_GRUB=1 chroot $mountPoint  </del> <ins> NIXOS_INSTALL_BOOTLOADER=1 chroot $mountPoint  </ins> /nix/var/nix/profiles/system/bin/switch-to-configuration boot fi

Discussion:
I was using gummiboot and struggling to figure out how to reinstall it. This option should be aliased and deprecated in favor of "--install-bootloader" or the like, and the manpage updated to be agnostic of the bootloader selected in , since the correct behavior is already in place (--install-grub reinstalls gummiboot properly).
Change:
}; services.zfs.zed.settings = { <del> ZED_EMAIL_PROG = mkDefault "${pkgs.mailutils}/bin/mail"; </del> <ins> ZED_EMAIL_PROG = mkIf cfgZED.enableMail (mkDefault "${pkgs.mailutils}/bin/mail"); </ins> PATH = lib.makeBinPath [ cfgZfs.package pkgs.coreutils

Discussion:
Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
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 .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in
Change:
<ins> unpackCmdHooks+=(_tryUnrar) _tryUnrar() { if ! [[ "$curSrc" =~ .rar$ ]]; then return 1; fi unrar x "$curSrc" >/dev/null } </ins>

Discussion:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.
Change:
Filters/Generic/FFT Forward Filters/Generic/FFT Inverse */ <del> name = "fourier-0.4.3"; buildInputs = with pkgs; [ fftw ]; </del> <ins> pname = "fourier"; version = "0.4.3"; </ins> src = fetchurl { <del> url = "https://www.lprp.fr/files/old-web/soft/gimp/${name}.tar.gz"; </del> <ins> url = "https://www.lprp.fr/files/old-web/soft/gimp/${pname}-${version}.tar.gz"; </ins> sha256 = "0mf7f8vaqs2madx832x3kcxw3hv3w3wampvzvaps1mkf2kvrjbsn"; }; <del> installPhase = "installPlugins fourier"; </del> <ins> buildInputs = with pkgs; [ fftw ]; postPatch = '' # The tarball contains a prebuilt binary. make clean ''; installPhase = '' runHook preInstall installPlugin fourier runHook postInstall ''; </ins> meta = with lib; { description = "GIMP plug-in to do the fourier transform";

Discussion:
Describe the bug I'm adding gimp like this in 20.09: However the fourier plugin is not being recognized. It should add: Filters/Generic/Forward FFT Filters/Generic/Inverse FFT But these filters are missing. Expected behavior FFT plugin should be recognized by gimp. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:
I'm not sure about these specific plugins, but gimp-with-plugins comes with G'MIC, which includes a FFT filter under Filters -G'MIC Qt... -Available Filters -Frequency -Fourier transform
Change:
githubId = 1162118; name = "Harald Gliebe"; }; <ins> hakan-demirli = { email = "ehdemirli@proton.me"; github = "hakan-demirli"; githubId = 78746991; name = "Emre Hakan Demirli"; }; </ins> hakuch = { email = "hakuch@gmail.com"; github = "hakuch";

Discussion:
Project description A waveform viewer with a focus on a snappy usable interface, and extensibility. <!-- Describe the project a little: --Metadata homepage URL: https://surfer- source URL: license: eupl12 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I tried to package it myself however, the following derivation fails: Error: Similar issue: Looks like the real issue has been solved couple years ago. I should update the derivation accordingly.
Change:
nativeBuildInputs = [ installShellFiles ]; <del> ldflags = [ "-s" "-w" ]; </del> <ins> ldflags = [ "-s" "-w" "-X main.version=${version}" "-X main.goVersion=${lib.getVersion go}" ]; </ins> # Test is disabled because e2e tests expect k8s. doCheck = false;

Discussion:
Expected this to show 0.15.6 instead of 0.0.1 <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- system: host os: multi-user?: sandbox: version: channels(root): channels(mauricio): nixpkgs:
Upon a cursory review this seems like an issue with upstream and not nixpkgs. See the search results for 0.0.1 in upstream @ .
Pretty sure it's controlled by the RELEASE_VERSION env var, which the nix package currently doesn't seem to set.
Change:
with ((import ./common.nix) { inherit stdenv rustc; <del> version = "2016-02-25"; </del> <ins> version = "2016-03-20"; </ins> }); buildRustPackage rec {

Discussion:
To make sure that we are on the same page: Kernel: (run ) 4.5.0 System: (NixOS: , Ubuntu/Fedora: , ...) (Flounder) Nix version: (run ) 1.11.2 Nixpkgs version: (run ) During testing of I managed to get at least two different hashes for . After some discussion with it seems that this derivation can produce non-deterministic output. Hashes of outputs are always the same. They are not. Build several times.
How would one work around that? It basically means the system cannot be rebuild :cry:
cc
You can work around it by updating SHA checksum in the affected package locally.
:confused: Is there any documentation you could point me too. I know how I would to it for packages that I install as a user: out nixpkgs repo the last commit that build for unstable on hydra that out the exa's file 5 run But I think it's also possible to override it in a nix expression, like the one in , since I installed it as a systems package. The thing is that all ressources I find either explain how to do it for that they link to
I changed my to include that: but to no avail :confused:
Sadly we don't have a mechanism to override (it needs to be supported). However, you can rebuild your whole NixOS from a modified repository:
Another way to do it is to call patched nixpkgs from your :
Thanks for your help! I really appreciate it. I tried your last suggestions, but that leads to: It looks like some network hick up, but I tried it multiple times and I opened the github repository from the same machine and it loads fine. Maybe it has something to do with this line: ?
Hm, unfortunately I have no idea what's going on -- you've fixed the hash, so it seems like another problem in .
Still thanks for the help. I learned a lot!
depends on a git repository in which doesn't work with
maybe fetchcargo could take an argument to pin git-based dependencies on a certain commit?
I can confirm that this is still an issue when building : through AUR/exa-git. cc
Are there any updates on this issue, please?
Should be fixed.
Change:
runHook postInstall ''; <del> outputHashAlgo = "sha256"; outputHashMode = "recursive"; outputHash = "1lmlc4fvjnp05gshc0arfysh8r1xxzpzdv3j0bk40mjf3d59814c"; </del> meta = with stdenv.lib; { description = "Nebula variant of the Ant theme"; homepage = "https://github.com/EliverLara/${themeName}";

Discussion:
Describe the bug While building ant-theme 3.0 with latest master the following error occurs: To Reproduce Steps to reproduce the behavior: ant-theme Expected behavior builds Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(maciej): channels(root): nixpkgs: Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
libsndfile pango perl <ins> python3 </ins> ]; postPatch = '' substituteInPlace scripts/e_gen_menu --replace "/usr/local:" "/run/current-system/sw:/usr/local:" <ins> substituteInPlace scripts/e_gen_menu --replace "'/opt'" "'/opt', '/run/current-system/sw'" substituteInPlace scripts/e_gen_menu --replace "'/.local'" "'/.nix-profile', '/.local'" </ins> ''; passthru.updateScript = gitUpdater {

Discussion:
In the e16 (enlightenment) window manager, menus are not generated dynamically, but rather via a script called . The version build by current nixpkgs has the following issues on NixOS: The script fails to run from the menu, as it hard-codes the interpreter path as The script does not find files for most Nix-installed applications, as it does not search in , so even if the script is manually run with the menu is quite empty I'll be submitting an MR to address this problem, as I already have a locally-tested fix. Steps to reproduce the behavior: an X session with as the window manager error on launch that menus could not be generated The correct behaviour is that should run without error, and pick up any files for applications installed via Nix. The generated menu file should then populate the menu list with installed applications. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
, xorg , zlib }: <ins> let </ins> <del> stdenv.mkDerivation rec { </del> <ins> suffix = if stdenv.system == "x86_64-linux" then "64" else "32"; in stdenv.mkDerivation rec { </ins> pname = "amdvlk"; <del> version = "2020.Q3.4"; </del> <ins> version = "2020.Q3.5"; </ins> src = fetchRepoProject { name = "${pname}-src"; manifest = "https://github.com/GPUOpen-Drivers/AMDVLK.git"; rev = "refs/tags/v-${version}"; <del> sha256 = "13yy1v43wyw2dbanl39sk1798344smmycgvl3gla61ipqls0qfgd"; </del> <ins> sha256 = "08fj3cg3axnwadlpfim23g5nyjl69044fqxdr57af6y79441njay"; </ins> }; buildInputs = [

Discussion:
Project description introduced amdvlk to nixos already, but afaict this only works with 64bit application, but since a lot of especially games are still 32bit it really would be nice to also be able to run those with amdvlk. I currently have this: In my nixos configuration to make sure that if possible amdvlk is used but also to make sure 32bit applications can still run Metadata should be the same
What would be the right way to do this with nix? The possibilities I see are: with the nix i686 toolchain (working amdvlk here: , can be used as ) A disadvantage of 2. is that it does not support lto.
Change:
<del> { mkDerivation, stdenv, fetchFromGitHub, cmake, extra-cmake-modules, gnumake, </del> <ins> { mkDerivation, lib, fetchFromGitHub, fetchpatch, cmake, extra-cmake-modules , kauth, krunner , pass, pass-otp ? null }: </ins> <del> pass, pass-otp ? null, krunner, }: let </del> <ins> mkDerivation rec { </ins> pname = "krunner-pass"; version = "1.3.0"; <del> in mkDerivation rec { name = "${pname}-${version}"; </del> src = fetchFromGitHub { owner = "akermu";

Discussion:
After switching to 19.03, krunner-pass failed to build on 19.03, it is failing with: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): channels(myuser): nixpkgs:
Upstream issue here looks like the same problem Needs a patch in the probably.
Change:
qrcode reportlab requests <del> setuptools </del> <ins> urllib3 </ins> vobject werkzeug xlrd xlsxwriter xlwt zeep <ins> setuptools mock </ins> ]; # takes 5+ minutes and there are not files to strip

Discussion:
Package name: Odoo Latest released version: 16.0. <!-- Search your package here: --- Current version on the unstable channel: 16.0. Current version on the stable/release channel: 15.0. <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Change:
{ stdenv, fetchurl, ncurses, asciidoc, xmlto, docbook_xsl, docbook_xml_dtd_45 <del> , readline, makeWrapper, git </del> <ins> , readline, makeWrapper, git, libiconv </ins> }: stdenv.mkDerivation rec {

Discussion:
After a bit of googling I get the impression that people think this may be a flaw in ncurses, but I haven't managed to pin it down. Something to do with tig trying to create windows that are 0 lines high, which the ncurses api claims to allow but the code doesn't, maybe? This happens in the unstable channel as well as master as of . I also verified that it's not fixed upstream in the tig source.
Can you provide more information? GDB logs, etc? I'm not able to test on darwin, but I try to help whereever I can...
I'll see if I can produce more debugging info later, once I'm back home where my mac is.
I also get this error when I installed tig from nix-env. I installed tig from the Git repo (), and it works fine.
Did you install the very same release or did you use latest master (or something) from the repo?
I just did a , so it's , as of now.
But how did you install it from the git repo?
I followed the instructions here:
Can you try to checkout the tag for 2.1.1 in your tig clone and from there? Does it fail like when installing via ?
Just tested the tag and it works just fine.
Okay, so it is an issue with the package definition. Someone with a darwin machine has to investigate, I cannot as I do not have a darwin machine, sorry. The information posted in this issue should be helpful anyways.