jiebi/CodeConvo huggingface dataset:
Code change:
dae = callPackage ../tools/networking/dae { }; <ins> darling = callPackage ../applications/emulators/darling { }; </ins> databricks-sql-cli = python3Packages.callPackage ../applications/misc/databricks-sql-cli { }; dhallDirectoryToNix = callPackage ../build-support/dhall/directory-to-nix.nix { };

Related discussion:
text: Darling is a compatibility layer for running macOS apps on Linux (think Wine for macOS). I think it would be interesting to work on with macOS support. They have reverse engineered some headers that Apple doesn't release publicly so having them in "libdarling" could be useful.
We already have this part:
Just heard of Darling. I would be delighted if it could be used for running builds on NixOS!
It seem to be packaged by but only for macOS. If i understand the project correctly, that makes no sense. We want it on linux, to run macOS apps. Also, the package has no version. That's probably because they havn't tagged a version yet. So this is pre-alpha state software. could you update the package to the commit the "stable" AUR package uses and add a version as described here: ? Then we can close this issue.
It looks like the project has started using tagged versions:
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 .
I'd still be very interested in seeing this , especially with the hope of future cross-compilation support
This would even make it possible to package Mac binaries for Linux!
I'm interested in this so that I can test cross compiled binaries when running tests.
I marked this as stale due to inactivity. &rarr;
Not stale!!
darling-dmg is just part of . To be exact, it is included as a submodule in the source tree of darling. The darling build will come with kernel modules. It would need someone with kernel-packaging experience to pack it into Nixpkgs. Build instructions in the Darling Docs:
I marked this as stale due to inactivity.
Code change:
dae = callPackage ../tools/networking/dae { }; <ins> darling = callPackage ../applications/emulators/darling { }; </ins> databricks-sql-cli = python3Packages.callPackage ../applications/misc/databricks-sql-cli { }; dhallDirectoryToNix = callPackage ../build-support/dhall/directory-to-nix.nix { };

