Question: stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

, CVSSv3=9.8 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.0 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc
See also: ,


Question: stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

, CVSSv3=9.8 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also:


Question: stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

, CVSSv3=9.8 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.


Question: stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

, CVSSv3=9.8 (nixos-20.03) CVSSv3=9.8 (nixos-20.03) CVSSv3=9.8 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=5.9 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.3 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
See also:


Question: stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

, CVSSv3=9.8 (nixos-19.09) CVSSv3=9.8 (nixos-19.09) CVSSv3=9.8 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09) CVSSv3=5.9 (nixos-19.09) CVSSv3=5.5 (nixos-19.09) CVSSv3=5.3 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also:
30.1 is also the default version in 20.03 ATM.


Question: rustPlatform.buildRustPackage rec { pname = "eww"; <del> version = "0.6.0"; </del> <ins> version = "0.6.0-unstable-2024-04-26"; </ins> src = fetchFromGitHub { owner = "elkowar"; repo = "eww"; <del> rev = "refs/tags/v${version}"; hash = "sha256-rzDnplFJNiHe+XbxbhZMEhPJMiJsmdVqtZxlxhzzpTk="; </del> <ins> # FIXME: change to a release tag once a new release is available # https://github.com/elkowar/eww/pull/1084 # using the revision to fix string truncation issue in eww config rev = "2c8811512460ce6cc75e021d8d081813647699dc"; hash = "sha256-eDOg5Ink3iWT/B1WpD9po5/UxS4DEaVO4NPIRyjSheM="; </ins> }; <del> cargoHash = "sha256-n9nd5E/VO+0BgkhrfQpeihlIkoVQRf6CMiPCK5opvvw="; </del> <ins> cargoHash = "sha256-ClnIW7HxbQcC85OyoMhBLFjVtdEUCOARuimfS4uRi+E="; </ins> <del> nativeBuildInputs = [ pkg-config wrapGAppsHook3 ]; </del> <ins> nativeBuildInputs = [ pkg-config wrapGAppsHook3 ]; </ins> buildInputs = [ gtk3

After upgrading to eww 0.6.0 from unstable I've got problems showing some strings in some of my widgets, one that shows the hour and another the minutes using two digits each one, i.e. : "09 : 10". When using eww 0.6.0 the string shown is like this: "... : ..." In eww's github repo I can see that there is a commit after version 0.6.0: And cloning eww repo with that commit, compiling it and using a local eww executable the problem explained before disappears for me. There's also another problem, asking eww-0.6.0 for version number shows it's 0.5.0: unstable eww 0.6.0 some string truncation (I think this is the problem) see "..." where a two char string with the hour should appear. eww should work as expected. Cloning eww repo with latest commit after v0.6.0 was published solves the problem for me.
~The current package for eww is . How did you install 0.6.0 from nixpkgs?~ ~As for the outdated 0.5.0 version in nixpkgs, there are three maintainers for eww in nixpkgs so it probably will be updated shortly, perhaps fetching a commit with the solution to the string truncation problem you describe.~ EDIT: i was wrong, see comment below.
I got it installed today from unstable when upgrading my system: But, as you say, if I look for it into unstable () it shows version 0.5.0...I can't understand very well this...I'm relatively new to nixos. Ok, I'll wait then. Thanks for your interest in this.
Oh sorry, you're right! There is eww 0.6.0 in master, although it didn't make it into unstable yet. I built the package and, indeed, truncation is broken the version is incorrectly reported So the truncation was fixed, as you mention, after the release, and the reported version . That . If you can't wait, for it, i'd recommend you use the package output from the eww flake.


Question: rustPlatform.buildRustPackage rec { pname = "eww"; <del> version = "0.6.0"; </del> <ins> version = "0.6.0-unstable-2024-04-26"; </ins> src = fetchFromGitHub { owner = "elkowar"; repo = "eww"; <del> rev = "refs/tags/v${version}"; hash = "sha256-rzDnplFJNiHe+XbxbhZMEhPJMiJsmdVqtZxlxhzzpTk="; </del> <ins> # FIXME: change to a release tag once a new release is available # https://github.com/elkowar/eww/pull/1084 # using the revision to fix string truncation issue in eww config rev = "2c8811512460ce6cc75e021d8d081813647699dc"; hash = "sha256-eDOg5Ink3iWT/B1WpD9po5/UxS4DEaVO4NPIRyjSheM="; </ins> }; <del> cargoHash = "sha256-n9nd5E/VO+0BgkhrfQpeihlIkoVQRf6CMiPCK5opvvw="; </del> <ins> cargoHash = "sha256-ClnIW7HxbQcC85OyoMhBLFjVtdEUCOARuimfS4uRi+E="; </ins> <del> nativeBuildInputs = [ pkg-config wrapGAppsHook3 ]; </del> <ins> nativeBuildInputs = [ pkg-config wrapGAppsHook3 ]; </ins> buildInputs = [ gtk3

I personally have been using it for a while and it works correctly (let me know if you need help, i'm on the matrix server with the same username). For now, I guess this issue can be closed because both are upstream bugs and the fixes will make it into a future release.
I think I we can backport the changes using patches. I'll send a PR.
Still I don't know how this 0.6.0 version was pulled from unstable into my system...I'm in my way learning nixos. Flakes! my never ending story :). I'll try to use it and if I have problems I'll try to ping you on the matrix server. Thx!
Since 0.6.0 reached unstable, of course, and you updated your channels/inputs. BTW the search can be out-of-date, so don't expect 100% accuracy from it.
Yep, that makes sense to me and seems to be the missing piece that confused me: how could it be possible that in the search appeared version 0.5 and I had installed v 0.6. thanks for clarifying it for me and for your work in Nixos.


Question: --replace '"/usr/local/bin/espanso"' '"${placeholder "out"}/bin/espanso"' ''; <ins> env = lib.optionalAttrs stdenv.cc.isClang { # Work around https://github.com/NixOS/nixpkgs/issues/166205. NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}"; }; </ins> # Some tests require networking doCheck = false;

was looking to resume my work on espanso's (which has been somewhat impeded by ), and now I find that espanso no longer builds at all. As those issues haven't gotten much attention thought I'd reach out to to see if anyone can at least confirm (as my understanding is that the reproducibility on darwin can't be quite as good as NixOS -- especially when one ). Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thank you so much for the quick fix! I keep running into these issues on darwin, I really want / need to learn more so I can contribute back! Unfortunately I'm still getting a build error, which looks to be a sandbox issue: This seems to fix the issue: Could you take a look and if appropriate merge? Many thanks!


Question: kpurpose kdeclarative wrapGAppsHook3 <del> glaxnimate </del> ]; # Both MLT and FFMpeg paths must be set or Kdenlive will complain that it

Rendering a project in Kdenlive with default rendering settings leads to the following error: Steps to reproduce the behavior: ( is the latest revision of at the moment of writing this) any clip to the timeline (for example, drag in an image) "Render..." "Render to File" You might need to use as your desktop manager to reproduce this issue. There is claiming that this crash doesn't happen on Plasma 6. I am using Plasma 5, but I am currently unable to verify if Plasma 6 would fix this issue (Plasma 6 is broken for me for unrelated reasons). Render should succeed. See issue for the previous instance of this problem. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are you using the kdenlive matching to your desktop? Edit: nope, you are using the plasma 6 package. You want to use plasma5Packages.kdenlive.
is plasma6? Wow, that's quite a foot gun. Shouldn't it be called ? Also, fails with the same error.
It really should not matter, and will (once is entirely gone) be whatever versions upstream ships.
it seems that the problem either wasn't fixed or has resurfaced again? I was able to reproduce the exact same error with and (where is the latest revision of at the moment of writing this)
Please try again after the staging-next merge (which should make its way to unstable in a few hours).
I will. Could you explain why staging-next is relevant in this case, though? I am just curious. I checked using and in the github UI directly, and it seems that the changes from should be already present in revision .
staging-next reshuffles protobuf versions again.
I wasn't sure which staging-next merge you were originally talking about, so I tried the same thing with commits (current nixos-unstable), (current staging-next) and (current master) and I am still getting the same error. Can you reopen this issue, or should I open a new one?
Hm. Actually, I think that I figured out, what the problem is. It seems that actually saves some paths in .


Question: kpurpose kdeclarative wrapGAppsHook3 <del> glaxnimate </del> ]; # Both MLT and FFMpeg paths must be set or Kdenlive will complain that it

For example, my had the following lines: Deleting the line fixes the issue, but then adds it back again with the new path, so it will almost certainly eventually break again. I am honestly not sure, why does do this, but we should probably either patch this behavior or report it upstream.
That sounds very wrong because you have defaults from two different kdenlive versions in there.
I can tell you that I've never touched prior to this debugging session. I didn't even know it existed. Those lines seem to be automatically populated on demand. Most likely, these lines were simply generated at different times, and so they picked up different paths to the "current" version of . Also, the fact that these paths are different from each other is mostly irrelevant in this case. The real problem is that they are cached once and aren't updated when a different version of is used.


Question: { path = "/boot"; inherit (cfg) devices; inherit (efi) efiSysMountPoint; } ]; <ins> boot.loader.supportsInitrdSecrets = true; </ins> system.build.installBootLoader = let install-grub-pl = pkgs.substituteAll {

Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.


Question: dotnetfx40 = callPackage ../development/libraries/dotnetfx40 { }; <del> dolphinEmu = callPackage ../misc/emulators/dolphin-emu { }; dolphinEmuMaster = qt5.callPackage ../misc/emulators/dolphin-emu/master.nix { </del> <ins> dolphin-emu = callPackage ../misc/emulators/dolphin-emu { }; dolphin-emu-beta = qt5.callPackage ../misc/emulators/dolphin-emu/master.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreBluetooth ForceFeedback IOKit OpenGL; };

The derivation of creates a different .desktop file from the "official" one that has a different name. This is probably done in order to differentiate the two versions of in case someone installs both of them, but the problem is that while it creates a new one, it doesn't delete the "official" one. Also, the new .desktop file should also set , otherwise games don't launch in Wayland. (Though maybe it should be a wrapper instead) (And, unrelated, but why and not ?) The same also applies to PATH: there are both and (which is a link made by the derivation to in the folder). For consistency, there should be made a , otherwise if both dolphins are installed, one overwrites the other in PATH. Steps to reproduce the behavior: dolphinEmuMaster; an app launcher; are both the original "Dolphin Emulator" and the new "Dolphin Emulator (master)" that open the same app (the master one doesn't set `QTQPAPLATFORM=xcb). PATH there are both and (which is a link). There should only be the "Dolphin Emulator (master)" desktop file, and in PATH there should be only (and instead of ). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --


Question: generic = { version, sha256, eol ? false, extraVulnerabilities ? [] <del> }: stdenv.mkDerivation rec { </del> <ins> }: let major = lib.versions.major version; in stdenv.mkDerivation rec { </ins> pname = "nextcloud"; inherit version;

<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 25.0.1 desired version: 25.0.2 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package -- maintainers: Please tag this issue in your PR.


Question: in stdenv.mkDerivation rec { pname = "cups-filters"; <del> version = "1.25.0"; </del> <ins> version = "1.25.6"; </ins> src = fetchurl { url = "https://openprinting.org/download/cups-filters/${pname}-${version}.tar.xz"; <del> sha256 = "1laiscq8yvynw862calkgbz9irrdkmd5l821q6a6wik1ifd186c1"; </del> <ins> sha256 = "1pgjk7j2p8m17pwynqd86hxgvz9lyb09ivx18lv6inmygij0pm4j"; </ins> }; nativeBuildInputs = [ pkgconfig makeWrapper ];

Describe the bug fails to build on current master To Reproduce Steps to reproduce the behavior: a checkout of the current nixpkgs master Expected behavior Build succeeds Screenshots <details<summaryNot a screenshot, but build output </summary<p</p</detailsAdditional context The kind of error (not including a needed header) seems to be an upstream bug for me. Metadata Please run and paste the result. Maintainer information:
Fixed by upstream in See my PR


Question: fullName = "European Union Public License 1.1"; }; <ins> eupl12 = spdx { spdxId = "EUPL-1.2"; fullName = "European Union Public License 1.2"; }; </ins> fdl12 = spdx { spdxId = "GFDL-1.2-only"; fullName = "GNU Free Documentation License v1.2 only";

Project description Client for authenticating to services using a German ID Metadata homepage URL: source URL: license: EUPL platforms: unix, linux, darwin, win32


Question: # Update this when adding the newest kernel major version! # And update linux_latest_for_hardened below if the patches are already available <del> linuxPackages_latest = linuxPackages_5_8; </del> <ins> linuxPackages_latest = linuxPackages_5_7; </ins> linux_latest = linuxPackages_latest.kernel; # Build the kernel modules for the some of the kernels.

Describe the bug The is failing. I bisected this problem to “linux: Init 5.8”. The error message matches , which points to both a workaround of recompiling systemd against Linux 5.8 headers, and an upstream systemd patch (systemd/systemd) that’s in systemd 246 () and was backported in 245.7 as systemd/systemd-stable To Reproduce Steps to reproduce the behavior: Notify maintainers Cc Metadata Please run and paste the result. Maintainer information:
My PR wasn't merged, Linux 5.8 ended up being by someone else.
Linking for visibility: that PR was
The PR bumping systemd to 245.7 is at
Is it really helpful to send systemd 245.7 to given that will be unable to advance without it? Or are you thinking we also want to revert the bump in for now?
Maybe we should revert in master, and re-revert it in staging again. I let and decide about this, they've been doing the staging rounds.
Hey all, question: How do you spot which tests block the channels? I always track and every few days I notice nixos-unstable doesn't progress. When it don't I see an issue with the "channel blocker" label and I always wonder..
Click on the “Hydra job for tests” link and go to the “Constituents” tab.


Question: , libtiff, librsvg, gconf, libxml2, imagemagick, gnutls, libselinux , alsaLib, cairo, acl, gpm, AppKit, GSS, ImageIO, m17n_lib, libotf , jansson, harfbuzz <del> , libgccjit, targetPlatform, makeWrapper # native-comp params </del> <ins> , libgccjit, targetPlatform, makeWrapper, nukeReferences # native-comp params </ins> , systemd ? null , withX ? !stdenv.isDarwin , withNS ? stdenv.isDarwin

Describe the bug In NixOS 20.09, Emacs now has the output of gtk+ in its closure, which in turn causes it to pull in stuff like mesa-drivers (424 MiB): This caused the closure size of Emacs to increase from 339 MiB in NixOS 20.03 to 1324 MiB in 20.09. Metadata NixOS 20.09..
cc
This was reverted in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Question: <ins> { stdenv, fetchFromGitHub }: let rev = "77686b3dfa20a34270cc52377c8e37c3a461e484"; version = stdenv.lib.strings.substring 0 7 rev; in stdenv.mkDerivation { name = "sbt-extras-${version}"; inherit version; src = fetchFromGitHub { owner = "paulp"; repo = "sbt-extras"; inherit rev; sha256 = "1bhqigm0clv3i1gvn4gsllywcnwfsa73xvqp8m7pbvn8g7i2ws6x"; }; dontBuild = true; installPhase = '' mkdir -p $out/bin install bin/sbt $out/bin ''; meta = { description = "A more featureful runner for sbt, the simple/scala/standard build tool"; homepage = https://github.com/paulp/sbt-extras; license = stdenv.lib.licenses.bsd3; maintainers = with stdenv.lib.maintainers; [ puffnfresh ]; platforms = stdenv.lib.platforms.unix; }; } </ins>

I'm told a lot of people favor Paul Phillips' SBT wrapper over vanilla SBT. We probably ought to have a package for it.
Minus the parts where it auto-downloads sbt for you, I expect
Mmm, I don't know. Isn't it kind of important to be able to auto-download the appropriate version of sbt for each project?
Maybe? Seems hard to keep it Nix-flavored though, given that it wants to retrieve unhashed versions from the outside. I guess we could either patch it to call out to nix to download scala and sbt, or we could leave it alone and users can decide whether they care about Nix-like behavior here.


Question: maintainers = with lib.maintainers; [ dotlambda foo-dogsquared ]; platforms = lib.platforms.all; mainProgram = "warp"; <ins> broken = stdenv.isDarwin; </ins> }; }

On an apple silicon: $ nix-env -iA I thought was supposed to add support for macos. <!-- 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.
Why don't you ping
I don't own a mac currently and I don't use the package, can't help you unfortunately.


Question: gmp libGL libGLU <ins> libSM </ins> mpfr proj python

Unable to launch gplates on NixOS. A shared object file appears to be missing. Steps to reproduce the behavior: : gplates is expected to launch and be usable. N/A N/A No listed maintainers on Nix Packages but was the last to touch the source for this application. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably adding to and/or adding to might help, but I'm too tired to debug tonight. I'll look into it in the next few days.
Thank you, I was reading about the first option you suggested being a potential fix. I'll see if I can wrap my head around doing it on my own as well this week, though I don't have a lot of experience contributing to projects likes this.


Question: ln -sf '${file}' "${local}" '') rules} <del> if [ ! -f /etc/opensnitch-system-fw.json ]; then </del> <ins> if [ ! -f /etc/opensnitchd/system-fw.json ]; then </ins> cp "${pkgs.opensnitch}/etc/opensnitchd/system-fw.json" "/etc/opensnitchd/system-fw.json" fi '');

Opensnitch requires system- file to be placed under /etc/opensnitchd/system- to be able to enable its System rules/Firewall settings to be active and changeable. Steps to reproduce the behavior: to OpenSnitch Statistics to the button on the left navigation window just right of Rules/System Rules. cannot change the firewall settings there. the service complains about it. Being able to access that windows' setting. These screenshot shows the corrected version of the window. ! ! Can be solved temporarily with the nixos config below (the file can be found in opensnitch github repo): <!-- 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.
Explain this line to me My hardware wouldn't be "asus" how do I find the directory for that?
the latest change to the opensnitch module (in unstable) has again a change for deploying the system- file, see the file comes from the opensnitch package and is linked to /etc/openstnichd/system- configuring this file is currently not supported. what would your use case be?


Question: <ins> { stdenv , lib , fetchFromGitHub , installShellFiles , binutils-unwrapped , systemd }: stdenv.mkDerivation rec { pname = "beefi"; version = "0.1.1"; src = fetchFromGitHub { owner = "jfeick"; repo = "beefi"; rev = version; sha256 = "1180avalbw414q1gnfqdgc9zg3k9y0401kw9qvcn51qph81d04v5"; }; nativeBuildInputs = [ installShellFiles ]; buildInputs = [ binutils-unwrapped systemd ]; patchPhase = '' substituteInPlace beefi  --replace objcopy ${binutils-unwrapped}/bin/objcopy  --replace /usr/lib/systemd ${systemd}/lib/systemd ''; installPhase = '' install -Dm755 beefi $out/bin/beefi installManPage beefi.1 ''; meta = with lib; { description = "A small script to create bootable EFISTUB kernel images"; license = licenses.gpl3; platforms = platforms.linux; maintainers = with maintainers; [ tu-maurice ]; homepage = "https://github.com/jfeick/beefi"; }; } </ins>

Project description Converts Linux images and kernels into UEFI images. Metadata homepage URL: source URL: license: GPL3 platforms: Linux


Question: ''; }) ]; <del> services.postfix = { </del> <ins> services.postfix = lib.mkIf cfg.enablePostfix { </ins> recipientDelimiter = "+";         # bake recipient addresses in mail envelopes via VERP config = { owner_request_special = "no";   # Mailman handles -owner addresses on its own

Describe the bug Mailman module in NixOS requires postfix enabled and has no way to configure Mailman to work with other MTAs supported by both NixOS and mailman upstream. To Reproduce Steps to reproduce the behavior: postfix mailman the evaluation with an assertion Expected behavior The Mailman module allows to select an MTA of choice (or even adapts to the currently enabled MTA) Screenshots n/a Additional context Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(vika): nixpkgs: Maintainer information:
It looks like exim's configuration should be RFC42-ised first if we want to inject Mailman-related settings into Exim config, which is a requirement (Mailman requires a custom Exim router and transport).
Yes, the module is currently quite opinionated. If you're willing to contribute exim support that's great.
I see how I could make it work, but the first version of it will require manual editing of Exim's config files (because RFC42-ising Exim will be a pain, even though I have some drafts on how to translate Nix into the syntax that's required), and I'm not sure if it will be merge-worthy enough :3
Exim config is complicated enough as is, I'm not sure adding an intermediate layer from nix will help that much. I also don't really see this integrating well with existing or other exim config. I'm honestly kind of surprised this works for postfix.


Question: config.nix.package ] ++ cfg.extraPackages; <del> serviceConfig = rec { </del> <ins> serviceConfig = { </ins> ExecStart = "${cfg.package}/bin/Runner.Listener run --startuptype service"; # Does the following, sequentially:

Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here:


Question: <ins> { lib , stdenv , fetchFromGitHub , meson , ninja , pkg-config , wrapGAppsHook , desktop-file-utils , appstream-glib , python3Packages , glib , gtk3 , libhandy , gobject-introspection , gst_all_1 }: python3Packages.buildPythonApplication rec { pname = "blanket"; version = "0.5.0"; src = fetchFromGitHub { owner = "rafaelmardojai"; repo = "blanket"; rev = version; sha256 = "00i821zqfbigxmc709322r16z75qsw4rg23yhv35gza9sl65bzkg"; }; nativeBuildInputs = [ meson ninja pkg-config wrapGAppsHook desktop-file-utils appstream-glib ]; buildInputs = [ glib gtk3 libhandy gobject-introspection gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good gst_all_1.gst-plugins-bad ]; propagatedBuildInputs = with python3Packages; [ pygobject3 ]; # Broken with gobject-introspection setup hook # https://github.com/NixOS/nixpkgs/issues/56943 strictDeps = false; format = "other"; postPatch = '' patchShebangs build-aux/meson/postinstall.py ''; meta = with lib; { homepage = "https://github.com/rafaelmardojai/blanket"; description = "Listen to different sounds"; maintainers = with maintainers; [ onny ]; license = licenses.gpl3Plus; platforms = platforms.linux; }; } </ins>

Project description ! Metadata homepage URL: source URL: license: gpl3 platforms: linux
FTR: This requires an update of .
I marked this as stale due to inactivity. →


Question: <del> diff --git a/Makefile b/Makefile index d6b9dc1..ce7c493 100644 --- a/Makefile +++ b/Makefile @@ -601,7 +601,7 @@ install-localstatedir: endif -install: all $(if $(BUILD_DOCS),install-doc) install-datadir install-localstatedir +install: all $(if $(BUILD_DOCS),install-doc) install-datadir ifneq ($(TOOLS),) $(call install-prog,$(subst qemu-ga,qemu-ga$(EXESUF),$(TOOLS)),$(DESTDIR)$(bindir)) endif </del>

Steps to reproduce the behavior: afl <!-- 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]:
If you are planing to open a PR, you don't need to create an issue first.
I wasn't sure, thanks for clarification


Question: linux_5_15_hardened = recurseIntoAttrs (packagesFor kernels.linux_5_15_hardened); linux_6_1_hardened = recurseIntoAttrs (packagesFor kernels.linux_6_1_hardened); linux_6_5_hardened = recurseIntoAttrs (packagesFor kernels.linux_6_5_hardened); <ins> linux_6_6_hardened = recurseIntoAttrs (packagesFor kernels.linux_6_6_hardened); </ins> linux_zen = recurseIntoAttrs (packagesFor kernels.linux_zen); linux_lqx = recurseIntoAttrs (packagesFor kernels.linux_lqx);

Project description Hardened patchset got released for Linux 6.6. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi, created the following merge request. Would appreciate a review.
will try to check that tomorrow's morning if my ibs allows me to, thanks


Question: echo "unsupported interpreter directive "$oldInterpreterLine" (set dontPatchShebangs=1 and handle shebang patching yourself)" exit 1 fi <del> newPath="$(command -v "$arg0" || true)" </del> <ins> newPath="$(PATH="${!pathName}" command -v "$arg0" || true)" </ins> else if [ "$oldPath" = "" ]; then # If no interpreter is specified linux will use /bin/sh. Set # oldpath="/bin/sh" so that we get /nix/store/.../sh. oldPath="/bin/sh" fi <del> newPath="$(command -v "$(basename "$oldPath")" || true)" </del> <ins> newPath="$(PATH="${!pathName}" command -v "$(basename "$oldPath")" || true)" </ins> args="$arg0 $args" fi

uses to determine the substitute for the shebang path. This selects the wrong path during cross-builds and results in x8664 binaries getting pulled in as dependencies to cross-built binaries that can't possibly use them at runtime. I don't know if we can reliably pick the correct /bin/sh without it being in the PATH envvar. I presume patchShebangs works fine for binaries that don't overlap with stdenv's and are included in buildInputs. If you cross-build some packages to ARM platforms, patchShebangs runs in the fixup phase and run , you'll see it points to the native /bin/sh rather than the cross one. I was considering a PR to just add to the cross build of glibc, but figured it'd be better if the root issue were fixed instead. System: "16.03pre75806." Nix version: nix-env (Nix) 1.12pre1234abcdef Nixpkgs version: (Gorilla)
/participate. (I've stumbled across this too.)
Is it safe to assume are the only paths that will ever realistically have this problem? If so, how and where would we pull in as a buildInput without it clobbering the native /bin/sh used by stdenv to run the builder? Once we're already executing , it's too late to find any s. This problem overlaps with another, , which is that crossDrvs clobber stdenv's binaries in the PATH. The best solution I can come up with is to manually include in of e.g. glibc, add logic in to not add to the PATH when crossbuilding, based on some new derivation attr like , then search during , independently of what's set in the PATH. Or we could just make smarter about importing /bin/ PATHs that contain elements of the stdenv, namely: .
is essential to fix this without greatly complicating bootstrapping.
don't forget to close. :)
Addressed in


Question: <del> { lib, python3, fetchFromGitHub, git, pkg-config }: </del> <ins> { lib, stdenv, python3, fetchFromGitHub, git, pkg-config, fetchpatch }: </ins> # Note: # Conan has specific dependency demands; check

Description Attempting to install conan with nix-env on Mac OS X errors out with the following message: To Reproduce Steps to reproduce the behavior: Expected behavior As Mac OS X is a supported platform for conan, it's expected that it would install. Additional context This appears to be due to conan's dependency on the python3-distro package, which only compiles on Linux architectures. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(tclemons): channels(root): nixpkgs:


Question: default = null; defaultText = literalExpression "username"; }; <ins> workDir = mkOption { type = with types; nullOr str; description = lib.mdDoc '' Working directory, available as `$GITHUB_WORKSPACE` during workflow runs and used as a default for [repository checkouts](https://github.com/actions/checkout). The service cleans this directory on every service start. A value of `null` will default to the systemd `RuntimeDirectory`. ''; default = null; }; </ins> }


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Julia 1.5 is out, see: and we don't have it packaged. More over, see how defines our other Julias: Several issues: is pointing to a TLS version which is old IMO. Certainly there are breaking changes seen in , but since Nixpkgs is a somewhat rolling release distro, are we going to keep these older versions and default to them for ever? I've once tried to reach for the community to hear if there's a strict policy regarding such scenarios, but Anyway, I'd like to propose a change that will keep only the LTS version and the latest - currently 1.4, and perhaps make the attribute , point to the latest. Any thoughts from maintainers or users? cc
Also, now I noticed all of our Julias fail to build, e.g:
I agree. And the 1.5 release candidates are out, so this will become the latest version in the near future. Last time I looked, the package built the same deps for all versions, including 0.7. In versions 1.0 and later, there are actually fewer dependencies (e.g. arpack and fftw have been dropped), so the package should be cleaned up to not include these unnecessary libraries in the build. I also think the default version should be the latest version (i.e., unless somebody explicitly installs julia-1-lts, they should get the latest).
OK I'm glad I have your support. I'll let this issue stay open for a while and hopefully I'll be able to take care of this a month or so from now.
cc
Back when Julia tests were not so messed up, I think there was often 1 previous version. I guess with 1.3 needing overriding to no tests, it is fine to just have julia-1-lts and Julia 1.4 as julia once Julia 1.4 gets built fine with some tests.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Haven't had a lot of time to work on julia in nixpkgs, so just posting this as a FYI.


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

We used multiple versions of julia at work, but we use a custom derivation, similar to this: We also do not run the tests, but in general it has been working great. Previously we also used the binary builds patched with patchelf, as there were some differences in the structure of the results of the vanilla binary build provided by julia and what we got when building from source. We gave up on using 'system' libraries, and build the releases that julia provides, as julia is very specific in the versions for its dependencies (LLVM patches mostly).
I tried to use that tarball in order to write a derivation from scratch. Here's my attempt: It fails with: Naturally I didn't further attempt to add curl or wget to the inputs, as that would fail in a sandbox as well. I've opened an issue upstream: complaining that that tarball doesn't really contain all dependencies.
I ran with sandbox enabled, and the expression I linked with works for me. So I think it is fine to just add curl to the deps, as with the full tarball, it isn't actually used.
There is another approach to avoid running tests: using precompiled binary. I tried downloading the 1.4.2 binary from and then afterward ran on the binary, then I got a running Julia interpreter just like that.
We did the same for a while using code similar to this: Unfortunately, we actually sometimes need to patch Julia, so we switched to the julia expressions from source, that I posted earlier.
Thanks that expression works well thanks to . I'm testing it now.
OK so after a long build, I got a working Julia derivation with these references: And this closure size: Which I must say it is satisfying. The question is, is this how we'd want it to be built? Using all of their dependencies and practically non of ours? Some of their dependencies are required to be patched, according to and they also specify that using the OS' libraries is not officially supported? Anyway I'd happy to get help on deciding this.
does this lead to Julia tests passing? I think for every dependency they patch, it is OK to just use their patched version. I guess it could be nice to use a separate build unpatched (but using the exact same version sounds like a likely restriction), but whatever dependency does not work right away can be switched to bundled.


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

I think it did, I've set and the build passed but I haven't inspected the log much, but here it is: Currently produces this log but there's no PR yet as I think there are many makeFlags that should probably be set as well. If anyone feels confident to open a PR with this feel free to ping me for a review. I agree with the idea, but what's bothering me is that it's not absolutely clear what versions are patched and which are not - the docs vs what's actually found in is not totally inline. Also, it seems that some of the patches are old, and were suggested upstream (to the libraries) but they weren't merged there for some reason. I'm still investigating, See My current target is to decide what libraries to use our version vs their version, with the preference to use our version, in order to hopefully reduce closure size due to sharing shared libraries. The idea is to decide this by checking whether the libraries have included the patch Julia suggests, and then whether the library's maintainer has released a new version that includes Julia's maintainers' patch, and whether we ship that new version.
does this lead to Julia tests passing? I think this log is cut short before the interesting part…
I've uploaded it here:
Hmmm. Reading the log does not convince me the tests were run… Pity.
Since 1.5 was just released, the title should probably be updated to be 1.5.
Downside with the patching approach, is users lose the ability to compile against MKL, which has HUGE performance increase (last I saw showed that MKL was ~4x faster at matrix multiplication!!). Would need to also package JuliaPro to get MKL. Of course, anything working nothing working, although would be a shame to lose compilation options.
Says
Thanks garrison, I saw that, but I have a feeling it won't play nicely with Nix...although if we go patching route, perhaps could do that during buildPhase
Are you concerned about specifically or all packages that use BinaryBuilder? There are a lot of them. More on this at
As I understand binary builder, that all happens in userspace, but modifies , which is in /nix/store
The installation instructions for do not seem to require root. My guess is that it stores the modified sysimage somewhere in .


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Am I wrong?
I just tried it with Julia 1.4 installed with Nix, and as I suspected fails to build due to
We need to have a interface - that would support building binary packages, and make the interpreter aware of them. I wish I was a bit more motivated to do this, but upstream disappoints me regarding the humble task of compiling Julia as is, with the right selection of a few system dependencies - no response at all at & . I'm also dis-motivated to explore this aspect, since their build system is of plain makefiles, and they keep patches of dependencies from so long ago, without documenting whether they are needed / used or not...
Nix behind It is a shame to see julia's support in NixOS languish. It seems pretty clear to me that upstream is only interested in supporting the configuration obtained by cloning their repository and typing on a stock Linux distribution. I understand their perspective in many ways, as having julia and all of its packages "just work" requires a lot of care, and building with unsupported configurations is very likely to result in brokenness somewhere in the package ecosystem if not in julia itself. Julia is a bit special in this regard because of its emphasis on performance and also its need to support interfaces to other languages/frameworks that often have weird requirements. I have found that typically, there is very good reason for these patches, even though at times they may not be documented except in git and github history. (Admittedly, I am less involved in upstream than I used to be.)
I think Julia team initially evaluated Nix as their binary distributor () but decided against it—there was a discussion somewhere but can’t find it. IIRC lack of Windows / desire to tie into native pkg management systems were factors. Julia’s does a pretty great job, and uses a solver to properly resolve dependency versions based on constraints. I’ve been incredibly frustrated by the withPackages pattern, at least in python. I constantly run into problems due to nixpkgs ignoring version constraints. There are some other nice advantages to nix of course: binary dependencies are shared across language ecosystems for example, and there are lots of supremely annoying packages (I’m looking at you CUDA...) that Nix makes delightfully easy to install, use, and maintain parallel versions.


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

But until Nixpkgs supports multiple versions across the board, and has a solver baked in, I’m honestly not sure Nix brings enough advantages to bail on Edit: I think the approach done by poetry2nix and Mach-nix are the way to go for Julia packages + nix. yarn2nix is another shining example. I would love to see a solution in this vein—didn’t mean to douse any enthusiasm for people interested in helping improve the Julia situation on NixOS :)
Maybe it is worth to reaching out to Julia Computing folks at to get their attention on ?
We'd probably need to put this information in our attribute sets, just like our Python packages know what deps they need. Hmm that's a bit surprising to hear as the Python ecosystem seems most well organized. Have you ever encountered a real bug with a mismatched version of a dependency with a specific version specified in a package's ? IIRC fails if a version is used and it's not exactly what's available. If you've ever felt there's a certain python package of a certain version missing, have you considered contributing it? Even if not, was it too hard to override it? What do you mean "across the board"? That might be much more harder then it sounds, due to the constraints of Nix it self when being evaluated everytime you run and friends, see It's not a question of whether Nix brings an advantage or not, it's a question of whether there are any Julia packages that are built at other distros imperatively with a , and this produces (or even worse, downloads) shared objects or executables into (not in ), linked to Julia or other Nix deps that do reside in . If the answer is yes, than every Nix user will experience breakage after Julia is updated in his - not necessarily if it's a version bump of Julia, it could be a mere rebuild of Julia by hydra. Yea Mach-nix is an awesome idea well implemented ( thanks for the inspiration :heart:). I've also reached a similar conclusion at . However, this is my opinion for Rust and Go, and I tend to think that for a small ecosystem like Julia, perhaps it'll be too much - it shouldn't be that hard to manage all of these pacakges like Python is managed in Nixpkgs.
I opened
Frequently.


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Especially with Scipy, matplotlib, bokeh, sklearn, tensorflow, pytorch, etc... Often, nixpkgs used to have it until it was updated. Except in very rare circumstances, we do not keep more than one version of a python package around. I have no interest wasting time working around bugs that authors tried to spare me by specifying precise versions. It seems a sort of cognitive dissonance in our next community that we all care so deeply about reproducible builds, but for convenience often disregard the officially supported dependencies. As a result, there are often subtle bugs in software on NixOS that do not appear on other platforms. (Eg x11vnc crashes, shared memory problems, etc). Nix supports crazy high specificity in versioning, well we past semantic versioning down the the bit in many cases. And yet in nixpkgs, by convention, we remove the old version anytime we update. It’s understandable that Hydra cannot build everything, but it’s always bothered me that I have to pin nixpkgs if I want a build to stay functional over 1+ years. is mostly declarative. Of course, Julia is constantly re-compiling code, and until there is true support for precompilation, I don’t see how it’s possible to use nix store. This is due to multiple dispatch. Suppose I wrote a library to do an efficient k-nearest-neighbor query using some fancy free structure. Perhaps the core algorithms simply require a function for your types. When you write this new function, Julia has to compile all the code in the k-nearest neighbor library for this new type. Thus, it is not possible right now to compile a package on its own as the core pattern in Julia involves extending the function of other packages via multiple dispatch. You can only compile a package in context of the code that is running. Therefore, the Nix store approach is not appropriate. See
I see. You are talking about "authors" of Nixpkgs' expressions? I'm still a bit perplexed, as I earlier said, and correct me if I'm wrong: should fail if is used in , and the exact version is not available. Sometimes (), we do hardcode such version requirement changes in our expressions, but hopefully that's done only when it's justified.


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

I agree (maybe a bit ). Generally I think, every dep's version related issue should be handled by someone like you, who's familiar with python packages you use. I'd at least (open PRs) to fix the issues I encounter :). I see. I guess the situation is more complex than I thought, but I don't think I'd be able to form a strong opinion until I'll get a Julia interpreter from an expression I'm satisfied with. Thanks for the link :).
Unfortunately, this pattern is done constantly (including in my own contributions!). The problem is that, except an extremely rare cases like tensorflow, nixpkgs does not allow multiple versions of same python package to co-exist. Every time we update a package, we remove the previous version from nixpkgs. Confounding this issue, we often disable tests because sometimes the effort is just too high when developers bake in assumptions that aren’t compatible with the Nix ethos (for some reason this seems to happen more with tests then source code...). The most frequent cause of failure is the code needs to download something to run the test. (I’ve tried to lobby in the past that the test phase should be permitted to have Internet access as long as it doesn’t modify /nix/store, but I digress). In any case, the end result is that using a python package on Nix typically means you aren’t using the exact dependencies that upstream declared, and you’re more likely to have a package that despite having changes in dependencies has never had the test run. Thus, amazingly, I’ve had more luck with Julia packages working on NixOS than Python when all other binaries are present in environment.
I don't think there's a strong policy in our Python ecosystem against multiple versions of packages - if this is what upstream recommends. Anyway, the whole topic is out of scope for this issue. Feel free to open a new issue and cc me and who's working hard to ship a 20.09 release.
Yes, sorry getting a little off topic here. I mainly mention it to suggest that our efforts in Julia that start from scratch Can learn from these issues. I’m not too familiar with the new binary builder, but was quite nice in that it would first search for libraries before attempting to install.


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

See this issue for some context: Note that a core Julia dev gave a pretty great endorsement on Nix (albeit back in 2014): I think it might be most productive to do this development outside of nixpkgs, and do it in Julia to hook in with nixpkgs as needed. That way users could seamlessly use Pkg in Julia. I’d love to and have it just work instead of the current hack that I wrote that a lot of people seem to be using ()
Short summary of the Discourse thread: for LLVM and libuv it is essential to use the patches/forks. For other packages it is probably unnecessary to use the exact version specified by upstream.
Thanks for being there with me :). I think I'm gonna work on this once we are through with , to avoid merge conflicts.
TIL Guix manages to package Julia 1.4.1: What's interesting, is that they but they build it with Julia's LLVM patches fetched from the internet - they don't rely on Julia's build system to build it's own LLVM. For similar dependencies which the real system's version can't be used, they do the same. I think we should try to copy this approach.
FWIW I did that in Fedora originally, but I stopped. Since LLVM makes breaking releases very quickly, you'll probably want to move to a new version that Julia doesn't support quite soon.
Maybe I don't understand, but why should I move to an LLVM version that julia doesn't support? Also, aren't the and versions don't introduce breaking changes between minor releases? We could stick to since that's what Guix does and I think Julia uses this version as a base too.
I don't really know how NixOS works, hence the "FWIW". If you used versioned LLVM packages and keep older major versions then it's probably OK.
Just offering a user perspective: Julia provides a package manager that provides mostly reproducible (in a practical/scientific reproducibility sense rather than a bit-identical sense) environments easily from manifests. Increasingly, these environments are isolated from the host OS by binary packages for dependencies being served by Julia. I don't want Nix to manage dependencies that can handle for me: Julia already handles those excellently and conveniently. I just want Nix to handle the (usually few) system dependencies.


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

What I would like as a NixOS user is for Nix to provide me with a working Julia 1.5 derivation that provides: julia, a FHS wrapper or something providing compatible versions of the few things that Julia's binary packages need (just libc, libstdc++, libgfortran; I think. ). When I say "compatible", I mean that these libraries should work with the binaries and with the julia binary provided by Nix. Not all Julia packages are BinaryBuilder-ised yet, so I'd also want an easy way to specify that I want compatible versions of other packages installed (e.g. Qt, cairo, etc). For packages that need python, I don't know if I'd like Julia or Nix to handle installing and managing that. The simplest approach would be to tell Julia to do it (there is pretty good support in Julia for distributing isolated environments of python + packages + dependencies; better than in , imo). I don't know how doable any of that is in Nix, just describing what a good outcome would look like to me.
I think this is quite doable. I would propose that we add a new package, , that is a "batteries included" build that contains system libraries for all common Julia packages. Would this approach work for BinaryBuilder? I haven't used this yet. If not, we could fall back to a FHSuserenv, but I'm reluctant to do so if at all avoidable as there are outstanding nix bugs () that create seg faults in some heavy data processing workflows.
I think that is a good proposal and I think it will work with BinaryBuilder packages (e.g. SDL2_jll). In any case, some approach that works with BinaryBuilder packages should be found because those are a critical part of the Julia environment now :) Some important packages (e.g. GR) still want to build and install their own software dynamically, and that doesn't work well in Nix, but most of those can plausibly move to the BinaryBuilder system (PR for GR ), so I think letting those be broken would be tolerable (and a big improvement over the status quo of Julia on nix). Perhaps we can get something working quickly by just patchelf'ing the official Julia builds for now? (I don't understand how all of this stuff works!)


Question: inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Is there anything presently blocking just getting julia 1.5 into nixpkgs? I don't care about ecosystem working with nixpkgs, just a good ol' fashioned julia install.
yes, see
If you just want Julia and don't mind about binary packages breaking you can just download Julia from the official site and patchelf it. On Sun, 4 Oct 2020, 09:32 Tyler Benster, <:
On the there was also the idea floated to patch to patchelf dynamically loaded binary dependencies.
Guix has a Julia package and it works quite well. Perhaps some ideas can be borrowed from there: It'd be really useful to get Julia working on Nix. It's the only big outstanding thing that doesn't work and prevents me from migrating some servers in my organization.
I tried to copy their expressions in and it doesn't work yet, but there's also another seemingly working attempt by at .
So, do we want anything else now that 1.5.3 is packaged (:greenheart: ? I think we: 't need clean up the expressions a bit - not use the file if it's not shared. I did (2) along with the julia_10 fix in As for (1) I will need a bit of feedback.
I guess some people like me still use julia_13 via test-disabling overrides, so a bit of time after 1.5 reaches channels for smooth transition could make sense?
Maybe backport 1.5 to 20.09?
OK so I disabled the tests for julia13 in and made the default there as well. All merged pull requests referenced here should be backported.


Question: , cmake , qttools , wrapQtAppsHook <ins> , qtbase , qtwayland </ins> , qtsvg }:

low priority qt6.qtdeclarative is a large package, so it should be excluded for non-GUI qt apps () currently, when i build a package with and empty buildInputs, it pulls qt6.qtwayland qt6.qtdeclarative qt6.qtshadertools the problem is wrapQtAppsHook and its deps and qtwayland pulls qtdeclarative the problem is fixed by removing from deps wrapQtAppsHook should use only the declared buildInputs disabling wrapQtAppsHook (dontWrapQtApps = true) is no option, as also CLI qt apps need the qt wrapper qtwayland is there, so that users dont need to add it to buildInputs assuming that all qt apps are GUI apps im in favor of making this consistent with cmake so that all GUI apps must add qtwayland to buildInputs CLI qt app: GUI qt app: since cc
I'm in favour of this change, but the proportion of qt cli app night be relatively small, and it's not immediately clear that qtwayland should be if the build log yields Qt6::Widgets is missing.
Actually we are abusing qtwayland as a shortcut to bringing in qtdeclarative, this should be fixed too.
we could patch the cmake message to "please add qtdeclarative to your propagatedBuildInputs" the alternative would be to add a flag, but thats more obscure than buildInputs
Adding the lines to nixpkgs manual is sufficient.
By the way, is not only needed to pull in , but it's required for all GUI apps so that they work seamlessly on X11 or Wayland.


Question: <del> { lib , stdenvNoCC , fetchzip , fetchFromGitHub , butler , electron , steam-run , makeWrapper , copyDesktopItems , makeDesktopItem </del> <ins> { lib, stdenvNoCC, fetchzip, fetchFromGitHub, electron, steam-run, makeWrapper, copyDesktopItems, makeDesktopItem, </ins> }: <del> stdenvNoCC.mkDerivation rec { pname = "itch"; version = "26.1.3"; # TODO: Using kitch instead of itch, revert when possible src = fetchzip { url = "https://broth.itch.ovh/kitch/linux-amd64/${version}/archive/default#.zip"; </del> <ins> let version = "26.1.9"; butler = fetchzip { url = "https://broth.itch.zone/butler/linux-amd64/15.21.0/butler.zip"; </ins> stripRoot = false; <del> hash = "sha256-FHwbzLPMzIpyg6KyYTq6/rSNRH76dytwb9D5f9vNKkU="; </del> <ins> hash = "sha256-jHni/5qf7xST6RRonP2EW8fJ6647jobzrnHe8VMx4IA="; </ins> }; itch-setup = fetchzip {

Package name: itch Latest released version: 26.1.3 Current version on the unstable channel: 26.1.3 Current version on the stable/release channel: 26.1.3 <!-- 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! --- The current version is broken since butler is marked broken 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]:
The latest version on seems to be 26.1.3 which is used in the package.
There is 26.1.5 as a source code , but current package uses binaryBytecode


Question: va_end (ap); return res; <ins> diff --git a/src/builder-source-archive.c b/src/builder-source-archive.c index 3c694e57..0de62318 100644 </ins> --- a/src/builder-source-archive.c +++ b/src/builder-source-archive.c @@ -443,7 +443,7 @@ tar (GFile   *dir,

Describe the bug flatpak-builder for some reasons can't use rofiles-fuse To Reproduce Steps to reproduce the behavior: build any app using flatpak-builder Expected behavior flatpak-builder should use rofiles-fuse. Screenshots Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
installing solve this problem so maybe should be ?
We patch the paths to the executables to be hardcoded, so the program doesn't have to rely on something like ostree being installed. I believe one path isn't hardcoded with the current patch That looks it up in PATH, probably why it was working once you installed it.
cc
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 .
should fix that issue.


Question: buildInputs = [ openssl zstd ] ++ lib.optionals stdenv.isDarwin [ zlib libiconv Security ] ++ lib.optionals (stdenv.isDarwin && stdenv.isx86_64) [ <del> Foundation </del> ( # Pull a header that contains a definition of proc_pid_rusage(). # (We pick just that one because using the other headers from `sdk` is not

Steps to reproduce the behavior: nix on x86_64-darwin experimental features nix-command and flakes to install nushell v0.75.0 via . Please run and paste the result.
I can confirm the bug, the following PR could resolve it.
that is great news! I am hopeful that can resolve it. I see that you marked this as resolved by . However, this does not seem to have resolved the issue for me. I am still receiving the same error when trying to build :
The ofborg test did pass, see Maybe you have to build it on master? Also, I don't think will help, as the author of that PR.
Hmm, after upgrading nix and updating my nixpkgs-unstable channel, I'm still receiving the same error.
You have to wait for the commit to arrive on nixpkgs-unstable.
Thank you your PR resolved it. the fix is in the nixpkgs-unstable channel. Much appreciated!


Question: # Symlink to bin mkdir -p $out/bin <del> ln -s $out/lib/Signal/signal-desktop $out/bin/signal-desktop </del> <ins> ln -s $out/lib/Signal/signal-desktop $out/bin/signal-desktop-unwrapped </ins> runHook postInstall ''; <ins> # Required for $SQLCIPHER_LIB which contains "/build/" inside the path: noAuditTmpdir = true; </ins> preFixup = '' <ins> export SQLCIPHER_LIB="$out/lib/Signal/resources/app.asar.unpacked/node_modules/better-sqlite3/build/Release/better_sqlite3.node" test -x "$SQLCIPHER_LIB" # To ensure the location hasn't changed </ins> gappsWrapperArgs+=( --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ stdenv.cc.cc ] }" <ins> --prefix LD_PRELOAD : "$SQLCIPHER_LIB" </ins> ${customLanguageWrapperArgs} )

Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended


Question: pname = "flutter"; src = fetchurl { url = "https://storage.googleapis.com/flutter_infra_release/releases/${channel}/linux/${filename}"; <del> sha256 = "12ycz7iasrc9p9c6zr95l6llyji3za43gsx8cmr2kjfiv23bcrv2"; </del> <ins> sha256 = "sha256-sSz/owGdCMB5b9+cAWvLkrfFcIIq5665Xopd4JKv1G4="; </ins> }; patches = getPatches ./patches; };

name: flutter current version: 2.5.1 desired version: 2.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
done on


Question: outputs = [ "out" "dev" "man" ]; <del> patches = [ (substituteAll { src = ./fix-paths.patch; zenity = gnome.zenity; }) ]; </del> src = fetchFromGitHub { owner = "linuxmint"; repo = pname;

Restart cinnamon from the panel freezes the desktop, from the journal you will find cinnamon crashes. click the panel trouble shooting cinnamon No crash.
Okay, I guess I need upstream help for this, going to forward this to upstream...


Question: rapidfuzz-cpp ]; <ins> NIX_CFLAGS_COMPILE = lib.optionals (stdenv.cc.isClang && stdenv.isDarwin) [ "-fno-lto"  # work around https://github.com/NixOS/nixpkgs/issues/19098 ]; </ins> propagatedBuildInputs = [ rapidfuzz ];

Steps to reproduce the behavior: python3Packages.rapidfuzz Introduced in . Please run and paste the result.
It appears that cmake selects an incorrect linker. I am currently unsure what's the reason for this. Following I think I might need to set: I have zero experience with nix os + no access to a mac. Is there any way to patch in the build system here to check whether this solves the issue?


Question: pathtools = callPackage ../development/python-modules/pathtools { }; <ins> pathvalidate = callPackage ../development/python-modules/pathvalidate { }; </ins> patiencediff = callPackage ../development/python-modules/patiencediff { }; patool = callPackage ../development/python-modules/patool { };

Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. 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. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:


Question: <ins> { lib, stdenv, fetchurl, fetchpatch }: stdenv.mkDerivation rec { pname = "libamplsolver"; version = "20211109"; src = fetchurl { url = "https://ampl.com/netlib/ampl/solvers.tgz"; sha256 = "sha256-LVmScuIvxmZzywPSBl9T9YcUBJP7UFAa3eWs9r4q3JM="; }; patches = [ # Debian provides a patch to build a shared library (fetchpatch { url = "https://sources.debian.org/data/main/liba/libamplsolver/0~20190702-2/debian/patches/fix-makefile-shared-lib.patch"; sha256 = "sha256-96qwj3fLugzbsfxguKMce13cUo7XGC4VUE7xKcJs42Y="; }) ]; installPhase = '' runHook preInstall pushd sys.`uname -m`.`uname -s` install -D -m 0644 *.h -t $out/include install -D -m 0644 *.so* -t $out/lib install -D -m 0644 *.a -t $out/lib popd runHook postInstall ''; meta = with lib; { description = "A library of routines that help solvers work with AMPL"; homepage = "https://ampl.com/netlib/ampl/"; license = [ licenses.mit ]; platforms = platforms.linux; maintainers = with maintainers; [ aanderse ]; }; } </ins>

A clear and concise description of what the bug is. The package doesn't include a folder. I am looking for a version of which includes the executable. Are we building the package incorrectly such that it doesn't include a binary? Any and all help/advice is much appreciated :bow: Steps to reproduce the behavior: output - notice there is no folder A clear and concise description of what you expected to happen. I want the executable. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- might know something about this? :man_shrugging:
was the binary there before On a quick note: I have never used , so I am not familiar with the package. It seems that the package also needs an update:
It appears that the binary requires AMPL, a commercial package, which is not packaged in nixpkgs. See: https://coin-
ah, I understand. Thank you.


Question: src = fetchurl { url = "https://www2.ati.com/drivers/linux/radeon-crimson-15.12-15.302-151217a-297685e.zip"; <del> sha256 = "0n0ynqmjkjp5dl5q07as7ps3rlyyn63hq4mlwgd7c7v82ky2skvh"; curlOpts = "--referer http://support.amd.com/en-us/download/desktop?os=Linux+x86_64"; </del> <ins> sha256 = "704f2dfc14681f76dae3b4120c87b1ded33cf43d5a1d800b6de5ca292bb61e58"; curlOpts = "--referer https://www.amd.com/en/support"; </ins> }; hardeningDisable = [ "pic" "format" ];

Maybe it's a problem with the ? Don't seem so. I can also not download it manually with curl: (i get a 0 byte file) But i can download it using a browser from the website. But the hash is also different: So they prevent us from downloading the file using something else than their website. Maybe the referer is not enough now? system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:


Question: (mkFlag true                      "generate-man-pages") ]; <ins> passthru.tests = { nixos-rsyslogd = nixosTests.rsyslogd; }; </ins> meta = { homepage = https://www.rsyslog.com/; description = "Enhanced syslog implementation";

Describe the bug Test  is broken on Master To Reproduce Steps to reproduce the behavior: Expected behavior For the test to pass Additional context I've bisected the problem to this commit:
Thank you for opening this :sparkles:
In that case let's it.
That is weird. How does depend on rsyslog?
This test is kind of flaky, there's some chance I incorrectly bisected it?
I'm bisecting again starting at
going to plug :grin: At a glance I don't see rysyslog having any relation, and likely if the tests are flakey enough bisecting can't give reliable results.
I didn't use that tool because I was bisecting by running the test thrice and only if all fail considering it a bad commit :P
cc. maybe add a flag to :P
That kind of unforseen usecase is exactly why nix-bisect is not just a tool, but a library ;) So you could write your own bisect script in python (a much more pleasant experience than doing so in bash). I may add that feature to the CLI at some poing though, since its probably a pretty common usecase. would probably be a better name, since we really want a minimum number of tries. Feel free to file an issue against :)
I tried bisecting again, but I think this result is also nonsense:
Core of the issue seems to be this:
I don't know – locally I'm getting this :arrow_up: error even on which (I tried several times).
Careful (manual) bisect lead me to a surprising result: I'll try a few more experiments now. Many my steps failed for other reasons (e.g. libselinux not building), so I suspect that's where you were led astray. I did 2-3 attempts on every step to be surer, but I found no non-determinism on my machine.
I had quite a few steps where the first attempt at building failed, but the second one succeeded, I was bisecting manually with this:
I re-confirmed that reverting that commit atop master () fixes the test for me. (Still no idea why so far.)
cc for the linux config change
Narrowed down just to the kernel option. I don't know... maybe the JIT has some bad interaction with the VM.


Question: (mkFlag true                      "generate-man-pages") ]; <ins> passthru.tests = { nixos-rsyslogd = nixosTests.rsyslogd; }; </ins> meta = { homepage = https://www.rsyslog.com/; description = "Enhanced syslog implementation";

For now I suppose I'll push a revert of that single option, unless someone suggests a better idea very soon.
Sounds good to me


Question: sed -i '0,/from numpy.distutils.core/s//import setuptools;from numpy.distutils.core/' setup.py ''; <ins> # First test: RuntimeWarning: Mean of empty slice. # Second: SyntaxError: invalid syntax. Due to wrapper? # Third: test checks permissions prePatch = '' substituteInPlace scipy/stats/tests/test_stats.py --replace "test_chisquare_masked_arrays" "remove_this_one" rm scipy/linalg/tests/test_lapack.py substituteInPlace scipy/weave/tests/test_catalog.py --replace "test_user" "remove_this_one" ''; </ins> inherit (support) preBuild checkPhase; <ins> patches = [../development/python-modules/scipy-0.16.1-decorator-fix.patch]; </ins> setupPyBuildFlags = [ "--fcompiler='gnu95'" ]; meta = {

As noted by scipy uses the wrong tests. Instead of running its own test-suite, it runs that of numpy. This is because accidentally pkgName was set to in
Most errors are which are harmless according to
The 12 errors that are encountered are in fact 11 deprecation warnings, and one syntax error in a test when setting PYTHONPATH.


Question: <ins> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-custom-packages"> <title>Adding Custom Packages</title> <para> It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs: </para> <programlisting> $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs </programlisting> <para> Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <xref linkend="opt-environment.systemPackages" />, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ pkgs.my-package ]; </programlisting> <para> and you run <literal>nixos-rebuild</literal>, specifying your own Nixpkgs tree: </para> <programlisting> # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs </programlisting> <para> The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <literal>configuration.nix</literal>: </para> <programlisting language="bash"> environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; }; in [ my-hello ]; </programlisting> <para> Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ (import ./my-hello.nix) ]; </programlisting> <para> where <literal>my-hello.nix</literal> contains: </para> <programlisting language="bash"> with import <nixpkgs> {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; } </programlisting> <para> This allows testing the package easily: </para> <programlisting> $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! </programlisting> </section> </ins>

This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.


Question: <ins> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-custom-packages"> <title>Adding Custom Packages</title> <para> It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs: </para> <programlisting> $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs </programlisting> <para> Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <xref linkend="opt-environment.systemPackages" />, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ pkgs.my-package ]; </programlisting> <para> and you run <literal>nixos-rebuild</literal>, specifying your own Nixpkgs tree: </para> <programlisting> # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs </programlisting> <para> The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <literal>configuration.nix</literal>: </para> <programlisting language="bash"> environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; }; in [ my-hello ]; </programlisting> <para> Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ (import ./my-hello.nix) ]; </programlisting> <para> where <literal>my-hello.nix</literal> contains: </para> <programlisting language="bash"> with import <nixpkgs> {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; } </programlisting> <para> This allows testing the package easily: </para> <programlisting> $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! </programlisting> </section> </ins>

This tracks the conversion of from Docbook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.
I opened a PR for and : PTAL, thanks in advance for reviewing :-)


Question: <del> { lib, buildFHSUserEnv, steam </del> <ins> { stdenv, lib, writeScript, buildFHSUserEnv, steam , steam-runtime, steam-runtime-i686 ? null </ins> , withJava ? false , withPrimus ? false , nativeOnly ? false

This weekend I tried these games, all deadlocked in the menu or character selection. Nyheim Oh...Sir! The Insult Simulator Reigns Unturned (free to play) You don't have to be worried to waste money in case you want to test a game. I have had no problem when requesting refunds, just go to I have played these games and found no issues with them: Dota 2 Counter-Strike TIS-100 World of goo Faster Than Light You Must Build a Boat Risk of Rain System: (NixOS: , Ubuntu/Fedora: , ...) 03pre99759. (Gorilla) Nix version: (run ) nix-env (Nix) 1.11.6 Nixpkgs version: (run ) "17.03pre99759." Integrated graphics card, 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
This is normal with steam on nixos unfortunately. There are many steam games that don't work for various reasons, unfortunately many linux steam game developers only make sure their games run on ubuntu and don't really care about relying only on dependencies from the steam runtime. Some games don't play nice with certain graphics cards or drivers as well. If you want to get a particular game working (I can list 150 games that work under nixos with nvidia card and drivers at least) then you'll need to do some work, or at least post any relevant logs from the game/steam so people can actually help you solve the problem. That is assuming that they own the game. :)
There's a slowly-growing list of extra dependencies in the Steam package. If you can figure out what's missing, you can add it there; e.g. as in
I don't have enough motivation to actually buy games for the sole purpose of fixing them and then refunding, sorry. Nevertheless, I'm happy to help if you can post logs and/or s -- those two are the most helpful for determining FHS-related problems.


Question: }; in buildPythonPackage ( rec { name = "numpy-${version}"; <del> version = "1.10.1"; </del> <ins> version = "1.10.2"; </ins> src = pkgs.fetchurl { url = "mirror://sourceforge/numpy/${name}.tar.gz"; <del> sha256 = "8b9f453f29ce96a14e625100d3dcf8926301d36c5f622623bf8820e748510858"; </del> <ins> sha256 = "23a3befdf955db4d616f8bb77b324680a80a323e0c42a7e8d7388ef578d8ffa9"; </ins> }; disabled = isPyPy;  # WIP


Question: buildInputs = [ qtbase <ins> rtaudio_6 </ins> rtmidi ] ++ lib.optionals stdenv.hostPlatform.isLinux [ qtwayland ] ++ lib.optionals (lib.versionAtLeast qtbase.version "6.0") [ qt5compat <del> ] ++ rtaudio.buildInputs; </del> <ins> ]; </ins> qmakeFlags = [ <del> # we don't have RtAudio 6 yet: https://github.com/NixOS/nixpkgs/pull/245075 # "CONFIG+=system_rtaudio" </del> <ins> "CONFIG+=system_rtaudio" </ins> "CONFIG+=system_rtmidi" ];

Package name: Latest released version: 5.2.0 Current version on the unstable channel: 5.2.0 Current version on the stable/release channel: 5.2.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Pending on


Question: warnings.warn("NIXOS_INSTALL_GRUB env var deprecated, use NIXOS_INSTALL_BOOTLOADER", DeprecationWarning) os.environ["NIXOS_INSTALL_BOOTLOADER"] = "1" <ins> # flags to pass to bootctl install/update bootctl_flags = [] if "@canTouchEfiVariables@" != "1": bootctl_flags.append("--no-variables") if "@graceful@" == "1": bootctl_flags.append("--graceful") </ins> if os.getenv("NIXOS_INSTALL_BOOTLOADER") == "1": # bootctl uses fopen() with modes "wxe" and fails if the file exists. if os.path.exists("@efiSysMountPoint@/loader/loader.conf"): os.unlink("@efiSysMountPoint@/loader/loader.conf") <del> flags = [] if "@canTouchEfiVariables@" != "1": flags.append("--no-variables") if "@graceful@" == "1": flags.append("--graceful") subprocess.check_call(["@systemd@/bin/bootctl", "--esp-path=@efiSysMountPoint@"] + flags + ["install"]) </del> <ins> subprocess.check_call(["@systemd@/bin/bootctl", "--esp-path=@efiSysMountPoint@"] + bootctl_flags + ["install"]) </ins> else: # Update bootloader to latest if needed available_out = subprocess.check_output(["@systemd@/bin/bootctl", "--version"], universal_newlines=True).split()[2]

During systemd-boot update step attempts to touch EFI variables, even when is set to . Steps to reproduce the behavior: NixOS 21.05 with systemd-boot and to NixOS 21.11 () switch fails with: An error is just an indication of update trying to touch EFI variables. (I have EFI vars touching disabled on that system because of some unrelated firmware breakage) Manually running properly finishes, further switches work fine. systemd-boot update should not touch EFI variables during upgrade. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
I had a similar issue which I fixed by running "sudo nixos-rebuild --install-bootloader switch"
The fix for this got reverted in


Question: { stdenv, fetchFromGitHub , autoreconfHook, docbook2x, pkgconfig , gtk3, dconf, gobject-introspection <del> , ibus, python3 }: </del> <ins> , ibus, python3, wrapGAppsHook }: </ins> stdenv.mkDerivation rec { <del> name = "ibus-table-${version}"; </del> <ins> pname = "ibus-table"; </ins> version = "1.9.21"; src = fetchFromGitHub {

Input methods based on do not work as of , at least on my machine as it is now. Upstream, I think the change comes from , which made start using . Other IBus input methods still work (mozc, hangul, Anthy). It feels as if this should have an easy solution amounting to “do what worked for other packages using ”, but I can't work out what it is that they do that makes them work. It's also believable that from is not being run. 1) 2) Switch to an -base input method (example: from ). Then, the input method is not changed, and the rest of the output is: Alternatively: 1) 2) Try to open the preferences for an -based input method. No preferences are shown. The following error message is printed. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
So, adding to stops the error message, but preference dialogs still do not show and all of the problems with actually using remain.
How did you install and activate the input method? i18n.inputMethod.enabled = "ibus"; = with ; [ table ]; does not seem to be enough.
Change to (ibus-table acts like a framework within a framework, and provides some actual input methods using it). Then, use -Input Method -Add -More... -Others -IPA-X-SAMPA (and maybe another to see the switching behaviour). Then, switch using the key combination from the preferences (I forget what the default is; maybe Ctrl-space). Expected behaviour from IPA-X-SAMPA includes ↦ and ↦ .
Have you managed to reproduce this problem?
I can confirm your observations in Maybe this could be the culprit:
I've found what appears to be a solution, but it's in some sense weird. Looking at other input methods, they seem to use rather than . Replacing the latter with the former on seems to fix the issue. I have no idea, though, why isn't broken on other platforms. is the new package description.


Question: sha256 = sha256; }; <del> includeScript = pkgs.writeText "include.php" '' </del> <ins> prePatch = '' dos2unix ./rainloop/rainloop/v/1.16.0/app/libraries/MailSo/Base/HtmlUtils.php ''; patches = [ ./fix-cve-2022-29360.patch ]; postPatch = '' unix2dos ./rainloop/rainloop/v/1.16.0/app/libraries/MailSo/Base/HtmlUtils.php ''; includeScript = writeText "include.php" '' </ins> <?php /**

via In short: rainloop, a php-based webmail client, features a trivially exploitable stored xss vulnerability. Upstream is unresponsive, and seem to have ceased development. This page explains how the XSS works and proposes an unofficial patch: Example of an other distro applying this very patch:


Question: { lib, appimageTools, fetchurl, nodePackages }: let pname = "flexoptix-app"; <del> version = "5.11.0"; name = "${pname}-${version}"; </del> <ins> version = "5.12.1"; </ins> src = fetchurl { <del> name = "${name}.AppImage"; </del> <ins> name = "${pname}-${version}.AppImage"; </ins> url = "https://flexbox.reconfigure.me/download/electron/linux/x64/FLEXOPTIX%20App.${version}.AppImage"; <del> hash = "sha256-Nj6S53b4w84qppkGB7lMpJhJlxifaD4acPryuZxY7cM="; </del> <ins> hash = "sha256-ugnJcSFgEEPJ9qxqmRGgW1fraE4E/HbbxpK/00TXPmw="; </ins> }; udevRules = fetchurl {

name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.


Question: in stdenv.mkDerivation rec { <del> srcVersion = "apr24a"; version = "20240401_a"; </del> <ins> srcVersion = "sep24a"; version = "20240901_a"; </ins> pname = "gildas"; src = fetchurl {

Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: LUA_PATH  = "${lgi}/share/lua/${lua.luaversion}/?.lua;;"; postInstall = '' <del> # Don't use wrapProgram or or the wrapper will duplicate the --search </del> <ins> # Don't use wrapProgram or the wrapper will duplicate the --search </ins> # arguments every restart mv "$out/bin/awesome" "$out/bin/.awesome-wrapped" makeWrapper "$out/bin/.awesome-wrapped" "$out/bin/awesome"

Cc: First of all, thanks to everyone for working on NixOS. Awesome 4.3 has a module called , it allows It can be used for theming, as shown in . However, the current build does not include the typelib files needed by the module making it unusable. The  implementation uses lgi to obtain via gobject-introspec return require('lgi').Gtk Since the current build does not include the typelib files needed, the above call fails. After some experimentation, I found out that both and are needed. For example: and try to load Gtk: fails with (the package that actually includes the typelib file) and add the folder to the environment variable: fails with and add it to and finally loads. Awesome as window manager to load the example gtk theme awesome the warnings issues by Awesome: I suggest that both and are as build inputs to the awesome package, I tried this out and it actually works. The catch is that the closure size increases by 123.9M: build awesome without gtk3-x11 and atk -99.6M build awesome with gtk3-x11 and atk -223.4M So, instead of adding the packages unconditionally, we could add an optional flag, like e.g. , defaulting to false. In this way, one could always build awesome and add it to . Ideally one could even add something like to the top level , a bit like : If a decision is made, I'd be happy to submit a PR. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: awesome 4.3 (Too long) Compiled against Lua 5.2.4 (running with Lua 5.2) D-Bus support: execinfo support: xcb-randr version: 1.6 LGI version: 0.9.2
It should not be necessary to use , should work just fine. See for docs on , which will populate the environment variable automatically.
Thanks, I'll have a look. For the record, I used because that's where told be the typelib files where. I am still keen on hearing what the correct solution would be regarding how to add support (closure size, optional arguments etc.). Thanks.
thanks for our suggestions.


Question: LUA_PATH  = "${lgi}/share/lua/${lua.luaversion}/?.lua;;"; postInstall = '' <del> # Don't use wrapProgram or or the wrapper will duplicate the --search </del> <ins> # Don't use wrapProgram or the wrapper will duplicate the --search </ins> # arguments every restart mv "$out/bin/awesome" "$out/bin/.awesome-wrapped" makeWrapper "$out/bin/.awesome-wrapped" "$out/bin/awesome"

Here are my thoughts: seems to work as well, the closure size is 222.9M instead of 223.4M seems quite conveniet, but awesome needs additional options in the wrapper and it's unclear to me whether we could do that after introducint uses that seems to have negative effects, see so we may have to look for alternative solutions anyway (Awesome does not seem to use much of GTK anyway as it's not a GTK app)
how could it shrink? can use as described in the doc PR to add more options. , I am aware of that but other than hardcoding the typelibs like we do in GNOME Shell extensions, we do not have anything better at the moment. See for deeper analysis.
¯()/¯ maybe it's got less dependencies built than the one? I see, I somehow missed that. It seems that works OK (I am using this in an overlay on NixOS waiting for the patches to land in the stable channel): In the end, AwesomeWM should not need the whole of gtk, I think that gtk should be made optional so one can turn it on or off. Thanks, I did notice that and I'll keep an eye on it


Question: ++ cfg.sessionPath; # Fonts. <del> fonts.packages = mkDefault [ </del> <ins> fonts.packages = [ </ins> pkgs.noto-fonts pkgs.hack-font ];

I enabled budgie: = true; I opened Budgie Desktop Settings. ! The font is "None", which is wrong. I expect a font be set. I am on a (neraly) freshly installed NixOS. It would be nice if a "Reset to default" button would be there (or some NixOS "magic" for configuring Budgie), but I did not found anything at Default fonts are listed at


Question: ++ optional langAda ../gnat-cflags.patch ++ optional langFortran ../gfortran-driving.patch ++ optional (targetPlatform.libc == "musl") ../libgomp-dont-force-initial-exec.patch <del> ++ optional (!crossStageStatic && targetPlatform.isMinGW) (fetchpatch { url = "https://raw.githubusercontent.com/lhmouse/MINGW-packages/${import ../common/mfcgthreads-patches-repo.nix}/mingw-w64-gcc-git/9000-gcc-${majorVersion}-branch-Added-mcf-thread-model-support-from-mcfgthread.patch"; sha256 = "1c449jgm1vx9g4kv82bxmvlgrwb8f6kwkl0gqmjlmhf7f4hjy2nr"; }); </del> <ins> # Obtain latest patch with ../update-mcfgthread-patches.sh ++ optional (!crossStageStatic && targetPlatform.isMinGW) ./Added-mcf-thread-model-support-from-mcfgthread.patch; </ins> javaEcj = fetchurl { # The `$(top_srcdir)/ecj.jar' file is automatically picked up at

Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.