Question: cp -R "usr/share" "$out/share" chmod -R g-w "$out" <del> # Wrap the startup command makeBinaryWrapper $out/opt/GoofCord/goofcord $out/bin/goofcord  </del> <ins> # use makeShellWrapper (instead of the makeBinaryWrapper provided by wrapGAppsHook3) for proper shell variable expansion # see https://github.com/NixOS/nixpkgs/issues/172583 makeShellWrapper $out/opt/GoofCord/goofcord $out/bin/goofcord  </ins> "''${gappsWrapperArgs[@]}"  --prefix XDG_DATA_DIRS : "${gtk3}/share/gsettings-schemas/${gtk3.name}/"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=UseOzonePlatform,WaylandWindowDecorations,WebRTCPipeWireCapturer}}"

ArmCord's wrapper seems unable to launch under Wayland, always chooses to launch under Steps to reproduce the behavior: sure and are properly set: Armcord: . ... 's on XWayland (as shown by ). I expect it to launch with Wayland instead of XWayland. Custom wrapper: Test case: Log output: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
probably need makeShellWrapper instead of makeBinaryWrapper in the package
Thanks for jumping on a PR will review this evening.


Question: postInstall = let includedLibs = [ "base" "contrib" "network" "prelude" ]; name = "${pname}-${version}"; <del> packagePaths = builtins.map (l: "$out/${name}/" + l) includedLibs; </del> <ins> packagePaths = builtins.map (l: "$out/${name}/${l}-${version}") includedLibs; </ins> additionalIdris2Paths = builtins.concatStringsSep ":" packagePaths; in '' # Remove existing idris2 wrapper that sets incorrect LD_LIBRARY_PATH

Describe the bug executing terminates with an error. This didn't happen with idris2 Version 0.3. To Reproduce See above and below. Expected behavior The REPL should successfully start and present its own prompt Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Could you try setting ? In particular, they should be set here:
The library paths mismatch.
Hey, your seems to be empty. :O This is what my recent install () looks like:
huh, why does it seems empty, it clearly contains stuff?
Ah sorry, I misread the columns then.
Can you compile and run execs?
suggestion:
when I manually adjust the library paths to include the version, it works:
Run with
Will apply, though I am now concerned about the different behavior in NixOS, so maybe I am getting the libs from somewhere else DX


Question: *x-nixos.autoresize*) if [ "$fsType" = ext2 -o "$fsType" = ext3 -o "$fsType" = ext4 ]; then echo "resizing $device..." <ins> e2fsck -fp "$device" </ins> resize2fs "$device" fi ;;

Rebooting a NixOS instance on ec2 does not resize the root volume even though Created one of the amazon ec2 instances: nixos-17.03.885.-x86_64-hvm-ebs Resize the ebs volume associated with the instance using the aws console. Reboot the instance. View to see that nothing has changed view Find this in the error logs: System: (Hummingbird) Nix version: nix-env (Nix) 1.11.11 Nixpkgs version: "17.03.885." Sandboxing enabled: build-use-sandbox = false


