text:
Cannot build vaultwarden: "it requires rustc 1.57 or newer"

Describe the bug
vaultwarden does not build.
The build started failing with the merge of staging-next in 64065d76f434457073f5d255a3246658119e08ed.
It builds fine in the previous commit 49b08e49195fdb17b5999a0695497765985c451e.
Steps To Reproduce
Run NixOS 21.11-pre; set nixpkgs to master,
at@dev:/home/at/code/system/nixpkgs:e2c7d2b885a3be8392f385eb5d31170b0cfdce9f# git checkout origin/master
HEAD is now at e2c7d2b885a Merge pull request #145740 from alyssais/apr-cross

at@dev:/home/at/code/system/nixpkgs:e2c7d2b885a3be8392f385eb5d31170b0cfdce9f# nix-env -iA vaultwarden
installing 'vaultwarden-1.23.0'
this derivation will be built:
  /nix/store/s5zxpmdipk7alv7j4810v5z4kc3bf5yz-vaultwarden-1.23.0.drv
these 8 paths will be fetched (12.17 MiB download, 70.69 MiB unpacked):
  /nix/store/5xjawi9k0wrbgcvgbd73i5b97gxh98xx-systemd-minimal-249.5
  /nix/store/6spdsyl5sq88mnc8nw4g9wfjm5hy0srs-kmod-29
  /nix/store/f2sgh54b78c3qfwx8qmhklq560zv6ml8-git-2.33.1
  /nix/store/fbk01swjnwhmjaraa7vl9k1s4dhfrmgc-openssh-8.8p1
  /nix/store/ndlfi1rcrwranvkl7kprbzkzk5adr70z-cargo-check-hook.sh
  /nix/store/r247fdhykfb2rxg24l3hnjlljz0iwdgh-cargo-1.56.1
  /nix/store/xzl2876i7cg4xn1xy9yyh71cmmjvnpaa-cargo-build-hook.sh
  /nix/store/z04jwlv053spabp2nmlyyps24zszssd8-libfido2-1.8.0
copying path '/nix/store/r247fdhykfb2rxg24l3hnjlljz0iwdgh-cargo-1.56.1' from 'https://cache.nixos.org'...
copying path '/nix/store/6spdsyl5sq88mnc8nw4g9wfjm5hy0srs-kmod-29' from 'https://cache.nixos.org'...
copying path '/nix/store/5xjawi9k0wrbgcvgbd73i5b97gxh98xx-systemd-minimal-249.5' from 'https://cache.nixos.org'...
copying path '/nix/store/ndlfi1rcrwranvkl7kprbzkzk5adr70z-cargo-check-hook.sh' from 'https://cache.nixos.org'...
copying path '/nix/store/xzl2876i7cg4xn1xy9yyh71cmmjvnpaa-cargo-build-hook.sh' from 'https://cache.nixos.org'...
copying path '/nix/store/z04jwlv053spabp2nmlyyps24zszssd8-libfido2-1.8.0' from 'https://cache.nixos.org'...
copying path '/nix/store/fbk01swjnwhmjaraa7vl9k1s4dhfrmgc-openssh-8.8p1' from 'https://cache.nixos.org'...
copying path '/nix/store/f2sgh54b78c3qfwx8qmhklq560zv6ml8-git-2.33.1' from 'https://cache.nixos.org'...
building '/nix/store/s5zxpmdipk7alv7j4810v5z4kc3bf5yz-vaultwarden-1.23.0.drv'...
unpacking sources
unpacking source archive /nix/store/mpg93qagnn41jvgbpfd7xhb52k12sqrm-source
source root is source
Executing cargoSetupPostUnpackHook
unpacking source archive /nix/store/wad8878r6mpd0a7x4d1r8q4xw5rchkzc-vaultwarden-1.23.0-vendor.tar.gz
Finished cargoSetupPostUnpackHook
patching sources
Executing cargoSetupPostPatchHook
Validating consistency between /build/source//Cargo.lock and /build/vaultwarden-1.23.0-vendor.tar.gz/Cargo.lock
Finished cargoSetupPostPatchHook
configuring
building
Executing cargoBuildHook
++ env CC_x86_64-unknown-linux-gnu=/nix/store/276p5pgfjf9ia9jljgkbmb7zky73p5ag-gcc-wrapper-10.3.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/276p5pgfjf9ia9jljgkbmb7zky73p5ag-gcc-wrapper-10.3.0/bin/c++ CC_x86_64-unknown-linux-gnu=/nix/store/276p5pgfjf9ia9jljgkbmb7zky73p5ag-gcc-wrapper-10.3.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/276p5pgfjf9ia9jljgkbmb7zky73p5ag-gcc-wrapper-10.3.0/bin/c++ cargo build -j 8 --target x86_64-unknown-linux-gnu --frozen --release --features sqlite
error: package `vaultwarden v1.0.0 (/build/source)` cannot be built because it requires rustc 1.57 or newer, while the currently active rustc version is 1.56.1
error: builder for '/nix/store/s5zxpmdipk7alv7j4810v5z4kc3bf5yz-vaultwarden-1.23.0.drv' failed with exit code 101;
       last 10 log lines:
       > Finished cargoSetupPostUnpackHook
       > patching sources
       > Executing cargoSetupPostPatchHook
       > Validating consistency between /build/source//Cargo.lock and /build/vaultwarden-1.23.0-vendor.tar.gz/Cargo.lock
       > Finished cargoSetupPostPatchHook
       > configuring
       > building
       > Executing cargoBuildHook
       > ++ env CC_x86_64-unknown-linux-gnu=/nix/store/276p5pgfjf9ia9jljgkbmb7zky73p5ag-gcc-wrapper-10.3.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/276p5pgfjf9ia9jljgkbmb7zky73p5ag-gcc-wrapper-10.3.0/bin/c++ CC_x86_64-unknown-linux-gnu=/nix/store/276p5pgfjf9ia9jljgkbmb7zky73p5ag-gcc-wrapper-10.3.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/276p5pgfjf9ia9jljgkbmb7zky73p5ag-gcc-wrapper-10.3.0/bin/c++ cargo build -j 8 --target x86_64-unknown-linux-gnu --frozen --release --features sqlite
       > error: package `vaultwarden v1.0.0 (/build/source)` cannot be built because it requires rustc 1.57 or newer, while the currently active rustc version is 1.56.1
       For full logs, run 'nix log /nix/store/s5zxpmdipk7alv7j4810v5z4kc3bf5yz-vaultwarden-1.23.0.drv'.

