Question: }; }; <ins> listenOptions = { options = { address = mkOption { type = types.str; description = lib.mdDoc '' Address of the interface for `upsd` to listen on. See `man upsd.conf` for details. ''; }; port = mkOption { type = types.port; default = defaultPort; description = lib.mdDoc '' TCP port for `upsd` to listen on. See `man upsd.conf` for details. ''; }; }; }; upsdOptions = { options = { enable = mkOption { type = types.bool; defaultText = literalMD "`true` if `mode` is one of `standalone`, `netserver`"; description = mdDoc "Whether to enable `upsd`."; }; listen = mkOption { type = with types; listOf (submodule listenOptions); default = []; example = [ { address = "192.168.50.1"; } { address = "::1"; port = 5923; } ]; description = lib.mdDoc '' Address of the interface for `upsd` to listen on. See `man upsd` for details`. ''; }; extraConfig = mkOption { type = types.lines; default = ""; description = lib.mdDoc '' Additional lines to add to `upsd.conf`. ''; }; }; config = { enable = mkDefault (elem cfg.mode [ "standalone" "netserver" ]); }; }; monitorOptions = { name, config, ... }: { options = { system = mkOption { type = types.str; default = name; description = lib.mdDoc '' Identifier of the UPS to monitor, in this form: `<upsname>[@<hostname>[:<port>]]` See `upsmon.conf` for details. ''; }; powerValue = mkOption { type = types.int; default = 1; description = lib.mdDoc '' Number of power supplies that the UPS feeds on this system. See `upsmon.conf` for details. ''; }; user = mkOption { type = types.str; description = lib.mdDoc '' Username from `upsd.users` for accessing this UPS. See `upsmon.conf` for details. ''; }; passwordFile = mkOption { type = types.str; defaultText = literalMD "power.ups.users.${user}.passwordFile"; description = lib.mdDoc '' The full path to a file containing the password from `upsd.users` for accessing this UPS. The password file is read on service start. See `upsmon.conf` for details. ''; }; type = mkOption { type = types.str; default = "master"; description = lib.mdDoc '' The relationship with `upsd`. See `upsmon.conf` for details. ''; }; }; config = { passwordFile = mkDefault cfg.users.${config.user}.passwordFile; }; }; upsmonOptions = { options = { enable = mkOption { type = types.bool; defaultText = literalMD "`true` if `mode` is one of `standalone`, `netserver`, `netclient`"; description = mdDoc "Whether to enable `upsmon`."; }; monitor = mkOption { type = with types; attrsOf (submodule monitorOptions); default = {}; description = lib.mdDoc '' Set of UPS to monitor. See `man upsmon.conf` for details. ''; }; settings = mkOption { type = nutFormat.type; default = {}; defaultText = literalMD '' { MINSUPPLIES = 1; RUN_AS_USER = "root"; NOTIFYCMD = "''${pkgs.nut}/bin/upssched"; SHUTDOWNCMD = "''${pkgs.systemd}/bin/shutdown now"; } ''; description = mdDoc "Additional settings to add to `upsmon.conf`."; example = literalMD '' { MINSUPPLIES = 2; NOTIFYFLAG = [ [ "ONLINE" "SYSLOG+EXEC" ] [ "ONBATT" "SYSLOG+EXEC" ] ]; } ''; }; }; config = { enable = mkDefault (elem cfg.mode [ "standalone" "netserver" "netclient" ]); settings = { RUN_AS_USER = "root"; # TODO: replace 'root' by another username. MINSUPPLIES = mkDefault 1; NOTIFYCMD = mkDefault "${pkgs.nut}/bin/upssched"; SHUTDOWNCMD = mkDefault "${pkgs.systemd}/bin/shutdown now"; MONITOR = flip mapAttrsToList cfg.upsmon.monitor (name: monitor: with monitor; [ system powerValue user ""@upsmon_password_${name}@"" type ]); }; }; }; userOptions = { options = { passwordFile = mkOption { type = types.str; description = lib.mdDoc '' The full path to a file that contains the user's (clear text) password. The password file is read on service start. ''; }; actions = mkOption { type = with types; listOf str; default = []; description = lib.mdDoc '' Allow the user to do certain things with upsd. See `man upsd.users` for details. ''; }; instcmds = mkOption { type = with types; listOf str; default = []; description = lib.mdDoc '' Let the user initiate specific instant commands. Use "ALL" to grant all commands automatically. For the full list of what your UPS supports, use "upscmd -l". See `man upsd.users` for details. ''; }; upsmon = mkOption { type = with types; nullOr str; default = null; description = lib.mdDoc '' Add the necessary actions for a upsmon process to work. See `man upsd.users` for details. ''; }; }; }; </ins> in

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: }; }; <ins> listenOptions = { options = { address = mkOption { type = types.str; description = lib.mdDoc '' Address of the interface for `upsd` to listen on. See `man upsd.conf` for details. ''; }; port = mkOption { type = types.port; default = defaultPort; description = lib.mdDoc '' TCP port for `upsd` to listen on. See `man upsd.conf` for details. ''; }; }; }; upsdOptions = { options = { enable = mkOption { type = types.bool; defaultText = literalMD "`true` if `mode` is one of `standalone`, `netserver`"; description = mdDoc "Whether to enable `upsd`."; }; listen = mkOption { type = with types; listOf (submodule listenOptions); default = []; example = [ { address = "192.168.50.1"; } { address = "::1"; port = 5923; } ]; description = lib.mdDoc '' Address of the interface for `upsd` to listen on. See `man upsd` for details`. ''; }; extraConfig = mkOption { type = types.lines; default = ""; description = lib.mdDoc '' Additional lines to add to `upsd.conf`. ''; }; }; config = { enable = mkDefault (elem cfg.mode [ "standalone" "netserver" ]); }; }; monitorOptions = { name, config, ... }: { options = { system = mkOption { type = types.str; default = name; description = lib.mdDoc '' Identifier of the UPS to monitor, in this form: `<upsname>[@<hostname>[:<port>]]` See `upsmon.conf` for details. ''; }; powerValue = mkOption { type = types.int; default = 1; description = lib.mdDoc '' Number of power supplies that the UPS feeds on this system. See `upsmon.conf` for details. ''; }; user = mkOption { type = types.str; description = lib.mdDoc '' Username from `upsd.users` for accessing this UPS. See `upsmon.conf` for details. ''; }; passwordFile = mkOption { type = types.str; defaultText = literalMD "power.ups.users.${user}.passwordFile"; description = lib.mdDoc '' The full path to a file containing the password from `upsd.users` for accessing this UPS. The password file is read on service start. See `upsmon.conf` for details. ''; }; type = mkOption { type = types.str; default = "master"; description = lib.mdDoc '' The relationship with `upsd`. See `upsmon.conf` for details. ''; }; }; config = { passwordFile = mkDefault cfg.users.${config.user}.passwordFile; }; }; upsmonOptions = { options = { enable = mkOption { type = types.bool; defaultText = literalMD "`true` if `mode` is one of `standalone`, `netserver`, `netclient`"; description = mdDoc "Whether to enable `upsmon`."; }; monitor = mkOption { type = with types; attrsOf (submodule monitorOptions); default = {}; description = lib.mdDoc '' Set of UPS to monitor. See `man upsmon.conf` for details. ''; }; settings = mkOption { type = nutFormat.type; default = {}; defaultText = literalMD '' { MINSUPPLIES = 1; RUN_AS_USER = "root"; NOTIFYCMD = "''${pkgs.nut}/bin/upssched"; SHUTDOWNCMD = "''${pkgs.systemd}/bin/shutdown now"; } ''; description = mdDoc "Additional settings to add to `upsmon.conf`."; example = literalMD '' { MINSUPPLIES = 2; NOTIFYFLAG = [ [ "ONLINE" "SYSLOG+EXEC" ] [ "ONBATT" "SYSLOG+EXEC" ] ]; } ''; }; }; config = { enable = mkDefault (elem cfg.mode [ "standalone" "netserver" "netclient" ]); settings = { RUN_AS_USER = "root"; # TODO: replace 'root' by another username. MINSUPPLIES = mkDefault 1; NOTIFYCMD = mkDefault "${pkgs.nut}/bin/upssched"; SHUTDOWNCMD = mkDefault "${pkgs.systemd}/bin/shutdown now"; MONITOR = flip mapAttrsToList cfg.upsmon.monitor (name: monitor: with monitor; [ system powerValue user ""@upsmon_password_${name}@"" type ]); }; }; }; userOptions = { options = { passwordFile = mkOption { type = types.str; description = lib.mdDoc '' The full path to a file that contains the user's (clear text) password. The password file is read on service start. ''; }; actions = mkOption { type = with types; listOf str; default = []; description = lib.mdDoc '' Allow the user to do certain things with upsd. See `man upsd.users` for details. ''; }; instcmds = mkOption { type = with types; listOf str; default = []; description = lib.mdDoc '' Let the user initiate specific instant commands. Use "ALL" to grant all commands automatically. For the full list of what your UPS supports, use "upscmd -l". See `man upsd.users` for details. ''; }; upsmon = mkOption { type = with types; nullOr str; default = null; description = lib.mdDoc '' Add the necessary actions for a upsmon process to work. See `man upsd.users` for details. ''; }; }; }; </ins> in

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: }; }; <ins> listenOptions = { options = { address = mkOption { type = types.str; description = lib.mdDoc '' Address of the interface for `upsd` to listen on. See `man upsd.conf` for details. ''; }; port = mkOption { type = types.port; default = defaultPort; description = lib.mdDoc '' TCP port for `upsd` to listen on. See `man upsd.conf` for details. ''; }; }; }; upsdOptions = { options = { enable = mkOption { type = types.bool; defaultText = literalMD "`true` if `mode` is one of `standalone`, `netserver`"; description = mdDoc "Whether to enable `upsd`."; }; listen = mkOption { type = with types; listOf (submodule listenOptions); default = []; example = [ { address = "192.168.50.1"; } { address = "::1"; port = 5923; } ]; description = lib.mdDoc '' Address of the interface for `upsd` to listen on. See `man upsd` for details`. ''; }; extraConfig = mkOption { type = types.lines; default = ""; description = lib.mdDoc '' Additional lines to add to `upsd.conf`. ''; }; }; config = { enable = mkDefault (elem cfg.mode [ "standalone" "netserver" ]); }; }; monitorOptions = { name, config, ... }: { options = { system = mkOption { type = types.str; default = name; description = lib.mdDoc '' Identifier of the UPS to monitor, in this form: `<upsname>[@<hostname>[:<port>]]` See `upsmon.conf` for details. ''; }; powerValue = mkOption { type = types.int; default = 1; description = lib.mdDoc '' Number of power supplies that the UPS feeds on this system. See `upsmon.conf` for details. ''; }; user = mkOption { type = types.str; description = lib.mdDoc '' Username from `upsd.users` for accessing this UPS. See `upsmon.conf` for details. ''; }; passwordFile = mkOption { type = types.str; defaultText = literalMD "power.ups.users.${user}.passwordFile"; description = lib.mdDoc '' The full path to a file containing the password from `upsd.users` for accessing this UPS. The password file is read on service start. See `upsmon.conf` for details. ''; }; type = mkOption { type = types.str; default = "master"; description = lib.mdDoc '' The relationship with `upsd`. See `upsmon.conf` for details. ''; }; }; config = { passwordFile = mkDefault cfg.users.${config.user}.passwordFile; }; }; upsmonOptions = { options = { enable = mkOption { type = types.bool; defaultText = literalMD "`true` if `mode` is one of `standalone`, `netserver`, `netclient`"; description = mdDoc "Whether to enable `upsmon`."; }; monitor = mkOption { type = with types; attrsOf (submodule monitorOptions); default = {}; description = lib.mdDoc '' Set of UPS to monitor. See `man upsmon.conf` for details. ''; }; settings = mkOption { type = nutFormat.type; default = {}; defaultText = literalMD '' { MINSUPPLIES = 1; RUN_AS_USER = "root"; NOTIFYCMD = "''${pkgs.nut}/bin/upssched"; SHUTDOWNCMD = "''${pkgs.systemd}/bin/shutdown now"; } ''; description = mdDoc "Additional settings to add to `upsmon.conf`."; example = literalMD '' { MINSUPPLIES = 2; NOTIFYFLAG = [ [ "ONLINE" "SYSLOG+EXEC" ] [ "ONBATT" "SYSLOG+EXEC" ] ]; } ''; }; }; config = { enable = mkDefault (elem cfg.mode [ "standalone" "netserver" "netclient" ]); settings = { RUN_AS_USER = "root"; # TODO: replace 'root' by another username. MINSUPPLIES = mkDefault 1; NOTIFYCMD = mkDefault "${pkgs.nut}/bin/upssched"; SHUTDOWNCMD = mkDefault "${pkgs.systemd}/bin/shutdown now"; MONITOR = flip mapAttrsToList cfg.upsmon.monitor (name: monitor: with monitor; [ system powerValue user ""@upsmon_password_${name}@"" type ]); }; }; }; userOptions = { options = { passwordFile = mkOption { type = types.str; description = lib.mdDoc '' The full path to a file that contains the user's (clear text) password. The password file is read on service start. ''; }; actions = mkOption { type = with types; listOf str; default = []; description = lib.mdDoc '' Allow the user to do certain things with upsd. See `man upsd.users` for details. ''; }; instcmds = mkOption { type = with types; listOf str; default = []; description = lib.mdDoc '' Let the user initiate specific instant commands. Use "ALL" to grant all commands automatically. For the full list of what your UPS supports, use "upscmd -l". See `man upsd.users` for details. ''; }; upsmon = mkOption { type = with types; nullOr str; default = null; description = lib.mdDoc '' Add the necessary actions for a upsmon process to work. See `man upsd.users` for details. ''; }; }; }; </ins> in

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: | Find libraries | `configurePhase` | Missing dependency on a `dev` output | Add the missing dependency | The `dev` output typically contain CMake configuration files | | Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries | <del> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`cudaPackages.autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=cudaPackages.autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </del> <ins> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </ins>

Directory renaming is now out of scope This directory is also being used as the way to get access to the host machines gpu drivers. I think it's another source of confusion for many users to have to add so that they can get a vulkan game / cuda workload / opencl workload to work. I think we should deprecate this prior to the 21.11 release, and fully move it to something like or something more representative of the desired affect. This was done in cc EDIT: roadmap (2.5 years later... lol): addOpenGLRunpath -addDriverRunpath Init addDriverRunpath: Deprecate : -autoAddDriverRunpath Init autoAddDriverRunpath: Deprecate cudaPackages.autoAdd{OpenGLRunpathHook,DriverRunpath}: NixOS Module changes: TODO
For the transition period ( NixOS 21.11), I think keeping the old would help alleviate a lot of the pain, would just like to get the ball rolling away from using explicitly
I agree. Also, on a related note, having to specify your graphics driver at the xserver level in the module system feels wrong to me. I'm still not exactly sure how it maps given names to driver packages either.
I propose two changes: move -- make a symlink to for backwards compatibility of existing derivations -- add a
potential future work as well: -- Until 21.11 EOL, have it add both and , to avoid system vs package invariance
I'm also kind of wondering whether is just another fallacy in naming, and we should really be exposing something like, would be even more appropriate, as other hardware-accelerated devices such as tpus, fpga's, and others would also likely need to import "libraries which are determined by the system, and need to be available at runtime".
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Should we, in addition, consider using a libc-versioned directory? Motivated by
Decided to rename this issue since renaming the underlying path was deemed too risky for potential breakages.
Could you provide some context as to why? My naive assumption was that we'd have a new path but: have both new and legacy path to rpath via the hook; new path preferred provide a legacy symlink pointing at the new path in NixOS which would be quite trivial.


Question: | Find libraries | `configurePhase` | Missing dependency on a `dev` output | Add the missing dependency | The `dev` output typically contain CMake configuration files | | Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries | <del> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`cudaPackages.autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=cudaPackages.autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </del> <ins> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </ins>

TBH, I'm not sure how much value there is to migrating the filesystem path (unless we splay the paths further to increase granularity). I suspect what users see in practice is the nixos option path
For the NixOS module change, I came up with these terms: acceleration API = an API standard which intends to provide hardware-assisted compute acceleration such as OpenGL, Vulkan or CUDA driver = userspace library component which implements one or more hardware-based acceleration APIs The usage of the NixOS options API would then look a little like this: Individual drivers would also have a option which is a package selector for the specific package to use aswell as driver-specific settings. (More on the package selector data type when I have a more concrete implementation but it'd allow setting 64/32 bit using a single value.) Each acceleration API would have a option which is an attrset with driver names as keys and package selectors as values. These could then be overridden indivually. The intention behind this is to enable use-cases where e.g. different versions of the same driver are required for different APIs or a specific driver must be disabled for one API but enabled in all others. All enabling a driver would do would be to insert the driver's package into the options of all APIs that it implements. Additionally, accel APIs have a option if the API supports setting one and of course API-specific knobs. Here's an example of how a non-trivial driver config could look like: It's currently not possible to know which implements which driver and all drivers are thrown into the same directory but the NixOS API drafted above requires this information for fine-grained control, so we will have to define an interface here. I've been thinking of defining the output to contain all driver bits and subdivide it into driver subdirs like this vulkan/... cuda/... opengl/... Alternatively, I had thought of using multiple outputs; one for each driver. I kinda like that approach more as it generally strikes me as cleaner and has the potential to reduce closure size ( is ~200M) but am not sure about potential naming conflicts or other downsides of those. In light of this, I'd also like to propose to split the global lib dirs into accel API subdirs for clean separation. Though as said, the NixOS options are a lot more critical to UX and therefore the first steps.


Question: | Find libraries | `configurePhase` | Missing dependency on a `dev` output | Add the missing dependency | The `dev` output typically contain CMake configuration files | | Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries | <del> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`cudaPackages.autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=cudaPackages.autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </del> <ins> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </ins>

Global path name and other changes are almost entirely tangential and could happen independantly but I'd appreciate if they came after the NixOS options changes such that we can let the knowledge we gained from the NixOS options influence their design. Anyhow, that's my current draft. Let me know what you think.
My naive assumption was that we'd have a new path but: That was my initial take as well, but there's community projects like nixGL and others who likely have hard coded the path. And there's a potential that we could never fully remove it without breaking someone
Forgive my ignorance, but wouldn't it be ok to make those kinda breaking changes by deprecating in one release and then removing one or two releases later? Surely nixos isn't promising to never change paths because someone might be using the old location? EDIT:I don't mean to imply we shouldn't consider non-breaking options where possible
nixGL only sets the LDLIBRARYPATH? Although in all probability we must break someone's workflow... Fun fact: cudaPackages don't ship the driver (except for for jetsons). All the relevant stuff comes with nvidia_x11 or with the datacenter driver. Interesting. Would we somehow have to filter the glvnd/opencl loader/vulkan loader configs that come with the drivers to enforce that the declarative configuration be implemented?
nixGL appears to be actively maintained. I don't think we need to worry about breaking it as they can simply adapt. Also, we could simply keep providing the old path in both NixOS and binaries with a preference for the new path and that should work out fine. Oh, okay. I'll leave it to you CUDA people to figure that out. I will only be lifting drivers to this interface on a best-effort basis and the rest will keep using their legacy interface with a minor implementation change. Though if you forsee possible issues you could have mapping your driver to this interface, let me know so that we can design the interface better from the start. That or simply write our own. Though I'll only be adding the option where it is feasible; currently, I only know that Vulkan has sane mechanisms for this. Some issues I still need to think about:How to handle drivers that only support 64 bit?


Question: | Find libraries | `configurePhase` | Missing dependency on a `dev` output | Add the missing dependency | The `dev` output typically contain CMake configuration files | | Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries | <del> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`cudaPackages.autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=cudaPackages.autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </del> <ins> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </ins>

Will have to filter that somehow How to handle APIs that can only have a single exclusive driver? Only have a option on the API, rather than ? Have but only install the default driver?
I think NixGL doesn't care about , it probably just exports an ?
The original protest against renaming the path: I feel more strongly about the NixOS options being intuitive than the implementation consistent.
I think was more concerned with it being placed under rather than some other directory in because is very much NixOS-specific while the current is not.
I believe I got all of the packages. Once merged, I should be able to deprecate
This thread is over my head, but I would like to check it , , and need the same? All three have GPU or CUDA support options.
This is more about deprecating usage of the term , as it's a bit of a misnomer. I don't see usage of the legacy OpenGL helpers in those packages.
Talked to , we concluded that we can close this ticket and have a more "NixOS options" specific ticket to represent that work.
Going to do one last pass on documentation to ensure all references have been updated. I'll close this ticket after that sweep
I wonder if needs an update. I'm not offering a PR because I'm out of context. Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating].
Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating]. It should come from the toplevel scope now, so it should never need to default to pulling them out of cudaPackages. I can update the nix expression though.


Question: <del> { lib, buildPythonPackage, fetchPypi, unrar }: </del> <ins> { lib, stdenv, buildPythonPackage, fetchPypi, unrar }: </ins> buildPythonPackage rec { pname = "unrardll";

Steps to reproduce the behavior: Happens on intel darwin. Please run and paste the result.
The .so dependency should be fixed up:


Question: setuid = true; owner = "root"; group = "root"; <del> source = "/run/${dirName}/nix-helpers/qemu-bridge-helper"; </del> <ins> source = "${cfg.qemu.package}/libexec/qemu-bridge-helper"; </ins> }; systemd.packages = [ cfg.package ];

When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.


Question: setuid = true; owner = "root"; group = "root"; <del> source = "/run/${dirName}/nix-helpers/qemu-bridge-helper"; </del> <ins> source = "${cfg.qemu.package}/libexec/qemu-bridge-helper"; </ins> }; systemd.packages = [ cfg.package ];

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


Question: <ins> { lib, stdenv, fetchFromGitea, }: stdenv.mkDerivation rec { pname = "game-devices-udev-rules"; version = "0.21"; src = fetchFromGitea { domain = "codeberg.org"; owner = "fabiscafe"; repo = "game-devices-udev"; rev = version; hash = "sha256-Yy91yDF5BSDTTlr/Pj8e0UklPooEdzvRW8mkhdHtHVo="; }; installPhase = '' runHook preInstall install -Dm444 -t "$out/lib/udev/rules.d" *.rules runHook postInstall ''; meta = with lib; { description = "Udev rules to make supported controllers available with user-grade permissions"; homepage = "https://codeberg.org/fabiscafe/game-devices-udev"; license = licenses.mit; longDescription = '' These udev rules are intended to be used as a package under 'services.udev.packages'. They will not be activated if installed as 'environment.systemPackages' or 'users.user.<user>.packages'. Additionally, you may need to enable 'hardware.uinput'. ''; platforms = platforms.linux; maintainers = with maintainers; [keenanweaver]; }; } </ins>

Project description udev rules to make supported controllers available with user-grade permissions Metadata homepage URL: source URL: license: mit platforms: linux


Question: ${keyboard.config} ''; <ins> # Only the config file generated by this module is checked.  A # user-provided one is not checked because it may not be available # at build time.  I think this is a good balance between module # complexity and functionality. </ins> checkPhase = '' ${getExe cfg.package} --cfg "$target" --check --debug '';

Currently it's only possible to configure kanata by specifying specific parts one at a time. It's not possible to read a configuration from a file and use that instead of the specific parts. I use HomeManager to manage the kanata configuration file and because it's also used for Windows this is the most platform neutral way for me without duplicating parts of the configuration. As a workaround I did it like this for now: But clearly that is not ideal. What I would want is to just keep the 'readFile' and uncomment the 'defcfg' part from the configuration file ()
I created to address this issue. Could you help test it?
Thanks a lot for the fast solution! I tested it with my config and it works without any issues.


Question: webdis = callPackage ../development/tools/database/webdis { }; <ins> xmake = callPackage ../development/tools/build-managers/xmake { lua = lua5_4; }; </ins> xc3sprog = callPackage ../development/embedded/xc3sprog { stdenv = gcc10StdenvCompat; }; xcb-imdkit = callPackage ../development/libraries/xcb-imdkit { };

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


Question: maintainers = [ ]; platforms = stdenv.lib.platforms.all; <ins> priority = 10; </ins> }; }

I have installed a very barebones server with NixOS. Whenever I run it shows the following warnings: I get that it does not matter that much which of these are used, but it makes these commands not very transparent. Why is being used from and not , while is apparently part of ? Should we make sure these packages will not both be part of or should we make sure the files are only available in one of the two packages? up a minimal version of NixOS. the log
These are usually fixable by just setting priority values. coreutils should probably have a lower priority as they are usually cross platform but not as many supported features. The getconf and getent are interesting because they are actually symlinks to glibc. But we might as well make unixtools lower priority as well.
Is this something we should do nixpkgs-wide? Will that avoid the warning messages? I was thinking why these are providing the same files and why both packages are being used. For instance, do we really need openresolv or is that included unintentionally? The priorities is a way to solve this safely, but I feel like there shouldn't be any conflicts for the base packages at all.
Maybe openresolv we can leave out of systemPackages. But, some of these collisions are kind of unavoidable. We need both procps and coreutils even though they both provide kill bunary. It might be interesting to see which other distros use but IIRC they are almost identical
For coreutils, ArchLinux seems to leave out the kill binary: This also feels a bit wrong, as it isn't the original package anymore. Changing the priority does indeed sound like a better option. Coreutils should have a lower priority.
I tried giving coreutils a lower priority, but it doesn't seem to have made a difference for those warnings.
oh it already has lowprio: but it doesn't really work when everything has the same priority.
systemd-resolved is not enable by default so resolvconf shouln't be really pointing to resolvectl. I think the dummy command provided for compatibility doesn't work correctly if resolved is not running and dhcpcd needs it to configure interfaces.
Should we just give openresolv a higher priority than systemd?
Yes, correct.


Question: maintainers = [ ]; platforms = stdenv.lib.platforms.all; <ins> priority = 10; </ins> }; }

The dhcpcd resolvconf hook check if resolvconf is installed and, because the command is in the PATH, it won't fall back to writing directly but will attempt to execute something like this: echo 'nameserver 10.0.1.1' | resolvconf -a wlan0 Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
Reproducible way to see these collisions: With a file set to I ran in the (the latest commit on the branch), and I get these collision messages:
ping
Hi all nixos-version 03. (Koi) I have the same collision on kill gnutar resolvconf but also on collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.


Question: maintainers = [ ]; platforms = stdenv.lib.platforms.all; <ins> priority = 10; </ins> }; }

0/share/icons/hicolor/48x48/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/48x48/apps/phonon-'
This seems to include many more collisions than related to this issue.
Maybe rather than changing the nix-env priority, a better solution is to remove some of these programs (e.g. delete in util-linux's ).
That seems hacky to me. What if you want util-linux's version of kill? Presumably if the maintainer thinks it's worth including, someone has a use for it. Nixpkgs shouldn't be making these decisions at the derivation level. Something like meta seems ideal because you can change it without effecting the derivation.
Since and were merged, does that mean this issue can be closed now?
I think so, I don't see these collisions anymore.
Let me know if this isn't fixed after all.
sorry, but i see these collisions.


Question: maintainers = [ ]; platforms = stdenv.lib.platforms.all; <ins> priority = 10; </ins> }; }

it's a different issue: it seems you're installing both the wrapped and unwrapped version of the same packages. I'd say there's something wrong with your configuration, but if you think otherwise open a new issue.


Question: <ins> { lib , stdenv , fetchFromGitHub , emptyDirectory , writeText , makeBinaryWrapper , gradle , jdk22 , llvmPackages }: let gradleInit = writeText "init.gradle" '' logger.lifecycle 'Replacing Maven repositories with empty directory...' gradle.projectsLoaded { rootProject.allprojects { buildscript { repositories { clear() maven { url '${emptyDirectory}' } } } repositories { clear() maven { url '${emptyDirectory}' } } } } settingsEvaluated { settings -> settings.pluginManagement { repositories { maven { url '${emptyDirectory}' } } } } ''; in stdenv.mkDerivation { pname = "jextract"; version = "unstable-2024-03-13"; src = fetchFromGitHub { owner = "openjdk"; repo = "jextract"; rev = "b9ec8879cff052b463237fdd76382b3a5cd8ff2b"; hash = "sha256-+4AM8pzXPIO/CS3+Rd/jJf2xDvAo7K7FRyNE8rXvk5U="; }; nativeBuildInputs = [ gradle makeBinaryWrapper ]; env = { ORG_GRADLE_PROJECT_llvm_home = llvmPackages.libclang.lib; ORG_GRADLE_PROJECT_jdk22_home = jdk22; }; buildPhase = '' runHook preBuild export GRADLE_USER_HOME=$(mktemp -d) gradle --console plain --init-script "${gradleInit}" assemble runHook postBuild ''; doCheck = true; checkPhase = '' runHook preCheck gradle --console plain --init-script "${gradleInit}" verify runHook postCheck ''; installPhase = '' runHook preInstall mkdir -p $out/opt/ cp -r ./build/jextract $out/opt/jextract makeBinaryWrapper "$out/opt/jextract/bin/jextract" "$out/bin/jextract" runHook postInstall ''; meta = with lib; { description = "A tool which mechanically generates Java bindings from a native library headers"; mainProgram = "jextract"; homepage = "https://github.com/openjdk/jextract"; platforms = jdk22.meta.platforms; license = licenses.gpl2Only; maintainers = with maintainers; [ jlesquembre sharzy ]; }; } </ins>

Package name: jextract (jextract-unstable) Current version on the unstable channel: 2023-11-27 Current version on the stable/release channel: n/a As of today the current release build is (see ) It would be nice for the nixpkgs version to be based on JDK 22 -- which contains the final non-preview release of Java Foreign Function & Memory API (aka "Panama") There are significant changes to that users will want before building/launching projects that use Panama. See: I am wiling to contribute but before we can do this we'll need to build with JDK 22 (see Issue )
It would be great if we could update to be based on JDK 22 :+1: , and we should also keep the current JDK 21 package as a new name (perhaps ?) at the same time, as some downstreams still depend on it and JDK 21 is a LTS version.
So should the first step be to rename the existing package? And leave as JDK 21-based (with a warning, maybe) and then do a separate PR to upgrade to JDK 21?
Update: There is a PR for JDK 22:
I can open a PR to update jextract after gets merged. Considering the significant API changes between JDK 21 and 22, and the fact that jextract itself produces very differnt code if you have to use JDK21 (see ) , is there really value in keeping a jextract version compatible with JDK21?
Awesome! I'm going to test on macOS/aarch64 this weekend, so that will help get it merged. wrote: as some downstreams still depend on it and JDK 21 is a LTS version. JDK 21 is LTS, but Panama (Foreign Functions & Memory API) is a "preview feature" which makes it really hard to build anything real with it (i.e. publish JARs for use by other projects. I even had problems with a Gradle multi-module build). I migrated my project to 22 a few weeks ago and am not looking back (which meant I had to stop using Nix as a source for temporarily.) But, I don't see any harm in renaming the existing to and starting a new one. And we certainly don't want to unnecessarily break anyone's dependencies.


Question: <ins> { lib , stdenv , fetchFromGitHub , emptyDirectory , writeText , makeBinaryWrapper , gradle , jdk22 , llvmPackages }: let gradleInit = writeText "init.gradle" '' logger.lifecycle 'Replacing Maven repositories with empty directory...' gradle.projectsLoaded { rootProject.allprojects { buildscript { repositories { clear() maven { url '${emptyDirectory}' } } } repositories { clear() maven { url '${emptyDirectory}' } } } } settingsEvaluated { settings -> settings.pluginManagement { repositories { maven { url '${emptyDirectory}' } } } } ''; in stdenv.mkDerivation { pname = "jextract"; version = "unstable-2024-03-13"; src = fetchFromGitHub { owner = "openjdk"; repo = "jextract"; rev = "b9ec8879cff052b463237fdd76382b3a5cd8ff2b"; hash = "sha256-+4AM8pzXPIO/CS3+Rd/jJf2xDvAo7K7FRyNE8rXvk5U="; }; nativeBuildInputs = [ gradle makeBinaryWrapper ]; env = { ORG_GRADLE_PROJECT_llvm_home = llvmPackages.libclang.lib; ORG_GRADLE_PROJECT_jdk22_home = jdk22; }; buildPhase = '' runHook preBuild export GRADLE_USER_HOME=$(mktemp -d) gradle --console plain --init-script "${gradleInit}" assemble runHook postBuild ''; doCheck = true; checkPhase = '' runHook preCheck gradle --console plain --init-script "${gradleInit}" verify runHook postCheck ''; installPhase = '' runHook preInstall mkdir -p $out/opt/ cp -r ./build/jextract $out/opt/jextract makeBinaryWrapper "$out/opt/jextract/bin/jextract" "$out/bin/jextract" runHook postInstall ''; meta = with lib; { description = "A tool which mechanically generates Java bindings from a native library headers"; mainProgram = "jextract"; homepage = "https://github.com/openjdk/jextract"; platforms = jdk22.meta.platforms; license = licenses.gpl2Only; maintainers = with maintainers; [ jlesquembre sharzy ]; }; } </ins>

And now that Panama/FF&M is final, I'm hoping it will be possible to use jextract 22 to build headers for JDK 23+. Newer versions of jextract might offer improvements, but headers generated for JDK 22 should work wth JDK 23+ (I don't know what guarantees the JDK makes for that, but this seems a reasonable conclusion given a stable API.)
Nice to hear that, and thanks for your work! IMO, I think it's worth. The point is that JDK 21 is a LTS version, some downstreams prefer to use a LTS version of JDK to develop their projects. For them, if we don't keep JDK 21's , this will be unavailable to them unless they give up on choosing LTS and do some extra effort - porting their project to a newer version of JDK.
I agree. But I also strongly encourage new projects to start with JDK 22 and existing projects to migrate as quickly as possible. Having to make sure "preview mode" is set in the compiler and at runtime can cause various problems with tools and the output of the latest is significantly improved. In general, it's much better to be using a non-LTS JDK with a non-preview feature than and LTS JDK with a preview feature. I migrated my project recently and wish I had migrated to JDK 22 much earlier.
PR has been merged. I gave it a quick test on macOS/aarch64 and it seems to be working. (I used it to build which uses JDK 22 and Panama via Gradle's Java toolchains)


Question: python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

Invoking is producing the following error message: is part of the package so it's just failing to locate it. I'm running on NixOS Unstable.
I believe this issue has been fixed and can be closed:


Question: python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

Travis has been giving build failures because of this: commit seems to be at fault here.. The reason I didn't just fix this this bug and push upstream is because there are two different ways to approach this and I'm not sure which the best course of action is. a) jfsrec removal was intentional, remove all references to jfsrec b) restore jfsrec Here is a listing of all current things pointing to jfsrec:
The jfsrec commit has already been reverted.
thanks for the info


Question: python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

nixos/modules/services/x11/display- has code to load ~/.Xdefaults, but not ~/.Xresources, even though ~/.Xdefaults is the deprecated version of ~/.Xresources


Question: python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

In its builder, there's a command saying "Need libgcc until the llvm compiler-rt library is complete". It's from in 2011, so I'm inclined to think it's out of date and that the dependency on gcc is spurious. Is that true?
For context from #llvm on oftc:
covers , covers , the only thing I'm not sure about is the C runtime files (e.g. ), none of those packages seem to come with them (but maybe clang does it another way)
Actually some of the files come from glibc, but these ones come with gcc: crtprec32.o crtendS.o crtbeginS.o crtfastmath.o crtprec64.o crtbeginT.o crtprec80.o crtbegin.o crtend.o
This story is quite old, is this still true?
Closing because no reaction.


Question: , pillow , toml , numpy <ins> , pyyaml </ins> , python , pytestCheckHook }: buildPythonPackage rec { pname = "clickgen"; <del> version = "2.1.3"; </del> <ins> version = "2.1.9"; </ins> format = "setuptools"; disabled = pythonOlder "3.8";

Package name: clickgen Latest released version: 2.1.9 <!-- Search your package here: --- Current version on the unstable channel: 2.1.3 Current version on the stable/release channel: 2.1.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- 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.


Question: monA.succeed( "ceph osd pool create multi-node-test 32 32", "ceph osd pool ls | grep 'multi-node-test'", <ins> # We need to enable an application on the pool, otherwise it will # stay unhealthy in state POOL_APP_NOT_ENABLED. # Creating a CephFS would do this automatically, but we haven't done that here. # See: https://docs.ceph.com/en/reef/rados/operations/pools/#associating-a-pool-with-an-application # We use the custom application name "nixos-test" for this. "ceph osd pool application enable multi-node-test nixos-test", </ins> "ceph osd pool rename multi-node-test multi-node-other-test", "ceph osd pool ls | grep 'multi-node-other-test'", )

Steps to reproduce the behavior:  nixos-unstable Noticed when setting and rebuilding <!-- 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]:
You won't get a reply if you leave that empty.
I'm having the same issue I didn't notice when it happened, but I also have sambaFull
Same error whit the package .
This seems related to
That turned out not to be the issue. The actual error: In colour so that one can actually make sense of C++ error messages: ! One potential problem here: This is because of having: Switching to : Builds Removing entirely (which swiches to ): Fails on new related errors (see below) Removing and : Fails because Ceph requires lua = 5.3 and nixpkgs's default is still 5.2: CMake saysCould NOT find Lua (missing: LUAINCLUDEDIR) (Required is at least version "5.3")` Build failure with : <details</detailsI noticed Arch . But we can just use to fix the build.
PR for the


Question: quickemu ''; <del> patches = [ # reduces windows vm ram requirements to 4G, to match microsoft recommendations # TODO: remove on next release (fetchpatch2 { name = "decrease-windows-ram-requirements.patch"; url = "https://github.com/quickemu-project/quickemu/commit/f51697593a4650c5486661292e2febe1d16f8c71.patch"; hash = "sha256-J5hIvQGtkufOcjk2FZN65iox/W2zkLlg+Veg9TF11Fs="; }) ]; </del> nativeBuildInputs = [ makeWrapper installShellFiles

There is a bug in the latest release of quickemu (present in nixpkgs), that sends invalid flags to qemu and thus doesn't work for MacOS (maybe others too). The fix I was planning to PR was to simply move the src to point to the most current revision. I wasn't 100% sure if that was something that I should do however, given it would set the precedent that we follow revisions for this package instead of the version tag, which may add maintenance burden. Just wanted opinions before I made a PR, would it be acceptable to bump the revision temporarily to avoid this issue? It's niche but its real and could affect users of this package. Steps to reproduce the behavior: Pops open a Qemu window with the appropriate screens. Fails with a strange "macos-ventura/macos- file not found", but it is related to the bugged release. <!-- 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]:
Don't know of any official policy on this. My opinion: If it's a single commit that fixes the issue, you can add a patch. If it's spread out over multiple commits, use current unstable, but that may introduce other unknown regressions and breaking changes. And in any case we'd go back to the release tag on the next release.
Patching sounds like a good idea, hopefully it is just one commit. Though honestly from personal testing the newest release worked perfectly fine (I tested via an override).


Question: wrapArgs="$wrapArgs --prefix PATH : $dep/bin" done wrapArgs="$wrapArgs --prefix PATH : ${gnused}/bin" <ins> wrapArgs="$wrapArgs --set HOME : /homeless-shelter" </ins> wrapProgram $out/bin/$name $wrapArgs }

is non-deterministic if given both and . Here are a couple runs back-to-back: However, when I make this and :
Interestingly, itself is deterministic, despite being non-deterministic (at least from the command line). This is pretty curious.
Perhaps environment variables come into play? Does the shell script take care to clear the environment like a nix build does?
So, I tried diffing two of the outputs: That looks an awful lot like part of my git hooks that automatically generate tags. Sure enough: I'm of the opinion that we should override in the package, to prevent these kinds of problems. Thoughts?
Seems like those scripts in general should almost completely clear out your environment
Yeah, I don't know how much to get rid of, considering that someone may want to get the hash of their private repos or something.


Question: # NOTE: You must also bump: # <nixpkgs/pkgs/development/python-modules/libvirt/default.nix> # SysVirt in <nixpkgs/pkgs/top-level/perl-packages.nix> <del> version = "8.5.0"; </del> <ins> version = "8.6.0"; </ins> src = fetchFromGitLab { owner = pname; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-x6TnMFYjcUSdQZd9ctN2hITCAl9TGVb7/qAObGb9xMk="; </del> <ins> sha256 = "sha256-bSId7G2o808WfHGt5ioFEIhPyy4+XW+R349UgHKOvQU="; </ins> fetchSubmodules = true; };

When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.


Question: # NOTE: You must also bump: # <nixpkgs/pkgs/development/python-modules/libvirt/default.nix> # SysVirt in <nixpkgs/pkgs/top-level/perl-packages.nix> <del> version = "8.5.0"; </del> <ins> version = "8.6.0"; </ins> src = fetchFromGitLab { owner = pname; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-x6TnMFYjcUSdQZd9ctN2hITCAl9TGVb7/qAObGb9xMk="; </del> <ins> sha256 = "sha256-bSId7G2o808WfHGt5ioFEIhPyy4+XW+R349UgHKOvQU="; </ins> fetchSubmodules = true; };

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


Question: assert command.env["WINE"] == str(wine_bin_dir / "wine") assert command.env["WINELOADER"] == str(wine_bin_dir / "wine") assert command.env["WINESERVER"] == str(wine_bin_dir / "wineserver") <ins> -        assert command.env["LEGACY_STEAM_RUNTIME_PATH"] ==  -            str(steam_runtime_dir / "steam-runtime") assert "STEAM_RUNTIME_PATH" not in command.env for name in ("wine", "wineserver"): @@ -166,16 +161,14 @@ class TestCLIRun: assert command.env["PATH"].startswith(str(wine_bin_dir)) # Compared to the traditional Steam Runtime, PROTON_LD_LIBRARY_PATH -        # will be different +        # will be the same (it would be different without steam-run.patch) proton_install_path = Path(proton_app.install_path) assert command.env["PROTON_LD_LIBRARY_PATH"] == "".join([ str(proton_install_path / "dist" / "lib"), os.pathsep, str(proton_install_path / "dist" / "lib64"), os.pathsep ]) -        # Environment variables for both legacy and new Steam Runtime exist -        assert command.env["LEGACY_STEAM_RUNTIME_PATH"] ==  -            str(steam_runtime_dir / "steam-runtime") +        # Environment variable for new Steam Runtime exists assert command.env["STEAM_RUNTIME_PATH"] ==  str(steam_runtime_soldier.install_path) @@ -238,10 +231,7 @@ class TestCLIRun: str(runtime_root / "lib" / "i386-linux-gnu"), os.pathsep, str(runtime_root / "lib" / "x86_64-linux-gnu") ])) - -        # Environment variables for both legacy and new Steam Runtime exist -        assert command.env["LEGACY_STEAM_RUNTIME_PATH"] ==  -            str(steam_runtime_dir / "steam-runtime") +        # Environment variable for new Steam Runtime exists assert command.env["STEAM_RUNTIME_PATH"] ==  str(steam_runtime_soldier.install_path) @@ -324,20 +314,6 @@ class TestCLIRun: assert "Zenity is not installed" in result -    def test_run_steam_runtime_not_found( -            self, cli, steam_dir, steam_app_factory): -        """ -        Try performing a command with Steam Runtime enabled but no -        available Steam Runtime installation -        """ -        steam_app_factory(name="Fake game 1", appid=10) -        result = cli( -            ["10", "winecfg"], env={"STEAM_RUNTIME": "invalid/path"}, -            expect_exit=True -        ) - -        assert "Steam Runtime was enabled but couldn't be found" in result - def test_run_proton_not_found(self, cli, steam_dir, steam_app_factory): steam_app_factory(name="Fake game 1", appid=10) result = cli(["10", "winecfg"], expect_exit=True) </ins>

This issue is mainly a note to myself since the upgrade won't be trivial and will need a lot of testing. Protontricks is now using the Pressure Vessel runtime, so I have to refactor my patches with steam-run to account for this. <!-- 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 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: protontricks <!-- The current version can be found easily with the same process than 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: 1.4.4 desired version: 1.5.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: myself


Question: , sassc , udisks2 , wrapGAppsHook <ins> , libX11 , libXext , libXNVCtrl </ins> }: stdenv.mkDerivation rec { pname = "monitor"; <del> version = "0.11.0"; </del> <ins> version = "0.12.0"; </ins> src = fetchFromGitHub { owner = "stsdc"; repo = "monitor"; rev = version; <del> sha256 = "sha256-xWhhjn7zk/juXx50wLG2TpB5aqU+588kWBBquWrVJbM="; </del> <ins> sha256 = "1fv98yz9393ddp0k96bwbgccy6x9dmmg8g1pjd3xs6m4c1bnvfc7"; </ins> fetchSubmodules = true; };

<!-- 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 the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process than 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: desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: are you already working on it? if not i can do it
I have some exams to take tomorrow, so maybe I cannot open a PR in 17 hours. Feel free to open one if you have done the update.
I just wanted to make sure you haven't started to work on it, so we don't do duplicate work. I wish you great success with the exams!
Just also have a try on this, fails with . Actually I have no idea what happened so I just opened , downstream workaround should be something like , actually this seems to work, builds and launches. <img src="https://user-" width=50%Also I noticed that we maybe need in , haven't tested yet.
downstream workaround should be something like , actually this seems to work, builds and launches. i don't understand what it does, but it works Also I noticed that we maybe need in , haven't tested yet. I noticed before that the indicators do not work. I'll try it.


Question: ''; # Register some undeclared runtime dependencies to be patched in by autoPatchelfHook <ins> # Note: dyalog.rt is used internally to run child APL processes in </ins> preFixup = '' <del> patchelf ${dyalogHome}/dyalog --add-needed libncurses.so </del> <ins> for exec in "dyalog" "dyalog.rt"; do patchelf ${dyalogHome}/$exec --add-needed libncurses.so done </ins> '' + lib.optionalString htmlRendererSupport '' patchelf ${dyalogHome}/libcef.so --add-needed libudev.so --add-needed libGL.so

Isolates parallelEach doesn't work Steps to reproduce the behavior: run nix develop with then run: dyalog then in the dyalog repl type ⎕DL isolate.llEach (1 2 3) returning like its the case when using the .deb on lets say a debian host strace log reveals a lot of lines like which does not happen on a debian host when I install dyalog 19 via dpkg -i I have also tested this on a debian host that has nix installed and installed dyalog via nix instead of dpkg but I run into the same issue making me believe there is something wrong with the drv system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 2.18.2, nixpkgs: /etc/channels/nixpkgs (I ran it against the current (1 hour ago) nixpkgs master/unstable branches) as in I pulled these 2 about 1 hour ago
I'll see what I can do about this. In the meantime, could you change the issue title to start with ?
sure
Phew, finally found it! The issue was with the class, which auto-crashed when created. I redirected its output to a file, and it turns out that because I didn't patch to require it wasn't able to load it, thus erroring out.
This is awesome, thanks for the incredibly fast response/fix time. I suspected it was something like this I initially thought that maybe some of the libraries weren't copied over since the nix expression is a little pickier than just cp *.so $out/lib but upon fixing that nothing change really. Usually knowing when to apply patchelf is quite clear as software will let you know if a library is missing so throwing ldd against it generally gives some pretty good insight. Though if you'd like sharing this information, would you mind telling me how you found out? Was it just intuition or did you use some sort of tool to debug it to come to the conclusion that this may be the issue. As i couldn't really get hold of logs making any sense when I tried it. This would be quite interesting to me as I most likely will get to fix more dyalog stuff in the future.


Question: ''; # Register some undeclared runtime dependencies to be patched in by autoPatchelfHook <ins> # Note: dyalog.rt is used internally to run child APL processes in </ins> preFixup = '' <del> patchelf ${dyalogHome}/dyalog --add-needed libncurses.so </del> <ins> for exec in "dyalog" "dyalog.rt"; do patchelf ${dyalogHome}/$exec --add-needed libncurses.so done </ins> '' + lib.optionalString htmlRendererSupport '' patchelf ${dyalogHome}/libcef.so --add-needed libudev.so --add-needed libGL.so

First of all, I somehow got my hand on the file that lists where it crashed exactly, then looked through it, found the definitions in the namespace explorer. It looked like it was supposed to start some processes and then connect to them, however they exited immediately. I was able to verify this by printing in . is an array of new objects, so I looked up the docs, and it turns out you can specify an OutFile, which specifies where a process should dump its logs (its the 5th parameter of ), so I overrode that to point to some known location. That file contained the following: In was required by the binary, so took care of it. However in they probably changed it to load dynamically using which can't be auto-detected with . I had to use with the normal binary to make it work, but I didn't know what was so I didn't do anything with it. Note: in a new binary named appeared, however I don't know where it's used, so I don't know what I should do with it. Might have to ask around for it.
thanks for taking the time to outline how you came to that conlcusion im sure that will help me in the future. Sorry for forgetting to close this its closed now
Well, the fix isn't merged yet, so I think that this issue staying open was not a problem.
oh sorry I forgot as I used the branch locally and then after many weeks I saw its still opened and somehow was under the assumption that it was merged. Sorry I skipped that


Question: nativeBuildInputs = [ file pkgconfig gnupg autoreconfHook git texinfo ] ++ lib.optionals pythonSupport [ python swig2 which ncurses ]; <ins> patches = [ (fetchpatch { name = "fix-key-expiry.patch"; url = "https://files.gnupg.net/file/data/fehgbjmataj5tc2pnfhj/PHID-FILE-aqck6l4elhw53tjanrie/file"; sha256 = "1h80m045gy7r0g7dzzlfpql6p065x88p274ij9jnf7d4lwwgrf1a"; }) ]; </ins> postPatch ='' substituteInPlace ./configure --replace /usr/bin/file ${file}/bin/file '';

(this is a qt specific test): Loc: [t-(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 1047ms This seems to affect master too, but for some reason it's been built successfully once. The aarch64 build started failing when updating qt5 from 5.11 to 5.12 making it the likely root cause: Edit: the cause was expired testing keys: cc maintainer cc as you've been active in keeping plasma/kde up to date lately. ping staging next:
Did you found ? Sounds very similar and should be fixed...
No didn't find that, but yeah, that sure looks exactly like the same issue. I'm guessing the qt issue were never actually fixed: Blame on the test gives no change at least:
And applying the suggested patch does fix the test: diff +++ gpgme-1.10.0/lang/qt/tests/t- -455,7 +455,7 private Q_SLOTS: QVERIFY(result.numSignatures() == 1); auto sig = result.signatures()[0]; QVERIFY(sig.validity() == Signature::Marginal); QVERIFY(sig.validity() == Signature::Marginal sig.validity() == Signature::Unknown); auto stats = ().userID(0).tofuInfo(); QVERIFY(!stats.isNull());
So, what are we want to do? Do you maybe want to comment on the upstream issue?
Hmm, strange, I'm getting the same failure on master (using ), forcing single core does not fix the problem though, so probably not a race condition. I've reported the failure as you suggested:
The cause is most likely qt 5.11 to 5.12 upgrade, as the aarch64 build started failing the test then:
So the keys used in this test expired on 2019-01-06, which explains why we suddenly saw this without any apparent reason. :
Thanks for fixing this and sorry for my late reply... (Edit: And of course also thanks


Question: , stdenv , rustPlatform , fetchFromGitHub <ins> , installShellFiles , pkg-config </ins> , libxcb <del> # Darwin dependencies </del> <ins> , openssl # Darwin dependencies </ins> , AppKit }: rustPlatform.buildRustPackage rec { pname = "didyoumean"; <del> version = "1.1.0"; </del> <ins> version = "1.1.3"; </ins> src = fetchFromGitHub { owner = "hisbaan"; repo = "didyoumean"; rev = "v${version}"; <del> sha256 = "sha256-t2bmvz05vWIxQhC474q/9uky1kAQoFN8Z+qflw5Vj68="; </del> <ins> sha256 = "sha256-hHl9PGNDFN7Dad2JOlAy99dz0pC9OmphwYMJHBBwx7Y="; </ins> }; <del> cargoSha256 = "sha256-4DbziI9enib4pm9/P4WEu15glIxtejaV2GCqbzuxxyw="; </del> <ins> cargoSha256 = "sha256-rjkj9MO6fXVOk3fA87olGt/iIaJ8Zv/cy/Cqy/pg6yI="; </ins> <del> buildInputs = lib.optional stdenv.isLinux [ libxcb ] ++ lib.optionals stdenv.isDarwin [ AppKit ]; </del> <ins> nativeBuildInputs = [ installShellFiles ] ++ lib.optionals stdenv.isLinux [ pkg-config ]; buildInputs = lib.optionals stdenv.isLinux [ libxcb openssl ] ++ lib.optionals stdenv.isDarwin [ AppKit ]; postInstall = '' installManPage man/dym.1 installShellCompletion completions/dym.{bash,fish} installShellCompletion --zsh completions/_dym ''; # Clipboard doesn't exist in test environment doCheck = false; </ins> meta = with lib; { description = "A CLI spelling corrector for when you're unsure"; homepage = "https://github.com/hisbaan/didyoumean"; license = licenses.gpl3Plus; <del> maintainers = with maintainers; [ evanjs ]; </del> <ins> maintainers = with maintainers; [ evanjs wegank ]; </ins> mainProgram = "dym"; }; }

name: didyoumean current version: 1.1.0 desired version: 1.1.3 maintainers: Version 1.1.3 comes with a man page as well as shell completions for a few shells (bash, zsh, fish, elvish). I'd like to have the script install these. I'm more than willing to do the actual update myself, but I'm very new to Nix, so I'll probably need some guidance, specifically on how to install these completions and the man page, and how to update the hash. Thanks!
To update the hashes, simply set and , and update them as suggested by . Having done it right, you'll haveTo install the man page and the shell completions, setYou may also need to set on some platforms (at least on ?). Before doing this, feel free to make a pull request.
I'm running into some issues trying to test it to ensure it's doing what I want it to. I'm going to the directory with in it and running but I'm running into issues regarding being undefined: Any pointers? I wasn't able to find anything searching through the web
needs to be in the attrset at the top of the file for you to be able to use it.
As explained, we need to add at the top of the file.


Question: }; }.${stdenv.hostPlatform.system} or (throw "Unsupported system: ${stdenv.hostPlatform.system}"); <del> nativeBuildInputs = [ autoPatchelfHook dpkg makeBinaryWrapper wrapGAppsHook3 ]; </del> <ins> nativeBuildInputs = [ autoPatchelfHook dpkg makeShellWrapper wrapGAppsHook3 ]; </ins> dontWrapGApps = true;

ArmCord's wrapper seems unable to launch under Wayland, always chooses to launch under Steps to reproduce the behavior: sure and are properly set: Armcord: . ... 's on XWayland (as shown by ). I expect it to launch with Wayland instead of XWayland. Custom wrapper: Test case: Log output: <!-- 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]:
probably need makeShellWrapper instead of makeBinaryWrapper in the package
Thanks for jumping on a PR will review this evening.


Question: echo "Publishing plugin $1" dotnet publish $1 -p:ContinuousIntegrationBuild=true -p:Deterministic=true  --output $out/lib/ArchiSteamFarm/plugins/$1 --configuration Release  <del> -p:TargetLatestRuntimePatch=false -p:UseAppHost=false --no-restore  --framework=net7.0 </del> <ins> -p:TargetLatestRuntimePatch=false -p:UseAppHost=false </ins> } buildPlugin ArchiSteamFarm.OfficialPlugins.ItemsMatcher

Looks like it now uses .NET 8 which probably made all existing plugins incompatible - Package name: ArchiSteamFarm Latest released version: 5.5.0.11 <!-- Search your package here: --- Current version on the unstable channel: 5.4.13.4 Current version on the stable/release channel: 5.4.12.5 <!-- 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]:
The package/module has no official way to use plugins, so there is no way to use them unless people are using overlays which should be constructed in a smart way to re-use the same methods as archisteamfarm does. Anyway, here is the update


Question: stdenv.mkDerivation rec { pname = "bluemail"; <del> version = "1.136.21-1884"; </del> <ins> version = "1.140.8-1922"; </ins> # Taking a snapshot of the DEB release because there are no tagged version releases. # For new versions, download the upstream release, extract it and check for the version string. # In case there's a new version, create a snapshot of it on https://archive.org before updating it here. src = fetchurl { <del> url = "https://archive.org/download/blue-mail-1.136.21-1884/BlueMail.deb"; hash = "sha256-L9mCUjsEcalVxzl80P3QzVclCKa75So2sBG7KjjBVIc="; </del> <ins> url = "https://web.archive.org/web/20240208120704/https://download.bluemail.me/BlueMail/deb/BlueMail.deb"; hash = "sha256-dnYOb3Q/9vSDssHGS2ywC/Q24Oq96/mvKF+eqd/4dVw="; </ins> }; <ins> desktopItems = [ (makeDesktopItem { name = "bluemail"; icon = "bluemail"; exec = "bluemail"; desktopName = "BlueMail"; comment = meta.description; genericName = "Email Reader"; mimeTypes = [ "x-scheme-handler/me.blueone.linux" "x-scheme-handler/mailto" ]; categories = [ "Office" ]; }) ]; </ins> nativeBuildInputs = [ autoPatchelfHook <ins> copyDesktopItems </ins> makeWrapper dpkg wrapGAppsHook

When installed through Nix, Bluemail does not create a desktop shortcut in $out/share/applications. The program can only be run through the terminal by default. The program also fails to load unless the --disable-gpu-sandbox option is used. Steps to reproduce the behavior: Bluemail by adding to , and rebuild. for Bluemail in the Application Launcher - not present in terminal - core dumps on gpu process not usable in terminal - bluemail opens with the default wayland icon What currently happens is detailed step-by-step above. What I'd expect to happen is that a desktop icon is created when I rebuild to install bluemail, and that clicking the application from the Application Launcher opens bluemail without a core dump. Installing from NixOS-Unstable Running on Intel UHD Graphics (10th Gen)


Question: <del> { lib, stdenv, fetchFromGitHub, pkg-config, avahi, libsoup, libjpeg </del> <ins> { lib, stdenv, fetchFromGitHub, pkg-config, avahi, libsoup, libjpeg, libpng </ins> , sane-backends, meson, ninja }: stdenv.mkDerivation rec { pname = "sane-airscan"; <del> version = "0.9.17"; </del> <ins> version = "0.99.0"; </ins> nativeBuildInputs = [ meson ninja pkg-config ]; <del> buildInputs = [ avahi libsoup libjpeg sane-backends ]; </del> <ins> buildInputs = [ avahi libsoup libjpeg libpng sane-backends ]; </ins> src = fetchFromGitHub { owner = "alexpevzner"; repo = pname; rev = version; <del> sha256 = "03y0c1z5s3wbvxa9nvji62w42cmvcgm2sw72j7wm831995q3abmx"; </del> <ins> sha256 = "0bbw3s95v5fmkpmmd26v9cf1c40dm85bgxlhs06ski5my803ck0a"; </ins> }; meta = with lib; {

Describe the bug SANE does not find the backend To Reproduce Steps to reproduce the behavior: backend to the error Expected behavior SANE loads the airscan backend. Screenshots Listing of symlinks to SANE-Backends: Additional context is missing the version suffix, so SANE does not use the library. The issue has been fixed on upstream master, but no new version has been released yet. Should we just update the package via commit-hash (it's still in early development anyhow), or wait for the next release for updating it? Using in my local nixpkgs fixes the problem. Notify maintainers Metadata Maintainer information:
I will quickly get in touch with the maintainer of to see if he can cut another release for us. It feels important enough to cut a bugfix release ;) thanks for taking the time for writing such a detailed explanation!


Question: <ins> diff --git a/tests/test_strpdatetime.py b/tests/test_strpdatetime.py index 6c371d6..a3d0232 100644 --- a/tests/test_strpdatetime.py +++ b/tests/test_strpdatetime.py @@ -44,5 +44,4 @@ TEST_DATA = [ @pytest.mark.parametrize("string, format, expected", TEST_DATA) def test_datetime_strptime(string, format, expected): """Test datetime_strptime""" -    locale.setlocale(locale.LC_ALL, "en_US.UTF-8") assert strpdatetime(string, format) == expected </ins>

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: nativeBuildInputs = [ pkg-config <del> ] ++ lib.optionals atLeast24 [ </del> autoconf-archive autoreconfHook bison flex jq <del> ] ++ lib.optionals (atLeast24 && enableDocumentation) [ </del> <ins> ] ++ lib.optionals (enableDocumentation && !atLeast24) [ libxslt libxml2 docbook_xsl_ns docbook5 ] ++ lib.optionals (enableDocumentation && atLeast24) [ </ins> (lib.getBin lowdown) mdbook ] ++ lib.optionals (atLeast213 && enableDocumentation) [

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: dependencies = []; buildInputs = [ python go cmake <del> (if stdenv.isDarwin then llvmPackages.clang else llvmPackages.clang-unwrapped) llvmPackages.llvm </del> ] ++ stdenv.lib.optional stdenv.isDarwin Cocoa; propagatedBuildInputs = stdenv.lib.optional (!stdenv.isDarwin) rustracerd; patches = [ <del> ./patches/youcompleteme/1-top-cmake.patch </del> ./patches/youcompleteme/2-ycm-cmake.patch ]; <ins> # YCM requires path to external libclang 3.9 # For explicit use and as env variable for ../third_party/ycmd/build.py EXTRA_CMAKE_ARGS="-DEXTERNAL_LIBCLANG_PATH=${llvmPackages.clang.cc}/lib/libclang.${if stdenv.isDarwin then "dylib" else "so"}"; </ins> buildPhase = '' patchShebangs . substituteInPlace plugin/youcompleteme.vim

Building on Darwin fails. The problem seems very similar to which was solved by —however I do not know how to apply that solution here.
Wasn't this fixed by merging
This issue is fixed, but it broke again recently. Same issue as but we use
Proposed
Fixed by


Question: <del> { stdenv, buildPythonPackage, fetchPypi, six }: buildPythonPackage rec { pname = "websocket_client"; version = "0.54.0"; src = fetchPypi { inherit version pname; sha256 = "e51562c91ddb8148e791f0155fdb01325d99bb52c4cdbb291aee7a3563fd0849"; }; prePatch = '' # ssl.match_hostname exists in python2.7 version maintained in nixpkgs, # the dependency is not necessary. sed -e "s/['backports.ssl_match_hostname']/[]/" -i setup.py ''; propagatedBuildInputs = [ six ]; meta = with stdenv.lib; { homepage = https://github.com/liris/websocket-client; description = "Websocket client for python"; license = licenses.lgpl2; }; } </del>

I had i3pystatus fail to build because of a pytest error with praw on unstable. I tried to bump praw from 6.0.0 to 6.3.1 but it requires a new dep websocket-client that doesn't look packaged thus I ended up ditching it from i3pystatus dependencies. Maybe we should do the same upstream and provide a leaner i3pystatus as it's not a core plugin anyway (and fails ). nix build -f channel:nixos-unstable system: host os: multi-user?: sandbox: version: channels(teto): channels(root): nixpkgs:
CC ? what do you think of removing it from i3pystatus default ?
Agree. A user can add manually by overriding of parameter.
is this still relevant now? or can it be closed?
I just removed praw it from i3pystatus default dependencies but itself still won't build. So it makes sense to keep the issue open even if I have no personal interest in praw.
it was irritating me, so i updated it.


Question: }) (callPackage ./common-overrides.nix { <del> inherit haskellLib; </del> <ins> inherit haskellLib fetchpatch buildPackages; </ins> }) ghcjsDepOverrides ]);

As a fallout of the migration to GHC 9.0.2 got marked as broken, as it failed to build with GHC 9.0.2 and the Stackage LTS 19 package set we now have. It would be necessary to investigate if survived this (i.e. if it still builds) and if not to get it to work again. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc
should compile again. The bootstrap is additionally built by Hydra, so only the GHC bundled libraries will need to be compiled (which is an improvement to before at least).


Question: <ins> { lib , stdenvNoCC , fetchFromGitHub , fetchzip , clickgen }: stdenvNoCC.mkDerivation rec { pname = "bibata-cursors"; version = "2.0.6"; src = fetchFromGitHub { owner = "ful1e5"; repo = "Bibata_Cursor"; rev = "v${version}"; hash = "sha256-iLBgQ0reg8HzUQMUcZboMYJxqpKXks5vJVZMHirK48k="; }; bitmaps = fetchzip { url = "https://github.com/ful1e5/Bibata_Cursor/releases/download/v${version}/bitmaps.zip"; hash = "sha256-8ujkyqby5sPcnscIPkay1gvd/1CH4R9yMJs1nH/mx8M="; }; nativeBuildInputs = [ clickgen ]; buildPhase = '' runHook preBuild ctgen build.toml -p x11 -d $bitmaps/Bibata-Modern-Amber -n 'Bibata-Modern-Amber' -c 'Yellowish and rounded edge bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Modern-Classic -n 'Bibata-Modern-Classic' -c 'Black and rounded edge Bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Modern-Ice -n 'Bibata-Modern-Ice' -c 'White and rounded edge Bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Original-Amber -n 'Bibata-Original-Amber' -c 'Yellowish and sharp edge Bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Original-Classic -n 'Bibata-Original-Classic' -c 'Black and sharp edge Bibata cursors.' ctgen build.toml -p x11 -d $bitmaps/Bibata-Original-Ice -n 'Bibata-Original-Ice' -c 'White and sharp edge Bibata cursors.' runHook postBuild ''; installPhase = '' runHook preInstall install -dm 0755 $out/share/icons cp -rf themes/* $out/share/icons/ runHook postInstall ''; meta = { description = "Material Based Cursor Theme"; homepage = "https://github.com/ful1e5/Bibata_Cursor"; license = lib.licenses.gpl3Only; platforms = lib.platforms.linux; maintainers = with lib.maintainers; [ rawkode AdsonCicilioti ]; }; } </ins>

Package name: bibata-cursors Latest released version: 2.0.4 <!-- Search your package here: --- Current version on the unstable channel: 2.0.3 Current version on the stable/release channel: 2.0.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- 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.


Question: inherit (lib) types; cfg = config.services.ollama; <del> ollamaPackage = cfg.package.override { </del> <ins> ollamaPackage = cfg.package.override (prevArgs: { </ins> inherit (cfg) acceleration; <ins> } // lib.optionalAttrs (prevArgs ? linuxPackages) { </ins> linuxPackages = config.boot.kernelPackages // { nvidia_x11 = config.hardware.nvidia.package; }; <del> }; </del> <ins> }); </ins> in { options = {

Steps to reproduce the behavior: unstable defined, enable the ollama service with pkg overridden to point at unstable: without show-trace: with --show-trace: 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]:
Hi! Can you confirm your nixpkgs revision has this change incorporated and you're not overriding the package manually?


Question: dontWrapQtApps = true; meta = with lib; { <del> maintainers = with lib.maintainers; [ peterhoeg ]; </del> <ins> description = "KDE Partition Manager core library"; homepage = "https://invent.kde.org/system/kpmcore"; license = with licenses; [ cc-by-40 cc0 gpl3Plus mit ]; maintainers = with maintainers; [ peterhoeg oxalica ]; </ins> # The build requires at least Qt 5.14: <del> broken = lib.versionOlder qtbase.version "5.14"; </del> <ins> broken = versionOlder qtbase.version "5.14"; </ins> }; }

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: dontWrapQtApps = true; meta = with lib; { <del> maintainers = with lib.maintainers; [ peterhoeg ]; </del> <ins> description = "KDE Partition Manager core library"; homepage = "https://invent.kde.org/system/kpmcore"; license = with licenses; [ cc-by-40 cc0 gpl3Plus mit ]; maintainers = with maintainers; [ peterhoeg oxalica ]; </ins> # The build requires at least Qt 5.14: <del> broken = lib.versionOlder qtbase.version "5.14"; </del> <ins> broken = versionOlder qtbase.version "5.14"; </ins> }; }

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: disallowedReferences = [ stdenv.cc.cc ]; postFixup = '' <del> remove-references-to -t ${stdenv.cc.cc} "$(readlink -f $out/share/perl6/runtime/dynext/libperl6_ops_moar.so)" </del> <ins> remove-references-to -t ${stdenv.cc.cc} "$(readlink -f $out/share/perl6/runtime/dynext/libperl6_ops_moar${stdenv.hostPlatform.extensions.sharedLibrary})" </ins> ''; meta = with lib; {

= 2021.07 does not build successfully on Darwin. A bisect over commits shows this: 2021.10 - - does not work 2021.07 - - does not work 2021.06 - - works 2020.12 - - works Steps to reproduce the behavior: this repo: on Darwin. (I'm on MacOS Big Sur). line 4 from to . . Observe the build failure in the output: For the full log, see .
Caused by Please use to show the files that a working rakudo contains on darwin
Tested on and it works. Thanks!


Question: (if compat185 then "--enable-compat185" else "--disable-compat185") ] ++ lib.optional dbmSupport "--enable-dbm" <del> ++ lib.optional stdenv.isFreeBSD "--with-pic"; </del> <ins> ++ lib.optional stdenv.isFreeBSD "--with-pic" ++ (drvArgs.configureFlags or []); </ins> preConfigure = '' cd build_unix

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