Question: ]; cmakeFlags = [ <del> "-DGLSLANG_INSTALL_DIR=${localGlslang}" "-DSPIRV_HEADERS_INSTALL_DIR=${localSpirvHeaders}" </del> <ins> "-DGLSLANG_INSTALL_DIR=${glslang}" "-DSPIRV_HEADERS_INSTALL_DIR=${spirv-headers}" </ins> "-DROBIN_HOOD_HASHING_INSTALL_DIR=${robin-hood-hashing}" "-DBUILD_LAYER_SUPPORT_FILES=ON" # Hide dev warnings that are useless for packaging

name: All packages in current version: 1.2.189.1 desired version: 1.2.200 maintainers: Please tag this issue in your PR.


Question: <del> { lib </del> <ins> { stdenv , lib </ins> , buildPythonPackage , fetchFromGitHub , isPy27

Describe the bug Tensorflow binary builds don't work on mac os. (neither do the source build, but that's a separate issue) To Reproduce $ nix-build '<nixpkgs' --show-trace -A python37Packages.tensorflow-bin_2 this derivation will be built: /nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow- building '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-'... Sourcing python-recompile-bytecode- Sourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing wheel setup hook Using wheelUnpackPhase Sourcing pip-install-hook Using pipInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook unpacking sources Executing wheelUnpackPhase Finished executing wheelUnpackPhase patching sources configuring /private/tmp/nix-build-python3.7-tensorflow- /private/tmp/nix-build-python3.7-tensorflow- Unpacking to: unpacked/tensorflow-2.1.0...OK substitute(): ERROR: file '--replace' does not exist error: --- Error
--------------------------------------------------------------------------- nix-build builder for '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-' failed with exit code 1 host os: multi-user?: sandbox: version: channels(noah): nixpkgs: yaml attribute: module:


Question: <del> { lib </del> <ins> { stdenv , lib </ins> , buildPythonPackage , fetchFromGitHub , isPy27

Describe the bug tensorflow-bin_2 wants gast-3.2.0 due to but gast has been updated to 3.3.0 so tensorflow refuses to install: To Reproduce Notify maintainers Metadata Maintainer information:
There are also other dependencies that fail the version checks: scipy==1.4.1 and tensorflow-estimator<2.2.0,=2.1.0rc0.
This compiles i'll test it, any feedback appreciated
Got some issues
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Related .
It looks like fixes this.


Question: ''; }; <del> # Allow DSA keys for now. (These were deprecated in OpenSSH 7.0.) </del> pubkeyAcceptedKeyTypes = mkOption { type = types.listOf types.str; <del> default = [ "+ssh-dss" ]; </del> <ins> default = []; </ins> example = [ "ssh-ed25519" "ssh-rsa" ]; description = '' Specifies the key types that will be used for public key authentication.

ssh-dss was deprecated in 2015. Server support was removed in 17.03. It might be time to remove them client-side, and also from examples.
cc me as openssh maintainer to look at this later
Probably fixed by update
This is still being set through the NixOS option default.


Question: # https://docs.nvidia.com/dgx/pdf/dgx-os-5-user-guide.pdf "char-nvidiactl" "char-nvidia-caps" <ins> "char-nvidia-frontend" </ins> "char-nvidia-uvm" # ROCm "char-drm"

this commit makes my NVIDIA GeForce RTX 3090 no longer visible to ollama: needs to be revisited, or add optional flag to disable hardening (which i don't really need since I dont expose ollama over internet). when running through systemd: when running :
Can you check , and try adding these strings, prefixed with to ? For me on NixOS 24.05 they show and the module currently allows the following device types:
Just upgraded to the unstable module and package and things are still looking fine. The only nvidia related config I have is
, will try later when I get back home. Not sure if related but I'm on nvidia as the newer versions are broken in one way or another (wayland/performance regressions/pytorch issues).
You can also try nuking the DevicePolicy altogether if the suggestions above do not work: = { DeviceAllow = lib.mkForce [ ]; DevicePolicy = lib.mkForce "auto"; };
was the missing piece: +
--------+ |-----------------------------------------+----------------------+----------------------+ +-----------------------------------------+----------------------+----------------------+
thanks for your support!
Feel free to send a PR to add it to the module. Thanks for looking into this!
some additional findings, nvidia device group names are definitely driver version dependent, this is what I get on 555 ( is gone):


Question: <del> { lib, pkgs, erlang }: </del> <ins> { lib, __splicedPackages, erlang }: </ins> let <ins> pkgs = __splicedPackages; </ins> inherit (lib) makeExtensible; lib' = pkgs.callPackage ./lib.nix { };

Describe the bug I need to list the out paths of cross compiled packages beforehand which causes an eval error. To Reproduce Steps to reproduce the behavior: Expected behavior List all out paths like `. Additional context I need this feature for nixpkgs-review when cross compiling. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(user): nixpkgs: Maintainer information:
I think its because of the lack of splicing for perl-packages. Note however, that when that is fixed, other package sets will fail with the same issue. cc
Probably multiple issues. Have seen that problem with building xwayland for aarch64 too. Removing makeWrapper helps but probably breaks it :(. But the deps don't cross-build anyway so never got that far for now. Was thinking about opening an issue but got caught up trying to find the issue -- to no avail. Not currently at my machine, might post it later.
I marked this as stale due to inactivity. →
still important to me
Fix in


Question: <ins> diff --git a/bin/rocprofv2 b/bin/rocprofv2 index 92f7489..8839d4d 100755 --- a/bin/rocprofv2 +++ b/bin/rocprofv2 @@ -2,7 +2,8 @@ set -eo pipefail CURRENT_DIR="$(dirname -- "$0")" ROCPROFV2_DIR=$(dirname -- $(realpath ${BASH_SOURCE[0]})) -ROCM_DIR=$(dirname -- "$ROCPROFV2_DIR") +ROCPROFILER_DIR=$(dirname -- "$ROCPROFV2_DIR") +ROCM_DIR=@rocmtoolkit_merged@ PLUGIN_LIST=("ctf" "perfetto" "file" "att") RUN_FROM_BUILD=0 if [[ $ROCPROFV2_DIR == *"/build"* ]]; then @@ -10,7 +11,7 @@ if [[ $ROCPROFV2_DIR == *"/build"* ]]; then ROCM_DIR=$ROCPROFV2_DIR fi -export ROCPROFILER_METRICS_PATH=$ROCM_DIR/libexec/rocprofiler/counters/derived_counters.xml +export ROCPROFILER_METRICS_PATH=$ROCPROFILER_DIR/libexec/rocprofiler/counters/derived_counters.xml export LD_LIBRARY_PATH=$ROCM_DIR/lib:$LD_LIBRARY_PATH usage() { @@ -70,8 +71,8 @@ while [ 1 ]; do exit 1 fi elif [[ "$1" = "--list-counters" ]]; then -    export LD_PRELOAD=$LD_PRELOAD:$ROCM_DIR/lib/rocprofiler/librocprofiler_tool.so -    eval $ROCM_DIR/libexec/rocprofiler/ctrl +    export LD_PRELOAD=$LD_PRELOAD:$ROCPROFILER_DIR/lib/rocprofiler/librocprofiler_tool.so +    eval $ROCPROFILER_DIR/libexec/rocprofiler/ctrl exit 1 elif [[ "$1" = "-i" || "$1" = "--input" ]]; then if [ $2 ] && [ -n $2 ] && [ -r $2 ]; then @@ -171,7 +172,7 @@ while [ 1 ]; do if [ $RUN_FROM_BUILD == 1 ]; then ATT_PATH=$ROCM_DIR/plugin/att/att/att.py else -        ATT_PATH=$ROCM_DIR/libexec/rocprofiler/att/att.py +        ATT_PATH=$ROCPROFILER_DIR/libexec/rocprofiler/att/att.py export ROCPROFV2_ATT_LIB_PATH=$ROCM_DIR/lib/hsa-amd-aqlprofile/librocprofv2_att.so fi ATT_ARGV=$3 @@ -236,13 +237,13 @@ if [ -n "$PMC_LINES" ] && [ ! -n "$ATT_ARGV" ]; then export OUTPUT_PATH=$FINAL_PATH fi let COUNTER=COUNTER+1 -    LD_PRELOAD=$LD_PRELOAD:$ROCM_DIR/lib/rocprofiler/librocprofiler_tool.so $* +    LD_PRELOAD=$LD_PRELOAD:$ROCPROFILER_DIR/lib/rocprofiler/librocprofiler_tool.so $* if [ -n "$OUTPUT_PATH" ]; then echo -e "nThe output path for the following counters: $OUTPUT_PATH" fi done else -  LD_PRELOAD=$LD_PRELOAD:$ROCM_DIR/lib/rocprofiler/librocprofiler_tool.so $* +  LD_PRELOAD=$LD_PRELOAD:$ROCPROFILER_DIR/lib/rocprofiler/librocprofiler_tool.so $* fi get_pmc_results_txt_path() { diff --git a/bin/rpl_run.sh b/bin/rpl_run.sh index c1a3daa..bc868a5 100755 --- a/bin/rpl_run.sh +++ b/bin/rpl_run.sh @@ -24,16 +24,17 @@ time_stamp=`date +%y%m%d_%H%M%S` BIN_DIR=$(dirname $(realpath ${BASH_SOURCE[0]})) -ROOT_DIR=$(dirname $BIN_DIR) +ROCPROFILER_DIR=$(dirname $BIN_DIR) +ROOT_DIR=@rocmtoolkit_merged@ RUN_DIR=`pwd` TMP_DIR="/tmp" DATA_DIR="rpl_data_${time_stamp}_$$" -RPL_PATH=$ROOT_DIR/lib +RPL_PATH=$ROCPROFILER_DIR/lib TLIB_PATH=$RPL_PATH/rocprofiler TTLIB_PATH=$ROOT_DIR/lib/roctracer ROCM_LIB_PATH=$ROOT_DIR/lib -PROF_BIN_DIR=$ROOT_DIR/libexec/rocprofiler +PROF_BIN_DIR=$ROCPROFILER_DIR/libexec/rocprofiler if [ -z "$ROCP_PYTHON_VERSION" ] ; then ROCP_PYTHON_VERSION=python3 @@ -73,7 +74,7 @@ export ROCP_METRICS=$TLIB_PATH/metrics.xml # Disable AQL-profile read API export AQLPROFILE_READ_API=0 # ROC Profiler package path -export ROCP_PACKAGE_DIR=$ROOT_DIR +export ROCP_PACKAGE_DIR=$ROCPROFILER_DIR # enabled SPM KFD mode export ROCP_SPM_KFD_MODE=1 @@ -350,7 +351,7 @@ convert_time_val() { ################################################################################################ # main -echo "RPL: on '$time_stamp' from '$ROOT_DIR' in '$RUN_DIR'" +echo "RPL: on '$time_stamp' from '$ROCPROFILER_DIR' in '$RUN_DIR'" # Parsing arguments if [ -z "$1" ] ; then usage @@ -557,7 +558,7 @@ elif [ "$input_type" = "txt" -o "$input_type" = "none" ] ; then else echo "<metric></metric>" > $RES_DIR/input.xml fi -  input_list=`/bin/ls $RES_DIR/input*.xml` +  input_list=`ls $RES_DIR/input*.xml` export ROCPROFILER_SESS=$RES_DIR else fatal "Bad input file type '$INPUT_FILE'" </ins>

When trying to use rocprofv2: This might have something to do with some predefined paths in Steps to reproduce the behavior: an executable with hipcc it with rocprofv2 <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I need to do some work with . need to make a patch that strips. I need to fix itself. I wonder if it's because I'm stripping out the test directories? Also yes, it looks like you're right. You can fix that by prepending too, so I'm not entirely sure it'll work. Try setting `. You may just be able to run it from that as well.
I don't think that removing hsa-amd-aqlprofile-bin is a good idea, because without it, it loses performance counters support. I think there should at least be a rocprof derivation with aqlprofile.
My bad, I forgot to add that the patch is optional.
Right. Could you tell me your test environment and the source of the hip executable (or just some stub) so I can replicate this? I've never actually used rocprofiler.
You can try this, it just prints 10 numbers, it can be compiled with hipcc without any flag. I am using a radeon rx6600m(gfx1032).
see


Question: , stdenv , fetchFromGitHub , rocmUpdateScript <ins> , symlinkJoin , substituteAll </ins> , cmake , clang , clr <ins> , rocm-core </ins> , rocm-thunk <ins> , rocm-device-libs </ins> , roctracer <ins> , rocdbgapi </ins> , rocm-smi , hsa-amd-aqlprofile-bin , numactl


Question: license = licenses.unfreeRedistributable; maintainers = with maintainers; [ MP2E ]; platforms = platforms.linux; <ins> broken = kernel.kernelOlder "3.2.0"; </ins> }; }

I'm trying to use the mwprocapture nixos module (which uses the mwprocapture kernel package) on 20.09 (linuxPackageslatest), and I get the following: Is this known and/or already fixed somewhere? (Also, is it safe to use it anyways?) I'd love to try and fix it further myself, but I don't know how to splice in a local/development nix file into my for development purposes :sweatsmile: (also CC
Looks like upgrading the package version resolved things. Will create a PR soon.
Thanks for the heads up.


Question: forgejo = handleTest ./forgejo.nix { }; freenet = handleTest ./freenet.nix {}; freeswitch = handleTest ./freeswitch.nix {}; <ins> freetube = discoverTests (import ./freetube.nix); </ins> freshrss-sqlite = handleTest ./freshrss-sqlite.nix {}; freshrss-pgsql = handleTest ./freshrss-pgsql.nix {}; frigate = handleTest ./frigate.nix {};

Steps to reproduce the behavior: system configuration with Freetube in it. See and for the exact same issue with Morgen. Electron version lock seems to have been introduced with . Upstream seems to be at Electron 27: . and
Maybe we could add the patches from It looks like they were waiting for a nixos user to test it and eventually gave up on us.
are you able to test ?
Looks good as far as I can tell.
fails on this branch, for whatever reason.


Question: "-DMZ_OPENSSL=ON" "-DMZ_BUILD_TESTS=${if finalAttrs.doCheck then "ON" else "OFF"}" "-DMZ_BUILD_UNIT_TESTS=${if finalAttrs.doCheck then "ON" else "OFF"}" <ins> "-DMZ_LIB_SUFFIX='-ng'" </ins> ] ++ lib.optionals stdenv.isDarwin [ # missing header file "-DMZ_LIBCOMP=OFF"

branch to nixos-unstable to your with
Bisect has identified (specifically ) as the source of this failure in nixpkgs, cc See also upstream issue
If you're using a flake, this is how I was able to mitigate this until it's fixed. I rolled back the changes from in a branch on my fork, and used it as an overlay for the affected packages like this: This is how you would add them to your overlay: Ofc, depending on how you do stuff, you'll have to fiddle with it a bit to get it to work. I found this helpful:
The fix is now on the nixos-unstable branch, but I still cannot build my system after updating, with the same build failure for opencolorio. Is this expected?
Probably not, since and both build on Hydra.
Oh thank you, this is very bizarre. I will ask on the forum what's going on
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Question: homepage = "https://github.com/electron/electron"; license = licenses.mit; maintainers = with maintainers; [ travisbhartwell manveru prusnak ]; <del> platforms = [ "x86_64-darwin" "x86_64-linux" "i686-linux" "armv7l-linux" "aarch64-linux" ] ++ optionals (versionAtLeast version "11.0.0") [ "aarch64-darwin" ]; </del> <ins> platforms = [ "x86_64-darwin" "x86_64-linux" "armv7l-linux" "aarch64-linux" ] ++ optionals (versionAtLeast version "11.0.0") [ "aarch64-darwin" ] ++ optionals (versionOlder version "19.0.0") [ "i686-linux" ]; </ins> sourceProvenance = with sourceTypes; [ binaryNativeCode ]; knownVulnerabilities = optional (versionOlder version "15.0.0") "Electron version ${version} is EOL"; };

Element v1.11.0 updated to Electron 19, so we need this packaged in Nixpkgs: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 18.1.0 desired version: 19.0.7 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
When I run the script tries to download which does not exist. Do you know where to get the electron headers?
PR that brings electron19 but does not provide electron19 headers:
I believe that states that they migrated storage. So, I think the new url would be
Great find, thanks! Updated PR to include this change and electron_19 now provides the headers.
electrum_19 to master via - feel free to update your package


Question: // Insist on using IPC for communicating with Tor // <del> // Defaults to creating $TBB_HOME/TorBrowser/Data/Tor/{socks,control}.socket </del> <ins> // Defaults to creating $XDG_RUNTIME_DIR/Tor/{socks,control}.socket </ins> lockPref("extensions.torlauncher.control_port_use_ipc", true); lockPref("extensions.torlauncher.socks_port_use_ipc", true);

When you try to connect to the Tor network using the Tor browser you get the error message ! When you try to visit a website after being shown the big red error message your get the error message ! This problem appeared between one and two weeks ago. ; can't find an existing Nixpkgs issue. Steps to reproduce the behavior: the Tor browser from Nixpkgs the Tor browser on error message to go to a website When clicking on the browser should connect to the Tor network and be able to browse. The . browsers says that it can detect my internet connection. ! Tor logs doesn't seem to indicate any problems (from what I can interpret) I live in Sweden and this issue has appeared both when I've connected to the internet using my home connection (Sunet) and when I've connected over a VPN. I.e. no fuckery by an oppressive government. The timeline match up-ish with when would have become available in the binary caches. Unsure if the error appeared before or after updating around that time. After checking the original PR I see that this problem was noticed, but a workaround was applied. Doesn't seem to work for me :-/ The value is for me. I'm using root on tmpfs, and nothing under is persistently saved between boots. ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- and because you seem to have actually researched the problem. The system is fully up-to-date as of 2023-03-05 22:15 CEST.
The red error message indicates that Tor cannot find the tor socket. Everything else is bound to not work unless it goes over the normal internet. Please see and for the underlying problem and please check if the firefox setting points to the right socket file.
I tested to set to , but that didn't help.
Setting to also doesn't work.
Just to avoid ambiguities, did you set to (with file name part)? TBB is still working fine for me with the workaround. Likewise for me, is a tmpfs. Have you modified (and forgotten about it) your torrc, e.g. to use a different control port/mechanism? What is your XDGSESSIONTYPE?


Question: // Insist on using IPC for communicating with Tor // <del> // Defaults to creating $TBB_HOME/TorBrowser/Data/Tor/{socks,control}.socket </del> <ins> // Defaults to creating $XDG_RUNTIME_DIR/Tor/{socks,control}.socket </ins> lockPref("extensions.torlauncher.control_port_use_ipc", true); lockPref("extensions.torlauncher.socks_port_use_ipc", true);

The person on uses wayland (with sway). I currently still use x11 (with i3) and haven't tested it with wayland.
That did it! I missed that you should specify the file in the path. I'm using AwesomeWM.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The person on had the same problem and the same solution :-)
Why did you close this issue You can't seriously think that this temporary workaround is an acceptable permanent solution to this problem? While we still don't have a permanent solution, it should be as easy as possible for users to find information about this workaround. By closing this issue we signal to people that this problem has been solved. And people currently experiencing this problem on a fully up-to-date system will probably not think about looking into closed issues, because the issue is still there.
I am also experiencing this issue. The fix worked for me.
Confirmed. The issue is still present. Default installed value of is 127.0.0.1. Changing it to resolves the problem.
This issue only started happening on my machine after deleting today.
Still an issue. I'm using TBB with firejail and I have to apply the workaround at every restart. TBB creates the folder but not a profile inside (this wouldn't be a problem for me if connection works out of the box). about:config - = tor-browser-bundle-bin 12.0.5 firejail-0.9.72 nixos-unstable
By default, the service runs on port 9050 and the control port on 9051. This is configured in the torrc file: Your firewall may be blocking some of these ports bound by default to localhost which normally point to 127.0.0.1
The PR for Tor Browser 13 removes the current workaround again, because it seems the issue was fixed upstream: I would be grateful if some of you could give this a try and report if it's still working (or working again).


