text:
package request: deepin-screenshot

Issue description
It would be nice to have deepin-screenshot available for NixOS. I used to like it's cropping and editing capabilities a lot.

https://www.deepin.org/wp-content/uploads/2017/01/deepin-screenshot1.png
https://www.deepin.org/wp-content/uploads/2017/01/deepin-screenshot2.png

cc @romildo

We have this now

authors: flokli worldofpeace


text:
Group netdev is missing when using Avahi

Here is a snippet from /nix/store/…-system-path/etc/dbus-1/system.d/avahi-dbus.conf:
  <!-- Allow everything, including access to SetHostName to users of the group "netdev" -->
  <policy group="netdev">
    <allow send_destination="org.freedesktop.Avahi"/>
    <allow receive_sender="org.freedesktop.Avahi"/>
  </policy>

netdev is one of those groups used by all the distros, just like video and plugdev (the latter one, actually, also doesn’t get created by NixOS and I’m not sure what implications this has).
I think this group should be created in config/users-groups.nix. Your thoughts?

Relevant issue from Arch (about "plugdev" group): https://bugs.archlinux.org/task/35602

Right, it seems that plugdev is really evil and it is not needed, since NixOS uses systemd. But unfortunatelly there are still packages that ship udev rules with references to plugdev.
On the other hand, netdev group seems to be completely harmless. I don’t what it is used for nowadays, I think NetworkManager used to decide whether user was allowed to create wifi connections based on membership in this group, but I’m pretty sure that right now I can do whaterver I want with networking with an empty netdev group.
Based on this I assume that the only real use for netdev right now is this avahi dbus rule. Avahi package creates this group in distros I checked (Gentoo, Fedora), so we should do this too.

@bjornfor BTW apparently Fedora fixed your issue by replacing all the plugdev with users in the rules they ship.

(triage) Do we really need another group? Has there been another issue about this? Maybe it’s getting replaced by systemd anyway.

It hasn't bothered me enough to do anything about it. My user is (overly) privileged, so I didn't have a use for the "netdev" group. But I can imagine there are use cases where it's useful. (Less privileged users that are allowed to do certain things with networking / avahi.
Also, I'm worried about exhausting the user/group namespace in NixOS :-)

Also, I'm worried about exhausting the user/group namespace in NixOS :-)

Yes, that could very well become a problem in the mid future.
Should this stay open?

For me, closing is fine. If this becomes an issue for me later I'll probably open a PR that adds the group.
CC @kirelagin.

@Profpatsch What do you mean being replaced by systemd? There's still lots of modules and hardware devices that still advise udev rules that use the plugdev group. We should either document that users should probably have the plugdev group by default, or standardise the handling of USB device modules and the groups/authentication system they use.

Are you talking about this kind of stuff: TAG+="uaccess", TAG+="udev-acl”?

source: gharchive/issue

authors: CMCDragonkai Profpatsch bjornfor kirelagin

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
conda error: install method not compatible

Issue description
# try any conda command
$ conda
ERROR: The install method you used for conda--probably either `pip install conda`
or `easy_install conda`--is not compatible with using conda as an application.
If your intention is to install conda as a standalone application, currently
supported install methods include the Anaconda installer and the miniconda
installer.  You can download the miniconda installer from
https://conda.io/miniconda.html.

Steps to reproduce

