jiebi/CodeConvo huggingface dataset:
Change:
if [ -n "$latest_tag" ]; then # print commands to commit the changes if [ "$version" != "$latest_tag" ]; then <del> pfile=$(EDITOR=echo ${nix}/bin/nix edit -f. "$attr_path") </del> <ins> pfile=$(EDITOR=echo ${nix}/bin/nix edit --extra-experimental-features nix-command -f. "$attr_path") </ins> echo "   git add $pfile " >> ${fileForGitCommands} echo "   git commit -m '$attr_path: $version -> $latest_tag'" >> ${fileForGitCommands} fi

Discussion:
Trying to update my package fails because assumes that just works. Steps to reproduce the behavior: 't have enabled? :shrug: or another package that uses / I should be able to run the updateScript without having to worry about experimental features & whether or not they're enabled. n/a I don't mess with experimental stuff ( or ) and Nix versions aside from the default one. Would adding be enough here without breaking stuff for everyone else? Please run and paste the result.
When the script was written, worked without any further options. was introduced later.
Change:
# "spray" requires some files that aren't compiling correctly in xcbuild. # "rtadvd" seems to fail with some missing constants. # "traceroute6" and "ping6" require ipsec which doesn't build correctly <ins> # "unbound" doesn’t build against supported versions of OpenSSL or LibreSSL </ins> patchPhase = '' substituteInPlace network_cmds.xcodeproj/project.pbxproj  --replace "7294F0EA0EE8BAC80052EC88 /* PBXTargetDependency */," ""  --replace "7216D34D0EE89FEC00AE70E4 /* PBXTargetDependency */," ""  --replace "72CD1D9C0EE8C47C005F825D /* PBXTargetDependency */," ""  <del> --replace "7216D2C20EE89ADF00AE70E4 /* PBXTargetDependency */," "" '' + lib.optionalString stdenv.isAarch64 '' # "unbound" does not build on aarch64 substituteInPlace network_cmds.xcodeproj/project.pbxproj  </del> <ins> --replace "7216D2C20EE89ADF00AE70E4 /* PBXTargetDependency */," ""  </ins> --replace "71D958C51A9455A000C9B286 /* PBXTargetDependency */," "" '';

