jiebi/CodeConvo huggingface dataset:
Code change:
(buildGoModule { inherit pname version src; <ins> patches = lib.optionals (projectName == "apptainer") [ (substituteAll { src = ./apptainer/0001-ldCache-patch-for-driverLink.patch; inherit (addDriverRunpath) driverLink; }) ]; </ins> # Override vendorHash with the output got from # nix-prefetch -E "{ sha256 }: ((import ./. { }).apptainer.override { vendorHash = sha256; }).goModules" # or with `null` when using vendored source tarball.

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:
(buildGoModule { inherit pname version src; <ins> patches = lib.optionals (projectName == "apptainer") [ (substituteAll { src = ./apptainer/0001-ldCache-patch-for-driverLink.patch; inherit (addDriverRunpath) driverLink; }) ]; </ins> # Override vendorHash with the output got from # nix-prefetch -E "{ sha256 }: ((import ./. { }).apptainer.override { vendorHash = sha256; }).goModules" # or with `null` when using vendored source tarball.

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:
(buildGoModule { inherit pname version src; <ins> patches = lib.optionals (projectName == "apptainer") [ (substituteAll { src = ./apptainer/0001-ldCache-patch-for-driverLink.patch; inherit (addDriverRunpath) driverLink; }) ]; </ins> # Override vendorHash with the output got from # nix-prefetch -E "{ sha256 }: ((import ./. { }).apptainer.override { vendorHash = sha256; }).goModules" # or with `null` when using vendored source tarball.

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:
<del> { mkDerivation, lib, stdenv, fetchurl, cmake, extra-cmake-modules </del> <ins> { mkDerivation, lib, stdenv, makeWrapper, fetchurl, cmake, extra-cmake-modules </ins> , karchive, kconfig, kwidgetsaddons, kcompletion, kcoreaddons , kguiaddons, ki18n, kitemmodels, kitemviews, kwindowsystem , kio, kcrash

Related discussion:
text: the python binding for krita are not build correctly. Please run and paste the results.
more details wouldn't hurt...
well I don't exactly know what is happening here, to build the python binding, it requires and . So when are to the buildInputs, cmake finds all the dependencies correctly; however, at around 98% the compilation fails due to not finding some sip bindings. Alternatively, if is to the buildInputs, everything works fine as intended. But the python interpreter overwrite the python interpreter in the nix-env, so that doesn't seem to be the right fix.
also tried setting the variable, but that didn't work either.
cc who worked on / in
Code change:
https://git.sr.ht/~whynothugo/lsp_lines.nvim hura/vim-asymptote iamcco/coc-spell-checker <ins> iamcco/coc-tailwindcss </ins> iamcco/markdown-preview.nvim ianks/vim-tsx idanarye/vim-merginal

Related discussion:
text: Project description Various vim plugins iamcco/coc-tailwindcss coc-extensions/coc-svelte evanleck/vim-svelte
Code change:
index e2d292e..b13c0db 100755 --- a/configure +++ b/configure <del> @@ -2880,6 +2880,7 @@ $MAKE </del> <ins> @@ -3874,6 +3874,7 @@ </ins> echo "building the hdf5 library..."; cd ../; <del> ## we add the '-w' flag to suppress all the warnings hdf5 prints </del> +sed -i 's#/bin/mv#mv#' configure <del> ./configure --with-pic --enable-shared=no --enable-cxx  --with-szlib  CXX="${CXX}" CXFLAGS="${CXXFLAGS} -w"  </del> <ins> ./configure --with-pic --enable-shared=no --enable-cxx --enable-hl  --with-szlib=${SZIP_HOME} --with-zlib=${ZLIB_HOME}  ${WITH_S3_VFD}  </ins>

Related discussion:
text: Describe the bug The rhdf5 library does not work on latest release. To Reproduce Expected behavior A shell with R and rhdf5. Additional context Instead I get: Notify maintainers Metadata Maintainer information:
"6.topic: rust" should be removed, this is an R package, not Rust.
This was fixed in
Code change:
maintainers = [ globin eqyiel ]; }; <del> nodes = { </del> <ins> nodes = rec { </ins> # The only thing the client needs to do is download a file. client = { ... }: { services.davfs2.enable = true;

Related discussion:
text: There is about the use of imagemagick in NextCloud due to . Admins may want to disable it unless they are certain that users won't upload untrusted files (which can easily happen by accident if folder sync is active). NextCloud is only passing certain file types to imagemagick but it is doing so based on the file extension. Therefore, an attacker can pass any file type to imagemagick. I have tested this with a PNM image (not supported by NextCloud) that I have renamed to . doesn't get a preview image but does, i.e. NextCloud thinks it is HEIF and passes it to ImageMagick, which processes it as PNM. There are several ways to disable imagick: in the NextCloud config. This will not only disable imagick but also previews for PNG and JPEG (which do not use imagick). in the NextCloud config. This may need manual adjustment after a NextCloud update. the extension for PHP. This also disables it for NextCloud plugins. Option 1 and 2 can already be used by an admin if the drawbacks are acceptable. However, I think 3 is the best option in most cases. has options that disable the other PHP extensions that used to be by default. I think we should do the same for imagick. If imagick is disabled, NextCloud will automatically disable the preview generators that need it. It will also show a warning about that (which is subject to debate in the issue linked above) and there may be some implications for the themes app (which I don't use). Therefore, I think we should keep imagick enabled by default and leave the decision to the admin. We could also add a suitable policy for ImageMagick and thereby disable any file formats or features that are considered insecure. I don't think I could write such a policy and be sure that it is secure (or even "secure enough"). In addition, we will have to keep it up-to-date with newer versions and CVEs. That is why I recommend that we only add a simple off switch. The above information is based on NextCloud 20. I will wait until and NextCloud 21 have landed in nixos-unstable (and on my server) and then test again and create a PR if there is any interest in having this upstream.
Code change:
maintainers = [ globin eqyiel ]; }; <del> nodes = { </del> <ins> nodes = rec { </ins> # The only thing the client needs to do is download a file. client = { ... }: { services.davfs2.enable = true;

Related discussion:
text: Ouch, decisions based purely on a file ext is a behavior that sounds pretty broken to me :/ Optiobally disabling imagemagick and adjusting the config accordingly sounds reasonable to me, so feel free to file a PR. You can ping me for a review or if you need assistance with modifying the module :)
It's ok for what they do with it. It won't do double duty as a mitigation but I guess that was never intended. Thanks. Any suggestions on a name for the new option? Simply ? Should I add any tests for that? The existing tests only test three different configurations so adding one just for imagick seems like overkill. It should be quite easy though. If we want to test that previews actually aren't generated... Well, that's a different story. We would have to automate the web interface, for that. I think the existing tests are only testing the service, CLI and WebDAV.
As imagemagick enabled will remain the default, I'd suggest . Yes, adding a fourth VM test just for imagemagick is indeed an overkill IMHO since those tend to be fairly expensive. I'd suggest to write a testcase in , other integrations such as are also tested there. Right that could be a non-trivial thing to solve. Maybe check if there's a REST API or a way to implement this with the CLI of . But I don't think it'd be worth spending too much time on this if there's no reasonable way to test :)
I think we still want to test the default option in so we will need a second configuration that disables imagick. We don't have to start that VM if we only want to check whether imagick is in its closure. As there isn't any test helper for that, we probably don't want to do that though ;-) see Unfortunately, qemu on ARM is too unreliable for the automatic tests because qemu crashes when started on one of the little cores (i.e. 4 out of 6 times). I have done some interactive testing of the above commit but not an automated run. I will have to find some system that is not ARM, not high-security, not already virtualized...
Qemu/KVM does work if a kernel build or stress-ng is hogging the big cores :) is ready for review.
Code change:
<command>nixos-rebuild switch</command>. </para> <del> <xi:include href="customizing-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/customizing-packages.section.xml" /> </ins> <del> <xi:include href="adding-custom-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/adding-custom-packages.section.xml" /> </ins> </section>

Related discussion:
text: This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.
Code change:
<command>nixos-rebuild switch</command>. </para> <del> <xi:include href="customizing-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/customizing-packages.section.xml" /> </ins> <del> <xi:include href="adding-custom-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/adding-custom-packages.section.xml" /> </ins> </section>

Related discussion:
text: This tracks the conversion of from Docbook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.
I opened a PR for and : PTAL, thanks in advance for reviewing :-)
Code change:
<ins> { pkgs, buildGoModule, fetchFromGitHub, lib, perl }: buildGoModule rec { pname = "XD"; version = "0.4.0"; src = fetchFromGitHub { owner = "majestrate"; repo = "XD"; rev = "v${version}"; sha256 = "sha256-fXENoqhR04TYS/kAJUqsqa0+j+KyzdsMlXIZ2GMPMhc="; }; vendorSha256 = "1wg3cym2rwrhjsqlgd38l8mdq5alccz808465117n3vyga9m35lq"; checkInputs = [ perl ]; postInstall = '' ln -s $out/bin/XD $out/bin/XD-CLI ''; meta = with lib; { description = "i2p bittorrent client"; homepage = "https://xd-torrent.github.io"; maintainers = with maintainers; [ nixbitcoin ]; license = licenses.mit; platforms = platforms.linux; }; } </ins>

Related discussion:
text: Project description homepage URL: https://xd- source URL: license: mit platforms: linux
I marked this as stale due to inactivity. &rarr;
Code change:
<del> From 44c2c979c4f2222567ce65f506cf47fb87482348 Mon Sep 17 00:00:00 2001 From: Pontus Stenetorp <pontus@stenetorp.se> Date: Thu, 8 Apr 2021 04:37:44 +0000 Subject: [PATCH 5/6] nix: Enable parallel unit tests for sandbox Disabled by default due to lack of networking in the Nix sandbox. This greatly speeds up the build process on a multi-core system. --- test/runtests.jl | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/test/runtests.jl b/test/runtests.jl index 2f9cd058bb..2f8c19fa32 100644 --- a/test/runtests.jl +++ b/test/runtests.jl @@ -83,8 +83,9 @@ prepend!(tests, linalg_tests) import LinearAlgebra cd(@__DIR__) do n = 1 -    if net_on -        n = min(Sys.CPU_THREADS, length(tests)) +    if net_on || haskey(ENV, "NIX_BUILD_CORES") +        x = haskey(ENV, "NIX_BUILD_CORES") ? parse(Int, ENV["NIX_BUILD_CORES"]) : Sys.CPU_THREADS +        n = min(x, Sys.CPU_THREADS, length(tests)) n > 1 && addprocs_with_testenv(n) LinearAlgebra.BLAS.set_num_threads(1) end -- 2.29.3 </del>

Related discussion:
text: <!-- 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: <!-- 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.
I started preparing the update in . Cc:
Code change:
dontDisableStatic = withStatic; <ins> # libusb-1.0.rc:11: fatal error: opening dependency file .deps/libusb-1.0.Tpo: No such file or directory dontAddDisableDepTrack = stdenv.hostPlatform.isWindows; </ins> configureFlags = lib.optional (!enableUdev) "--disable-udev" ++ lib.optional (withExamples) "--enable-examples-build";

Related discussion:
text: Steps to reproduce the behavior: So when I wanted to dig deeper, with I'm trying to recreate with a toolchain that's on hydra so I don't have to compile GCC for myself (twice!) Please run and paste the result. In particular, is pinned to:
Diff-ing the two files, I get: I suspect the problem comes from in the that isn't present in the . I wonder why so many differences are present though? I've confirmed this by adding to the derivation, but again why are the differences present? Even if they have been helpful to track this down
I suspect there were impurities in your environment but the difference is still weird. I don't know why would be there but not Adding to the mingw build in
Code change:
wrapQtAppsHook ]; <del> buildInputs = [ qtsvg ]; </del> <ins> buildInputs = [ qtbase qtwayland qtsvg ]; </ins> postInstall = lib.optionalString stdenv.isDarwin '' mkdir -p $out/Applications

Related discussion:
text: low priority qt6.qtdeclarative is a large package, so it should be excluded for non-GUI qt apps () currently, when i build a package with and empty buildInputs, it pulls qt6.qtwayland qt6.qtdeclarative qt6.qtshadertools the problem is wrapQtAppsHook and its deps and qtwayland pulls qtdeclarative the problem is fixed by removing from deps wrapQtAppsHook should use only the declared buildInputs disabling wrapQtAppsHook (dontWrapQtApps = true) is no option, as also CLI qt apps need the qt wrapper qtwayland is there, so that users dont need to add it to buildInputs assuming that all qt apps are GUI apps im in favor of making this consistent with cmake so that all GUI apps must add qtwayland to buildInputs CLI qt app: GUI qt app: since cc
I'm in favour of this change, but the proportion of qt cli app night be relatively small, and it's not immediately clear that qtwayland should be if the build log yields Qt6::Widgets is missing.
Actually we are abusing qtwayland as a shortcut to bringing in qtdeclarative, this should be fixed too.
we could patch the cmake message to "please add qtdeclarative to your propagatedBuildInputs" the alternative would be to add a flag, but thats more obscure than buildInputs
Adding the lines to nixpkgs manual is sufficient.
By the way, is not only needed to pull in , but it's required for all GUI apps so that they work seamlessly on X11 or Wayland.
Code change:
}; <del> config = with cfg; let secretsFile = ipsecSecrets cfg.secrets; in mkIf enable </del> <ins> config = with cfg; mkIf enable </ins> { # here we should use the default strongswan ipsec.secrets and # append to it (default one is empty so not a pb for now) <del> environment.etc."ipsec.secrets".source = secretsFile; </del> <ins> environment.etc."ipsec.secrets".text = ipsecSecrets cfg.secrets; </ins> systemd.services.strongswan = { description = "strongSwan IPSec Service";

Related discussion:
text: Fail to connect to a l2tp + ipsec VPN after putting in all information. This happens on both Latest Gnome ISO and after NixOS installation. Message received on Gnome Desktop: Connection Failed Activation of network connection failed Steps to reproduce the behavior: Live Gnome ISO. l2tp + ipsec (strongswan) details in NetworkManager. on VPN connection. There are several fixes listed in this issue I was able to fix the problem by creating the file AFTER creating the connection and failing to connect once. (I also created the file BEFORE creating the connection, but that did not fix the issue.) After successfully connecting, this was content of file include The following is the failure output from journalctl From ISO system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I was also having issues and tried the above suggested by and was able to connect only after a failed connection !
This seems to fix the bug May we have this to the default package?
Fix in