install conda
try using it, e.g. just conda or the more explicit /nix/store/x1mhg06627mxrgm0avc2h6lnmia4z3xy-python3.7-conda-4.3.16/bin/conda, with or without extra commands
find above error

Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.
 - system: `"x86_64-linux"`
 - host os: `Linux 4.18.0, NixOS, 18.09.1799.b9fa31cea0e (Jellyfish)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.1.3`
 - channels(root): `"nixos-18.09.1799.b9fa31cea0e, nixos-unstable-small-19.03pre164396.24cdaa7b488"`
 - channels(tycho): `"nixos-unstable-small-19.03pre164396.24cdaa7b488"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

You want nixpkgs.conda not nixpkgs.pythonPackages.conda.
This should put you in a (unfortunately extremely barren) shell where you can use conda:
nix run nixpkgs.conda --command conda-shell-4.3.31

I made a branch a while back that puts you inside a more fully feathered shell (the command is simply called conda-shell there): https://github.com/hedning/nixpkgs/commits/better-buildFHSUserEnv

Thanks for your reply @hedning. I tried conda-shell, but was quite confused about it, as it seemed to function like bash rather than like the conda cli.
Is there any outstanding PR to get your improved shell integrated here? :)

Is there any outstanding PR to get your improved shell integrated here? :)

It's on my to do list, but I haven't made a PR yet.


text:
Vulnerability roundup 79: gcc-7.4.0: 2 advisories

search, files

[ ] CVE-2018-12886 CVSSv3=8.1 (nixos-19.03)
[ ] CVE-2019-15847 CVSSv3=7.5 (nixos-19.03)

Scanned versions: nixos-19.03: d1dff0bcd9f. May contain false positives.

See also: #73633


text:
How to use xrdp with pantheon desktop?

Issue description
When connecting to the xrdp server with Remmina, i only get a black screen and this error.

xrdp log: https://gist.github.com/davidak/e2cc009b6b359e4d0ffbdb6ac09a91ab
@worldofpeace do you know how the pantheon session is started?
Steps to reproduce
I tried this
  services.xrdp = {
    enable = true;
    defaultWindowManager = "gnome-session --session=pantheon";
  };

Also tried with these as defaultWindowManager:

pantheon
pantheon-session
gnome-session

I also followed this tutorial from 2015 and got the same error: https://cant-remember-everything.blogspot.com/2015/03/enable-remote-desktop-in-elementary-os.html
Technical details

system: "x86_64-linux"
host os: Linux 5.4.62, NixOS, 20.03.2910.42674051d12 (Markhor)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.6
channels(root): "home-manager-20.03, nixos-20.03.2910.42674051d12, nixos-unstable-20.09pre239318.c59ea8b8a0e"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

On NixOS stable, most desktops don't work with xrdp. https://github.com/NixOS/nixpkgs/issues/57717

@davidak See https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/pantheon/desktop/elementary-session-settings/default.nix#L117

Since
services.xrdp.enable = true;
services.xrdp.defaultWindowManager = "${pkgs.xfce4-12.xfce4-session}/bin/xfce4-session";
services.xserver.desktopManager.xfce.enable = true;

works, i tried
  services.xrdp.enable = true;
  services.xrdp.defaultWindowManager = "${pkgs.pantheon.elementary-session-settings}/libexec/pantheon";
  services.xserver.desktopManager.pantheon.enable = true;

when i connect with remmina, i get a black window, that crashes after few seconds...
xrdp log:
Sep 07 17:13:36 zipper xrdp[2694]: [20200907-17:12:39] [DEBUG] return value from xrdp
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:12:39] [DEBUG] return value from xrdp
Sep 07 17:13:36 zipper xrdp[2840]: -port parameter found, ini override [3389]
Sep 07 17:13:36 zipper xrdp[2840]: --config parameter found [/nix/store/0jw9ccf0wjh0rj9b389wb5y1c7qqr24w-xrdp.conf/xrdp.ini]
Sep 07 17:13:36 zipper xrdp[2840]: logging configuration:
Sep 07 17:13:36 zipper xrdp[2840]:         LogFile:       /dev/null
Sep 07 17:13:36 zipper xrdp[2840]:         LogLevel:      4
Sep 07 17:13:36 zipper xrdp[2840]:         EnableSyslog:  0
Sep 07 17:13:36 zipper xrdp[2840]:         SyslogLevel:   4
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:11:15] [INFO ] starting xrdp with pid 1632
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:11:15] [INFO ] listening to port 3389 on 0.0.0.0
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:12:17] [INFO ] Socket 11: AF_INET6 connection received from ::ffff:10.0.4.12 port 55584
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:12:17] [DEBUG] Closed socket 11 (AF_INET6 ::ffff:10.0.0.52 port 3389)
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:12:38] [INFO ] Socket 11: AF_INET6 connection received from ::ffff:10.0.4.12 port 55586
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:12:38] [DEBUG] Closed socket 11 (AF_INET6 ::ffff:10.0.0.52 port 3389)
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [INFO ] Socket 11: AF_INET6 connection received from ::ffff:10.0.4.12 port 55588
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [DEBUG] Closed socket 10 (AF_INET6 :: port 3389)
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [DEBUG] TLSv1.3 enabled
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [DEBUG] TLSv1.2 enabled
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [DEBUG] Security layer: requested 3, selected 1
Sep 07 17:13:36 zipper xrdp[2840]: ssl_tls_accept: TLS connection accepted
Sep 07 17:13:36 zipper xrdp[2840]: colorDepth 0xca01 (0xca00 4bpp 0xca01 8bpp)
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [INFO ] connected client computer name: gaming
Sep 07 17:13:36 zipper xrdp[2840]: postBeta2ColorDepth 0xca01 (0xca00 4bpp 0xca01 8bpp 0xca02 15bpp 0xca03 16bpp 0xca04 24bpp)
Sep 07 17:13:36 zipper xrdp[2840]: highColorDepth 0x0018 (0x0004 4bpp 0x0008 8bpp 0x000f 15bpp 0x0010 16 bpp 0x0018 24bpp)
Sep 07 17:13:36 zipper xrdp[2840]: supportedColorDepths 0x000f (0x0001 24bpp 0x0002 16bpp 0x0004 15bpp 0x0008 32bpp)
Sep 07 17:13:36 zipper xrdp[2840]: earlyCapabilityFlags 0x0523 (0x0002 want32)
Sep 07 17:13:36 zipper xrdp[2840]: got client client connection type 0x00000006
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_sec_process_mcs_data_CS_SECURITY:
Sep 07 17:13:36 zipper xrdp[2840]:   client and server support none crypt, using none crypt
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [INFO ] adding channel item name rdpdr chan_id 1004 flags 0xc0800000
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [INFO ] adding channel item name rdpsnd chan_id 1005 flags 0xc0000000
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [INFO ] adding channel item name cliprdr chan_id 1006 flags 0xc0a00000
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:34] [INFO ] addin0800000
Sep 07 17:13:36 zipper xrdp[2840]: error unknown xrdp_sec_process_mcs_data tag 0xc006 size 8
Sep 07 17:13:36 zipper xrdp[2840]: error unknown xrdp_sec_process_mcs_data tag 0xc00a size 8
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_sec_out_mcs_data: using no security
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_load_keyboard_layout: keyboard_type [4] keyboard_subtype [0]
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_load_keyboard_layout: model [] variant [] layout [de] options []
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:35] [INFO ] TLS connection established from ::ffff:10.0.4.12 port 55588: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_caps_process_order: not enough orders supported by client, using painter.
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_caps_process_pointer: client supports new(color) cursor
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_caps_process_glyphcache: support level 0
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_process_offscreen_bmpcache: support level 1 cache size 7864320 MB cache entries 2000
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_caps_process_surface_cmds:
Sep 07 17:13:36 zipper xrdp[2840]:   cmdFlags 0x00000052
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_caps_process_frame_ack:
Sep 07 17:13:36 zipper xrdp[2840]:   max_unacknowledged_frame_count 2
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_caps_process_confirm_active: not enough orders supported by client, client wants off screen bitmap but offscreen bitmaps disabled
Sep 07 17:13:36 zipper xrdp[2840]: yeah, up_and_running
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_channel_drdynvc_start:
Sep 07 17:13:36 zipper xrdp[2840]: xrdp:xrdp_bitmap [1763781497]: xrdp_bitmap_create: noorders
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:35] [DEBUG] xrdp_00000b18_wm_login_mode_event_00000001
Sep 07 17:13:36 zipper xrdp[2840]: xrdp:xrdp_mm [1763781501]: xrdp_mm_create: bpp 32 mcs_connection_type 6 jpeg_codec_id 0 v3_codec_id 0 rfx_codec_id 0 h264_codec_id 0
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:35] [INFO ] Loading keymap file /nix/store/0jw9ccf0wjh0rj9b389wb5y1c7qqr24w-xrdp.conf/km-00000407.ini
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:35] [WARN ] local keymap file for 0x00000407 found and doesn't match built in keymap, using local keymap file
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_wm_login_mode_changed: login_mode is 0
Sep 07 17:13:36 zipper xrdp[2840]: in xrdp_wm_init:
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_wm_init: channel rdpdr channel id 0 is allowed
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_wm_init: channel rdpsnd channel id 1 is allowed
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_wm_init: channel cliprdr channel id 2 is allowed
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_wm_init: channel drdynvc channel id 3 is allowed
Sep 07 17:13:36 zipper xrdp[2840]: out xrdp_wm_init:
Sep 07 17:13:36 zipper xrdp[2840]: xrdp_wm_login_mode_changed: login_mode is 2
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:35] [DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 3350
Sep 07 17:13:36 zipper xrdp[2840]: connecting to sesman ip 127.0.0.1 port 3350
Sep 07 17:13:36 zipper xrdp[2840]: [20200907-17:13:36] [INFO ] xrdp_wm_log_msg: sesman connect ok
Sep 07 17:13:36 zipper xrdp[2840]: sesman connect ok

I believe remote desktop on gnome is builtin without using the xrdp.
We instead use pipewire and gnome3.gnome-remote-desktop.
services.gnome3.gnome-remote-desktop = true;

But I don't think pantheon has support for this (or I've never tested it).
My main hunch is, if it was support and could work, I haven't backported latest pipewire support to pantheon's fork of mutter, so it will be broken.

And I think plasma should be using pipewire at this point also.

authors: davidak worldofpeace


text:
littlegptracker: unstable-2019-04-14 -> unstable-2020-11-26, remove upstreamed patch

Motivation for this change
The second patch was just upstreamed
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 105062 run on x86_64-linux 1

1 package built:

littlegptracker

Result of nixpkgs-review pr 105062 run on x86_64-darwin 1

1 package marked as broken and skipped:

littlegptracker

source: gharchive/pull-request


text:
Synchronize cross-stdenv LLVM input with pkgs.llvmPackages

Motivation for this change
Refer to the unversioned llvmPackages in pkgs/stdenv/cross/default.nix so that it can overriden via an overlay. As a prerequisite llvmPackages must be updated for consistency with the current cross LLVM.

I imagine this is a big change for Darwin? And you might want to bump the llvmPackages_7 in the darwin stdenv to llvmPackages_8 too. (Unfortunately it must keep the hard-coded number.)
CC @NixOS/darwin-maintainers

Actually I can override which LLVM I have in stdenv with final: prev: { stdenv = if x then final.llvmPackages_42.stdenv else prev.stdenv }.
I don't need this change then, but since I've pinged everyone, is there a related cleanup here that I can make?

I probably should have opened an issue rather than a PR.

I imagine this is a big change for Darwin? And you might want to bump the llvmPackages_7 in the darwin stdenv to llvmPackages_8 too. (Unfortunately it must keep the hard-coded number.)

Would it be better to downgrade the cross LLVM to llvmPackages_7 using the current llvmPackages alias, and whomever needs llvmPackages_8 can make an override somewhere?

WASM won't work with LLVM 7 IIRC.

Related https://discourse.nixos.org/t/cross-compiling-with-clang-for-risc-v/6683

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/cross-compiling-with-clang-for-risc-v/6683/7

I've rewritten the PR to make the llvmPackages version explicit for some platforms in all-packages.nix, seems like the most transparent thing to do.

I've rewritten the PR to make the llvmPackages version explicit for some platforms in all-packages.nix, seems like the most transparent thing to do.

ping @Ericson2314

ping @Ericson2314

@ehmry hehe nice escape hatch! Also I suppose we could send to maser too? I meant to not merge and post that instead haha.

@ehmry hehe nice escape hatch! Also I suppose we could send to maser too? I meant to not merge and post that instead haha.

@Ericson2314 yes, that would be great, this gets me closer to building Genode using an overlay against nixpkgs master.

@Ericson2314 yes, that would be great, this gets me closer to building Genode using an overlay against nixpkgs master.

Done.

Done.

Do you know how I would override this attribute? I'd like to bump the version of llvmPackages for riscv64 (since llvm 7 doesn't exist for that platform) but I'm not sure where to bump it.

If you can use a overlay I would do this:
final: prev:
with prev; {
  llvmPackages =
    if targetPlatform.isRiscV then llvmPackages_latest else llvmPackages;
}

Actually I think hostPlatform.isRiscV is what you want.

you probably want if hostPlatform.isRiscV || targetPlatform.isRiscV: it's target for the tools but host for the libraries, but the versions of each ought to be in sync too.

authors: DieracDelta Ericson2314 ehmry nixos-discourse


text:
varscan: 2.4.2 -> 2.4.4

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 108437 1

1 package built:

varscan

Result of nixpkgs-review pr 108437 1

1 package built:

varscan

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108437 run on x86_64-linux 1

1 package built:

varscan

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108437 run on x86_64-linux 1

1 package built:

varscan

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108437 run on x86_64-darwin 1

1 package built:

varscan

authors: SuperSandro2000 fabaff jbedo


text:
musl fixes

Motivation for this change
With these changes I can build not-os with musl.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

build on e06355f (#115841):
builder for '/nix/store/6m1bcxxzrx7xxhigazvn33bxyj09jakd-systemtap-4.1.drv' failed with exit code 1; last 25 log lines:                                                         checking to see if sdt probes should be the default... yes                                                                                checking whether g++ supports C++11 features by default... yes                                                                                configure: Compiling with gcc -fstack-protector-all et al.                                                                                checking pkg-config is at least version 0.9.0... yes                                                                                checking for sqlite3... no                                                                                checking for latex... no                                                                                checking for dvips... no                                                                                checking for ps2pdf... no                                                                                configure: will only install prebuilt documentation                                                                                checking for xmlto... no                                                                                checking for fop... no                                                                                checking for nss... no                                                                                checking for openssl... no                                                                                configure: using dracut module directory /usr/lib/dracut/modules.d/99stap                                                                                configure: using dracut binary /sbin                                                                                configure: WARNING: will not build systemtap compile server, cannot find nss headers                                                                                configure: WARNING: compile-server client functionality will be disabled, cannot find nss development files                                                                   checking for avahi... no                                                                                configure: WARNING: some compile-server functionality will be restricted, cannot find avahi development files                                                                 checking for rpmtsInitIterator in -lrpm... no
  checking for rpmdbNextIterator in -lrpmdb... no
  checking for rpmFreeCrypto in -lrpmio... no
  checking how to link readline libs... none
  configure: error: python version 2 is required

I removed the systemtap change again.

Not really sure what is happening here:
error: --- ParseError ---------------------------------------------------------------------------------------------------------------------------------------------------- nixat: (23:5) in file: /home/hotpi/.cache/nixpkgs-review/pr-115841-4/nixpkgs/pkgs/os-specific/windows/mcfgthreads/default.nix

    22|     substituteInPlace Makefile.am --replace '-Werror' ''
    23|   '';
      |     ^
    24|

syntax error, unexpected end of file, expecting IND_STR or DOLLAR_CURLY or IND_STRING_CLOSE
(use '--show-trace' to show detailed location information)
nix --experimental-features nix-command eval --json --impure --expr (import /nix/store/v9bjqm0wzg71cq0cgcwsc5s4fj5mb5j4-nixpkgs-review-2.5.0/lib/python3.8/site-packages/nixpkgs_review/nix/evalAttrs.nix /run/user/1000/tmpnmnks6ui) failed to run, /run/user/1000/tmpnmnks6ui was stored inspection
https://github.com/NixOS/nixpkgs/pull/115841 failed to build

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 115841 run on x86_64-linux 1

4 packages failed to build and are new build failures:

lvm2: log was empty
pcsclite: log was empty
procps-ng: log was empty
util-linux: log was empty

4 packages built:

argp-standalone
aws-sdk-cpp
libsmbios
nix

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:

argp-standalone:

warning: unclear-gpl
gpl2 is a deprecated license, check if project uses gpl2Plus or gpl2Only and change meta.license accordingly.
Near pkgs/development/libraries/argp-standalone/default.nix:32:5:
   |
32 |     license = licenses.gpl2;
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/unclear-gpl.md

@Mic92 please resolve the merge conflict and target staging

done.

@Mic92 ofborg still fails but I am not sure why:
install flags: SHELL=/nix/store/wq541npf2ni6gcwdwpjm8m01kdvycfkg-bash-4.4-p23/bin/bash install
  /nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl//bin/ash -> busybox
  /nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl//bin/sh -> busybox
patching script interpreter paths in /nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl/default.script
/nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl/default.script: interpreter directive changed from "#!/bin/sh" to "/nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl/bin/sh"
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl
shrinking /nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl/bin/busybox
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
aarch64-unknown-linux-musl-strip is /nix/store/ygzwsvvxv336im1mi019ikp6si8j6ijc-aarch64-unknown-linux-musl-binutils-2.35.1/bin/aarch64-unknown-linux-musl-strip
stripping (with command aarch64-unknown-linux-musl-strip and flags -S) in /nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl/bin
patching script interpreter paths in /nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl
checking for references to /build/ in /nix/store/73ml7a20janvsmnmg0xyvvj0vgwpaz6r-busybox-1.32.1-aarch64-unknown-linux-musl...
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
error: 5 dependencies of derivation '/nix/store/j5f8y0mq9vlvf0qjq1iwjwwv2rkr7dga-nix-2.3.10.drv' failed to build
error: 3 dependencies of derivation '/nix/store/9lw3b09j20g9b39mnlp31b04qrncdi0m-pcsclite-1.9.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/ijq7f1z6sfi76mwqr2zhmh8j6qv6ql46-util-linux-2.36.1.drv' failed to build
error: 8 dependencies of derivation '/nix/store/7q77c2az5mqfbbkjgmid64i15qlgmfky-aws-sdk-cpp-1.8.121.drv' failed to build
error: build of '/nix/store/7q77c2az5mqfbbkjgmid64i15qlgmfky-aws-sdk-cpp-1.8.121.drv', '/nix/store/9lw3b09j20g9b39mnlp31b04qrncdi0m-pcsclite-1.9.1.drv', '/nix/store/ijq7f1z6sfi76mwqr2zhmh8j6qv6ql46-util-linux-2.36.1.drv', '/nix/store/j5f8y0mq9vlvf0qjq1iwjwwv2rkr7dga-nix-2.3.10.drv', '/nix/store/z564jpg8khis8i21gh0bnmpsgc6gfp42-lvm2-2.03.11.drv' failed

I actually only tested x86 musl. I have not tested aarch64.


text:
mtools: 4.0.26 -> 4.0.27

Motivation for this change
https://lists.gnu.org/archive/html/info-gnu/2021-04/msg00002.html
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 119693 at 63eda681 run on x86_64-linux 1

1 package marked as broken and skipped:

multibootusb

9 packages built successfully:

fwanalyzer
fwup
gnome3.gnome-boxes
ipxe
memtest86-efi
mtools
syslinux
unetbootin
wimlib

2 suggestions:

warning: maintainers-missing
Package does not have a maintainer. Consider adding yourself?
Near pkgs/tools/filesystems/mtools/default.nix:19:3:
   |
19 |   meta = with lib; {
   |   ^

warning: unclear-gpl
gpl3 is a deprecated license, please check if project uses gpl3Plus or gpl3Only and change meta.license accordingly.
Near pkgs/tools/filesystems/mtools/default.nix:23:5:
   |
23 |     license = licenses.gpl3;
   |     ^

authors: lsix r-rmcgibbo


text:
lib.licenses: cleanup, consistency and redistributable attribute

Motivation for this change

Application of common attributes was not expandable
free and deprecated were only set on licenses where they're false and true respectively
https://github.com/NixOS/nixpkgs/issues/83884 needs the ability to know whether a package is redistributable

Future work: Make hydra look for redistributable instead of free.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

cc @mkg20001

/marvin opt-in
/status needs_reviewer

Thanks!


text:
pantheon.switchboard-plug-sound: 2.2.5 -> 2.2.7

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for pantheon.switchboard-plug-sound is: "Switchboard Sound Plug"
meta.homepage for pantheon.switchboard-plug-sound is: "https://github.com/elementary/switchboard-plug-sound"
meta.changelog for pantheon.switchboard-plug-sound is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.2.7 with grep in /nix/store/dryn3jdsvpy7sqz1jpj6wcf5aznwaacd-switchboard-plug-sound-2.2.7

found 2.2.7 in filename of file in /nix/store/dryn3jdsvpy7sqz1jpj6wcf5aznwaacd-switchboard-plug-sound-2.2.7

directory tree listing: https://gist.github.com/e05b63a4a29e0f92e87b2cbb5ddd4615

du listing: https://gist.github.com/f0a987b9be230445efea434cb272d2e7

Rebuild report (if merged into master) (click to expand)

15 total rebuild path(s)

5 package rebuild(s)

5 x86_64-linux rebuild(s)
5 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
5 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
pantheon.elementary-greeter
pantheon.switchboard-plug-sound
pantheon.switchboard-with-plugs
pantheon.wingpanel-applications-menu
pantheon.wingpanel-with-indicators

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/dryn3jdsvpy7sqz1jpj6wcf5aznwaacd-switchboard-plug-sound-2.2.7 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A pantheon.switchboard-plug-sound https://github.com/r-ryantm/nixpkgs/archive/97c0d90a955c512d6b44246126a6e377abe0d19e.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/dryn3jdsvpy7sqz1jpj6wcf5aznwaacd-switchboard-plug-sound-2.2.7
ls -la /nix/store/dryn3jdsvpy7sqz1jpj6wcf5aznwaacd-switchboard-plug-sound-2.2.7/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @davidak @bobby285271 for testing.

Duplicate of #130380.

Result of nixpkgs-review pr 134885 at 97c0d90a run on x86_64-linux 1

5 packages built successfully:

pantheon.elementary-greeter
pantheon.switchboard-plug-sound
pantheon.switchboard-with-plugs
pantheon.wingpanel-applications-menu
pantheon.wingpanel-with-indicators

Thank you @SuperSandro2000!

authors: davidak r-rmcgibbo r-ryantm


text:
weylus: init at 0.11.2 & nixos/weylus: init

https://github.com/H-M-H/Weylus
Motivation for this change
Adds the weylus package and module, which allows you to use your tablet as an input device for your computer; Similar to Wacom drawing boards.
It's not a binary source package due to the build process being very complex, having to compile ffmpeg and headers for graphics from source separately. I tried packaging it source based but it ended up looking something like this, and even this failed to build: https://github.com/legendofmiracles/nixpkgs/commit/3689ae97319418fd56aba0f16677f5fcf27ae27b
The GUI starts on both xorg (my display server) and wayland (tested by changing the sway nixos test a bit)
How should I add the program to the release notes? All current release notes are only services.*.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ? ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 135284 at fbe22985 run on x86_64-linux 1

2 packages built successfully:

nixos-install-tools
weylus

2 suggestions:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/applications/graphics/weylus/default.nix:26:3:
   |
26 |   installPhase = ''
   |   ^

warning: unused-argument
Unused argument: ffmpeg.
Near pkgs/applications/graphics/weylus/default.nix:4:3:
  |
4 | , ffmpeg
  |   ^

Suggestions of the bot applied.

You're not actually running the software..

That's because it's not a service, but a GUI program the user has to start themselves. The module only exists because the user has to be added to a special group and uinput has to be enabled for the stylus to work. (As described here: https://github.com/H-M-H/Weylus#linux)
Thanks for the feedback! I don't think that there are more options that are missing.
There is a config file, but it's expected to be in the users home directory so there's only so much nix can do.

Sorry I missed that this runs as a gui application. Thanks!

@SuperSandro2000 update on the package part?

authors: aanderse legendofmiracles r-rmcgibbo


text:
kmod: 27 -> 29

Motivation for this change
Updating kmod to 29. Version 28 introduces zstd support and kmod is now built with it. One of the patches was removed, because a similar change is upstream.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

ah some version of the patch did land after all :+1:

I think this should probably go to staging.

Ok, will change to staging, but I need to fix the darwin patch first.

authors: abdelq alyssais xaverdh


text:
stdenv: simplify nix_build_core guess

Motivation for this change

rely on a bash builtin rather than the external exp
simplify the logic

This can be tested with the following script
NIX_BUILD_CORES=4
NIX_BUILD_CORES="${NIX_BUILD_CORES:-1}"
if ((NIX_BUILD_CORES <= 0 )); then
  GUESS=$(nproc 2>/dev/null || true)
  NUMERIC_GUESS="${GUESS//[^0-9]/}"
  NIX_BUILD_CORES="${NUMERIC_GUESS:-1}"
fi
echo $NIX_BUILD_CORES

replace the first assignement with potential initial values.
4, 1, 0, -1, abcd
all lead to the correct NIX_BUILD_CORES value.
I know this doesn't matter in the grand scheme of things, just trying in case people agree.
@7c6f434c you've been kind enough to review some bash before.
@andersk you've been very knowledgeable about shell
No worries if you don't have time.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

I've used a lowercase for guess, and applied the suggested change. Let me know if anything else.
This is much better, thanks a lot!

I've squashed and rebased, leaving this open one more day in case anyone wants to have another look.

There is a darwin failure on the CI but it doesn't appear to be related to this. I'm going to check that failure first.


text:
ntttcp: init at 1.4.0

Motivation for this change
Packaging a useful network throughput testing tool not currently in nixpkgs.
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 137643 run on x86_64-linux 1

1 package built:

ntttcp

authors: delroth figsoda


text:
plasma5: 5.23.3 -> 5.23.4

Motivation for this change
Simple version bump for KDE Plasma5 desktop.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Seems to be working nicely. This also fixes an annoying issue where certain applications launch with a 1x1 window size so I'd love to get it merged sooner rather than later.

authors: andrevmatos jansol


text:
Remove applications that depend on python2Packages (Part 2)

Motivation for this change
https://github.com/NixOS/nixpkgs/issues/148779
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@thoughtpolice opae still fails to build, PTAL.

blink: @pSub
curaByDagoma: @tiramiseb
neap: @romildo
metamorphose2: @RamKromberg
lumpy: @jbedo
cvs2svn: @makefu
gitinspector: @bjornfor
ino: @antono
getmail: @7c6f434c
displaycal: @MarcWeber

You can remove curaByDagoma. I'm not using it anymore and I bet nobody else ever did.

thanks for the cleanup!

Not aware of any benefit of getmail over getmail6 now that I look at this pair in Nixpkgs…

Tailor and csv2svn (that is also cvs2git) seem useful and trivial to fix via PyPy2. #154752

Should we turn getmail into an alias for getmail6 or suggest using getmail6 in the appropriate throw?

Upstream promises to be drop-in replacement, so I guess alias could be fine.

Not aware of any benefit of getmail over getmail6 now that I look at this pair in Nixpkgs…

Should we turn getmail into an alias for getmail6 or suggest using getmail6 in the appropriate throw?

I did the latter.

Result of nixpkgs-review pr 154697 run on x86_64-linux 1

13 packages marked as broken and skipped:

linuxKernel.packages.hardkernel_4_14.perf
linuxKernel.packages.hardkernel_4_14.systemtap
linuxKernel.packages.linux_4_14.perf
linuxKernel.packages.linux_4_14_hardened.perf
linuxKernel.packages.linux_4_19.perf
linuxKernel.packages.linux_4_19_hardened.perf
linuxKernel.packages.linux_4_4.perf
linuxKernel.packages.linux_4_9.perf
linuxPackages_4_14_hardened.perf
linuxPackages_4_19_hardened.perf
linuxPackages_hardkernel_latest.perf
linuxPackages_hardkernel_latest.systemtap
tlspool

2 packages blacklisted:

nixos-install-tools
tests.nixos-functions.nixos-test

5 packages failed to build:

opae
python310Packages.cartopy
python310Packages.fiona
python310Packages.geopandas
python310Packages.osmnx

48 packages built:

cargo-flamegraph
digikam
enblend-enfuse
gdal_2
git-crecord
hugin
linuxKernel.packages.linux_4_14.systemtap
linuxPackages_4_14_hardened.systemtap (linuxKernel.packages.linux_4_14_hardened.systemtap)
linuxKernel.packages.linux_4_19.systemtap
linuxPackages_4_19_hardened.systemtap (linuxKernel.packages.linux_4_19_hardened.systemtap)
linuxKernel.packages.linux_4_4.systemtap
linuxKernel.packages.linux_4_9.systemtap
linuxPackages.perf (linuxKernel.packages.linux_5_10.perf)
linuxPackages.systemtap (linuxKernel.packages.linux_5_10.systemtap)
linuxPackages_hardened.perf (linuxPackages_5_10_hardened.perf)
linuxPackages_hardened.systemtap (linuxPackages_5_10_hardened.systemtap)
linuxKernel.packages.linux_5_15.perf
linuxKernel.packages.linux_5_15.systemtap
linuxPackages_5_15_hardened.perf (linuxKernel.packages.linux_5_15_hardened.perf)
linuxPackages_5_15_hardened.systemtap (linuxKernel.packages.linux_5_15_hardened.systemtap)
linuxPackages_latest.perf (linuxKernel.packages.linux_5_16.perf)
linuxPackages_latest.systemtap (linuxKernel.packages.linux_5_16.systemtap)
linuxKernel.packages.linux_5_4.perf
linuxKernel.packages.linux_5_4.systemtap
linuxPackages_5_4_hardened.perf (linuxKernel.packages.linux_5_4_hardened.perf)
linuxPackages_5_4_hardened.systemtap (linuxKernel.packages.linux_5_4_hardened.systemtap)
linuxPackages_latest-libre.perf (linuxKernel.packages.linux_latest_libre.perf)
linuxPackages_latest-libre.systemtap (linuxKernel.packages.linux_latest_libre.systemtap)
linuxPackages-libre.perf (linuxKernel.packages.linux_libre.perf)
linuxPackages-libre.systemtap (linuxKernel.packages.linux_libre.systemtap)
linuxPackages_lqx.perf (linuxKernel.packages.linux_lqx.perf)
linuxPackages_lqx.systemtap (linuxKernel.packages.linux_lqx.systemtap)
linuxPackages_testing_bcachefs.perf (linuxKernel.packages.linux_testing_bcachefs.perf)
linuxPackages_testing_bcachefs.systemtap (linuxKernel.packages.linux_testing_bcachefs.systemtap)
linuxPackages_xanmod.perf (linuxKernel.packages.linux_xanmod.perf)
linuxPackages_xanmod.systemtap (linuxKernel.packages.linux_xanmod.systemtap)
linuxPackages_zen.perf (linuxKernel.packages.linux_zen.perf)
linuxPackages_zen.systemtap (linuxKernel.packages.linux_zen.systemtap)
python310Packages.rasterio
python39Packages.cartopy
python39Packages.fiona
python39Packages.geopandas
python39Packages.osmnx
python39Packages.rasterio
qtcreator
quickder
saga
vigra

While I still often use metamorphose2, I can make due with scripts and such so feel free to drop it if it's holding back the python2 deprecation and no one else raises objections.

@dotlambda Done.

@mweinelt Opae doesn't build. How did you test that it works with Python 3?

Mentioned in https://github.com/NixOS/nixpkgs/pull/154697#issuecomment-1010596920.
Previously:
❯ nix-build -A opae
error: pytest-forked-1.4.0 not supported for interpreter python2.7

So we don't loose anything either way.

So we don't loose anything either way.

But if it doesn't work Python 3 (we don't know whether it does) it should be removed instead.

It is maintained upstream and probably just needs a maintainer update.
https://github.com/OPAE/opae-sdk

I'm ok with removing lumpy, python 3 support has been an open issue since 2016 https://github.com/arq5x/lumpy-sv/issues/124.

authors: 7c6f434c RamKromberg dotlambda jbedo makefu mweinelt tiramiseb


text:
python310Packages.oci: 2.60.0 -> 2.60.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.oci is: "Oracle Cloud Infrastructure Python SDK"
meta.homepage for python310Packages.oci is: "https://oracle-cloud-infrastructure-python-sdk.readthedocs.io/"
meta.changelog for python310Packages.oci is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.60.1 with grep in /nix/store/knnw07ql1dhqj6afsqsyrg9k0n8rws2h-python3.10-oci-2.60.1

found 2.60.1 in filename of file in /nix/store/knnw07ql1dhqj6afsqsyrg9k0n8rws2h-python3.10-oci-2.60.1

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

4 package rebuild(s)

4 x86_64-linux rebuild(s)
4 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
lexicon
oci-cli
python310Packages.oci
python39Packages.oci

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/knnw07ql1dhqj6afsqsyrg9k0n8rws2h-python3.10-oci-2.60.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.oci https://github.com/r-ryantm/nixpkgs/archive/9dfcd7e746474227608f58faeb92faecef191620.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/knnw07ql1dhqj6afsqsyrg9k0n8rws2h-python3.10-oci-2.60.1
ls -la /nix/store/knnw07ql1dhqj6afsqsyrg9k0n8rws2h-python3.10-oci-2.60.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

oci-cli

3 packages built:

lexicon
python310Packages.oci
python39Packages.oci

Maintainer pings
cc @ilian for testing.

seems like oci-cli and this package need to be updated at the same time


text:
python3Packages.pygame: fix build

Description of changes
This fixes the pygame build by adding the include/SDL2 directory to the include path. Fixes https://github.com/NixOS/nixpkgs/issues/160150#issuecomment-1076976373 as well as pygame builds in general.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@ofborg build python3Packages.pygame

authors: Infinisil ModdedGamers


text:
gitea: patch for CVE-2022-0905, CVE-2022-1058

Description of changes
Patch gitea for known vulnerabilities: https://github.com/NixOS/nixpkgs/issues/166640
Things done

Built on platform(s)

[x] x86_64-linux (NixOS)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested with nixosTests.gitea
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

I also had it on my radar, but nice that you took care of it @rnhmjoj!
@techknowlogick would you mind checking this as well? I recall you mentioned that applying these patches caused some additional issues.
Anyways, let's run the tests to see if there's something obvious.
@ofborg test gitea

Can you also include the following, as these patches also belong to security issues from other 1.16.x releases

Can you add comments that links to an issue/CVE? I'm not sure what they are about without these.

Can you add comments that links to an issue/CVE? I'm not sure what they are about without these.

Yup, I've updated with links to the PR. CVE's have been requested, but as we (the gitea project) are not a CNA we can't issue them ourselves

The last three patches don't apply cleanly to this version.

I think we should merge this as is: more patches can be added later and at least two vulnerabilities are done.

@ofborg eval

authors: Ma27 cole-h rnhmjoj techknowlogick


text:
dgoss: 0.3.16 -> 0.3.18

Description of changes
Release notes: https://github.com/aelsabbahy/goss/releases/tag/v0.3.18
Container backend is now configurable via the environment variable $CONTAINER_RUNTIME, which enables support of podman instead of docker.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Thanks for the reviews!


text:
rtl8188fu: init at 2022-06-11

Description of changes
Fixes #91124
The repo was archived, for some reason, last month:
https://github.com/kelebek333/rtl8188fu
But it was the only active fork with compatibility above Linux 5.10
I have been using this driver on an ARM device for almost a month. It's not great, but it does mostly work.
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

From the README:

info: rtl8188fu support added to rtl8xxxu module of Linux kernel with version 6.2.

However, we do support kernels that are below that version.

The repo was archived, for some reason, last month:

It looks like this is no longer the case (which is good!).

As far as getting this PR landed, a rebase would go a long way. Additionally, there are some new patterns and conventions (finalAttrs, nixfmt) that have been introduced after this PR was created; I'll review this when I have a moment.

Also I think new firmware should be under linuxPackages, so the commit and PR titles should be linuxPackages.rtl8188fu: init at 0-unstable-2022-06-11

authors: pluiedev puffnfresh tomodachi94


text:
python310Packages.paranoid-crypto: init at unstable-20220819

Description of changes
Library contains checks for well known weaknesses on cryptographic artifacts
https://github.com/google/paranoid_crypto
Related to https://github.com/NixOS/nixpkgs/issues/81418

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 188020 run on x86_64-linux 1

2 packages built:

python310Packages.paranoid-crypto
python39Packages.paranoid-crypto


text:
vimPlugins.command-t: fix build on darwin

Description of changes
fixes #193617 @lilyball

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 194240 run on aarch64-darwin 1

1 package built:

vimPlugins.command-t


text:
nixos/kubo: make the configuration options idempotent

Description of changes
Without this commit, unsetting any of the services.kubo.settings options does not reset the value back to the default. This commit gets rid of this statefulness.
This is achieved by generating the default config, applying the user specified config options to it and then patching the Identity and Pinning config options from the old config back in. This new config is then applied using ipfs config replace.
The only remaining stateful parts of the config are the Identity and Pinning.RemoteServices settings as those can't be changed with ipfs config replace. Pinning.RemoteServices also contains secrets that shouldn't be in the Nix store. Setting these options wasn't possible before as it would result in an error when the daemon tried to start. I added some assertions to guard against this case.
I tested this on my NixOS server.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[x] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[x] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1363

I resolved the conflict in nixos/doc/manual/from_md/release-notes/rl-2305.section.xml.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/820

This is nice conceptually, but:

it uses IFD, which is unfortunate
the defaultConfig logic makes it very annoying to override complex settings (in particular, Datastore for badgerds use) due to recursiveUpdate

To get rid of IFD, one would need to filter out Identity and Pinning with jq and then somehow rewrite systemd.services.ipfs.preStart to do the merge instead of using lib.recursiveUpdate for that. Do you think you can get rid of IFD here? I can probably do the first part but I'm not sure about the second part. I know that IFD is strongly discouraged in Nixpkgs but this seemed like the best way at the time. Did you notice any of the disadvantages of IFD or did you say it is "unfortunate" just because it is to be avoided out of principle?
I hadn't thought about the use-case of changing the Datastore to use badgerds. What would be the best way to make this easier? Maybe by somehow allowing to set profile to badgerds? Any other suggestions?

authors: Luflosi max-privatevoid nixos-discourse


text:
carapace: 0.18.0 -> 0.18.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/carapace/versions.
meta.description for carapace is: "Multi-shell multi-command argument completer"
meta.homepage for carapace is: "https://rsteube.github.io/carapace-bin/"
meta.changelog for carapace is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.18.1 in filename of file in /nix/store/1zd011bif9grzmaa71l8b6p9639vmmjb-carapace-0.18.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
carapace

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/1zd011bif9grzmaa71l8b6p9639vmmjb-carapace-0.18.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A carapace https://github.com/r-ryantm/nixpkgs/archive/a7db653b05e31619f90c2501cff04f87424bad49.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/1zd011bif9grzmaa71l8b6p9639vmmjb-carapace-0.18.1
ls -la /nix/store/1zd011bif9grzmaa71l8b6p9639vmmjb-carapace-0.18.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

carapace

Maintainer pings
cc @mredaelli for testing.

@ofborg eval

authors: r-ryantm raphaelr


text:
swagger-codegen3: 3.0.35 -> 3.0.36

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/swagger-codegen/versions.
meta.description for swagger-codegen3 is: "Allows generation of API client libraries (SDK generation), server stubs and documentation automatically given an OpenAPI Spec"
meta.homepage for swagger-codegen3 is: "https://github.com/swagger-api/swagger-codegen/tree/3.0.0"
meta.changelog for swagger-codegen3 is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.0.36 with grep in /nix/store/rjl0qvz7iskaqjc8wxbj0rgi8p0zc191-swagger-codegen-3.0.36
found 3.0.36 in filename of file in /nix/store/rjl0qvz7iskaqjc8wxbj0rgi8p0zc191-swagger-codegen-3.0.36

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
swagger-codegen3

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/rjl0qvz7iskaqjc8wxbj0rgi8p0zc191-swagger-codegen-3.0.36 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A swagger-codegen3 https://github.com/r-ryantm/nixpkgs/archive/9344a238f7e0dbbfa5d6e5eb911d273c9343bcce.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/rjl0qvz7iskaqjc8wxbj0rgi8p0zc191-swagger-codegen-3.0.36
ls -la /nix/store/rjl0qvz7iskaqjc8wxbj0rgi8p0zc191-swagger-codegen-3.0.36/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

swagger-codegen3

Maintainer pings
cc @1000101 for testing.

@ofborg eval

@ofborg build swagger-codegen3 swagger-codegen3.passthru.tests

authors: cole-h r-ryantm wegank


text:
python310Packages.pylsp-mypy: 0.6.4 -> 0.6.5

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.pylsp-mypy is: Mypy plugin for the Python LSP Server
meta.homepage for python310Packages.pylsp-mypy is: https://github.com/Richardk2n/pylsp-mypy
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.6.5 with grep in /nix/store/yi9l4hdll9lyc93k41j00lxgry52zlvl-python3.10-pylsp-mypy-0.6.5
found 0.6.5 in filename of file in /nix/store/yi9l4hdll9lyc93k41j00lxgry52zlvl-python3.10-pylsp-mypy-0.6.5

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
python310Packages.pylsp-mypy
python311Packages.pylsp-mypy

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/yi9l4hdll9lyc93k41j00lxgry52zlvl-python3.10-pylsp-mypy-0.6.5 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.pylsp-mypy https://github.com/r-ryantm/nixpkgs/archive/ab9efae911964d48812d1310d8f23fc0fde70acf.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/yi9l4hdll9lyc93k41j00lxgry52zlvl-python3.10-pylsp-mypy-0.6.5
ls -la /nix/store/yi9l4hdll9lyc93k41j00lxgry52zlvl-python3.10-pylsp-mypy-0.6.5/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

python311Packages.pylsp-mypy

1 package built:

python310Packages.pylsp-mypy

Maintainer pings
cc @cpcloud for testing.

Result of nixpkgs-review pr 212178 run on x86_64-linux 1

1 package failed to build:

python311Packages.pylsp-mypy

1 package built:

python310Packages.pylsp-mypy

authors: onny r-ryantm


text:
rke2: 1.26.3+rke2r1 -> 1.26.4+rke2r1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/rancher/rke2/releases.
meta.description for rke2 is: RKE2, also known as RKE Government, is Rancher's next-generation Kubernetes distribution.
meta.homepage for rke2 is: https://github.com/rancher/rke2
meta.changelog for rke2 is: https://github.com/rancher/rke2/releases/tag/v1.26.4+rke2r1
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.26.4+rke2r1 with grep in /nix/store/s4517n9aflkfwwihfc5y6wsmd70wkdzk-rke2-1.26.4+rke2r1
found 1.26.4+rke2r1 in filename of file in /nix/store/s4517n9aflkfwwihfc5y6wsmd70wkdzk-rke2-1.26.4+rke2r1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
rke2

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/s4517n9aflkfwwihfc5y6wsmd70wkdzk-rke2-1.26.4+rke2r1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rke2 https://github.com/r-ryantm/nixpkgs/archive/537cb55cdd20d7e813a65890b79fccae85be9b35.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/s4517n9aflkfwwihfc5y6wsmd70wkdzk-rke2-1.26.4+rke2r1
ls -la /nix/store/s4517n9aflkfwwihfc5y6wsmd70wkdzk-rke2-1.26.4+rke2r1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

rke2

Maintainer pings
cc @stefan-bordei for testing.

As v1.26.3+rke2r1 is still the latest release tag I would prefer to hold on until we update the nixpkgs with v1.26.4+rke2r1 for this package.
If any of the mods feel different about this please feel free to merge this PR.
Thank you!

I think the upstream just forgot to update the tag, so LGTM.
Ideally, we would upgrade to 1.27, since kubernetes is at version 1.27.0 in nixpkgs.

That makes sense. I will be able to test the build locally early next week.
As previously mentioned, if any mod is happy with this PR it can be merged in the meantime. (anyway I don't have the option to merge it) :)
Thank you!

authors: r-ryantm stefan-bordei wegank


text:
mysql57: Add developer_cmds as build input on darwin

Motivation for this change
I was not able to build it on my Macbook. Found this issue after a small investigation.
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

cc @LnL7

authors: grahamc johbo


text:
Quote paths in makeWrapper

Motivation for this change
Fixes https://github.com/NixOS/nixpkgs/pull/22962#commitcomment-21144939
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

With this blink builds correctly. cc @rnhmjoj

Thank you

Would it be possible to add some tests for cases that failed before and are now fixed?

I'm not sure where nixpkgs tests are supposed to go but we definitely want to run tests for this, with as evil paths as possible :3

Sadly nowhere yet, but I might have something in the pipeline about that. ;)

you don't need evil test cases, use shellcheck :)
Can you run shellcheck against the script and see what it says?

@grahamc I feel ashamed always forgetting about this wonderful tool. Helped fix some more problems, thanks!

The commit broke firewall tests and consequently blocks nixos-unstable*.  I've got no idea why ATM (bisected).  They fail with:
starting VDE switch for network 1
running the VM test script
error: Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 1.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 4.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 5.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 9.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 16.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 17.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 20.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 24.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 1.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 4.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 5.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 9.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 16.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 17.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 20.
Global symbol "$walled" requires explicit package name (did you forget to declare "my $walled"?) at (eval 15) line 24.
vde_switch: EOF on stdin, cleaning up and exiting
cleaning up

There is some broken code in lib/testing.nix relying on old makeWrapper behaviour. I'm trying to fix that but stumbled into another Bashism:
$ foo=(a b c)
$ echo ${foo[@]}
a b c
$ echo "${foo[@]}"
$ # ??????

Ugh, so:
foo=(a b c)
wrapProgram --add-flags "${foo[@]}"

results in an empty argument list. My best guess is that becase wrapProgram is a Bash function, not a program, Bash passes arrays instead of strings and they break inside (because code is obviously not suited to handle arrays).
I made a workaround at https://github.com/abbradar/nixpkgs/commit/4b364130a493b4f9d9d31d489fcf4dc3e8bea735 which fixes this problem but haven't yet pushed it -- maybe some Bash guru knows how to do this more elegantly? (I argue that elegance is a relative concept so it can be applied even to Bash)

Oh, wait, I was just tricked by Bash again. "${foo[@]}" is interpreted as "expand array into separate arguments".

So the correct way to do what I wanted to is ${foo[*]}. Fix is pushed to master (1f0ce0eaf8ca840e769615acc7581bd71268ca44) and release.

This broke buildDotnetPackage see #24387

authors: Profpatsch abbradar globin grahamc rnhmjoj vcunat


text:
clatd: init at 1.6

Description of changes
A CLAT component for 464XLAT: https://github.com/toreanderson/clatd
I will do NixOS module later on and proper testing.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

I built a test for clatd some time ago. Feel free to use. https://github.com/hax404/nixpkgs/commit/6be04700ef7f5441b44102add9dca95b681f7c45

Please ignore this PR given the existence of superior https://github.com/NixOS/nixpkgs/pull/240982 containing a clatd component AFAIK.

Reopened because Jool is actually inferior in practical usecases.


text:
lapce: use upstream .desktop file

Description of changes
Use the more complete .desktop file included upstream, instead of haphazardly making one here.
Untested.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2406

authors: SuperSamus nixos-discourse


text:
lib.generators: add toTOML

Description of changes
TOML is a quite common format for configuration files. This PR introduces a TOML serializer at eval-time. Current pkgs.formats.toml uses remarshal to convert JSON to TOML, which is at runtime and has a large closure size.
Unresolved: A quick grep shows 44 usages of formats.toml. Most of them have input settings known at eval-time, but also use the types defined by formats.toml. Mixing lib.generators.toTOML for serialization and pkgs.formats.toml for types together is kinda messy to me. Not sure if there is a clean way to make them use eval-time toTOML instead.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

I don't agree.

It would increase evaluation time, which is already too slow

It's a eval-time and build-time trade off. And trivial jobs like serializing Nix attrsets into TOML should be cheaper to be done in Nix interpreter, instead of building another derivation, with Nix's JSON serializing, heavy sandboxing, and conversion.

It requires a bunch of Nix code, with tests and documentation, all of which aren't very good to do in Nix

True. If you think docs are not enough, I can fix it, and maybe mention it in nixpkgs manual also.

It requires maintenance, which Nixpkgs is generally fairly poor at

TOML is currently stable since v1, and we will not add new datatypes into Nix. So I don't think there is much to maintain.

If the build-time closure of the generate functions in pkgs.formats is too large, we can always switch it out with a conversion tool that has a smaller footprint, it's really quite flexible.

The main issue is that it is a derivation, a second class object. They are opaque and hard to read (IFD), costly to update (sandboxing), especially when offline. If you have no network access, and the serializer is GC-ed (), you are doomed to keep your current settings forever. This can be catastrophic when the module itself is essential for the network access, like VPN services.

Yeah it's a tradeoff, but derivations should be preferred because:

They can be built in parallel, whereas Nix evaluation is always serial
They can be cached individually, whereas Nix evaluation can't currently

Imo evaluation should only be used when the result is needed at evaluation time, out of necessity, which is not the case for generated configuration files.

If you have no network access, and the serializer is GC-ed (build-time dependency only), you are doomed to keep your current settings forever. This can be catastrophic when the module itself is essential for the network access, like VPN services.

That's a good point, I haven't thought of that. This could be mitigated though:

You can always update configuration files in other ways, e.g. using environment.etc directly, or even without rebuilding by editing /etc directly. And if the config file is just used in a systemd service you could override the services ExecStart.

Ideally the configuration file should always also be exposed as an option, so that you could forcibly override it directly

We could make sure that all formats have the generation tooling as a runtime dependency somehow (lib.addContextFrom? Though that's hacky..)

We were discussing this on Matrix, where @lilyinstarlight made a great point:
To get the property of being able to rebuild a system without internet, keep-outputs = true should work (mostly, Nix GC has some problems).

We were discussing this on Matrix, where @lilyinstarlight made a great point:
To get the property of being able to rebuild a system without internet, keep-outputs = true should work (mostly, Nix GC has some problems).

This is massive. It's almost keeping all compilers on your machine.

Yeah it's a tradeoff, but derivations should be preferred because:
* They can be built in parallel, whereas Nix evaluation is always serial

* They can be cached individually, whereas Nix evaluation can't currently

I have to point out that parallel is not always better, especially for ~40 LoC in Nix which runs < 1ms for any reasonable configuration file. Derivations add a >100ms penalty before doing anything. It's already a pain to cost nixos-rebuild >5s (already longer than the whole evaluation time) on each systemd*service config drvs which are updated on systemPackage change, which again may be caused by a single configuration update.

Hmm you do make a good point, though I also think we could optimise the generators more. Check out https://github.com/NixOS/nixpkgs/pull/248945 where I did that for TOML, maybe you can give it a go?
Still, it might be good to give users at least the option to pick between eval-time and build-time generation for use-cases like these. I think this should then be integrated into pkgs.formats though, e.g. such that there's a standard flag like pkgs.formats.toml { evalTimeGenerator = true; }, instead of having to use lib.generators directly.

A semi-related question. The Home Manager CI recently started failing due to unexpected TOML files being generated. E.g. https://github.com/nix-community/home-manager/actions/runs/6020363476/job/16331559623#step:9:3849
Is that related to this or any similar PR? I was thinking to update the expected output in our tests but thought it would be nice to be able to point to the specific PR / commit that caused the change. Could you help me find the right one?

@rycee This PR is not related. I think this is the cause: https://github.com/NixOS/nixpkgs/pull/245440, also had to be fixed in staging: https://github.com/NixOS/nixpkgs/commit/0782b000d91bab97f62521cbd10974637246b0f8

All the opinions against generators.toTOML under this issue applies to other generators as well. If the opinions are valid, then we should deprecate lib.generators. Is that true?

I don't think it's very necessary or urgent, but I wouldn't be opposed to moving towards deprecating lib.generators

Still, it might be good to give users at least the option to pick between eval-time and build-time generation for use-cases like these. I think this should then be integrated into pkgs.formats though, e.g. such that there's a standard flag like pkgs.formats.toml { evalTimeGenerator = true; }, instead of having to use lib.generators directly.

@infinisil  Could you elaborate why you think pkgs.formats.toml { evalTimeGenerator = true; } would be better than lib.generators.toTOML?
I think it would be nice to have a unique API for eval-time and build-time generation if we haven't have lib.generators. But given that we already have both lib.generators and pkgs.formats, it would be easier to just keep both.

lib.generators return the generated config values as strings, which I'm pretty sure is never strictly necessary. And that's the constraint that prevents it from using derivations underneath instead of implementing it in Nix. This constraint doesn't exist for pkgs.formats because it returns a path instead, so it's more flexible and can support more formats. In essence, pkgs.formats is always going to be a super-set of lib.generators.

In the previous discussion, the consensus is that both eval-time and build-time generation have its pros and cons, and you suggest to add a evalTimeGenerator = true options to pkgs.formats. The consensus is never about whether "generated config values as strings" is strictly neccessary or not.
IMHO, the need of eval-time TOML generation is real, and since we have not yet had a plan to deprecate lib.generators, the best place to implement eval-time TOML generation is lib.generators.toTOML, not pkgs.formats.toml { evalTimeGenerator = true; }.
Introducing pkgs.formats.toml { evalTimeGenerator = true; } but not deprecating lib.generators would result in inconsistant API in the code base, which is bad in my opinion.

Hmm you do have a point. Here's another argument though: If we introduce a separate eval-time TOML formatter, it could easily deviate from the pkgs.formats one, but ideally they should always be consistent with each other. With pkgs.formats this becomes much easier because we can easily reuse the interface, docs and tests for both eval-time and build-time generators.

If we introduce a separate eval-time TOML formatter, it could easily deviate from the pkgs.formats one, but ideally they should always be consistent with each other.

Even if it's true, it's about a possible future design option, not paticularly about lib.generators.toTOML. I would consider lib.generators as the current best practice. I think exploring a better design option that deprecates lib.generators would require RFC process. It should not prevent this PR from being merged at the moment.

As the primary maintainer of most of lib and the original author of pkgs.formats, I really think pkgs.formats is best practice now. And we don't need to deprecate lib.generators right now, but it definitely wouldn't need an RFC, it's nothing unusual to deprecate parts of lib.

authors: Atry infinisil oxalica rycee


text:
Add salt master module

Motivation for this change
Add Salt master module.
Bump Salt to the newest version.
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Thanks!


text:
trezor-suite: 23.4.2 -> 23.10.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/trezor-suite/versions.
meta.description for trezor-suite is: Trezor Suite - Desktop App for managing crypto
meta.homepage for trezor-suite is: https://suite.trezor.io
meta.changelog for trezor-suite is: https://github.com/trezor/trezor-suite/releases/tag/v23.10.1
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 23.10.1 with grep in /nix/store/a9xbzcnpr4bf762mfraazsb58i2jr3p9-trezor-suite-23.10.1
found 23.10.1 in filename of file in /nix/store/a9xbzcnpr4bf762mfraazsb58i2jr3p9-trezor-suite-23.10.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
trezor-suite

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/a9xbzcnpr4bf762mfraazsb58i2jr3p9-trezor-suite-23.10.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A trezor-suite https://github.com/r-ryantm/nixpkgs/archive/f991005d42a7c6509230e5ea9913ae0d141c8c94.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/f991005d42a7c6509230e5ea9913ae0d141c8c94#trezor-suite

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/a9xbzcnpr4bf762mfraazsb58i2jr3p9-trezor-suite-23.10.1
ls -la /nix/store/a9xbzcnpr4bf762mfraazsb58i2jr3p9-trezor-suite-23.10.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

trezor-suite

Maintainer pings
cc @prusnak for testing.

superseded by https://github.com/NixOS/nixpkgs/pull/262508
because two issues happened here, both reported here:

https://github.com/ryantm/nixpkgs-update/issues/367
https://github.com/ryantm/nixpkgs-update/issues/350

authors: prusnak r-ryantm


text:
python311Packages.orbax-checkpoint: init at 0.4.2

Description of changes
Add orbax-checkpoint.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 266467 run on x86_64-linux 1

4 packages built:

python310Packages.orbax-checkpoint
python310Packages.orbax-checkpoint.dist
python311Packages.orbax-checkpoint
python311Packages.orbax-checkpoint.dist

@GaetanLepage sorry for the noise, but this PR seems to be superseded by

https://github.com/NixOS/nixpkgs/pull/291171
https://github.com/NixOS/nixpkgs/pull/291764

i'll close for now since it looks like these changes have been superseded by other PRs, and we can always reopen or open follow up PRs to resurrect anything from this one

authors: GaetanLepage samuela stephen-huan