Discussion:
When I install openssl or opensslopenssl or opensslunstable I get an error that looks like a dependency is out of date. The following is from 22.11 but I get the same issue from unstable also. Steps to reproduce the behavior: -shell -p openconnect It should install without errors. Add any other context about the problem here. Sorry if I get this wrong :-) Please run and paste the result. `
I can't reproduce this on the latest unstable, could you try updating your channels () and see if this issue persists?
Upgraded (from about 5days). Same problem. Hmm. I think this might be OSX specific :-(
Hm, in this case I can't help you unfortunately because I know close to nothing about Darwin, sorry :(
I have been told that the problem is actually with networkcmds, see I was also told that just replacing this with doesn't work. CC:
On I think we concluded if we drop support for unbound (and Apple has dropped support in latest network_cmds anyway), then it should build with .
Change:
<ins> { lib, stdenv, fetchhg, pkg-config, makeBinaryWrapper, SDL2, glew, gtk3, testers, }: stdenv.mkDerivation (finalAttrs: { pname = "blastem"; version = "0.6.2-unstable-2024-03-31"; src = fetchhg { url = "https://www.retrodev.com/repos/blastem"; rev = "48ab1e3e5df5"; hash = "sha256-UZl5fIE7LJqxwS8kFJ3xr8BJyHF60dnRNeA5k7lAuxg="; }; # will probably be fixed in https://github.com/NixOS/nixpkgs/pull/302481 postPatch = lib.optionalString stdenv.isDarwin '' substituteInPlace Makefile  --replace-fail "-flto" "" ''; nativeBuildInputs = [ pkg-config makeBinaryWrapper ]; buildInputs = [ gtk3 SDL2 glew ]; # Note: menu.bin cannot be generated yet, because it would # need the `vasmm68k_mot` executable (part of vbcc for amigaos68k # Luckily, menu.bin doesn't need to be present for the emulator to function makeFlags = [ "HOST_ZLIB=1" ]; env.NIX_CFLAGS_COMPILE = "-I${lib.getDev SDL2}/include/SDL2"; installPhase = '' runHook preInstall # not sure if any executable other than blastem is really needed here install -Dm755 blastem dis zdis termhelper -t $out/share/blastem install -Dm644 gamecontrollerdb.txt default.cfg rom.db -t $out/share/blastem cp -r shaders $out/share/blastem/shaders # wrapping instead of sym-linking makes sure argv0 stays at the original location makeWrapper $out/share/blastem/blastem $out/bin/blastem runHook postInstall ''; passthru.tests.version = testers.testVersion { package = finalAttrs.finalPackage; command = "blastem -v"; version = "0.6.3-pre"; # remove line when moving to a stable version }; meta = { description = "The fast and accurate Genesis emulator"; homepage = "https://www.retrodev.com/blastem/"; license = lib.licenses.gpl3Plus; mainProgram = "blastem"; maintainers = with lib.maintainers; [ tomasajt ]; platforms = [ "i686-linux" "x86_64-linux" "x86_64-darwin" ]; }; }) </ins>

Discussion:
Project description <!-- Describe the project a little: --BlastEm is an open source, highly accurate emulator for the Genesis/Megadrive. Nightly release should be packaged as stable is five years out of date. Metadata homepage URL: source URL: license: GPLv3 platforms: unix Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
The fourStore and fourStoreEndpoint modules have been removed. </para> </listitem> <ins> <listitem> <para> Polkit no longer has the user of uid 0 (root) as an admin identity. We now follow the upstream default of only having every member of the wheel group admin privileged. Before it was root and members of wheel. The positive outcome of this is pkexec GUI popups or terminal prompts will no longer require the user to choose between two essentially equivalent choices (whether to perform the action as themselves with wheel permissions, or as the root user). </para> </listitem> </ins> </itemizedlist> </section>

Discussion:
On 19.09, when you on NixOS with default settings and your user being part of unix group , you get a prompt whether you want to get admin capabilities via your user or the user. This is somewhat inconvenient, because you always have to choose the user by clicking on it (or pressing a number key in the terminal); on other systems like Ubuntu, it somehow figures out that these two are identical and prompts immediately for the password. In we have both as the default. Setting it to only generates only 1 prompt. What is the first one good for, should we just remove it from the default, given that adding users to the is the default way of "making them admins"? Or do we somehow want to depart from the unix group approach of making people admins?
These are the patches used in ubuntu and also debian The default upstream for is So seemingly ubuntu and many other distro's aren't doing what we are doing. We use for probably a specific reason at some point in time.
It appears to have been this way for a long time My recommendation is we just use the default way it is in polkit. As far as I can tell, is how it's done in NixOS.
Right, most notably which does saying Seems reasonable to me as well
Change:
railgun = callPackage ./railgun { }; <ins> rec-mode = callPackage ./rec-mode { }; </ins> structured-haskell-mode = self.shm; sv-kalender = callPackage ./sv-kalender { };

Discussion:
Project description The advertises an advanced Emacs mode with the following features: Navigation mode and editing mode. Field folding. Visual edition of fields driven by types. User manual. …as well as Org mode integration: Read data from recfiles into a table in an org-mode buffer in Emacs. Publish the resulting data. Unfortunately and are not provided in the package provided by nixpkgs. They should be in , but the only file there is . See source linked below. Metadata homepage URL: source URL: license: GPL 3+ platforms: Unix
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 .
Change:
<del> { callPackage, fetchpatch, lib, stdenv }: callPackage ./generic.nix { version = "1.12.0"; sha256 = "0f7xd66vc1lzjbn7jzd5kyqrgxpsfxi4zc7iymhb5xrwyxipjl1g"; patches = [ (fetchpatch { # Fixed a compilation error with GCC 10.0 to 11.0. June 1, 2020. # Should be included in the next release after 1.12.0 url = "https://github.com/google/flatbuffers/commit/988164f6e1675bbea9c852e2d6001baf4d1fcf59.patch"; sha256 = "0d8c2bywqmkhdi0a41cry85wy4j58pl0vd6h5xpfqm3fr8w0mi9s"; excludes = [ "src/idl_gen_cpp.cpp" ]; }) (fetchpatch { # Fixed a compilation error with GCC 10.0 to 11.0. July 6, 2020. # Should be included in the next release after 1.12.0 url = "https://github.com/google/flatbuffers/pull/6020/commits/44c7a4cf439b0a298720b5a448bcc243a882b0c9.patch"; sha256 = "126xwkvnlc4ignjhxv9jygfd9j6kr1jx39hyk0ddpcmvzfqsccf4"; }) ]; preConfigure = lib.optionalString stdenv.buildPlatform.isDarwin '' rm BUILD ''; } </del>

Discussion:
We define two packages, one for version 1.12 and one for version 2.0. The package for version 1.12 . Upstream has the fixes needed but only for version 2.0. The version 1.12 branch does not appear maintained, and there to it since March of 2020. We can continue to maintain this (e.g. we can disable warnings, or we can adapt those fixes to 1.12 and patch them), but perhaps we could drop support for the old version altogether? ZHF: /cc
Disabling -Werror is always reasonable, but if there's no users left in nixpkgs I think it's ok to drop it. Unless the maintainer or someone else still has a use for this (do a scream test by removing it, I guess)
is unused and can be safely removed.
Change:
version = "3.13.4"; src = fetchurl { <del> url = "https://www.ocenaudio.com/downloads/index.php/ocenaudio_debian9_64.deb?version=${version}"; </del> <ins> url = "https://www.ocenaudio.com/downloads/index.php/ocenaudio_debian9_64.deb?version=v${version}"; </ins> hash = "sha256-vE+xwwkBXIksy+6oygLDsrT8mFfHYIGcb6+8KMZe0no="; };

Discussion:
Getting the following error when trying to install =! I'm using the latest NixOS 11.23 and Gnome.
Change:
sha256 = "2x8vwLTSngqQqmVrVh/mM4peATgaRqOSwrfm5XCkg/g="; }; <del> sourceRoot = "./src"; </del> <ins> sourceRoot = "${src.name}/src"; </ins> meta = with lib; { homepage = "http://michaelcmartin.github.io/Ophis/";

Discussion:
Describe the bug On current nixos-unstable (), fails to build To Reproduce Steps to reproduce the behavior: -shell -p ophis Notify maintainers
Change:
, chromecastSupport ? false , serverSupport ? false , keyringSupport ? true <del> , notifySupport ? true, libnotify , networkSupport ? true, networkmanager </del> <ins> , notifySupport ? true , libnotify , networkSupport ? true , networkmanager </ins> }: python3Packages.buildPythonApplication rec {

Discussion:
Steps to reproduce the behavior: sublime-music Just the error: Full log: Add any other context about the problem here. Built OK as of rev . I tried bisecting but too many commits required me to build multiple versions of LLVM/GHC/god knows what else. I also tried applying patch from but that didn't change the error. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
<del> { lib, buildPackages, stdenvNoCC, autoreconfHook, fetchurl, fetchpatch }: stdenvNoCC.mkDerivation rec { </del> <ins> { lib, stdenv, buildPackages, autoreconfHook, fetchurl, fetchpatch, }: stdenv.mkDerivation rec { </ins> pname = "alsa-firmware"; version = "1.2.4";

Discussion:
Steps to reproduce the behavior: Discovered by <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
version = "4.1.1"; src = fetchurl { <del> url = "https://www.rs.tus.ac.jp/yyusa/ricty/ricty_generator-${version}.sh"; </del> <ins> url = "http://www.yusa.lab.uec.ac.jp/~yusa/ricty/ricty_generator-${version}.sh"; </ins> sha256 = "03fngb8f5hl7ifigdm5yljhs4z2x80cq8y8kna86d07ghknhzgw6"; };

Discussion:
Describe the bug The build of package () fails because returns a 403 error code (and no useful data) To Reproduce Steps to reproduce the behavior: in the nixpkgs directory, on current master Expected behavior Build succeeds Screenshots Additional context Metadata Please run and paste the result. Maintainer information:
Possible hotfix: Use as url which provides the needed source, but sadly no https, and this is not a mirror with versions in the url.
It seems the homepage moved to
The versioned ~yusa/ricty/ricty_generator- also exists
Change:
-e "$link/nixos-version" ? readFile("$link/nixos-version") : basename((glob(dirname(Cwd::abs_path("$link/kernel")) . "/lib/modules/*"))[0]); <del> addEntry("@distroName@ - Configuration " . nrFromGen($link) . " ($date - $version)", $link, $subEntryOptions, 0); </del> <ins> addGeneration("@distroName@ - Configuration " . nrFromGen($link), " ($date - $version)", $link, $subEntryOptions, 0); </ins> } $conf .= "}n";

Discussion:
NixOS specialisations are supposed to have their own entries in the Grub menu for previous generations according to the . However in practice that is not the case. The older generations do not hold any boot entry for the specialisations, but only the default entry. nixpkgs: I am not sure, whether to update the wiki to correctly mention current behavior, or whether to fix the grub module to generate entries for specialisations for older generations. <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions
Fixed by .
Change:
expandResponseParams = "${expand-response-params}/bin/expand-response-params"; shell = getBin shell + shell.shellPath or ""; gnugrep_bin = if nativeTools then "" else gnugrep; <ins> # stdenv.cc.cc should not be null and we have nothing better for now. # if the native impure bootstrap is gotten rid of this can become `inherit cc;` again. cc = if nativeTools then "" else cc; </ins> wrapperName = "CC_WRAPPER"; <del> inherit suffixSalt coreutils_bin bintools cc; </del> <ins> inherit suffixSalt coreutils_bin bintools; </ins> inherit libc_bin libc_dev libc_lib; inherit darwinPlatformForCC darwinMinVersion darwinMinVersionVariable; };

Discussion:
Describe the bug I'm getting from some Nix packages. /nix/store/8br3hnwahahpi4m3s9xjd34xn18bf1l4-source/pkgs/stdenv/generic/make- Here -Originated from: Is it because it should be Expected behavior No error nix-env version is 2.11.0 Additional context Add any other context about the problem here.
I ran into the same issue when I tried to use nix-darwin with flakes. The example was using an old version of nixpkgs-darwin. Changing it to use the latest version seemed to fix it. I made a PR to update the readme: LnL7/nix-darwin .
Same problem on OpenBSD The trace
Can be reproduced on linux with: ` Edit: The problem is in cc-native which seems to be rotted over time because we didn't add a new system for a longer time. The problem is that cc-native has not version attr. Trying to find a fix for that right now.
can you move this to nixpkgs?
Change:
buildRustPackage = callPackage ../../../build-support/rust { git = buildPackages.gitMinimal; <del> inherit cargoBuildHook cargoCheckHook cargoInstallHook cargoSetupHook </del> <ins> inherit stdenv cargoBuildHook cargoCheckHook cargoInstallHook cargoSetupHook </ins> fetchCargoTarball importCargoLock rustc; }; importCargoLock = buildPackages.callPackage ../../../build-support/rust/import-cargo-lock.nix {}; rustcSrc = callPackage ./rust-src.nix { <del> inherit rustc; </del> <ins> inherit stdenv rustc; </ins> }; rustLibSrc = callPackage ./rust-lib-src.nix { <del> inherit rustc; </del> <ins> inherit stdenv rustc; </ins> }; # Hooks inherit (callPackage ../../../build-support/rust/hooks { <del> inherit cargo rustc; </del> <ins> inherit stdenv cargo rustc; </ins> }) cargoBuildHook cargoCheckHook cargoInstallHook cargoSetupHook maturinBuildHook; }

