jiebi/CodeConvo huggingface dataset:
Code change:
''} ''; <del> postFixup = '' </del> <ins> postFixup = let archMap = { "x86_64-linux" = "x86_64"; "i686-linux" = "x86"; }; layerPlatform = archMap."${stdenv.hostPlatform.system}" or null; # We need to give the different layers separate names or else the loader # might try the 32-bit one first, fail and not attempt to load the 64-bit # layer under the same name. in lib.optionalString (layerPlatform != null) '' substituteInPlace $out/share/vulkan/implicit_layer.d/MangoHud.${layerPlatform}.json  --replace "VK_LAYER_MANGOHUD_overlay" "VK_LAYER_MANGOHUD_overlay_${toString stdenv.hostPlatform.parsed.cpu.bits}" '' + '' </ins> # Add OpenGL driver path to RUNPATH to support NVIDIA cards addOpenGLRunpath "$out/lib/mangohud/libMangoHud.so" <del> ${lib.optionalString gamescopeSupport '' addOpenGLRunpath "$out/bin/mangoapp" ''} ${lib.optionalString finalAttrs.doCheck '' # libcmocka.so is only used for tests rm "$out/lib/libcmocka.so" ''} </del> <ins> '' + lib.optionalString gamescopeSupport '' addOpenGLRunpath "$out/bin/mangoapp" '' + lib.optionalString finalAttrs.doCheck '' # libcmocka.so is only used for tests rm "$out/lib/libcmocka.so" </ins> ''; passthru.updateScript = nix-update-script { };

Related discussion:
text: Mangohud no longer appears on gnome/wayland when opening a game. "rev": "", (works) "rev": "", (doesn't) Steps to reproduce the behavior: a game on gnome/wayland doesn't appear even when enabled (worked in previous revision of nixpkgs above) ... Mangohud shows system stats Please run and paste the result.
I have the same problem too. I'm using Hyprland btw.
Oh weird. I'll try looking into this. The only thing that really sticks out to me in the diff is possibly ? - but it seems unlikely. I'll do a git bisect to try to narrow it down better.
If it helps you narrow down, here's my repo with the exact commit where mangohud stopped working. If I revert back to previous commit mangohud starts working again:
I bisected it, it's cc
mangohud uses its own internal copy of vulkan-headers: So it's probably the loader? If it is though, it might be tricky to bisect...
So, what are we going to do? Especially w.r.t. 23.05 being around the door. I don't think we should ship a broken mangohud in 23.05. Honestly, I think should have probably not made it to master before branch-off. (Eventhough it was technically merged a few dasy before breaking changes were restricted.)
I'll try to reproduce locally and see if I can bisect vulkan-loader.
cc because of
We could also try updating the headers externally; Mangohud's are really quite old. They use this weird meson wrap thingy rather than letting the distro provide it and it too is very out of date. Also, this is the error we're getting: (This is on 64-bit-only Mangohud.)
It breaks when built with newer headers.
Oh sorry, forgot to get back to this! Maybe we need to switch back to using the system headers?
I'm actually pretty sure it's which we probably don't want to revert, but we may need to look into layer ordering?
oh no - yeah i think you're right, i think the duplicate behaviour was specifically to support multi-arch layers (from what I remember).
Code change:
''} ''; <del> postFixup = '' </del> <ins> postFixup = let archMap = { "x86_64-linux" = "x86_64"; "i686-linux" = "x86"; }; layerPlatform = archMap."${stdenv.hostPlatform.system}" or null; # We need to give the different layers separate names or else the loader # might try the 32-bit one first, fail and not attempt to load the 64-bit # layer under the same name. in lib.optionalString (layerPlatform != null) '' substituteInPlace $out/share/vulkan/implicit_layer.d/MangoHud.${layerPlatform}.json  --replace "VK_LAYER_MANGOHUD_overlay" "VK_LAYER_MANGOHUD_overlay_${toString stdenv.hostPlatform.parsed.cpu.bits}" '' + '' </ins> # Add OpenGL driver path to RUNPATH to support NVIDIA cards addOpenGLRunpath "$out/lib/mangohud/libMangoHud.so" <del> ${lib.optionalString gamescopeSupport '' addOpenGLRunpath "$out/bin/mangoapp" ''} ${lib.optionalString finalAttrs.doCheck '' # libcmocka.so is only used for tests rm "$out/lib/libcmocka.so" ''} </del> <ins> '' + lib.optionalString gamescopeSupport '' addOpenGLRunpath "$out/bin/mangoapp" '' + lib.optionalString finalAttrs.doCheck '' # libcmocka.so is only used for tests rm "$out/lib/libcmocka.so" </ins> ''; passthru.updateScript = nix-update-script { };