Related discussion:
text: &rarr;
I'd still like to see this, though largely for much the same reason Andrew mentions at this point -- I've started working with zig and being able to test cross-compiled macos binaries would be brilliant.
I have got most of a Darling build file running, but I have found an interesting issue. Wever I build I get the following error: From this cmake file: As far as I can tell, the command is a special MacOS thing, and I unfortunately do not understand CMake well enough to fix it...
Well, turns out the issue is that Darling relies on git-submodules, and it looks like this must be built against the Git repo directly, not against the released tarball...
What would therefore be a derivation?
What do you mean It's just a with .
I tried to re-package the prebuilt deb from darling GitHub releases. Here is the nix code darling- Save these 2 snippets as and darling-, then run . With 2 problems: needs setuid/setgid perms, while nix-build would fail if dpkg-deb -x executed directly. I use fakeroot to ignore this problem. always fails. I am not a darling expert, have no idea.
Ah, fantastic, thanks! Looking forward to having this in nixpkgs anyway, but let's see how we go there.
It could be named when entering Nixpkgs.
Good suggestion. I've edited those two scripts.
I got as far as finding out that darlingserver doesn't start with that script because it expects /usr/bin, so updating my to a version, the next issue was that darlingserver was trying to mount overlayfs on "lowerdir=/usr/libexec/darling,up" (may be incomplete, this is strace output) which did not exist.
After a bit of tinkering I got Darling to build from source. I opened with more info. Please give it a try!
It seems that they now use instead of the kernel module. This would make packaging easier.
What's the purpose of ? If it is only the sandbox part of Darling, a new name like would bring less confusion. Update: Opened PR to do the renaming.
Code change:
<ins> {stdenv, fetchurl, leptonica, zlib, libwebp, giflib, libjpeg, libpng, libtiff }: stdenv.mkDerivation { name = "jbig2enc-0.28"; src = fetchurl { url = http://github.com/agl/jbig2enc/archive/0.28-dist.tar.gz; sha256 = "1wc0lmqz4jag3rhhk1xczlqpfv2qqp3fz7wzic2lba3vsbi1rrw3"; }; propagatedBuildInputs = [ leptonica zlib libwebp giflib libjpeg libpng libtiff ]; # This is necessary, because the resulting library has # /tmp/nix-build-jbig2enc/src/.libs before /nix/store/jbig2enc/lib # in its rpath, which means that patchelf --shrink-rpath removes # the /nix/store one.  By cleaning up before fixup, we ensure that # the /tmp/nix-build-jbig2enc/src/.libs directory is gone. preFixup = '' make clean ''; } </ins>

Related discussion:
text: Unfortunately I can not pinpoint the issue, but it seems that after a on Feb 1st, starts to omit a key file out of 3 key files and completely fails with a fresh system installation. Steps to reproduce the behavior: .nix contains the following lines All three files exist on disk. -rebuild switch produces a initrd-secret archive that is missing the third key file. system installation produces the following: All key files are included in generated initrd-secrets and does not fail. This issue does not exist before system update. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --This option is declared in <nixpkgs/nixos/modules/system/boot/stage-1.nix. Please run and paste the result.
I specifically installed an encrypted root on zfs system with . GRUB will decrypt disk on boot and initrd will re-decrypt disk partitions and swap with the keys embedded here.
I have that too, there seem to be a problem with here: Not sure where it is set from, but its value should be relative to the chroot, e.g. , not . It can be worked around by setting to an existing directory before installing/rebuilding, for example: Or by preparing a directory with yourself:
May be a duplicate of
Duplicate of indeed.
Code change:
, hello # Overridable configurations , enableNvidiaContainerCli ? true <ins> # --nvccli currently requires extra privileges: # https://github.com/apptainer/apptainer/issues/1893#issuecomment-1881240800 , forceNvcCli ? false </ins> # Compile with seccomp support # SingularityCE 3.10.0 and above requires explicit --without-seccomp when libseccomp is not available. , enableSeccomp ? true

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:
, hello # Overridable configurations , enableNvidiaContainerCli ? true <ins> # --nvccli currently requires extra privileges: # https://github.com/apptainer/apptainer/issues/1893#issuecomment-1881240800 , forceNvcCli ? false </ins> # Compile with seccomp support # SingularityCE 3.10.0 and above requires explicit --without-seccomp when libseccomp is not available. , enableSeccomp ? true

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:
, hello # Overridable configurations , enableNvidiaContainerCli ? true <ins> # --nvccli currently requires extra privileges: # https://github.com/apptainer/apptainer/issues/1893#issuecomment-1881240800 , forceNvcCli ? false </ins> # Compile with seccomp support # SingularityCE 3.10.0 and above requires explicit --without-seccomp when libseccomp is not available. , enableSeccomp ? true

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:
version = "11"; }; <ins> mathmod = libsForQt5.callPackage ../applications/science/math/mathmod { }; </ins> metis = callPackage ../development/libraries/science/math/metis { }; nauty = callPackage ../applications/science/math/nauty { };

Related discussion:
text: Project description Mathematical modelling software Metadata homepage URL: source URL: license: gpl2 platforms: cross-platform
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 .
I marked this as stale due to inactivity. &rarr;
Code change:
sha256 = "sha256-Hi9d5IF09QXeAlp9HnzwG73ZQiyoq5RReCvwDuF4YCw="; }; <ins> patches = [ # Fix tests for Ghostscript 9.56 # Remove after v0.1.3 has been released (fetchpatch { url = "https://github.com/CourtBouillon/pydyf/commit/d4c34823f1d15368753c9c26f7acc7a24fc2d979.patch"; sha256 = "sha256-2hHZW/q5CbStbpSJYbm3b23qKXANEb5jbPGQ83uHC+Q="; }) ]; </ins> postPatch = '' substituteInPlace pyproject.toml  --replace "--isort --flake8 --cov --no-cov-on-fail" ""

Related discussion:
text: Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: -
Code change:
--add-flags "--enable-preview"  --add-flags "--class-path '$out/share/cryptomator/libs/*'"  --add-flags "--module-path '$out/share/cryptomator/mods'"  <del> --add-flags "-Dcryptomator.logDir='~/.local/share/Cryptomator/logs'"  --add-flags "-Dcryptomator.pluginDir='~/.local/share/Cryptomator/plugins'"  --add-flags "-Dcryptomator.settingsPath='~/.config/Cryptomator/settings.json'"  --add-flags "-Dcryptomator.ipcSocketPath='~/.config/Cryptomator/ipc.socket'"  --add-flags "-Dcryptomator.mountPointsDir='~/.local/share/Cryptomator/mnt'"  </del> <ins> --add-flags "-Dfile.encoding='utf-8'"  --add-flags "-Dcryptomator.logDir='@{userhome}/.local/share/Cryptomator/logs'"  --add-flags "-Dcryptomator.pluginDir='@{userhome}/.local/share/Cryptomator/plugins'"  --add-flags "-Dcryptomator.settingsPath='@{userhome}/.config/Cryptomator/settings.json'"  --add-flags "-Dcryptomator.p12Path='@{userhome}/.config/Cryptomator/key.p12'"  --add-flags "-Dcryptomator.ipcSocketPath='@{userhome}/.config/Cryptomator/ipc.socket'"  --add-flags "-Dcryptomator.mountPointsDir='@{userhome}/.local/share/Cryptomator/mnt'"  </ins> --add-flags "-Dcryptomator.showTrayIcon=false"  --add-flags "-Dcryptomator.buildNumber='nix'"  --add-flags "-Dcryptomator.appVersion='${version}'" 

Related discussion:
text: In the vault options, vaults can only be mounted as . Steps to reproduce the behavior: cryptomator to a vault options the tab, the combo box does not contain a FUSE item Vaults can be mounted as FUSE volumes In the console output, cryptomator seems to have access to the fuse3 libs in its PATH: Full console output:
I think this might be related to It seems since they switched to the new fuse integration they only search a predefined number of paths. This is also consistent as the nix build of cryptomator works on non nixos linux.
I have the same issue. Does somebody have some workaraound yet? EDIT: so what I am currently doing, which is really not ideal, is just mounting the webdav directory with rclone, which, well, uses FUSE. so yeah rclone has no problems with using FUSE...
The fix for this is merged but not yet released It's in the 4.0.0 milestone of fuse-nio-adapter. I'm currently using the flapak version of Cryptomator.
thank you for the answer! i don't quite understand what is. Is it a dependency of ? Is there a way to manually fetch this so that it works? I'm gonna try the flatpak version of Cryptomator out, thanks for the hint. I actually tried out appimage, but that didn't change anything.
In the 1.11.0-beta2 release of cryptomator, vaults are able to be mounted as FUSE volumes. So once 1.11.0 is fully released (and the nixpkgs version updated), this issue should be fixed. Until the new version of cryptomator is released, you could create an overlay to use the beta version, like I am doing at the moment. Apart from changing the version and hashes, I also needed to change the jdk used to a jdk21 and overriding it to enable JavaFX:
thank you for your response! i hope i am not rude to ask for your help in achieving this myself. i put the following in my : and i also did the overlay.
Code change:
--add-flags "--enable-preview"  --add-flags "--class-path '$out/share/cryptomator/libs/*'"  --add-flags "--module-path '$out/share/cryptomator/mods'"  <del> --add-flags "-Dcryptomator.logDir='~/.local/share/Cryptomator/logs'"  --add-flags "-Dcryptomator.pluginDir='~/.local/share/Cryptomator/plugins'"  --add-flags "-Dcryptomator.settingsPath='~/.config/Cryptomator/settings.json'"  --add-flags "-Dcryptomator.ipcSocketPath='~/.config/Cryptomator/ipc.socket'"  --add-flags "-Dcryptomator.mountPointsDir='~/.local/share/Cryptomator/mnt'"  </del> <ins> --add-flags "-Dfile.encoding='utf-8'"  --add-flags "-Dcryptomator.logDir='@{userhome}/.local/share/Cryptomator/logs'"  --add-flags "-Dcryptomator.pluginDir='@{userhome}/.local/share/Cryptomator/plugins'"  --add-flags "-Dcryptomator.settingsPath='@{userhome}/.config/Cryptomator/settings.json'"  --add-flags "-Dcryptomator.p12Path='@{userhome}/.config/Cryptomator/key.p12'"  --add-flags "-Dcryptomator.ipcSocketPath='@{userhome}/.config/Cryptomator/ipc.socket'"  --add-flags "-Dcryptomator.mountPointsDir='@{userhome}/.local/share/Cryptomator/mnt'"  </ins> --add-flags "-Dcryptomator.showTrayIcon=false"  --add-flags "-Dcryptomator.buildNumber='nix'"  --add-flags "-Dcryptomator.appVersion='${version}'" 

Related discussion:
text: i get the following error when building: haven't been able to successfully find a solution via search engines...
For overlays, I simply copy the nix files and doing the following overlay: This is quite crude, and there is probably a better way to do it, but it at least avoids any weird errors like the one you are having.
Code change:
preFixup = '' gappsWrapperArgs+=( --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ stdenv.cc.cc ] }" <del> --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}" </del> <ins> # Currently crashes see https://github.com/NixOS/nixpkgs/issues/222043 #--add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}" </ins> --suffix PATH : ${lib.makeBinPath [ xdg-utils ]} )