Discussion:
My hydra instance started to report hash mismatches in rust packages (agate, ion, nushell, ox, ripgrep) (I'm cross-compiling to aarch64-multiplatform). It appears that the commit introduced this. See also the associated PR: Steps to reproduce the behavior: nixpkgs @ (just building the attribute would be enough) all deps... mismatch for cargo dependencies. No hash mismatch. I don't understand why the linked change would cause this. Maybe you know why this happens? Please run and paste the result. Maintainer information:
Huh, this is really interesting, I'm going to revert that change for now.
Reverting has fixed this. Hopefully the right solution can be found :).
Would you have time to test a re-do of the original PR? I think I know how to get it to work correctly.
Change:
patches = patches fetchpatch; <del> src = fetchurl { url = "mirror://gnu/emacs/${name}.tar.xz"; </del> <ins> src = fetchFromSavannah { repo = "emacs"; rev = version; </ins> inherit sha256; };

Discussion:
The issue is what the title says. By half, I mean and for my previously used from emacs-overlay to your system the eln cache in your home, e.g. to open emacs for the manual for by and inputing the eln cache in your home: , you will find together other eln cache. I think this is a bug since is builtin for emacs and it's eln cache should be distributed together with . Uses of will not need to native-compile builtin libraries themselves. does distributed together with from emacs-overlay I used before. It's . might be related to the bump of 28 , so
The difference between the two versions is that one is built from the tarball, while the other is built from Git. The tarball includes byte-compiled () files but not native-compiled () files. The build notices the files and does not rebuild them, but native-compilation is a side-effect of byte-compilation and so the files aren't built either. (Almost all of the files you see for the new version are trampolines, there are only 3 non-trampoline files.)
ideally we'd run , which is the expected way of deleting such things (or perhaps even ). But the tarball only has a , so we'd need to run , then , then again, which is super ugly. Hopefully deleting the files the naïve way is enough?
I think maybe we should just skip the tarball entirely and fetch it from git instead.
There are other side-effects caused by skipping the tarball. This claims, for example, that bootstrapping is only expected to happen to emacs developers. Part of bootstrapping is converting the Japanese input method dictionaries, and this takes some amount of time. They're in the tarball at , but are absent in the git checkout.
That's a good point, I would still rather inflate build times a bit and exercise bootstrapping as a part of our regular build though to completely avoid these types of issues.
I'm hesitant about building things in a way that upstream doesn't expect, unless necessary to adapt for nixpkgs. For a related example, using the repo instead of the tar distribution for Ruby caused a subtle problem where the commit hash was not propagated, which broke the bootsnap gem's cache invalidation (fixed in , by using the tarball).

The real question here, I think, is how upstream expects native compilation to be used if their tarball doesn't support it.
Change:
bcachefs-tools = callPackage ../tools/filesystems/bcachefs-tools { }; <ins> bit = callPackage ../applications/version-management/git-and-tools/bit { }; </ins> bitwarden = callPackage ../tools/security/bitwarden { }; inherit (nodePackages) bitwarden-cli;

Discussion:
Bit is a modern Git CLI bit is an experimental modernized git CLI built on top of git that provides happy defaults and other niceties Metadata homepage URL: source URL: license: apache 2.0 platforms: linux, darwin, windows
Change:
in { mariadb_104 = mariadbPackage { # Supported until 2024-06-18 <del> version = "10.4.23"; sha256 = "1wlhjd1xvk6p2lb93v8kfjk1scyjz882fx0i0sjyyk047mh2i852"; </del> <ins> version = "10.4.22"; sha256 = "000ca1hdnj2jg051cjgdd2ralgwgh2p8nwb1x6b85202xdpc7ga4"; </ins> }; mariadb_105 = mariadbPackage { # Supported until 2025-06-24 <del> version = "10.5.14"; sha256 = "02y292mfvr6ils4m61lh9vy74z3w2xkz6xinpgg9wl5h7q29gzaf"; </del> <ins> version = "10.5.13"; sha256 = "0n0w1pyypv6wsknaqyykj3lc9zv6smji4q5jcf90w4rid330iw0n"; </ins> }; mariadb_106 = mariadbPackage { # Supported until 2026-07 <del> version = "10.6.6"; sha256 = "1hz1iwkgrlhhrn5ypxszfp5ngfmfakjxl3ihzsm4845xhzn1fr77"; }; mariadb_107 = mariadbPackage { # Supported until 2023-02 version = "10.7.2"; sha256 = "1cx5s8vq7s3r4w1drmp549kl2nyijzq6ds2mcjyzc7bk9ylipx6p"; }; mariadb_108 = mariadbPackage { # Supported until 2023-05 version = "10.8.1"; sha256 = "0ns0z8w3374jrfdrmq7ncag089xwmf7wkr5aq3p9shk1b5mln9z2"; </del> <ins> version = "10.6.5"; sha256 = "13qaqb2h6kysfdi3h1l9zbb2qlpjgxb1n8mxnj5jm96r50209gp0"; </ins> }; }

Discussion:
MariaDB 10.6.6 does not seem to exist at the given source.
Yeah, they unpublished those releases. I'd suggest just reverting the updates for now
Change:
, fetchFromGitHub , pnpm , nodejs <del> , electron_30 </del> <ins> , electron_31 </ins> , makeWrapper , copyDesktopItems , makeDesktopItem }: stdenv.mkDerivation rec { pname = "armcord"; <del> version = "3.2.8"; </del> <ins> version = "3.3.0"; </ins> src = fetchFromGitHub { owner = "ArmCord"; repo = "ArmCord"; rev = "v${version}"; <del> hash = "sha256-H/Y3xA7gE24UsUkrxmrRFSvs16qZCVxli9vdnt7ihi8="; </del> <ins> hash = "sha256-nVirmGgR5yssMRXFUialMjTTSEa5nVNtue207eYUJCg="; </ins> }; nativeBuildInputs = [ pnpm.configHook nodejs makeWrapper copyDesktopItems ]; pnpmDeps = pnpm.fetchDeps { inherit pname version src; <del> hash = "sha256-hYp1XbWQL5NbIzzUSnZ7y7V+vYQmymRNo+EiSjn5d9E="; </del> <ins> hash = "sha256-ETnTWErdOIdcyK/v42bx+dFPPt+Lc0Lxyzo+RpxvEjU="; </ins> }; ELECTRON_SKIP_BINARY_DOWNLOAD = "1";

Discussion:
Package name: armcord Latest released version: 3.3.0 <!-- Search your package here: --- Current version on the unstable channel: 3.2.8 Current version on the stable/release channel: 3.2.7 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Unstable is currently waiting on Electron 32 to be to nixpkgs to be able to update to 3.3.0. We may be able to update Stable before then since it is using the compiled packages. Which are you running currently (Stable vs Unstable)?
I'm currently using unstable.
Got it, once we have electron 32 available it should be a fairly quick package / release.
I attempted to package this using Electron 31 since that's available, and it seems to be working stably. I looked at the ArmCord source and it doesn't look like it relies on anything Electron 32-specific, so I'll try to put out a PR.