Question: rustPlatform.buildRustPackage rec { pname = "fido2luks"; <del> version = "0.2.20"; </del> <ins> version = "0.2.21"; </ins> src = fetchFromGitHub { owner = "shimunn"; repo = pname; rev = version; <del> sha256 = "04gl7wn38f42mapmkf026rya668vvhm03yi8iqnz31xgggbr2irm"; </del> <ins> sha256 = "sha256-bXwaFiRHURvS5KtTqIj+3GlGNbEulDgMDP51ZiO1w9o="; </ins> }; <del> cargoPatches = [ #https://github.com/shimunn/fido2luks/pull/50 (fetchpatch { name = "libcryptsetup-rs.patch"; url = "https://github.com/shimunn/fido2luks/commit/c87a9bbb4cbbe90be7385d4bc2946716c593b91d.diff"; sha256 = "2IWz9gcEbXhHlz7VWoJNBZfwnJm/J3RRuXg91xH9Pl4="; }) ]; </del> <ins> nativeBuildInputs = [ pkg-config clang ]; </ins> buildInputs = [ cryptsetup ]; <del> nativeBuildInputs = [ pkg-config clang ]; </del> configurePhase = '' export LIBCLANG_PATH="${llvmPackages.libclang.lib}/lib" ''; <del> cargoSha256 = "U/2dAmFmW6rQvojaKSDdO+/WzajBJmhOZWvzwdiYBm0="; </del> <ins> cargoSha256 = "sha256-MPji87jYJjYtDAXO+v/Z4XRtCKo+ftsNvmlBrM9iMTk="; </ins> meta = with lib; { description = "Decrypt your LUKS partition using a FIDO2 compatible authenticator"; homepage = "https://github.com/shimunn/fido2luks"; <del> license = licenses.gpl3; </del> <ins> license = licenses.mpl20; </ins> maintainers = with maintainers; [ prusnak mmahut ]; platforms = platforms.linux; };

The license listed for is incorrect. It has been re-licensed upstream: name: current version: desired version: n/a maintainers: Please tag this issue in your PR.
Fix in (which also updates the package)


Question: environment.systemPackages = [ pkgs.curl ]; }; traefik = { config, pkgs, ... }: { <del> docker-containers.nginx = { extraDockerOptions = [ </del> <ins> virtualisation.oci-containers.containers.nginx = { extraOptions = [ </ins> "-l" "traefik.enable=true" "-l" "traefik.http.routers.nginx.entrypoints=web" "-l" "traefik.http.routers.nginx.rule=Host(`nginx.traefik.test`)"

Describe the bug To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

Julia 1.5 is out, see: and we don't have it packaged. More over, see how defines our other Julias: Several issues: is pointing to a TLS version which is old IMO. Certainly there are breaking changes seen in , but since Nixpkgs is a somewhat rolling release distro, are we going to keep these older versions and default to them for ever? I've once tried to reach for the community to hear if there's a strict policy regarding such scenarios, but Anyway, I'd like to propose a change that will keep only the LTS version and the latest - currently 1.4, and perhaps make the attribute , point to the latest. Any thoughts from maintainers or users? cc
Also, now I noticed all of our Julias fail to build, e.g:
I agree. And the 1.5 release candidates are out, so this will become the latest version in the near future. Last time I looked, the package built the same deps for all versions, including 0.7. In versions 1.0 and later, there are actually fewer dependencies (e.g. arpack and fftw have been dropped), so the package should be cleaned up to not include these unnecessary libraries in the build. I also think the default version should be the latest version (i.e., unless somebody explicitly installs julia-1-lts, they should get the latest).
OK I'm glad I have your support. I'll let this issue stay open for a while and hopefully I'll be able to take care of this a month or so from now.
cc
Back when Julia tests were not so messed up, I think there was often 1 previous version. I guess with 1.3 needing overriding to no tests, it is fine to just have julia-1-lts and Julia 1.4 as julia once Julia 1.4 gets built fine with some tests.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Haven't had a lot of time to work on julia in nixpkgs, so just posting this as a FYI.


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

We used multiple versions of julia at work, but we use a custom derivation, similar to this: We also do not run the tests, but in general it has been working great. Previously we also used the binary builds patched with patchelf, as there were some differences in the structure of the results of the vanilla binary build provided by julia and what we got when building from source. We gave up on using 'system' libraries, and build the releases that julia provides, as julia is very specific in the versions for its dependencies (LLVM patches mostly).
I tried to use that tarball in order to write a derivation from scratch. Here's my attempt: It fails with: Naturally I didn't further attempt to add curl or wget to the inputs, as that would fail in a sandbox as well. I've opened an issue upstream: complaining that that tarball doesn't really contain all dependencies.
I ran with sandbox enabled, and the expression I linked with works for me. So I think it is fine to just add curl to the deps, as with the full tarball, it isn't actually used.
There is another approach to avoid running tests: using precompiled binary. I tried downloading the 1.4.2 binary from and then afterward ran on the binary, then I got a running Julia interpreter just like that.
We did the same for a while using code similar to this: Unfortunately, we actually sometimes need to patch Julia, so we switched to the julia expressions from source, that I posted earlier.
Thanks that expression works well thanks to . I'm testing it now.
OK so after a long build, I got a working Julia derivation with these references: And this closure size: Which I must say it is satisfying. The question is, is this how we'd want it to be built? Using all of their dependencies and practically non of ours? Some of their dependencies are required to be patched, according to and they also specify that using the OS' libraries is not officially supported? Anyway I'd happy to get help on deciding this.
does this lead to Julia tests passing? I think for every dependency they patch, it is OK to just use their patched version. I guess it could be nice to use a separate build unpatched (but using the exact same version sounds like a likely restriction), but whatever dependency does not work right away can be switched to bundled.


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

I think it did, I've set and the build passed but I haven't inspected the log much, but here it is: Currently produces this log but there's no PR yet as I think there are many makeFlags that should probably be set as well. If anyone feels confident to open a PR with this feel free to ping me for a review. I agree with the idea, but what's bothering me is that it's not absolutely clear what versions are patched and which are not - the docs vs what's actually found in is not totally inline. Also, it seems that some of the patches are old, and were suggested upstream (to the libraries) but they weren't merged there for some reason. I'm still investigating, See My current target is to decide what libraries to use our version vs their version, with the preference to use our version, in order to hopefully reduce closure size due to sharing shared libraries. The idea is to decide this by checking whether the libraries have included the patch Julia suggests, and then whether the library's maintainer has released a new version that includes Julia's maintainers' patch, and whether we ship that new version.
does this lead to Julia tests passing? I think this log is cut short before the interesting part…
I've uploaded it here:
Hmmm. Reading the log does not convince me the tests were run… Pity.
Since 1.5 was just released, the title should probably be updated to be 1.5.
Downside with the patching approach, is users lose the ability to compile against MKL, which has HUGE performance increase (last I saw showed that MKL was ~4x faster at matrix multiplication!!). Would need to also package JuliaPro to get MKL. Of course, anything working nothing working, although would be a shame to lose compilation options.
Says
Thanks garrison, I saw that, but I have a feeling it won't play nicely with Nix...although if we go patching route, perhaps could do that during buildPhase
Are you concerned about specifically or all packages that use BinaryBuilder? There are a lot of them. More on this at
As I understand binary builder, that all happens in userspace, but modifies , which is in /nix/store
The installation instructions for do not seem to require root. My guess is that it stores the modified sysimage somewhere in .


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

Am I wrong?
I just tried it with Julia 1.4 installed with Nix, and as I suspected fails to build due to
We need to have a interface - that would support building binary packages, and make the interpreter aware of them. I wish I was a bit more motivated to do this, but upstream disappoints me regarding the humble task of compiling Julia as is, with the right selection of a few system dependencies - no response at all at & . I'm also dis-motivated to explore this aspect, since their build system is of plain makefiles, and they keep patches of dependencies from so long ago, without documenting whether they are needed / used or not...
Nix behind It is a shame to see julia's support in NixOS languish. It seems pretty clear to me that upstream is only interested in supporting the configuration obtained by cloning their repository and typing on a stock Linux distribution. I understand their perspective in many ways, as having julia and all of its packages "just work" requires a lot of care, and building with unsupported configurations is very likely to result in brokenness somewhere in the package ecosystem if not in julia itself. Julia is a bit special in this regard because of its emphasis on performance and also its need to support interfaces to other languages/frameworks that often have weird requirements. I have found that typically, there is very good reason for these patches, even though at times they may not be documented except in git and github history. (Admittedly, I am less involved in upstream than I used to be.)
I think Julia team initially evaluated Nix as their binary distributor () but decided against it—there was a discussion somewhere but can’t find it. IIRC lack of Windows / desire to tie into native pkg management systems were factors. Julia’s does a pretty great job, and uses a solver to properly resolve dependency versions based on constraints. I’ve been incredibly frustrated by the withPackages pattern, at least in python. I constantly run into problems due to nixpkgs ignoring version constraints. There are some other nice advantages to nix of course: binary dependencies are shared across language ecosystems for example, and there are lots of supremely annoying packages (I’m looking at you CUDA...) that Nix makes delightfully easy to install, use, and maintain parallel versions.


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

But until Nixpkgs supports multiple versions across the board, and has a solver baked in, I’m honestly not sure Nix brings enough advantages to bail on Edit: I think the approach done by poetry2nix and Mach-nix are the way to go for Julia packages + nix. yarn2nix is another shining example. I would love to see a solution in this vein—didn’t mean to douse any enthusiasm for people interested in helping improve the Julia situation on NixOS :)
Maybe it is worth to reaching out to Julia Computing folks at to get their attention on ?
We'd probably need to put this information in our attribute sets, just like our Python packages know what deps they need. Hmm that's a bit surprising to hear as the Python ecosystem seems most well organized. Have you ever encountered a real bug with a mismatched version of a dependency with a specific version specified in a package's ? IIRC fails if a version is used and it's not exactly what's available. If you've ever felt there's a certain python package of a certain version missing, have you considered contributing it? Even if not, was it too hard to override it? What do you mean "across the board"? That might be much more harder then it sounds, due to the constraints of Nix it self when being evaluated everytime you run and friends, see It's not a question of whether Nix brings an advantage or not, it's a question of whether there are any Julia packages that are built at other distros imperatively with a , and this produces (or even worse, downloads) shared objects or executables into (not in ), linked to Julia or other Nix deps that do reside in . If the answer is yes, than every Nix user will experience breakage after Julia is updated in his - not necessarily if it's a version bump of Julia, it could be a mere rebuild of Julia by hydra. Yea Mach-nix is an awesome idea well implemented ( thanks for the inspiration :heart:). I've also reached a similar conclusion at . However, this is my opinion for Rust and Go, and I tend to think that for a small ecosystem like Julia, perhaps it'll be too much - it shouldn't be that hard to manage all of these pacakges like Python is managed in Nixpkgs.
I opened
Frequently.


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

Especially with Scipy, matplotlib, bokeh, sklearn, tensorflow, pytorch, etc... Often, nixpkgs used to have it until it was updated. Except in very rare circumstances, we do not keep more than one version of a python package around. I have no interest wasting time working around bugs that authors tried to spare me by specifying precise versions. It seems a sort of cognitive dissonance in our next community that we all care so deeply about reproducible builds, but for convenience often disregard the officially supported dependencies. As a result, there are often subtle bugs in software on NixOS that do not appear on other platforms. (Eg x11vnc crashes, shared memory problems, etc). Nix supports crazy high specificity in versioning, well we past semantic versioning down the the bit in many cases. And yet in nixpkgs, by convention, we remove the old version anytime we update. It’s understandable that Hydra cannot build everything, but it’s always bothered me that I have to pin nixpkgs if I want a build to stay functional over 1+ years. is mostly declarative. Of course, Julia is constantly re-compiling code, and until there is true support for precompilation, I don’t see how it’s possible to use nix store. This is due to multiple dispatch. Suppose I wrote a library to do an efficient k-nearest-neighbor query using some fancy free structure. Perhaps the core algorithms simply require a function for your types. When you write this new function, Julia has to compile all the code in the k-nearest neighbor library for this new type. Thus, it is not possible right now to compile a package on its own as the core pattern in Julia involves extending the function of other packages via multiple dispatch. You can only compile a package in context of the code that is running. Therefore, the Nix store approach is not appropriate. See
I see. You are talking about "authors" of Nixpkgs' expressions? I'm still a bit perplexed, as I earlier said, and correct me if I'm wrong: should fail if is used in , and the exact version is not available. Sometimes (), we do hardcode such version requirement changes in our expressions, but hopefully that's done only when it's justified.


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

I agree (maybe a bit ). Generally I think, every dep's version related issue should be handled by someone like you, who's familiar with python packages you use. I'd at least (open PRs) to fix the issues I encounter :). I see. I guess the situation is more complex than I thought, but I don't think I'd be able to form a strong opinion until I'll get a Julia interpreter from an expression I'm satisfied with. Thanks for the link :).
Unfortunately, this pattern is done constantly (including in my own contributions!). The problem is that, except an extremely rare cases like tensorflow, nixpkgs does not allow multiple versions of same python package to co-exist. Every time we update a package, we remove the previous version from nixpkgs. Confounding this issue, we often disable tests because sometimes the effort is just too high when developers bake in assumptions that aren’t compatible with the Nix ethos (for some reason this seems to happen more with tests then source code...). The most frequent cause of failure is the code needs to download something to run the test. (I’ve tried to lobby in the past that the test phase should be permitted to have Internet access as long as it doesn’t modify /nix/store, but I digress). In any case, the end result is that using a python package on Nix typically means you aren’t using the exact dependencies that upstream declared, and you’re more likely to have a package that despite having changes in dependencies has never had the test run. Thus, amazingly, I’ve had more luck with Julia packages working on NixOS than Python when all other binaries are present in environment.
I don't think there's a strong policy in our Python ecosystem against multiple versions of packages - if this is what upstream recommends. Anyway, the whole topic is out of scope for this issue. Feel free to open a new issue and cc me and who's working hard to ship a 20.09 release.
Yes, sorry getting a little off topic here. I mainly mention it to suggest that our efforts in Julia that start from scratch Can learn from these issues. I’m not too familiar with the new binary builder, but was quite nice in that it would first search for libraries before attempting to install.


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

See this issue for some context: Note that a core Julia dev gave a pretty great endorsement on Nix (albeit back in 2014): I think it might be most productive to do this development outside of nixpkgs, and do it in Julia to hook in with nixpkgs as needed. That way users could seamlessly use Pkg in Julia. I’d love to and have it just work instead of the current hack that I wrote that a lot of people seem to be using ()
Short summary of the Discourse thread: for LLVM and libuv it is essential to use the patches/forks. For other packages it is probably unnecessary to use the exact version specified by upstream.
Thanks for being there with me :). I think I'm gonna work on this once we are through with , to avoid merge conflicts.
TIL Guix manages to package Julia 1.4.1: What's interesting, is that they but they build it with Julia's LLVM patches fetched from the internet - they don't rely on Julia's build system to build it's own LLVM. For similar dependencies which the real system's version can't be used, they do the same. I think we should try to copy this approach.
FWIW I did that in Fedora originally, but I stopped. Since LLVM makes breaking releases very quickly, you'll probably want to move to a new version that Julia doesn't support quite soon.
Maybe I don't understand, but why should I move to an LLVM version that julia doesn't support? Also, aren't the and versions don't introduce breaking changes between minor releases? We could stick to since that's what Guix does and I think Julia uses this version as a base too.
I don't really know how NixOS works, hence the "FWIW". If you used versioned LLVM packages and keep older major versions then it's probably OK.
Just offering a user perspective: Julia provides a package manager that provides mostly reproducible (in a practical/scientific reproducibility sense rather than a bit-identical sense) environments easily from manifests. Increasingly, these environments are isolated from the host OS by binary packages for dependencies being served by Julia. I don't want Nix to manage dependencies that can handle for me: Julia already handles those excellently and conveniently. I just want Nix to handle the (usually few) system dependencies.


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

What I would like as a NixOS user is for Nix to provide me with a working Julia 1.5 derivation that provides: julia, a FHS wrapper or something providing compatible versions of the few things that Julia's binary packages need (just libc, libstdc++, libgfortran; I think. ). When I say "compatible", I mean that these libraries should work with the binaries and with the julia binary provided by Nix. Not all Julia packages are BinaryBuilder-ised yet, so I'd also want an easy way to specify that I want compatible versions of other packages installed (e.g. Qt, cairo, etc). For packages that need python, I don't know if I'd like Julia or Nix to handle installing and managing that. The simplest approach would be to tell Julia to do it (there is pretty good support in Julia for distributing isolated environments of python + packages + dependencies; better than in , imo). I don't know how doable any of that is in Nix, just describing what a good outcome would look like to me.
I think this is quite doable. I would propose that we add a new package, , that is a "batteries included" build that contains system libraries for all common Julia packages. Would this approach work for BinaryBuilder? I haven't used this yet. If not, we could fall back to a FHSuserenv, but I'm reluctant to do so if at all avoidable as there are outstanding nix bugs () that create seg faults in some heavy data processing workflows.
I think that is a good proposal and I think it will work with BinaryBuilder packages (e.g. SDL2_jll). In any case, some approach that works with BinaryBuilder packages should be found because those are a critical part of the Julia environment now :) Some important packages (e.g. GR) still want to build and install their own software dynamically, and that doesn't work well in Nix, but most of those can plausibly move to the BinaryBuilder system (PR for GR ), so I think letting those be broken would be tolerable (and a big improvement over the status quo of Julia on nix). Perhaps we can get something working quickly by just patchelf'ing the official Julia builds for now? (I don't understand how all of this stuff works!)


Question: makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

Is there anything presently blocking just getting julia 1.5 into nixpkgs? I don't care about ecosystem working with nixpkgs, just a good ol' fashioned julia install.
yes, see
If you just want Julia and don't mind about binary packages breaking you can just download Julia from the official site and patchelf it. On Sun, 4 Oct 2020, 09:32 Tyler Benster, <:
On the there was also the idea floated to patch to patchelf dynamically loaded binary dependencies.
Guix has a Julia package and it works quite well. Perhaps some ideas can be borrowed from there: It'd be really useful to get Julia working on Nix. It's the only big outstanding thing that doesn't work and prevents me from migrating some servers in my organization.
I tried to copy their expressions in and it doesn't work yet, but there's also another seemingly working attempt by at .
So, do we want anything else now that 1.5.3 is packaged (:greenheart: ? I think we: 't need clean up the expressions a bit - not use the file if it's not shared. I did (2) along with the julia_10 fix in As for (1) I will need a bit of feedback.
I guess some people like me still use julia_13 via test-disabling overrides, so a bit of time after 1.5 reaches channels for smooth transition could make sense?
Maybe backport 1.5 to 20.09?
OK so I disabled the tests for julia13 in and made the default there as well. All merged pull requests referenced here should be backported.


Question: { lib <del> , stdenv , fetchFromGitea </del> , acl , attr , autoreconfHook <ins> , bzip2 , fetchFromGitea </ins> , libburn <ins> , libcdio , libiconv </ins> , libisofs , pkg-config <ins> , readline , stdenv </ins> , zlib }:

Can't build xorriso due to source archive hash mismatch. Steps to reproduce the behavior: the substituter -shell -p xorriso nixpkgs 23.11.5408.
Probably it comes from a moving target... Let's go!
How exactly it happened? Here is the url: Is web archive failing?? P.S.: since Xorriso is just another name for libisoburn, I will remove xorriso and link-alias it to libisoburn.


Question: sha256 = "sha256-b9cBn5Nv+IxB58gi9G8QtRvXLWZZePZYZIPedbMMNr8="; }; <del> buildInputs = [ iptables-legacy libuuid openssl ]; </del> <ins> buildInputs = [ iptables-legacy libuuid openssl ] ++ lib.optionals (firewall == "nftables") [ libmnl libnftnl ]; </ins> nativeBuildInputs= [ pkg-config makeWrapper ]; # ./configure is not a standard configure file, errors with: # Option not recognized : --prefix= dontAddPrefix = true; <ins> configureFlags = [ "--firewall=${firewall}" # allow using various config options "--ipv6" "--leasefile" "--regex" "--vendorcfg" # hardening "--portinuse" ]; </ins> installFlags = [ "PREFIX=$(out)" "INSTALLPREFIX=$(out)" ]; <del> postFixup = '' for script in $out/etc/miniupnpd/ip{,6}tables_{init,removeall}.sh do wrapProgram $script --set PATH '${scriptBinEnv}:$PATH' done ''; </del> <ins> postFixup = { # Ideally we'd prefer using system's config.firewall.package here for iptables, # however for some reason switching --prefix to --suffix breaks the script iptables = '' for script in $out/etc/miniupnpd/ip{,6}tables_{init,removeall}.sh do wrapProgram $script --prefix PATH : '${scriptBinEnv}:$PATH' done ''; nftables = '' for script in $out/etc/miniupnpd/nft_{delete_chain,flush,init,removeall}.sh do wrapProgram $script --suffix PATH : '${scriptBinEnv}:$PATH' done ''; }.${firewall}; </ins> passthru.tests = { bittorrent-integration = nixosTests.bittorrent;

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: }; buildInputs = lib.optional pulseSupport libpulseaudio <del> ++ lib.optional jackSupport libjack2 ++ lib.optional alsaSupport alsa-lib; </del> <ins> ++ lib.optionals jackSupport [ libjack2 soxr ] ++ lib.optional alsaSupport alsa-lib ++ lib.optional pcapSupport libpcap; </ins> nativeBuildInputs = [ cmake pkg-config ]; cmakeFlags = [ "-DPULSEAUDIO_ENABLE=${if pulseSupport then "ON" else "OFF"}" "-DALSA_ENABLE=${if alsaSupport then "ON" else "OFF"}" "-DJACK_ENABLE=${if jackSupport then "ON" else "OFF"}" <ins> "-DPCAP_ENABLE=${if pcapSupport then "ON" else "OFF"}" </ins> ]; cmakeDir = "../Receivers/unix";

Scream does not compile with jack support when it is explicitly enabled through an overlay. nixpkgs.overlays = [ (final: prev: { scream = { jackSupport = true; }; }) ]
Error message?
There is no error, it just skips compiling it. someone else ran it and i think they said that it skips compiling it with jack support because soxr is missing -- Checking for module 'jack' -- Found jack, version 1.9.19 -- Checking for module 'soxr' -- No package 'soxr' found
See . In the meantime, you can try: nixpkgs.overlays = [ (final: prev: { scream = ( { jackSupport = true; }).overrideAttrs (old: { buildInputs = old.buildInputs ++ [ ]; }); }) ]


Question: <ins> { buildPythonPackage, fetchFromGitHub, fetchpatch, lib, pythonOlder , clang_7, python2 , graphviz, matplotlib, numpy, pandas, plotly, scipy, six , withCuda ? false, cudatoolkit }: buildPythonPackage rec { pname = "catboost"; version = "0.24.4"; disabled = pythonOlder "3.4"; src = fetchFromGitHub { owner = "catboost"; repo = "catboost"; rev = "v${version}"; sha256 = "sha256-pzmwEiKziB4ldnKgeCsP2HdnisX8sOkLssAzNfcSEx8="; }; nativeBuildInputs = [ clang_7 python2 ]; propagatedBuildInputs = [ graphviz matplotlib numpy pandas scipy plotly six ] ++ lib.optional withCuda [ cudatoolkit ]; patches = [ ./nix-support.patch (fetchpatch { name = "format.patch"; url = "https://github.com/catboost/catboost/pull/1528/commits/a692ba42e5c0f62e5da82b2f6fccfa77deb3419c.patch"; sha256 = "sha256-fNGucHxsSDFRLk3hFH7rm+zzTdDpY9/QjRs8K+AzVvo="; }) ]; preBuild = '' cd catboost/python-package ''; setupPyBuildFlags = [ "--with-ymake=no" ]; CUDA_ROOT = lib.optional withCuda cudatoolkit; enableParallelBuilding = true; # Tests use custom "ya" tool, not yet supported. dontUseSetuptoolsCheck = true; pythonImportsCheck = [ "catboost" ]; meta = with lib; { description = "High-performance library for gradient boosting on decision trees."; longDescription = '' A fast, scalable, high performance Gradient Boosting on Decision Trees library, used for ranking, classification, regression and other machine learning tasks for Python, R, Java, C++. Supports computation on CPU and GPU. ''; license = licenses.asl20; platforms = [ "x86_64-linux" ]; homepage = "https://catboost.ai"; maintainers = with maintainers; [ PlushBeaver ]; }; } </ins>

Would be a very useful package to have for ML Enthusiasts Project description Machine Learning Catboost Library Metadata CatBoost is a high-performance open source library for gradient boosting on decision trees homepage URL: source URL: license: Apache License 2.0 platforms: Linux installation instructions: Please let me know if I should stop tagging you in random issues and it bothers you (sorry, i'll stop), but I thought this might be of interest to you since you are very involved in tensorflow.
taggining maintainers of xgboost and lightgbm. Wondering if you could look into compiling catboost too?
I use tensorflow at work, which is why I care :). But I'm not a data-scientist
understood, thank you. GPU support for catboost would also be very welcome.
Looks like they have a non standard install script. But definitely doable. Sadly I don't think I have time in the near future but would be happy to point you in the right direction to get stared with a PR
both eyes wide open - i'll try to start this w/e, any pointers very welcome, thank you.
Currently failing to build on nix, although the file clearly exists.
- maybe it's easier if you create a work-in-progress pull request so other people can check? Two things that stand out are: looks like something is being downloaded during the build process. This won't work with sandboxing because there won't be a working network. builds should be isolated, i.e. access to should be rewritten to the local build directory, not (probably hardcoded somewhere in the build scripts). Packaging for nix can be quite fiddly - I think might be a good example for fetching complex dependencies + build script patches.
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 .


Question: 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 { };

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. →
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.


Question: 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 { };

→
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.


Question: <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>

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.


Question: , 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

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: , 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

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: , 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

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

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. →


Question: 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" ""

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: -


Question: --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}'"

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.


Question: --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}'"

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.


Question: 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 ]} )

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:


