Question: pkg-config glib wrapGAppsHook4 <ins> gobject-introspection </ins> ]; buildInputs = [ librsvg <del> gobject-introspection </del> libnotify libadwaita libportal

crashes, even when installed into the system. Steps to reproduce the behavior: shell "nixpkgs#gnome-frog" -c frog Program doesn’t crash Please run and paste the result.
Interestingly, I was able to build and run the app in commit (I also rebuild it with just to double check). ! Though, it does fail to build and run in recent revisions (at least in ). It needs to apply to be able to build. Running it however gives me the following error: Not exactly familiar with GTK development but I'll see what I can do. Thank you for reporting!
Running it on my end gives me another error:
frog+main+Application' doesn't support property gobject-introspectionbuildInputsnativeBuildInputswrapGAppsHookGITYPELIB_PATH`, resulting in typelibs being picked up from the environment.
Thank you for the explanation, . Simply putting into did build and run the app (at least in the recent commits).


Question: inherit (llvmPackages) libcxx; } else <del> clangNoMarch; </del> <ins> swiftLlvmPackages.clang; </ins> # Overrides that create a useful environment for swift packages, allowing # packaging with `swiftPackages.callPackage`. These are similar to

Since was merged into the master, swift cannot be built on aarch64. Steps to reproduce the behavior: reported in I'm not familiar with swift or clang, but I'm using the following overlay as a workaround until it's fixed. <!-- 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]:
states that this only fixed the swift build but all downstream packages are still broken. re-opening.
Actually, it seems only dark-mode-notify is broken, others seem fine. Probably because it uses Cocoa or disables sandbox. I don't know for sure.
I noticed that my personal package does not build either. Maybe it's because of swift itself or swiftpm?
The above open PR seems to run into the same issue…


Question: PrivateNetwork = false; # Cannot be true due to Node MemoryDenyWriteExecute = false; <ins> # The more restrictive "pid" option makes `nix` commands in CI emit # "GC Warning: Couldn't read /proc/stat" # You may want to set this to "pid" if not using `nix` commands ProcSubset = "all"; # Coverage programs for compiled code such as `cargo-tarpaulin` disable # ASLR (address space layout randomization) which requires the # `personality` syscall # You may want to set this to `true` if not using coverage tooling on # compiled code LockPersonality = false; </ins> }; }; };

introduced systemd syscall filtering which seems overly restrictive for common use cases. We use for coverage reports of our Rust projects which makes use of the ptrace(2) system call (denied by ). Android projects commonly rely on which uses chown(2) (denied by ). In my opinion, those use cases are too common and should work out of the box. Also, workflow failures are difficult to debug if syscall filtering (or any hardening) steps in. I'd suggest to revise the syscall filtering: Also, it might help with debugging or employing a custom hardening configuration if we add a module option which defaults to . Please run and paste the result.
I agree that if the hardening make github-runner not to work as expected or as "standard" installation, we should remove them or make them optional with new option Do you want it to default to ? Maybe better with so it work as expected out of box?
also noted problems with makefile workflows in that I have been able to reproduce. I am sorry I did not catch this when making the changes originally. My usecase was running binaries on uncommon targets (e.g. ) connected over USB; and I only had light testing for other usecases. I have since a makefile test to the runner I use for testing package/module updates and will add a coverage workflow now too. I am ok with removing the harderning entirely, or making it more permissive. I only this because at the time I thought it would be a sane default for majority of applications. I would prefer we keep some hardening. Most people probably do not want a CI process to change the clock, hostname, or reboot the system entirely. I have been working on this in the background since reported issues; this is what I have come up with so far, I have not tested it with yet (will do that later this weekend); but it does allow and debug related tools such as to function. In addition to changes should also be changed to so that nix does not emit warnings when running.
:+1: :+1: Yes, all this hardening is already available and entirely optional! Every user is free to add anything to that they want.


Question: PrivateNetwork = false; # Cannot be true due to Node MemoryDenyWriteExecute = false; <ins> # The more restrictive "pid" option makes `nix` commands in CI emit # "GC Warning: Couldn't read /proc/stat" # You may want to set this to "pid" if not using `nix` commands ProcSubset = "all"; # Coverage programs for compiled code such as `cargo-tarpaulin` disable # ASLR (address space layout randomization) which requires the # `personality` syscall # You may want to set this to `true` if not using coverage tooling on # compiled code LockPersonality = false; </ins> }; }; };

I understand that NixOS developers are super keen on hardening, which is generally good, but for certain applications I just don't think it makes sense to go over the top... or even provide "curated" selections behind 'enableHardening' type flags. CI software is so broad I think we're providing more trouble and confusion than value here. My personal recommendation for this specific module is to follow what suggested as a reasonable default and let users decide any hardening they want for themselves. But I'm not the maintainer of this module in NixOS, just a user, so I defer to those who are volunteering their time to maintain this module :bowing_man:
PR to fix is here: Mentions do not generate notifications, just making a comment so that anyone subscribed to this issue gets a notification.


Question: setupHook = writeText "setupHook.sh" '' addCoqPath () { if test -d "''$1/lib/coq/${coq-version}/user-contrib"; then <del> export COQPATH="''${COQPATH}''${COQPATH:+:}''$1/lib/coq/${coq-version}/user-contrib/" </del> <ins> export COQPATH="''${COQPATH-}''${COQPATH:+:}''$1/lib/coq/${coq-version}/user-contrib/" </ins> fi }

Describe the bug Shell with and will fail to start with a following message: This is an issue because depends on so they would be always included to the shell started by nix-review. I noticed this issue while reviewing . I suspect this is caused by . To Reproduce Steps to reproduce the behavior: This does not reproduce on release-19.09 Expected behavior Shell will start, shell prompt will appear. Metadata Please run and paste the result. Maintainer information: cc
I'm getting "CLASSPATH: unbound variable" since updating master an hour ago from last Sunday, and reports "JAVA_HOME: unbound variable" started happening while working on eleven hours ago.


Question: owner = "named-data"; repo = lib.toUpper pname; rev = "NFD-${version}"; <del> sha256 = "1l9bchj8c68r6qw4vr1kc96jgxl0vpqa2vjkvy1xmhz92sivr6gi"; </del> <ins> sha256 = "sha256-8Zm8oxbpw9qD31NuofDdgPYnTWIz5E04NhkZhiRkK9E="; </ins> fetchSubmodules = true; };

The default boost version has been bumped from 1.69 (or 1.75) to 1.77. This is a notice for maintainers that the following packages are now failing to build: - - - - - - - - - - [x] cryfs A typical fix would involve pinning the package to a specific version (e.g. see )
My fix in is not the same as . Is there a very good reason to prefer one over the other ?
Well, I like trying to keep it away from the huge top-level file. (which is e.g. harder to use in git)
Re. pivx, I think we should mark it broken. Our current version is very old (and therefore useless), and the new version includes a rust build. I don't have the capacity to fix this ATM.
In my case, what broke it was the update from boost175 to boost177. Fix is in .
It's in the branch now, so please target any further fixes there as well (unless they're a mass rebuild, etc.)
colobot fixed with
FYI, ledger has some broken behavior with the new boost version, although it curiously doesn't cause a test failure: ledger/ledger.
Our expression does not attempt to run tests.
Ah, that would be why, thanks. Nevertheless, the binary exhibits the same problem described in that issue in interactive use.


Question: { stdenv, lib, fetchurl, iptables-legacy, libuuid, openssl, pkg-config <del> , which, iproute2, gnused, coreutils, gawk, makeWrapper </del> <ins> , which, iproute2, gnused, coreutils, gnugrep, gawk, makeWrapper </ins> , nixosTests <ins> , firewall ? "iptables", nftables, libmnl, libnftnl </ins> }: let <del> scriptBinEnv = lib.makeBinPath [ which iproute2 iptables-legacy gnused coreutils gawk ]; </del> <ins> scriptBinEnv = lib.makeBinPath { iptables = [ # needed for dirname in ip{,6}tables_*.sh coreutils # used in miniupnpd_functions.sh: which iproute2 iptables-legacy gnused gnugrep gawk ]; nftables = [ # needed for dirname in nft_*.sh & cat in nft_init.sh coreutils # used in miniupnpd_functions.sh: which nftables ]; }.${firewall}; </ins> in stdenv.mkDerivation rec { pname = "miniupnpd";

We already have in , but only with iptables support. It would be nice to have the nftables version available as well.
Being worked on in , I'm trying to test myself but couldn't make it to work yet.
I think the PR is ready now, testing welcome!
Maybe add an option for will be better?


Question: fastapi-mail = callPackage ../development/python-modules/fastapi-mail { }; <ins> fast-histogram = callPackage ../development/python-modules/fast-histogram { }; </ins> fastavro = callPackage ../development/python-modules/fastavro { }; fastbencode = callPackage ../development/python-modules/fastbencode { };

Project description Glue is a python project to link visualizations of scientific datasets across many files. Click on the image for a quick demo: ! Metadata homepage URL: source URL: license: BSD Linux, BSD


Question: { lib , buildPythonPackage , fetchPypi <del> # build-system , setuptools , plux # dependencies , cachetools , click , cryptography </del> , dill , dnslib , dnspython <del> , psutil , python-dotenv , pyyaml </del> <ins> , plux , pyaes , python-jose </ins> , requests <del> , rich , semver , stevedore , tailer </del> <ins> , tabulate </ins> # Sensitive downstream dependencies , localstack

Steps to reproduce the behavior: localstack (from unstable) (version 3.2.0) localstack 2.3.0 works and so does (tagged because you bumped the version) (the channel is slightly messed up. I am using 23.11 but with flakes) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The new version requires too many dependencies to package up in a reasonable time frame and even includes circular ones. contains a revert to 3.0.0 which builds for me and shows the usage. Can you take a look if that works for you?
Sorry for the delay! Yes, the revert works well for me! Thank you!


Question: license = lib.licenses.agpl3Plus; maintainers = with lib.maintainers; [ arturcygan ]; platforms = lib.platforms.unix; <ins> mainProgram = "echidna-test"; </ins> }

<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.7.3 desired version: 2.0.2 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
waiting for 0.50.0 release of
I fixed echidna.
Lovely. Thanks you so much for you effort.


Question: buildKernel = any (n: n == configFile) [ "kernel" "all" ]; buildUser = any (n: n == configFile) [ "user" "all" ]; <ins> # remove this patch at the next ZFS release (> 2.0.1) reapplyPathSanitizerPatch = fetchpatch { url = "https://github.com/openzfs/zfs/commit/03f036cbccdd8699f5fe8540ef317595a35bceb8.patch"; sha256 = "c157bbb6551a4e720c3faba005e1b72e4692d304c6ff5e0e685691bd47197dca"; }; </ins> common = { version , sha256 , extraPatches ? []

Describe the bug When booting with ZFS legacy mountpoints like this: the boot fails as described in this post: To Reproduce I guess this is difficult if not anyone is having this issue with legacy mountpoints, but it seems that in the linked discourse post, I'm not the only one with this issue. But I've tested it just on this commit: where it fails, and on this (just one commit before): And there everything works. Expected behavior Mounting of legacy ZFS mountpoints succeeds while booting. Notify maintainers <!-- Metadata Please run and paste the result. Maintainer information: --
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Can you check if this is fixed by ?
I tried with this overlay: Not sure if that's the way to do it, but it didn't work.
it should probably be
Thanks I tried that, and it didn't work. Not sure how to confirm the patch got applied properly though.
if you have the log output, you will have something like:
Guys, just to report, I'm in the latest zen with ZFS 2.0.1-1 with encryption, unstable channel and I'm not having any problems.
I've just found time to test this, thanks for the research. The patch did indeed fix the issue for me! (I've checked the log output for the application of the patch). For the sake of completeness the overlay I've applied (needed a slightly different sha256 sum for me):
Could you make a PR adding the patch to zfs?


Question: <itemizedlist> <listitem> <para> <ins> The Mailman NixOS module (<literal>services.mailman</literal>) has a new option <xref linkend="opt-services.mailman.enablePostfix" />, defaulting to true, that controls integration with Postfix. </para> <para> If this option is disabled, default MTA config becomes not set and you should set the options in <literal>services.mailman.settings.mta</literal> according to the desired configuration as described in <link xlink:href="https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html">Mailman documentation</link>. </para> </listitem> <listitem> <para> </ins> The default-version of <literal>nextcloud</literal> is <package>nextcloud20</package>. Please note that it's <emphasis>not</emphasis> possible to upgrade <literal>nextcloud</literal> across multiple major versions! This means that it's e.g. not possible to upgrade

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


Question: qtWrapperArgs = let libpath = with xorg; <del> lib.makeLibraryPath [ </del> <ins> lib.makeLibraryPath ([ </ins> libX11 libXext libXcursor

A clear and concise description of what the bug is. Prism Launcher doesn't allow enabling Feral GameMode or MangoHud under the "Performance" tab because it can't find it. Steps to reproduce the behavior: GameMode ( ) MangoHud ( ) Prism Launcher ( ) new instance in Prism Launcher instance and go to "Performance" tab A clear and concise description of what you expected to happen. GameMode and MangoHud should be able to be enabled when installed. If applicable, add screenshots to help explain your problem. ! ! Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
Addressed here -


Question: ++ lib.optional enableSqlite sqlite; dontWrapQtApps = true; <ins> dontWrapGApps = true; </ins> configureFlags = [ "--enable-shared" ] ++ lib.optional sdlClient "--enable-client=sdl"

should provide a QT client to freeciv, which is probably named if I had to guess. Steps to reproduce the behavior: only gtk client installed (see below) A executable. If applicable, add screenshots to help explain your problem. ! -( does not exist) ! The installed is indeed a gtk client. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (You were the last person to commit, so I choose you :) ) (I don't believe the listed maintainer exists). Please run and paste the result. Maintainer information:


Question: <del> { lib, stdenv, fetchzip, jdk11 }: </del> <ins> { lib, stdenv, fetchzip, jdk11, wrapGAppsHook }: </ins> stdenv.mkDerivation rec { pname = "igv";

The IGV package freezes and crashed when a file dialog should open (open file, save as, etc.). Steps to reproduce the behavior: igv: igv "File" -"Load from File.." application crashes The file dialog should open and allow me to open a file. If I open igv through the terminal, then this error is shown: This error is the same as previously reported issues for other application, e.g. I'll shortly open a PR with the same fix. I'll rather do that in the PR with the fix. Please run and paste the result. NA


Question: default = [ "aes" "aes_generic" "blowfish" "twofish" "serpent" "cbc" "xts" "lrw" "sha1" "sha256" "sha512" <ins> "af_alg" "algif_skcipher" </ins> (if pkgs.stdenv.hostPlatform.system == "x86_64-linux" then "aes_x86_64" else "aes_i586") ];

See:
I've been using cryptsetup with an SSD and without kernel crypto to run my entire NixOS and didn't noted any performance issues, but I agree that my patch was a temporary workaround, so enabling the crypto module would be a better solution.
The option also breaks the feature of that can be used when installing nixos to reason about the speed of disk encryption
The NixOS test works with and the kernel userapace crypto API enabled in on at least 19.03. was updated to 2.0.6 in the meantime, maybe the bug was fixed? Haven't noticed anything in release notes. This API shouldn't in fact be need for LUKS, only for tcrypt and the benchmark. Did you also run the test or did you just notice that on your local machine? Do you have any non-standard config concerning the initrd?
Hmm, even with the test succeeds. We need more information.
I haven't ran any tests, I just tested it in my work laptop and in a VM used to isolate the issue. I used a non-standard initrd config only for debugging, but after finding the problem I used the standard one. The only strange thing I did was to have a LUKS2 encrypted volume, which isn't very common (or at least it wasn't at the moment I experienced the issue). In a few days I will try to boot my system both with and without kernel crypto to check whether it is necessary or not.
I can confirm that I still have problems booting my system when kernel crypto is enabled. I put this in my , in an updated unstable NixOS: With this configuration, my system boots. If I uncomment the line, it doesn't because it fails to unencrypt my root partition. I'm using LVM inside a LUKS2 partition.
Here is the result of using when mounting my LUKS2 volume with kernel crypto enabled. The last image is the most important. Sorry for pasting screenshots, I didn't have a flash drive to copy the logs. ! ! ! ! !
Thank you very much for your detailed analysis. :+1: Oh, LUKS2! Seems the userspace API is indeed needed for LUKS2 but not LUKS1. I'll try to adapt the test and fix this issue. There are probably just some modules missing.


Question: default = [ "aes" "aes_generic" "blowfish" "twofish" "serpent" "cbc" "xts" "lrw" "sha1" "sha256" "sha512" <ins> "af_alg" "algif_skcipher" </ins> (if pkgs.stdenv.hostPlatform.system == "x86_64-linux" then "aes_x86_64" else "aes_i586") ];

Commit introduced to the configuration of . This causes to no longer work, with the following message: Run , where is a truecrypt volume. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The issue for re-enabling kernel_crypto is
It also breaks
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 .
still important to me
I marked this as stale due to inactivity. →
are you sure this is still an issue? This seems to have been solved by . e.g. cryptsetup benchmark works just fine on my machine.
I did not check and do not care anymore. Thanks!


Question: libxcrypt lttng-ust_2_12 musl <ins> ]++ lib.optionals (stdenv.isLinux && stdenv.isAarch64) [ expat libxml2 xz </ins> ]; }).overrideAttrs (attrs: { postInstall = (attrs.postInstall or "") + lib.optionalString (stdenv.isLinux) '' (

Steps to reproduce the behavior: for n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --built from nixpkgs master () Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: buildInputs = lib.optionals (lib.versionOlder cudaVersion "11.4") [cudatoolkit] ++ lib.optionals (lib.versionAtLeast cudaVersion "11.4") [ <del> libcublas </del> <ins> libcublas.dev libcublas.lib libcublas.static </ins> cuda_cudart ] ++ lib.optionals (lib.versionAtLeast cudaVersion "12.0") [cuda_cccl];

singularity cannot use nvidia gpu because it does not access 'nvidia-container-cli' Steps to reproduce the behavior: return result of ! This is because the path is not listed in , as also in a. It is caused by neither the option nor . I tried to handle it with override, but since it was called in , I think it is impossible to handle. Also, I created a conf file in as shown in the singularity docs, but it was not read. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Thank you for reporting and sorry for the trouble. I'll look at the SingularityCE documentation again. (Those configuration options has been deprecated by Apptainer.) Also, I created a conf file in /usr/local/etc/singularity/ as shown in the singularity docs, but it was not read.  shold be what you are looking for. The overriden package can be assigned to . (If you would like to bypass all the overriding done by the module and directly specify the package to install for some special reason, you can assign it to .)
Thanks for the reply. I followed your advice and tried the override and was able to use the GPU. Here is the code This is simply adding a process to append the nvidia-docker path to the I mentioned earlier that when conf was entered in , it was not reflected, and the same is true for '/etc/singularity'. I referred to .
At least we have confirmed that in works and the path is replaced by , but the product does not seem to be recognizable.
Does setting the to make ldconfig search in help? This is modified from the configuration proposed by (). There's also (probably) related to this topic.
Adding the path of to works well. This once removed from consideration. Next we have a patched version of ldconfig. This does not append the path of to the config. The result was an error that could not be found, and it could not be started.
Oh, I already forgot about this issue. Absolutely coincidentally, but maybe efforts such as might open up a way to implement this hack more reliably.


Question: buildInputs = lib.optionals (lib.versionOlder cudaVersion "11.4") [cudatoolkit] ++ lib.optionals (lib.versionAtLeast cudaVersion "11.4") [ <del> libcublas </del> <ins> libcublas.dev libcublas.lib libcublas.static </ins> cuda_cudart ] ++ lib.optionals (lib.versionAtLeast cudaVersion "12.0") [cuda_cccl];

Meanwhile, in my config I'm still abusing You probably already have guessed, but singularity in nixpkgs is configured to read this config from the package-specific directory, rather than from the global . You could in principle override this behaviour, but there maybe isn't much value in supporting that
I tried to enable the use of external sysconfdir (), but have encountered issue trying to specify a directory under with the NixOS module ().
Have you tried to apply both at the same time?
The SingularityCE Admin Guide says If the value of nvidia-container-cli path is empty, SingularityCE will look for the binary on $PATH at runtime. It should work as long as is found in the run-time , even when is not set. As nvidia-container-cli is alredy included in the PATH-prefixing wrapper, we shouldn't have to set the .
Update: I found a bug in the prefixed PATH of the wrapper introduced in . The prefixing should be specified as (in Bash) I forgot to add , causing the trailing to be missing.
The statement in the SingularityCE Admin Guide turns out to be wrong / irrelevant. The source code clearly states that nvidia-container-cli will only be read from the configuration.
(we need to patch nvidia-container-cli, for many reasons )
Eh, actually, closed semi-automatically. Apptainer with is fixed (on NixOS), but not with . The fix doesn't concern singularity-ce either, unfortunately. Shouldn't be hard to make this work with singularity too, but I'm out of bandwidth
Hi folks, I've been trying to get apptainer to run this (which I've done previously successfully with a slight ldconfig hack -- that doesn't work anymore -- on NixOS 22.11), that will make use of the machine's Tesla V100 to do some simulation stuff. The machine is running NixOS 23.11. Using the workaround from 9th of May post further up, I was able to get past the ldconfig issue, but now I'm getting an error saying the driver and CUDA are not in sync.


Question: buildInputs = lib.optionals (lib.versionOlder cudaVersion "11.4") [cudatoolkit] ++ lib.optionals (lib.versionAtLeast cudaVersion "11.4") [ <del> libcublas </del> <ins> libcublas.dev libcublas.lib libcublas.static </ins> cuda_cudart ] ++ lib.optionals (lib.versionAtLeast cudaVersion "12.0") [cuda_cccl];

Before I start posting any details (I don't want to re-open this issue, but I'm also not sure if I'm just doing something wrong) I was wondering if the current implementation of singularity/apptainer on NixOS is expected to work, and I'm just being an idiot, or if there are known breaking issues? I've seen the other issues about singularity/apptainer here, but I'm not knowledgeable enough to make a judgement call if they are responsible for my problem or not. Thanks very much in advance!
(If I understood the message correctly) That usually means you need a reboot, and you should experience the same issue outside the container
No, the reboot didn't help either. For some reason, though, after upgrading to 24.05, everything "just works[tm]" again. So, whatever the issue was, thanks for fixing it (probably)! :)
Thanks to Nixpkgs 24.05 includes GPU-related changes/fixes to the package and the module.
Well more like thanks to ShamrockLee


Question: CMakeLists.txt ''; <del> postInstall = '' cp -r ${desktopItem}/share/applications $out/share ln -sf $out/bin/dolphin-emu $out/bin/dolphin-emu-master '' + lib.optionalString stdenv.hostPlatform.isLinux '' </del> <ins> postInstall = lib.optionalString stdenv.hostPlatform.isLinux '' </ins> install -D $src/Data/51-usb-device.rules $out/etc/udev/rules.d/51-usb-device.rules '';

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


Question: }) ]; <del> extraBuildCommands = '' mkdir -p steamrt </del> <ins> extraBuildCommands = '' mkdir -p steamrt ln -s ../lib/steam-runtime steamrt/${steam-runtime.arch} ${lib.optionalString (steam-runtime-i686 != null) '' ln -s ../lib32/steam-runtime steamrt/${steam-runtime-i686.arch} ''} ''; </ins> <del> ln -s ../lib64/steam-runtime steamrt/amd64 ln -s ../lib32/steam-runtime steamrt/i386 ''; </del> <ins> extraInstallCommands = '' mkdir -p $out/share/applications ln -s ${steam}/share/icons $out/share ln -s ${steam}/share/pixmaps $out/share sed "s,/usr/bin/steam,$out/bin/steam,g" ${steam}/share/applications/steam.desktop > $out/share/applications/steam.desktop ''; </ins> <del> extraInstallCommands = '' mkdir -p $out/share/applications ln -s ${steam}/share/icons $out/share ln -s ${steam}/share/pixmaps $out/share sed "s,/usr/bin/steam,$out/bin/steam,g" ${steam}/share/applications/steam.desktop > $out/share/applications/steam.desktop ''; </del> <ins> profile = '' export STEAM_RUNTIME=/steamrt ''; </ins> <del> profile = '' export STEAM_RUNTIME=/steamrt ''; </del> <ins> runScript = "steam"; </ins> <del> runScript = "steam"; } </del> <ins> passthru.run = buildFHSUserEnv (self // { name = "steam-run"; runScript = let ldPath = map (x: "/steamrt/${steam-runtime.arch}/" + x) steam-runtime.libs ++ lib.optionals (steam-runtime-i686 != null) (map (x: "/steamrt/${steam-runtime-i686.arch}/" + x) steam-runtime-i686.libs); in writeScript "steam-run" '' #!${stdenv.shell} run="$1" if [ "$run" = "" ]; then echo "Usage: steam-run command-to-run args..." >&2 exit 1 fi shift export LD_LIBRARY_PATH=${lib.concatStringsSep ":" ldPath}:$LD_LIBRARY_PATH exec "$run" "$@" ''; passthru = {}; }); }; in buildFHSUserEnv self </ins>

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


Question: }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "proton-pass"; <del> version = "1.20.2"; </del> <ins> version = "1.22.0"; </ins> src = fetchurl { url = "https://proton.me/download/PassDesktop/linux/x64/ProtonPass_${finalAttrs.version}.deb"; <del> hash = "sha256-4QSBKVnEH7yDXwqY+29/a+yWv89i/TVCYO26V95KA4s="; </del> <ins> hash = "sha256-ARIUHmU/YN8IoAFMkcxzGAoH31vbJLT7HfYD6a57QaY="; </ins> }; dontConfigure = true;

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


Question: }; postPatch = '' <del> addAutoPatchelfSearchPath ${jre8}/lib/openjdk/jre/lib/ </del> <ins> addAutoPatchelfSearchPath ${jdk}/lib/openjdk/lib/ </ins> autoPatchelf lib # Nix cannot see the runtime references to the paths we just patched in

Wanted to install and start sweethomed.application. the build worked without problems but when i started it, it didnt started. Steps to reproduce the behavior: sweethome3d.application via configuration file to start it Starting the Application stucks at the start screen ! Add any other context about the problem here. At the moment its installed in my user context. When i try to start it as my user over the terminal i get no errors. When i start it with "sudo sweethome3d" I get the following error, and it also dont start, also start at starting screen and vanishing from the task bar: I think these happens because its not installed as user, but propably it helps to find the issue.
Starting random applications as root seems like an unwise idea.
Apologies, I misread the error, this appears to be a separate issue
Just to confirm, which GPU do you use?
I've got the same issue, and none of the solutions given in appear to work. On my side says my GPU is . EDIT: I should mention SH3D 7.02 works fine on my setup Mmh, I just tried with , and things work just fine (even though I'm on NixOS + tells me OpenGL is happy)...
Same problem here, on NIXOS unstable. Stuck on the starting blue window. Had to install it with flatpak in the mean time... Any idea?
sorry for delay i dont get informations from messages in last time from github... really annoying... I have an Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
Same here, also on Intel hardware.
Based on the NixGL idea, applying the following patch works to update to the latest version and fix the driver issue on Intel. But this does not seem like the best way to go about it; I can't find a single other package messing with , and it seems more like a debugging tool than something that should be in a package.
I forgot to mention, to avoid getting terrible performance (< 1 fps), I also had to set Not sure if it's needed for others. Maybe related to my using Wayland/Sway. I also have to use to get the window displayed properly, but that's a common issue for most Java apps and tiling windowing managers.
I also ran into this issue with a Nvidia card.


Question: }; postPatch = '' <del> addAutoPatchelfSearchPath ${jre8}/lib/openjdk/jre/lib/ </del> <ins> addAutoPatchelfSearchPath ${jdk}/lib/openjdk/lib/ </ins> autoPatchelf lib # Nix cannot see the runtime references to the paths we just patched in

For me, was needed (with patch). I also needed . and didn't seem needed (or give noticable changes).


Question: installTargets = [ "install" "install-lib" ]; <del> # Get rid of update-pciids as it won't work. postInstall = "rm $out/sbin/update-pciids $out/man/man8/update-pciids.8"; </del> <ins> postInstall = '' # Remove update-pciids as it won't work on nixos rm $out/sbin/update-pciids $out/man/man8/update-pciids.8 # use database from hwdata instead # (we don't create a symbolic link because we do not want to pull in the # full closure of hwdata) cp --reflink=auto ${hwdata}/share/hwdata/pci.ids $out/share/pci.ids ''; </ins> meta = with lib; { homepage = "http://mj.ucw.cz/pciutils.html";

Describe the bug pciutils is using a really old file which doesn't include any definitions for AMD Radeon 6800 XT cards. When running you get the following output If you get a newer version of the file from https://pci- which update-pciids script in package normally updates (but is disabled in nix package). You get the following: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wil): nixpkgs: Maintainer information:
Should also mention when running strace on lspci it reads the file from /nix/store/464020m9r6mhsivgp9v1bhkyzz5pa0gq-pciutils- and not from hwdata like I originally thought.
Would it make sense to make lspci depend on hwdata and then use from hwdata? cc'ing (who is listed as shadow maintainer of pciutils)
Hmm, makes sense. Except that seems to be in significantly more closures than , so depending on the extra 6+ MB of other data seems significant. Perhaps make put it into a separate output? Or could just copy it as a quick work-around (that's free for people with )
Oh, we can't "just" make multi-output, as it's a fixed-output derivation, but we could fake it through multiple derivations. Maybe just the work-around for simplicity then?
I think the work-around is actually pretty sensible. I'll prepare a pull request :-) Update: Did so, . Once both and are merged, our issue should be resolved.
Thanks for fixing that :). I tried your two updates on my machine and it appears to be resolved. Closing the issue out. Now we just wait for this to get into unstable :).


Question: globalAsserts = prefix: cfg: flatten [ <del> (assertKeysValid prefix freeformGlobalKeys cfg.settings) </del> <ins> (assertKeysValid "${prefix}.settings" freeformGlobalKeys cfg.settings) </ins> (imap0 (n: l: listenerAsserts "${prefix}.listener.${toString n}" l) cfg.listeners) (mapAttrsToList (n: b: bridgeAsserts "${prefix}.bridge.${n}" b) cfg.bridges) ];

lists a listener option called that can be used to listen for incoming network connections only on the specified interface. Unfortunately does not accept this option. Steps to reproduce the behavior: This should evaluate cleanly. Incidentally, that assertion message drops the component in the attribute path, it might be nice to fix that.


Question: repo = "river"; rev = "refs/tags/v${finalAttrs.version}"; fetchSubmodules = true; <del> hash = "sha256-I09cR5aN7qXOzV9HDXaL4TjoeJcVa0Ch00zxOJokdDE="; </del> <ins> hash = "sha256-DYaxtYJLZQqE2SyPfWec/zXsZKRnxK2QNgOkM7GJkLI="; </ins> }; deps = callPackage ./build.zig.zon.nix { };

Package name: river Latest released version: 0.3.3 <!-- Search your package here: --- Current version on the unstable channel: 0.3.2 Current version on the stable/release channel: 0.3.2 <!-- 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]:
3 is only a zig 0.13 compatibility release. It’s blocked by
has been merged, this is not blocked anymore.


Question: maintainers = with maintainers; [ fab ]; platforms = platforms.linux; }; <del> } </del> <ins> }) </ins>

Steps to reproduce the behavior: g810-led Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: installed_test_metadir = "${placeholder "installedTests"}/share/installed-tests/flatpak-builder"; in stdenv.mkDerivation rec { pname = "flatpak-builder"; <del> version = "1.0.10"; </del> <ins> version = "1.0.11"; </ins> outputs = [ "out" "doc" "man" "installedTests" ]; src = fetchurl { url = "https://github.com/flatpak/flatpak-builder/releases/download/${version}/${pname}-${version}.tar.xz"; <del> sha256 = "1fn61cl1d33yd1jgqm8jpffjw3xlyyhkn032g14d9gnwkcaf4649"; </del> <ins> sha256 = "EYNLdrvSs8S/GCYy0jGsnP1+C988y1j7WzcLfczM1Ew="; </ins> }; nativeBuildInputs = [

Describe the bug flatpak-builder for some reasons can't use rofiles-fuse To Reproduce Steps to reproduce the behavior: build any app using flatpak-builder Expected behavior flatpak-builder should use rofiles-fuse. Screenshots Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
installing solve this problem so maybe should be ?
We patch the paths to the executables to be hardcoded, so the program doesn't have to rely on something like ostree being installed. I believe one path isn't hardcoded with the current patch That looks it up in PATH, probably why it was working once you installed it.
cc
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
should fix that issue.


Question: owner = "OpenMW"; repo = "openmw"; rev = name; <del> sha256 = "0lj8v81hk807dy0wcdhfp0iyn4l5yag53hx1a6xm44gh2dpyil43"; </del> <ins> sha256 = "1nybxwp77qswjayf0g9xayp4x1xxq799681rhjlggch127r07ifi"; </ins> }; enableParallelBuilding = true;

The version claimed to be produced by the openmw derivation is , however once installed it is still version system: host os: multi-user?: sandbox: version: channels(avery): channels(root): nixpkgs:


Question: <xi:include href="beam.xml" /> <xi:include href="bower.xml" /> <xi:include href="coq.xml" /> <ins> <xi:include href="gnome.xml" /> </ins> <xi:include href="go.xml" /> <xi:include href="haskell.section.xml" /> <xi:include href="idris.section.xml" />

I just found out about wrapGAppsHook by examining a gnome package, but there really should be documentation about this in the Nixpkgs User Guide (a section about Gnome would be nice, which would show the right way to package GTK3 / GTK2 glib based apps). Also, perhaps there are other things I missed that one should know when packaging Gnome Applications or GTK3/2 apps? /cc Gnome maintainers
I'd like to know as well. Currently receiving this error: On one of the packages I'm trying to put into nixpkgs. Apparently sometimes you need for buildInputs. So apparently all you need to do to use this is:
The error occurs when you do not have any directory containing in variable. One of the things does is (which usually contains the aforementioned file) of dependencies to . (Actually this happens in cooperation with via variable.) Icon themes work in the same vein, only is used and it is populated by which is propagated to (). (XDG fallback theme) should be probably to any GTK application that uses icons (I think that is every GTK applicaton nowadays due to CSD) but some applications require Adwaita because they use icons not in hicolor. Not sure if this functions correctly though, at least it should not according to my mental model of how icon theme selection works; I will need to read the relevant XDG spec before I can finish the documentation.
Just thought I'd leave this comment here for future reference: if you get an error like for python gtk applications, try adding to propogatedBuildInputs!
It should go to , though. But be wary of


Question: <ins> diff -Naur mpd-0.19.9.orig/configure mpd-0.19.9/configure --- mpd-0.19.9.orig/configure	2015-01-26 19:47:27.000000000 +0000 +++ mpd-0.19.9/configure	2015-01-26 19:47:27.000000000 +0000 @@ -17113,138 +17113,6 @@ done -if test x$no_exceptions = xyes; then - - - - -for flag in -fno-exceptions; do -  as_CACHEVAR=`$as_echo "ax_cv_check_cxxflags__$flag" | $as_tr_sh` -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether C++ compiler accepts $flag" >&5 -$as_echo_n "checking whether C++ compiler accepts $flag... " >&6; } -if eval ${$as_CACHEVAR+:} false; then : -  $as_echo_n "(cached) " >&6 -else - -  ax_check_save_flags=$CXXFLAGS -  CXXFLAGS="$CXXFLAGS  $flag" -  cat confdefs.h - <<_ACEOF >conftest.$ac_ext -/* end confdefs.h.  */ - -int -main () -{ - -  ; -  return 0; -} -_ACEOF -if ac_fn_cxx_try_compile "$LINENO"; then : -  eval "$as_CACHEVAR=yes" -else -  eval "$as_CACHEVAR=no" -fi -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext -  CXXFLAGS=$ax_check_save_flags -fi -eval ac_res=$$as_CACHEVAR -	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5 -$as_echo "$ac_res" >&6; } -if test x"`eval 'as_val=${'$as_CACHEVAR'};$as_echo "$as_val"'`" = xyes; then : -  if ${CXXFLAGS+:} false; then : -  case " $CXXFLAGS " in -    *" $flag "*) -      { { $as_echo "$as_me:${as_lineno-$LINENO}: : CXXFLAGS already contains $flag"; } >&5 -  (: CXXFLAGS already contains $flag) 2>&5 -  ac_status=$? -  $as_echo "$as_me:${as_lineno-$LINENO}: $? = $ac_status" >&5 -  test $ac_status = 0; } -      ;; -    *) -      { { $as_echo "$as_me:${as_lineno-$LINENO}: : CXXFLAGS="$CXXFLAGS $flag""; } >&5 -  (: CXXFLAGS="$CXXFLAGS $flag") 2>&5 -  ac_status=$? -  $as_echo "$as_me:${as_lineno-$LINENO}: $? = $ac_status" >&5 -  test $ac_status = 0; } -      CXXFLAGS="$CXXFLAGS $flag" -      ;; -   esac -else -  CXXFLAGS="$flag" -fi - -else -  : -fi - -done - - - - - -for flag in -fno-rtti; do -  as_CACHEVAR=`$as_echo "ax_cv_check_cxxflags__$flag" | $as_tr_sh` -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether C++ compiler accepts $flag" >&5 -$as_echo_n "checking whether C++ compiler accepts $flag... " >&6; } -if eval ${$as_CACHEVAR+:} false; then : -  $as_echo_n "(cached) " >&6 -else - -  ax_check_save_flags=$CXXFLAGS -  CXXFLAGS="$CXXFLAGS  $flag" -  cat confdefs.h - <<_ACEOF >conftest.$ac_ext -/* end confdefs.h.  */ - -int -main () -{ - -  ; -  return 0; -} -_ACEOF -if ac_fn_cxx_try_compile "$LINENO"; then : -  eval "$as_CACHEVAR=yes" -else -  eval "$as_CACHEVAR=no" -fi -rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext -  CXXFLAGS=$ax_check_save_flags -fi -eval ac_res=$$as_CACHEVAR -	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5 -$as_echo "$ac_res" >&6; } -if test x"`eval 'as_val=${'$as_CACHEVAR'};$as_echo "$as_val"'`" = xyes; then : -  if ${CXXFLAGS+:} false; then : -  case " $CXXFLAGS " in -    *" $flag "*) -      { { $as_echo "$as_me:${as_lineno-$LINENO}: : CXXFLAGS already contains $flag"; } >&5 -  (: CXXFLAGS already contains $flag) 2>&5 -  ac_status=$? -  $as_echo "$as_me:${as_lineno-$LINENO}: $? = $ac_status" >&5 -  test $ac_status = 0; } -      ;; -    *) -      { { $as_echo "$as_me:${as_lineno-$LINENO}: : CXXFLAGS="$CXXFLAGS $flag""; } >&5 -  (: CXXFLAGS="$CXXFLAGS $flag") 2>&5 -  ac_status=$? -  $as_echo "$as_me:${as_lineno-$LINENO}: $? = $ac_status" >&5 -  test $ac_status = 0; } -      CXXFLAGS="$CXXFLAGS $flag" -      ;; -   esac -else -  CXXFLAGS="$flag" -fi - -else -  : -fi - -done - -fi </ins>

nix fails to build libjack2 and libpulseaudio on darwin too (probably another two issues should be filed?). mpd build log is the third one. After disabling libjack2: After disabling libpulseaudio: I'm no expert in c++ but quick googling shows that exceptions are disabled by default when building with xcode toolchain. On a side note, which way is proper to manage ? I'm editing expression in but not sure if that is the right way. I'm using OS X 10.10.4, nix-env 1.9, nixpkgs from master HEAD.
Compilation fails on throw from boost library and mpd sources are compiling with , so I've to mpd expression but still no luck here.
Seems like this didn't get resolved and it's been a while... I have mpd failing to build on Darwin also, but with a different error, CoreAudio related. I'm using a local nixpkgs checked out at , OS X 10.11.3. Here's the failure:


Question: <del> { stdenv, lib, fetchFromGitHub, cmake, nasm , gtk2, glib, ffmpeg_4, alsa-lib, libmad, libogg, libvorbis , glew, libpulseaudio, udev </del> <ins> { lib , stdenv , fetchFromGitHub , fetchpatch , cmake , nasm , alsa-lib , ffmpeg_6 , glew , glib , gtk2 , libmad , libogg , libpulseaudio , libvorbis , udev , xorg </ins> }: <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation { </ins> pname = "stepmania"; <del> version = "5.1.0-b2"; </del> <ins> version = "5.1.0-b2-unstable-2022-11-14"; </ins> src = fetchFromGitHub { owner = "stepmania"; repo  = "stepmania"; <del> rev   = "v${version}"; sha256 = "0a7y9l7xm510vgnpmj1is7p9m6d6yd0fcaxrjcickz295k5w3rdn"; </del> <ins> rev   = "d55acb1ba26f1c5b5e3048d6d6c0bd116625216f"; hash = "sha256-49H2Q61R4l/G0fWsjCjiAUXeWwG3lcsDpV5XvR3l3QE="; </ins> }; patches = [ <del> ./0001-fix-build-with-ffmpeg-4.patch </del> <ins> # https://github.com/stepmania/stepmania/pull/2247 (fetchpatch { name = "fix-building-with-ffmpeg6.patch"; url = "https://github.com/stepmania/stepmania/commit/3fef5ef60b7674d6431f4e1e4ba8c69b0c21c023.patch"; hash = "sha256-m+5sP+mIpcSjioRBdzChqja5zwNcwdSNAfvSJ2Lww+g="; }) </ins> ]; postPatch = ''

Describe the bug The menu icon for Stepmania is missing. To Reproduce Steps to reproduce the behavior: to find it in the Applications menu. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. →


Question: --log-config-json $out/share/immich/log_conf.json" ''; <ins> passthru.tests = { inherit (nixosTests) immich; }; </ins> meta = { description = "Self-hosted photo and video backup solution (machine learning component)"; homepage = "https://immich.app/";

Build on () and when running I find the following in the runtime closure: pytest shouldn't be a runtime dependency Seems to be a regression, did not have this issue Might be able to bisect this one, but it'll take a while <!-- 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]:
After bisecting, first bad commit is (


Question: nativeBuildInputs = [ nukeReferences <ins> pkg-config </ins> xz ] ++ lib.optionals stdenv.hostPlatform.isDarwin [ fixDarwinDylibNames ];

cannot process svg files despite the documentation advertising it can. Steps to reproduce the behavior: SVG should be supported Introduced in Build logs: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: }: let pname = "polars"; <del> version = "0.20.0"; </del> <ins> version = "0.19.12"; </ins> rootSource = fetchFromGitHub { owner = "pola-rs"; repo = "polars";

Running shows a version that is different from the one in the Nix store file name. Run The output will look something like: Notice the store path says while the command show that the version is actually 0.19.12. The two versions match. I ran into this because I tried to use and got the error "has no attribute 'replace'": According to this part of the API was released at least in version 0.19.16, so it would confirm that the version I have installed is in fact 0.19.12. <!-- 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]:
PR only updated the version and not the hash.
Thanks, well spotted! when I merely update the hash I end up with this error:
hey, after having had just a quick look, I've opened I haven't tested though, could you help with testing and let me know if that works ?
ah, I've just had a compilation failure. This is because the maturin used currently is 1.3.0 and polars requires 1.3.2. the bump is also going to require a maturin bump. Are you interested in taking care of it ? Otherwise I should be able to make some time at some point.
Thanks for this! I might try it out in the next few days :)
alright, I've tried with maturin 1.3.2, but I still get a rust compilation failure. I've checked their MSRV and it's only 1.71. So I don't know what could be causing this compilation failure. if you have any ideas, feel free to re-use anything from that PR without any need for attribution. I'll be happy to help merge a solution.
might be worth setting the version back to in the meantime so the package will build on a cache miss.
so version has been set back to 0.19.12. I have finally had some luck in compiling the latest polars version in if anyone is interested to test the PR, feel free to post a comment. I'm running a nixpkgs-review to check what the update breaks


Question: { lib <del> , stdenv , fetchFromGitHub </del> , rustPlatform <ins> , fetchFromGitHub , stdenv </ins> , Security }: rustPlatform.buildRustPackage rec { pname = "routinator"; <del> version = "0.10.1"; </del> <ins> version = "0.10.2"; </ins> src = fetchFromGitHub { owner = "NLnetLabs"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-ThgTGtTZ0LGm9nHJoy0KhnBFWNvKRjk7hoNTVVTeL/Y="; </del> <ins> sha256 = "0a2iwpmljkha6qlbw0373wph7pxz05qym5712vzbszw0z42f82l2"; </ins> }; cargoPatches = [ ./Cargo.toml.patch ]; <del> cargoSha256 = "sha256-mcx+qUtTUxeYP0PeJp1eOQwsdS6PPUx/m7TfAyqFiIM="; </del> <ins> cargoSha256 = "0l3fhwgrdvjrlmiqdy90sfd8kb2s7y0lbfswlrr560ly0bi1lfbx"; </ins> buildInputs = lib.optionals stdenv.isDarwin [ Security ]; <ins> buildNoDefaultFeatures = true; buildFeatures = [ "socks" ]; </ins> meta = with lib; { description = "An RPKI Validator written in Rust"; homepage = "https://github.com/NLnetLabs/routinator"; <ins> changelog = "https://github.com/NLnetLabs/routinator/blob/v${version}/Changelog.md"; </ins> license = licenses.bsd3; maintainers = with maintainers; [ _0x4A6F ]; <del> platforms = platforms.all; </del> }; }

, CVSSv3=7.5 (nixos-21.05) CVSSv3=7.5 (nixos-21.05) CVSSv3=7.5 (nixos-21.05) NLnet Labs Routinator prior to 0.10.2 happily processes a chain of RRDP repositories of infinite length causing it to never finish a validation run. In RPKI, a CA can choose the RRDP repository it wishes to publish its data in. By continuously generating a new child CA that only consists of another CA using a different RRDP repository, a malicious CA can create a chain of CAs of de-facto infinite length. Routinator prior to version 0.10.2 did not contain a limit on the length of such a chain and will therefore continue to process this chain forever. As a result, the validation run will never finish, leading to Routinator continuing to serve the old data set or, if in the initial validation run directly after starting, never serve any data at all. In NLnet Labs Routinator prior to 0.10.2, a validation run can be delayed significantly by an RRDP repository by not answering but slowly drip-feeding bytes to keep the connection alive. This can be used to effectively stall validation. While Routinator has a configurable time-out value for RRDP connections, this time-out was only applied to individual read or write operations rather than the complete request. Thus, if an RRDP repository sends a little bit of data before that time-out expired, it can continuously extend the time it takes for the request to finish. Since validation will only continue once the update of an RRDP repository has concluded, this delay will cause validation to stall, leading to Routinator continuing to serve the old data set or, if in the initial validation run directly after starting, never serve any data at all. NLnet Labs Routinator versions 0.9.0 up to and including 0.10.1, support the gzip transfer encoding when querying RRDP repositories. This encoding can be used by an RRDP repository to cause an out-of-memory crash in these versions of Routinator. RRDP uses XML which allows arbitrary amounts of white space in the encoded data.


Question: { lib <del> , stdenv , fetchFromGitHub </del> , rustPlatform <ins> , fetchFromGitHub , stdenv </ins> , Security }: rustPlatform.buildRustPackage rec { pname = "routinator"; <del> version = "0.10.1"; </del> <ins> version = "0.10.2"; </ins> src = fetchFromGitHub { owner = "NLnetLabs"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-ThgTGtTZ0LGm9nHJoy0KhnBFWNvKRjk7hoNTVVTeL/Y="; </del> <ins> sha256 = "0a2iwpmljkha6qlbw0373wph7pxz05qym5712vzbszw0z42f82l2"; </ins> }; cargoPatches = [ ./Cargo.toml.patch ]; <del> cargoSha256 = "sha256-mcx+qUtTUxeYP0PeJp1eOQwsdS6PPUx/m7TfAyqFiIM="; </del> <ins> cargoSha256 = "0l3fhwgrdvjrlmiqdy90sfd8kb2s7y0lbfswlrr560ly0bi1lfbx"; </ins> buildInputs = lib.optionals stdenv.isDarwin [ Security ]; <ins> buildNoDefaultFeatures = true; buildFeatures = [ "socks" ]; </ins> meta = with lib; { description = "An RPKI Validator written in Rust"; homepage = "https://github.com/NLnetLabs/routinator"; <ins> changelog = "https://github.com/NLnetLabs/routinator/blob/v${version}/Changelog.md"; </ins> license = licenses.bsd3; maintainers = with maintainers; [ _0x4A6F ]; <del> platforms = platforms.all; </del> }; }

The gzip scheme compresses such white space extremely well, leading to very small compressed files that become huge when being decompressed for further processing, big enough that Routinator runs out of memory when parsing input data waiting for the next XML element. Scanned versions: nixos-21.05: . Cc


Question: getPatches = dir: let files = builtins.attrNames (builtins.readDir dir); in map (f: dir + ("/" + f)) files; <del> version = "2.5.1"; </del> <ins> version = "2.8.0"; </ins> channel = "stable"; filename = "flutter_linux_${version}-${channel}.tar.xz"; # Decouples flutter derivation from dart derivation, # use specific dart version to not need to bump dart derivation when bumping flutter. <del> dartVersion = "2.14.2"; </del> <ins> dartVersion = "2.15.0"; </ins> dartSourceBase = "https://storage.googleapis.com/dart-archive/channels"; dartForFlutter = dart.override { version = dartVersion; sources = { "${dartVersion}-x86_64-linux" = fetchurl { url = "${dartSourceBase}/stable/release/${dartVersion}/sdk/dartsdk-linux-x64-release.zip"; <del> sha256 = "1gr2dr683kz0a0k6rcn4jcbxf9fr2xlzi5fcgn1lzrrxvys2lddx"; </del> <ins> sha256 = "sha256-U1V1OPmFeNZCdBxFy7yqAbAE0cxh9f2UqKQmreJu9YA="; </ins> }; }; };

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


Question: <ins> { lib , stdenv , fetchFromGitHub , cmake }: stdenv.mkDerivation (finalAttrs: { pname = "iir1"; version = "1.9.4"; src = fetchFromGitHub { owner = "berndporr"; repo = "iir1"; rev = finalAttrs.version; hash = "sha256-T8gl51IkZIGq+6D5ge4Kb3wm5aw7Rhphmnf6TTGwHbs="; }; nativeBuildInputs = [ cmake ]; meta = { homepage = "https://berndporr.github.io/iir1/"; description = "A DSP IIR realtime filter library written in C++"; downloadPage = "https://github.com/berndporr/iir1"; changelog = "https://github.com/berndporr/iir1/releases/tag/${finalAttrs.src.rev}"; license = with lib.licenses; [ mit ]; maintainers = with lib.maintainers; [ AndersonTorres ]; platforms = lib.platforms.unix; }; }) </ins>

Steps to reproduce the behavior: dosbox-staging on darwin Complaining that alsa-lib not available on darwin I suggest referencing the derivation of in which use to opt-in dependencies P.S. wonder why the maintenance of this package is separated from and Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't have a Darwin machine. Nice. A full log would be nicer of course, but nice nonetheless. Wonder why they should be maintained by the same people.


Question: buildInputs = [ libnl ]; preBuild = '' <del> makeFlags="PREFIX=$out PKG_CONFIG=${pkg-config}/bin/${pkg-config.targetPrefix}pkg-config" </del> <ins> makeFlags="PREFIX=$out" </ins> ''; meta = {

Failed to cross compile batctl package for riscv64 using nixpkgs on Ubuntu. Nix is not able to meat the dependency for the package: While the package successfully cross compiles on a NixOS* machine. Steps to reproduce the behavior: nix environment on a Ubuntu machine. and cross compile batctl package for riscv64. Below is the command I am using: attached nix-info not availble on Ubuntu
can you give the version of nix and the revision of nixpkgs (it might be in a file called .git-revision).
is the sandbox enabled, if they're at the same rev
Turns out I couldn't reproduce it because my machine has riscv emulation enabled, the makefile is calling a riscv version of pkg-config. I'm testing a fix to the problem at the moment


Question: , fetchurl , makeWrapper , makeDesktopItem <del> # sweethome3d 6.5.2 does not yet fully build&run with jdk 9 and later? , jdk8 , jre8 </del> <ins> , jdk </ins> , ant , gtk3 , gsettings-desktop-schemas

Wanted to install and start sweethomed.application. the build worked without problems but when i started it, it didnt started. Steps to reproduce the behavior: sweethome3d.application via configuration file to start it Starting the Application stucks at the start screen ! Add any other context about the problem here. At the moment its installed in my user context. When i try to start it as my user over the terminal i get no errors. When i start it with "sudo sweethome3d" I get the following error, and it also dont start, also start at starting screen and vanishing from the task bar: I think these happens because its not installed as user, but propably it helps to find the issue.
Starting random applications as root seems like an unwise idea.
Apologies, I misread the error, this appears to be a separate issue
Just to confirm, which GPU do you use?
I've got the same issue, and none of the solutions given in appear to work. On my side says my GPU is . EDIT: I should mention SH3D 7.02 works fine on my setup Mmh, I just tried with , and things work just fine (even though I'm on NixOS + tells me OpenGL is happy)...
Same problem here, on NIXOS unstable. Stuck on the starting blue window. Had to install it with flatpak in the mean time... Any idea?
sorry for delay i dont get informations from messages in last time from github... really annoying... I have an Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
Same here, also on Intel hardware.
Based on the NixGL idea, applying the following patch works to update to the latest version and fix the driver issue on Intel. But this does not seem like the best way to go about it; I can't find a single other package messing with , and it seems more like a debugging tool than something that should be in a package.
I forgot to mention, to avoid getting terrible performance (< 1 fps), I also had to set Not sure if it's needed for others. Maybe related to my using Wayland/Sway. I also have to use to get the window displayed properly, but that's a common issue for most Java apps and tiling windowing managers.
I also ran into this issue with a Nvidia card.


Question: , fetchurl , makeWrapper , makeDesktopItem <del> # sweethome3d 6.5.2 does not yet fully build&run with jdk 9 and later? , jdk8 , jre8 </del> <ins> , jdk </ins> , ant , gtk3 , gsettings-desktop-schemas

For me, was needed (with patch). I also needed . and didn't seem needed (or give noticable changes).


Question: sha256 = "0g89al4kwfbx1l3zjddgb9ay4mhr7zk0ndchca3sm1vq2j47nf4l"; }; <ins> # This patch is required for version 2.2.1. As the patch is already part of # upstream master, it will be incorporated into the next release. The patch # fixes a (well-justified) compiler warning which breaks the build because # we compile with -Werror. patches = [ (fetchpatch { url = "https://github.com/Nuand/bladeRF/commit/163425d48a3b7d8c100d7295220d3648c050d0dd.patch"; sha256 = "1swsymlyxm3yk2k8l71z1fv0a5k2rmab02f0c7xkrvk683mq6yxw"; }) ]; </ins> nativeBuildInputs = [ pkgconfig ]; # ncurses used due to https://github.com/Nuand/bladeRF/blob/ab4fc672c8bab4f8be34e8917d3f241b1d52d0b8/host/utilities/bladeRF-cli/CMakeLists.txt#L208 buildInputs = [ cmake git doxygen help2man tecla libusb1 ]

Describe the bug libbladeRF fails to build on the nixos-unstable channel and latest master: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Cannot reproduce this in master. I am on . Was this fixed in ?
I have just tried on , here is a full log:
Can also confirm that the build fails on .
This appears to me a genuine error in the source. Live bladerf1.c:841 (and also bladerf2.c:283) reference , but it should be . With , we stop the build on purpose. Luckily the typo is not of further consequence, since both values are numerically the same (both zero). I will try to report this to upstream.
Oh nice, this has already been fixed in upstream master (in from last May to be precise), but there isn't yet a new release containing a fix. I'll prepare a pull request cherrypicking this patch. Be aware though that I cannot test libbladeRF (in fact I don't even know what it is about :-)).
maybe also add . This options is meant for development where there is control over the compiler, but in nixpkgs we want to update gcc without breaking half the packages due to warnings.
I see, thank you for the suggestion! Generally I'm in favor of , but your argument is quite reasonable. I'll force-push in a second.


Question: # code refactoring of bcachefs-tools broke reading passphrases from stdin (vs. terminal) # upstream issue https://github.com/koverstreet/bcachefs-tools/issues/261 ./fix-encrypted-boot.patch <ins> # https://github.com/koverstreet/bcachefs-tools/pull/305 (fetchpatch { name = "use-ar-var-in-makefile.patch"; url = "https://github.com/koverstreet/bcachefs-tools/commit/91e67ab2bd48fa135a1f5109b23899a4f1019a03.patch"; sha256 = "sha256-nB4Tgcwa8eeasIDQ4rrYORie/X8LMuCSRi+WJNw+R/U="; }) </ins> ]; <ins> postPatch = '' substituteInPlace Makefile  --replace-fail "target/release/bcachefs" "target/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/bcachefs" ''; </ins> preCheck = lib.optionalString (!fuseSupport) '' rm tests/test_fuse.py '';

This is . Trying to build bcachefs-tools` for an aarch64-linux from x86_64-linux produces: I think comes from binutils. Adding binutils to nativeBuildInputs wasn't enough to fix it.
It's using a non-prefixed version of , it should instead be using
And after that we need to pass something like to cargo (or maybe directly to rustc?) somewhere. And we're spoiled for choice here: from in the Makefile to and env variables to maybe even .
I was able to fix this partially with this diff: That fixed the issue but seems like our libraries are incompatible? <details</details
Something has to be substituted in the source because ar is hardcoded
Applying that patch and adding The build now fails at
command encounters an error? Weird.
The built file is in instead of


Question: --prefix LD_LIBRARY_PATH : ${libPath} ''; <del> postInstall = '' </del> <ins> postInstall = lib.optionalString stdenv.isDarwin '' mkdir -p $out/Applications cp -r extra/osx/Neovide.app $out/Applications ln -s $out/bin $out/Applications/Neovide.app/Contents/MacOS '' + lib.optionalString stdenv.isLinux '' </ins> for n in 16x16 32x32 48x48 256x256; do install -m444 -D "assets/neovide-$n.png"  "$out/share/icons/hicolor/$n/apps/neovide.png"

On aarch64-darwin, while neovide does build and install successfully and I can launch it from the terminal, there is no app bundle that can be found in finder to launch neovide from there or pin it to the dock to launch from. Once opened the global menu calls it .neovide-unwrapped and the icon in the dock is a blank white page as a generic icon. I can only assume that once is fixed, that this will also be applicable to x86_64-darwin Steps to reproduce the behavior: neovide as either a system app in nix-darwin or a user app in home-manager on aarch64-darwin An app bundle name that will be linked into or depending on and usage I'd like to point out that the global menu title is .neovide-unwrapped to for sure indicate that this is the nix neovide and not the homebrew neovide ! ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Following PR MacOS app information a few days ago: We can install the files with next release of neovide.


Question: buildCommand = "sed s/dot_root/agroot/g ${raw_patch} > $out"; }; # 2.42 has the patch included <del> patches = optional (lib.versionOlder version "2.42") patchToUse; </del> <ins> patches = optional (lib.versionOlder version "2.42") patchToUse ++ optionals (lib.versionOlder version "2.46.0") [ (fetchpatch { name = "CVE-2020-18032.patch"; url = "https://gitlab.com/graphviz/graphviz/-/commit/784411ca3655c80da0f6025ab20634b2a6ff696b.patch"; sha256 = "1nkw9ism8lkfvxsp5fh95i2l5s5cbjsidbb3g1kjfv10rxkyb41m"; }) ]; </ins> in stdenv.mkDerivation {

, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
NixOS 20.09 is EOL, so this issue isn't actionable anymore.


Question: buildCommand = "sed s/dot_root/agroot/g ${raw_patch} > $out"; }; # 2.42 has the patch included <del> patches = optional (lib.versionOlder version "2.42") patchToUse; </del> <ins> patches = optional (lib.versionOlder version "2.42") patchToUse ++ optionals (lib.versionOlder version "2.46.0") [ (fetchpatch { name = "CVE-2020-18032.patch"; url = "https://gitlab.com/graphviz/graphviz/-/commit/784411ca3655c80da0f6025ab20634b2a6ff696b.patch"; sha256 = "1nkw9ism8lkfvxsp5fh95i2l5s5cbjsidbb3g1kjfv10rxkyb41m"; }) ]; </ins> in stdenv.mkDerivation {

, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
09 is EOL


Question: # backends , enableDeckjsBackend ? false , enableOdfBackend ? false <ins> # java is problematic on some platforms, where it is unfree , enableJava ? true </ins> }: assert enableStandardFeatures ->

Since is provided by the non-free on aarch64, I'm not able to install asciidoc-full or any software that requires it to create e.g. the man pages. Can we make an option different from ? /cc
Making new granular options is fine, but I think enableStandardFeatures should still include java. (Or else the option is dishonest.) Alternatively, can we switch to openjdk (assuming that works on aarch64)?
It was just recently changed to in I'm fine with granular options, even though it will be quite some work to make packages not use anymore.
Oh, so this problem is due to licensing, not wanting to use non-free software? I didn't pick up on that earlier. How about adding a disableJava option, that has priority over enableStandardFeatures? Hm, this feels like a local solution to a global problem.
is a good idea! What do you think should be the default?
If enableStandardFeatures is true, you should get java. Setting disableJava then enables standard features except those requiring java. I'm not sure if doing this (per package) is a good idea though. Isn't this the start of a new whack-a-mole game?
Yes, it's certainly not a perfect solution, but I can then use an overlay which sets for . Alternatively, we could enable Java for x86 only by default.
Perhaps it would be less confusing to have so the additive condition is positive.