Question: cde-gtk-theme = throw "cde-gtk-theme has been removed from nixpkgs as it shipped with python2 scripts that didn't work anymore"; # Added 2022-01-12 cgmanager = throw "cgmanager was deprecated by lxc and therefore removed from nixpkgs"; # Added 2020-06-05 checkbashism = throw "'checkbashism' has been renamed to/replaced by 'checkbashisms'"; # Converted to throw 2022-02-22 <ins> chefdk = throw "chefdk has been removed due to being deprecated upstream by Chef Workstation"; # Added 2023-03-22 </ins> chrome-gnome-shell = gnome-browser-connector; # Added 2022-07-27 chronos = throw "chronos has been removed from nixpkgs, as it was unmaintained"; # Added 2020-08-15 chunkwm = throw "chunkwm has been removed: abandoned by upstream"; # Added 2022-01-07

ChefDK is deprecated and no longer maintained by Chef. This package is currently maintained by and I believe ChefDK should be dropped and replaced by Chef Workstation (see issue ). This has been deprecated since 2021.


Question: installPhase = '' mkdir -p $out/bin <del> cp git-open $out/bin </del> <ins> mv git-open $out/bin </ins> installManPage git-open.1 wrapProgram $out/bin/git-open  <del> --prefix PATH : "${lib.makeBinPath [ git gnugrep ]}"  </del> <ins> --prefix PATH : "${lib.makeBinPath [ gnugrep ]}"  </ins> --suffix PATH : "${lib.makeBinPath [ xdg-utils ]}" '';

Package name: git-open Latest released version: 3.0.0 <!-- Search your package here: --- Current version on the unstable channel: 2.1.0 Current version on the stable/release channel: 2.1.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.
The latest version of listed on the project's is (Dec 3, 2018), however was released on the project's (Jul 18, 2022).


Question: defaultBuildInputs = extraBuildInputs; <ins> stdenv = (stdenv-overridable argsStdenv); </ins> # The stdenv that we are producing. <del> stdenv = </del> <ins> in </ins> derivation ( lib.optionalAttrs (allowedRequisites != null) { allowedRequisites = allowedRequisites

I tried to build a package with debug symbols today and failed. NixOS wiki and nixpkgs repository comments say the following should work: Please run and paste the result.
It worked in Aug 2018: Bisected down to breakage at : Looks like it stems from the fact that does not expose anymore, only . /cc
Woah. master and both work for me with nix stable.
That's surprising. Here is my attempt at current master checkout: I tried removing and seeing the same failure. I wonder why it works for you. Might be a different stdenv?
Does it mean and are the same object?
i can reproduce
I can also reproduce with stable Nix (2.3.14):
Hmm, the issue is that / slaps the on after is defined, closing over the old . In Smalltalk paralance, this would be an issue of insufficiently "late binding".
Still reproducible on current master ()
I ran into this.
Bump, ran into this while updating the Nixpkgs pin on a project of mine.
There should be a test for this :)
Gonna spend next hour or two trying to fix this.
Things that are also missing:
So, this function is not executed on passed through stdenv. Not yet sure why.
Yeah, I've fixed it (thanks, for being there :heart:)
Post-mortem: always read threads. Solution was kinda already provided in , but I delved right in without knowing that)
atleast you now know more about stdenv :slightlysmilingface:
How is the PR looking? I've been waiting on this for a couple of weeks to debug an intermittent crash I'm having with xfce4-sesion :)


Question: ++ optionals (versionAtLeast version "11.0.0") [ "aarch64-darwin" ] ++ optionals (versionOlder version "19.0.0") [ "i686-linux" ]; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; <del> knownVulnerabilities = optional (versionOlder version "15.0.0") "Electron version ${version} is EOL"; </del> <ins> knownVulnerabilities = optional (versionOlder version "18.0.0") "Electron version ${version} is EOL"; </ins> }; fetcher = vers: tag: hash: fetchurl {

Electron is a security-critical component for several desktop applications and we shouldn't be keeping EOL versions around. Please remove all versions older than 18 if possible. The latest version is 21. via cc
There are at least 14 packages that require Electron < 18, should we drop them as well? Isn't it better to just mark Electron < 18 packages as insecure via ?
That is a start, ideally we could move those packages off older Electron versions, but I don't know how feasible that is.


Question: # TODO(@Ericson2314): Build bionic libc from source bionic = if stdenv.hostPlatform.useAndroidPrebuilt <del> then pkgs."androidndkPkgs_${stdenv.hostPlatform.androidNdkVer}".libraries </del> <ins> then pkgs."androidndkPkgs_${stdenv.hostPlatform.androidNdkVersion}".libraries </ins> else callPackage ../os-specific/linux/bionic-prebuilt { }; boolstuff = callPackage ../development/libraries/boolstuff { };

Steps to reproduce the behavior: to build (required by ) fail Full trace (libxml2): Doesn't happen on , before I have no idea if this happens on any other platforms, needs triage. I also have no idea why python for linux needs something darwin?!? This also breaks the evaluation of , but not Python team <!-- You know a bunch about splicing --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: buildPythonPackage rec { pname = "pex"; <del> version = "2.1.137"; </del> <ins> version = "2.1.141"; </ins> format = "flit"; disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; <del> hash = "sha256-ywzmz2R1fdW6TzTEYHq0hfeQnmwkzUecoozlIgXw7es="; </del> <ins> hash = "sha256-EsIurZNgWslUciz5Pc2hj2F4tAJ8hQydRWnVIWdryDc="; </ins> }; nativeBuildInputs = [

fails to run most basic commands when installed via nix, due to an error seemingly related to it's vendoring of some dependencies. On a NixOS machine or Darwin with Nix installed, run: <details<summaryPEXVERBOSE=9 nix shell -c pex</summary</detailsA pex-managed python repl should open, same behavior as in a venv. For comparision: <details<summarynix shell nixpkgs#python3 -c sh -c "python -m venv ./venv; ./venv/bin/pip install pex; ./venv/bin/pex"</summary</detailsthe site-packages path where pex lies is in the /nix/store, so read-only. however, the the vendored dependencies are included in the closure; exists and includes attrs, pip, etc. maybe could help us interpret the error and/or how to debug this efficiently? :) some simple commands such as do work. same commands run fine in a venv on the same machines using the same python intepreter. same symptoms on NixOS and when installed via nixpkgs unstable on darwin. the tempdir path mentioned in the error message is writeable, but non existent or cleaned up. the alternative script/entrypoint shows similar symptoms: <details<summaryPEX_VERBOSE=9 nix shell -c pex3 lock create requests</summary</detailsHope you don't mind the pings (maintainer) (done multiple recent updates) (pex developer)
NixOS is pretty exotic in my world. Can you confirm that I can use a container to emulate this? I assume I can, but just to check. I'll be back at a keyboard August 3rd to repro, but I expect the workaround for now is to set PEX_ROOT somewhere writable. Pex does try to detect the default is unwritable and fall back to tmp, but perhaps all these measures are foiled in this environment.
wow, that was fast! :) Should be able to emulate in a container or almost anywhere you can get a recent nix with flakes enabled running. Let me know if can assist you with that!