Question: <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>

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]:


Question: rm -rf $out/include rm -rf $out/lib/*.a mv $out/bin/chat $out/bin/${finalAttrs.meta.mainProgram} <ins> install -D ${finalAttrs.embed_model} $out/resources/nomic-embed-text-v1.5.f16.gguf </ins> install -m 444 -D $src/gpt4all-chat/flatpak-manifest/io.gpt4all.gpt4all.desktop $out/share/applications/io.gpt4all.gpt4all.desktop <del> install -m 444 -D $src/gpt4all-chat/icons/logo.svg $out/share/icons/hicolor/scalable/apps/io.gpt4all.gpt4all.svg </del> <ins> install -m 444 -D $src/gpt4all-chat/icons/nomic_logo.svg $out/share/icons/hicolor/scalable/apps/io.gpt4all.gpt4all.svg </ins> substituteInPlace $out/share/applications/io.gpt4all.gpt4all.desktop  --replace-fail 'Exec=chat' 'Exec=${finalAttrs.meta.mainProgram}' '';

Package name: gpt4all Latest released version: 3.2.1 <!-- Search your package here: --- Current version on the unstable channel: 2.8.0 Current version on the stable/release channel: 2.7.5 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi, I don't maintain GPT4All any longer, I switched to some other technologies (Open-WebUI).
haha, maybe i'll give that one a try then :) ty for all your hard work


Question: inherit (python2Packages) mutagen python wrapPython; }; <ins> dsp = callPackage ../tools/audio/dsp { }; </ins> dirdiff = callPackage ../tools/text/dirdiff { tcl = tcl-8_5; tk = tk-8_5;

Project description is an audio processing program with an interactive mode. Also has a LADSPA frontend. Metadata homepage URL: source URL: license: isc platforms: linux


Question: <ins> { lib , buildPythonPackage , fetchFromGitHub , pythonOlder , setuptools , setuptools-scm , libxcrypt , numpy , qt6 , qtpy , pyqt6 , pytestCheckHook , pytest-cov }: buildPythonPackage rec { pname = "echo"; version = "0.8.0"; disabled = pythonOlder "3.6"; src = fetchFromGitHub { owner = "glue-viz"; repo = pname; rev = "v${version}"; sha256 = "sha256-0FmUA7kOFSRZXwbj8d7asujBPOjE2pFhu6TDNSGD4r0="; }; nativeBuildInputs = [ setuptools setuptools-scm qt6.wrapQtAppsHook ]; buildInputs = lib.optionals (pythonOlder "3.9") [ libxcrypt ]; propagatedBuildInputs = [ qt6.qtconnectivity qt6.qtbase qt6.qttools pyqt6 numpy qtpy ]; env.SETUPTOOLS_SCM_PRETEND_VERSION = version; # collecting ... qt.qpa.xcb: could not connect to display # qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. doCheck = false; nativeCheckInputs = [ pytestCheckHook pytest-cov ]; pythonImportsCheck = [ "echo" ]; meta = with lib; { homepage = "https://github.com/glue-viz/echo"; description = "Callback Properties in Python"; license = licenses.mit; maintainers = with maintainers; [ ifurther ]; }; } </ins>

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: "--outfile", pubcert ) except: <del> rmtree(basedir) </del> <ins> rmtree(userdir) </ins> raise

So I today I spawned a machine with and satisfyingly the directory was generated with all of the certificates etc that taskwarrior needs, including the clients' certificates. I noticed that the users' keys located at are owned by root with read only permissions for the root user alone. No matter what are and . I'd like to enable the group read those client keys, as well as the file so that I can configure a client easily. Thankfully the group can read the file, but not the client keys. The manual indeed explains that the command: Could be used to get those keys, but I'd like to use syncthing for that to automate the process even further. I got a bit lost while reading the . Specifically, I'm not sure why does always works in the following umask: I mean, ~why not~ - a solution is suggested in . A word of comment will be appreciated. cc .


Question: pushover-complete = callPackage ../development/python-modules/pushover-complete { }; <ins> pvextractor = callPackage ../development/python-modules/pvextractor { }; </ins> pvlib = callPackage ../development/python-modules/pvlib { }; pvo = callPackage ../development/python-modules/pvo { };


Question: <ins> { gnome3, fetchFromGitHub, autoconf, automake, gtk_doc, gettext, libtool, gperf }: gnome3.vte.overrideAttrs (oldAttrs: rec { name = "vte-ng-${version}"; version = "0.46.1.a"; src = fetchFromGitHub { owner = "thestinger"; repo = "vte-ng"; rev = version; sha256 = "125fpibid1liz50d7vbxy71pnm8b01x90xnkr4z3419b90lybr0a"; }; # The patches apply the changes from https://github.com/GNOME/vte/pull/7 and # can be removed once the commits are merged into vte-ng. patches = [ ./fix_g_test_init_calls.patch ./fix_vteseq_n_lookup_declaration.patch ]; preConfigure = oldAttrs.preConfigure + "; ./autogen.sh"; nativeBuildInputs = [ gtk_doc autoconf automake gettext libtool ]; buildInputs = oldAttrs.buildInputs ++ [ gperf ]; }) </ins>

The package has been . Trying to install results in the following error: Why was the package marked as broken? Is there a way to help fix it? System: Nix version: Nixpkgs version:
According to the project homepage it requires a different version of the vte library: If you package this one and add it as a dependency the package should work again.
Thanks for the response . Could you help understand the reasoning behind the commit that marked it as broken? Was the problem that was being packaged with the wrong dependency?
The dependency it needs is not in NixPkgs, so it has to be packaged and nobody cared enough to do it.
We had the patched vte under gnome-3.20, but 3.20 was now removed whole without porting that to the vte in 3.22. EDIT: refs and .
I've wasted hours trying to fix building the special vte library, you may try to continue: This fails with: I don't see marking one package broken preferable to keeping the whole gnome-3.20 in tree, sadly. Please open a pull request if you manage to succeed, but I don't see myself wasting more time on this otherwise soon.
I fixed the errors you found during compilation and submitted a PR to upstream VTE. As the changes may take a while to propagate down into vte-ng, I them as patches to the vte-ng package, which is now used to compile termite.


Question: ```ShellSession $ cd /path/to/nixpkgs/doc $ nix-shell <del> [nix-shell]$ make $makeFlags </del> <ins> [nix-shell]$ make </ins> ``` If you experience problems, run `make debug` to help understand the docbook errors.

Describe the bug To contribute to the nixpkgs documentation I followed the instructions in the nixpkgs manual "Chapter 21. Contributing to this documentation" and I followed the code snippet Firstly I was greeted with some warnings: But moving on to I saw a large number of errors. It looks like is set up inside the nix-shell but it's not picked up by ? Running the command does work. To Reproduce Expected behavior No warnings, no errors. Metadata Please run and paste the result. Maintainer information:
nix-shell has a specific setup to allow running stdenv phases such as
That also gives me a bunch of errors as well, but different ones: For a bunch of files. I managed to write some updates to the docs and validated them just using the command, but it's a bit unfortunate that just following the instructions literally doesn't work.
Sorry about that. should fix it.
Thanks, that fixes it for me (tested by setting the env variable manually). Great to see these steps towards making it easier to contribute to the docs.


Question: configureFlags = [ "--localstatedir=/var" "--sysconfdir=/etc" <ins> ] ++ optionals withCloud [ "--enable-cloud" "--with-aclk-ng" </ins> ]; postFixup = ''

Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. →
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?


Question: grep -l -r '/bin/bash' --null | xargs -0 sed -i -e "s!/bin/bash!${bash}/bin/bash!g" ''; <del> nativeBuildInputs = [ makeWrapper python3 jdk11 ant watchman ]; </del> <ins> nativeBuildInputs = [ makeWrapper python3 jdk8 ant watchman ]; </ins> buildPhase = '' # Set correct version, see https://github.com/facebook/buck/issues/2607

Buck build system is packaged with the wrong JDK it seems PR introduced a bump in JDK version, see (). Metadata Please run and paste the result. Maintainer information:
I guess the most recent version should support java 11:
Until they make a stable release with those changes included, we will just use jdk8


Question: <del> { lib , stdenv , fetchFromGitHub , alsa-lib , cmake , ffmpeg , fribidi , game-music-emu , libXdmcp , libXv , libass , libcddb , libcdio , libpulseaudio , libsidplayfp , libva , libxcb , pkg-config , qtbase , qttools , taglib , vulkan-headers , vulkan-tools , wrapQtAppsHook }: stdenv.mkDerivation (finalAttrs: { pname = "qmplay2"; version = "24.04.07"; src = fetchFromGitHub { owner = "zaps166"; repo = "QMPlay2"; rev = finalAttrs.version; fetchSubmodules = true; hash = "sha256-WIDGApvl+aaB3Vdv0sHY+FHWqzreWWd3/xOLV11YfxM="; }; nativeBuildInputs = [ cmake pkg-config wrapQtAppsHook ]; buildInputs = [ alsa-lib ffmpeg fribidi game-music-emu libXdmcp libXv libass libcddb libcdio libpulseaudio libsidplayfp libva libxcb qtbase qttools taglib vulkan-headers vulkan-tools ]; postInstall = '' # Because we think it is better to use only lowercase letters! ln -s $out/bin/QMPlay2 $out/bin/qmplay2 ''; meta = { homepage = "https://github.com/zaps166/QMPlay2/"; description = "Qt-based Multimedia player"; longDescription = '' QMPlay2 is a video and audio player. It can play all formats supported by FFmpeg, libmodplug (including J2B and SFX). It also supports Audio CD, raw files, Rayman 2 music and chiptunes. It contains YouTube and MyFreeMP3 browser. ''; changelog = "https://github.com/zaps166/QMPlay2/releases/tag/${finalAttrs.version}"; license = lib.licenses.lgpl3Plus; maintainers = with lib.maintainers; [ AndersonTorres kashw2 ]; platforms = lib.platforms.linux; }; }) </del>

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.


Question: <del> { lib, stdenv, fetchurl, pkg-config, freeglut, libGLU, libGL, libcdio, libjack2 , libsamplerate, libsndfile, libX11, SDL2, SDL2_net, zlib, alsa-lib }: </del> <ins> { lib , stdenv , fetchurl , SDL2 , SDL2_net , alsa-lib , flac , freeglut , libGL , libGLU , libX11 , libcdio , libjack2 , libsamplerate , libsndfile , pkg-config , zlib }: </ins> stdenv.mkDerivation rec { pname = "mednafen"; <del> version = "1.26.1"; </del> <ins> version = "1.29.0"; </ins> src = fetchurl { url = "https://mednafen.github.io/releases/files/${pname}-${version}.tar.xz"; <del> sha256 = "1x7xhxjhwsdbak8l0iyb497f043xkhibk73w96xck4j2bk10fac4"; </del> <ins> hash = "sha256-2j+88Ch3+b4PAov6XRy1npU6QEm5D+fjk4ijOG2fNi4="; </ins> }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ <ins> SDL2 SDL2_net alsa-lib flac </ins> freeglut <del> libGLU libGL </del> <ins> libGL libGLU libX11 </ins> libcdio libjack2 <del> alsa-lib </del> libsamplerate libsndfile <del> libX11 SDL2 SDL2_net </del> zlib ];

<!-- 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: mednafen <!-- 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.26.1 (dated November 10, 2020) desired version: 1.29.0 (dated January 19, 2022) <!-- 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.


Question: <del> { lib, buildNpmPackage, fetchFromGitHub, vscode }: </del> <ins> { lib, stdenv, buildNpmPackage, fetchFromGitHub, vscode }: </ins> buildNpmPackage rec { pname = "vscode-langservers-extracted";

Steps to reproduce the behavior: nixos-unstable to home.packages -rebuild build Please run and paste the result.


Question: umurmur = callPackage ../applications/networking/umurmur { }; <del> udocker = pythonPackages.callPackage ../tools/virtualization/udocker { }; </del> <ins> udocker = callPackage ../tools/virtualization/udocker { }; </ins> uefitoolPackages = recurseIntoAttrs (callPackage ../tools/system/uefitool/variants.nix {}); uefitool = uefitoolPackages.new-engine;

I just discovered and i can't use it on NixOS Pulling image seems good Trying to run image fail because it try to mount some specials folders The : Trying without mounting folder fail because it can't find Start a shell with still fail because it can't find Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(pinage404): channels(root): nixpkgs:
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 .
It could still be important.
I marked this as stale due to inactivity. →


Question: <ins> diff --git a/MathMod.pro b/MathMod.pro index 2e2fbf1..bb8f8bd 100644 --- a/MathMod.pro +++ b/MathMod.pro @@ -63,7 +63,5 @@ OTHER_FILES     +=  mathmodcollection.js  mathmodconfig.js # install -target.path    = $TARGET -sources.files  = $$SOURCES $$HEADERS $$RESOURCES $$FORMS mathmod.pro -sources.path   = $TARGET -INSTALLS      += target sources +target.path    = @out@/bin +INSTALLS      += target </ins>

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. →


Question: }; }; <ins> disableImagemagick = mkOption { type = types.bool; default = false; description = '' Whether to not load the ImageMagick module into PHP. This is used by the theming app and for generating previews of certain images (e.g. SVG and HEIF). You may want to disable it for increased security. In that case, previews will still be available for some images (e.g. JPEG and PNG). See https://github.com/nextcloud/server/issues/13099 ''; }; </ins> caching = { apcu = mkOption { type = types.bool;

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.


Question: }; }; <ins> disableImagemagick = mkOption { type = types.bool; default = false; description = '' Whether to not load the ImageMagick module into PHP. This is used by the theming app and for generating previews of certain images (e.g. SVG and HEIF). You may want to disable it for increased security. In that case, previews will still be available for some images (e.g. JPEG and PNG). See https://github.com/nextcloud/server/issues/13099 ''; }; </ins> caching = { apcu = mkOption { type = types.bool;

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.


Question: }; config = mkMerge [ <ins> ({ # minimal configuration file to make lvmconfig/lvm2-activation-generator happy environment.etc."lvm/lvm.conf".text = "config {}"; }) </ins> (mkIf (!config.boot.isContainer) { systemd.tmpfiles.packages = [ cfg.package.out ]; environment.systemPackages = [ cfg.package ];

Describe the bug While the configuration contains no settings related to LVM, is launched during boot, and so on, and the "lvm2-activation-generator: lvmconfig failed" message is logged in the journal. Expected behavior At least, does not produce error messages. It might be better if the service is not activated if the system does not use LVM at all. Additional context may or may not be relevant. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(omasanori): nixpkgs: Maintainer information:
cc
I'll try to find some time to look into this, as I might be responsible for this.
I got this error when running in the console. It just froze, didn't reboot. Hitting enter put me back into the shell. Doing shutdown -h now worked. Very strange ..
I strongly suspect that your freeze was not caused by this warning message.
Yeah, so this was most likely caused by , which combined with the rest of leads to systemd being aware of lvm2 things. lvm2 was already in and for anything that's not a container, before this, but now it's also in . As for why this happens, it looks like it's , which fails when does not return what it expects. Since we do not install the default lvm config, it fails like so: The easiest solution to this is probably to install the default config file to . There is a problem with that though. If we use , we cannot use anymore to append any settings. We also cannot "copy" the defaults into e.g. with , because that would be import from derivation. So the remaining option is to simply set some default settings, which also kind of sucks, because then we need to track upstream on those, but it's probably our best option. If you have any other/better ideas, I'd gladly go for those, but if nobody does, I'll go with specifying some defaults, in a few days.
+1 to importing upstream defaults as it seems the safest option if it tracks upstream properly, even though it will certainly increase the maintenance cost.
I also would just create a default configuration if it is not possible to disable lvm2-activation-generator somehow if lvm is not used.
Detecting if lvm is used sadly isn't trivial.


Question: }; config = mkMerge [ <ins> ({ # minimal configuration file to make lvmconfig/lvm2-activation-generator happy environment.etc."lvm/lvm.conf".text = "config {}"; }) </ins> (mkIf (!config.boot.isContainer) { systemd.tmpfiles.packages = [ cfg.package.out ]; environment.systemPackages = [ cfg.package ];

For filesystems (in ) we can just look at the and enable the respective kernel modules and tools, but how would that be done for lvm?
Maybe it would be possible to fix/patch(&upstream) the generator?
lvm seems to have its default hard coded so we don't need to copy over the whole file. To fix the loading error I just an almost empty configuration to make the warning go away:


Question: xdotool = callPackage ../tools/X11/xdotool { }; <ins> xed-editor = callPackage ../applications/editors/xed-editor { xapps = cinnamon.xapps; }; </ins> xenPackages = recurseIntoAttrs (callPackage ../applications/virtualization/xen/packages.nix {}); xen = xenPackages.xen-vanilla;

Xed Text Editor from Linux Mint Text editor from the Linux Mint distribution xed text editor homepage URL: source URL: license: gpl2 platforms: linux
needs an update of a dependency to package newest version 2.8.4


Question: libcaca = null; }; <del> vlc_qt5 = vlc; </del> libvlc = vlc.override { withQt5 = false; qtbase = null;

Packaged VLC does not seem to support wayland. Steps to reproduce the behavior: vlc with on e.g. sway opens as a XWayland window VLC opens as a Wayland native window Not applicable Possibly related to VLC not depending on qtwayland. Please run and paste the result. EDIT: Typo
It is strange. I built it and verified, it is not linked with QT libraries even if they are put as inputs.
Is also pulled in as an input?
Nope. Working on it now. First encounter: Wayland is considered experimental and disabled by default.
Can you test the patch?
Works like a charm, thanks a lot! :)
I'm on NixOS 23.05 and discovered that vlc prefers to use XWayland if var is set. If I unset then vlc starts in Wayland mode. Does anyone know how to make it to start on Wayland by default?
For now I hacked it with: Special thanks to
Well, if this is hardcoded on VLC, there is nothing to do (besides maybe searching some hidden commandline flag).
The "use QTQPAPLATFORM be damned" behavior is apparently just what QT does, and is not specific to VLC
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Here is the updated wrap that also addresses the desktop file


Question: let pname = "shogun"; version = "6.1.4"; rxcppVersion = "4.0.0"; gtestVersion = "1.8.0"; srcs = { toolbox = fetchFromGitHub { owner = pname + "-toolbox";

shogun fails to build since the eigen 3.4.0 bump: The package is a likely candidate for removal. Upstream is unresponsive and development has halted. Removed from debian: Removed from fedora: Blocking vcpkg update: Please run and paste the result. Maintainer information:
I think you were the last one to modify this package, so please speak up if you need it. Also pinging Last call - if no one responds within the next week, I'll open a PR to remove this package.
Yes, I was working on making it build on Darwin and adding it as a Python 3 module. Well, I did, but I didn't feel motivated to create a PR. As you comment, upstream has been inactive for almost a year, the latest release is several years old, and it becomes harder and harder to make it work, and the patches would start to accumulate. To make it work on Darwin we need two upstream patches that fix the build with newer compiler versions. In the current derivation, the Python interface is not built because the CMake flag is not the right one. When enabled, Swig 3 is used to generate the Python interface, but Swig 3 doesn't support Python 3.8+ (and with Swig 4 just fails). It can be fixed with a patch, that feels more like a hack, intercepting the Makefile build, so I am not happy with it: Another small patch is needed to fix the deprecated . Also, I wasn't happy that adding it as a Python module will recompile the entire library again, which takes too much time IMO. I haven't checked if it is possible to build with Eigen 3.4 because it takes forever to compile. It could probably work on the development version. Note that the development version doesn't support Eigen 3.4 because of this, but it may work: But there is no such limitation on the 6.1.4 release, which probably means it would require another patch to fix the code, if somebody figures out. So, I'd argue that the package is too old now, and the derivation has too many issues, and it's too much of a hassle to maintain it, so it's probably better to just remove it.
I decided to sit and take a look at the error, and I actually fixed it.


Question: let pname = "shogun"; version = "6.1.4"; rxcppVersion = "4.0.0"; gtestVersion = "1.8.0"; srcs = { toolbox = fetchFromGitHub { owner = pname + "-toolbox";

I don't really use Eigen but the patch makes sense. So, I can send a PR to keep this package on the repo for another cycle at least. I mean, I already did all of the work and it builds. Other distros end up removing it because nobody cares to maintain it.
Nice! Thanks for looking into it. Like you said, if you've already done the work to get it working I don't see why not. If it's too much work to keep it working in the future we can always revisit this and drop it.


Question: }) ]; <ins> # Tweaks to fix undefined variable substitutions # https://github.com/HowardHinnant/date/pull/538#pullrequestreview-1373268697 postPatch = '' substituteInPlace date.pc.in  --replace '@CMAKE_INSTALL_LIB@' '@CMAKE_INSTALL_FULL_LIBDIR@'  --replace '@CMAKE_INSTALL_INCLUDE@' '@CMAKE_INSTALL_FULL_INCLUDEDIR@'  --replace '@PACKAGE_VERSION@' '${version}' ''; </ins> nativeBuildInputs = [ cmake ]; cmakeFlags = [

The pkg-config file in pkg looks like this: The and variables are empty. The keyword is also empty. As a result, the flags returned by pkg-config are wrong and checking the version does not work. Note the empty and and that the package version is actually 3.0.1, i.e. = 3.0.0. and should point to the correct directories in the and outputs of the pkg.


Question: github = "auchter"; githubId = 1190483; }; <ins> aucub = { name = "aucub"; email = "dr56ekgbb@mozmail.com"; github = "aucub"; githubId = 78630225; }; </ins> augustebaum = { email = "auguste.apple@gmail.com"; github = "augustebaum";

waveterm Modern open-source terminal emulator supporting inline rendering. homepage URL: source URL: license: Apache-2.0 platforms: linux, darwin
I've tried, got stuck at packaging waveterm with scripthaus. However i have packaged scripthaus which is required here. Maybe someone with better understanding of nodejs will make it.
Here's my attempt at cobbling something together for linux, which seems to be working locally for me (well, it's "working" in the sense that it builds, the GUI shows up and the basic shell features seem to be working): I wasn't able to get it building using the provided scripthaus scripts yet, but I'm also quite inexperienced in this area so that could be why. I'm currently using and instead, basing it off from a bunch of other electron and go packages on nixpkgs. I haven't carried across all the build flags from waveterm's provided scripthaus scripts though, and you might also see some vestigial code that I copied from other packages that don't apply for waveterm which I haven't cleaned up yet. If I have time I might give the scripthaus scripts another try. Some other remaining todos that I'm aware of include the desktop icon, getting it working on darwin, checking the AI features, checking that the package includes all the dependencies it needs at runtime, and fixing a failing test regarding command completions. Please feel free to continue working off from what I have if it helps, especially if I don't get back to this soon.
Waveterm offers a packages. I was installing and noticed that it fetched a package and installed it. Is it not possible to do the same? I also saw in this that packages are pulled for Opera and Skype as well. So, is it possible to do the same for Waveterm as well?
Forced M1 user here, tried packaging wave but didn't manage to make the scripthaus scripts run without fails, mainly because both go and scripthaus try to create cache directories and I didn't manage to disable this behaviour.


Question: github = "auchter"; githubId = 1190483; }; <ins> aucub = { name = "aucub"; email = "dr56ekgbb@mozmail.com"; github = "aucub"; githubId = 78630225; }; </ins> augustebaum = { email = "auguste.apple@gmail.com"; github = "augustebaum";

I also tried to use package but due to it requiring electron and it not being available for the M1 architecture I couldn't compile the application from source, so I think packaging for the M1 will have to be done through the .dmg that they have on the realeases page. I'll try packaging the application when I have time this weekend.
In the end I couldn't resist and worked something out for M1 in my free time, this works and creates a ./result directory with an application I can open, so I think it's pretty much done. The only thing missing is integrating with solution... I'll try doing it this weekend.
where did you get that info from?
When I searched for electron on Nix packages it never appeared a platform for darwin... I know it should be possible to have electron in M1 but at least on Nix it isn't packaged for it already. <img width="313" alt="image" src=""
Oh, nice! I thought the panel with platforms displayed all of them, clearly it doesn't. I'll first merge the linux build mentioned previously and then I'll try using that electron to build the app from scratch. Thank you!


Question: <ins> diff --git a/build.gradle b/build.gradle index 7025b2b..d063da3 100644 --- a/build.gradle +++ b/build.gradle @@ -20,6 +20,11 @@ repositories { } +tasks.withType(AbstractArchiveTask) { +    preserveFileTimestamps = false +    reproducibleFileOrder = true +} + licenseReport { renderers = [new JsonReportRenderer()] </ins>

Project description <!-- Describe the project a little: --Tools to manipulate pdf files. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll see what I can do, should be good practice working with Gradle apps
Thank you Tom, much appreciated, best of luck.
By the way, I have pretty much succeeded in packaging it, and it seemed to run fine. Just forgot about it a little. The only issue with the package currently is that jar files are created non-deterministically by default (timestamps are not set to a fixed time). After using the fixup hook made for this situation (unzip and rezip the jar file) springboot doesn't recognise its files anymore, which is really weird. So it stayed non-deterministic. So I have two options: A) use the non-deterministic package or B) use the prebuilt jar from GitHub. The latter one is much less complex to work with.
See if this helps you.. or this discussion from the top (concerning java apps)...
Thanks for the pointers, though the second thing linked is my own post :) I finally managed to figure out how to fix the jar timestamps, so I'll open a PR adding the package
Thank you for your help . Much appreciated.. sorry for the delay. had a rough week last and it spilled into this one. Looking forward to using stirling-pdf on nixos.