Related discussion:
text: NixOS unstable is affected by on Wayland. Steps to reproduce the behavior: signal-desktop on Wayland. No crash. Add any other context about the problem here. Please run and paste the result.
I am also getting a crash every once in a while on startup. Starting it again works so far and it seems stable after that. Don't know what to do about that.
I've fixed this locally by using the following overlay:
Apparently, Signal beta works again on Wayland.
Just adding a data point. Having Wayland disabled actually caused more bugs for me. Re-enabling Wayland via 's overlay helped fix my compositor crashing whenever I clicked on certain UI like "preferences" in the "file" menu. Currently running: with set to and have the following env variables set:
Code change:
<ins> { alsa-lib, at-spi2-atk, at-spi2-core, atk, cairo, cups, curl, dbus, dpkg, expat, fetchurl, fontconfig, freetype, gdk-pixbuf, glib, gtk3, lib, libdrm, libnotify, libsecret, libuuid, libxcb, libxkbcommon, mesa, nspr, nss, pango, stdenv, systemd, wrapGAppsHook3, xorg, }: let version = "1.43.2"; rpath = lib.makeLibraryPath [ alsa-lib at-spi2-atk at-spi2-core atk cairo cups curl dbus expat fontconfig freetype gdk-pixbuf glib gtk3 libdrm libnotify libsecret libuuid libxcb libxkbcommon mesa nspr nss pango stdenv.cc.cc systemd xorg.libX11 xorg.libXScrnSaver xorg.libXcomposite xorg.libXcursor xorg.libXdamage xorg.libXext xorg.libXfixes xorg.libXi xorg.libXrandr xorg.libXrender xorg.libXtst xorg.libxkbfile xorg.libxshmfence (lib.getLib stdenv.cc.cc) ]; src = if stdenv.hostPlatform.system == "x86_64-linux" then fetchurl { url = "https://downloads.mongodb.com/compass/mongodb-compass_${version}_amd64.deb"; hash = "sha256-idOFt60MlspB8Bm9HbLAhd/F1zhkHSVmdTxvCsgjGvk="; } else throw "MongoDB compass is not supported on ${stdenv.hostPlatform.system}"; # NOTE While MongoDB Compass is available to darwin, I do not have resources to test it # Feel free to make a PR adding support if desired in stdenv.mkDerivation { pname = "mongodb-compass"; inherit version; inherit src; buildInputs = [ dpkg wrapGAppsHook3 gtk3 ]; dontUnpack = true; buildCommand = '' IFS=$'n' # The deb file contains a setuid binary, so 'dpkg -x' doesn't work here dpkg --fsys-tarfile $src | tar --extract mkdir -p $out mv usr/* $out # cp -av $out/usr/* $out rm -rf $out/share/lintian # The node_modules are bringing in non-linux files/dependencies find $out -name "*.app" -exec rm -rf {} ; || true find $out -name "*.dll" -delete find $out -name "*.exe" -delete # Otherwise it looks "suspicious" chmod -R g-w $out for file in `find $out -type f -perm /0111 -o -name *.so*`; do echo "Manipulating file: $file" patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" "$file" || true patchelf --set-rpath ${rpath}:$out/lib/mongodb-compass "$file" || true done wrapGAppsHook $out/bin/mongodb-compass ''; meta = { description = "GUI for MongoDB"; maintainers = with lib.maintainers; [ bryanasdev000 ]; homepage = "https://github.com/mongodb-js/compass"; sourceProvenance = with lib.sourceTypes; [ binaryNativeCode ]; license = lib.licenses.sspl; platforms = [ "x86_64-linux" ]; mainProgram = "mongodb-compass"; }; } </ins>

Related discussion:
text: Package name: mongodb-compass Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 1.43.0 Current version on the stable/release channel: 1.43.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]: