Question:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help

<ins> diff --git a/sdk/program/src/account_info.rs b/sdk/program/src/account_info.rs index 372370d0e15a0f2877b02ad29586e5b352438b24..3db3e9839b6535786e60be5602c03d0c909bf937 100644 --- a/sdk/program/src/account_info.rs +++ b/sdk/program/src/account_info.rs @@ -182,6 +182,7 @@ impl<'a> AccountInfo<'a> { Ok(()) } +    #[rustversion::attr(since(1.72), allow(invalid_reference_casting))] pub fn assign(&self, new_owner: &Pubkey) { // Set the non-mut owner field unsafe { </ins>


Question:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help

"solana-gossip" "solana-install" "solana-keygen" <ins> "solana-ledger-tool" </ins> "solana-log-analyzer" "solana-net-shaper" <del> "solana-sys-tuner" "rbpf-cli" </del> "solana-validator" <del> "solana-ledger-tool" "cargo-build-bpf" "cargo-test-bpf" "solana-dos" "solana-install-init" "solana-stake-accounts" "solana-test-validator" "solana-tokens" "solana-watchtower" "cargo-test-sbf" "cargo-build-sbf" </del> ] ++ [ # XXX: Ensure `solana-genesis` is built LAST! # See https://github.com/solana-labs/solana/issues/5826


Question:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help

] }: let <del> version = "1.14.23"; sha256 = "sha256-NUkkLzLNh8P7PFh/SVtd9JM18w3egDaaK80urGw1SSs="; cargoSha256 = "sha256-7t8Quh6T2MzJWEM5Y50CgCyFfx2ZJRAdCpZyyYvJrt4="; </del> <ins> version = "1.16.27"; sha256 = "sha256-xd0FCSlpPJDVWOlt9rIlnSbjksmvlXJWHkvlZONd2dM="; </ins> inherit (darwin.apple_sdk_11_0) Libsystem; inherit (darwin.apple_sdk_11_0.frameworks) System IOKit AppKit Security; in rustPlatform.buildRustPackage rec { pname = "solana-cli"; <del> inherit version cargoSha256; </del> <ins> inherit version; </ins> src = fetchFromGitHub { owner = "solana-labs";


Question:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help

inherit sha256; }; <ins> cargoLock = { lockFile = ./Cargo.lock; outputHashes = { "crossbeam-epoch-0.9.5" = "sha256-Jf0RarsgJiXiZ+ddy0vp4jQ59J9m0k3sgXhWhCdhgws="; "ntapi-0.3.7" = "sha256-G6ZCsa3GWiI/FeGKiK9TWkmTxen7nwpXvm5FtjNtjWU="; }; }; patches = [ # Fix: https://github.com/solana-labs/solana/issues/34203 # From https://github.com/Homebrew/homebrew-core/pull/156930/files#diff-f27c55b86df31cd4935c956efee1be743eae0958e3850f3f9891d51bfea50b1cR76 ./account-info.patch ]; </ins> strictDeps = true; cargoBuildFlags = builtins.map (n: "--bin=${n}") solanaPkgs;


Question:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help

description = "Web-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces. "; homepage = "https://solana.com"; license = licenses.asl20; <del> maintainers = with maintainers; [ netfox happysalada ]; </del> <ins> maintainers = with maintainers; [ netfox happysalada aikooo7 ]; </ins> platforms = platforms.unix; };


Question:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

-e 's^addCVars^addCVars${_infixSalt}^g'  -e 's^[ -z "$crossConfig" ]^[[ "${builtins.toString (targetPlatform != hostPlatform)}" || -z "$crossConfig" ]]^g' <del> '' + stdenv.lib.optionalString (textFile == ./setup-hook.sh) '' cat << 'EOF' >> $out for CMD in ar as nm objcopy ranlib strip strings size ld windres do # which is not part of stdenv, but compgen will do for now if PATH=$_PATH type -p ${prefix}$CMD > /dev/null then export ''$(echo "$CMD" | tr "[:lower:]" "[:upper:]")=${prefix}''${CMD}; fi done EOF sed -i $out -e 's_envHooks_crossEnvHooks_g' '' + '' </del> # NIX_ things which we don't both use and define, we revert them #asymmetric=$( #  for pre in "" "$"


Question:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

inherit cc shell libc_bin libc_dev libc_lib binutils_bin coreutils_bin; gnugrep_bin = if nativeTools then "" else gnugrep; <ins> binPrefix = prefix; </ins> passthru = { inherit libc nativeTools nativeLibc nativePrefix isGNU isClang default_cxx_stdlib_compile


Question:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

wrap ${prefix}ld.bfd ${preWrap ./ld-wrapper.sh} ${binutils_bin}/bin/${prefix}ld.bfd fi <del> export real_cc=${prefix}cc export real_cxx=${prefix}c++ </del> <ins> # We export environment variables pointing to the wrapped nonstandard # cmds, lest some lousy configure script use those to guess compiler # version. export named_cc=${prefix}cc export named_cxx=${prefix}c++ </ins> export default_cxx_stdlib_compile="${default_cxx_stdlib_compile}" if [ -e $ccPath/${prefix}gcc ]; then wrap ${prefix}gcc ${preWrap ./cc-wrapper.sh} $ccPath/${prefix}gcc ln -s ${prefix}gcc $out/bin/${prefix}cc <del> export real_cc=${prefix}gcc export real_cxx=${prefix}g++ </del> <ins> export named_cc=${prefix}gcc export named_cxx=${prefix}g++ </ins> elif [ -e $ccPath/clang ]; then wrap ${prefix}clang ${preWrap ./cc-wrapper.sh} $ccPath/clang ln -s ${prefix}clang $out/bin/${prefix}cc <del> export real_cc=clang export real_cxx=clang++ </del> <ins> export named_cc=${prefix}clang export named_cxx=${prefix}clang++ </ins> fi if [ -e $ccPath/${prefix}g++ ]; then


Question:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

<del> export NIX_CC=@out@ </del> addCVars () { if [ -d $1/include ]; then export NIX_CFLAGS_COMPILE+=" ${ccIncludeFlag:--isystem} $1/include"


Question:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

fi if [ -z "$crossConfig" ]; then <del> export CC=@real_cc@ export CXX=@real_cxx@ </del> <ins> ENV_PREFIX="" </ins> else <del> export BUILD_CC=@real_cc@ export BUILD_CXX=@real_cxx@ </del> <ins> ENV_PREFIX="BUILD_" </ins> fi <ins> export NIX_${ENV_PREFIX}CC=@out@ export ${ENV_PREFIX}CC=@named_cc@ export ${ENV_PREFIX}CXX=@named_cxx@ for CMD in  cpp  ar as nm objcopy ranlib strip strings size ld windres do if PATH=$_PATH type -p "@binPrefix@$CMD" > /dev/null then export "${ENV_PREFIX}${CMD^^}=@binPrefix@${CMD}"; fi done # No local scope available for sourced files unset ENV_PREFIX </ins>


Question:
I would absolutely love for somebody to package up :)
will attempt to reserve some time to give it a try in the next days :-)
I created a first working version which compiles on my machine ( ): Unfortunately I had to use an older revision since the latest revisions require language features from Rust 1.19 and I'll have to bump it in nixpkgs before using the latest revision, after that I'll open a PR :-)
btw do we want to add an option which allows to change the coreutils pkg from to ? Something like and every module should start start using .
I had contemplated using a package override and just make equal to . Not sure how well that would work out... This may be something where is one of the few qualified to chime in.
Please don't introduce this as a NixOS option. This rewrite is not compatible with the GNU coreutils. This will certainly break NixOS. The package override will break lots of packages and will trigger a full rebuild anyway. Packaging these for testing is fine. :+1:
Could you just wrap this into a PR then? I will certainly test this and create some aliases to replace the GNU tools (in the user environment)
sorry for the delay at first. I'm aware of this. I just proposed an approach to switch the package just for system-wide testing purposes. This is actually the better approach. Furthermore this is something anyone can do locally, so shouldn't have concers with it as it shouldn't affect code in for now :-) I'll certainly do. However we have to wait for since the latest revisions of require Rust 1.19 (I'm currenty using an older revision from July 2017 locally). I checked out this change tried to compile uutils-coreutils against the new Rust compiler, but it cargo builds seem to fail ()
Ah, of course. Let's wait for then.
after has been merged it should be possible to finally implement this. Will open a PR in th next days...

<ins> { stdenv, fetchFromGitHub, rustPlatform, cargo, cmake, sphinx, lib, prefix ? "uutils-" }: rustPlatform.buildRustPackage { name = "uutils-coreutils-2018-02-09"; src = fetchFromGitHub { owner = "uutils"; repo = "coreutils"; rev = "f333ab26b03294a32a10c1c203a03c6b5cf8a89a"; sha256 = "0nkggs5nqvc1mxzzgcsqm1ahchh4ll11xh0xqmcljrr5yg1rhhzf"; }; # too many impure/platform-dependent tests doCheck = false; cargoSha256 = "0qv2wz1bxhm5xhzbic7cqmn8jj8fyap0s18ylia4fbwpmv89nkc5"; makeFlags = [ "CARGO=${cargo}/bin/cargo" "PREFIX=$(out)" "PROFILE=release" "INSTALLDIR_MAN=$(out)/share/man/man1" ] ++ lib.optional (prefix != null) [ "PROG_PREFIX=${prefix}" ]; nativeBuildInputs = [ cmake ]; buildInputs = [ cargo sphinx ]; # empty {build,install}Phase to use defaults of `stdenv.mkDerivation` rather than rust defaults buildPhase = ""; installPhase = ""; meta = with stdenv.lib; { description = "Cross-platform Rust rewrite of the GNU coreutils"; longDescription = '' uutils is an attempt at writing universal (as in cross-platform) CLI utils in Rust. This repo is to aggregate the GNU coreutils rewrites. ''; homepage = https://github.com/uutils/coreutils; maintainers = with maintainers; [ ma27 ]; license = licenses.mit; platforms = platforms.unix; }; } </ins>


Question:
I would absolutely love for somebody to package up :)
will attempt to reserve some time to give it a try in the next days :-)
I created a first working version which compiles on my machine ( ): Unfortunately I had to use an older revision since the latest revisions require language features from Rust 1.19 and I'll have to bump it in nixpkgs before using the latest revision, after that I'll open a PR :-)
btw do we want to add an option which allows to change the coreutils pkg from to ? Something like and every module should start start using .
I had contemplated using a package override and just make equal to . Not sure how well that would work out... This may be something where is one of the few qualified to chime in.
Please don't introduce this as a NixOS option. This rewrite is not compatible with the GNU coreutils. This will certainly break NixOS. The package override will break lots of packages and will trigger a full rebuild anyway. Packaging these for testing is fine. :+1:
Could you just wrap this into a PR then? I will certainly test this and create some aliases to replace the GNU tools (in the user environment)
sorry for the delay at first. I'm aware of this. I just proposed an approach to switch the package just for system-wide testing purposes. This is actually the better approach. Furthermore this is something anyone can do locally, so shouldn't have concers with it as it shouldn't affect code in for now :-) I'll certainly do. However we have to wait for since the latest revisions of require Rust 1.19 (I'm currenty using an older revision from July 2017 locally). I checked out this change tried to compile uutils-coreutils against the new Rust compiler, but it cargo builds seem to fail ()
Ah, of course. Let's wait for then.
after has been merged it should be possible to finally implement this. Will open a PR in th next days...

uudeview = callPackage ../tools/misc/uudeview { }; <ins> uutils-coreutils = callPackage ../tools/misc/uutils-coreutils { inherit (pythonPackages) sphinx; }; </ins> zabbix-cli = callPackage ../tools/misc/zabbix-cli { }; ### DEVELOPMENT / EMSCRIPTEN


Question:
Steps to reproduce the behavior: curaengine This was on an update yesterday to . Please run and paste the result.
I opened a PR yesterday:

<del> { lib, stdenv, fetchFromGitHub, cmake, libarcus, stb, protobuf }: </del> <ins> { lib, stdenv, fetchFromGitHub, cmake, libarcus, stb, protobuf, fetchpatch }: </ins> stdenv.mkDerivation rec { pname = "curaengine";


Question:
Steps to reproduce the behavior: curaengine This was on an update yesterday to . Please run and paste the result.
I opened a PR yesterday:

cmakeFlags = [ "-DCURA_ENGINE_VERSION=${version}" ]; <ins> # TODO already fixed in master, remove in next release patches = [ (fetchpatch { url = "https://github.com/Ultimaker/CuraEngine/commit/de60e86a6ea11cb7d121471b5dd192e5deac0f3d.patch"; hash = "sha256-/gT9yErIDDYAXvZ6vX5TGlwljy31K563+sqkm1UGljQ="; includes = [ "src/utils/math.h" ]; }) ]; </ins> meta = with lib; { description = "A powerful, fast and robust engine for processing 3D models into 3D printing instruction"; homepage = "https://github.com/Ultimaker/CuraEngine";


Question:
Steps to reproduce the behavior: with latest master branch is building with the older version of (2.5), because it can't build with the latest version (see: ). Build of started to fail after recent update to version . Notify Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

<del> { lib , stdenv , callPackage , fetchFromGitHub , testers , enableE57 ? lib.meta.availableOn stdenv.hostPlatform libe57format , cmake , curl , gdal , hdf5-cpp , LASzip , libe57format , libgeotiff , libtiff , libxml2 , openscenegraph , pkg-config , postgresql , tiledb , xercesc , zlib , zstd }: stdenv.mkDerivation (finalAttrs: { pname = "pdal"; version = "2.5.6"; src = fetchFromGitHub { owner = "PDAL"; repo = "PDAL"; rev = finalAttrs.version; sha256 = "sha256-JKwa89c05EfZ/FxOkj8lYmw0o2EgSqafRDIV2mTpZ5E="; }; nativeBuildInputs = [ cmake pkg-config ]; buildInputs = [ curl gdal hdf5-cpp LASzip libgeotiff libtiff libxml2 openscenegraph postgresql tiledb xercesc zlib zstd ] ++ lib.optionals enableE57 [ libe57format ]; cmakeFlags = [ "-DBUILD_PLUGIN_E57=${if enableE57 then "ON" else "OFF"}" "-DBUILD_PLUGIN_HDF=ON" "-DBUILD_PLUGIN_PGPOINTCLOUD=ON" "-DBUILD_PLUGIN_TILEDB=ON" "-DWITH_TESTS=ON" "-DBUILD_PGPOINTCLOUD_TESTS=OFF" # Plugins can probably not be made work easily: "-DBUILD_PLUGIN_CPD=OFF" "-DBUILD_PLUGIN_FBX=OFF" # Autodesk FBX SDK is gratis+proprietary; not packaged in nixpkgs "-DBUILD_PLUGIN_GEOWAVE=OFF" "-DBUILD_PLUGIN_I3S=OFF" "-DBUILD_PLUGIN_ICEBRIDGE=OFF" "-DBUILD_PLUGIN_MATLAB=OFF" "-DBUILD_PLUGIN_MBIO=OFF" "-DBUILD_PLUGIN_MRSID=OFF" "-DBUILD_PLUGIN_NITF=OFF" "-DBUILD_PLUGIN_OCI=OFF" "-DBUILD_PLUGIN_RDBLIB=OFF" # Riegl rdblib is proprietary; not packaged in nixpkgs "-DBUILD_PLUGIN_RIVLIB=OFF" ]; doCheck = true; disabledTests = [ # Tests failing due to TileDB library implementation, disabled also # by upstream CI. # See: https://github.com/PDAL/PDAL/blob/bc46bc77f595add4a6d568a1ff923d7fe20f7e74/.github/workflows/linux.yml#L81 "pdal_io_tiledb_writer_test" "pdal_io_tiledb_reader_test" "pdal_io_tiledb_time_writer_test" "pdal_io_tiledb_time_reader_test" "pdal_io_tiledb_bit_fields_test" "pdal_io_e57_read_test" "pdal_io_e57_write_test" "pdal_io_stac_reader_test" # Segfault "pdal_io_hdf_reader_test" # Failure "pdal_app_plugin_test" ]; checkPhase = '' runHook preCheck # tests are flaky and they seem to fail less often when they don't run in # parallel ctest -j 1 --output-on-failure -E '^${lib.concatStringsSep "|" finalAttrs.disabledTests}$' runHook postCheck ''; passthru.tests = { version = testers.testVersion { package = finalAttrs.finalPackage; command = "pdal --version"; version = "pdal ${finalAttrs.finalPackage.version}"; }; pkg-config = testers.testMetaPkgConfig finalAttrs.finalPackage; }; meta = with lib; { description = "PDAL is Point Data Abstraction Library. GDAL for point cloud data"; homepage = "https://pdal.io"; license = licenses.bsd3; maintainers = teams.geospatial.members; platforms = platforms.all; pkgConfigModules = [ "pdal" ]; }; }) </del>


Question:
Steps to reproduce the behavior: with latest master branch is building with the older version of (2.5), because it can't build with the latest version (see: ). Build of started to fail after recent update to version . Notify Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

}: let <del> # replace with global pdal version once # https://github.com/qgis/QGIS/pull/54940 is backported pdal = callPackage ./pdal-2_5.nix { }; </del> py = python3.override { packageOverrides = self: super: { pyqt5 = super.pyqt5.override {


Question:
Steps to reproduce the behavior: with latest master branch is building with the older version of (2.5), because it can't build with the latest version (see: ). Build of started to fail after recent update to version . Notify Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

qtserialport qtxmlpatterns qt3d <del> pdal </del> <ins> # pdal </ins> zstd ] ++ lib.optional withGrass grass ++ lib.optional withWebKit qtwebkit


Question:
Steps to reproduce the behavior: with latest master branch is building with the older version of (2.5), because it can't build with the latest version (see: ). Build of started to fail after recent update to version . Notify Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

}) ]; <ins> # PDAL is disabled until https://github.com/qgis/QGIS/pull/54940 # is backported. </ins> cmakeFlags = [ "-DWITH_3D=True" <del> "-DWITH_PDAL=TRUE" </del> <ins> "-DWITH_PDAL=False"  # TODO: re-enable PDAL </ins> "-DENABLE_TESTS=False" ] ++ lib.optional (!withWebKit) "-DWITH_QTWEBKIT=OFF" ++ lib.optional withGrass (let


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

{ config, lib, pkgs, ... }: <del> with lib; </del> let cfg = config.services.locate; <del> isMLocate = hasPrefix "mlocate" cfg.package.name; isPLocate = hasPrefix "plocate" cfg.package.name; </del> <ins> isMLocate = lib.hasPrefix "mlocate" cfg.package.name; isPLocate = lib.hasPrefix "plocate" cfg.package.name; </ins> isMorPLocate = isMLocate || isPLocate; <del> isFindutils = hasPrefix "findutils" cfg.package.name; </del> <ins> isFindutils = lib.hasPrefix "findutils" cfg.package.name; </ins> in { imports = [ <del> (mkRenamedOptionModule [ "services" "locate" "period" ] [ "services" "locate" "interval" ]) (mkRenamedOptionModule [ "services" "locate" "locate" ] [ "services" "locate" "package" ]) (mkRemovedOptionModule [ "services" "locate" "includeStore" ] "Use services.locate.prunePaths") </del> <ins> (lib.mkRenamedOptionModule [ "services" "locate" "period" ] [ "services" "locate" "interval" ]) (lib.mkRenamedOptionModule [ "services" "locate" "locate" ] [ "services" "locate" "package" ]) (lib.mkRemovedOptionModule [ "services" "locate" "includeStore" ] "Use services.locate.prunePaths") </ins> ]; <del> options.services.locate = with types; { enable = mkOption { type = bool; </del> <ins> options.services.locate = { enable = lib.mkOption { type = lib.types.bool; </ins> default = false; description = '' If enabled, NixOS will periodically update the database of


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

''; }; <del> package = mkPackageOption pkgs [ "findutils" "locate" ] { </del> <ins> package = lib.mkPackageOption pkgs [ "findutils" "locate" ] { </ins> example = "mlocate"; }; <del> interval = mkOption { type = str; </del> <ins> interval = lib.mkOption { type = lib.types.str; </ins> default = "02:15"; example = "hourly"; description = ''


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

''; }; <del> extraFlags = mkOption { type = listOf str; </del> <ins> extraFlags = lib.mkOption { type = lib.types.listOf lib.types.str; </ins> default = [ ]; description = '' Extra flags to pass to {command}`updatedb`. ''; }; <del> output = mkOption { type = path; </del> <ins> output = lib.mkOption { type = lib.types.path; </ins> default = "/var/cache/locatedb"; description = '' The database file to build. ''; }; <del> localuser = mkOption { type = nullOr str; </del> <ins> localuser = lib.mkOption { type = lib.types.nullOr lib.types.str; </ins> default = "nobody"; description = '' The user to search non-network directories as, using


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

''; }; <del> pruneFS = mkOption { type = listOf str; </del> <ins> pruneFS = lib.mkOption { type = lib.types.listOf lib.types.str; </ins> default = [ "afs" "anon_inodefs"


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

''; }; <del> prunePaths = mkOption { type = listOf path; </del> <ins> prunePaths = lib.mkOption { type = lib.types.listOf lib.types.path; </ins> default = [ "/tmp" "/var/tmp"


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

''; }; <del> pruneNames = mkOption { type = listOf str; </del> <ins> pruneNames = lib.mkOption { type = lib.types.listOf lib.types.str; </ins> default = lib.optionals (!isFindutils) [ ".bzr" ".cache" ".git" ".hg" ".svn" ]; <del> defaultText = literalMD '' </del> <ins> defaultText = lib.literalMD '' </ins> `[ ".bzr" ".cache" ".git" ".hg" ".svn" ]`, if supported by the locate implementation (i.e. mlocate or plocate). '';


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

''; }; <del> pruneBindMounts = mkOption { type = bool; </del> <ins> pruneBindMounts = lib.mkOption { type = lib.types.bool; </ins> default = false; description = '' Whether not to index bind mounts


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

}; <del> config = mkIf cfg.enable { users.groups = mkMerge [ (mkIf isMLocate { mlocate = { }; }) (mkIf isPLocate { plocate = { }; }) </del> <ins> config = lib.mkIf cfg.enable { users.groups = lib.mkMerge [ (lib.mkIf isMLocate { mlocate = { }; }) (lib.mkIf isPLocate { plocate = { }; }) </ins> ]; security.wrappers =


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

setgid = true; setuid = false; }; <del> mlocate = mkIf isMLocate { </del> <ins> mlocate = lib.mkIf isMLocate { </ins> group = "mlocate"; source = "${cfg.package}/bin/locate"; }; <del> plocate = mkIf isPLocate { </del> <ins> plocate = lib.mkIf isPLocate { </ins> group = "plocate"; source = "${cfg.package}/bin/plocate"; }; in <del> mkIf isMorPLocate { locate = mkMerge [ common mlocate plocate ]; plocate = mkIf isPLocate (mkMerge [ common plocate ]); </del> <ins> lib.mkIf isMorPLocate { locate = lib.mkMerge [ common mlocate plocate ]; plocate = lib.mkIf isPLocate (lib.mkMerge [ common plocate ]); </ins> }; <del> environment.systemPackages = [ cfg.package ]; </del> <ins> environment = { # write /etc/updatedb.conf for manual calls to `updatedb` etc."updatedb.conf".text = '' PRUNEFS="${lib.concatStringsSep " " cfg.pruneFS}" PRUNENAMES="${lib.concatStringsSep " " cfg.pruneNames}" PRUNEPATHS="${lib.concatStringsSep " " cfg.prunePaths}" PRUNE_BIND_MOUNTS="${if cfg.pruneBindMounts then "yes" else "no"}" ''; </ins> <del> environment.variables.LOCATE_PATH = cfg.output; </del> <ins> systemPackages = [ cfg.package ]; </ins> <del> environment.etc = { # write /etc/updatedb.conf for manual calls to `updatedb` "updatedb.conf" = { text = '' PRUNEFS="${lib.concatStringsSep " " cfg.pruneFS}" PRUNENAMES="${lib.concatStringsSep " " cfg.pruneNames}" PRUNEPATHS="${lib.concatStringsSep " " cfg.prunePaths}" PRUNE_BIND_MOUNTS="${if cfg.pruneBindMounts then "yes" else "no"}" ''; </del> <ins> variables = lib.mkIf isFindutils { LOCATE_PATH = cfg.output; </ins> }; }; <del> warnings = optional (isMorPLocate && cfg.localuser != null) </del> <ins> warnings = lib.optional (isMorPLocate && cfg.localuser != null) </ins> "mlocate and plocate do not support the services.locate.localuser option. updatedb will run as root. Silence this warning by setting services.locate.localuser = null." <del> ++ optional (isFindutils && cfg.pruneNames != [ ]) </del> <ins> ++ lib.optional (isFindutils && cfg.pruneNames != [ ]) </ins> "findutils locate does not support pruning by directory component" <del> ++ optional (isFindutils && cfg.pruneBindMounts) </del> <ins> ++ lib.optional (isFindutils && cfg.pruneBindMounts) </ins> "findutils locate does not support skipping bind mounts"; systemd.services.update-locatedb = { description = "Update Locate Database"; <del> path = mkIf (!isMorPLocate) [ pkgs.su ]; </del> <ins> path = lib.mkIf (!isMorPLocate) [ pkgs.su ]; </ins> # mlocate's updatedb takes flags via a configuration file or # on the command line, but not by environment variable.


Question:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

if isMorPLocate then let toFlags = x: <del> optional (cfg.${x} != [ ]) "--${lib.toLower x} '${concatStringsSep " " cfg.${x}}'"; args = concatLists (map toFlags [ "pruneFS" "pruneNames" "prunePaths" ]); </del> <ins> lib.optional (cfg.${x} != [ ]) "--${lib.toLower x} '${lib.concatStringsSep " " cfg.${x}}'"; args = lib.concatLists (map toFlags [ "pruneFS" "pruneNames" "prunePaths" ]); </ins> in '' exec ${cfg.package}/bin/updatedb  <del> --output ${toString cfg.output} ${concatStringsSep " " args}  </del> <ins> --output ${toString cfg.output} ${lib.concatStringsSep " " args}  </ins> --prune-bind-mounts ${if cfg.pruneBindMounts then "yes" else "no"}  <del> ${concatStringsSep " " cfg.extraFlags} </del> <ins> ${lib.concatStringsSep " " cfg.extraFlags} </ins> '' else '' exec ${cfg.package}/bin/updatedb  <del> ${optionalString (cfg.localuser != null && !isMorPLocate) "--localuser=${cfg.localuser}"}  --output=${toString cfg.output} ${concatStringsSep " " cfg.extraFlags} </del> <ins> ${lib.optionalString (cfg.localuser != null && !isMorPLocate) "--localuser=${cfg.localuser}"}  --output=${toString cfg.output} ${lib.concatStringsSep " " cfg.extraFlags} </ins> ''; <del> environment = optionalAttrs (!isMorPLocate) { PRUNEFS = concatStringsSep " " cfg.pruneFS; PRUNEPATHS = concatStringsSep " " cfg.prunePaths; PRUNENAMES = concatStringsSep " " cfg.pruneNames; </del> <ins> environment = lib.optionalAttrs (!isMorPLocate) { PRUNEFS = lib.concatStringsSep " " cfg.pruneFS; PRUNEPATHS = lib.concatStringsSep " " cfg.prunePaths; PRUNENAMES = lib.concatStringsSep " " cfg.pruneNames; </ins> PRUNE_BIND_MOUNTS = if cfg.pruneBindMounts then "yes" else "no"; }; <del> serviceConfig.Nice = 19; serviceConfig.IOSchedulingClass = "idle"; serviceConfig.PrivateTmp = "yes"; serviceConfig.PrivateNetwork = "yes"; serviceConfig.NoNewPrivileges = "yes"; serviceConfig.ReadOnlyPaths = "/"; # Use dirOf cfg.output because mlocate creates temporary files next to # the actual database. We could specify and create them as well, # but that would make this quite brittle when they change something. # NOTE: If /var/cache does not exist, this leads to the misleading error message: # update-locatedb.service: Failed at step NAMESPACE spawning …/update-locatedb-start: No such file or directory serviceConfig.ReadWritePaths = dirOf cfg.output; </del> <ins> serviceConfig = { Nice = 19; IOSchedulingClass = "idle"; PrivateTmp = "yes"; PrivateNetwork = "yes"; NoNewPrivileges = "yes"; ReadOnlyPaths = "/"; # Use dirOf cfg.output because mlocate creates temporary files next to # the actual database. We could specify and create them as well, # but that would make this quite brittle when they change something. # NOTE: If /var/cache does not exist, this leads to the misleading error message: # update-locatedb.service: Failed at step NAMESPACE spawning …/update-locatedb-start: No such file or directory ReadWritePaths = dirOf cfg.output; }; </ins> }; <del> systemd.timers.update-locatedb = mkIf (cfg.interval != "never") { </del> <ins> systemd.timers.update-locatedb = lib.mkIf (cfg.interval != "never") { </ins> description = "Update timer for locate database"; partOf = [ "update-locatedb.service" ]; wantedBy = [ "timers.target" ];


Question:
A recent update broke building sysdig on release-17.03 branch. Nixpkgs version:
Does newer versions of sysdig solve the problem?
Fixed in
Thanks!

<ins> {stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { version = "0.15.2"; name = "vala-${version}"; src = fetchurl { url = "mirror://gnome/sources/vala/0.15/${name}.tar.xz"; sha256 = "0g71zq6dpqrw2f40wfzdf18fdw41ymr17laqniy2kr622hkxdi8w"; }; buildNativeInputs = [ yacc flex pkgconfig xz ]; buildInputs = [ glib ]; meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; }; } </ins>


Question:
A recent update broke building sysdig on release-17.03 branch. Nixpkgs version:
Does newer versions of sysdig solve the problem?
Fixed in
Thanks!

<ins> {stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { version = "0.16.1"; name = "vala-${version}"; src = fetchurl { url = "mirror://gnome/sources/vala/0.16/${name}.tar.xz"; sha256 = "1n708n9ixyy9qrzyv1wf4ybvcclx43ib9ki028wwpvkz6kv8zqlb"; }; buildNativeInputs = [ yacc flex pkgconfig xz ]; buildInputs = [ glib ]; meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; }; } </ins>


Question:
A recent update broke building sysdig on release-17.03 branch. Nixpkgs version:
Does newer versions of sysdig solve the problem?
Fixed in
Thanks!

{stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { <del> name = "vala-0.14.2"; </del> <ins> version = "0.17.2"; name = "vala-${version}"; </ins> src = fetchurl { <del> url = mirror://gnome/sources/vala/0.14/vala-0.14.2.tar.xz; sha256 = "1l5kllw9vpwv24lzv9fp64l3sad46wpxgvsgryrwlrjg91w6jzl0"; </del> <ins> url = "mirror://gnome/sources/vala/0.17/${name}.tar.xz"; sha256 = "09i2s0dwmrk147ind2dx7nq845g12fp6fsjqrphhrr0dbi0zzgh3"; </ins> }; buildNativeInputs = [ yacc flex pkgconfig xz ];


Question:
A recent update broke building sysdig on release-17.03 branch. Nixpkgs version:
Does newer versions of sysdig solve the problem?
Fixed in
Thanks!

meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; <ins> license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; </ins> }; }


Question:
A recent update broke building sysdig on release-17.03 branch. Nixpkgs version:
Does newer versions of sysdig solve the problem?
Fixed in
Thanks!

urweb = callPackage ../development/compilers/urweb { }; <del> vala = callPackage ../development/compilers/vala { }; </del> <ins> vala = vala17; vala15 = callPackage ../development/compilers/vala/15.2.nix { }; vala16 = callPackage ../development/compilers/vala/16.1.nix { }; vala17 = callPackage ../development/compilers/vala/default.nix { }; </ins> visualcpp = callPackage ../development/compilers/visual-c++ { };


Question: Package name: Tribler Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 7.13.0 Current version on the stable/release channel: 7.11.0 <!-- 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. This may Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<del> { lib , stdenv , fetchurl , fetchPypi , python3 , makeWrapper , libtorrent-rasterbar-1_2_x , qt5 }: let libtorrent = (python3.pkgs.toPythonModule (libtorrent-rasterbar-1_2_x)).python; in stdenv.mkDerivation rec { pname = "tribler"; version = "7.13.0"; src = fetchurl { url = "https://github.com/Tribler/tribler/releases/download/v${version}/Tribler-${version}.tar.xz"; hash = "sha256-j9+Kq6dOqiJCTY3vuRWGnciuwACU7L0pl73l6nkDLN4="; }; nativeBuildInputs = [ python3.pkgs.wrapPython makeWrapper # we had a "copy" of this in tribler's makeWrapper # but it went out of date and broke, so please just use it directly qt5.wrapQtAppsHook ]; buildInputs = [ python3.pkgs.python ]; pythonPath = [ libtorrent ] ++ (with python3.pkgs; [ # requirements-core.txt aiohttp aiohttp-apispec anyio chardet configobj cryptography decorator faker libnacl lz4 marshmallow netifaces networkx pony psutil pyasn1 pydantic_1 pyopenssl pyyaml sentry-sdk service-identity yappi yarl bitarray (pyipv8.overrideAttrs (p: rec { version = "2.10.0"; src = fetchPypi { inherit (p) pname; inherit version; hash = "sha256-yxiXBxBiPokequm+vjsHIoG9kQnRnbsOx3mYOd8nmiU="; }; })) libtorrent file-read-backwards brotli human-readable # requirements.txt pillow pyqt5 #pyqt5-sip pyqtgraph pyqtwebengine ]); installPhase = '' mkdir -pv $out # Nasty hack; call wrapPythonPrograms to set program_PYTHONPATH. wrapPythonPrograms cp -prvd ./* $out/ makeWrapper ${python3.pkgs.python}/bin/python $out/bin/tribler  --set _TRIBLERPATH "$out/src"  --set PYTHONPATH $out/src/tribler-core:$out/src/tribler-common:$out/src/tribler-gui:$program_PYTHONPATH  --set NO_AT_BRIDGE 1  --chdir "$out/src"  --add-flags "-O $out/src/run_tribler.py" mkdir -p $out/share/applications $out/share/icons cp $out/build/debian/tribler/usr/share/applications/org.tribler.Tribler.desktop $out/share/applications/ cp $out/build/debian/tribler/usr/share/pixmaps/tribler_big.xpm $out/share/icons/tribler.xpm mkdir -p $out/share/copyright/tribler mv $out/LICENSE $out/share/copyright/tribler ''; shellHook = '' wrapPythonPrograms || true export QT_QPA_PLATFORM_PLUGIN_PATH=$(echo ${qt5.qtbase.bin}/lib/qt-*/plugins/platforms) export PYTHONPATH=./tribler-core:./tribler-common:./tribler-gui:$program_PYTHONPATH export QT_PLUGIN_PATH="${qt5.qtsvg.bin}/${qt5.qtbase.qtPluginPrefix}" ''; meta = with lib; { description = "Decentralised P2P filesharing client based on the Bittorrent protocol"; mainProgram = "tribler"; homepage = "https://www.tribler.org/"; license = licenses.lgpl21Plus; maintainers = with maintainers; [ xvapx viric mkg20001 ]; platforms = platforms.linux; }; } </del>


Question: Package name: Tribler Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 7.13.0 Current version on the stable/release channel: 7.11.0 <!-- 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. This may Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<ins> { lib, stdenv, fetchurl, fetchPypi, python3, makeWrapper, libtorrent-rasterbar-1_2_x, qt5, nix-update-script, }: let libtorrent = (python3.pkgs.toPythonModule (libtorrent-rasterbar-1_2_x)).python; in stdenv.mkDerivation (finalAttrs: { pname = "tribler"; version = "7.14.0"; src = fetchurl { url = "https://github.com/Tribler/tribler/releases/download/v${finalAttrs.version}/Tribler-${finalAttrs.version}.tar.xz"; hash = "sha256-fQJOs9P4y71De/+svmD7YZ4+tm/bC3rspm7SbOHlSR4="; }; nativeBuildInputs = [ python3.pkgs.wrapPython makeWrapper # we had a "copy" of this in tribler's makeWrapper # but it went out of date and broke, so please just use it directly qt5.wrapQtAppsHook ]; buildInputs = [ python3.pkgs.python ]; pythonPath = [ libtorrent ] ++ (with python3.pkgs; [ # requirements-core.txt aiohttp aiohttp-apispec anyio chardet configobj cryptography decorator faker libnacl lz4 marshmallow netifaces networkx pony psutil pyasn1 pydantic_1 pyopenssl pyyaml sentry-sdk service-identity yappi yarl bitarray filelock (pyipv8.overrideAttrs (p: rec { version = "2.10.0"; src = fetchPypi { inherit (p) pname; inherit version; hash = "sha256-yxiXBxBiPokequm+vjsHIoG9kQnRnbsOx3mYOd8nmiU="; }; })) file-read-backwards brotli human-readable # requirements.txt pillow pyqt5 #pyqt5-sip pyqtgraph pyqtwebengine ]); installPhase = '' mkdir -pv $out # Nasty hack; call wrapPythonPrograms to set program_PYTHONPATH. wrapPythonPrograms cp -prvd ./* $out/ makeWrapper ${python3.pkgs.python}/bin/python $out/bin/tribler  --set _TRIBLERPATH "$out/src"  --set PYTHONPATH $out/src/tribler-core:$out/src/tribler-common:$out/src/tribler-gui:$program_PYTHONPATH  --set NO_AT_BRIDGE 1  --chdir "$out/src"  --add-flags "-O $out/src/run_tribler.py" mkdir -p $out/share/applications $out/share/icons cp $out/build/debian/tribler/usr/share/applications/org.tribler.Tribler.desktop $out/share/applications/ cp $out/build/debian/tribler/usr/share/pixmaps/tribler_big.xpm $out/share/icons/tribler.xpm mkdir -p $out/share/copyright/tribler mv $out/LICENSE $out/share/copyright/tribler ''; shellHook = '' wrapPythonPrograms || true export QT_QPA_PLATFORM_PLUGIN_PATH=$(echo ${qt5.qtbase.bin}/lib/qt-*/plugins/platforms) export PYTHONPATH=./tribler-core:./tribler-common:./tribler-gui:$program_PYTHONPATH export QT_PLUGIN_PATH="${qt5.qtsvg.bin}/${qt5.qtbase.qtPluginPrefix}" ''; passthru.updateScript = nix-update-script { }; meta = { description = "Decentralised P2P filesharing client based on the Bittorrent protocol"; mainProgram = "tribler"; homepage = "https://www.tribler.org/"; changelog = "https://github.com/Tribler/tribler/releases/tag/v${finalAttrs.version}"; license = lib.licenses.lgpl21Plus; maintainers = with lib.maintainers; [ xvapx viric mkg20001 ]; platforms = lib.platforms.linux; }; }) </ins>


Question: Package name: Tribler Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 7.13.0 Current version on the stable/release channel: 7.11.0 <!-- 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. This may Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

tremc = callPackage ../applications/networking/p2p/tremc { }; <del> tribler = callPackage ../applications/networking/p2p/tribler { }; </del> trillian-im = callPackage ../applications/networking/instant-messengers/trillian-im { }; trojita = libsForQt5.callPackage ../applications/networking/mailreaders/trojita { };


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

<ins> diff --git a/build.gradle b/build.gradle index c206e2f..b1fda33 100644 --- a/build.gradle +++ b/build.gradle @@ -69,19 +69,7 @@ launch4j { messagesInstanceAlreadyExists="Stirling-PDF is already running." } -spotless { -    java { -        target project.fileTree('src/main/java') -        googleJavaFormat('1.19.1').aosp().reorderImports(false) - -        importOrder('java', 'javax', 'org', 'com', 'net', 'io') -        toggleOffOn() -        trimTrailingWhitespace() -        indentWithSpaces() -        endWithNewline() -    } -} dependencies { //security updates @@ -163,9 +151,6 @@ dependencies { annotationProcessor 'org.projectlombok:lombok:1.18.28' } -tasks.withType(JavaCompile) { -    dependsOn 'spotlessApply' -} compileJava { options.compilerArgs << '-parameters' } </ins>


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

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


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

<ins> { lib, stdenv, fetchFromGitHub, substituteAll, gradle_7, perl, makeWrapper, jre, }: stdenv.mkDerivation (finalAttrs: { pname = "stirling-pdf"; version = "0.22.3"; src = fetchFromGitHub { owner = "Stirling-Tools"; repo = "Stirling-PDF"; rev = "v${finalAttrs.version}"; hash = "sha256-8zXTapFAXw4+KLLirxBeEBmqNw6ILFHtbsaBSP3Ehyg="; }; patches = [ # disable spotless because it tries to fetch files not in the FOD # and also because it slows down the build process ./disable-spotless.patch # remove timestamp from the header of a generated .properties file ./remove-props-file-timestamp.patch # use gradle's built-in method of zeroing out timestamps, # because stripJavaArchivesHook can't patch signed JAR files ./fix-jar-timestamp.patch # set the FOD as the only repository gradle can resolve from (substituteAll { src = ./use-fod-maven-repo.patch; inherit (finalAttrs) deps; }) ]; # fake build to pre-download deps into fixed-output derivation deps = stdenv.mkDerivation { name = "${finalAttrs.pname}-${finalAttrs.version}-deps"; inherit (finalAttrs) src; patches = [ ./disable-spotless.patch ]; nativeBuildInputs = [ gradle_7 perl ]; buildPhase = '' runHook preBuild export GRADLE_USER_HOME=$(mktemp -d) gradle --no-daemon --console=plain build runHook postBuild ''; # perl code mavenizes pathes (com.squareup.okio/okio/1.13.0/a9283170b7305c8d92d25aff02a6ab7e45d06cbe/okio-1.13.0.jar -> com/squareup/okio/okio/1.13.0/okio-1.13.0.jar) installPhase = '' runHook preInstall find $GRADLE_USER_HOME/caches/modules-2 -type f -regex '.*.(jar|pom)'  | perl -pe 's#(.*/([^/]+)/([^/]+)/([^/]+)/[0-9a-f]{30,40}/([^/s]+))$# ($x = $2) =~ tr|.|/|; "install -Dm444 $1 $out/$x/$3/$4/$5" #e'  | sh # Mimic existence of okio-3.6.0.jar, originally known as okio-jvm-3.6.0 (and renamed). # Gradle doesn't detect such renames and only fetches the latter. # Whenever this package gets updated, please check if this hack is obsolete. ln -s $out/com/squareup/okio/okio-jvm/3.6.0/okio-jvm-3.6.0.jar $out/com/squareup/okio/okio/3.6.0/okio-3.6.0.jar runHook postInstall ''; outputHashAlgo = "sha256"; outputHashMode = "recursive"; outputHash = "sha256-zUzKSa7zuIoXE77Hk/Xr5iMF4CEumV9horW2BTFRdtE="; }; nativeBuildInputs = [ gradle_7 makeWrapper ]; buildPhase = '' runHook preBuild export GRADLE_USER_HOME=$(mktemp -d) gradle --offline --no-daemon --console=plain build runHook postBuild ''; installPhase = '' runHook preInstall install -Dm644 build/libs/Stirling-PDF-*.jar $out/share/stirling-pdf/Stirling-PDF.jar makeWrapper ${jre}/bin/java $out/bin/Stirling-PDF  --add-flags "-jar $out/share/stirling-pdf/Stirling-PDF.jar" runHook postInstall ''; meta = { changelog = "https://github.com/Stirling-Tools/Stirling-PDF/releases/tag/${finalAttrs.src.rev}"; description = "A locally hosted web application that allows you to perform various operations on PDF files"; homepage = "https://github.com/Stirling-Tools/Stirling-PDF"; license = lib.licenses.gpl3Only; mainProgram = "Stirling-PDF"; maintainers = with lib.maintainers; [ tomasajt ]; platforms = jre.meta.platforms; sourceProvenance = with lib.sourceTypes; [ fromSource binaryBytecode # deps ]; }; }) </ins>


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

<ins> diff --git a/build.gradle b/build.gradle index e12cbd3..094a219 100644 --- a/build.gradle +++ b/build.gradle @@ -173,6 +173,7 @@ task writeVersion { def props = new Properties() props.setProperty('version', version) props.store(propsFile.newWriter(), null) +    propsFile.text = propsFile.readLines().tail().join('n') } swaggerhubUpload { </ins>


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

<ins> diff --git a/build.gradle b/build.gradle index c206e2f..cdaddf7 100644 --- a/build.gradle +++ b/build.gradle @@ -16,7 +16,7 @@ version = '0.22.3' sourceCompatibility = '17' repositories { -    mavenCentral() +    maven { url '@deps@' } } diff --git a/settings.gradle b/settings.gradle index f813993..2c87f3c 100644 --- a/settings.gradle +++ b/settings.gradle @@ -1 +1,7 @@ +pluginManagement { +    repositories { +        maven { url '@deps@' } +    } +} + rootProject.name = 'Stirling-PDF' </ins>


Question:
When creating a dev shell with + , the resulting environment cannot use CUDA with . Steps to reproduce the behavior: a Note that I am using the commit from nixos-23.11, which is the latest at this moment. However, I have tried the commit from a month ago and the problem was there as well. , run with the above flake. and Note that it reports is found, but does not seem to have CUDA enabled. The above can be found . It is expected that and run with CUDA and GPU appears in the device list. I am running this on my NixOS machine with a Nvidia GPU, where nvidia-driver is properly installed. I am also an intensive user and it works perfectly. Also I vaguely remember such combination works correctly a few months ago. I am not particularly sure about the maintainers so I might be wrong. Based on 's commit history and meta I am goingt to and Please run and paste the result.
Let me know if I can provide more useful information. Any suggestion on how I can continue debugging this would also be very helpful. Thanks in advance!
hmm interesting... ooc what gpu are you trying to use? have you confirmed that the cuda capabilities specified in your flake are compatible with your gpu?
Also please gist the outputs of demonstrating which implementation of jaxlib ends up being loaded, and whether a search for is attempted
On this machine it is a 3060 Ti. I have been using on this machine, with the samilar dev Shell, so I can confirm the cuda capabilities specified should work.
Thanks. Let me put the stderr log here: The log is very huge. I tried to search for and it did not come back with anything. I am trying to see how is loaded from it.
I think it is trying to load from , but I am not sure whether it is the GPU-enabled one or not. I tend to think the above is the GPU-enabled because if I specify in the dev shell, it loads instead.
Also just to confirm: what's the output of ? Sometimes multiple jaxlib versions can get pulled in as transitive dependencies (though they shouldn't if everything is packaged correctly). Then python can end up loading jaxlib-without-cuda instead of jaxlib-with-cuda depending on the ordering in PYTHONPATH. From the looks of your flake this shouldn't be the case, but I'm guessing that this is a reproduction distilled from a more complex flake/project?
Yes this is distilled from a real world flake. It seems that in my dev shell is not set. However, running produces: I looked into the of the : Apparently there is only one being pulled in here.
Ok yeah that looks fine.. hmm
Btw, I tried two more things the capabilities constraint - still the same this on a 3090 machine, a 3080 machine and a 4090 machine. All of them produce exactly the same behavior.
Attempting to repro this but currently blocked on
Interesting. I had an attempt to run my nix-based ML project on an Ubuntu machine but wasn't able to get the nix dev shell to recognize the GPU a while ago. Have been using NixOS for development since then ...
Oh yeah it definitely works... mostly. This is the first real issue I've had with nixGL haha
Will give it a try! Meanwhile, I can try out any thoughts/ideas you might have to debug. Thanks!
Yeah my hope upon getting a repro is to bisect nixpkgs commits to find a known-good commit and then hopefully isolate the issue in a commit range. If you're feeling up to the task it would be quite useful! This would be a great use case for GPU-enabled tests and some CI infrastructure. tl;dr is that build has been green for a while but at some point it stopped actually using/recognizing GPUs.
Got it. This looks like something I can try. It would probably take a while as I'd imagine CUDA will be built again and again.
Let me try to build from a few commits on to start with.
Tried from about 3 months ago. Got different behavior: An older version has similar issue:
Also confirmed that can reproduce the probem: Similarly, from 2023-12-01 can reproduce the issue:
The above seems to suggest that, it is likely that in the past 3 months would not work with CUDA.
I found the a successful commit on : Please note that this is not a commit from and I believe it is using CUDA 11.7
Nice! Well I guess we have a (rough) commit window now to bisect on. Btw, I'm curious: does work any better for you on master? We don't have a CUDA alias for that one, so you'll need to set
Let me try that. My understanding is that is about downloading the pre-built binary (wheel) and patch it, while is about spinning up to build the wheel by ourselves And for end users of , they should behave pretty much the same. Is my understanding correct? Thanks!
Tried . Seeing the following error:
Digged a little bit into this. On the successful branch 23.05 with CUDA 11.7: while on the failed branch 23.11, This seems to suggest that the we have in this case is not enabled for cuda support.
Yes, that's exactly right! Nice find! Huh, very weird. We're building with all the GPU/CUDA flags turned on AFAIK. Also, it's surprising to me that jaxlib-bin isn't working on your system since upstream builds that and we make only minor modifications
I checked their and found that there is a bazel flag called . Don't know what it is (maybe related to ?), but 's does not have it. I tried to add it and (more specifically, the inside it) cannot build any more. Sorry if I did not make it clear. can be successfully built on my system. The problem is similar to , as it cannot be used with CUDA. It just prompts a different error.
More on . Although it can successfully create the "client", will report not being able to find cuda drivers: This is on 23.11. The on has been upgraded to , which has the same problem of not being able to find CUDA:
Tracing the code and I realized that the problem is that this line , which in turn calls in failed for . Based on , I think the <versionhere should be . And it turns out that we already have for , which contains . Scratching my head again now ...
Yup, totally with you there. Now if jaxlib-bin didn't build successfully that'd be an easier fix... Debugging with jaxlib-bin can be convenient since it offers "known-good" binaries to work with. Hmm, ok this is where output ought to point the way. But looking through the logs you posted earlier it, I'm not able to find the string anywhere... Would you mind posting the logs for the version? OOC how did you come to conclude that <versionis the failing lookup? It's a perfectly sensible conclusion since just about every CUDA package ever has to load it, but just curious re your methodology.
Ah sorry I should have provided more information here. So my journey starts with the error: and this quickly leads to the code in tensorflow: This means that the call to failed. This particular function can be found at , which is essentially . The function is , which is basically a call to , which in turn is just a call to of the here. Reading the above functions, we can see that the offending filename is in the format of . I could not figure out the because it is actually defined , which is in turn injected from . Because I had the impression that I was using , so I believe the version here is . This turned out to be wrong, see below. Thanks a lot for the suggestion! I tried the following Which produces log: Turns out that it is actually looking for . However, it is looking for ! Below are the selected part of the above log: I then went back to check for the : , and apparently it is downloading the prebuilt binary that is tagged with . Note that points to Cuda 11.8. I might be wrong, but is prebuilt binary tagged with supposed to work with CUDA 11 as well? The logic that finds and loads the files definitely is not compatible with CUDA 11.
For as long as tf is 2.13: We should add the comment. It's possible that jaxlib and tf actually come with different version constraints, I haven't checked. I guess one then has to pass it ( specifically) . Looks like jaxlib is trying to take over a part of the dynamic linker's job instead of just using DT_NEEDED and naturally this doesn't play out smoothly. They probably wanted to defer loading or something
I am trying adding an overlay like this: Seems that is now working. I am not sure whether this will have bad implications though. Yeah they might have some reason to defer it.
There is one problem though, if I have the following overlay: is ok, but will fail to build because of test failures. See the log: Note that all the failures seem to be related to: I suspect this is jax tests that should run on CUDA but incorrectly ran on cpu - but I am not sure.
At this moment, with the help of and (Thanks!), I think I might have a solution to this. TLTR: We can now use (version 0.4.23) on , if you apply an overlay to point to . NOTE: usually you will also need alongside . It works on , but you will have to disable the unit tests and import test. See below in "what is still unclear". Detailed explanation: download a prebuilt binary, which defers loading of at runtime via dynamically. prebuilt binary is built against , meaning that will look for . , there is another check to make sure that the CUDA version is exactly (i.e. 12.1 and 12.0 will not work). , uses , which is designed for . The current needs instead of . However, if your environment does not require , just point to and everything should work out. with fixed above, I cannot build unless all the tests are disabled. It does not seem to affect the actual usage of because the test failure is specifically about not finding GPU-version of during test. This should be fixable but I am not sure how at this moment. we want to be able to use instead of to have more flexibility. The current build of seems to produce a library that does not have CUDA support. This remains a mystery and needs further investigation.
I propose that we template the "cudaXX" strings in based on the version of the inputted / instead of hardcoding. That will prevent this kind of issue in the future. It's worth noting that upstream releases builds for both cuda11 and cuda12, so we're in luck there. Unfortunately I'm of minimal use in terms of submitting PRs until is resolved. This reminds me that we should also migrate jaxlib-bin to use the redist packages at some point. Fixing the source build will be its own adventure. I suspect we're just missing some kind of flag that changed in upstream's build process.
Sounds good. Still, for the upstream releases, cuda11 = cuda 11.8, cuda12 = cuda 12.2. The minor version is still important here and should be checked. Agree. It probably requires setting a development environment and build incrementally with to investigate. Blindly update flag and build the whole package again from scratch is quite inefficient ...
Sorry but I was not able to find the build for . I saw the ones under , but not under . Are they the same?
Search for "cuda11/jaxlib-0.4.23" and you'll find them. This link seems to be outdated, or at least not actively maintained by upstream. We should prob update the comment to point to instead.
I saw you're using that with Ubuntu? Did you try nixglhost?
oooh no i hadn't heard of nixglhost before... i'll give that a shot!
With that I was able to find the one for CUDA 11 (cudnn 8.6) and it worked out with this overlay: Need some advice on how to fix on . Based on suggestion, I am thinking about the version of cuda, assert on 11.8 / 12.2 will be set to if cuda is 11.8, or if cuda is 12.2 the file based on the above version Does that make sense?
Yup, exactly what I was thinking! Though I have a sneaking suspicion that CUDA versions outside of 11.8 / 12.2 might work. Sometimes they'll attempt to and then try , and so forth. So we should try seeing if other CUDA versions work too.
Thanks! I tried 12.0 and it won't work for prebuilt binary originally built against 12.2.
Ah ok maybe not then... damn EDIT: the JAX folks claim that this ought to be possible:
I still don't understand (and haven't got around to verify myself) whether is functional, and why do we keep focusing on instead?
is not functional, which is the original report of this issue: can be built However, the built (more specifically, ), was not able to work with CUDA. It seems that the problem is is actually not "withCuda". There might be some flags to be set during bazel build, but I was not able to find the reason. We then turn to as an alternative because we need a working at this moment. Turns out that has a different issue, but is easier to fix.
I also read about that, but my experiment wasn't successful, for example, it will panic about JAX being built with but the current CUDA version is
Looking at for https://hercules- I see no mention of () Is it intentional we add to but not to the following? (again, I've no idea what I'm talking about)
Similar here, I am not that familiar with jax's bazel code. Would like to provide some information here. with CUDA 11.7 works, and at that time looks pretty much the same:
It seems that the version of cudnn is not a requirement. Binary built with 8.6 can work with 8.9 at runtime.
Well, there's definitely a bug in here somewhere. It is def possible that this is part of it. I'm guessing that upstream changed their build flags and we completed a version upgrade without realizing since we don't have a means to run GPU-enabled tests in CI/nixpkgs-review yet. is included in as a means to reduce the number of possible hashes that we have to record. The fetch is a superset of the CPU-only fetch, so we combine them for simplicity. is really handy in these situations where the source build is either broken or not on a version that the user wants. The source build is really quite unwieldy unfortunately. (Similar but not quite as bad as the tensorflow situation.)
I am working on the fix for . Not sure what is the best way to test it though. I am thinking about: the fix in a branch a that points to that branch with CUDA 11 and 12 on 3.9 through 3.12
Another approach, IMHO a little easier but totally up to you: Then you can run this for , , etc and and . That way you can run/test locally without committing changes.
The PR is created at
I am closing this as at least the version is fixed now. Thanks a lot for the help
Fixing the *-bin version is great, but let's keep this open until the source version is fixed as well
FWIW, the Guix version (there is only a source version) is here: It works fine with CUDA. The definition of the CUDA-less version that it references is here: Maybe there's an obvious difference somewhere in the arguments.
Ok I think I've found the culprit. Somewhere along the way we removed from and/or . Oops! Working on a fix now... Currently blocked on AFAICT we do not package CUB and it is not provided in any of the cudaPackages that I've consulted thus far. If anyone has any ideas on the best way to proceed, do let me know!
Pretty sure it's part of , and we also used to distribute it as part of nvidia-thrust which we deleted
Ah, thanks for the tip ! I wasn't able to find or : Perhaps it has a different attribute name? Assuming a typo, I checked nccl which is already a dependency of jaxlib, but to no avail: Perhaps I'm missing something? Btw, draft PR started here:
Oop, found , but not finding that header file sadly:
Not ""?
Adding seemed to solve the problem, despite the difference in filenames. Not sure exactly what kind of wizardry they're doing to adjust header names, but it seems happy for now.
Looking at your issue upstream, I think the names match?
Oop, yeah you're right. I was confusing that with something else
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
If you're using NixOS is there a platform wide config to always have the cuda libraries enabled?
I'm trying to compile jax using the commit , which appears to have closed this issue. When I tried to run jax on CUDA using this commit, I would need to compile jaxlib from scratch. During the compilation, I get a hash mismatch error in a library that is compiling. I even tried to use a later commit to get the following output: This is my And this is my (for the newer commit):
This seems like a support question, you're more likely to find help on NixOS Discourse or Matrix. But the answer is and this will trigger a lot of rebuilds Interesting, this might be a reproducibility issue with the way we fetch bazel dependencies, in which case this deserves a separate issue

, curl , cython , fetchFromGitHub <ins> , fetchpatch </ins> , git , IOKit , jsoncpp