Notify maintainers
cc @msteen
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.77-hardened1, NixOS, 21.11 (Porcupine)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.5pre20211007_844dd90`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

It looks like vaultwarden's Cargo.toml has a rust-version = "1.57" in the 1.23.0 release, but somehow https://github.com/NixOS/nixpkgs/pull/143331 was working when I tested it. I guess that the Rust changes in the staging-next merge are causing this.

In the last successful build in https://hydra.nixos.org/log/bgpvfmakwzwafkrcw8l4jfmzb19ydhxj-vaultwarden-1.23.0.drv, I see
warning: `rust-version` is not supported on this version of Cargo and will be ignored

and a build that otherwise seems to work perfectly fine?


text:
avrgcclibc fails to build

Issue description
The package avrgcclibc fails to build with the error:
checking dependency style of avr-gcc... gcc3
checking for avr-ranlib... ranlib
checking for avr-ar... ar
configure: error: Wrong assembler found; check the PATH!
builder for ‘/nix/store/08bhr9qkx2dyjk42v5ypgvxlxhw7gjl5-avr-gcc-libc.drv’ failed with exit code 1

I did a git bisect to determine this issue was a result of 093cc00cdd.
CC @Ericson2314
Steps to reproduce
nix-build "<nixpkgs>" -A avrgcclibc
for a version of nixpkgs after 093cc00cdd
Technical details

System: 17.09.git.5476a54 (Hummingbird)
Nix version:  (Nix) 1.11.13
Nixpkgs version: 17.09.git.5476a54c1d
Sandboxing enabled: true

preconfigure = "unset AS" should do it. See https://github.com/NixOS/nixpkgs/issues/28106 for why (analogous problem with non-standard linker instead of assembler).

This does not work.

Oh taking another look....this is kind of a hack-job derivation. This should be deleted and a normal cross compiled toolchain used in it's place. If you're not in too much of a rush, I can do that take care of that in the last column of https://github.com/NixOS/nixpkgs/projects/8

I am doing my avr compilations with release-17.03 for now. I don't need this as a priority. As long as it works in release-17.09 I am happy with it.
Thanks for your effort! :muscle:

Well, code cutoff is comming up quick :O. let's hope I can knock off https://github.com/NixOS/nixpkgs/projects/8!

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/where-is-avr-ar-currently-exported/13658/1

source: gharchive/issue

authors: Ericson2314 danielfullmer mguentner nixos-discourse

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
nixos/krb5: database_name needs to be configurable in order to add principals

Issue description
I'm just looking into Kerberos and struggling to create a principal because krb5_util tries to write to /nix/store.
Steps to reproduce
root@hoshijiro> kdb5_util -r HOSHIJIRO.LAN create -s
Loading random data
Initializing database '/nix/store/03r5a4szk0vy5598hwd4fr9ssriws03s-krb5-1.15/var/krb5kdc/principal' for realm 'HOSHIJIRO.LAN',
master key name 'K/M@HOSHIJIRO.LAN'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
kdb5_util: Read-only file system while creating database '/nix/store/03r5a4szk0vy5598hwd4fr9ssriws03s-krb5-1.15/var/krb5kdc/principal'

Technical details

System: 18.03pre-git (Impala)
Nix version: nix-env (Nix) 1.11.14
Nixpkgs version: 17.03.1517.849b5a5193
Sandboxing enabled: false

MIT Kerberos docs say:
If the default location does not suit your setup,
explicitly configure the following values:
   database_name = /var/krb5kdc/principal
   key_stash_file = /var/krb5kdc/.k5.ATHENA.MIT.EDU
   acl_file = /var/krb5kdc/kadm5.acl

It looks like this has to be done per-realm.

Well, it looks like I was getting confused because if you have krb5.enable = true; and services.kerberos_server.enable = true; you end up with both MIT and Heimdal Kerberos in environment.systemPackages.
For future humans, you want to read the Heimdal docs here: http://www.h5l.org/manual/HEAD/info/heimdal/Setting-up-a-realm.html#Setting-up-a-realm

I think this path was fixed in https://github.com/NixOS/nixpkgs/pull/29272 for the MIT Kerberos server.


text:
liquidhaskell-cabal doesn't build

$ nix-env -iA nixos.haskellPackages.liquidhaskell-cabal
installing 'liquidhaskell-cabal-0.1.1.0'
these derivations will be built:
  /nix/store/ph75kjblhqayywcnmlq8wkz85hssdqn0-liquidhaskell-cabal-0.1.1.0.drv
building '/nix/store/ph75kjblhqayywcnmlq8wkz85hssdqn0-liquidhaskell-cabal-0.1.1.0.drv'...
setupCompilerEnvironmentPhase
Build with /nix/store/5z8gx1bjw5s0q96n191k0a8caqr4r580-ghc-8.4.3.
ignoring (possibly broken) abi-depends field for packages
unpacking sources
unpacking source archive /nix/store/8ifd056kyfkgdslmin4wf7z9jfgvsxaw-liquidhaskell-cabal-0.1.1.0.tar.gz
source root is liquidhaskell-cabal-0.1.1.0
setting SOURCE_DATE_EPOCH to timestamp 1462662619 of file liquidhaskell-cabal-0.1.1.0/src/LiquidHaskell/Cabal.hs
patching sources
compileBuildDriverPhase
setupCompileFlags: -package-db=/build/setup-package.conf.d -j1 -threaded
[1 of 1] Compiling Main             ( Setup.hs, /build/Main.o )
Linking Setup ...
configuring
configureFlags: --verbose --prefix=/nix/store/vsfgcr0y319cjn69vpxp0b8342xwyc0y-liquidhaskell-cabal-0.1.1.0 --libdir=$prefix/lib/$compiler --libsubdir=$abi/$libname --docdir=/nix/store/lihnm95imjbs8jpfi83nmb4chpq5nrmv-liquidhaskell-cabal-0.1.1.0-doc/share/doc/liquidhaskell-cabal-0.1.1.0 --with-gcc=gcc --package-db=/build/package.conf.d --ghc-option=-j1 --disable-split-objs --enable-library-profiling --profiling-detail=exported-functions --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --enable-tests --disable-benchmarks --enable-library-vanilla --enable-library-for-ghci --ghc-option=-split-sections --extra-lib-dirs=/nix/store/s2n99784krxl91mfw3cnn9ylbb5fjvkx-ncurses-6.1/lib --extra-lib-dirs=/nix/store/rxaclc3vhxbzgfllv7601i85z854h48a-gmp-6.1.2/lib
Using Parsec parser
Configuring liquidhaskell-cabal-0.1.1.0...
CallStack (from HasCallStack):
  die', called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:958:20 in Cabal-2.2.0.1:Distribution.Simple.Configure
  configureFinalizedPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:462:12 in Cabal-2.2.0.1:Distribution.Simple.Configure
  configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:596:20 in Cabal-2.2.0.1:Distribution.Simple
  confHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.2.0.1:Distribution.Simple.UserHooks
  configureAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:178:19 in Cabal-2.2.0.1:Distribution.Simple
  defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:115:27 in Cabal-2.2.0.1:Distribution.Simple
  defaultMain, called at Setup.hs:2:8 in main:Main
Setup: Encountered missing dependencies:
Cabal >=1.18 && <1.26

builder for '/nix/store/ph75kjblhqayywcnmlq8wkz85hssdqn0-liquidhaskell-cabal-0.1.1.0.drv' failed with exit code 1
error: build of '/nix/store/ph75kjblhqayywcnmlq8wkz85hssdqn0-liquidhaskell-cabal-0.1.1.0.drv' failed

Technical details

system: "x86_64-linux"
host os: Linux 4.14.71, NixOS, 19.03pre153158.7df10f388da (Koi)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.1.2
channels(turion): ""
channels(root): "musnix, nixos-19.03pre153158.7df10f388da"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

https://github.com/spinda/liquidhaskell-cabal/issues/11

This is an upstream issue that's unrelated to Nix.

authors: ElvishJerricco peti turion


text:
Vulnerability roundup 64: python-2.7.15: 2 advisories

search, files

[ ] CVE-2019-9636 (nixos-unstable, nixos-18.09)
[ ] CVE-2019-9740 (nixos-unstable, nixos-18.09)

Scanned versions: nixos-unstable: 373488e6f4c; nixos-18.09: 40e716b92a7. May contain false positives.

18.09 is EOL, unstable is at python 2.7.18 @ckauhaus Close?

yes

authors: ckauhaus wamserma


text:
Vulnerability roundup 85: helm-0.9.0: 1 advisory [9.8]

search, files

[ ] CVE-2019-1010275 CVSSv3=9.8 (nixos-20.03, nixos-unstable)

Scanned versions: nixos-20.03: a84b797b28e; nixos-unstable: 22c98819ccd. May contain false positives.

NVD refers to helm/helm (as in helm chart)
This package is the synthesizer helm.
Closing as an FP.

authors: ckauhaus redvers


text:
Vulnerability roundup 87: i2p-0.9.42: 1 advisory [7.8]

search, files

[ ] CVE-2020-13431 CVSSv3=7.8 (nixos-20.03, nixos-unstable)

Scanned versions: nixos-20.03: f1a79c86358; nixos-unstable: b3251e04ee4. May contain false positives.
Cc @joelmo

20.03 is frozen and EOL.
master at 0.9.47
Closing.


text:
Vulnerability roundup 89: electron-3.1.13: 1 advisory [6.8]

search, files

[ ] CVE-2020-15096 CVSSv3=6.8 (nixos-20.03, nixos-unstable)

Scanned versions: nixos-20.03: dabbc5a5603; nixos-unstable: c71518e75bf. May contain false positives.
Cc @manveru
Cc @prusnak
Cc @travisbhartwell

both master and nixos-20.03 contain electron 3.1.13

both master and nixos-20.03 contain electron 3.1.13 which is the latest from the 3.x series

See https://github.com/NixOS/nixpkgs/issues/93257#issuecomment-660141633

authors: ckauhaus prusnak


text:
buildah from fedora - while pulling "fedora" as "localhost/fedora": error obtaining default signature policy: open /etc/containers/policy.json: no such file or directory

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
buildah from fedora
(image name "fedora" is a short name and no search registries are defined in /etc/containers/registries.conf): while pulling "fedora" as "localhost/fedora": error obtaining default signature policy: open /etc/containers/policy.json: no such file or directory

Expected behavior
add fedora image
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Notify maintainers

@Profpatsch
@adisbladis
@saschagrunert
@vdemeester
@zowoq
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

system: "x86_64-linux"
host os: Linux 5.8.9, NixOS, 20.03.2652.076c67fdea6 (Markhor)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.6
channels(ae): "OsUnstable-21.03pre243854.2a14d21224f, NxUnstable-21.03pre243968.2a35f664394, home-manager-20.03, nixos-20.03.3002.773ef5ae783"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

Since buildah has no module, you probably have to enable:
virtualisation.containers.enable = true;

The option virtualisation.containers' defined in /etc/nixos/configuration.nix' does not exist.
that's a 20.09 option

a way to use buildah in 20.03?

authors: InLaw saschagrunert


text:
terragrunt: 0.25.5 -> 0.26.2

Motivation for this change
Bump terragrunt to 0.26.2
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 (x86_64)
[ ] 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)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 103308 1

1 package built:

terragrunt

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

Thanks for the review @dbirks
If you're interested you can post to this Discourse thread of already reviewed PRs https://discourse.nixos.org/t/prs-already-reviewed/2617 (format  is merge: <LINK>)
Not sure what the protocol is with posting something that someone else has reviewed but I can post it in your stead if you'd prefer.

source: gharchive/pull-request


text:
nixos/systemd: make services with DynamicUser depend on nscd

otherwise their username does not resolve to their uid
Fixes #105353
Things done
Tested with the sslh nixos test

[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

[x] 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
[ ] Fits CONTRIBUTING.md.

sslh is a special beast here - we have some iptables commands that run as a ExecStartPre script, so we require name lookups immediately at startup.
I think this qualifies it for adding a After=nss-user-lookup.target as per https://www.freedesktop.org/software/systemd/man/systemd.special.html#nss-user-lookup.target:

All services for which the availability of the full user/group database is essential should be ordered after this target, but not pull it in.

systemd.services.nscd.wantedBy contains a nss-user-lookup.target, so this should be sufficient.
I don't think adding a dependency to nscd for all services started with DynamicUser=true is correct - while it's true nss_systemd is a non-glibc nss module, and we provide non-glibc nss modules via nscd,  there's nothing saying a service started will try to lookup its username at startup time.
On the other hand, services not making use of DynamicUser=yes can still depend on a fully functional user/group database at startup - imagine configuring nginx.conf to run as a uid which is provided via LDAP.
Let's add After=nss-user-lookup.target to sslh.service.

Ah. I think I saw this behavior in other places too and I was always wondering why.

sslh is a special beast here - we have some iptables commands that run as a ExecStartPre script, so we require name lookups immediately at startup.
I think this qualifies it for adding a After=nss-user-lookup.target as per freedesktop.org/software/systemd/man/systemd.special.html#nss-user-lookup.target:

All services for which the availability of the full user/group database is essential should be ordered after this target, but not pull it in.

systemd.services.nscd.wantedBy contains a nss-user-lookup.target, so this should be sufficient.
I don't think adding a dependency to nscd for all services started with DynamicUser=true is correct - while it's true nss_systemd is a non-glibc nss module, and we provide non-glibc nss modules via nscd, there's nothing saying a service started will try to lookup its username at startup time.
On the other hand, services not making use of DynamicUser=yes can still depend on a fully functional user/group database at startup - imagine configuring nginx.conf to run as a uid which is provided via LDAP.
Let's add After=nss-user-lookup.target to sslh.service.

This might be true but it is also a bit of a foot gun. This is not what you would expect looking at the code.

Hm? Not sure I understand what you mean is the footgun here :-)
The fact we need to pipe all non-glibc nss calls via nscd should have been somewhat better documented as part of https://github.com/NixOS/nixpkgs/pull/86940, https://github.com/NixOS/nixpkgs/pull/87016 and https://github.com/NixOS/nixpkgs/pull/86010. I agree it's annoying, but nscd is the somewhat stable interface. Feel free to carry that discussion over here: https://github.com/NixOS/nixpkgs/issues/55276
If this service requires being able to resolve dynamic users on startup, it needs to add After=nss-user-lookup.target (maybe add a comment why).
Of course, it's ugly, but probably needed, as we don't know (and thus can't pass in statically) the user id in that iptables invocation (so need the lookup).
I'm against pulling in nscd for all other service that have DynamicUser enabled. It's really two different concepts here.
Services might perfectly fine work without being able to resolve their own username, and DynamicUser itself also happily is able to allocate temporary user ids without nss_systemd being available in the system at all - it's just resolving these user ids won't work.

Hm? Not sure I understand what you mean is the footgun here :-)

I mean it is not easy to see if a service needs to resolve its own username at startup or not.

Note that also from the docs:

system users and groups are required to be resolvable during earliest boot already, and hence do not need any special ordering against this target.

I don't think this is the case at the moment so this is really an us bug. I suggest starting nscd during early boot (WantedBy=sysinit.target , Default dependencies=no) .   DynamicUsers are system users and per systemds contract they should be resolvable as soon as sysinit.target is reached which is currently not the case.

Note that also from the docs of nss-user-lookup.target

system users and groups are required to be resolvable during earliest boot already, and hence do not need any special ordering against this target.

I don't think this is the case at the moment so this is really an us bug. I suggest starting nscd during early boot (WantedBy=sysinit.target , Default dependencies=no) . DynamicUsers are system users and per systemds contract they should be resolvable as soon as sysinit.target is reached which is currently not the case.

I think this problem also appears when nscd is restarted. So we would need not to restart it.

This basically has the same effect as what this PR is doing but a bit more elegantly. I'm thus in favor of this PR- with some tweaks.
nss-lookup.target really is meant for things like ldap and friends. And specifically only for non-system users.
When you have a named DynamicUser in a Systemd service it should immediately be usable .that's the contract Systemd provides and that we break.

I think this problem also appears when nscd is restarted. So we would need not to restart it.

We could mark it "never restart" just like dbus. Though that's not very nice.
Another option would be to make nscd socket-activatable. Systemd would then buffer the requests during restarts. But I don't think that code exists upstream yet and quite frankly the nscd upstream code is quite messy and I'm very afraid to touch it.

Let's move nscd earlier into boot then. We still need to restart it whenever our enabled nss modules are updated, because the LD_LIBRARY_PATH it's run with is restarted, at last as long as we keep providing them like that.
Not picking up changes there is probably worse than an eventual blip while restarting nscd.

@Mic92  if nscd is ordered before sysinit.target  and all   services in the activation script are restarted in the same transaction; then it would always be restarted before any services that might blip because of it during startup no?    Running services might still get a blip but i don't know how to avoid that.

@Mic92 if nscd is ordered before sysinit.target and thus before all other late-boot services and all services in the activation script are restarted in the same transaction; then it would always be restarted before any services that might blip because of it during startup no? Running services might still get a blip but i don't know how to avoid that.

I see. That might work.

I did some experiments with this approach
diff --git a/nixos/modules/services/system/nscd.nix b/nixos/modules/services/system/nscd.nix
index d720f254b81..5703fd04421 100644
--- a/nixos/modules/services/system/nscd.nix
+++ b/nixos/modules/services/system/nscd.nix
@@ -79,6 +79,16 @@ in
                 "${nscd}/sbin/nscd --invalidate hosts"
               ];
           };
+
+        # Services with DynamicUser=true require nscd to be fully started to
+        # resolve their own username. We add a dependency of sysinit.target to nscd to ensure
+        # these units are started after nscd is fully started.
+        unitConfig.DefaultDependencies = false;
+        wantedBy = [ "sysinit.target" "nss-lookup.target" "nss-user-lookup.target" ];
+        before = [ "sysinit.target" "shutdown.target" ];
+        conflicts = [ "shutdown.target" ];
+        wants = [ "local-fs.target" ];
+        after = [ "local-fs.target" ];
       };

   };

It looks like it does not fully solve the problem because once sysinit.target is started, restarting sslh and nscd together will happen in any order. sslh only depends on sysinit.target but it is already up. So I'm afraid we need a direct dependency from services to nscd without mediation through a target unit.

I think the problem is that systemctl restart doesnt actually add units to the same transaction and thus does not take indirect ordering into account so yeh you seem to be right. This is a bit unfortunate

The way I expected systemctl restart to behave seems to be exactly described in : https://github.com/systemd/systemd/issues/2607
For now; perhaps we should make sure in our activation script that nscd is always restarted before any other services; instead of adding this direct dependency everywhere?  It's also not a very attractive solution. I wish systemd would just be able to do the right thing for us here.
I don't know which of the two options is best.

For now; perhaps we should make sure in our activation script that nscd is always restarted before any other services; instead of adding this direct dependency everywhere? It's also not a very attractive solution. I wish systemd would just be able to do the right thing for us here.

I very much prefer making systemd aware of the specificities of our setup by adding explicit dependencies on nscd to working around systemd by hacking the activation script.

What is actually the security advantage of DynamicUser over users created on demand with no fixed uid? We could actually safe a lot of hassle if we would not use this feature at all.

Not managing UIDs does not work.  UID ownership is sticky.  Say you deploy postgres and then in the next deploy remove postgres and then deploy nginx. Suddenly your nginx instance has read/write access to all of postgres's data as it recycled the UID.
The alternative is managing a list of global UIDs and make sure you never reuse any of them but that's also not nice.
DynamicUser is a neat way of both not having to think of uids but still protect again UID reuse attacks. When it's enabled the unit can only write to files in StateDirectory= and systemd makes sure to manage this directory in such a way that UID reuse attacks can not occur.
From the manpage:
           If DynamicUser= is used in conjunction with StateDirectory=, the
           logic for CacheDirectory= and LogsDirectory= is slightly altered:
           the directories are created below /var/lib/private,
           /var/cache/private and /var/log/private, respectively, which are
           host directories made inaccessible to unprivileged users, which
           ensures that access to these directories cannot be gained through
           dynamic user ID recycling. Symbolic links are created to hide this
           difference in behaviour. Both from perspective of the host and from
           inside the unit, the relevant directories hence always appear
           directly below /var/lib, /var/cache and /var/log.

I think this PR is good to merge.  But I still think it's a good idea to move nscd to  before sysinit.target as system users should be resolveable after sysinit.target is reached.
We could add that patch in a separate PR or add it to this PR as well. I'm ok with either.

Not managing UIDs does not work. UID ownership is sticky. Say you deploy postgres and then in the next deploy remove postgres and then deploy nginx. Suddenly your nginx instance has read/write access to all of postgres's data as it recycled the UID.
The alternative is managing a list of global UIDs and make sure you never reuse any of them but that's also not nice (but is how we coped in NixOS before this feature)
DynamicUser is a neat way of both not having to think of uids but still protect again UID reuse attacks. When it's enabled the unit can only write to files in StateDirectory= and systemd makes sure to manage this directory in such a way that UID reuse attacks can not occur.
From the manpage:
           If DynamicUser= is used in conjunction with StateDirectory=, the
           logic for CacheDirectory= and LogsDirectory= is slightly altered:
           the directories are created below /var/lib/private,
           /var/cache/private and /var/log/private, respectively, which are
           host directories made inaccessible to unprivileged users, which
           ensures that access to these directories cannot be gained through
           dynamic user ID recycling. Symbolic links are created to hide this
           difference in behaviour. Both from perspective of the host and from
           inside the unit, the relevant directories hence always appear
           directly below /var/lib, /var/cache and /var/log.

In NixOS we actually has /var/lib/nixos/uid-map and similar for groups to not reuse uids for different users.

How about starting nscd before the rest?
diff --git a/nixos/modules/system/activation/switch-to-configuration.pl b/nixos/modules/system/activation/switch-to-configuration.pl
index b82d69b3bb8..a41fa70b62c 100644
--- a/nixos/modules/system/activation/switch-to-configuration.pl
+++ b/nixos/modules/system/activation/switch-to-configuration.pl
@@ -349,6 +349,7 @@ sub filterUnits {
 my @unitsToStopFiltered = filterUnits(\%unitsToStop);
 my @unitsToStartFiltered = filterUnits(\%unitsToStart);

+my $startNscd = delete $unitsToStart{nscd.service};

 # Show dry-run actions.
 if ($action eq "dry-activate") {
@@ -359,6 +360,7 @@ sub filterUnits {
     print STDERR "would restart systemd\n" if $restartSystemd;
     print STDERR "would restart the following units: ", join(", ", sort(keys %unitsToRestart)), "\n"
         if scalar(keys %unitsToRestart) > 0;
+    print STDERR "would start nscd\n" if $startNscd;
     print STDERR "would start the following units: ", join(", ", @unitsToStartFiltered), "\n"
         if scalar @unitsToStartFiltered;
     print STDERR "would reload the following units: ", join(", ", sort(keys %unitsToReload)), "\n"
@@ -434,6 +436,13 @@ sub filterUnits {
     unlink($restartListFile);
 }

+
+# Services depending on DynamicUser needs nscd to resolve users/groups
+if $startNscd {
+    print STDERR "starting the nscd\n";
+    system("@systemd@/bin/systemctl", "start", "nscd.service") == 0 or $res = 4;
+}
+
 # Start all active targets, as well as changed units we stopped above.
 # The latter is necessary because some may not be dependencies of the
 # targets (i.e., they were manually started).  FIXME: detect units

This is what I proposed originally and personally I think combined with making nscd an early-boot service (order before sysinit.target) it would solve all the issues.

For now; perhaps we should make sure in our activation script that nscd is always restarted before any other services; instead of adding this direct dependency everywhere? It's also not a very attractive solution. I wish systemd would just be able to do the right thing for us here.

But @flokli and @symphorien seem to disagree.
I still think it's the better approach though. The direct dependency on nscd.service feels wrong to me because nscd will always be started up early enough if we have it ordered before sysinit.target .    that systemctl stop/start does not take into account those indirect dependencies is a shame; but it's a bug in systemd and/or our activation script; not in the systemd units.
I'm ok with making this change to switch-to-configuration.pl combined with the above-mentioned patch to add nscd to sysinit.target

@symphorien I think your solution fixes services that directly depend on their own dynamic user. However it seems that we also need the same users for other services i.e. the firewall service: https://github.com/NixOS/nixpkgs/issues/106127
I created https://github.com/NixOS/nixpkgs/pull/106336 as an alternative. I have not checked yet if it actually would fix the firewall uid issue.

I created #106336 as an alternative

I don't think it is an alternative but complementary.  We have 2 problems:

sometimes nscd is not started early enough:  #106336
when restarting nscd and a dynamic user services at the same time, it fails: either this PR or hacking nixos-rebuild (which is only a partial solution, as nixos-rebuild is not the only thing to restart services)

oh I had not seen this PR does also hack nixos-rebuild. Fine then. Again I would prefer making systemd aware of dependencies rather than working around it, because then bare systemctl restart would work, but do as you wish.

Let's close this in favor of https://github.com/NixOS/nixpkgs/pull/106336.

authors: Mic92 arianvp flokli symphorien


text:
vtk_9: qt514 -> qt515

Motivation for this change
As requested in #104474
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
[ ] Fits CONTRIBUTING.md.

❯ nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
$ git -c fetch.prune=false fetch --force https://github.com/NixOS/nixpkgs master:refs/nixpkgs-review/0
remote: Enumerating objects: 50, done.
remote: Counting objects: 100% (50/50), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 54 (delta 43), reused 44 (delta 38), pack-reused 4
Unpacking objects: 100% (54/54), 9.88 KiB | 1.65 MiB/s, done.
From https://github.com/NixOS/nixpkgs
   0a907ad8488..1f8ef6970a1  master     -> refs/nixpkgs-review/0
$ git worktree add /home/thiago/.cache/nixpkgs-review/rev-0a907ad84884de0d6a65dba8484fb95d302d4b46-dirty-2/nixpkgs 1f8ef6970a146c49a601bec2a7750c3f560e1206
Preparing worktree (detached HEAD 1f8ef6970a1)
HEAD is now at 1f8ef6970a1 linux: 5.9.12 -> 5.9.14
$ nix-env -f /home/thiago/.cache/nixpkgs-review/rev-0a907ad84884de0d6a65dba8484fb95d302d4b46-dirty-2/nixpkgs -qaP --xml --out-path --show-trace
Applying `nixpkgs` diff...
$ nix-env -f /home/thiago/.cache/nixpkgs-review/rev-0a907ad84884de0d6a65dba8484fb95d302d4b46-dirty-2/nixpkgs -qaP --xml --out-path --show-trace --meta
2 packages updated:
f3d vtk

$ nix --experimental-features nix-command build --no-link --keep-going --option build-use-sandbox relaxed -f /home/thiago/.cache/nixpkgs-review/rev-0a907ad84884de0d6a65dba8484fb95d302d4b46-dirty-2/build.nix
2 packages built:
f3d vtk_9

/marvin opt-in
/status needs_reviewer


text:
meteor: 1.10.2 -> 1.12

Motivation for this change
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"
[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.

This is a semi-automatic executed nixpkgs-review. 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 107963 run on x86_64-linux 1

1 package built:

meteor


text:
ttyrec: 1.0.8 -> ovh-ttyrec 1.1.6.6

Motivation for this change
The upstream ttyrec package has been marked broken since January 2020, as it depends on a deprecated POSIX API that Linux has never fully supported, and for which such support as did exist has been withdrawn from glibc.
This PR replaces the broken ttyrec derivation with one packaging an actively-maintained fork by @ovh.
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"
[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.

Items where feedback is requested:

[ ] Is it okay to take over the ttyrec name when switching source trees, or should this have a new top-level entry?
[ ] Is @zimbatm okay with remaining on the maintainers list with this change?

Items where feedback is requested:

[ ] Is it okay to take over the ttyrec name when switching source trees, or should this have a new top-level entry?
[ ] Is @zimbatm okay with remaining on the maintainers list with this change?

[ ]  Is it okay to take over the ttyrec name when switching source trees, or should this have a new top-level entry?

The old one had its last release 14 years ago and if it is a drop in replacement I think it is finish.

[ ]  Is it okay to take over the ttyrec name when switching source trees, or should this have a new top-level entry?

The old one had its last release 14 years ago and if it is a drop in replacement I think it is finish.

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

1 package built:

ttyrec

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

1 package built:

ttyrec

This is a semi-automatic executed nixpkgs-review. 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 108182 run on x86_64-linux 1

1 package built:

ttyrec

This is a semi-automatic executed nixpkgs-review. 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 108182 run on x86_64-linux 1

1 package built:

ttyrec

Since the pname has changed, can you please update all-packages.nix to rename the attibute as well? Update ttyrec to ovh-ttyrec and then add an alias back from ttyrec to ovh-ttyrec in pkgs/top-level/aliases.nix
Ideally we want pname and attribute names to match, to simplify reverse-lookup from a store path to attribute. ttyrec can then be kept as

Since the pname has changed, can you please update all-packages.nix to rename the attibute as well? Update ttyrec to ovh-ttyrec and then add an alias back from ttyrec to ovh-ttyrec in pkgs/top-level/aliases.nix
Ideally we want pname and attribute names to match, to simplify reverse-lookup from a store path to attribute. ttyrec can then be kept as

@zimbatm -- I've updated this to also have the directory name match the pname. LGTY, or have I overstepped?

@zimbatm -- I've updated this to also have the directory name match the pname. LGTY, or have I overstepped?

(Argh, missed the top-level/aliases.nix specification; apologies, going back and modifying that...)

(Argh, missed the top-level/aliases.nix specification; apologies, going back and modifying that...)

@zimbatm -- updated per request; ttyrec is now in pkgs/top-level/aliases.nix, whereas pkgs/top-level/all-packages.nix uses the ovh-ttyrec name. I also updated the directory name to match.

@zimbatm -- updated per request; ttyrec is now in pkgs/top-level/aliases.nix, whereas pkgs/top-level/all-packages.nix uses the ovh-ttyrec name. I also updated the directory name to match.

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

1 package built:

ovh-ttyrec

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

1 package built:

ovh-ttyrec


text:
caddy: 2.2.1 -> 2.3.0

Motivation for this change
https://github.com/caddyserver/caddy/releases/tag/v2.3.0
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
[x] 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
[x] Fits CONTRIBUTING.md.

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 108551 run on x86_64-linux 1

2 packages built:

caddy
styx

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 108551 run on x86_64-linux 1

2 packages built:

caddy
styx

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 108551 run on x86_64-darwin 1

2 packages built:

caddy
styx

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 108551 run on x86_64-darwin 1

2 packages built:

caddy
styx


text:
uchardet: disable check on i686

Motivation for this change
The check fails on i686
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/)
[ ] 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.

The check fails on i686

Do you have a log or reported this upstream?

The check fails on i686

Do you have a log or reported this upstream?

This was reported by another user running i686 on #nixos.
log: https://logs.nix.samueldr.com/nixos/2021-01-23#4521395;
The following tests FAILED:
         29 - fi:iso-8859-1 (Failed)
         37 - ga:iso-8859-1 (Failed)
        106 - th:tis-620 (Failed)
Errors while running CTest
make: *** [Makefile:127: test] Error 8
builder for '/nix/store/7k0970580kzadwpybrrypjdxswh63y5c-uchardet-0.0.7.drv' failed with exit code 2
cannot build derivation '/nix/store/6n22sn3x8sdl6fklyvv91nxpfg27dcm4-mpv-0.32.0.drv': 1 dependencies couldn't be built
building '/nix/store/6i7sagwmqp228r2801j2a2if2mxwwcdf-xsession.drv'...
building '/nix/store/z25l2kpn3g102f5qadafqcmkmxs1sci6-xsession.drv'...
cannot build derivation '/nix/store/14gydj27lfixny1qga3ysrvbqqw7yvir-mpv-with-scripts-0.32.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/63nzcv9zs8zw72hn029h5bh7sq7m1dls-system-path.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/gk6qirajwnjnrs0gir8q0hnsk3zqb67f-nixos-system-Studio-1555-NixOS-20.09.2660.da3378c4aaf.drv': 1 dependencies couldn't be built
error: build of '/nix/store/gk6qirajwnjnrs0gir8q0hnsk3zqb67f-nixos-system-Studio-1555-NixOS-20.09.2660.da3378c4aaf.drv' failed

This was reported by another user running i686 on #nixos.
log: https://logs.nix.samueldr.com/nixos/2021-01-23#4521395;
The following tests FAILED:
         29 - fi:iso-8859-1 (Failed)
         37 - ga:iso-8859-1 (Failed)
        106 - th:tis-620 (Failed)
Errors while running CTest
make: *** [Makefile:127: test] Error 8
builder for '/nix/store/7k0970580kzadwpybrrypjdxswh63y5c-uchardet-0.0.7.drv' failed with exit code 2
cannot build derivation '/nix/store/6n22sn3x8sdl6fklyvv91nxpfg27dcm4-mpv-0.32.0.drv': 1 dependencies couldn't be built
building '/nix/store/6i7sagwmqp228r2801j2a2if2mxwwcdf-xsession.drv'...
building '/nix/store/z25l2kpn3g102f5qadafqcmkmxs1sci6-xsession.drv'...
cannot build derivation '/nix/store/14gydj27lfixny1qga3ysrvbqqw7yvir-mpv-with-scripts-0.32.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/63nzcv9zs8zw72hn029h5bh7sq7m1dls-system-path.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/gk6qirajwnjnrs0gir8q0hnsk3zqb67f-nixos-system-Studio-1555-NixOS-20.09.2660.da3378c4aaf.drv': 1 dependencies couldn't be built
error: build of '/nix/store/gk6qirajwnjnrs0gir8q0hnsk3zqb67f-nixos-system-Studio-1555-NixOS-20.09.2660.da3378c4aaf.drv' failed

🤦🏽  this PR is a duplicate of #112300

authors: SuperSandro2000 siraben vcunat


text:
Darwin platform versions

Motivation for this change
Implement the reproducibility of #77632, without the warnings that were introduced by cctools (https://github.com/NixOS/nixpkgs/pull/93596#issuecomment-695186910), with support for cross compilation by moving sdk versions and deployment targets out of the darwin stdenv and onto targetPlatform.
Effectively reverts: #110140 by @holymonson. When working on aarch64-darwin the SDK version provided (and embedded in LC_BUILD_VERSION) controls some kind of compatibility layer, see gist, so I think we need to support an idea of "SDK version" even though nixpkgs generally treats darwin as a set of independent and overridable packages.
Also tries to define a platform definition structure for all darwin targets including ios. Currently these have platforms have equivalent attributes which I would like to unify with the rest of darwin. The extra configuration here pkgs/os-specific/darwin/xcode/sdk-pkgs.nix should be able to entirely removed, and instead be provided by the standard darwin stdenv and binutils.
Original PR: #77632
Related: #103053, #83180
Motivation: https://github.com/NixOS/nixpkgs/pull/105026#issuecomment-770341696
Tested:

[x] Default stdenv (clang 7)
[x] stdenv with clang 10
[x] stdenv with clang 11 (using #111701)

Untested:

[ ] ios cross

Motivating test case
The following set of test cases should include no information from the building host and produce no linker warnings.
See results in $(nix-build version-test-case.nix)/summary.

version-test-case.nix
let
  pkgs = import ./. {};
  inherit (pkgs) lib;

  ## Default stdenv
  stdenv = pkgs.stdenv;

  ## With clang 11
  # stdenv = pkgs.overrideCC pkgs.stdenv pkgs.buildPackages.clang_11;

  ## With clang 10
  # stdenv = pkgs.overrideCC pkgs.stdenv pkgs.buildPackages.clang_10;

  source = pkgs.writeText "main.c" ''
    int main() {}
  '';

  tests = {
    clangDefault = ''
      $CC -v -o test ${source}
    '';

    clangExplicit = ''
      $CC -v -mmacos-version-min=10.14 -o test ${source}
    '';

    ldDefault = ''
      $CC -o test.o -c ${source}
      $LD -L${pkgs.darwin.Libsystem}/lib -lSystem -o test test.o
    '';

    ldMacosVersion = ''
      $CC -o test.o -c ${source}
      $LD \
        -macos_version_min 10.14 \
        -L${pkgs.darwin.Libsystem}/lib -lSystem -o test test.o
    '';

    ldBothLegacyFlags = ''
      $CC -o test.o -c ${source}
      $LD \
        -macos_version_min 10.14 \
        -sdk_version 10.14 \
        -L${pkgs.darwin.Libsystem}/lib -lSystem -o test test.o
    '';

    ldSdkVersion = ''
      $CC -o test.o -c ${source}
      $LD \
        -sdk_version 10.14 \
        -L${pkgs.darwin.Libsystem}/lib -lSystem -o test test.o
    '';

    ldPlatformVersion = ''
      $CC -o test.o -c ${source}
      $LD \
        -platform_version macos 10.14 10.14 \
        -L${pkgs.darwin.Libsystem}/lib -lSystem -o test test.o
    '';
  };

  buildTest = name: testScript: stdenv.mkDerivation {
    inherit name testScript;
    passAsFile = [ "testScript" "buildCommand" ];

    buildCommand = ''
      set -u
      echo $testScriptPath
      mkdir $out
      NIX_DEBUG=3 $SHELL -x $testScriptPath 2>&1 | tee $out/build.log
      ${pkgs.darwin.cctools}/bin/otool -l test> $out/load_commands
    '';
  };
in
  pkgs.runCommand "all-tests" {
    passthru = lib.mapAttrs buildTest tests;
  } (
    ''
      mkdir $out
    '' +
    lib.concatStringsSep "\n" (
      lib.mapAttrsToList (name: script: ''
        ln -s ${buildTest name script} $out/${name}
      '') tests
    ) + ''
      cd $out
      {
        showCommand() {
          local cmdName=$1
          echo -ne "\t$cmdName: "
          awk "/$cmdName/ { show = 1 }; /Load command/ { show = 0 }; show" < $i | tr '\n' '\t'
          echo
        }

        for i in */load_commands; do
          echo $i
          showCommand LC_BUILD_VERSION
          showCommand LC_UUID
          showCommand LC_VERSION_MIN_MACOSX
        done

        echo

        echo "Linker warnings:"
        grep -nH 'warning' */build.log || true
      } > summary 2>&1
    ''
  )

Things done

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

[ ] NixOS
[x] 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.

FYI, I was working on #111658 which could support multiple versions of sdk (by generating several info lists). I'm not sure if you need it, but I will pause here.

With the debugging commit the evaluation error is visible:
darwinPlatform: unknown platform for x86_64-unknown-linux-gnu

Is there an idiom for platform configuration that doesn't apply to all platforms?

This ensures MACOSX_VERSION_MIN is set for the correct platform, but now I'm finding a significant downside. As is, x86_64-darwin uses clang 7 and aarch64-darwin uses clang 11. When cross-compiling for aarch64-darwin, MACOSX_DEPLOYMENT_TARGET=11.0. When clang 7 builds for the build platform it uses this environment variable. It's incorrect since it's for the wrong platform, and it's also an error since clang prior to 11 rejects values not starting with 10. It's easy to work around with NIX_CFLAGS_COMPILE_FOR_BUILD in a given package, but I'm considering adding -mmacos-version-min to cflags in the cc-wrapper.

This is ready for review. Still outstanding: how to represent the absence of value for darwin* flags on platforms that aren't darwin.

@thefloweringash This does not evaluate btw.

@thefloweringash This does not evaluate btw.

I didn't know a nice way to have the darwinPlatform be absent on platforms other than darwin. I had it as a throw which was triggering on linux platforms. I've made it a null, which doesn't quite seem correct but should at least not break unless it's actually used, and not silently fail if interpolated.

null seems fine to me.

@thefloweringash Are you going to change https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/darwin/xcode/sdk-pkgs.nix later then?
Also, was the MACOSX_DEPLOYMENT_TARGET issues resolved? This sounds like the sort of thing where we could do MACOSX_DEPLOYMENT_TARGET and MACOSX_DEPLOYMENT_TARGET_FOR_BUILD, and the build compiler would the "suffix salt" black magic to get the right one. (c.f. the pkg-config wrapper and PKG_CONFIG_PATH for the most self-contained example of that.)

Is this ready now?

@thefloweringash Are you going to change https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/darwin/xcode/sdk-pkgs.nix later then?

Updated to include this. I don't know of any example that uses it in the nixpkgs tree so I haven't tested it. If anyone that relies on cross compiling to iPhone has a chance to test it, it would be appreciated.

Also, was the MACOSX_DEPLOYMENT_TARGET issues resolved? This sounds like the sort of thing where we could do MACOSX_DEPLOYMENT_TARGET and MACOSX_DEPLOYMENT_TARGET_FOR_BUILD, and the build compiler would the "suffix salt" black magic to get the right one. (c.f. the pkg-config wrapper and PKG_CONFIG_PATH for the most self-contained example of that.)

I've now added support for the MACOSX_DEPLOYMENT_TARGET_FOR_BUILD variable, which required making a variable mangler that operated on a singular value.

Is this ready now?

I believe so.

@Ericson2314 feel free to merge if this looks good to you.

Took me a second to figure out what mangleVarSingle is for, but yeah looks good. Sometimes I wish we had build-cc, cc, and target-cc rather than these tools prefixed with concrete platforms, and then we wouldn't have to worry about conflicts. Thanks for handling the conflict case correctly.

(As to iOS cross, I will someday need to bump our stuff to use this version of Nixpkgs, but i don't have the phones to test with me. I like this design better so if there are regressions they should be plenty easy to fix and totally worth it :).)

authors: Ericson2314 domenkozar holymonson thefloweringash veprbl


text:
taskwarrior-tui: 0.9.10 -> 0.9.12

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/kdheepak/taskwarrior-tui/releases.
meta.description for taskwarrior-tui is: "A terminal user interface for taskwarrior "
meta.homepage for taskwarrior-tui is: "https://github.com/kdheepak/taskwarrior-tui"
meta.changelog for taskwarrior-tui is: ""
Updates performed

Rust 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

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 0.9.12 with grep in /nix/store/785w7dkr2l4w4kllg1ljx5sl9spy5wnc-taskwarrior-tui-0.9.12

directory tree listing: https://gist.github.com/0cc96e4cbe02fa9a8cb84f3c678da17f

du listing: https://gist.github.com/7bbbd8ea3b0b9995dc9024292749199b

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

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
taskwarrior-tui

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/785w7dkr2l4w4kllg1ljx5sl9spy5wnc-taskwarrior-tui-0.9.12 \
  --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 taskwarrior-tui https://github.com/r-ryantm/nixpkgs/archive/4cf0fb07a65a76583bc164404454738e56e1ef29.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/785w7dkr2l4w4kllg1ljx5sl9spy5wnc-taskwarrior-tui-0.9.12
ls -la /nix/store/785w7dkr2l4w4kllg1ljx5sl9spy5wnc-taskwarrior-tui-0.9.12/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:

taskwarrior-tui

Maintainer pings
cc @matthiasbeyer for testing.

Cannot review because github sends broken patch URLs.

obsolete

authors: Lassulus matthiasbeyer r-ryantm


text:
fcitx5-rime: 5.0.3 -> 5.0.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/fcitx5-rime/versions.
meta.description for fcitx5-rime is: "RIME support for Fcitx5"
meta.homepage for fcitx5-rime is: "https://github.com/fcitx/fcitx5-rime"
meta.changelog for fcitx5-rime is: ""
Updates performed

Version update

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
fcitx result is not automatically checked, because some binaries gets stuck in daemons

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

4 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
fcitx5-rime
tests.nixos-functions.nixos-test

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/2msxlmf11p0p7k6j2qrw7q2mkzw4vfgf-fcitx5-rime-5.0.4 \
  --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 fcitx5-rime https://github.com/r-ryantm/nixpkgs/archive/5f24a13cbfe86e0de62b80ca4f715cc1e196470a.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/2msxlmf11p0p7k6j2qrw7q2mkzw4vfgf-fcitx5-rime-5.0.4
ls -la /nix/store/2msxlmf11p0p7k6j2qrw7q2mkzw4vfgf-fcitx5-rime-5.0.4/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:

fcitx5-rime

Maintainer pings
cc @poscat0x04 for testing.

Result of nixpkgs-review pr 113907 at 5f24a13c run on aarch64-linux 1

1 package built:

fcitx5-rime

1 suggestion:

warning: unused-argument
Unused argument: fetchurl.
Near pkgs/tools/inputmethods/fcitx5/fcitx5-rime.nix:2:3:
  |
2 | , fetchurl
  |   ^

authors: r-rmcgibbo r-ryantm


text:
zoxide: 0.5.0 -> 0.6.0

https://github.com/ajeetdsouza/zoxide/compare/v0.5.0...v0.6.0

Motivation for this change
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"
[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.

Closing in favor of https://github.com/NixOS/nixpkgs/pull/118875, which additionally fixes the build on darwin.


text:
cawbird: 1.3.2 -> 1.4.0

Motivation for this change

regular minor feature update, changelog: https://github.com/IBBoard/cawbird/releases/tag/v1.4
specified exact version of GPLv3 usage

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"
[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)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build cawbird

@SuperSandro2000 These are the default keys from upstream as provided in https://github.com/IBBoard/cawbird/blob/master/README.md#preparation.
It'd be nice to have separate keys for the nixpkgs build, but only Twitter accounts with a linked phone number are able to request API keys which I'm unwilling to do. So unless anyone else provides new keys, we're gonna use the ones from upstream despite all the app-level rate limiting.

Can you add a comment with a short explanation and the link? That would be great.

:ballot_box_with_check:


text:
opentelemetry-collector: init at 0.26.0

Motivation for this change
Add https://github.com/open-telemetry/opentelemetry-collector/.
Note this is built using the source at https://github.com/open-telemetry/opentelemetry-collector-contrib/ rather than the main project, as it has more receivers and exporters. It has the same license and is a strict superset as noted in the description:

Please note that this repository and its releases are a superset of the core repository.

However I have left the binary name as otelcontribcol.
Things done

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

[ ] NixOS
[x] macOS
[x] 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 123232 at 43975052 run on x86_64-linux 1

1 package failed to build:

opentelemetry-collector

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement. Does something look off? Please file an issue or reach out on IRC.

@ofborg build opentelemetry-collector opentelemetry-collector.passthru.tests

lukegb@Mac-mini pr123232 % ./result/bin/otelcontribcol --version
otelcontribcol version latest

authors: lukegb r-rmcgibbo uri-canva


text:
python3Packages.aioswitcher: 1.2.3 -> 1.2.5

Motivation for this change
Update to latest upstream release 1.2.5
Change log: https://github.com/TomerFi/aioswitcher/releases/tag/1.2.5
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/)
[ ] Added a release notes entry if the change is major or breaking
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 125577 at 2a7f5370 run on aarch64-linux 1

3 packages built successfully:

home-assistant
python38Packages.aioswitcher
python39Packages.aioswitcher

authors: fabaff r-rmcgibbo


text:
use File::Spec to remove double backslashes from grub conf file

This pull request fixes the double backslash issue without turning relative paths into absolute ones. My previous pull request used Cwd::abs_path() which mangled relative paths in the boot.cfg file.
Here is some example usage of File::Spec from the command line to give some intuition about how it works:
$ perl -MFile::Spec -le 'print File::Spec->canonpath("//")'
/
$ perl -MFile::Spec -le 'print File::Spec->canonpath("./test")'
test
$ perl -MFile::Spec -le 'print File::Spec->canonpath("a/b/c")'
a/b/c
$ perl -MFile::Spec -le 'print File::Spec->canonpath("//test")'
/test

Thanks!

Here is some documentation on File::Spec->canonpath from the documentation:

canonpath
No physical check on the filesystem, but a logical cleanup of a path.
$cpath = File::Spec->canonpath( $path ) ;
Note that this does not collapse x/../y sections into y. This is by design. If /foo on your system is a >symlink to /bar/baz, then /foo/../quux is actually /bar/quux, not /quux as a naive ../-removal would give >you. If you want to do this kind of processing, you probably want Cwd 's realpath() function to actually >traverse the filesystem cleaning up paths like this.

I am sorry, @benwbooth, but you are completely incorrect in your assertion regarding the nature of the problem---it was exactly a consequence of no value being returned.
This was mentioned---albeit perhaps not as clearly as it might have been) in #12949 ("it does spew a bunch of complaints about concatenating an undefined variable"), and it is quite easy for you to observe for yourself: rollback your nixpkgs to your prior commit, and run nix-rebuild switch.  What you will then see is:
    Use of uninitialized value $kernel in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 356.
    Use of uninitialized value $initrd in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 357.
    Use of uninitialized value $kernel in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 356.
    Use of uninitialized value $initrd in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 357.
    Use of uninitialized value $kernel in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 356.
    Use of uninitialized value $initrd in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 357.
    Use of uninitialized value $kernel in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 356.
    Use of uninitialized value $initrd in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 357.
    Use of uninitialized value $kernel in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 356.
    Use of uninitialized value $initrd in concatenation (.) or string at /nix/store/sg7grlwi2xsx3f1gx081gh0vcw6y43x3-install-grub.pl line 357.

repeated many, many times.  And the resulting grub.cfg has entries that look like:
    menuentry "NixOS - Default" {
    search --set=drive1 --fs-uuid bbf97785-583e-42f5-a03b-15b3e183191a
    search --set=drive2 --fs-uuid bbf97785-583e-42f5-a03b-15b3e183191a
      linux  systemConfig=/nix/store/5hqspna6lybajh2bb8an0hy4mnr2xvvb-nixos-system-aching-16.03.git.b861bf8 init=/nix/store/5hqspna6lybajh2bb8an0hy4mnr2xvvb-nixos-system-aching-16.03.git.b861bf8/init loglevel=4
      initrd
    }

Which is missing paths to both the kernel and the initrd, which are the two things your changes were touching.
So I am, in fact, quite certain that the problem with your prior change was that you ended up returning no data, and thus I am skeptical of any change to this code that doesn't take the absolute minimum precaution of making sure that some value is returned before it makes changes that can so easily render someone's system unbootable.

I think it would be safer and cleaner to prevent the extra slash getting in the relevant variables ($grubBoot->path I think) in the first place, instead of trying to fix the damage everywhere it's used. I think https://github.com/benwbooth/nixpkgs/blob/master/nixos/modules/system/boot/loader/grub/install-grub.pl#L140 is the source of the problem.

@mdorman, sorry, I somehow misread that part of your issue description.
Maybe the problem with my original pull request was that Cwd::abs_path() returns undef if it fails to construct an absolute path from a given relative path. Based on a reading of the code I don't think File::Spec->canonpath has this issue, but in any case, I would be happy with any solution to this problem that both fixes the double backslash issue and doesn't break grub! @dezgeg's idea may be the more sensible one if it prevents any further issues like the one @mdorman experienced.
Thanks again for everyone's input on this issue.

If anyone else stumbles upon the same issue I've had with pygrub and nix, I found a workaround:
Apparently, this is only an issue if your /boot partition is formatted with ext2/3/4. If you format the /boot partition using fat32, reiserfs, or some other format, the double-backslash is ignored by pygrub.

It seems to me this could be closed?

authors: benwbooth dezgeg joachifm mdorman


text:
checkstyle: 8.44 -> 8.45

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/checkstyle/checkstyle/releases.
meta.description for checkstyle is: "Checks Java source against a coding standard"
meta.homepage for checkstyle is: "http://checkstyle.sourceforge.net/"
meta.changelog for checkstyle is: ""
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

/nix/store/dcmshsks0inzwkvqdag85xdbj2bn359k-checkstyle-8.45/bin/checkstyle passed the binary check.

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

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

found 8.45 with grep in /nix/store/dcmshsks0inzwkvqdag85xdbj2bn359k-checkstyle-8.45

found 8.45 in filename of file in /nix/store/dcmshsks0inzwkvqdag85xdbj2bn359k-checkstyle-8.45

directory tree listing: https://gist.github.com/0c5595fe4295f8c973d314595f308ff1

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

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

3 total rebuild path(s)

1 package rebuild(s)

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

First fifty rebuilds by attrpath
checkstyle

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/dcmshsks0inzwkvqdag85xdbj2bn359k-checkstyle-8.45 \
  --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 checkstyle https://github.com/r-ryantm/nixpkgs/archive/b8f14c331176c1fde5740b29fe8a27a2957a7bb4.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/dcmshsks0inzwkvqdag85xdbj2bn359k-checkstyle-8.45
ls -la /nix/store/dcmshsks0inzwkvqdag85xdbj2bn359k-checkstyle-8.45/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:

checkstyle

Maintainer pings
cc @pSub for testing.

Result of nixpkgs-review pr 132376 at b8f14c33 run on x86_64-linux 1

1 package built successfully:

checkstyle

1 suggestion:

warning: unclear-gpl
lgpl21 is a deprecated license, please check if project uses lgpl21Plus or lgpl21Only and change meta.license accordingly.
Near pkgs/development/tools/analysis/checkstyle/default.nix:33:5:
   |
33 |     license = licenses.lgpl21;
   |     ^

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

1 package built:

checkstyle

authors: r-rmcgibbo r-ryantm siraben


text:
python3Packages.karton-dashboard: 1.2.0 -> 1.2.1

Motivation for this change
Update to latest upstream release 1.2.1
Change log: https://github.com/CERT-Polska/karton-dashboard/releases/tag/v1.2.1
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"
[ ] 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 136278 run on x86_64-linux 1

2 packages built:

python38Packages.karton-dashboard
python39Packages.karton-dashboard


text:
llvmPackages_13.compiler-rt: Mark as broken on Aarch64

To avoid unnecessary builds but this needs to be fixed ASAP. Chromium
already depends on it and a lot of additional packages, including Mesa,
will depend on it after the stable release.

Motivation for this change
I made some progress in #136574 but it needs more work and I lack time.
cc @thefloweringash as the Aarch64 maintainer for Chromium
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.

How about just disabling libfuzzer?

@r-burns unfortunately I don't have time to take a look, as I noted above. Feel free to submit a PR.

authors: primeos r-burns


text:
traefik: 2.5.2 -> 2.5.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/traefik/versions.
meta.description for traefik is: "A modern reverse proxy"
meta.homepage for traefik is: "https://traefik.io"
meta.changelog for traefik is: "https://github.com/traefik/traefik/raw/v2.5.3/CHANGELOG.md"
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

/nix/store/h5mpcrxhykpn7435hwa77rg2dh8pbb07-traefik-2.5.3/bin/traefik passed the binary check.

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

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

found 2.5.3 with grep in /nix/store/h5mpcrxhykpn7435hwa77rg2dh8pbb07-traefik-2.5.3

found 2.5.3 in filename of file in /nix/store/h5mpcrxhykpn7435hwa77rg2dh8pbb07-traefik-2.5.3

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

du listing: https://gist.github.com/012108db698f1f1cae82cbd979979ee4

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

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
traefik

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/h5mpcrxhykpn7435hwa77rg2dh8pbb07-traefik-2.5.3 \
  --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 traefik https://github.com/r-ryantm/nixpkgs/archive/ba482884f4e3d9c9419d67513c70df2d333eead8.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/h5mpcrxhykpn7435hwa77rg2dh8pbb07-traefik-2.5.3
ls -la /nix/store/h5mpcrxhykpn7435hwa77rg2dh8pbb07-traefik-2.5.3/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:

traefik

Maintainer pings
cc @vdemeester @kalbasit for testing.

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

1 package built:

traefik

authors: figsoda r-ryantm


text:
python3Packages.pysiaalarm: 3.0.1 -> 3.0.2

Motivation for this change
Update to latest upstream release 3.0.2
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"
[ ] 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 140196 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.pysiaalarm
python39Packages.pysiaalarm


text:
invidious: unstable-2021-11-08 -> unstable-2022-03-07

Motivation for this change
Add update script.
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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[x] (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.

With https://github.com/iv-org/invidious/pull/2685 substituteInPlace src/invidious/helpers/helpers.cr ... needs fixing and other stuffs breaks during build as well.

Thanks for maintaining this branch for so long.  I hope it gets merged soon 🌞.

Just tested this by cherry-picking this PR, enabling services.invidious.enable, going to localhost:3000 and doing any search. Unfortunately this runs into this issue, which makes it essentially unusable: https://github.com/iv-org/invidious/issues/2753
Title: SSL_connect: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED (OpenSSL::SSL::Error)
Date: 2022-03-12T02:41:05Z
Route: /search?q=aoeu
Version: 2022.03.07-440549f @ master

Backtrace

SSL_connect: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED (OpenSSL::SSL::Error)
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from /nix/store/wpiwbvbcia4w9qlmdcbdvwkiqavxcg7l-invidious-unstable-2022-03-07/bin/invidious in '??'
  from ???

This doesn't happen with the old version without this PR, so this is a regression :/

The reason for this issue is that the statically linked boringssl (required by lsquic) overrides OpenSSL’s CA certificate file location.
It can be fixed either by patching boringssl (like in https://github.com/NixOS/nixpkgs/pull/145882) or by setting the SSL_CERT_FILE environment variable (like @squalus pointed out in https://github.com/NixOS/nixpkgs/pull/145882#issuecomment-972104021).
Patching boringssl
diff --git a/pkgs/servers/invidious/lsquic.nix b/pkgs/servers/invidious/lsquic.nix
index e44e41cee09..50f6d186705 100644
--- a/pkgs/servers/invidious/lsquic.nix
+++ b/pkgs/servers/invidious/lsquic.nix
@@ -9,6 +9,11 @@ let
       url = "https://boringssl.googlesource.com/boringssl";
       inherit (versions.boringssl) rev sha256;
     };
+
+    patches = (old.patches or [ ]) ++ [
+      # Use /etc/ssl/certs/ca-certificates.crt instead of /etc/ssl/cert.pem
+      ./use-etc-ssl-certs.patch
+    ];
   });
 in
 stdenv.mkDerivation rec {
diff --git a/pkgs/servers/invidious/use-etc-ssl-certs.patch b/pkgs/servers/invidious/use-etc-ssl-certs.patch
new file mode 100644
index 00000000000..ea62378008d
--- /dev/null
+++ b/pkgs/servers/invidious/use-etc-ssl-certs.patch
@@ -0,0 +1,13 @@
+diff --git a/crypto/x509/x509_def.c b/crypto/x509/x509_def.c
+index d2bc3e5c1..329580075 100644
+--- a/crypto/x509/x509_def.c
++++ b/crypto/x509/x509_def.c
+@@ -67,7 +67,7 @@
+
+ #define X509_CERT_AREA          OPENSSLDIR
+ #define X509_CERT_DIR           OPENSSLDIR "/certs"
+-#define X509_CERT_FILE          OPENSSLDIR "/cert.pem"
++#define X509_CERT_FILE          "/etc/ssl/certs/ca-certificates.crt"
+ #define X509_PRIVATE_DIR        OPENSSLDIR "/private"
+ #define X509_CERT_DIR_EVP        "SSL_CERT_DIR"
+ #define X509_CERT_FILE_EVP       "SSL_CERT_FILE"

Setting the SSL_CERT_FILE environment variable with a wrapper
diff --git a/pkgs/servers/invidious/default.nix b/pkgs/servers/invidious/default.nix
index 14eed9a3be7..cfe423236f5 100644
--- a/pkgs/servers/invidious/default.nix
+++ b/pkgs/servers/invidious/default.nix
@@ -56,7 +56,7 @@ crystal.buildCrystalPackage rec {
           --replace 'Process.run(%(rsvg-convert' 'Process.run(%(${lib.getBin librsvg}/bin/rsvg-convert'
     '';

-  nativeBuildInputs = [ pkg-config shards ];
+  nativeBuildInputs = [ makeWrapper pkg-config shards ];
   buildInputs = [ libxml2 openssl sqlite ];

   format = "crystal";
@@ -77,6 +77,9 @@ crystal.buildCrystalPackage rec {
   '';

   postInstall = ''
+    wrapProgram $out/bin/invidious \
+        --set SSL_CERT_FILE "/etc/ssl/certs/ca-bundle.crt" \
+
     mkdir -p $out/share/invidious/config

     # Copy static parts

Applying any of those patches fixed the problem for me.

The NixOS module should certainly be fixed before this can be merged, the NIX_SSL_FILE approach sounds good

sbruder's 970d249d39ccac356c705e6e4db6318ffe93dd42 fixes that.

sbruder's 970d249d39ccac356c705e6e4db6318ffe93dd42 fixes that.

I will squash them before the refactor in c3bae5b1191ddfdc036407884d603cff5cc6717f, otherwise it will get ugly.

aarch64-darwin build fails in CI. Is that expected? If so the platform should be marked as not supported somewhere

The error Failed to spawn codesign_allocate: No such file or directory seems fixable, but I don't know the first thing about darwin, so I will mark it as broken.

Looking good, thanks!

authors: Infinisil isker sbruder schnusch


text:
cups: Add passthru printing test

Motivation for this change
Adding passthru printing test for the cups package
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)
[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.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.

Cannot nix-instantiate `cups.passthru.tests' because:
error: undefined variable 'nixosTests' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ofborg-evaluator-0/pkgs/misc/cups/default.nix:137:26

