Question: ./config/fonts/fontdir.nix ./config/fonts/ghostscript.nix ./config/fonts/packages.nix <del> ./config/gnu.nix </del> ./config/gtk/gtk-icon-cache.nix ./config/i18n.nix ./config/iproute2.nix

When I set in , the rebuild fails as is no longer a valid option. Steps to reproduce the behavior: thrown: The option definition /nix/store/bfg7xzgvbhxhs7vnl7lynaxmjhmvc4j0-' no longer has any effect; please remove it. See the 16.09 release notes for more information. should not fail. - - Please run and paste the result.
Having had a look at that module (), IMO it should just be removed. ? really?
The module in general looks outdated and incomplete. I share the opinion of either dropping it or actually correcting and finishing it.
Other question is when you look at the history they removed lsh 7 years ago because it was unmaintained, but then the commit got reverted later?
This module doesn't make sense at all. GNU stuff and non-GNU ones usually can't fully replace each other, and it's up to the users to decide which one to use.


Question: stdenv.mkDerivation rec { pname = "xreader"; <del> version = "3.4.3"; </del> <ins> version = "3.4.4"; </ins> src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> sha256 = "sha256-GkJo/wc5StyeQv0pv5XK0Qy3o8EGpfPYY8gOMq0Afgs="; </del> <ins> sha256 = "sha256-uYnQE1GjkUxYlvXSJNmvr6q4OdvAWgv8HqTXk0KkRQM="; </ins> }; nativeBuildInputs = [

I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. 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.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.


Question: stdenv.mkDerivation rec { pname = "xreader"; <del> version = "3.4.3"; </del> <ins> version = "3.4.4"; </ins> src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> sha256 = "sha256-GkJo/wc5StyeQv0pv5XK0Qy3o8EGpfPYY8gOMq0Afgs="; </del> <ins> sha256 = "sha256-uYnQE1GjkUxYlvXSJNmvr6q4OdvAWgv8HqTXk0KkRQM="; </ins> }; nativeBuildInputs = [

I have user-installed Cinnamon applets, desklets, extensions, themes, which have been installed in the home folder by a different OS (as far as i remember). Many of them work under NixOS (some do not: ). However, i cannot update them. When i try, i get the message: The same happens if i try to install a new applet. Steps to reproduce the behavior: up Cinnamon desktop on NixOS and log in. to install an applet. Should be able to install and update user-installed applets, desklets, extensions, themes. ! I am just beginning to switch over to Cinnamon from GNOME 3 (having been fed up with GNOME, especially under NixOS).
Installing [][gettext] that provided solved the issue. Shouldn't be a dependency of Cinnamon desktop then? [gettext]:


Question: install_name_tool -change libblas.dylib ${blas}/lib/libblas.dylib $out/lib/libarpack.dylib ''; <ins> # disable stackprotector on aarch64-darwin for now # https://github.com/NixOS/nixpkgs/issues/127608 hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "stackprotector" ]; </ins> meta = { homepage = "https://github.com/opencollab/arpack-ng"; description = ''

Reported via email by a Nix user without a GitHub account. Build fines. In the attempt to build GNU octave for aarch64 darwin. Maintainer information:
I would suggest opening an issue but I guess that's not an option.
Perhaps, but it seems peculiar that the user "is not able to compile a simple test program" - as if there's a bug in our compiler . Related issues: Perhaps the user should try this edit to Nixpkgs: So even on Darwin the compiler that will be used will be gcc, to play nicely with gfortran.
The suggestion to use is good; I think couldn't possibly work otherwise. Beyond that, I have no idea.
But doesn't it work on x86_64 Darwin?
perhaps you could help us - does arpack and/or octave build currently on x8664 Darwin?
Any news here? This also affects other derivations (e.g. openspecfun). arpack does build on x86_64-darwin.
This issue should be renamed "gfortran broken on aarch64-darwin", as it is not specific to arpack:
See – but we should really fix this in gfortran, rather than requiring every derivation to copy/paste the line.
cc To summarize, we should set: In stdenv somehow.. Perhaps this should go here:
We probably don't want to globally disable stack protector support, though; this only affects gfortran. Seems like we'd want to have the cc-wrapper for gfortran (on aarch64-darwin) to never inject the options, either through a option, or in the cc- script itself. Actually fixing whatever goes wrong in the toolchain would be preferable, of course.
Here's a proposal:


Question: <del> { lib, stdenv, fetchFromGitHub, boost-build, lua, boost }: </del> <ins> { lib, stdenv, fetchFromGitHub, lua, boost, cmake }: </ins> stdenv.mkDerivation rec { pname = "luabind"; version = "0.9.1"; src = fetchFromGitHub { <del> owner = "luabind"; </del> <ins> owner = "Oberon00"; </ins> repo = "luabind"; <del> rev = "v${version}"; sha256 = "sha256-sK1ca2Oj9yXdmxyXeDO3k8YZ1g+HxIXLhvdTWdPDdag="; </del> <ins> rev = "49814f6b47ed99e273edc5198a6ebd7fa19e813a"; sha256 = "sha256-JcOsoQHRvdzF2rsZBW6egOwIy7+7C4wy0LiYmbV590Q"; </ins> }; <del> patches = [ ./0.9.1_modern_boost_fix.patch ./0.9.1_boost_1.57_fix.patch ./0.9.1_discover_luajit.patch ]; </del> <ins> nativeBuildInputs = [ cmake ]; </ins> <del> buildInputs = [ boost-build lua boost ]; </del> <ins> buildInputs = [ boost ]; </ins> propagatedBuildInputs = [ lua ]; <del> buildPhase = "LUA_PATH=${lua} bjam release"; installPhase = "LUA_PATH=${lua} bjam --prefix=$out release install"; </del> passthru = { inherit lua; };

Steps to reproduce the behavior: FWIW: my fix is here, - but it is using a fork of . If somebody has the time to create a minimal patch on top of the current source, please feel free to. Please run and paste the result.
Looks like you are on a good path. Unfortunately I have no access to Apple hardware at all, but would be happy to merge a PR.
Yes, is working on it. There is a more active fork of luabind here: - how about we switch to using it? It'll obviate a bunch of patches as well.
I agree, sounds sensible.


Question: <ins> { lib , stdenv , fetchFromGitHub , rustPlatform , pkg-config , meson , ninja , rustc , cargo , wrapGAppsHook4 , python3 , libadwaita , graphene , gst_all_1 , glib-networking , darwin , libsoup_3 }: stdenv.mkDerivation rec { pname = "glide-media-player"; version = "0.6.1"; src = fetchFromGitHub { owner = "philn"; repo = "glide"; rev = version; hash = "sha256-dIXuWaoTeyVBhzr6VWxYBsn+CnUYG/KzhzNJtLLdRuI="; }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; hash = "sha256-azvxW40fuKuF/N0qwzofFk1bZiNxyTN6YBFU5qHQkCA="; }; postPatch = '' substituteInPlace scripts/meson_post_install.py  --replace "gtk-update-icon-cache" "gtk4-update-icon-cache" patchShebangs --build scripts/meson_post_install.py '' + lib.optionalString stdenv.isDarwin '' sed -i "/wayland,x11egl,x11glx/d" meson.build ''; nativeBuildInputs = [ pkg-config meson ninja rustPlatform.cargoSetupHook rustc cargo wrapGAppsHook4 python3 ]; buildInputs = [ libadwaita graphene gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-bad gst_all_1.gst-plugins-good glib-networking ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk_11_0.frameworks.IOKit ]; # FIXME: gst-plugins-good missing libsoup breaks streaming # (https://github.com/nixos/nixpkgs/issues/271960) preFixup = '' gappsWrapperArgs+=(--prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ libsoup_3 ]}") ''; meta = with lib; { description = "Linux/macOS media player based on GStreamer and GTK"; homepage = "https://philn.github.io/glide"; license = licenses.mit; maintainers = with maintainers; [ aleksana ]; mainProgram = "glide"; platforms = platforms.unix; # error: could not find system library 'gstreamer-gl-1.0' required by the 'gstreamer-gl-sys' crate broken = stdenv.isDarwin && stdenv.isx86_64; }; } </ins>

Project description "Linux/macOS media player based on GStreamer and GTK" gstreamer rust Metadata homepage URL: source URL: license: MIT platforms: linux
I tried to package glide and it's building successfully but the timestamps and the progress bar at the bottom aren't working. My progress is at if someone else is willing to look into it but I'm not sure how to debug this.
Nice, thanks Sadly, I think you made it further than me: heh
I couldn't really find anything about
I pulled your branch but it doesn't launch for me. Just the .
Stuck here I think maybe updating the registry would help, but I'd better waiting for the next release if possible...


Question: ssh-askpass-fullscreen = callPackage ../tools/networking/ssh-askpass-fullscreen { }; <ins> sshed = callPackage ../tools/networking/sshed { }; </ins> sshguard = callPackage ../tools/security/sshguard { }; sshping = callPackage ../tools/networking/sshping { };

Project description So basically it is a simple ssh config manager. Metadata homepage URL: source URL: license: Apache-2.0 platforms:


Question: python3.pkgs.buildPythonApplication rec { pname = "sticky"; <del> version = "1.11"; </del> <ins> version = "1.12"; </ins> format = "other"; src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> hash = "sha256-PXJpNKzF9goQvfh3lUUfOaZFessFNrWtg8nMDxPxRMo="; </del> <ins> hash = "sha256-kAO8Qz4bTn3+YeIXAvPZ1SpKgn+g+rBgi9+TaqL1vOY="; </ins> }; postPatch = ''


Question: python3.pkgs.buildPythonApplication rec { pname = "sticky"; <del> version = "1.11"; </del> <ins> version = "1.12"; </ins> format = "other"; src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> hash = "sha256-PXJpNKzF9goQvfh3lUUfOaZFessFNrWtg8nMDxPxRMo="; </del> <ins> hash = "sha256-kAO8Qz4bTn3+YeIXAvPZ1SpKgn+g+rBgi9+TaqL1vOY="; </ins> }; postPatch = ''


Question: }; systemd.services.libvirtd = { <ins> wantedBy = [ "multi-user.target" ]; </ins> requires = [ "libvirtd-config.service" ]; after = [ "libvirtd-config.service" ] ++ optional vswitch.enable "ovs-vswitchd.service";

the following configuration: guests are started to confirm VM should have automatically started guests marked to start on boot start Guests marked to boot on startup should start doesn't seem to do what it says
Not stale
The problem is that libvirtd is socket-activated on NixOS which it isn't out of the box.


Question: gmic_stdlib = fetchurl { name = "gmic_stdlib.h"; url = "http://gmic.eu/gmic_stdlib${lib.replaceStrings ["."] [""] version}.h"; <del> sha256 = "adObp8s+2TWaS+X/bQSphWRK6o85h+DGwlIDol6XN/4="; </del> <ins> hash = "sha256-kWHzA1Dk7F4IROq/gk+RJllry3BABMbssJxhkQ6Cp2M="; </ins> }; nativeBuildInputs = [

Steps to reproduce the behavior: gmic in a nix shell using the unstable channel Add any other context about the problem here.
Will be fixed by
Thanks! Note that it makes darktable fail to build.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Question: use = builtins.trace "Obsolete option `${showOption from}' is used. It was renamed to `${showOption to}'."; }; <ins> mkRenamedOptionModuleWith = { /* Old option path as list of strings. */ from, /* New option path as list of strings. */ to, /* Release number of the first release that contains the rename, ignoring backports. Set it to the upcoming release, matching the nixpkgs/.version file. */ sinceRelease, }: doRename { inherit from to; visible = false; warn = lib.isInOldestRelease sinceRelease; use = lib.warnIf (lib.isInOldestRelease sinceRelease) "Obsolete option `${showOption from}' is used. It was renamed to `${showOption to}'."; }; </ins> /* Return a module that causes a warning to be shown if any of the "from" option is defined; the defined values can be used in the "mergeFn" to set the "to" value.

The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors


Question: , protobuf, speechd, libXdamage, cups , ffmpeg, libxslt, libxml2, at-spi2-core , jre <ins> , pipewire_0_2 </ins> # optional dependencies , libgcrypt ? null # gnomeSupport || cupsSupport

Project description This flag is available in most other major distros. It is necessary to enable screen sharing on wayland inside of chromium, combined with xlr-desktop-portal-wlr and pipewire. It requires the build flag and a dependency on libpipewire02. See as an example. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
that would definitely be nice to have :) I actually also noticed this but unfortunately cannot test this easily as I'm not using screen sharing. If you could contribute a PR that would be awesome (but be aware that Chromium does unfortunately take quite some time to compile). Alternatively (but less preferably) we could make the required changes with the next update and test the core functionality (as always) and you could test screen sharing after the new version is available in the binary caches. Additionally we would need to package in Nixpkgs to make this work on wlroots based compositors. On Gnome/KDE this might work out-of-the-box, but I don't know what they currently implement/provide.
was just merged w/ . I'll try building chromium w/ the flag - as you say it takes a while, so I can leave it overnight and give it a shot.
how does the situation look like with ? Is the flag available there, as in, screensharing with wayland already works there?
yes, it's available in google-chrome. ! I'm still trying to get it to work with xlr-desktop-portal-wlr - I've done this in the past, but it's not working out of the box yet with
And just to make sure, you also did set as described there?
yes I did. I'm almost got it working I think. There are a few issues out of the box: -chrome is missing the pipewire 0.2 runtime dependency, so I it as (I'm on 20.03 so pkgs.pipewire is 0.2): .pipewire service doesn't work - it doesn't seem to be setting up the path correctly. I'm trying to fix this now: My current config on 20.03 looks like: Where is the same package that was recently merged.


Question: , protobuf, speechd, libXdamage, cups , ffmpeg, libxslt, libxml2, at-spi2-core , jre <ins> , pipewire_0_2 </ins> # optional dependencies , libgcrypt ? null # gnomeSupport || cupsSupport

yeah, I'm currently already looking at it - pipewire wants to execute , but it's not in . We can patch to contain the absolute path. I'll check if it works and will get back to you.
Btw, we /really/ need a sway NixOS test, and better documentation on how to use sway. I was trying stuff until it worked, and does autologin me into a sway, but there might be a smarter way to do this, without also starting X.
The sway recommendation is to just run sway from the terminal after login - that's how I do it at least. I was able to workaround the environment issue by doing (but this is a kludge I think and shouldn't be necessary). But unfortunately it's now crashing and I'm not sure why:
Yeah, even my sddm config I also had to , otherwise pipewire complained about not being able to reach dbus: Afterwards, it segfaulted, as it wasn't able to find ; I patched to be able to find the path to , and that error message is gone. Now (apart from not being able to find bluez or rtkit) it /might/ only be some version incompatibilities, not sure: I'll see if I can get as far with your chromium PR, will merge that then, and also submit the pipewire patch.
Okay, with the pipewire patch and , It seems I'm able to share at least my own application window :tada:. I don't know yet why the alacritty window nearby isn't shown, and why "Entire Screen" is black, but that's probably due to me running sway inside X via ssdm.
pipewire PRs:
I don't think you're using pipewire in that case. xdg-desktop-portal-wlr only supports full screen sharing atm. If it is black that means it's not working. By the way I had to add pipewire02 to my system packages to prevent xdg-desktop-portal from crashing. But now there seems to be some incompatibility in the pipewire service logs when chrome tries to connect:
you should be able to cherry-pick the to not have to manually add this to $PATH.
Thanks! I'm suspecting google-chrome is compiled with a too old version of pipewire.


Question: , protobuf, speechd, libXdamage, cups , ffmpeg, libxslt, libxml2, at-spi2-core , jre <ins> , pipewire_0_2 </ins> # optional dependencies , libgcrypt ? null # gnomeSupport || cupsSupport

Enabling pipewire debug logs, it seems to be sending an incompatible format to the pipewire server (similar to ). I have got this working with chromium compiled against pipewire 0.2.7 in the past, so I'm pretty sure it should work assuming the client library is recent enough. Once the chromium package has that flag enabled I'll try to retest.
I just confirmed my last comment by building chromium locally w/ rtcusepipewire=true. It works perfectly for fullscreen sharing.
Hmm take that back - it worked the first time but not anymore :/. Not sure what lib is missing where.
Seems like xdg-desktop-portal is crashing:
This might be yet another version incompatibility problem. I propose merging (as it's built with 0.2 everywhere else too), and then see if we can get it to work if the system pipewire also is 0.2. I asked upstream about these problems in - maybe 0.3 needs to support 0.2 clients for some time until we should switch.
Heads-up: the bad client situation should have been fixed with the latest pipewire release, PR at
Thanks for your help! I'm still getting the xdg-desktop-portal crash, however. I'm guessing there is something missing from my dbus environment - or perhaps it's trying to access a file/directory not available in nixos.
could you open a new issue with some more details, like logs etc.?
Okay, I made


Question: , makeWrapper , autoreconfHook , gtk-doc <ins> , graphviz </ins> }: let python = python2.withPackages (pp: [ pp.pygtk ]);

Installing results in a broken application that exits on startup with the message "GEGL operation missing! Glimpse requires the GEGL operation "gegl:introspect". This operation cannot be found. Check your GEGL install and ensure it has been compiled with any dependencies required for Glimpse." Steps to reproduce the behavior: to Glimpse Glimpse should work! works fine for me. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
Thanks for the report, Unfortunately I cannot reproduce your issue. Neither on as you reported nor on current . Could you elaborate on your setup a bit? Which window manager/desktop environment are you using? Is it possible that you modified glimpse in an overlay? I'm running Sway (Wayland) and deleted and before testing to make sure I didn't have any leftover state in my home directory.
I'm using i3wm (with no separate desktop manager); I installed Glimpse by adding it to environment.systemPackages in , I don't think there's any chance I did anything special with overlays there. I can't think of anything else I've done that might have affected this – I only installed NixOS a few days ago. I do have Home Manager installed, so I guess is it possible that something I've installed via that is causing a problem? (I don't have that much stuff installed, though, I don't think.) on my system is a tmpfs, so if something put a file outside of /nix or /home on install and is expecting it to still be there then it'll be unhappy, but I think I tried running Glimpse immediately after installing it with and it didn't work even then, so it shouldn't be anything related to that. Deleting changes the icon in the popup, which is weird, it looks like this if that directory isn't present at statup: ! and like this if I leave the directory there: ! but nothing else seems to change. (I noticed there's a directory in and , but removing it doesn't seem to do anything.)
aha, I found the problem: works just fine, and adding graphviz to environment.systemPackages fixes it permanently. see e.g.


Question: , makeWrapper , autoreconfHook , gtk-doc <ins> , graphviz </ins> }: let python = python2.withPackages (pp: [ pp.pygtk ]);

Ooh nice, didn't think about using a pure nix-shell to circumvent already installed packages clouding the issue. Now I'm able to reproduce the issue. Will add graphviz as runtime dependency then.
Looks like Gimp is not affected, as they got it . Glimpse didn't receive that fix, and it won't in the foreseeable future as the project .


Question: doCheck = false; postPatch = '' <del> substituteInPlace CMakeLists.txt --replace $'{SoQt_INCLUDE_DIRS}'  </del> <ins> substituteInPlace distutils_cmake/CMakeLists.txt --replace $'{SoQt_INCLUDE_DIRS}'  </ins> $'{Coin_INCLUDE_DIR}';$'{SoQt_INCLUDE_DIRS}' '';

pivy fails to build due to being unable to find some files Steps to reproduce the behavior: try to build pivy from nixpkgs HEAD


Question: "-DCMAKE_INSTALL_LIBDIR=lib" "-DBUILD_DOCS:BOOL=ON" (lib.optionalString usePython "-DUSE_PYTHON=true") <ins> ] ++ lib.optionals (usePython && stdenv.isDarwin) [ # Fix python lookup on Darwin. Not necessary after # https://github.com/NixOS/nixpkgs/pull/94090 lands in master "-DPython_ROOT_DIR=${python}" </ins> ]; # by default, it will query the python interpreter for it's sitepackages location

Describe the bug Since the recent commit ( ledger fails to build on Darwin. To Reproduce or similar. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(steve): channels(root): nixpkgs: Maintainer information:
if you don't need python. do you mind trying to build it with it off?
the error you're seeing is that a header from package isn't able to be found. I don't have a darwin machine to see why these two are different
Thanks. I don't need to work around it particularly, more interested in identifying a fix. I think the issue is that it's somehow picking up the system python: so probably some of the handling is broken, and indeed there are a few suspicious portions in the output I pasted, e.g. and subsequently:
I got the same cmake warnings, upstream needs to update some of their files. I'm not familiar enough with nix-darwin to have it NOT pull in system python


Question: # ToDo: a ligther version of libsoup to have FTP/HTTP support? ] ++ stdenv.lib.optionals gnomeSupport (with gnome; [ libsoup gcr <ins> glib-networking # TLS support </ins> gnome-online-accounts libsecret libgdata ]);

Inkscape has support for openclipart but it doesn't work in the package provided by nixpkgs. inkscape to File -Import Clip Art... a search term and click the Search button. the in the GUI and in the terminal. NixOS 18.09 and nixpkgs master.
I researched a bit and thought adding glib-networking would fix it. I wrote the following patch, but it doesn't seem to have any effect:
I wonder whether it really is because TLS support is unavailable, or because uses an invalid security certificate?
Good point. Hm, that's weird. I followed that URL () a day or two ago (when I first noticed this) and was redirected to https:// without problems. But now I see the certificate warning in firefox.
I think it may be a packaging bug after all. Look at this grep: The message only appears in the glib tree, in the gdummytlsbackend.c file. No matches from glib-networking, which AFAIK, provides TLS support.
I tried the patch and am getting Probably because the site is down.
is not down for me.
Thank you!


Question: <del> { lib , stdenv , fetchFromGitHub , buildNpmPackage , nix-update-script , electron , writeShellScriptBin , makeWrapper , copyDesktopItems , giflib , makeDesktopItem , pkg-config , pixman , cairo , pango , npm-lockfile-fix , overrideSDK , darwin </del> <ins> { lib, stdenv, fetchFromGitHub, buildNpmPackage, nix-update-script, electron, writeShellScriptBin, makeWrapper, copyDesktopItems, makeDesktopItem, pkg-config, pixman, cairo, pango, npm-lockfile-fix, overrideSDK, darwin, </ins> }: let # fix for: https://github.com/NixOS/nixpkgs/issues/272156 <del> buildNpmPackage' = buildNpmPackage.override { stdenv = if stdenv.isDarwin then overrideSDK stdenv "11.0" else stdenv; }; </del> <ins> buildNpmPackage' = buildNpmPackage.override { stdenv = if stdenv.isDarwin then overrideSDK stdenv "11.0" else stdenv; }; </ins> in buildNpmPackage' rec { pname = "bruno";

Attempt to build on Sample This is on an M2 chip, and it seems the issue is with node-canvas not being able to install due to missing giflib. Building with: Fixes this. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: buildNpmPackage rec { pname = "bitwarden-cli"; <del> version = "2023.10.0"; </del> <ins> version = "2023.12.0"; </ins> src = fetchFromGitHub { owner = "bitwarden"; repo = "clients"; rev = "cli-v${version}"; <del> hash = "sha256-egXToXWfb9XV7JuCRBYJO4p/e+WOwMncPKz0oBgeALQ="; </del> <ins> hash = "sha256-WYhLKV3j3Ktite5u1H4fSku38hCCrMzKoxtjq6aT9yo="; </ins> }; nodejs = nodejs_18; <del> npmDepsHash = "sha256-iO8ZozVl1vOOqowQARnRJWSFUFnau46+dKfcMSkyU3o="; </del> <ins> npmDepsHash = "sha256-bnYpvHO9Pnob+MbrSshv03mSwXCADH/2xw33nLVKMdg="; </ins> nativeBuildInputs = [ python3

Steps to reproduce the behavior: bitwarden Please run and paste the result.
Will be fixed by


Question: <ins> #! @bash@/bin/bash set -eo pipefail PATH=@coreutils@/bin:$PATH export CLASSPATH=@CLASSPATH@ export FREENET_HOME="$HOME/.local/share/freenet" if [ -n "$XDG_DATA_HOME" ] ; then FREENET_HOME="$XDG_DATA_HOME/freenet" fi mkdir -p -- $FREENET_HOME cp -u -- @seednodes@/seednodes.fref $FREENET_HOME/seednodes.fref chmod u+rw -- $FREENET_HOME/seednodes.fref cd -- $FREENET_HOME exec @jre@/bin/java -Xmx1024M freenet.node.NodeStarter "$@" </ins>

Freenet installs successfully but fails to run for both the service and the package with Steps to reproduce the behavior: Failure with Or alternatively with the service = true; to config For Freenet to start and be able to access setup wizard on 127.0.0.1:8888 Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. --> <ins> - The `power.ups` module now generates `upsd.conf`, `upsd.users` and `upsmon.conf` automatically from a set of new configuration options. This breaks compatibility with existing `power.ups` setups where these files were created manually. Back up these files before upgrading NixOS. </ins> - `mkosi` was updated to v19. Parts of the user interface have changed. Consult the [release notes](https://github.com/systemd/mkosi/releases/tag/v19) for a list of changes.

Describe the bug I'm trying to use NixOS in a UPS client (not server). When , the and services shouldn't be running. There is a note that says that is not used currently. To Reproduce Steps to reproduce the behavior: Error: and fail. Expected behavior only upsmon should be running 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 Maintainer information: See also
Looks like there's a pretty simple workaround:
I marked this as stale due to inactivity. →


Question: <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. --> <ins> - The `power.ups` module now generates `upsd.conf`, `upsd.users` and `upsmon.conf` automatically from a set of new configuration options. This breaks compatibility with existing `power.ups` setups where these files were created manually. Back up these files before upgrading NixOS. </ins> - `mkosi` was updated to v19. Parts of the user interface have changed. Consult the [release notes](https://github.com/systemd/mkosi/releases/tag/v19) for a list of changes.

Describe the bug The following snippet: results in services failing to start due to missing config files etc. : : ( fails too, but that could be down to the fact that I haven't plugged the UPS in yet -- but for the record, it complains ) Expected behavior I'd expect the services to start successfully (and probably complain about the missing actual UPS). Notify maintainers (The UPS module appears to have received only drive-by changes for the last several years, so no idea who to bug personally). Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
OK, should've read the whole module: I'm supposed to supply the missing /etc/nut files myself because it's unwise to keep them in the store (they could contain passwords and whatnot, I guess?). Declaring (in the service definitions) the state directory to be but creating for the purpose appears to be a real bug, though :)
Also (sorry for the semi-off-topic) what are best practices for referencing hand-written config files without their contents winding up in the store? Double-symlinking? If this is documented somewhere, then I haven't found where.
I was struggling with the same problem as until I noticed this bug report. After copying and editing , , and from to (and setting on all those files), I was able to get it to work. I think this should be more discoverable. If it's not appropriate to copy those sample files to on the users behalf, there should at least be detailed instructions on the option to explain what else needs to be done.
I marked this as stale due to inactivity. →
Agreed this should be more discoverable. Perhaps at least could be defaulted to empty and written, since I seem to be getting away without anything in there. In case it helps anyone, I got it working with something like this:
I was hit this bug today, too. Maybe we can fix it by using a startup unit that handles the secrets and setup the state directories like nextcloud or syncthing do
Been working on today and wanted to put some notes here. Using version 2.7.4. First, isn't used by for PIDs and it will try to write to .


Question: <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. --> <ins> - The `power.ups` module now generates `upsd.conf`, `upsd.users` and `upsmon.conf` automatically from a set of new configuration options. This breaks compatibility with existing `power.ups` setups where these files were created manually. Back up these files before upgrading NixOS. </ins> - `mkosi` was updated to v19. Parts of the user interface have changed. Consult the [release notes](https://github.com/systemd/mkosi/releases/tag/v19) for a list of changes.

flags , , may be needed instead of environment variables until a 2.7.5 release. Ref: Using for debug makes it non-forking, requiring a change to the systemd unit . I was able to get to run as non-root: I'm still working on understanding how to manage state directories in NixOS but this was needed:
I set out to get my UPS (cyberpower CP1500 AVR UPS) working with NixOS today. This was the first issue I came across, I figured this was the best place to share my configuration. I probably made this more complex than it needed to be because I have no idea what I am doing, and it is definitely not secure; one problem at a time.
Not stale; still relevant
Thanks for providing your standalone config! I learned a ton tweaking it into a netserver config! The below config creates a working NUT netserver that other machines on your local network can be connected to. The only thing I have yet to figure out is a secure way to include passwords in .nix files that won't show up if I push my local copy to github. Any ideas? If you want to tweak when NUT shuts down your computers you can modify the values of " = <percentage" and " = <seconds" under "directives". SHUTDOWNCMD will be triggered when both conditions are met. The "ignorelb" directive is necessary to have NUT ignore the UPS's defaults. Anyone using this config may want to make sure SHUTDOWNCMD and NOTIFYCMD point to the correct binaries in their filesystem. One other thing of note is to check the value of the "schedulerRules" field under below. You must give it the path to your file. I just put a copy of it inside my /etc/nixos. Could probably add another variable to hold the path for convenience. `
For secrets in nix config, I think the current recommendation is to put it in a separate file and not include it in the repo. See also
I have been using sops-nix to commit encrypted passwords to my NixOS repo, but I have yet to put in the elbow grease to make this work with my upsmon password.
is my attempt at making generate the config files necessary for basic operation. If you are using , could you try out the changes and leave a review?


Question: with lib; let cfg = config.services.networkd-dispatcher; in { options = { services.networkd-dispatcher = {

refuses to work since it requires the directories containing the scripts to have mode 755, but the nixos module creates them with mode 750. Steps to reproduce the behavior: (re)-configure an interface (for example by unplugging and replugging a network cable) something like in the journal and that does not exist, i.e. the hook was never run. networkd-dispatcher works. <!-- 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.
Thank you for the report! I'm thinking about adding a rules option to the networkd-dispatcher module so this might solve your issue


Question: nlohmann_json ]; <del> NIX_LDFLAGS = lib.optionals (!atLeast24) [ # https://github.com/NixOS/nix/commit/3e85c57a6cbf46d5f0fe8a89b368a43abd26daba (lib.optionalString enableStatic "-lssl -lbrotlicommon -lssh2 -lz -lnghttp2 -lcrypto") # https://github.com/NixOS/nix/commits/74b4737d8f0e1922ef5314a158271acf81cd79f8 (lib.optionalString (stdenv.hostPlatform.system == "armv5tel-linux" || stdenv.hostPlatform.system == "armv6l-linux") "-latomic") ]; </del> postPatch = '' patchShebangs --build tests '';

Package name: nix23 Latest released version: 2.3.17 (see ) Current version on the unstable channel: 2.3.16 Current version on the stable/release channel: 2.3.16 Notify maintainers Note for maintainers: Please tag this issue in your PR. See for context. The release script apparently doesn't upload source tarballs anymore, so 2.3.17 sources look more like the other ones. There's a bunch of expressions in that might need to be revisited.


Question: desktop-file-utils glib wrapGAppsHook <ins> python3Packages.pip </ins> ]; buildInputs = [

Steps to reproduce the behavior: package 'grapejuice' Fixed by adding to propagatedBuildInputs Please run and paste the result.


Question: doCheck = (!stdenv.isDarwin); <ins> # examples.complex.xss_scanner doesn't import correctly with pytest5 </ins> checkPhase = '' export HOME=$(mktemp -d) export LC_CTYPE=en_US.UTF-8 <del> pytest -k 'not test_find_unclaimed_URLs and not test_tcp' </del> <ins> pytest --ignore test/examples  -k 'not test_find_unclaimed_URLs and not test_tcp' </ins> ''; propagatedBuildInputs = [

Describe the bug A clear and concise description of what the bug is. mitmproxy tests broken on unstable. To Reproduce Steps to reproduce the behavior: nix-env -iA nixos-unstable.mitmproxy Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
thank you for submitting this, ill get it fixed


Question: ${optionalString cfg.caching.apcu "'memcache.local' => 'OCMemcacheAPCu',"} 'log_type' => 'syslog', 'log_level' => '${builtins.toString cfg.logLevel}', <del> ${optionalString (cfg.config.overwriteProtocol != null) "'overwriteprotocol' => '${cfg.config.overwriteProtocol}',"} </del> <ins> ${optionalString (c.overwriteProtocol != null) "'overwriteprotocol' => '${c.overwriteProtocol}',"} ${optionalString (c.dbname != null) "'dbname' => '${c.dbname}',"} ${optionalString (c.dbhost != null) "'dbhost' => '${c.dbhost}',"} ${optionalString (c.dbport != null) "'dbport' => '${toString c.dbport}',"} ${optionalString (c.dbuser != null) "'dbuser' => '${c.dbuser}',"} ${optionalString (c.dbtableprefix != null) "'dbtableprefix' => '${toString c.dbtableprefix}',"} ${optionalString (c.dbpass != null) "'dbpassword' => '${c.dbpass}',"} ${optionalString (c.dbpassFile != null) "'dbpassword' => nix_read_pwd(),"} 'dbtype' => '${c.dbtype}', 'trusted_domains' => ${writePhpArrary c.extraTrustedDomains}, </ins> ]; ''; occInstallCmd = let <del> c = cfg.config; adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </del> dbpass = if c.dbpassFile != null then ''"$(<"${toString c.dbpassFile}")"'' else if c.dbpass != null then ''"${toString c.dbpass}"'' else null; <ins> adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </ins> installFlags = concatStringsSep " n    " (mapAttrsToList (k: v: "${k} ${toString v}") { "--database" = ''"${c.dbtype}"'';

Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do.


Question: ${optionalString cfg.caching.apcu "'memcache.local' => 'OCMemcacheAPCu',"} 'log_type' => 'syslog', 'log_level' => '${builtins.toString cfg.logLevel}', <del> ${optionalString (cfg.config.overwriteProtocol != null) "'overwriteprotocol' => '${cfg.config.overwriteProtocol}',"} </del> <ins> ${optionalString (c.overwriteProtocol != null) "'overwriteprotocol' => '${c.overwriteProtocol}',"} ${optionalString (c.dbname != null) "'dbname' => '${c.dbname}',"} ${optionalString (c.dbhost != null) "'dbhost' => '${c.dbhost}',"} ${optionalString (c.dbport != null) "'dbport' => '${toString c.dbport}',"} ${optionalString (c.dbuser != null) "'dbuser' => '${c.dbuser}',"} ${optionalString (c.dbtableprefix != null) "'dbtableprefix' => '${toString c.dbtableprefix}',"} ${optionalString (c.dbpass != null) "'dbpassword' => '${c.dbpass}',"} ${optionalString (c.dbpassFile != null) "'dbpassword' => nix_read_pwd(),"} 'dbtype' => '${c.dbtype}', 'trusted_domains' => ${writePhpArrary c.extraTrustedDomains}, </ins> ]; ''; occInstallCmd = let <del> c = cfg.config; adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </del> dbpass = if c.dbpassFile != null then ''"$(<"${toString c.dbpassFile}")"'' else if c.dbpass != null then ''"${toString c.dbpass}"'' else null; <ins> adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </ins> installFlags = concatStringsSep " n    " (mapAttrsToList (k: v: "${k} ${toString v}") { "--database" = ''"${c.dbtype}"'';

If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect.


Question: ${optionalString cfg.caching.apcu "'memcache.local' => 'OCMemcacheAPCu',"} 'log_type' => 'syslog', 'log_level' => '${builtins.toString cfg.logLevel}', <del> ${optionalString (cfg.config.overwriteProtocol != null) "'overwriteprotocol' => '${cfg.config.overwriteProtocol}',"} </del> <ins> ${optionalString (c.overwriteProtocol != null) "'overwriteprotocol' => '${c.overwriteProtocol}',"} ${optionalString (c.dbname != null) "'dbname' => '${c.dbname}',"} ${optionalString (c.dbhost != null) "'dbhost' => '${c.dbhost}',"} ${optionalString (c.dbport != null) "'dbport' => '${toString c.dbport}',"} ${optionalString (c.dbuser != null) "'dbuser' => '${c.dbuser}',"} ${optionalString (c.dbtableprefix != null) "'dbtableprefix' => '${toString c.dbtableprefix}',"} ${optionalString (c.dbpass != null) "'dbpassword' => '${c.dbpass}',"} ${optionalString (c.dbpassFile != null) "'dbpassword' => nix_read_pwd(),"} 'dbtype' => '${c.dbtype}', 'trusted_domains' => ${writePhpArrary c.extraTrustedDomains}, </ins> ]; ''; occInstallCmd = let <del> c = cfg.config; adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </del> dbpass = if c.dbpassFile != null then ''"$(<"${toString c.dbpassFile}")"'' else if c.dbpass != null then ''"${toString c.dbpass}"'' else null; <ins> adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </ins> installFlags = concatStringsSep " n    " (mapAttrsToList (k: v: "${k} ${toString v}") { "--database" = ''"${c.dbtype}"'';

If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented.


Question: ${optionalString cfg.caching.apcu "'memcache.local' => 'OCMemcacheAPCu',"} 'log_type' => 'syslog', 'log_level' => '${builtins.toString cfg.logLevel}', <del> ${optionalString (cfg.config.overwriteProtocol != null) "'overwriteprotocol' => '${cfg.config.overwriteProtocol}',"} </del> <ins> ${optionalString (c.overwriteProtocol != null) "'overwriteprotocol' => '${c.overwriteProtocol}',"} ${optionalString (c.dbname != null) "'dbname' => '${c.dbname}',"} ${optionalString (c.dbhost != null) "'dbhost' => '${c.dbhost}',"} ${optionalString (c.dbport != null) "'dbport' => '${toString c.dbport}',"} ${optionalString (c.dbuser != null) "'dbuser' => '${c.dbuser}',"} ${optionalString (c.dbtableprefix != null) "'dbtableprefix' => '${toString c.dbtableprefix}',"} ${optionalString (c.dbpass != null) "'dbpassword' => '${c.dbpass}',"} ${optionalString (c.dbpassFile != null) "'dbpassword' => nix_read_pwd(),"} 'dbtype' => '${c.dbtype}', 'trusted_domains' => ${writePhpArrary c.extraTrustedDomains}, </ins> ]; ''; occInstallCmd = let <del> c = cfg.config; adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </del> dbpass = if c.dbpassFile != null then ''"$(<"${toString c.dbpassFile}")"'' else if c.dbpass != null then ''"${toString c.dbpass}"'' else null; <ins> adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </ins> installFlags = concatStringsSep " n    " (mapAttrsToList (k: v: "${k} ${toString v}") { "--database" = ''"${c.dbtype}"'';

What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?


Question: ${optionalString cfg.caching.apcu "'memcache.local' => 'OCMemcacheAPCu',"} 'log_type' => 'syslog', 'log_level' => '${builtins.toString cfg.logLevel}', <del> ${optionalString (cfg.config.overwriteProtocol != null) "'overwriteprotocol' => '${cfg.config.overwriteProtocol}',"} </del> <ins> ${optionalString (c.overwriteProtocol != null) "'overwriteprotocol' => '${c.overwriteProtocol}',"} ${optionalString (c.dbname != null) "'dbname' => '${c.dbname}',"} ${optionalString (c.dbhost != null) "'dbhost' => '${c.dbhost}',"} ${optionalString (c.dbport != null) "'dbport' => '${toString c.dbport}',"} ${optionalString (c.dbuser != null) "'dbuser' => '${c.dbuser}',"} ${optionalString (c.dbtableprefix != null) "'dbtableprefix' => '${toString c.dbtableprefix}',"} ${optionalString (c.dbpass != null) "'dbpassword' => '${c.dbpass}',"} ${optionalString (c.dbpassFile != null) "'dbpassword' => nix_read_pwd(),"} 'dbtype' => '${c.dbtype}', 'trusted_domains' => ${writePhpArrary c.extraTrustedDomains}, </ins> ]; ''; occInstallCmd = let <del> c = cfg.config; adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </del> dbpass = if c.dbpassFile != null then ''"$(<"${toString c.dbpassFile}")"'' else if c.dbpass != null then ''"${toString c.dbpass}"'' else null; <ins> adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </ins> installFlags = concatStringsSep " n    " (mapAttrsToList (k: v: "${k} ${toString v}") { "--database" = ''"${c.dbtype}"'';

Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)


Question: # luarocks only looks for rockspecs in the default/system tree instead of all # configured trees) luarocks_config = "luarocks-config.lua"; <del> luarocks_content = '' </del> <ins> luarocks_content = let extraVariablesStr = lib.concatStringsSep "n " (lib.mapAttrsToList (k: v: "${k}='${v}';") extraVariables); in '' </ins> local_cache = "" -- To prevent collisions when creating environments, we install the rock -- files into per-package subdirectories

Describe the bug neovim fails to build with missing , similar to , on . To Reproduce Steps to reproduce the behavior: to from master () Expected behavior The package should successfully build. Metadata On master () Maintainer information:
via in
so you could do until a proper fix.
Reverting the luarocks bump doesn't work for me. That fix is also very surprising to me, since neovim broke (for me) after the latest nixos-unstable channel update.
Interesting. It worked fine for me. Running the above revert command and then (inside my local nixpkgs with it reverted) let me build neovim properly. I don't think it's particularly surprising if updating a channel that happens to include the luarocks bump causes it to break, unless I'm misunderstanding you.
I updated from a channel where the luarocks bump had already happened, and neovim worked on that channel. In fact, I reverted to the previous hydra evaluation to make my system evaluate again.
This was actually before and it was working without problems and then suddenly the problem appeared again. I can also report that I cam getting this in the same way described (updated latest nixos-unstable channel and then neovim stopped building again).
I confirm this fixed by on master (channels may take a while). For now I'll assume that charvp's failure to resolve the issue with that revert was some kind of mistake; we can re-open otherwise, perhaps separately if it's a different kind of error.
Does anyone know why updating the luarocks dependency is so brittle? Is it possible to at least add a test so we don't regress again in the future?
the tool exists (nixpkgs-review) but it takes CPU and disk space to run plus some reviewer time (and was not run in this case). Also for this specific case, the luarocks update broke in subtle ways the build so I wouldn't call it . It is called unstable for a reason. The good thing about nixpkgs is you can pin neovim to an older version while keeping your system on unstable.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Are we sure this is fixed on Darwin? still shows failing with logs of: Or is this a different issue?


Question: # luarocks only looks for rockspecs in the default/system tree instead of all # configured trees) luarocks_config = "luarocks-config.lua"; <del> luarocks_content = '' </del> <ins> luarocks_content = let extraVariablesStr = lib.concatStringsSep "n " (lib.mapAttrsToList (k: v: "${k}='${v}';") extraVariables); in '' </ins> local_cache = "" -- To prevent collisions when creating environments, we install the rock -- files into per-package subdirectories

I think the root problem here is that luarocks has a poor implementation of "move". Combined with the build's behavior being affected by filesystem ordering the result is essentially random. The [implementation of move][] calls out to the operating system commands [][] and [][]. Building with will contain a sequence of , and . I've extracted the [relevant part of the log][]. The critical aspect here is that by default, unix will dereference symlinks and copy their contents. [implementation of move]: []: []: [relevant part of the log]: My theory: luarocks scans the directory for external libraries in filesystem order and attempts to move all shared libraries from to . At which point one of 3! things will happen, but the two main ones are: is copied and deleted and , now broken symlinks, fail to copy and are copied by dereferencing, and deleted is copied and deleted Either way is wrong to some degree, but one of them happens to work well enough for downstream packages to build. If I build locally, the filesystem order I get seems to work, so we can inspect the two results: I've been focusing on this for darwin since the failure case happens to be cached, but I believe it applies equally to linux.
is that sthg you have already witnessed ?
What LuaRocks version is this happening with? I have pushed fixes related to the file deployment stage in 3.3.1.
I've tested 3.2.1 (current nixpkgs master) and 3.3.1 (hasty upgrade locally), they both have similar results, except on 3.3.1 the errors now propagate correctly. I've uploaded a [log of a failed build][] with 3.3.1. [log of a failed build]:
I was hoping to find time to write a proper issue report and a test lua package for this, but haven't yet. My test case would have a directory structure made with , that looks like: In order to succeed the deployment stage would have to produce both the file and its symlink.


Question: # luarocks only looks for rockspecs in the default/system tree instead of all # configured trees) luarocks_config = "luarocks-config.lua"; <del> luarocks_content = '' </del> <ins> luarocks_content = let extraVariablesStr = lib.concatStringsSep "n " (lib.mapAttrsToList (k: v: "${k}='${v}';") extraVariables); in '' </ins> local_cache = "" -- To prevent collisions when creating environments, we install the rock -- files into per-package subdirectories

Describe the bug I have neovim in my systemPackages, I did and today and it stuck at building luajit: To Reproduce Steps to reproduce the behavior: to Expected behavior The system should upgrade properly. Additional context Output: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kj): nixpkgs: Maintainer information:
Possible fix is in . There was already an open issue about it () but from an unclear reason people have reached the conclusion it was fixed on latest master.
Oh I meant , not .
Well, I agree with that conclusion. For me, on the build is broken with the error above and on current master it isn't. EDIT: note that the channels lag behind, usually less than a couple days, but sometimes we get a week or two due to some harder regression.
Yea right. For me on NixOS I tried with the nixpkgs-unstable channel and could install successfully. The nixos-unstable still fails though.


Question: }; }; <ins> # Test OCSP Stapling specialisation.ocsp-stapling.configuration = { pkgs, ... }: { security.acme.certs."a.example.test" = { ocspMustStaple = true; }; services.nginx.virtualHosts."a.example.com" = { extraConfig = '' ssl_stapling on; ssl_stapling_verify on; ''; }; }; </ins> # Test using Apache HTTPD specialisation.httpd-aliases.configuration = { pkgs, config, lib, ... }: { services.nginx.enable = lib.mkForce false;

Describe the bug causes Lego to fail. To Reproduce Steps to reproduce the behavior: set on an enabled certificate. to this configuration. fail. Lego complains about an unrecognized (really misplaced) flag. Expected behavior The certificate will be successfully fetched, with Must-Staple enabled. Screenshots Additional context I think the problematic code is here: should not be in commonOpts, it should instead be in runOpts and renewOpts. Lego runs successfully when is to and . Notify maintainers (the acme team) Metadata Maintainer information:
Thanks for the report :) It appears that the --must-staple option is common to both "run" and "renew" modes, but is not actually a common option that can be specified before the mode. I'll get a PR ready for this.


Question: "test_album_from_string" "test_album_from_url" "test_album_length" <del> "test_artist_from_url" </del> "test_artist_from_string" <ins> "test_artist_from_url" </ins> "test_convert" "test_download_ffmpeg" "test_download_song"

Failure happens locally as well when trying to build spotdl on the nixos-23.05 branch. this the tail of the log: The last line is apparently unrelated: (maintainer) (recent bumps)
This test doesn't fail if spotdl is built using version from this nixpkgs commit , I'm not sure if this is an upstream issue with spotdl while using newer yt-dlp versions (newer than ).


Question: , awscli }: <del> python3.pkgs.buildPythonApplication rec { pname = "awscli"; version = "1.32.101"; # N.B: if you change this, change botocore and boto3 to a matching version too pyproject = true; </del> <ins> let botocoreVersion = python3.pkgs.botocore.version; # awscli.version should be pinned to 2 minor versions less than the botocoreVersion versionMinor = toString (lib.toInt (lib.versions.minor botocoreVersion) - 2); versionPatch = lib.versions.patch botocoreVersion; self = python3.pkgs.buildPythonApplication rec { pname = "awscli"; version = "1.${versionMinor}.${versionPatch}"; # N.B: if you change this, change botocore and boto3 to a matching version too pyproject = true; </ins> <del> src = fetchPypi { inherit pname version; hash = "sha256-M4KzuQ+srPfk85P5QeQfVMorSKWhmNhdX4AY0AeRDTQ="; }; </del> <ins> src = fetchPypi { inherit pname version; hash = "sha256-GPcXkl2H0XNaeqt2/qD5+KvW23dRB0X+zLWo9hLigQM="; }; </ins> <del> nativeBuildInputs = [ python3.pkgs.pythonRelaxDepsHook ]; </del> <ins> nativeBuildInputs = [ python3.pkgs.pythonRelaxDepsHook ]; </ins> <del> pythonRelaxDeps = [ "botocore" "colorama" "docutils" "rsa" ]; </del> <ins> pythonRelaxDeps = [ # botocore must not be relaxed "colorama" "docutils" "rsa" ]; </ins> <del> build-system = [ python3.pkgs.setuptools ]; </del> <ins> build-system = [ python3.pkgs.setuptools ]; </ins> <del> propagatedBuildInputs = with python3.pkgs; [ botocore s3transfer colorama docutils rsa pyyaml groff less ]; </del> <ins> propagatedBuildInputs = with python3.pkgs; [ botocore s3transfer colorama docutils rsa pyyaml groff less ]; </ins> <del> postInstall = '' mkdir -p $out/share/bash-completion/completions echo "complete -C $out/bin/aws_completer aws" > $out/share/bash-completion/completions/awscli </del> <ins> postInstall = '' mkdir -p $out/share/bash-completion/completions echo "complete -C $out/bin/aws_completer aws" > $out/share/bash-completion/completions/awscli </ins> <del> mkdir -p $out/share/zsh/site-functions mv $out/bin/aws_zsh_completer.sh $out/share/zsh/site-functions </del> <ins> mkdir -p $out/share/zsh/site-functions mv $out/bin/aws_zsh_completer.sh $out/share/zsh/site-functions </ins> <del> rm $out/bin/aws.cmd ''; </del> <ins> rm $out/bin/aws.cmd ''; </ins> <del> doInstallCheck = true; </del> <ins> doInstallCheck = true; </ins> <del> installCheckPhase = '' runHook preInstallCheck </del> <ins> installCheckPhase = '' runHook preInstallCheck </ins> <del> $out/bin/aws --version | grep "${python3.pkgs.botocore.version}" $out/bin/aws --version | grep "${version}" </del> <ins> $out/bin/aws --version | grep "${botocoreVersion}" $out/bin/aws --version | grep "${version}" </ins> <del> runHook postInstallCheck ''; </del> <ins> runHook postInstallCheck ''; </ins> <del> passthru = { python = python3; # for aws_shell updateScript = nix-update-script { # Excludes 1.x versions from the Github tags list extraArgs = [ "--version-regex" "^(1.(.*))" ]; }; tests.version = testers.testVersion { package = awscli; command = "aws --version"; inherit version; </del> <ins> passthru = { python = python3; # for aws_shell updateScript = nix-update-script { extraArgs = [ "--version=skip" ]; }; tests.version = testers.testVersion { package = awscli; command = "aws --version"; inherit version; }; </ins> }; <del> }; meta = with lib; { homepage = "https://aws.amazon.com/cli/"; changelog = "https://github.com/aws/aws-cli/blob/${version}/CHANGELOG.rst"; description = "Unified tool to manage your AWS services"; license = licenses.asl20; mainProgram = "aws"; maintainers = with maintainers; [ anthonyroussel ]; </del> <ins> meta = with lib; { homepage = "https://aws.amazon.com/cli/"; changelog = "https://github.com/aws/aws-cli/blob/${version}/CHANGELOG.rst"; description = "Unified tool to manage your AWS services"; license = licenses.asl20; mainProgram = "aws"; maintainers = with maintainers; [ anthonyroussel ]; }; </ins> }; <del> } </del> <ins> in assert self ? pythonRelaxDeps -> !(lib.elem "botocore" self.pythonRelaxDeps); self </ins>

The version of AWSCLI in master is 1.32.58. This version requires botocore==1.34.58, however the version of botocore in master is 1.34.87 AWSCli botocore pin: This started happening after changing my to Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This should be fixed by , which syncs botocore, awscli, and boto3.


Question: * Full encryption, DHT, and PEX support ''; homepage = "http://www.transmissionbt.com/"; <del> license = lib.licenses.gpl2; # parts are under MIT </del> <ins> license = lib.licenses.gpl2Plus; # parts are under MIT </ins> maintainers = with lib.maintainers; [ astsmtl vcunat wizeman ]; platforms = lib.platforms.unix; };

Project description Fragments is a modern, responsive and graphical Gnome bittorrent client Metadata homepage URL: source URL: license: gpl3 platforms: linux The new version of Fragments depends on libutp which hopefully gets merged soon. I've opened a pull request for it . for Fragments.
We have transmission and torrential. Maybe that's something for you.
That's true but Fragments is a really neat, easy and modern looking torrent client. It has an adaptive interface which would also work quite well on mobile devices, for example NixOS mobile :+1:


Question: <ins> { lib , stdenv , fetchurl , pkg-config , lua , readline , ncurses , lz4 , tbox , xmake-core-sv }: stdenv.mkDerivation rec { pname = "xmake"; version = "2.7.9"; src = fetchurl { url = "https://github.com/xmake-io/xmake/releases/download/v${version}/xmake-v${version}.tar.gz"; hash = "sha256-m0LYY0gz9IhbBbiUKd1gBE3KmSMvYJYyC42Ff7M9Ku8="; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ lua lua.pkgs.cjson readline ncurses lz4 tbox xmake-core-sv ]; configureFlags = [ "--external=y" ]; meta = with lib; { description = "A cross-platform build utility based on Lua"; homepage = "https://xmake.io"; license = licenses.asl20; platforms = lua.meta.platforms; maintainers = with maintainers; [ rewine ]; }; } </ins>

Project description A lightweight cross-platform build utility based on Lua Metadata homepage URL: source URL: license: asl20 platforms: unix


Question: are used internally to configure an HTTP server using <literal><link xlink:href="https://php-fpm.org/">PHP-FPM</link></literal> and <literal>nginx</literal>. The <literal>config</literal> attribute set is <del> used for the <literal>config.php</literal> which is used for the application's configuration. <emphasis>Beware: this isn't entirely pure since the config is modified by the application's runtime!</emphasis> </del> <ins> used by the imperative installer and all values are written to an additional file to ensure that changes can be applied by changing the module's options. </ins> </para> <para> <del> In case the application serves multiple hosts (those are checked with </del> <ins> In case the application serves multiple domains (those are checked with </ins> <literal><link xlink:href="http://php.net/manual/en/reserved.variables.server.php">$_SERVER['HTTP_HOST']</link></literal>) <del> those can be added using </del> <ins> it's needed to add them to </ins> <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>. </para> <ins> <para> Auto updates for Nextcloud apps can be enabled using <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </ins> </section> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Pitfalls</title>


Question: are used internally to configure an HTTP server using <literal><link xlink:href="https://php-fpm.org/">PHP-FPM</link></literal> and <literal>nginx</literal>. The <literal>config</literal> attribute set is <del> used for the <literal>config.php</literal> which is used for the application's configuration. <emphasis>Beware: this isn't entirely pure since the config is modified by the application's runtime!</emphasis> </del> <ins> used by the imperative installer and all values are written to an additional file to ensure that changes can be applied by changing the module's options. </ins> </para> <para> <del> In case the application serves multiple hosts (those are checked with </del> <ins> In case the application serves multiple domains (those are checked with </ins> <literal><link xlink:href="http://php.net/manual/en/reserved.variables.server.php">$_SERVER['HTTP_HOST']</link></literal>) <del> those can be added using </del> <ins> it's needed to add them to </ins> <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>. </para> <ins> <para> Auto updates for Nextcloud apps can be enabled using <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </ins> </section> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Pitfalls</title>


Question: are used internally to configure an HTTP server using <literal><link xlink:href="https://php-fpm.org/">PHP-FPM</link></literal> and <literal>nginx</literal>. The <literal>config</literal> attribute set is <del> used for the <literal>config.php</literal> which is used for the application's configuration. <emphasis>Beware: this isn't entirely pure since the config is modified by the application's runtime!</emphasis> </del> <ins> used by the imperative installer and all values are written to an additional file to ensure that changes can be applied by changing the module's options. </ins> </para> <para> <del> In case the application serves multiple hosts (those are checked with </del> <ins> In case the application serves multiple domains (those are checked with </ins> <literal><link xlink:href="http://php.net/manual/en/reserved.variables.server.php">$_SERVER['HTTP_HOST']</link></literal>) <del> those can be added using </del> <ins> it's needed to add them to </ins> <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>. </para> <ins> <para> Auto updates for Nextcloud apps can be enabled using <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </ins> </section> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Pitfalls</title>


Question: are used internally to configure an HTTP server using <literal><link xlink:href="https://php-fpm.org/">PHP-FPM</link></literal> and <literal>nginx</literal>. The <literal>config</literal> attribute set is <del> used for the <literal>config.php</literal> which is used for the application's configuration. <emphasis>Beware: this isn't entirely pure since the config is modified by the application's runtime!</emphasis> </del> <ins> used by the imperative installer and all values are written to an additional file to ensure that changes can be applied by changing the module's options. </ins> </para> <para> <del> In case the application serves multiple hosts (those are checked with </del> <ins> In case the application serves multiple domains (those are checked with </ins> <literal><link xlink:href="http://php.net/manual/en/reserved.variables.server.php">$_SERVER['HTTP_HOST']</link></literal>) <del> those can be added using </del> <ins> it's needed to add them to </ins> <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>. </para> <ins> <para> Auto updates for Nextcloud apps can be enabled using <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </ins> </section> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Pitfalls</title>


Question: are used internally to configure an HTTP server using <literal><link xlink:href="https://php-fpm.org/">PHP-FPM</link></literal> and <literal>nginx</literal>. The <literal>config</literal> attribute set is <del> used for the <literal>config.php</literal> which is used for the application's configuration. <emphasis>Beware: this isn't entirely pure since the config is modified by the application's runtime!</emphasis> </del> <ins> used by the imperative installer and all values are written to an additional file to ensure that changes can be applied by changing the module's options. </ins> </para> <para> <del> In case the application serves multiple hosts (those are checked with </del> <ins> In case the application serves multiple domains (those are checked with </ins> <literal><link xlink:href="http://php.net/manual/en/reserved.variables.server.php">$_SERVER['HTTP_HOST']</link></literal>) <del> those can be added using </del> <ins> it's needed to add them to </ins> <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>. </para> <ins> <para> Auto updates for Nextcloud apps can be enabled using <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </ins> </section> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Pitfalls</title>


Question: libsoup gnome3.gnome-settings-daemon gnome3.nautilus gnome3.mutter gnome3.gnome-desktop gobjectIntrospection gnome3.nautilus <ins> # Makes it possible to select user themes through the `user-theme` extension gnome3.gnome-shell-extensions </ins> ]; postPatch = ''

The meson build doesn't compile the schemas, opting to do it instead in a package shell script. Unfortunately it seems that compiling the schemas aren't enough to make all the extensions work. In particular at least and still won't work (seems to fix though). With the schemas installed Tweaks simply complains that the extension is incorrectly installed. complains about lacking any typelib file for . I'm not sure how well these extensions worked before 3.28, but a report on irc indicated that at least worked before. cc Run Tweaks on nixos-unstable, try to enable eg. the extension under or . Running a schema fix on top of system: host os: multi-user?: sandbox: version: channels(hed): channels(root): nixpkgs:
The extension works for me when I manually change the directory structure to: As for the , I removed from dependencies so that might explain this failure. The extension should probably be fixed like .
You're able to switch switch themes in in Tweaks? Might be something wrong on my end. I'll submit a PR fixing the schemas at least.
Testing out a fix for .
Hmm, I can enable it but the theme switching does not work. I seems to require the extension schemas in when running Tweaks. Maybe it got picked up from global for bash users, but the option was always disabled for me with fish.
We might want to add as a dependency to Tweaks so that it could work for non-bash users. Then we will need to fix the schemas: the schemas in and find a hack similar to to add the schemas path to the extension. like the following to put the schemas where extensions can find them and add symlink for Tweaks. same thing as the second point but accomplished by patching files.
Your suggested fix worked for at least :) I went with basically adding the code from to to fix the schema problem. Generating the directory structure you quoted above seems the most sane and keeping with upstream. Tested things out in a vm with bash, and didn't seem to work there either. So not sure if the problem is non bash. Anyway, adding to fixes , so I think that's appropriate. I should've got everything now, will submit a PR :)
I think it only works in bash and globally installed packages or something.


Question: libsoup gnome3.gnome-settings-daemon gnome3.nautilus gnome3.mutter gnome3.gnome-desktop gobjectIntrospection gnome3.nautilus <ins> # Makes it possible to select user themes through the `user-theme` extension gnome3.gnome-shell-extensions </ins> ]; postPatch = ''

I would not rely on it since I consider it an ugly impurity. I would prefer the first solution since it will be the cleanest and could be possibly automated in the future, but number two is fine too.


Question: EOF cat ${certdata2pem} > certdata2pem.py <del> patch -p1 < ${./fix-unicode-ca-names.patch} ${optionalString includeEmail '' # Disable CAs used for mail signing substituteInPlace certdata2pem.py --replace ['CKA_TRUST_EMAIL_PROTECTION'] ''' ''} </del> ''; buildPhase = ''

Describe the bug Putting a valid certificate name in will cause nixos-rebuild to fail. To Reproduce Steps to reproduce the behavior: this line in . This command will fail. Expected behavior finishes sucessfully. Additional context This error message is related to : I guess this error is caused by switching to python 3. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
isn't compatible with Python 3, it seems. We'll need to update or carry a patch.
MRTC:


Question: # For backwards compatibility with removed pkgs/development/interpreters/hy # Example usage: #   hy.withPackages (ps: with ps; [ hyrule requests ]) <del> withPackages = python-packages: python.withPackages (ps: (python-packages ps) ++ [ ps.hy ]); </del> <ins> withPackages = python-packages: (python.withPackages (ps: (python-packages ps) ++ [ ps.hy ])).overrideAttrs (old: { name = "${hy.name}-env"; meta = lib.mergeAttrs (builtins.removeAttrs hy.meta [ "license" ]) { mainProgram = "hy"; }; }); </ins> }; meta = with lib; {

Using with and any packages depending on results in the following error: However, packages not depending on work fine, as does running on packages depending on and entering the manually. Steps to reproduce the behavior: the following flake: and that fails while succeeds. To be dropped in a with packages depending on . <!-- 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.
While I could reproduce your case with nixos-22.05, on master, in both cases, I get dropped to a python shell, not a hy shell. Here is a version of your flake that overrides the so that you land in a hy repl. But I think it would be better to put this into eventually.
I'd done that with , but hadn't thought to do it with ; it works! Thanks! Should one of us submit a pull request?
Or perhaps would want to?
Not really, if you want to open a PR I can review/merge.
Sorry, the instructions for contributing are a little confusing to me; could someone give me a summary of steps I need to take?
Also, I just realized I don't know how to merge this with ...
And my own problem was fixed after changing the way the flake apps were made; thanks for all the help!


Question: # badPlatformsConditions :: AttrSet Bool # Sets `meta.badPlatforms = meta.platforms` if any of the conditions are true. # Example: Broken on a specific architecture when some condition is met (like targeting Jetson). <del> badPlatformsConditions = { }; </del> <ins> badPlatformsConditions = { "No source" = !sourceMatchesHost; }; </ins> # src :: Optional Derivation src = trivial.pipe redistArch [

should have only eliminated the s and removed some of the platform-based (adding new broken/non-buildable attrs), but instead has changed the actual logic. Since that commit, no longer resolves into but into (note the wrong cuda release), later leading to evaluation errors This currently breaks on Steps to reproduce the behavior: We should probably add some tests for the selection logic as well... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. 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: nativeBuildInputs = [ cmake ninja curl git pandoc wrapQtAppsHook copyDesktopItems pkg-config unzip zip ]; buildInputs = [ libGL libGLU xorg.libXxf86vm xorg.libSM <del> freeimage freetype qtbase catch2 fmt </del> <ins> freeimage freetype qtbase qtwayland catch2 fmt </ins> glew miniz tinyxml-2 assimp ]; QT_PLUGIN_PATH = "${qtbase}/${qtbase.qtPluginPrefix}";

Package name: trenchbroom Latest released version: 2024.1 <!-- Search your package here: --- Current version on the unstable channel: 2023.1 Current version on the stable/release channel: 2023.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: cmakeFlags = '' -DSC_WII=OFF <del> -DSC_EL=${if useSCEL then "ON" else "OFF"} </del> <ins> -DSC_EL=${if useSCEL then "ON" else "OFF"} </ins> ''; nativeBuildInputs = [ cmake pkgconfig ]; <del> buildInputs = [ gcc libjack2 libsndfile fftw curl libXt qt readline ] </del> <ins> buildInputs = [ gcc ljack2 libsndfile fftw curl libXt qt readline ] </ins> ++ optional useSCEL emacs; }

nix-shell -p supercollider [anders $ nixos-version (Flounder) [anders $ nix-env --version nix-env (Nix) 1.11.2 [anders $ nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion ""
you use supercollider ?
no, sorry.
Same here:


Question: # A target remains active. Use this to probe the fact that # a service fired eventhough it is not RemainAfterExit <del> systemd.targets."acme-finished-a.example.test" = {}; systemd.services."acme-a.example.test" = { wants = [ "acme-finished-a.example.test.target" ]; before = [ "acme-finished-a.example.test.target" ]; after = [ "nginx.service" ]; </del> <ins> systemd.targets."acme-finished-a.example.test" = { after = [ "acme-a.example.test.service" ]; wantedBy = [ "acme-a.example.test.service" ]; </ins> }; services.nginx.enable = true;

I use enabled. I also have a web server service that specifies: Because my web server is a bit long to start, the timeout and its systemd unit fails. To Reproduce Use the following example module: Expected behavior The acme systemd units created by  should wait that nginx is started before starting. Metadata Maintainer information:
Should adding to what is already to  fix the issue?
Making a note that has the same code and presumably the same issue so any fix on should likely be ported to .
Thank you for the issue and reproducer. I'll have a closer look at this today
what exactly do you mean by "timeout" here by the way. could you provide some journal logs of this failure? I can try reproduce when I'm home, but maybe the logs are enough to understand what is going wrong
I mean "Timeout during connect (likely firewall problem)" in the logs below. Note that the hostname, email and domain have been redacted. Also notice the long time between and . nginx was not started when the Let's Encrypt tried to retrieve the challenge:
I'm scared that won't work. The lack of here is very deliberate pulls in (Through and ) to create fake certs, as nginx crashes hard when certificate paths aren't present. We want to start up before the acme challenge is initiated, as nginx is responsible for serving the director to complete it. If starts before nginx, it will always fail. It's all a bit mind-boggling and the dependencies are a bit complicated. I wish it was a bit more simpler too. However; isn't what we want here instead? We want to guarentee that is running before the certificate request is fired off. So adding a to might work? I'll see if that fixes it..
Absolutely, that is what I meant but I wrote it wrongly.
Should we go for the solution proposed?
Yep. I have a PR in the works on my machine. I'll try to get it out this week


Question: patches = [ ./fedora-fixes.patch ]; <ins> # Fix for #40213, probably permanent, because upstream doesn't seem to be # developed anymore. Alternatively, gcc7Stdenv could be used. NIX_CFLAGS_COMPILE = "-Wno-error=array-bounds"; </ins> meta = with stdenv.lib; { homepage = https://sourceforge.net/projects/omxil/; description = "An opensource implementation of the Khronos OpenMAX Integration Layer API to access multimedia components";

On the , quite a few jobs are failing because libomxil-bellagio fails to build (, for an example). cc (as the package maintainer)
Copy-paste from IRC (for the record)


Question: <del> { lib, stdenv, pixie, fetchFromGitHub }: </del> <ins> { lib, stdenv, fetchFromGitHub , pixie, rlwrap }: </ins> stdenv.mkDerivation rec { pname = "dust";

Running reports: To Reproduce on NixOS 19.09. . Metadata I ran but got .
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
I had this same problem today.
I marked this as stale due to inactivity. →
Not stale; this is still a problem on a flakes based NixOS system using


Question: rich-rst = callPackage ../development/python-modules/rich-rst { }; <ins> rich-theme-manager = callPackage ../development/python-modules/rich-theme-manager { }; </ins> ring-doorbell = callPackage ../development/python-modules/ring-doorbell { }; rio-tiler = callPackage ../development/python-modules/rio-tiler { };

Project description Python app to work with pictures and associated metadata from Apple Photos on macOS. Also includes a package to provide programmatic access to the Photos library, pictures, and metadata. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This was the most complex package i ever tried to write :sweat_smile:


Question: ./programs/nm-applet.nix ./programs/npm.nix ./programs/oblogout.nix <ins> ./programs/partition-manager.nix </ins> ./programs/plotinus.nix ./programs/proxychains.nix ./programs/qt5ct.nix

Describe the bug and failed to build on current master (). (The former depends on the latter.) Build log: To Reproduce Steps to reproduce the behavior: nixpkgs master. (or ) the build error. 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. Maintainer information:


Question: ./programs/nm-applet.nix ./programs/npm.nix ./programs/oblogout.nix <ins> ./programs/partition-manager.nix </ins> ./programs/plotinus.nix ./programs/proxychains.nix ./programs/qt5ct.nix

Describe the bug If you open KDE Partition Manager using its file, it tells you that you aren't running it as root, and you won't be able to make any changes with it (rendering the program useless). The only workaround is running (which is probably unintuitive to people with less linux experience) or changing the file (a bad idea when you want Nix to manage your system) To Reproduce Steps to reproduce the behavior: by adding it to your the file (e.g. in KDE, click on the start menu in the bottom left, type in partition manager, and click on the program) Expected behavior Use when clicking the file for a seamless experience Screenshots ! Additional context The message mentions so I tried adding it to by hand, but that did not work. Metadata Maintainer information:
Looks like the package is out of date. This dialogue does not appear to be part of the latest version:
This might work
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 . on the on .


Question: <ins> diff --git a/meson.build b/meson.build index 5030d0c..6de7a20 100644 --- a/meson.build +++ b/meson.build @@ -32,10 +32,11 @@ transmission_dep = declare_dependency( meson.get_compiler('c').find_library('dht'), meson.get_compiler('c').find_library('natpmp'), meson.get_compiler('c').find_library('event'), -				meson.get_compiler('c').find_library('libcurl'), -				meson.get_compiler('c').find_library('libcrypto'), +				meson.get_compiler('c').find_library('curl'), +				meson.get_compiler('c').find_library('crypto'), +				meson.get_compiler('c').find_library('ssl'), meson.get_compiler('c').find_library('libpthread'), -				meson.get_compiler('c').find_library('libz'), +				meson.get_compiler('c').find_library('z'), transmission_vapi, transmission_lib ]) @@ -45,4 +46,4 @@ subdir('data') subdir('po') subdir('src') -meson.add_install_script('build-aux/postinstall.py') +meson.add_install_script('python3', '../build-aux/postinstall.py') </ins>


Question: + +case $1 in +    ""|"repl") <del> +        rlwrap_cmd="" +        if [ -n "`which rlwrap`" ]; then +            rlwrap_cmd="rlwrap -aignored -n" +        fi +        $rlwrap_cmd $pixie_path $load_path </del> <ins> +        $rlwrap_cmd -aignored -n $pixie_path $load_path </ins> +        ;; +    "run") +        shift


Question: --replace /usr/bin/perl "${perl}/bin/perl" substituteInPlace src/lib/Gitolite/Hooks/Update.pm  --replace /usr/bin/perl "${perl}/bin/perl" <ins> substituteInPlace src/lib/Gitolite/Setup.pm  --replace hostname "${nettools}/bin/hostname" </ins> ''; installPhase = ''

I don't know much more than this: and but I don't know how to fix this.
I was bit by this as well. It fails on other key for me -- looks like it would fail on any.
How did you solve this issue?
Can someone tell me where this "keydir" should be located? I cannot find it in my !
The keydir should be in your gitolite datadir, which is /var/lib/gitolite in the default settings.
Okay. My shows:
oh it should be in "/var/lib/gitolite/.gitolite/keydir", my bad.
Okay, everything is there. How to check why it fails?
It failed for me for every key on v3.6.2. So, besides upgrading gitolite to v3.6.3, there is not really much you can do.
Update solved the issue.


Question: environment.systemPackages = [ alsaUtils ]; <del> environment.etc = mkIf (config.sound.extraConfig != "") </del> <ins> environment.etc = mkIf (!pulseaudioEnabled && config.sound.extraConfig != "") </ins> [ { source = pkgs.writeText "asound.conf" config.sound.extraConfig; target = "asound.conf";

Setting to while setting to any non-empty value will cause a build failure because and both attempt to create The correct result would be for the contents of to be written out at the end of , after the stanzas provided by pulseaudio. Somewhat relatedly, the in and in pulseaudio's generated config doesn't make a whole lot of sense. means "override", currently there is nothing for it to override, and we would like user config to override generated config, not the other way around. However, as long as user config is placed in the file after generated config then I don't think the actually makes any difference.
I am having this issue as well. Easily replicated by setting those two options.
Can you make a pull request?
Should be fixed with . If there still is a problem, please reopen this issue.


Question: <ins> diff --git a/setup.py b/setup.py index 62db8af..4a980c1 100755 --- a/setup.py +++ b/setup.py @@ -52,7 +52,7 @@ setuptools.setup( 'ruamel.yaml>0.15.69', 'jsonschema>=4.1.2', 'rfc3987', -        'pylibfdt', +        'libfdt', ], classifiers=[ </ins>

<!-- 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: dt-schema <!-- 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: 2022.1 desired version: 2022.12 <!-- 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.
A new version is out: Should I just update this and my PR to make use of this new version?


Question: enableExtraPlugins = true; }; <del> asciidoctor = callPackage ../tools/typesetting/asciidoctor { }; </del> <ins> asciidoctor = callPackage ../tools/typesetting/asciidoctor { bundlerApp = bundlerApp.override { # asciidoc supports both ruby 2 and 3, # but we don't want to be stuck on it: ruby = ruby_3_1; }; }; </ins> asciidoctor-with-extensions = callPackage ../tools/typesetting/asciidoctor-with-extensions { };

Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . nix-build '<nixpkgs' -A ... --check --keep-failed You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: nix-store --read-log $(nix-instantiate '<nixpkgs' -A ...) Seems to be a file ordering issue while generating : vs
Looks like this list is generated with the standard Ruby function, which in 2.x leaves the sorting up to the filesystem, but from 3.x onwards itself. So perhaps we should just update to Ruby 3.x. In general 2.7 is in mode, so it will only receive security updates and we should probably plan to move things to 3.x