Question: buildPythonPackage rec { pname = "pex"; <del> version = "2.1.137"; </del> <ins> version = "2.1.141"; </ins> format = "flit"; disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; <del> hash = "sha256-ywzmz2R1fdW6TzTEYHq0hfeQnmwkzUecoozlIgXw7es="; </del> <ins> hash = "sha256-EsIurZNgWslUciz5Pc2hj2F4tAJ8hQydRWnVIWdryDc="; </ins> }; nativeBuildInputs = [

(contact info in profile) Many environment variables like and are different when run via nix (symlinks to /nix/store), but "~/" and other filesystems are not namespaced or sandboxed in any way here. is writable by my user. I've tried with PEXROOT set, but that didn't incfluence the output. Going to have another look tomorrow, but it's quite late already here in CEST.
I don't think notifications are sent for linked issues; think I found a fix in Thanks to for pointing me into the right direction
Ok, this works perfectly fine in nixos (N.B.: I 1st used the vanilla image which is not sandboxed and everything worked fine; so I went through a bit of extra effort below to enable sandboxing in the image and prove it out to see if the sandboxing behavior was relevant to repro): So I'll try to repro using .
Ok, after following the multi-user install instructions for the command here: and enabling flakes, etc - I do repro: So, for someone with knowledge of nixos vs nix shell vs flakes, this would presumably mean something. I'll continue to dig in my shell to see what's up.
Alright, Pex 2.1.141 should fix. Please let me know either way
Sandboxed builds do not work inside Docker as we can't create required namespaces from an unprivileged container.
I've tested a build against your tag and that works just fine on NixOS (with sandboxing enabled).
Ok, great. I used in addition to mounting in that custom nix config.


Question: python2Full = python2.override{x11Support=true;}; python27Full = python27.override{x11Support=true;}; python3Full = python3.override{x11Support=true;}; <del> python35Full = python35.override{x11Support=true;}; </del> python36Full = python36.override{x11Support=true;}; python37Full = python37.override{x11Support=true;}; python38Full = python38.override{x11Support=true;};

According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.


Question: <ins> { stdenv , lib , fetchFromGitHub , pkg-config , autoreconfHook , autoconf-archive , guile , texinfo , rofi }: stdenv.mkDerivation rec { pname = "pinentry-rofi"; version = "2.0.3"; src = fetchFromGitHub { owner = "plattfot"; repo = pname; rev = version; sha256 = "sha256-EzbeMAhdn9SuSmE+aMHeyuje3s74isIKRDTrFO3bX04="; }; nativeBuildInputs = [ autoconf-archive autoreconfHook pkg-config texinfo ]; buildInputs = [ guile ]; propagatedBuildInputs = [ rofi ]; meta = with lib; { description = "Rofi frontend to pinentry"; homepage = "https://github.com/plattfot/pinentry-rofi"; license = licenses.gpl3Plus; platforms = platforms.unix; maintainers = with maintainers; [ seqizz ]; }; } </ins>

Project description It's a pinentry app, using rofi. I , but failed with (pls ignore metadata on that derivation, was testing): Metadata homepage URL: source URL: license: gpl-3+ platforms: linux
I just gave it try and quickly hacked together the following (based on ): Please feel free to use this as a base for a pr.


Question: owner = "OctoPrint"; repo = "OctoPrint"; rev = version; <del> hash = "sha256-SYN/BrcukHMDwk70XGu/pO45fSPr/KOEyd4wxtz2Fo0="; </del> <ins> hash = "sha256-71uE8JvcS++xH8WSVWj5x0+9s3XIwf3A64c6YtxpSRc="; </ins> }; propagatedBuildInputs = with self; [

Steps to reproduce the behavior: also yields the "got" hash. The hash was last changed in nixpkgs @
we just hit the same issue in Alpine - it looks like the upstream uses format specifiers for that change depending on the state of the repo: (found by [here][1]) in your case it might help to do instead ( provided that doesn't just do on the remote URL, but fetches the repo in some other way ): [1]:
thanks for the new upstream issue and the infos!


Question: LDFLAGS = "-Wl,-rpath,${placeholder "out"}/lib/${binaryName}"; }; <ins> # workaround for clang statically linking against libstdc++ NIX_LDFLAGS = lib.optionals stdenv.cc.isGNU [ "-L${stdenv.cc.cc.lib}/lib" ]; </ins> # tests were disabled in configureFlags doCheck = false;

After the recent update of nixos-23.05 from to (which included , updating Firefox from 119.0.1 to 120.0) Firefox started crashing, apparently when WebGL gets used. Steps to reproduce the behavior: 120.0 with a clean profile. a crash. Some crash reports: https://crash- https://crash- These crash reports point to , which shows a matching backtrace: The underlying problem might be somewhat different though, because the offending option is not present in any Hydra build logs ( is present though). system: host os: multi-user?: sandbox: version: nixpkgs:
You can disable WebGL temporarily while the bug is being fixed. about:config webgl.disabled set to true
also works without crashing even with WebGL enabled.
Hydra build log: This is the same root cause as described in (originally for Ubuntu Firefox Beta PPA for 18.04 LTS). This is caused by building in such a way that and (and ) embed and export their own version of the code from libstdc++ (in particular ) instead of using dynamic linking to call into the code that is exported by . It is unsafe to do that because of the flag that is used to compile these binaries, and starting with Firefox 120 that results in a WebGL crash. For the Ubuntu Firefox Beta PPA this was caused by compiling with but we do not understand why this situation occurs for the NixOS 23.05 build at the moment. But it does occur (see screenshot below). <img width="399" alt="Commands showing that indeed firefox, and all export std::locale::Sinitialize with this build" src=""If someone knows how to ensure that and (and ) do not embed and export code for , that should fix the crash (we should not see a for when using on these binaries, in fact we should not see it at all because this function is internal to the implementation).
Also apparently the problem is specific to the branch:
Comparing the “good” build log () with the “bad” one () shows the difference in clang versions (and the extra option for the build, which uses clang-15): And the difference is indeed in the compiler behavior.


Question: LDFLAGS = "-Wl,-rpath,${placeholder "out"}/lib/${binaryName}"; }; <ins> # workaround for clang statically linking against libstdc++ NIX_LDFLAGS = lib.optionals stdenv.cc.isGNU [ "-L${stdenv.cc.cc.lib}/lib" ]; </ins> # tests were disabled in configureFlags doCheck = false;

Using the test file from the Mozilla bug report: With the new compiler from : With the old compiler from : Apparently the important difference here is that the compiler from passes the option to , and the directory contains , therefore the linker uses the definitions from the shared library as intended. However, the compiler from passes the option, which refers to a nonexistent directory ( actually exists, and there is the symlink, but these directories are not mentioned in the parameters), therefore the linker does not see and uses only from , so the resulting shared library contains copies of all libstdc++ functions, which breaks things when is also specified. So apparently the real problem is that in the branch uses wrong library paths for the GCC libraries.
I'm currently building with the following patch, thanks to trofi. This approach fails, as it overrwrites all previously accumulated flags. This was apparently fixed on master in
This will most likely be resolved through , but I'm still testing a solution that would be more localized to firefox and thus arrive quicker.
The workaround is part of the latest release-23.05 evaluation. You can follow its progress here:


Question: { stdenv, fetchurl, libgpgerror, gnupg, pkgconfig, glib, pth, libassuan , file, which, ncurses <del> , autoreconfHook </del> <ins> , autoreconfHook, fetchpatch </ins> , git , texinfo , qtbase ? null

(this is a qt specific test): Loc: [t-(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 1047ms This seems to affect master too, but for some reason it's been built successfully once. The aarch64 build started failing when updating qt5 from 5.11 to 5.12 making it the likely root cause: Edit: the cause was expired testing keys: cc maintainer cc as you've been active in keeping plasma/kde up to date lately. ping staging next:
Did you found ? Sounds very similar and should be fixed...
No didn't find that, but yeah, that sure looks exactly like the same issue. I'm guessing the qt issue were never actually fixed: Blame on the test gives no change at least:
And applying the suggested patch does fix the test: diff +++ gpgme-1.10.0/lang/qt/tests/t- -455,7 +455,7 private Q_SLOTS: QVERIFY(result.numSignatures() == 1); auto sig = result.signatures()[0]; QVERIFY(sig.validity() == Signature::Marginal); QVERIFY(sig.validity() == Signature::Marginal sig.validity() == Signature::Unknown); auto stats = ().userID(0).tofuInfo(); QVERIFY(!stats.isNull());
So, what are we want to do? Do you maybe want to comment on the upstream issue?
Hmm, strange, I'm getting the same failure on master (using ), forcing single core does not fix the problem though, so probably not a race condition. I've reported the failure as you suggested:
The cause is most likely qt 5.11 to 5.12 upgrade, as the aarch64 build started failing the test then:
So the keys used in this test expired on 2019-01-06, which explains why we suddenly saw this without any apparent reason. :
Thanks for fixing this and sorry for my late reply... (Edit: And of course also thanks


Question: <del> { lib </del> <ins> { stdenv , lib </ins> , buildPythonPackage , fetchpatch , fetchPypi

Describe the bug Tensorflow binary builds don't work on mac os. (neither do the source build, but that's a separate issue) To Reproduce $ nix-build '<nixpkgs' --show-trace -A python37Packages.tensorflow-bin_2 this derivation will be built: /nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow- building '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-'... Sourcing python-recompile-bytecode- Sourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing wheel setup hook Using wheelUnpackPhase Sourcing pip-install-hook Using pipInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook unpacking sources Executing wheelUnpackPhase Finished executing wheelUnpackPhase patching sources configuring /private/tmp/nix-build-python3.7-tensorflow- /private/tmp/nix-build-python3.7-tensorflow- Unpacking to: unpacked/tensorflow-2.1.0...OK substitute(): ERROR: file '--replace' does not exist error: --- Error
--------------------------------------------------------------------------- nix-build builder for '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-' failed with exit code 1 host os: multi-user?: sandbox: version: channels(noah): nixpkgs: yaml attribute: module:


Question: <del> { lib </del> <ins> { stdenv , lib </ins> , buildPythonPackage , fetchpatch , fetchPypi

Describe the bug tensorflow-bin_2 wants gast-3.2.0 due to but gast has been updated to 3.3.0 so tensorflow refuses to install: To Reproduce Notify maintainers Metadata Maintainer information:
There are also other dependencies that fail the version checks: scipy==1.4.1 and tensorflow-estimator<2.2.0,=2.1.0rc0.
This compiles i'll test it, any feedback appreciated
Got some issues
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Related .
It looks like fixes this.


Question: gsound gtk3 json-glib <del> libsoup </del> <ins> libsoup # referenced in js/ui/environment.js </ins> libstartup_notification libXtst libXdamage

I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.


Question: gsound gtk3 json-glib <del> libsoup </del> <ins> libsoup # referenced in js/ui/environment.js </ins> libstartup_notification libXtst libXdamage

I have user-installed Cinnamon applets, desklets, extensions, themes, which have been installed in the home folder by a different OS (as far as i remember). Many of them work under NixOS (some do not: ). However, i cannot update them. When i try, i get the message: The same happens if i try to install a new applet. Steps to reproduce the behavior: up Cinnamon desktop on NixOS and log in. to install an applet. Should be able to install and update user-installed applets, desklets, extensions, themes. ! I am just beginning to switch over to Cinnamon from GNOME 3 (having been fed up with GNOME, especially under NixOS).
Installing [][gettext] that provided solved the issue. Shouldn't be a dependency of Cinnamon desktop then? [gettext]:


Question: with stdenv.lib; stdenv.mkDerivation rec { <del> name = "corosync-2.4.3"; </del> <ins> pname = "corosync"; version = "2.4.5"; </ins> src = fetchurl { <del> url = "http://build.clusterlabs.org/corosync/releases/${name}.tar.gz"; sha256 = "15y5la04qn2lh1gabyifygzpa4dx3ndk5yhmaf7azxyjx0if9rxi"; </del> <ins> url = "http://build.clusterlabs.org/corosync/releases/${pname}-${version}.tar.gz"; sha256 = "0pxs18vci9kq3qnqsg5i1h35jrxxiccwbm0mzja3g8j3izdsyvmb"; </ins> }; nativeBuildInputs = [ makeWrapper pkgconfig ];

, CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
merged
Need to keep open for 20.09
Merged to 20.09 too. Closing.


Question: viw = callPackage ../applications/editors/viw { }; <ins> virter = callPackage ../applications/virtualization/virter { }; </ins> virt-viewer = callPackage ../applications/virtualization/virt-viewer { }; virt-top = callPackage ../applications/virtualization/virt-top { };

Project description Virter is a command line tool for simple creation and cloning of virtual machines based on libvirt Metadata homepage URL: source URL: Blogs: , license: Apache v2 platforms: Linux only written in: go Thanks a ton!


Question: iperf3 = callPackage ../tools/networking/iperf/3.nix { }; iperf = iperf3; <ins> ipfetch = callPackage ../tools/networking/ipfetch { }; </ins> ipfs = callPackage ../applications/networking/ipfs { buildGoModule = buildGo116Module; };

Project description Neofetch like tool that can lookup IPs. :earth_americas: Metadata homepage URL: source URL: license: gpl3 platforms: posix shell
I'll do this myself.


Question: dotnet-sdk_7 = dotnetCorePackages.sdk_7_0; dotnet-runtime_3 = dotnetCorePackages.runtime_3_1; <del> dotnet-runtime_5 = dotnetCorePackages.runtime_5_0; </del> dotnet-runtime_6 = dotnetCorePackages.runtime_6_0; dotnet-runtime_7 = dotnetCorePackages.runtime_7_0; dotnet-aspnetcore_3 = dotnetCorePackages.aspnetcore_3_1; <del> dotnet-aspnetcore_5 = dotnetCorePackages.aspnetcore_5_0; </del> dotnet-aspnetcore_6 = dotnetCorePackages.aspnetcore_6_0; dotnet-aspnetcore_7 = dotnetCorePackages.aspnetcore_7_0;

Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)


Question: environment.etc = mapAttrsToList (n: v: makePAMService v) config.security.pam.services; <del> systemd.tmpfiles.rules = optionals (any (s: s.updateWtmp) (attrValues config.security.pam.services)) [ "f /var/log/wtmp" "f /var/log/lastlog" ]; </del> security.pam.services = { other.text = ''

Describe the bug /dev/fuse isn't user read/writable To Reproduce Expected behavior Additional context I've been testing with and : Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
After further testing, I found that reverting fixes the issue. I'm guessing that this new file needs to be installed somewhere. CCing maintainers of systemd:
There are even more tmpfiles configs that we're not using. I'll check what applies to us and prepare a PR.
It would be cool if there was a test for the permissions.
I have the same issue with /dev/fuse for can't mount remote sshfs as user only as root la /dev/fuse 10.6s crw------- 1 root root 10, 229 Sep 23 14:36 /dev/fuse ~sshfs user ~/sshfs/ fuse: failed to open /dev/fuse: Permission denied Any fix we can expect soon?
Seems permissions is associated with systemd /etc/static/systemd/system/kmod-static-nodes.service
apparently that broke permissions for me, which are needed for
Strangely, on my 19.09 system does have 666 permission, despite containing a line .
I think the permission is automatically set to 666 by udev rules when the fuse module is loaded.
In my system on 19.09pre channel I have this issue manifesting in kbfsmount failing with a permission error. crw------- 1 root root 10, 229 Sep 23 21:48 /dev/fuse


Question: export PERLPATH ''; <del> configureFlags = [ "--sysconfdir=/etc" "--localstatedir=/var" "--with-openldap" "--with-db" "--with-db-inc=${db.dev}/include" "--with-db-lib=${db.out}/lib" "--with-sasl=${cyrus_sasl.dev}" "--with-netsnmp=yes" "--with-netsnmp-inc=${lib.getDev net-snmp}/include" "--with-netsnmp-lib=${lib.getLib net-snmp}/lib" ]; </del> <ins> configureFlags = let mkEnable = cond: name: if cond then "--enable-${name}" else "--disable-${name}"; in [ "--enable-cmocka" "--localstatedir=/var" "--sysconfdir=/etc" "--with-db-inc=${db.dev}/include" "--with-db-lib=${db.out}/lib" "--with-db=yes" "--with-netsnmp-inc=${lib.getDev net-snmp}/include" "--with-netsnmp-lib=${lib.getLib net-snmp}/lib" "--with-netsnmp=yes" "--with-openldap" "${mkEnable enableCockpit "cockpit"}" "${mkEnable enablePamPassthru "pam-passthru"}" "${mkEnable enableDna "dna"}" "${mkEnable enableLdapi "ldapi"}" "${mkEnable enableAutobind "autobind"}" "${mkEnable enableAutoDnSuffix "auto-dn-suffix"}" "${mkEnable enableBitwise "bitwise"}" "${mkEnable enableAcctPolicy "acctpolicy"}" "${mkEnable enablePosixWinsync "posix-winsync"}" ]; </ins> enableParallelBuilding = true; <ins> doCheck = true; </ins> installFlags = [ "sysconfdir=${placeholder "out"}/etc" "localstatedir=${placeholder "TMPDIR"}"

Project description Upgrade 389-ds-base Apparenty its new 1.4.4.4 release is a bit different. Metadata homepage URL: source URL:
I marked this as stale due to inactivity. →


Question: <del> { stdenv, fetchurl, autoconf, vala_0_32, pkgconfig, glib, gobjectIntrospection, gnome3 }: </del> <ins> { stdenv, fetchurl, autoconf, vala, pkgconfig, glib, gobjectIntrospection, gnome3 }: </ins> let <del> ver_maj = "0.18"; </del> <ins> ver_maj = "0.20"; </ins> ver_min = "0"; in stdenv.mkDerivation rec {

Geary and are . I suppose updating might remove its dependency on the insecure . (I think i remember having seen somewhere in an issue tracker that this dependency was removed in Geary source code, but i cannot find now where i saw it.)
By the way, I do not really understand these GTK and WebKitGTK issues and versions, but, just for reference, there is an open issue about previous versions of Geary using GTK2 instead of GTK3: .
In Geary 0.12 there are some fresh bugs (for example, ). It looks like version 0.12.1 is in the beginning of November.
Running shows gtk2 as a transitive dependency from webkitgtk (which depends on both GTK 2 and GTK 3) and gnome-themes-standard. I do not think the latter is necessary for GTK 3 applications since Adwaita is built into GTK 3.


Question: --offline ) <del> local -r tmpDir="$(mktemp -d yarnInstallHook.XXXXXX)" </del> <ins> local -r tmpDir="$(mktemp -d)" </ins> # yarn pack does not work at all with bundleDependencies. # Since we are imediately unpacking, we can just remove them from package.json

is currently using this command creates the temporary directory inside the current working directory instead of in . This can cause the generated directory to be included in the final package, as I'm assuming accidentally picked it up. I encountered this while working on and The temporary directory is not included in the output use use (output is of the format ) note: this isn't really used across nixpkgs use something else <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: { lib, stdenv, fetchFromGitHub, cmake, makeWrapper, perlPackages, <del> libminc, EBTKS }: </del> <ins> libminc, ebtks }: </ins> stdenv.mkDerivation rec { pname = "N3";

For x8664-darwin, aarch64-darwin: build .#EBTKS x8664-darwin: aarch64-darwin:


Question: propagatedBuildInputs = [ ncurses zlib ]; <ins> patches = [ # Force a test to evaluate the saved benchmark for a CPU for which LLVM has # an execution model. See NixOS/nixpkgs#119673. ../../exegesis-force-bdver2.patch ]; </ins> postPatch = optionalString stdenv.isDarwin '' substituteInPlace cmake/modules/AddLLVM.cmake  --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"

Describe the bug wendy, one of the big-parallel build hosts used by , cannot successfully build This blocks advancing nixos-unstable. To Reproduce Steps to reproduce the behavior: wendy to build Observe :( or, more realistically: the attached CMOV16rm-, and run (a reduced commandline that produces the same assertion failure is ) Expected behavior A clear and concise description of what you expected to happen. Additional context The assertion that's tripped by this YAML file is: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
is the CMOV16rm- (can't upload it here because it's not a supported GitHub filetype, apparently). To be more precise, the test that is failing is this one:
This has primarily become apparent because the configuration was changed in NixOS/nixos-org-configurations to make wendy only build big-parallel jobs. Since llvm is big-parallel, this means that wendy will now usually get selected for building llvm, since the load is otherwise pretty low. Previous successful builds of have been using one of the packet builders instead, which are using a newer CPU for which LLVM has a scheduling machine model.
FWIW, this probably affects other LLVM versions as well, but they have current versions in the cache. If wendy rebuilds the other packages (e.g. stdenv bump or something), they'll likely start failing as well.
If you spin up a VM using the CPU profile that at least virt-manager calls "OpteronG1", then you can reproduce this using the LLVM tests. That's not quite the same as the CPU reported on wendy (OpteronG1: k8-sse3; wendy: amdfam10), but it exhibits the same problem.
I don't know why, but wendy as disabled now.
it's probably late for you (I hope I didn't confuse names), but you this issue some time ago.
uh, same full name but this GitHub name is in .
Filed upstream for this.


Question: # this also disables necessary patches contained in `ollama/llm/patches/` # those patches are applied in `postPatch` ./disable-git.patch <ins> # we provide our own deps at runtime ./skip-rocm-cp.patch </ins> ]; postPatch = ''

Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra can reproduce:
I tracked down the potential source of this failure, and am working on a fix. These builds take 30 minutes for me though, so it's slow going.
Please see for a fix. Testing appreciated.
Thanks for the quick patch. EDIT: My way of installing to profile didn't pull the fix, I'll see if I can figure out a way to do it properly using the pr review package
Builds and runs... seg faults as soon as I load a model, but that's an AMD driver thing (whole WM crashes)... Ship it :laughing:
I did see some segfaults, but was able to restart and get it to load on my 6700xt. “Glad” to know it’s known and common.
Nice! Thanks for this - excited to see it roll into unstable soon. Ollama seems to always have some issue - is there a "working group" that has some focus on this program and nix? Anyway, thanks again!
The problems with crashing aren't nix problems, they're crappy amd driver issues. It doesn't crash if you don't load models close to the max vram available... obviously it shouldn't crash if you do, but amd... so yeah


Question: <del> { config, lib, stdenv, fetchFromGitHub, runCommand, ncurses, pkg-config </del> <ins> { config, lib, stdenv, fetchFromGitHub, fetchpatch, ncurses, pkg-config </ins> , libiconv, CoreAudio, AudioUnit, VideoToolbox , alsaSupport ? stdenv.isLinux, alsa-lib ? null

Steps to reproduce the behavior: cmus on current (). Full logs: I haven't updated in a while, so I'm not sure where this failure starts. Nothing has changed in the cmus package; it must be a change in dependencies. system: host os: multi-user?: sandbox: version: channels(root): channels(jamesw): nixpkgs:
cmus started failing somewhere between (good) and (bad). I don't have the hundreds of gigabytes of RAM that would allow me to do a bisection between those, so I'll leave that to someone else.
Manually going through it suggests as a possible culprit. I have no idea what that commit does, though, yet.
the issue is bump of ffmpeg to 6, i am about to push a fix


Question: , fetchurl , autoPatchelfHook , dpkg <del> , makeBinaryWrapper </del> <ins> , makeShellWrapper </ins> , wrapGAppsHook3 , alsa-lib , at-spi2-atk

ArmCord's wrapper seems unable to launch under Wayland, always chooses to launch under Steps to reproduce the behavior: sure and are properly set: Armcord: . ... 's on XWayland (as shown by ). I expect it to launch with Wayland instead of XWayland. Custom wrapper: Test case: Log output: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
probably need makeShellWrapper instead of makeBinaryWrapper in the package
Thanks for jumping on a PR will review this evening.


Question: <ins> { lib, buildGoModule, fetchFromGitHub }: buildGoModule rec { pname = "devspace"; version = "5.18.4"; src = fetchFromGitHub { owner = "loft-sh"; repo = "devspace"; rev = "v${version}"; sha256 = "0s5117cgxgrxfki5drvg6d22dvrjffa03bi644zdl1p631r599r1"; }; vendorSha256 = null; ldflags = [ "-s" "-w" "-X main.version=${version}" ]; # Check are disable since they requiered a working K8S cluster # TODO: add a nixosTest to be able to perform the package check doCheck = false; meta = with lib; { description = "DevSpace is an open-source developer tool for Kubernetes that lets you develop and deploy cloud-native software faster"; homepage = "https://devspace.sh/"; changelog = "https://github.com/loft-sh/devspace/releases/tag/v${version}"; license = licenses.asl20; maintainers = with maintainers; [ darkonion0 ]; }; } </ins>

Project description DevSpace is an open-source developer tool for Kubernetes that lets you develop and deploy cloud-native software faster. Metadata homepage URL: source URL: license: apache2 platforms: linux, darwin


Question: <ins> { config, lib, pkgs, utils, ... }: let inherit (lib) mkEnableOption mkPackageOption mkOption mkIf mkDefault types optionals getExe; inherit (utils) escapeSystemdExecArgs; cfg = config.services.sunshine; # ports used are offset from a single base port, see https://docs.lizardbyte.dev/projects/sunshine/en/latest/about/advanced_usage.html#port generatePorts = port: offsets: map (offset: port + offset) offsets; defaultPort = 47989; appsFormat = pkgs.formats.json { }; settingsFormat = pkgs.formats.keyValue { }; appsFile = appsFormat.generate "apps.json" cfg.applications; configFile = settingsFormat.generate "sunshine.conf" cfg.settings; in { options.services.sunshine = with types; { enable = mkEnableOption "Sunshine, a self-hosted game stream host for Moonlight"; package = mkPackageOption pkgs "sunshine" { }; openFirewall = mkOption { type = bool; default = false; description = '' Whether to automatically open ports in the firewall. ''; }; capSysAdmin = mkOption { type = bool; default = false; description = '' Whether to give the Sunshine binary CAP_SYS_ADMIN, required for DRM/KMS screen capture. ''; }; settings = mkOption { default = { }; description = '' Settings to be rendered into the configuration file. If this is set, no configuration is possible from the web UI. See https://docs.lizardbyte.dev/projects/sunshine/en/latest/about/advanced_usage.html#configuration for syntax. ''; example = '' { sunshine_name = "nixos"; } ''; type = submodule (settings: { freeformType = settingsFormat.type; options.port = mkOption { type = port; default = defaultPort; description = '' Base port -- others used are offset from this one, see https://docs.lizardbyte.dev/projects/sunshine/en/latest/about/advanced_usage.html#port for details. ''; }; }); }; applications = mkOption { default = { }; description = '' Configuration for applications to be exposed to Moonlight. If this is set, no configuration is possible from the web UI, and must be by the `settings` option. ''; example = '' { env = { PATH = "$(PATH):$(HOME)/.local/bin"; }; apps = [ { name = "1440p Desktop"; prep-cmd = [ { do = "''${pkgs.kdePackages.libkscreen}/bin/kscreen-doctor output.DP-4.mode.2560x1440@144"; undo = "''${pkgs.kdePackages.libkscreen}/bin/kscreen-doctor output.DP-4.mode.3440x1440@144"; } ]; exclude-global-prep-cmd = "false"; auto-detach = "true"; } ]; } ''; type = submodule { options = { env = mkOption { default = { }; description = '' Environment variables to be set for the applications. ''; type = attrsOf str; }; apps = mkOption { default = [ ]; description = '' Applications to be exposed to Moonlight. ''; type = listOf attrs; }; }; }; }; }; config = mkIf cfg.enable { services.sunshine.settings.file_apps = mkIf (cfg.applications.apps != [ ]) "${appsFile}"; environment.systemPackages = [ cfg.package ]; networking.firewall = mkIf cfg.openFirewall { allowedTCPPorts = generatePorts cfg.settings.port [ (-5) 0 1 21 ]; allowedUDPPorts = generatePorts cfg.settings.port [ 9 10 11 13 21 ]; }; boot.kernelModules = [ "uinput" ]; services.udev.packages = [ cfg.package ]; services.avahi = { enable = mkDefault true; publish = { enable = mkDefault true; userServices = mkDefault true; }; }; security.wrappers.sunshine = mkIf cfg.capSysAdmin { owner = "root"; group = "root"; capabilities = "cap_sys_admin+p"; source = getExe cfg.package; }; systemd.user.services.sunshine = { description = "Self-hosted game stream host for Moonlight"; wantedBy = [ "graphical-session.target" ]; partOf = [ "graphical-session.target" ]; wants = [ "graphical-session.target" ]; after = [ "graphical-session.target" ]; startLimitIntervalSec = 500; startLimitBurst = 5; serviceConfig = { # only add configFile if an application or a setting other than the default port is set to allow configuration from web UI ExecStart = escapeSystemdExecArgs ([ (if cfg.capSysAdmin then "${config.security.wrapperDir}/sunshine" else "${getExe cfg.package}") ] ++ optionals (cfg.applications.apps != [ ] || (builtins.length (builtins.attrNames cfg.settings) > 1 || cfg.settings.port != defaultPort)) [ "${configFile}" ]); Restart = "on-failure"; RestartSec = "5s"; }; }; }; } </ins>

Project description <!-- Describe the project a little: --Sunshine has already been packaged here in nixpkgs: But it doesn't come out of the box just by , according to and and , at least it needs a and maybe . It would be better if we could add a NixOS module for it to make it availale just by sth. like or . CC maintainer Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This has been on my to-do list for ages :) The module itself wouldn't be a huge deal, and I think I have a plan for tests, just need some time to work on it.
I actually started working on this a while ago. My module can create valid and files (i.e. they work when I start sunshine manually) and open the necessary ports, however I couldn't get the systemd service to function properly. If I recall correctly, the issue was related to getting access to the screen. Here is what I have so far, maybe it can help someone:
Thanks I used yours as inspiration and opened for this. It's still a draft -- I need to work on the tests -- but any testing or comments are welcome. I've tested on Plasma 6 + Wayland + AMD and seems to work, have not tested much with Xorg or NVIDIA.
Think it's got all the functionality I had planned -- marked as ready for review.


Question: ./services/web-apps/cryptpad.nix ./services/web-apps/documize.nix ./services/web-apps/frab.nix <ins> ./services/web-apps/gotify-server.nix </ins> ./services/web-apps/icingaweb2/icingaweb2.nix ./services/web-apps/icingaweb2/module-monitoring.nix ./services/web-apps/limesurvey.nix

Project description A simple server for sending and receiving messages in real-time per WebSocket. Includes a web UI, also has an Android client for receiving notifications and an optional CLI program (distributed separately) for sending notifications. Metadata homepage URL: source URL: license: MIT platforms: anything Go runs on
I started an attempt locally, however it failed due to some timeouts while fetching Go dependencies... will retry during this week :)
I think the main difficulty is the UI, which needs to be compiled with NPM. In essence, I think the build is three-staged: fetch UI dependencies, fetch Go dependencies, do the actual build.
You may want to take a look at .


Question: buildPythonPackage rec { pname = "flax"; <del> version = "0.6.0"; </del> <ins> version = "0.6.1"; </ins> src = fetchFromGitHub { owner = "google"; repo = pname; rev = "refs/tags/v${version}"; <del> sha256 = "sha256-egTYYFZxhE/Kk7jXRi1HmjCjyFia2LoRigH042isDu0="; </del> <ins> sha256 = "sha256-fZiODo+izOwGjCCTvi11GvUG/VQL1DV9bNXKjvIIw4A="; </ins> }; <del> patches = [ # Bump rich dependency, should be fixed in releases after 0.6.0 # https://github.com/google/flax/pull/2407 (fetchpatch { url = "https://github.com/google/flax/commit/72189153f9779022b97858ae747c23fbaf571e3d.patch"; sha256 = "sha256-hKOn/M7qpBM6R1RIJpnXpRoZgIHqkwQZApN4L0fBzIE="; name = "bump_rich_dependency.patch"; }) ]; </del> buildInputs = [ jaxlib ]; propagatedBuildInputs = [

Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -


Question: lib.fakeSha256; inherit url change state channel; <ins> impureEnvVars = lib.fetchers.proxyImpureEnvVars; </ins> } )

The pijul fetcher throws a certificate error when used, for example with the following command: Related: Steps to reproduce the behavior: fetchpijul (for example like in the command above) fails with above error Repository gets fetched successfully Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oh my, thanks for notifying, I'll make a PR to fix that ASAP!


Question: ninja pkg-config python3 <ins> rustPlatform.cargoSetupHook rustc </ins> wrapGAppsHook ];

Describe the bug fails to compile with Additional context See for a possible cause. Notify maintainers cc (sorry for notifying you here and in the PR!)
Gonna try to just switch it to . We should probably update gnome docs for Rust+Gnome packages
Yeah, I think that would be best. The idea of the hooks is that is not necessary anymore in mixed projects. I will also do a PR for cargoBuildHook, since it should not be used when is set explicitly.


Question: qdarkstyle ]; <del> preBuild = '' </del> <ins> postPatch = '' # make compatible with protobuf4 by easing dependencies ... substituteInPlace ./contrib/requirements/requirements.txt  --replace "protobuf>=3.12,<4" "protobuf>=3.12" # ... and regenerating the paymentrequest_pb2.py file protoc --python_out=. electrum/paymentrequest.proto </ins> substituteInPlace ./electrum/ecc_fast.py  --replace ${libsecp256k1_name} ${secp256k1}/lib/libsecp256k1${stdenv.hostPlatform.extensions.sharedLibrary} '' + (if enableQt then ''

Steps to reproduce the behavior: nixpkgs electrum was recently updated 4.3.1 -4.3.2: previously built fine on nixpkgs 2022-09-28 () <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --<!-- attempting ti bisect, but on a slow machine, and it looks like there's miscellaneous failures over this duration so not sure it'll bisect cleanly: --
bisected to: good: bad: that's the staging-next merge though, so a lot of surface area. however, we appear to address a very similar build failure over in pkgs/development/python- by doing: i'm not sure how to test this same patch on electrum since it doesn't have any file.
oh just kidding, Electrum just places its in a different location. the patch below fixes the build when applied to master, and the application starts but i didn't test any functionality that i know touches protobuf. not sure how concerned i should be about overriding a pinned dep (i'm not a python dev):
Fix in


Question: <ins> { config , lib , pkgs , ... }: let cfg = config.services.realm; configFormat = pkgs.formats.json { }; configFile = configFormat.generate "config.json" cfg.config; inherit (lib) mkEnableOption mkPackageOption mkOption mkIf types getExe; in { meta.maintainers = with lib.maintainers; [ ocfox ]; options = { services.realm = { enable = mkEnableOption "A simple, high performance relay server written in rust"; package = mkPackageOption pkgs "realm" { }; config = mkOption { type = types.submodule { freeformType = configFormat.type; }; default = { }; description = '' The realm configuration, see <https://github.com/zhboner/realm#overview> for documentation. ''; }; }; }; config = mkIf cfg.enable { systemd.services.realm = { serviceConfig = { DynamicUser = true; MemoryDenyWriteExecute = true; PrivateDevices = true; ProtectClock = true; ProtectKernelLogs = true; ProtectKernelModules = true; ProtectProc = "invisible"; ProtectKernelTunables = true; ExecStart = "${getExe cfg.package} --config ${configFile}"; AmbientCapabilities = [ "CAP_NET_ADMIN" "CAP_NET_BIND_SERVICE" ]; }; wantedBy = [ "multi-user.target" ]; }; }; } </ins>

Project description A simple, high performance relay server written in rust. Metadata homepage URL: source URL: license: mit platforms: Linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: # there is at least one "privileged" account that has a # password or an SSH authorized key. Privileged accounts are # root and users in the wheel group. <del> assertion = !cfg.mutableUsers -> any id ((mapAttrsToList (_: cfg: (cfg.name == "root" </del> <ins> # The check does not apply when users.disableLoginPossibilityAssertion # The check does not apply when users.mutableUsers assertion = !cfg.mutableUsers -> !cfg.allowNoPasswordLogin -> any id (mapAttrsToList (name: cfg: (name == "root" </ins> || cfg.group == "wheel" || elem "wheel" cfg.extraGroups) &&

Describe the bug There are reasons to want a system, that has no user that can log in by SSH or with their password, for example in a declarative container To Reproduce Steps to reproduce the behavior: up a minimal declarative container asserts that I will be locked out from the system and refuses to build the configuration with Expected behavior nix generates me a container that I can log in with , or maybe I don't want to log into it at all (because it's a disposable VM or something of the like). I think there should be a check whether the generated system is a container and an additional "I know what I'm doing" override for other cases. I'll create a PR once we agreed on what's best. Maintainer information: Code causing the problem: mentioning since you the check.
Is it an option to set a randomly-generated (the hash itself would be generated, not obtained by honestly hashing a password)? Recovering the password from such a hash is probably harder than a lot of other attack vectors. But an override «doLockOutEveryone» sounds fine.
Setting a password would certainly be a possibility, but somewhat (for lack of a better word) really lame. Having slept a night over it, I propose , that disables all the assertions at the bottom. I can see scenarios where two users with the same uid could be wanted. I want my unixoid to always give me enough rope to shoot myself in the leg.
What about not enabling ssh and disabling the getty? It should completely lock anyone out, unless I am missing something. Take a look at the profile.
In case of a nixos declaratively defined nixos container, you are not logged out because the root system(d) can generate a root shell without any authentication, which is why I consider this a bug. Having to "fool" the assertion to actually lock oneself out is another matter, I could live with that but I don't think it's nice behavior.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this.


Question: # there is at least one "privileged" account that has a # password or an SSH authorized key. Privileged accounts are # root and users in the wheel group. <del> assertion = !cfg.mutableUsers -> any id ((mapAttrsToList (_: cfg: (cfg.name == "root" </del> <ins> # The check does not apply when users.disableLoginPossibilityAssertion # The check does not apply when users.mutableUsers assertion = !cfg.mutableUsers -> !cfg.allowNoPasswordLogin -> any id (mapAttrsToList (name: cfg: (name == "root" </ins> || cfg.group == "wheel" || elem "wheel" cfg.extraGroups) &&

Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
This is still an issue.
I marked this as stale due to inactivity. →
Fixed via


Question: ), formatter_class=argparse.RawTextHelpFormatter ) <del> @@ -133,14 +132,10 @@ def main(args=None): </del> <ins> @@ -138,18 +137,9 @@ def main(args=None): ) </ins> sys.exit(-1) <del> # 2. Find Steam Runtime if enabled -    steam_runtime_path = None +    steam_runtime = False </del> <ins> -    # 2. Find the pre-installed legacy Steam Runtime if enabled -    legacy_steam_runtime_path = None -    use_steam_runtime = True - +    # 2. Use Steam Runtime if enabled </ins> if os.environ.get("STEAM_RUNTIME", "") != "0" and not args.no_runtime: <del> -        steam_runtime_path = find_steam_runtime_path(steam_root=steam_root) </del> <ins> -        legacy_steam_runtime_path = find_legacy_steam_runtime_path( -            steam_root=steam_root -        ) </ins> - <del> -        if not steam_runtime_path: </del> <ins> -        if not legacy_steam_runtime_path: </ins> -            print("Steam Runtime was enabled but couldn't be found!") -            sys.exit(-1) <del> +        steam_runtime = True </del> <ins> +        use_steam_runtime = True </ins> else: <ins> use_steam_runtime = False </ins> logger.info("Steam Runtime disabled.") <del> @@ -201,7 +196,7 @@ def main(args=None): winetricks_path=winetricks_path, </del> <ins> @@ -212,7 +202,6 @@ def main(args=None): </ins> proton_app=proton_app, steam_app=steam_app, <del> -            steam_runtime_path=steam_runtime_path, +            steam_runtime=steam_runtime, command=[winetricks_path, "--gui"] </del> <ins> use_steam_runtime=use_steam_runtime, -            legacy_steam_runtime_path=legacy_steam_runtime_path, command=[winetricks_path, "--gui"], use_bwrap=use_bwrap </ins> ) <del> @@ -269,7 +264,7 @@ def main(args=None): winetricks_path=winetricks_path, </del> <ins> @@ -282,7 +271,6 @@ def main(args=None): </ins> proton_app=proton_app, steam_app=steam_app, <del> -            steam_runtime_path=steam_runtime_path, +            steam_runtime=steam_runtime, </del> <ins> use_steam_runtime=use_steam_runtime, -            legacy_steam_runtime_path=legacy_steam_runtime_path, use_bwrap=use_bwrap, </ins> command=[winetricks_path] + args.winetricks_command) elif args.command: <del> run_command( @@ -277,7 +272,7 @@ def main(args=None): proton_app=proton_app, </del> <ins> @@ -292,7 +280,6 @@ def main(args=None): </ins> steam_app=steam_app, command=args.command, <del> -            steam_runtime_path=steam_runtime_path, +            steam_runtime=steam_runtime, </del> <ins> use_steam_runtime=use_steam_runtime, -            legacy_steam_runtime_path=legacy_steam_runtime_path, use_bwrap=use_bwrap, </ins> # Pass the command directly into the shell *without* # escaping it <del> cwd=steam_app.install_path, </del> diff --git a/src/protontricks/steam.py b/src/protontricks/steam.py <del> index fa5772d..4f30cd3 100644 </del> <ins> index 8554e24..509afb6 100644 </ins> --- a/src/protontricks/steam.py +++ b/src/protontricks/steam.py <del> @@ -11,7 +11,7 @@ from .util import lower_dict </del> <ins> @@ -13,8 +13,8 @@ from .util import lower_dict </ins> __all__ = ( "COMMON_STEAM_DIRS", "SteamApp", "find_steam_path", <del> -    "find_steam_proton_app", "find_proton_app", "find_steam_runtime_path", +    "find_steam_proton_app", "find_proton_app", "find_appid_proton_prefix", "get_steam_lib_paths", "get_steam_apps", "get_custom_proton_installations" </del> <ins> "find_steam_proton_app", "find_proton_app", -    "find_legacy_steam_runtime_path", "find_appid_proton_prefix", -    "get_steam_lib_paths", "get_steam_apps", "get_custom_proton_installations" +    "find_appid_proton_prefix", "get_steam_lib_paths", +    "get_steam_apps", "get_custom_proton_installations" </ins> ) <del> @@ -254,37 +254,6 @@ def find_steam_path(): </del> <ins> COMMON_STEAM_DIRS = [ @@ -283,37 +283,6 @@ def find_steam_path(): </ins> return None, None <del> -def find_steam_runtime_path(steam_root): </del> <ins> -def find_legacy_steam_runtime_path(steam_root): </ins> -    """ <del> -    Find the Steam Runtime either using the STEAM_RUNTIME env or </del> <ins> -    Find the legacy Steam Runtime either using the STEAM_RUNTIME env or </ins> -    steam_root -    """ -    env_steam_runtime = os.environ.get("STEAM_RUNTIME", "")

This issue is mainly a note to myself since the upgrade won't be trivial and will need a lot of testing. Protontricks is now using the Pressure Vessel runtime, so I have to refactor my patches with steam-run to account for this. <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: protontricks <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.4.4 desired version: 1.5.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: myself


Question: { lib, stdenv , substituteAll , fetchurl <ins> , fetchpatch </ins> , fetchFromGitHub , autoreconfHook , gettext

Upstream ibus-1.5.24 (in nixpkgs) supports gtk4. It will be good if we enable gtk4 support in nixpkgs. I fail to enable it with the following patch.


Question: cp -r ${driver} driver-src chmod -R +w driver-src <ins> cp ${driverKernel610MainC} driver-src/driver/main.c </ins> cmakeFlagsArray+=( "-DFALCOSECURITY_LIBS_SOURCE_DIR=$(pwd)/libs"

Steps to reproduce the behavior: sysdig Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can't repro on master () and the error isn't in the log output, can you provide additional info?
Hey, thanks for the response - checking again - it only happens if for me if I enable the sysdig-option in my config not building the sysdig-package - maybe this helps to reproduce and depends on the used kernel-version? I've uploaded the full build log:
Thanks, seems this is the error:
I guess this is already fixed upstream in the drivers () but needs to be to nixpkgs to fix 6.10-kernel builds.
fixes it for me
~Ah 0.38.1 - got released somehow oversaw it should check first if that includes the fix~ 38.1 does not include a driver-bump


Question: "google.oauth2" ]; <ins> disabledTests = lib.optionals stdenv.isDarwin [ "test_request_with_timeout_success" "test_request_with_timeout_failure" "test_request_headers" "test_request_error" "test_request_basic" ]; </ins> meta = with lib; { description = "Google Auth Python Library"; longDescription = ''

Describe the bug Tensorflow binary builds don't work on mac os. (neither do the source build, but that's a separate issue) To Reproduce $ nix-build '<nixpkgs' --show-trace -A python37Packages.tensorflow-bin_2 this derivation will be built: /nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow- building '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-'... Sourcing python-recompile-bytecode- Sourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing wheel setup hook Using wheelUnpackPhase Sourcing pip-install-hook Using pipInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook unpacking sources Executing wheelUnpackPhase Finished executing wheelUnpackPhase patching sources configuring /private/tmp/nix-build-python3.7-tensorflow- /private/tmp/nix-build-python3.7-tensorflow- Unpacking to: unpacked/tensorflow-2.1.0...OK substitute(): ERROR: file '--replace' does not exist error: --- Error
--------------------------------------------------------------------------- nix-build builder for '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-' failed with exit code 1 host os: multi-user?: sandbox: version: channels(noah): nixpkgs: yaml attribute: module:


Question: "google.oauth2" ]; <ins> disabledTests = lib.optionals stdenv.isDarwin [ "test_request_with_timeout_success" "test_request_with_timeout_failure" "test_request_headers" "test_request_error" "test_request_basic" ]; </ins> meta = with lib; { description = "Google Auth Python Library"; longDescription = ''

Describe the bug tensorflow-bin_2 wants gast-3.2.0 due to but gast has been updated to 3.3.0 so tensorflow refuses to install: To Reproduce Notify maintainers Metadata Maintainer information:
There are also other dependencies that fail the version checks: scipy==1.4.1 and tensorflow-estimator<2.2.0,=2.1.0rc0.
This compiles i'll test it, any feedback appreciated
Got some issues
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Related .
It looks like fixes this.


Question: MACOSX_DEPLOYMENT_TARGET=10.16 '' else null; <ins> configureFlags = [ "PYTHON_VERSION=${lib.versions.major python.version}" ]; </ins> nativeBuildInputs = [ pkg-config ]; buildInputs = [ dbus dbus-glib ] # My guess why it's sometimes trying to -lncurses.

A clear and concise description of what the bug is. Steps to reproduce the behavior: build github:nixos/nixpkgs/nixos-unstable#legacyPackages.x86_64- Nix builds the derivation. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Maintainer information:


Question: }; users.groups.${cfg.group}.gid = config.ids.gids.gitolite; <del> systemd.tmpfiles.rules = [ "d '${cfg.dataDir}' 0750 ${cfg.user} ${cfg.group} - -" "d '${cfg.dataDir}'/.gitolite - ${cfg.user} ${cfg.group} - -" "d '${cfg.dataDir}'/.gitolite/logs - ${cfg.user} ${cfg.group} - -" "Z ${cfg.dataDir} 0750 ${cfg.user} ${cfg.group} - -" ]; </del> systemd.services.gitolite-init = { description = "Gitolite initialization"; wantedBy    = [ "multi-user.target" ];

Describe the bug My server uses an encrypted filesystem /data that I have to mount manually after reboot. Gitolite is configured to use /data/gitolite. I have configured gitolite-init to only run once /data is mounted. Mounting of /data always fails, as gitolite uses to generate directories and thus the mountpoint is not empty. Manual cleanup is required every time. Expected behavior Gitolite should create its directories in gitolite-init.service. Additional context systemd-tmpfiles-setup.service runs before the system is fully initialized, so I cannot delay that service. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I'll try to address this in the next few days.


Question: { fetchurl, stdenv, pkgconfig, intltool, pulseaudio, gtkmm3 <del> , libcanberra_gtk3 }: </del> <ins> , libcanberra_gtk3, makeWrapper, gnome3 }: </ins> stdenv.mkDerivation rec { name = "pavucontrol-2.0";

Here is result of — I'll try to do something about it when I have time but it'll most likely be next year, so please go ahead and fix it if you have time for minor issues.
Screenshot?
pavucontrol has no binary wrapper, thus icons won't show unless relevant icon themes are installed in the system.
Fixed in master.


Question: '' # Move the outputs into their respective outputs. + strings.concatMapStringsSep "n" mkMoveToOutputCommand (builtins.tail finalAttrs.outputs) <ins> # Add a newline to the end of the installPhase, so that the post-install hook doesn't # get concatenated with the last moveToOutput command. + "n" </ins> # Post-install hook + '' runHook postInstall

Possibly a regression after CC <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Log The clue is in this log line Odd that we'd be copying something to a derivation ending in , right? Let's investigate further. is one of the CUDA redistributables, so I know it's built by the manifest builder. Looking it over, we can see the relevant portion of the : Well, that looks about right, but what is it actually rendered as when building? Uh oh. Yeah, that's right -- we're missing a newline character! Turns out using the multiline string literal doesn't mean we get a leading newline character (which makes sense given that we concatenate them everywhere and we're not drowning in empty lines). With just a small patch Our is what we would expect: And the resulting build contains our binaries! More generally, the problem likely caused the last, non-, output to disappear.
Will be
I suppose it wouldn't be unfair to say that this is an instance of the "we've stringified our data and failed to parse it again" issue?
I think that’s fair to say. As I view it, the actual build is always done by a bash script. We can either write it entirely in bash, or template it (like we do currently). Both come with tradeoffs. In my opinion, the boost we get in expressivity from lifting some parts of the build up into Nix expressions (so we can use attribute sets and functions in the library) outweigh the cost of making sure we’re producing well-formed bash. Although, that does fall apart sometimes (like here, where we were missing a new line). I’ve not tried to rewrite the install phase as a static bash script which leverages structured attributes, but I do wonder if it would have been as easy to debug? At least with the approach of using Nix as a templating language for bash we can use nix eval on the install phase to see the result. thoughts?
Yea we can also use to peek at the attributes that would go into the JSON, and then maybe there's less bash to read


Question: homepage = "https://github.com/cinemast/libjson-rpc-cpp"; license = licenses.mit; platforms = platforms.linux; <ins> sourceProvenance = with lib.sourceTypes; [ binaryBytecode ]; maintainers = with maintainers; [ robertrichter ]; </ins> }; }

Package name: libjson-rpc-cpp Latest released version: 1.3.0 <!-- Search your package here: --- Current version on the unstable channel: 1.3.0 Current version on the stable/release channel: 1.3.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 no maintainers :< <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: dm-sonnet = callPackage ../development/python-modules/dm-sonnet { }; <del> dm-tree = callPackage ../development/python-modules/dm-tree { }; </del> <ins> dm-tree = callPackage ../development/python-modules/dm-tree { abseil-cpp = pkgs.abseil-cpp.override { cxxStandard = "14"; }; }; </ins> dnachisel = callPackage ../development/python-modules/dnachisel { };

Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
Looks like another gcc11 issue. would you mind taking a look?


Question: <ins> { lib, stdenv, fetchFromGitHub, autoconf, automake, libtool, pkg-config, perl }: stdenv.mkDerivation rec { pname = "libxcrypt"; version = "4.4.18"; src = fetchFromGitHub { owner = "besser82"; repo = "libxcrypt"; rev = "v${version}"; sha256 = "4015bf1b3a2aab31da5a544424be36c1a0f0ffc1eaa219c0e7b048e4cdcbbfe1"; }; preConfigure = '' patchShebangs autogen.sh ./autogen.sh ''; nativeBuildInputs = [ autoconf automake libtool pkg-config perl ]; doCheck = true; meta = with lib; { description = "Extended crypt library for descrypt, md5crypt, bcrypt, and others"; homepage = "https://github.com/besser82/libxcrypt/"; platforms = platforms.all; maintainers = with maintainers; [ dottedmag ]; license = licenses.lgpl21Plus; }; } </ins>

Project description is a library that provides strong cryptographic hashes for password hashing, such as bcrypt and yescrypt, as well as a number of legacy ones for backward compatibility (e.g. sha256). It is API- and ABI-compatible with provided by glibc. glibc intends to drop the library eventually: This is a first step towards transitioning whole nixpkgs from libcrypt bundled in glibc, as described here: Metadata homepage URL: source URL: license: lgpl2.1+ platforms: unix


Question: ${upstreamDoc} ''; }; <ins> configFile = mkOption { type = types.path; default = mkConfig name config; defaultText = "A config file generated by values from other kanata module options."; description = '' The config file. By default, it is generated by values from other kanata module options. You can also set it to your own full config file which overrides all other kanata module options.  ${upstreamDoc} ''; }; </ins> extraArgs = mkOption { type = types.listOf types.str; default = [ ];

Currently it's only possible to configure kanata by specifying specific parts one at a time. It's not possible to read a configuration from a file and use that instead of the specific parts. I use HomeManager to manage the kanata configuration file and because it's also used for Windows this is the most platform neutral way for me without duplicating parts of the configuration. As a workaround I did it like this for now: But clearly that is not ideal. What I would want is to just keep the 'readFile' and uncomment the 'defcfg' part from the configuration file ()
I created to address this issue. Could you help test it?
Thanks a lot for the fast solution! I tested it with my config and it works without any issues.


Question: passthru = { wpName = pname; <ins> }; meta = { license = lib.licenses.${license}; </ins> } // (args.passthru or {}); } // lib.optionalAttrs (type == "language") { nativeBuildInputs = [ gettext wp-cli ];

The package with that are automatically fetched carry no license. ` cc
Poking upstream does not seem to yield anything. They did indicate they wouldn't support this use case, so what are you expecting from them?
I talked to the authors of wp4nix and they are happy for new contributions. It would be nice if the wp4nix script would somehow handle license informations, for example by manually defining them. Not quite sure yet how to implement it
If we don't know the licenses to these packages we honestly cannot keep them around. For example, it is absolutely unclear, whether we have a license to even redistribute them. Of course upstream will take patches, but they're not exactly in the same boat we are. I think your attitude towards the whole licensing situation around wp4nix/nc4nix and its resulting packages is alarming.
As written : Fixing this for Wordpress packages and themes (wp4nix) and Nextcloud apps (nc4nix) in a foreseeable time exceeds my skills and competence. Therefore I would like to offer to add a flag to these package sets and remove them for the next release 23.11 if it's not resolved by then.
Couldn't we mark them as unfree so they don't get cached on hydra but people can still use them if they want? Unfortunately it seems like the wordpress plugins repository doesn't seem to provide the license information in an easy manner. And I don't know whether it is stored somewhere else or can even be extracted from the derivation without import-from-derivation.
Actuallly we seem to be safe in theory. claims
In an ideal world, that would hold true, but it is up to the user and distributor to validate the final outcome. I therefore think this situation remains unresolved.