Question: ec2-config = (handleTestOn ["x86_64-linux"] ./ec2.nix {}).boot-ec2-config or {}; ec2-nixops = (handleTestOn ["x86_64-linux"] ./ec2.nix {}).boot-ec2-nixops or {}; ecryptfs = handleTest ./ecryptfs.nix {}; <ins> fscrypt = handleTest ./fscrypt.nix {}; </ins> ejabberd = handleTest ./xmpp/ejabberd.nix {}; elk = handleTestOn ["x86_64-linux"] ./elk.nix {}; emacs-daemon = handleTest ./emacs-daemon.nix {};

I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. →


Question: ]; </programlisting> </para> <para> <del> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </del> <ins> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </ins> <programlisting> self: super: { postgresql_custom = self.postgresql_11.withPackages (ps: [

to newer version to different directory as under postgresql user Output I get:
The NixOS service module for PostgreSQL, for some unfathomable reason, initializes new databases using a non-standard superuser role name ( instead of ). This makes it a nightmare to get to work right, so forget that. Instead: back to your old version of postgresql root, dump your entire database to a file somewhere: to the new version of postgresql root, read in the database dump: (you'll likely see an error go by about the role already existing, you can ignore this) For good measure I went and tested this upgrading a 9.2 database to 9.4 under NixOS, worked fine, the applications using it continued on as normal after the import. That said, the real issue here is: why are we initializing databases using a non-standard install / superuser role name?
cc
See regarding the superuser role name.
Shouldn't we switch the default user to "postgres" on new databases and keep the "root" account around for existing-ones ? See
I strongly agree we should switch the default superuser to . Currently, it seems impossible to use to upgrade postgresql databases due to NixOS using the superuser: simply refuses to run as root.
The approach given by above doesn't work for me:
I can submit the change as a PR but don't use postgresql and it needs testing. Feel free to steal it and do the upgrade process with it.
pgdumpall tends to e pretty useless if you database isn't tiny_ :(
that would be a good start :)
there you go :)
FYI: I've just tested migrating 9.2 to 9.6 using and it works flawlessly.
Ok, I think I found out why wasn't working for me, like I mentioned in It seems to be due to this line in the Hydra module: If I change the mapping to then the command works fine. But I'm not exactly sure what are the implications of doing this, or why was mapped to in the first place...
In case someone runs into the same issue as me, I am documenting the procedure I used to upgrade a PostgreSQL database that was being used (only) for Hydra.


Question: ]; </programlisting> </para> <para> <del> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </del> <ins> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </ins> <programlisting> self: super: { postgresql_custom = self.postgresql_11.withPackages (ps: [

I tried to follow procedure above, but as I mentioned before, to use as suggested I needed to change the PostgreSQL user mapping in the Hydra module as specified in my comment just above this one, otherwise I would get a message. However, to read the database dump back into the new PostgreSQL installation I had to change the user mapping as follows: ... and then, after activating the configuration, I needed to run the command in the following way (as root): After doing this, the upgrade from PostgreSQL 9.4 to 9.6 seems to have completed successfully.
Related
If anyone else stumbles on this, pgupgrade seems to work now. I realized after upgrade that my db got reinitialized, so steps for me were much more brutish than that post, but in a nutshell: with new postgresql running, clear whatever got reinitialized (pgupgrade won't run if there are data around, but won't tell you what to remove... lists databases, don't know how to list users, I guessed) drop database whatever; drop user whatever; stop postgresql.service figure path for old binaries, e.g. and copy it somewhere. run the actual pgupgrade as user: restart the postgresql service if all went well after some testing pgupgrade suggests removing the old db with (disclaimer: Don't blame me if that eats your data)


Question: ++ optional langFortran ../gfortran-driving.patch ++ optional (targetPlatform.libc == "musl" && targetPlatform.isPower) ../ppc-musl.patch ++ optional (targetPlatform.libc == "musl") ../libgomp-dont-force-initial-exec.patch <del> ++ optional (!crossStageStatic && targetPlatform.isMinGW) (fetchpatch { url = "https://raw.githubusercontent.com/lhmouse/MINGW-packages/${import ../common/mfcgthreads-patches-repo.nix}/mingw-w64-gcc-git/9000-gcc-${majorVersion}-branch-Added-mcf-thread-model-support-from-mcfgthread.patch"; sha256 = "1in5kvcknlpi9z1vvjw6jfmwy8k12zvbqlqfnq84qpm99r0rh00a"; }); </del> <ins> # Obtain latest patch with ../update-mcfgthread-patches.sh ++ optional (!crossStageStatic && targetPlatform.isMinGW) ./Added-mcf-thread-model-support-from-mcfgthread.patch; </ins> /* Cross-gcc settings (build == host != target) */ crossMingw = targetPlatform != hostPlatform && targetPlatform.libc == "msvcrt";

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


Question: <del> diff --git a/llm/llama.go b/llm/llama.go index f23d5d8..6563550 100644 --- a/llm/llama.go +++ b/llm/llama.go @@ -25,7 +25,6 @@ import ( "github.com/jmorganca/ollama/api" ) -//go:embed llama.cpp/*/build/*/bin/* var llamaCppEmbed embed.FS type ModelRunner struct { @@ -33,6 +32,10 @@ type ModelRunner struct { } func chooseRunners(workDir, runnerType string) []ModelRunner { +	return []ModelRunner{ +		{Path: "@llamaCppServer@"}, +	} + buildPath := path.Join("llama.cpp", runnerType, "build") var runners []string </del>

Package name: ollama Latest released version: 0.1.20 <!-- Search your package here: --- Current version on the unstable channel: 0.1.17 Current version on the stable/release channel: 0.1.7 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
20 was released.[^1] :tada: Had a quick look into the source changes. Seems that patching is required because of the integration of ROCm. [^1]:
I modified the title :-)
21 is going to be released very soon.
I opened
update: 0.1.22 is the latest version.
Seems update can be problematic. I've tried manually download and executing new ollama and encountered a lot of issues connected with ROCM libraries. After adding I've got it to state where it crushes: But before adding it seems also miss new version of because it was asking for but current unstable version have CPU works fine without mentioned ROCM packages.
This appears to have been resolved by . Reopen if it's not.


Question: pkg-config wayland xwayland <del> zig_0_12.hook </del> <ins> zig_0_13.hook </ins> ] ++ lib.optional withManpages scdoc;

Package name: river Latest released version: 0.3.3 <!-- Search your package here: --- Current version on the unstable channel: 0.3.2 Current version on the stable/release channel: 0.3.2 <!-- 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]:
3 is only a zig 0.13 compatibility release. It’s blocked by
has been merged, this is not blocked anymore.


Question: , stdenv , buildPythonPackage , fetchPypi <del> , fetchpatch </del> , substituteAll , pythonOlder , geos

Add any other context about the problem here. Please run and paste the result. repro'd on commit id
backtrace: <details<summaryBacktrace from lldb</summary</details
shapely 1.8.4 with the fix is now in pypi, I saw you wanted to upgrade it, did you get around to do it?
thanks for the reminder, committed it


Question: paths = cuda-common-redist; }; in <del> stdenv.mkDerivation (finalAttrs: { name = "tiny-cuda-nn"; version = "1.6"; format = strings.optionalString pythonSupport "setuptools"; src = fetchFromGitHub { owner = "NVlabs"; repo = finalAttrs.name; rev = "v${finalAttrs.version}"; fetchSubmodules = true; hash = "sha256-qW6Fk2GB71fvZSsfu+mykabSxEKvaikZ/pQQZUycOy0="; }; nativeBuildInputs = [ cmake cuda-native-redist ninja which ] ++ lists.optionals pythonSupport (with python3Packages; [ pip setuptools wheel ]); buildInputs = [ cuda-redist ] ++ lib.optionals pythonSupport ( with python3Packages; [ pybind11 python ] ); propagatedBuildInputs = lib.optionals pythonSupport ( with python3Packages; [ torch ] ); # NOTE: We cannot use pythonImportsCheck for this module because it uses torch to immediately #   initailize CUDA and GPU access is not allowed in the nix build environment. # NOTE: There are no tests for the C++ library or the python bindings, so we just skip the check #   phase -- we're not missing anything. doCheck = false; preConfigure = '' export TCNN_CUDA_ARCHITECTURES=${ strings.concatStringsSep ";" (lists.map cudaFlags.dropDot cudaFlags.cudaCapabilities) } export CUDA_HOME=${cuda-native-redist} export LIBRARY_PATH=${cuda-native-redist}/lib/stubs:$LIBRARY_PATH export CC=${backendStdenv.cc}/bin/cc export CXX=${backendStdenv.cc}/bin/c++ ''; # When building the python bindings, we cannot re-use the artifacts from the C++ build so we # skip the CMake confurePhase and the buildPhase. dontUseCmakeConfigure = pythonSupport; # The configurePhase usually puts you in the build directory, so for the python bindings we # need to change directories to the source directory. configurePhase = strings.optionalString pythonSupport '' runHook preConfigure mkdir -p $NIX_BUILD_TOP/build cd $NIX_BUILD_TOP/build runHook postConfigure ''; buildPhase = strings.optionalString pythonSupport '' runHook preBuild python -m pip wheel  --no-build-isolation  --no-clean  --no-deps  --no-index  --verbose  --wheel-dir $NIX_BUILD_TOP/build  $NIX_BUILD_TOP/source/bindings/torch runHook postBuild ''; installPhase = '' runHook preInstall mkdir -p $out/lib '' # Installing the C++ library just requires copying the static library to the output directory + strings.optionalString (!pythonSupport) '' cp libtiny-cuda-nn.a $out/lib/ '' # Installing the python bindings requires building the wheel and installing it + strings.optionalString pythonSupport '' python -m pip install  --no-build-isolation  --no-cache-dir  --no-deps  --no-index  --no-warn-script-location  --prefix="$out"  --verbose  ./*.whl '' + '' runHook postInstall ''; passthru = { inherit cudaPackages; }; meta = with lib; { description = "Lightning fast C++/CUDA neural network framework"; homepage = "https://github.com/NVlabs/tiny-cuda-nn"; license = licenses.bsd3; maintainers = with maintainers; [ connorbaker ]; platforms = platforms.linux; }; }) </del> <ins> stdenv.mkDerivation (finalAttrs: { pname = "tiny-cuda-nn"; version = "1.6"; strictDeps = true; format = strings.optionalString pythonSupport "setuptools"; src = fetchFromGitHub { owner = "NVlabs"; repo = finalAttrs.pname; rev = "v${finalAttrs.version}"; fetchSubmodules = true; hash = "sha256-qW6Fk2GB71fvZSsfu+mykabSxEKvaikZ/pQQZUycOy0="; }; nativeBuildInputs = [ cmake cuda-native-redist ninja which ] ++ lists.optionals pythonSupport (with python3Packages; [ pip setuptools wheel ]); buildInputs = [ cuda-redist ] ++ lib.optionals pythonSupport ( with python3Packages; [ pybind11 python ] ); propagatedBuildInputs = lib.optionals pythonSupport ( with python3Packages; [ torch ] ); # NOTE: We cannot use pythonImportsCheck for this module because it uses torch to immediately #   initailize CUDA and GPU access is not allowed in the nix build environment. # NOTE: There are no tests for the C++ library or the python bindings, so we just skip the check #   phase -- we're not missing anything. doCheck = false; preConfigure = '' export TCNN_CUDA_ARCHITECTURES="${ strings.concatStringsSep ";" (lists.map cudaFlags.dropDot cudaFlags.cudaCapabilities) }" export CUDA_HOME="${cuda-native-redist}" export LIBRARY_PATH="${cuda-native-redist}/lib/stubs:$LIBRARY_PATH" export CC="${backendStdenv.cc}/bin/cc" export CXX="${backendStdenv.cc}/bin/c++" ''; # When building the python bindings, we cannot re-use the artifacts from the C++ build so we # skip the CMake confurePhase and the buildPhase. dontUseCmakeConfigure = pythonSupport; # The configurePhase usually puts you in the build directory, so for the python bindings we # need to change directories to the source directory. configurePhase = strings.optionalString pythonSupport '' runHook preConfigure mkdir -p "$NIX_BUILD_TOP/build" cd "$NIX_BUILD_TOP/build" runHook postConfigure ''; buildPhase = strings.optionalString pythonSupport '' runHook preBuild python -m pip wheel  --no-build-isolation  --no-clean  --no-deps  --no-index  --verbose  --wheel-dir "$NIX_BUILD_TOP/build"  "$NIX_BUILD_TOP/source/bindings/torch" runHook postBuild ''; installPhase = '' runHook preInstall mkdir -p "$out/lib" '' # Installing the C++ library just requires copying the static library to the output directory + strings.optionalString (!pythonSupport) '' cp libtiny-cuda-nn.a "$out/lib/" '' # Installing the python bindings requires building the wheel and installing it + strings.optionalString pythonSupport '' python -m pip install  --no-build-isolation  --no-cache-dir  --no-deps  --no-index  --no-warn-script-location  --prefix="$out"  --verbose  ./*.whl '' + '' runHook postInstall ''; passthru = { inherit cudaPackages; }; meta = with lib; { description = "Lightning fast C++/CUDA neural network framework"; homepage = "https://github.com/NVlabs/tiny-cuda-nn"; license = licenses.bsd3; maintainers = with maintainers; [connorbaker]; platforms = platforms.linux; }; }) </ins>

Originally spotted by (thank you!). Steps to reproduce the behavior (assuming and are both ): The environment variable contains semicolons and must be quoted, otherwise bash will interpret the semicolons as command separators.
- Hey, I am not sure how to clean up the mess I just made on . Really embarrassed. I intended to rebase and hit merge instead, which pulled in 10k changes.
No worries, Happens to everyone at some point :) Personally, I'd just open a new PR.
Here it is: . Does the commit history look clean enough? I'll try to rebase it later, but I am concerned about retagging all of those folks.
I'd say don't worry about it -- as far as best practice goes, I'm actually not sure what's recommended for commits. do we recommend squashing before merge? I know I typically just do force pushes to avoid any commit history :l
I went ahead and squashed, and I'll post a nixpkgs-review when it's finished.
I don't think we have an official stance on this. Contributors use their best judgement for whatever keeps the commit history simplest and easiest to use


Question: <ins> { lib, stdenvNoCC, fetchFromGitHub, glib, # These loosen security a bit, so we don't install them by default. See also: # https://github.com/hardpixel/systemd-manager?tab=readme-ov-file#without-password-prompt allowPolkitPolicy ? "none", config, systemd ? config.systemd.package, }: assert lib.elem allowPolkitPolicy [ "none" "pkexec" "systemctl" ]; stdenvNoCC.mkDerivation rec { pname = "gnome-shell-extension-systemd-manager"; version = "16"; # Upstream doesn't post new versions in extensions.gnome.org anymore, see also: # https://github.com/hardpixel/systemd-manager/issues/19 src = fetchFromGitHub { owner = "hardpixel"; repo = "systemd-manager"; rev = "v${version}"; hash = "sha256-JecSIRj582jJWdrCQYBWFRkIhosxRhD3BxSAy8/0nVw="; }; nativeBuildInputs = [ glib ]; postInstall = '' rm systemd-manager@hardpixel.eu/schemas/gschemas.compiled glib-compile-schemas systemd-manager@hardpixel.eu/schemas mkdir -p $out/share/gnome-shell/extensions mv systemd-manager@hardpixel.eu $out/share/gnome-shell/extensions '' + lib.optionalString (allowPolkitPolicy == "pkexec") '' local bn=org.freedesktop.policykit.pkexec.systemctl.policy mkdir -p $out/share/polkit-1/actions substitute systemd-policies/$bn $out/share/polkit-1/actions/$bn  --replace-fail /usr/bin/systemctl ${lib.getBin systemd}/bin/systemctl '' + lib.optionalString (allowPolkitPolicy == "systemctl") '' install -Dm0644  systemd-policies/10-service_status.rules  $out/share/polkit-1/rules.d/10-gnome-extension-systemd-manager.rules ''; passthru = { extensionUuid = "systemd-manager@hardpixel.eu"; extensionPortalSlug = "systemd-manager"; }; meta = with lib; { description = "GNOME Shell extension to manage systemd services"; homepage = "https://github.com/hardpixel/systemd-manager"; license = licenses.gpl3Only; maintainers = with maintainers; [ linsui doronbehar ]; }; } </ins>

After reboot, while systemd units are still loading, if user clicks on Systemd-Manger extension the entire DE will crash and Gnome will force a log out of that user. Moreover, Systemd-Manager is at v14 when v15 is out from the developer. Steps to reproduce the behavior: Computer DE loads and user is logged in on Systemd-Manager (while the systemd units [custom systemd units by the user into the extension] are still loading for example "bitcoind") crashes and forces log out No crashing of DE and you should be able to see in Systemd-Manager the units that have not started without it crashing Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Any news on this? Thanks so much!
Any news on this Thanks so much!
Update should be contained in
sweet!!! Thanks, I will keep an eye on it. Thanks again!
I checked and plus the superseding still contain version 14. The author notes on the that they will no longer be publishing to that site, and indeed the latest version available for download there is still 14. So the metadata for that extension may need to be manually overridden in nixpkgs since it is not going to get the latest from via the automated update process.
This works as a standalone package, for inclusion in you'd probably be fine not declaring ,,. Would be happy to make a PR for it, though it's not something I'd actively mantain/use myself. Just updating the metadata itself wont do, as it would still be pulling from for nonexistent files.
Looks good! That updated package does fix the crash for me.
did you just install the package from nixos?
yes, it seems then having its own package would be the best no?
Ah no, it would need a PR to even get into nixpkgs. I just it to my local config using an overlay.
okay, well I will look into how to overly in a nix file. Also, it is hard to maintain a package? As, maybe I could learn how to maintain this extension if will be unable to maintain it?


Question: <ins> { lib, stdenvNoCC, fetchFromGitHub, glib, # These loosen security a bit, so we don't install them by default. See also: # https://github.com/hardpixel/systemd-manager?tab=readme-ov-file#without-password-prompt allowPolkitPolicy ? "none", config, systemd ? config.systemd.package, }: assert lib.elem allowPolkitPolicy [ "none" "pkexec" "systemctl" ]; stdenvNoCC.mkDerivation rec { pname = "gnome-shell-extension-systemd-manager"; version = "16"; # Upstream doesn't post new versions in extensions.gnome.org anymore, see also: # https://github.com/hardpixel/systemd-manager/issues/19 src = fetchFromGitHub { owner = "hardpixel"; repo = "systemd-manager"; rev = "v${version}"; hash = "sha256-JecSIRj582jJWdrCQYBWFRkIhosxRhD3BxSAy8/0nVw="; }; nativeBuildInputs = [ glib ]; postInstall = '' rm systemd-manager@hardpixel.eu/schemas/gschemas.compiled glib-compile-schemas systemd-manager@hardpixel.eu/schemas mkdir -p $out/share/gnome-shell/extensions mv systemd-manager@hardpixel.eu $out/share/gnome-shell/extensions '' + lib.optionalString (allowPolkitPolicy == "pkexec") '' local bn=org.freedesktop.policykit.pkexec.systemctl.policy mkdir -p $out/share/polkit-1/actions substitute systemd-policies/$bn $out/share/polkit-1/actions/$bn  --replace-fail /usr/bin/systemctl ${lib.getBin systemd}/bin/systemctl '' + lib.optionalString (allowPolkitPolicy == "systemctl") '' install -Dm0644  systemd-policies/10-service_status.rules  $out/share/polkit-1/rules.d/10-gnome-extension-systemd-manager.rules ''; passthru = { extensionUuid = "systemd-manager@hardpixel.eu"; extensionPortalSlug = "systemd-manager"; }; meta = with lib; { description = "GNOME Shell extension to manage systemd services"; homepage = "https://github.com/hardpixel/systemd-manager"; license = licenses.gpl3Only; maintainers = with maintainers; [ linsui doronbehar ]; }; } </ins>

Maintaining an extension like this should be as simple as increasing the version number when a new release exists, given it's lack of external dependencies or nixos-specific quirks that need to be patched (there may be some out there). What I meant by not mantaining it is that I do not actively use it within my setup. And I assume these manually packaged ones would need at least a "reference" mantainer to keep it in check and direct issues to.
Thanks for the good info ! Well, I can be the maintainer, but I might need help from time to time. I will use your code if that is okay? So, next steps to put in the PR and then add me as the maintainer. Also, would you want to be on this as well?
piegamesde was only the maintainer of the original extension package because they're the . Manually packaged extensions go in and generally have a maintainer attribute set.
Circling back to this... I would like to be the maintainer of this plugin. However, I have never maintained a piece of software on github and I only have minimal skills with shell and nix configuration files. I have never made or packaged a nix module before. Should this task be reserved for someone else with more skills or is there someone who could mentor me in how to be a maintainer? Thank you all for the help in this.
Added this to extension creator's github :
Okay, I figured out how to add 's code into my existing setup. For all the noobs out there this is what I did it: I did NOT use the "overlay" process in NixOS as describe here: I used the process as described here: This is an excellent write up BTW! Save this link for future use. With these resources in mind, this is what I did. I used 's code and named the file . This naming is arbitrary. It can be anything you want as long it has at the end. Then, move that file into directory. Do this via terminal and you must be the user. Then in my NixOS (not nix) configuration file () I simply into the Then, like always, as root This is all explained in the link above. Limitations: hack does not put the new is in the official repository.