You need to add nixosTests to the arguments

Did you really request my review 6 days ago? I only received the notification today)

@ncfavier Thanks for the note. Just added you to the review list :)

authors: ncfavier onny


text:
update nixos

Motivation for this change
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
[ ] OS X
[ ] 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.

update channel


text:
python310Packages.lxml: 4.8.0 -> 4.9.0

Description of changes

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

@ofborg build python310Packages.lxml

https://bugs.launchpad.net/lxml/+bug/1976407


text:
gpm: pull patch pending upstream inclusion to fix parallel install

Without the change when install parallelism is enabled it fails as:
install -c gpm ../gpm-unstable-2020-06-17/sbin/gpm
install: cannot create regular file '../gpm-unstable-2020-06-17/sbin/gpm': No such file or directory

Description of changes

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.

@GrahamcOfBorg eval

@ofborg eval

You wanna set enableParallelBuilding too or not?

Yeah, enabling it here sounds reasonable. Added enableParallelBuilding = true;. Thank you!

Oh, did you intend to target staging?

Oh, did you intend to target staging?

I somehow mis-remembered gpm to be a low-level depend used by ncurses. But it's guarded by mouseSupport = false;. master should be fine. Flipped.

authors: Mindavi trofi veprbl


text:
trino-cli: init at 387

Description of changes
Add trino-cli. The Trino CLI provides a terminal-based, interactive shell for running queries
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[x] 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.

@legendofmiracles thanks for the review!

@legendofmiracles I believe I addressed all of your comments. Please take a look when you get a chance. Thanks!

@legendofmiracles comments addressed, thanks!

@legendofmiracles done.


text:
nauty: 2.7r3 -> 2.7r4

Description of changes

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

[ ] Fits CONTRIBUTING.md.

@ofborg build sage


text:
notion: groff -> mandoc & busybox -> which

bad name/version
whole busybox just for which
one of multiple groff -> mandoc test subjects

cc @jfb

fair warning: @joachifm has reservation agianst the mandoc stuff he has expressed in https://github.com/NixOS/nixpkgs/pull/18746

closed since it's not going anywhere.

authors: RamKromberg siddharthist