Related discussion:
text: If it's just an issue of duplicate layers, perhaps we could add 32 and 64 suffixes to the layer names. obs-vkcapture does that too.
I gave up o pursuing this, as seen in It works, but for this case here, it's probably better to bring attention upstream. Cc
Having only the 64-bit mangohud json in the implicit layer dir works! Going to try giving the 32-bit layer a different name now.
This is also going to affect vkbasalt too then - I haven't tried yet though - I'll take a look at fixing that too!
Speaking of, any reason you gave up on that? I personally really liked the good idea.
Different suffixes work! PR incoming.
It needed a proper rebase+bump to v1.3.250, and I couldn't figure out how to really take a good benefit from it.
Hm, I'll definitely try to pick it up after branch-off then.
Peculiarly, obs-vkcapture seem to do this for some time already: from gamescope might need this fix too.
Code change:
qmediathekview = libsForQt5.callPackage ../applications/video/qmediathekview { }; <del> qmplay2 = libsForQt5.callPackage ../applications/video/qmplay2 { }; </del> <ins> qmplay2-qt5 = qmplay2.override { qtVersion = "5"; }; qmplay2-qt6 = qmplay2.override { qtVersion = "6"; }; </ins> qmidiarp = callPackage ../applications/audio/qmidiarp { };

Related discussion:
text: Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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.
Code change:
wrapProgram "$out/bin/${projectName}"  --prefix PATH : "''${defaultPathInputs// //bin:}''${defaultPathInputs:+/bin:}" # Make changes in the config file <del> ${lib.optionalString enableNvidiaContainerCli '' </del> <ins> ${lib.optionalString forceNvcCli '' </ins> substituteInPlace "$out/etc/${projectName}/${projectName}.conf"  --replace "use nvidia-container-cli = no" "use nvidia-container-cli = yes" ''}

Related discussion:
text: 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.
Code change:
wrapProgram "$out/bin/${projectName}"  --prefix PATH : "''${defaultPathInputs// //bin:}''${defaultPathInputs:+/bin:}" # Make changes in the config file <del> ${lib.optionalString enableNvidiaContainerCli '' </del> <ins> ${lib.optionalString forceNvcCli '' </ins> substituteInPlace "$out/etc/${projectName}/${projectName}.conf"  --replace "use nvidia-container-cli = no" "use nvidia-container-cli = yes" ''}

Related discussion:
text: 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.
Code change:
wrapProgram "$out/bin/${projectName}"  --prefix PATH : "''${defaultPathInputs// //bin:}''${defaultPathInputs:+/bin:}" # Make changes in the config file <del> ${lib.optionalString enableNvidiaContainerCli '' </del> <ins> ${lib.optionalString forceNvcCli '' </ins> substituteInPlace "$out/etc/${projectName}/${projectName}.conf"  --replace "use nvidia-container-cli = no" "use nvidia-container-cli = yes" ''}

Related discussion:
text: 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
Code change:
config = mkIf cfg.enable { programs.singularity.packageOverriden = (cfg.package.override ( <del> optionalAttrs cfg.enableFakeroot { </del> <ins> optionalAttrs cfg.enableExternalLocalStateDir { externalLocalStateDir = "/var/lib"; } // optionalAttrs cfg.enableFakeroot { </ins> newuidmapPath = "/run/wrappers/bin/newuidmap"; newgidmapPath = "/run/wrappers/bin/newgidmap"; } // optionalAttrs cfg.enableSuid {

Related discussion:
text: The derivation is missing the directory to work properly. Steps to reproduce the behavior: A clear and concise description of what you expected to happen. is output without error. This can be fixed by creating the directory manually (). I guess this could be to the derivation. <!-- 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.
NixOS module provides those top-level directories. discussed with one of the main Apptainer developer in . He think it should be easy to specify a directory that will always exist at build time. Regalding this, I'm considering the possibility to put those dilectories under the derivation store path. Not sure if there would be potential problem using a store path as a mount point, but it seems to work without problem.
Could you help me take a look at ?
If you have time, please help me test the PR . It should fundamentally solve this issue. If applied, you no longer need the NixOS module or just to run images. It specifies the LOCALSTATEDIR as , making both Apptainer and Sylabs SingularityCE works without . (The image running still depends on and to run images, which might be the final obstacle to build images as a package without invoking a virtual machine. Other than that, it should not be an issue for most users, as are available on most of the UNIX/UNIX-like systems.)
I removed (the temporary fix for this issue) and ran the following and it seems to work fine: Thank you for this fix!
Glad to hear that! Would you mind ? I've heard that committers tend to merge PRs getting two approvals.
Done!
Code change:
<ins> Remove about:buildconfig.  If used as-is, it would add unnecessary runtime dependencies. --- a/comm/mail/base/jar.mn +++ b/comm/mail/base/jar.mn @@ -119,9 +119,6 @@ messenger.jar: % override chrome://mozapps/content/profile/profileDowngrade.js chrome://messenger/content/profileDowngrade.js % override chrome://mozapps/content/profile/profileDowngrade.xhtml chrome://messenger/content/profileDowngrade.xhtml -*   content/messenger/buildconfig.html              (content/buildconfig.html) -% override chrome://global/content/buildconfig.html chrome://messenger/content/buildconfig.html - # L10n resources and overrides. % override chrome://mozapps/locale/profile/profileDowngrade.dtd chrome://messenger/locale/profileDowngrade.dtd % override chrome://global/locale/netError.dtd chrome://messenger/locale/netError.dtd </ins>

Related discussion:
text: It got a huge closure size. Jump happened here: 91.1.0: 0.5 G 91.1.1: 3+ G On a quick glance, it's mainly due to dragging lots of toolchain packages, rustc in particular: /cc other likely interested people:
and don't suffer from this, by the way.
This may be relating to ().
Code change:
ledfx = callPackage ../applications/audio/ledfx { }; <del> libdislocator = callPackage ../tools/security/afl/libdislocator.nix { }; </del> <ins> libdislocator = callPackage ../tools/security/aflplusplus/libdislocator.nix { }; </ins> afpfs-ng = callPackage ../tools/filesystems/afpfs-ng { };

Related discussion:
text: Steps to reproduce the behavior: afl <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If you are planing to open a PR, you don't need to create an issue first.
I wasn't sure, thanks for clarification
Code change:
version = "1.3.0"; format = "setuptools"; <del> src = fetchPypi  { </del> <ins> src = fetchPypi { </ins> pname = "face_recognition"; inherit version; hash = "sha256-Xl790WhqpWavDTzBMTsTHksZdleo/9A2aebT+tknBew=";

Related discussion:
text: When you set , although it sets the CMAKE flag correctly the resulting package isn't actually built correctly as cmake can't find cuda so it unsets the flag. This is due to the incorrect usage of instead of when building the cuda related packages. The correct usage can be seen in the package. It also tries to build with CUDA by default which is wrong. Dlib hasn't supported fftw since however there are leftover references to it in cmake which might lead people to think it does support fftw. fftw should be removed. As mentioned in this it makes more sense to have as an input into rather that so that people can override it with other BLAS implementations e.g more easily if they want to. The package was also missing lapack which should be . Steps to reproduce the behavior: Build the package, it tries to build with CUDA by default. I made an example with a fairly simple nix flake that let's you switch between my patch and the original package. I have created a which fixes these issues. For it to build with CUDA. How CMAKE fails ! For this simple c switching from my fix to the original bugged package on 23.11 before openblas was . ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Thanks!
Code change:
let # Release calendar: https://www.mesa3d.org/release-calendar.html # Release frequency: https://www.mesa3d.org/releasing.html#schedule <del> version = "21.3.3"; </del> <ins> version = "21.3.4"; </ins> branch  = versions.major version; self = stdenv.mkDerivation {

Related discussion:
text: Mesa 21.3.2 present in is causing , and they point to , not yet fixed as of now. Reverting to nixos-unstable to Mesa 21.2.6 updates fixes the issue. Steps to reproduce the behavior: sure you're using Intel GPU nixos channel to No flickering should happen on the application screen. Mesa bug report has a video demonstrating the issue. If applicable, add screenshots to help explain your problem. cc: Please run and paste the result.
According to the bug report this seems to affect at least Blender as well. Anyway, we can leave this issue open for a while (in case it helps users to figure this out) but I don't think there's anything actionable for Nixpkgs (it's an upstream bug and we simply have to wait until a fix is released via a new version). It looks like the patch from should be submitted formally via a PR so that it might get included in Mesa 21.3.4.
This is also happening on qutebrowser for me, but only on the wayland backend. I have a temporary fix to just launch with , but this obviously disables the hardware. Works fine though so far for just browsing and work stuff, at least until a proper fix is merged.
It's unlikely that the patch will be applied for 21.3.4 (as no one filed a MR for it so far), should we apply it downstream?
I'm seeing this in qutebrowser as well (non-wayland)
I'd prefer to avoid applying a patch that hasn't been reviewed upstream.
+1 for what said. Luckily a developer from Intel started looking into this so let's see how things will develop: Ideally a patch will be ready for 21.3.4 but the release might happen in two days (unless it gets delayed) so it'll indeed be close (but we'll of course re-evaluate our options once the release is out).
Unfortunately it was indeed too close for the patch to land in Mesa 21.3.4. However, now there's at least an alternative patch from Paulo Zanoni (the Intel developer) and Giuseppe Ghibò (author of the other patch) and others confirmed that it's working: I've included that patch in Does someone have time to test it () and report if it indeed fixes the issues?
Code change:
let # Release calendar: https://www.mesa3d.org/release-calendar.html # Release frequency: https://www.mesa3d.org/releasing.html#schedule <del> version = "21.3.3"; </del> <ins> version = "21.3.4"; </ins> branch  = versions.major version; self = stdenv.mkDerivation {

Related discussion:
text: Thanks a lot for putting together a fix! I'm happy to test. Could you confirm I understood the instructions correctly? 1) integrate the code from the above PR into my nixpkgs tree. 2) put the following into my nixos config: 3) replace with the path to my nixpkgs tree. 4) run Did I get that right?
It's the easiest if you use a separate/dedicated Nixpkgs tree for Mesa ( in the example). That way you don't have to rebuild a lot of other packages (which would most likely still take way too long). You can also cherry-pick the commit to (I'd recommend doing that) which saves additional rebuilds (I only tested it that way so no idea how many many builds are currently cached for staging-next). The rest looks fine. And thanks in advance :)
It works like a charm. Thanks
Seems like this wasn't closed automatically once landed in master. Should be fixed now. And upstream merged the required patches in the meantime (s. note in ). And thanks for testing the fix and :)
Code change:
Group = data.group; PrivateTmp = true; StateDirectory = "acme/.lego ${lpath}"; <del> StateDirectoryMode = rights; </del> <ins> StateDirectoryMode = if data.allowKeysForGroup then "750" else "700"; </ins> WorkingDirectory = spath; # Only try loading the credentialsFile if the dns challenge is enabled EnvironmentFile = if data.dnsProvider != null then data.credentialsFile else null;

Related discussion:
text: Describe the bug If I change and enable when the cert/key in question already exists the group access will not be granted after rebuilding and restarting the . This is because a condition in the post start script does so only when the key is newer than the existing one. To Reproduce Steps to reproduce the behavior: without group/allowKeysForGroup and start the service to reques the certificate group and allowKeysForGroup again and restart the service, the ownership/ode will not be updated Expected behavior The group and chmod setting should be set on existing certificates as well as new ones. Metadata Please run and paste the result. Maintainer information:
Additionally, shouldn't chmod 0640 suffice on the files?
cc as potentially interested individuals