text:
libxkbcommon: build with wayland support tools

Motivation for this change
As wayland is the future anyway, it really doesn't make sense to not have the wayland support tools built with libxkbcommon.
Size difference:
/nix/store/czvbssspmfmm40syq0ylbczf9c4lv6ss-libxkbcommon-1.0.3     45346264
/nix/store/g81gf06jmyxp0j4ymjnjlggz71pz9zcq-libxkbcommon-1.0.3     46533584
Very large rebuild, so staging first.
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/)
[X] 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.

Could you go a bit more into why this is required?

As mentioned in the first post, it's just to get the wayland tools.

As mentioned in the first post, it's just to get the wayland tools.

I've read your comments but tbh I'm still not convinced (it's only one tool, or rather a subcommand, and it's an interactive "debugger"). I don't mind but I think we should at least state that in the commit message (to avoid someone reverting this due to concerns that this wasn't really worth it).

@primeos, do you still have concerns with the updated comment?

"This is the wayland equivalent of xev on X11." <- That comment? Is there a source for this? I haven't compared the two but IIRC interactive-wayland will at least only print keyboard related events. https://git.sr.ht/~sircmpwn/wev (also in Nixpkgs) should be the Wayland equivalent of xev.

"This is the wayland equivalent of xev on X11." <- That comment? Is there a source for this? I haven't compared the two but IIRC interactive-wayland will at least only print keyboard related events.

Sure, right, but do we really want to make such a big deal out of what is a tiny issue?
The point is, with this flag, you get a sub command that is helpful to some. For everybody else, the price is 1MB.
Don't we have bigger things to worry about?

@peterhoeg not sure if my comments came of wrong but I never intended to prevent this from being merged (but I realize now that I forgot to dismiss my earlier review, which was a blocker for me but is resolved now). My intention was simply to raise some concerns to see if they where considered so that we don't regret the decision later (and personally I don't see this change as really necessary but that doesn't mean that I'm against it - feel free to merge it). The very slightly increased closure size is no problem at all IMO but the addition of Wayland into the dependency chain could theoretically cause some issues (but if that would happen we could still look for other solutions than reverting the change).
Anyway, the tl;dr is to regard my position as neutral and that I have no issue if you or anyone else merges this PR. Sorry if that came of wrong.

but the addition of Wayland into the dependency chain could theoretically cause some issues

Such as?

Anyway, the tl;dr is to regard my position as neutral and that I have no issue if you or anyone else merges this PR. Sorry if that came of wrong.

Nothing to apologize for - all good! I hope my earlier message didn't come across as confrontational. Just trying to
move this forward.

Such as?

Should hopefully be very unlikely but e.g. dependency cycles (wayland's dependencies for documentation aren't low-level) and it could (but shouldn't) make cross-compilation more difficult. But that's all speculation (I haven't looked at the dependency graph) and shouldn't matter for now.
Normally I wouldn't even bring it up but in this case I made an exception because libxkbcommon is used as a library and I feel like few to none users have libxkbcommon.bin installed which is why I don't see a practical advantage (so it isn't that I'm particularly concerned about potential drawbacks, it's just that I don't see a useful (enough) advantage / that we're enabling something simply because we can without really knowing if it'll be helpful/useful - but that's just a very subjective opinion).
(And I'm not that happy with some irrelevant details like the reformatting, the renaming of withWaylandSupport (both names aren't ideal and it requires changes in case anyone already uses it), and the new "This is the wayland equivalent of xev on X11." comment - but that's all irrelevant/nitpicking/bikeshedding)

I hope my earlier message didn't come across as confrontational. Just trying to
move this forward.

No problem, it didn't come across as confrontational. I just wanted to say that I'm not trying to prevent this from moving forward.
Tbh I start regretting to even bring up those concerns as this has lead to unnecessary bikeshedding over a simple change that should even be very easy to revert at any point in the future in case we'll run into any (minor) issues that are difficult to avoid.
So to make this easier I'll just approve it so that we can move this forward :D (but I'm basically neutral here as I don't see any real reasons for/against this change)

authors: peterhoeg primeos


text:
sickgear: 0.23.15 -> 0.23.16

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/SickGear/SickGear/releases.
meta.description for sickgear is: "The most reliable stable TV fork of the great Sick-Beard to fully automate TV enjoyment with innovation"
meta.homepage for sickgear is: "https://github.com/SickGear/SickGear"
meta.changelog for sickgear 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

Warning: no invocation of /nix/store/z51v42y7xy1xw8is3r5vsm69xhkc9mzp-sickgear-0.23.16/bin/sickgear had a zero exit code or showed the expected version

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

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

found 0.23.16 with grep in /nix/store/z51v42y7xy1xw8is3r5vsm69xhkc9mzp-sickgear-0.23.16

found 0.23.16 in filename of file in /nix/store/z51v42y7xy1xw8is3r5vsm69xhkc9mzp-sickgear-0.23.16

directory tree listing: https://gist.github.com/43bdb7f938e9d72158ac108cacb7bcf6

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

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

1 total rebuild path(s)

1 package rebuild(s)

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

First fifty rebuilds by attrpath
sickgear

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/z51v42y7xy1xw8is3r5vsm69xhkc9mzp-sickgear-0.23.16 \
  --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 sickgear https://github.com/r-ryantm/nixpkgs/archive/7539ba07a211bf2153a62ca9478fe61d7b3cedb5.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/z51v42y7xy1xw8is3r5vsm69xhkc9mzp-sickgear-0.23.16
ls -la /nix/store/z51v42y7xy1xw8is3r5vsm69xhkc9mzp-sickgear-0.23.16/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:

sickgear

Maintainer pings
cc @rembo10 for testing.

Result of nixpkgs-review pr 119160 at 7539ba07 run on x86_64-linux 1

1 package built successfully:

sickgear

2 suggestions:

warning: unclear-gpl
gpl3 is a deprecated license, please check if project uses gpl3Plus or gpl3Only and change meta.license accordingly.
Near pkgs/servers/sickbeard/sickgear.nix:31:5:
   |
31 |     license     = licenses.gpl3;
   |     ^

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/servers/sickbeard/sickgear.nix:22:3:
   |
22 |   installPhase = ''
   |   ^

source: gharchive/pull-request

authors: r-rmcgibbo r-ryantm

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
home-assistant: find unstable versions in parse-requirements.py

Motivation for this change
Previously unstable versions would not have been found, because the
regular expression was looking for a numeric version after the attribute
name. When the version is however an unstable one, it would start with

unstable-2021-04-23

and therefore not match the pattern.
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
[x] Fits CONTRIBUTING.md.

@fabaff Fix for the slackclient package included.

Thanks, nice work.

authors: fabaff mweinelt


text:
trivial-builders: refactor writeTextFile to be overridable, fixes #126344

NOTE: For anyone that looks at this after it's merged, the most up to date and detailed information will be in the commit message.
Motivation for this change
This fixes #126344, specifically with the goal of enabling overriding the
checkPhase argument.
This allows among other things, enabling bash extension for the checkPhase.
Previously using such bash extensions was prohibited by the writeShellScript
code because there was no way to enable the extension in the checker.
Here is an example of what is now possible:
(writeShellScript "foo" ''
  shopt -s extglob
  echo @(foo|bar)
  '').override (old: {
    checkPhase = ''
      export BASHOPTS
      shopt -s extglob
      ${old.checkPhase}
      #shopt -u extglob\n
      '';
    })

Things done
I tested if the example expression above evals.

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

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

[ ] Fits CONTRIBUTING.md.

cc @ncfavier

054eb1b82c8077b4886b35ac32f57d29ac069fe8 can be dropped entirely, right?

Yeah, I just figured I'd leave history until we are OK to merge and then I'll squash or force push or something.

@ofborg build build tests.trivial-overriding

@ofborg build build tests.trivial-overriding

@ofborg build tests.trivial-overriding

authors: deliciouslytyped sternenseemann


text:
python3Packages.spiderpy: init at 1.5.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"
[ ] Tested execution of all binary files (usually in ./result/bin/)
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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 126792 at e4c3c50d run on aarch64-linux 1

3 packages built successfully:

home-assistant
python38Packages.spiderpy
python39Packages.spiderpy

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

3 packages built:

home-assistant
python38Packages.spiderpy
python39Packages.spiderpy

authors: dotlambda fabaff r-rmcgibbo


text:
Redundant DHCP support in initrd

This is the followup to https://github.com/NixOS/nixpkgs/commit/cc925d0506ab2a049d5ee55c1173950073ed307f#commitcomment-15838365. It's more for discussion than for merge now! There may be some problems of old DHCP support via ip=dhcp, so this needs a comment from @edolstra. Notice that I haven't tested changes for amazon-image.nix!
One more thing that @edolstra pointed out is that ipconfig from mkinitcpio-net-utils seems redundant there when we have BusyBox. It's there only because it is tedious to parse ip= string by ourselves, but we may want to do this is future. On the other hand, ipconfig is only 28K in size and is there only if initrd networking is enabled, so this maybe is not so relevant.

:-1:, we should be able to configure networking via networking.* rather than setting boot.kernelParams. The latter is discoverable and consistent with stage 2 network configuration.

Hm, I think that configuring this in networking (or NixOS options in general) sounds better, too -- now I see your point. Then there are several questions:

Do we still want to have ip=? There might be other people already using it, so we should be careful to not break their (remote!) setups.
We wouldn't be able to have 100% consistency because networking has too many things inside (firewall, WLAN, virtual interfaces -- to name a few) that we can't (and don't want) to bring inside initrd. So we need to somehow document what options are supported in initrd and what are not. One solution may be to have all supported settings duplicated in a distinct boot.initrd.network namespace, but it's not ideal.

Let's close this and move to a separate issue for discussion instead.

authors: abbradar edolstra


text:
python3Packages.discogs_client: 2.3.0 -> 2.3.12

Motivation for this change
Update to latest upstream release 2.3.12
Change log: https://github.com/joalla/discogs_client/releases/tag/v2.3.12
Rename from discogs_client to discogs-client.
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/)
21.11 Release Notes (or backporting 21.05 Relase notes)

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

[x] Fits CONTRIBUTING.md.

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

6 packages built:

beets
beetsExternalPlugins.alternatives
beetsExternalPlugins.copyartifacts
beetsExternalPlugins.extrafiles
python38Packages.discogs-client (python38Packages.discogs_client)
python39Packages.discogs-client (python39Packages.discogs_client)

Result of nixpkgs-review pr 129027 at d1eeee03 run on aarch64-linux 1

6 packages built successfully:

beets
beetsExternalPlugins.alternatives
beetsExternalPlugins.copyartifacts
beetsExternalPlugins.extrafiles
python38Packages.discogs-client
python39Packages.discogs-client

authors: fabaff r-rmcgibbo


text:
nushell: 0.33.0 -> 0.34.0

Motivation for this change
https://github.com/nushell/nushell/releases/tag/0.34.0
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

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

[x] Fits CONTRIBUTING.md.

Having trouble building 0.34.0 under Nix because of zstd-sys, which tries to bundle zstd as a submodule.


text:
python3Packages.testfixtures: 6.17.1 -> 6.18.0

Motivation for this change
Update to latest upstream release 6.18.0
Change log: https://github.com/Simplistix/testfixtures/blob/master/CHANGELOG.rst#6180-15-jul-2021
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 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 133276 run on x86_64-linux 1

10 packages failed to build:

python38Packages.scrapy
python38Packages.scrapy-deltafetch
python38Packages.scrapy-fake-useragent
python38Packages.scrapy-splash
python38Packages.sopel
python39Packages.scrapy
python39Packages.scrapy-deltafetch
python39Packages.scrapy-fake-useragent
python39Packages.scrapy-splash
python39Packages.sopel

24 packages built:

borgmatic
bump2version
check-esxi-hardware
giara
home-assistant
privacyidea
python38Packages.connexion
python38Packages.django-simple-captcha
python38Packages.openerz-api
python38Packages.praw
python38Packages.prawcore
python38Packages.pykwalify
python38Packages.pywbem
python38Packages.testfixtures
python38Packages.west
python39Packages.connexion
python39Packages.django-simple-captcha
python39Packages.openerz-api
python39Packages.praw
python39Packages.prawcore
python39Packages.pykwalify
python39Packages.pywbem
python39Packages.testfixtures
python39Packages.west

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

34 packages built:

borgmatic
bump2version
check-esxi-hardware
giara
home-assistant
privacyidea
python38Packages.connexion
python38Packages.django-simple-captcha
python38Packages.openerz-api
python38Packages.praw
python38Packages.prawcore
python38Packages.pykwalify
python38Packages.pywbem
python38Packages.scrapy
python38Packages.scrapy-deltafetch
python38Packages.scrapy-fake-useragent
python38Packages.scrapy-splash
python38Packages.sopel
python38Packages.testfixtures
python38Packages.west
python39Packages.connexion
python39Packages.django-simple-captcha
python39Packages.openerz-api
python39Packages.praw
python39Packages.prawcore
python39Packages.pykwalify
python39Packages.pywbem
python39Packages.scrapy
python39Packages.scrapy-deltafetch
python39Packages.scrapy-fake-useragent
python39Packages.scrapy-splash
python39Packages.sopel
python39Packages.testfixtures
python39Packages.west

nixpkgs-review reveals no new failures, macos 10.15

authors: fabaff risicle


text:
[21.05] firefox{,-bin}: 91.0 -> 91.0.1; firefox-esr-91: 91.0esr -> 91.0.1esr; firefox-esr-78: 78.12.0esr -> 78.13.0esr

Motivation for this change
Backport #134584
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 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.

@ofborg test firefox firefox-78-esr firefox-91-esr

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

9 packages built:

adoptopenjdk-icedtea-web
dropbox
dropbox-cli
firefox-bin-unwrapped
firefox-esr-78-unwrapped (firefoxPackages.firefox-esr-78)
firefox-esr-91-unwrapped (firefoxPackages.firefox-esr-91)
xulrunner (firefox-unwrapped)
mate.caja-dropbox
slimerjs

Test still passes as well.


text:
pkgsStatic: make pkgsMusl a no-op

When pkgsStatic is already musl, we can let pkgsMusl simply be a no-op.
As the interaction of pkgsStatic and pkgsMusl machinery is currently broken
(see discussion in https://github.com/NixOS/nixpkgs/issues/114510), this fixes pkgsStatic.pkgsMusl.stdenv.

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

Still relevant. Previous command gives same result on current master.

The fact pkgsStatic is using musl is an accident: glibc static build was broken at the time and musl was used instead. Ideally pkgsStatic should differ from pkgsin just having-static` kind of flags.
Nowadays glibc.static is working and I was actually thinking about changing pkgsStatic back to using it.

Well, this whole contraption is conditional on isMusl anyway, so if we stop setting useMusl for glibc linux, it should gracefully use static glibc instead.

@rnhmjoj Do you still plan on moving static back to glibc? (I guess would be nice if you did it. It is quite odd the way it is now. It took me a while to understand why static was using musl. / I was out of context.)

That's the idea, but I don't plan on working on this soon.

I don't think pkgsMusl.pkgsStatic should be a no-op compared to pkgsStatic. It changes the build platform from glibc to musl as well, so makes the difference if you are cross-compiling from glibc to musl-static, or from musl to musl-static.

authors: r-burns rnhmjoj superherointj yu-re-ka


text:
gildas: 20200901_a -> 20211101_a

Motivation for this change
Update gildas to the latest upstream.
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/)
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.

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

1 package built:

gildas

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

1 package built:

gildas

authors: bzizou smaret


text:
qgis: 3.16.13 -> 3.16.14

Motivation for this change
Update to latest LTS.
Things done

Built on platform(s)

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

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

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

[X] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

@lsix In the meantime, 3.22.1 was released. Could you bump to that?

@lsix In the meantime, 3.22.1 was released. Could you bump to that?

3.22.1 is not LTR.

Oops, could have guessed that from when 3.22.1 came out. Is there any particular reasoning behind only packaging the LTS release here? As a user I'd expect the qgis attribute to be the latest release, while something like qgis-lts could point to the LTS release.

Is there any particular reasoning behind only packaging the LTS release here?

I guess there is no reason, I'll try to build 3.22.1.

As a user I'd expect the qgis attribute to be the latest release, while something like qgis-lts could point to the LTS release.

Agree.

Btw would be interested in being a maintainer to qgis, so could you add me to maintainers if you prepare a bump anyway?

@erictapen if you wand to join and help maintain QGIS in nixpkgs, maybe you can create I PR adding yourself in the maintainers list? I’ll happily approve that!  This would have to be in a separate commit from the bump anyway.
On the subject of LTS v.s. non LTS, as NixOS is a non rolling release, I have always found it easier to maintain LTS versions of packages.  Otherwise backport to release branches can be a pain as it can imply backporting dependencies to new versions which can have bigger impacts than just upgrading qgis. This i has be especially true when migrating from QGIS-2 to QGIS-3. And to be fair, at that  time, just having QGIS-2 (LTS) and QGIS-3 (latest) in tree would have be quite a pain. As of now, the dependencies are much closer than what they used to be at that moment, but I kept this habit of only maintaining QGIS-LTS.
Apart from that, and as far as I am aware, there is no strong reason that prevents us from having both a latest and a lts version available.  Hopefully, we fill not see to much situations where the two versions require incompatible dependencies.

I see your point here about the ease of backporting changes to LTS releases. Still there are the unstable channels that always benefit of having the newest version. Also NixOS somewhat has a reputation for always having the newest package version available (see e.g. Newest metric on repology).
Do I understand it right that you would be in favor of maintaining both LTS and latest qgis? If yes, I'd propose to name them qgis-lts and qgis, as that seems to be a common scheme in Nixpkgs.

a vote in favor of qgis-ltr and qgis!
particularly re #71398, i can imagine that at different times trying to keep darwin compatibility working might be better or worse in either of the two packages. on the one hand, once it's built, ltr would seem to be a more stable target. on the other hand, as was/is true with PyQt5 on darwin (for homebrew in addition to nix), it may end up that targeting more modern builds might help keep one of the two formulas working if the old versions of Qt or other dependencies make ltr more brittle the more long in the tooth it gets.

Trusting existing reviews and I guess this is ready to merge.

authors: bobby285271 erictapen lsix sikmir willcohen


text:
[21.11] vault{,bin}: 1.8.4 -> 1.8.6

Motivation for this change
https://github.com/hashicorp/vault/releases/tag/v1.8.5
https://github.com/hashicorp/vault/releases/tag/v1.8.6
#150708
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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

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

[x] Fits CONTRIBUTING.md.

@ofborg build vault nixosTests.vault-postgresql

Thanks @LeSuisse.

authors: LeSuisse thiagokokada


text:
texlive package list: 2015-09-17 -> 2016-05-15

Things done

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

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

Supersedes #15292. Followed approach in default.nix. nix-build -E 'with import <nixpkgs> {}; texlive.combine { inherit (texlive) scheme-full; }' runs successfully. Adding updated packages to fixedHashes.nix missed out on new packages, but I don't know whether there's some other recommended way of adding new packages.
cc @vcunat

This PR removes whole fixedHashes.nix.

And I don't understand the connection with the recent 7abe192b0. That one claims to "fix" the problems.

I don't understand fixedHashes.nix, or more specifically, why we would want it. With it, building texlive.scheme-full complained about lots of incorrect hashes, presumably from packages that have been updated since their entry in fixedHashes.nix was last edited. It seems easier to just update pkgs.nix whenever someone finds a wrong hash. 7abe192 doesn't appear to add any new packages, so has no mathpartir, for example. This PR should supersede it.

fixedHashes.nix contains hashes of the resulting store paths (for non-binary packages). That way you won't get rebuild even if stdenv changes. Without it, all texlive packages will get redownloaded/rebuilt every now and then, consuming space again.

Okay. I don't understand how that works, but I can believe it. So how should new packages be added?

Superseded by https://github.com/NixOS/nixpkgs/pull/16391. Some things are easier done than explained...

authors: laMudri vcunat


text:
screen: 4.8.0 -> 4.9.0

Motivation for this change

Fix build of screen 4.8.0 - the debian patch disappeared from their master branch because they moved on to 4.9.0.
Oh, hey, I guess we should move on to version 4.9.0 too.  Release announcement

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)

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

FYI screen maintainer @vrthra.

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

2 packages built:

apt-dater
screen

authors: chkno siraben


text:
anki-bin: 2.1.49 -> 2.1.51

anki-bin -> 2.1.51
Description of changes
Since the previous version of anki no longer works on nixos-unstable
due to glibc changes the version was bumped to 2.1.51 which works. See #167765
NOTE: The darwin version has not been tested due to lack of a darwin
machine to try it on. The hash and download url has been updated, but
this package should be tested before this pull request is accepted.

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

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

[x] Fits CONTRIBUTING.md.

Addressed all of the comments and added support for aarch64. Again, that support is untested since I don't have access to apple silicon to test it on. Would be great if someone else could test.

I think, due to add-ons compatibility reasons, it should be possible to choose between Qt5 and Qt6.

Hello,
trying this new version anki doesn't start and I get the following error:
Anki starting...
Initial setup...
Running with temporary Qt5 compatibility shims.
Run with DISABLE_QT5_COMPAT=1 to confirm compatibility with Qt6.
Preparing to run...
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /run/opengl-driver/lib/dri/swrast_dri.so) (search paths /run/opengl-driver/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
Command '['gsettings', 'get', 'org.gnome.desktop.interface', 'gtk-theme']' returned non-zero exit status 1.
Qt warning: WebEngineContext used before QtWebEngineCore::initialize() or OpenGL context creation failed.
Qt warning: QGLXContext: Failed to create dummy context
/nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/QtWebEngineProcess: /usr/lib/libz.so.1: no version information available (required by /nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/../lib/libQt6WebEngineCore.so.6)
/nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/QtWebEngineProcess: /usr/lib/libz.so.1: no version information available (required by /nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/../lib/libQt6Gui.so.6)
/nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/QtWebEngineProcess: /usr/lib/libz.so.1: no version information available (required by /nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/../lib/libQt6Gui.so.6)
/nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/QtWebEngineProcess: /usr/lib/libz.so.1: no version information available (required by /nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/../lib/libQt6WebEngineCore.so.6)
/nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/QtWebEngineProcess: /usr/lib/libz.so.1: no version information available (required by /nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/../lib/libQt6Gui.so.6)
/nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/QtWebEngineProcess: /usr/lib/libz.so.1: no version information available (required by /nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/../lib/libQt6Gui.so.6)
Qt info:
GLImplementation:
Surface Type: OpenGL
Surface Profile: NoProfile
Surface Version: 2.0
Using Default SG Backend: yes
Using Software Dynamic GL: no
Using Angle: no
Init Parameters:

application-name Anki
browser-subprocess-path /nix/store/xwi84ffanr87553zjway3c6ygpp8hs3b-anki-bin-2.1.50/share/anki/lib/PyQt6/Qt6/libexec/QtWebEngineProcess
disable-features DnsOverHttpsUpgrade,ConsolidatedMovementXY,InstalledApp,BackgroundFetch,WebOTP,WebPayments,WebUSB,PictureInPicture
disable-gpu
disable-setuid-sandbox
disable-speech-api
enable-features NetworkServiceInProcess,TracingServiceInProcess
enable-threaded-compositing

Starting main loop...

Thanks for doing this update!
The commit message subject should also be formatted as anki-bin: 2.1.49 -> 2.1.51

I can also confirm this works, thanks! 🙂

Anki hasn’t been working at all in unstable for a while now. If you merge
this pull request Anki will work for most people, then new issues can be
made for whatever reason needed.
On Sun, 1 May 2022 at 19:20, Atemu @.***> wrote:

@.**** requested changes on this pull request.
I don't use any but if add-on compatibility is a concern, we should either
allow the choice of both QT versions or only offer QT5 (where available).
—
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/168300#pullrequestreview-958613137,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ5KBL6Y5COHF6NN3MZ62LVH24OJANCNFSM5TEBDV5A
.
You are receiving this because you authored the thread.Message ID:
@.***>

What pull request? Also instead of creating issues in our big collection we should try to fix issues right away.

I think GitHub is acting up right now, that message was written by me five months ago, no idea why it says two hours

authors: Patryk27 SuperSandro2000 TheBlackBeans dnaq euank robert-elles


text:
asterisk: add nixos test

Description of changes
Added a test for the asterisk 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

[ ] Fits CONTRIBUTING.md.

cc: @DerTim1 @yayayayaka @sbruder

@ofborg build asterisk.passthru.tests


text:
liferea: 1.12.9 -> 1.13.8

Description of changes
Update to version 1.13.8
The stable versions (1.12.x) do not build with current versions of webkitgtk on nixpkg master.  See https://github.com/NixOS/nixpkgs/pull/170538#issuecomment-1117939492
The unstable version is working well for me. It is also on Archlinux and Debian 12. So I suppose it is stable enough for us.
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

I believe that since https://github.com/lwindolf/liferea/commit/ab849555164bc3a6a287bd6a88ad5f83633efe8f fribidi is required, although for some reason liferea build process doesn't error on missing header.

I believe that since lwindolf/liferea@ab84955 fribidi is required, although for some reason liferea build process doesn't error on missing header.

Probably it is automatically found because it is propagated from other dependencies. I see that gtk3 propagates fribidi.

authors: McSinyx romildo


text:
python310Packages.mwoauth: 0.3.7 -> 0.3.8

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.mwoauth is: "Python library to perform OAuth handshakes with a MediaWiki installation"
meta.homepage for python310Packages.mwoauth is: "https://github.com/mediawiki-utilities/python-mwoauth"
meta.changelog for python310Packages.mwoauth is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 0.3.8 with grep in /nix/store/c214a797skyxfp0j4y7xpvzd9ymw03za-python3.10-mwoauth-0.3.8
found 0.3.8 in filename of file in /nix/store/c214a797skyxfp0j4y7xpvzd9ymw03za-python3.10-mwoauth-0.3.8

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

8 total rebuild path(s)

4 package rebuild(s)

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

First fifty rebuilds by attrpath
python310Packages.mwoauth
python310Packages.oauthenticator
python39Packages.mwoauth
python39Packages.oauthenticator

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.mwoauth https://github.com/r-ryantm/nixpkgs/archive/393557ebef4a8494a794102f27777917d390cfad.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/c214a797skyxfp0j4y7xpvzd9ymw03za-python3.10-mwoauth-0.3.8
ls -la /nix/store/c214a797skyxfp0j4y7xpvzd9ymw03za-python3.10-mwoauth-0.3.8/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

4 packages built:

python310Packages.mwoauth
python310Packages.oauthenticator
python39Packages.mwoauth
python39Packages.oauthenticator

Maintainer pings
cc @ixxie for testing.

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

4 packages built:

python310Packages.mwoauth
python310Packages.oauthenticator
python39Packages.mwoauth
python39Packages.oauthenticator

authors: fabaff r-ryantm


text:
python310Packages.torchmetrics: 0.8.2 -> 0.9.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.torchmetrics is: "Machine learning metrics for distributed, scalable PyTorch applications (used in pytorch-lightning)"
meta.homepage for python310Packages.torchmetrics is: "https://torchmetrics.readthedocs.io"
meta.changelog for python310Packages.torchmetrics is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 0.9.0 with grep in /nix/store/cx9pkmq02m46y71pphmr79i6ikd61mc6-python3.10-torchmetrics-0.9.0
found 0.9.0 in filename of file in /nix/store/cx9pkmq02m46y71pphmr79i6ikd61mc6-python3.10-torchmetrics-0.9.0

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

8 total rebuild path(s)

4 package rebuild(s)

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

First fifty rebuilds by attrpath
python310Packages.pytorch-lightning
python310Packages.torchmetrics
python39Packages.pytorch-lightning
python39Packages.torchmetrics

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.torchmetrics https://github.com/r-ryantm/nixpkgs/archive/834c7b70a5fd147f2b9fb237d58b5e3a66f3ea02.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/cx9pkmq02m46y71pphmr79i6ikd61mc6-python3.10-torchmetrics-0.9.0
ls -la /nix/store/cx9pkmq02m46y71pphmr79i6ikd61mc6-python3.10-torchmetrics-0.9.0/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

4 packages built:

python310Packages.pytorch-lightning
python310Packages.torchmetrics
python39Packages.pytorch-lightning
python39Packages.torchmetrics

Maintainer pings
cc @SomeoneSerge for testing.

tests/detection/test_map.py:21: in <module>
    from pycocotools import mask
E   ModuleNotFoundError: No module named 'pycocotools'

torchmetrics

I tried adding pycocotools to checkInputs but there are more errors:
_________________ ERROR collecting tests/detection/test_map.py _________________
tests/detection/test_map.py:31: in <module>
    with open(_SAMPLE_DETECTION_SEGMENTATION) as fp:
E   FileNotFoundError: [Errno 2] No such file or directory: '/build/source/_data/detection/instance_segmentation_inputs.json'

@SomeoneSerge Can you open your own PR for the update?

authors: SomeoneSerge dotlambda r-ryantm


text:
bcachefs: 2022-05 -> 2022-06

Description of changes
Currently, we can't patch due to printbuf changes.
Also, there is an error with modpost I don't understand happening even with these changes.
  CC      arch/x86/boot/compressed/kaslr.o
  CC      arch/x86/boot/compressed/ident_map_64.o
  CC      arch/x86/boot/compressed/idt_64.o
  AS      arch/x86/boot/compressed/idt_handlers_64.o
  AS      arch/x86/boot/compressed/mem_encrypt.o
  CC      arch/x86/boot/compressed/pgtable_64.o
  CC      arch/x86/boot/compressed/acpi.o
  AS      arch/x86/boot/compressed/efi_thunk_64.o
  CC      arch/x86/boot/compressed/misc.o
  ZSTD22  arch/x86/boot/compressed/vmlinux.bin.zst
ERROR: modpost: "stack_trace_save_tsk" [fs/bcachefs/bcachefs.ko] undefined!
make[1]: *** [../scripts/Makefile.modpost:134: modules-only.symvers] Error 1
make[1]: *** Deleting file 'modules-only.symvers'
make: *** [../Makefile:1749: modules] Error 2
make: *** Waiting for unfinished jobs....
  MKPIGGY arch/x86/boot/compressed/piggy.S
  AS      arch/x86/boot/compressed/piggy.o
  LD      arch/x86/boot/compressed/vmlinux
  OBJCOPY arch/x86/boot/vmlinux.bin
  ZOFFSET arch/x86/boot/zoffset.h
  AS      arch/x86/boot/header.o
  LD      arch/x86/boot/setup.elf
  OBJCOPY arch/x86/boot/setup.bin
  BUILD   arch/x86/boot/bzImage
Kernel: arch/x86/boot/bzImage is ready  (#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)
[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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Related: https://github.com/koverstreet/bcachefs/issues/429
May be best to compile as built-in for now.

Ready for review.

cc @davidak

We may want to wait on merging actually, I'm not sure if it's a problem with 5.18 in general or if it is because we aren't patching anymore, but I'm getting the kernel not being able to work around duplicate NSIDs for NVME drives.

Patching problem is with bio.c, no idea why I didn't see that before.
Not sure how to properly work around this, but working on it.

I'm out of my depth again. Can't figure anything out even with any derivation of:
{
  name = "bcachefs-${commit}";

  patch = fetchpatch {
    name = "bcachefs-${commit}.diff";
    url = "https://evilpiepirate.org/git/bcachefs.git/rawdiff/?id=${commit}&id2=v${lib.versions.majorMinor kernel.version}";
    sha256 = diffHash;

    postFetch = ''
      ${pkgs.buildPackages.patchutils}/bin/filterdiff -x 'a/block/bio.c' "$out" > "$tmpfile"
      mv "$tmpfile" "$out"
    '';
};

Looks like the duplicate NSID error is a problem with 5.18 in general.

At this point, we may want to consider getting rid of the linux bcachefs testing package and waiting for it to go into mainline.
AFAIK all the other bcachefs stuff (bcachefs-tools, tests, tasks) is fine, but it seems to be near-impossible to continue supporting this.

I managed to get your PR working when I changed it to the latest Kent has and compiled it as built in instead of a module. Not sure whether this is helpful but I would be glad if you would keep this PR open and we would keep up with the effort however futile it seems.
Thanks for doing this work on this PR!

Last time I tried it was an issue with patching. IIRC compiling it as built-in was required now anyway due to a bug.

This worked for me
{ lib
, pkgs
, fetchpatch
, kernel
, date ? "2022-07-03"
, commit ? "04962c7b97e783d4b705616a858af141cc6ba878"
, diffHash ? "sha256-zsieai/29Ry4LsJQuwMaxtdYdIJdEJCusg016ovUM2Q="
, kernelPatches # must always be defined in bcachefs' all-packages.nix entry because it's also a top-level attribute supplied by callPackage
, argsOverride ? {}
, ...
} @ args:

# NOTE: bcachefs-tools should be updated simultaneously to preserve compatibility
(kernel.override ( args // {
  argsOverride = {
    version = "${kernel.version}-bcachefs-unstable-${date}";

    extraMeta = {
      branch = "master";
      maintainers = with lib.maintainers; [ davidak Madouura ];
    };
  } // argsOverride;

  kernelPatches = [
    {
      name = "bcachefs-${commit}";

      patch = fetchpatch {
        name = "bcachefs-${commit}.diff";
        url = "https://evilpiepirate.org/git/bcachefs.git/rawdiff/?id=${commit}&id2=v${lib.versions.majorMinor kernel.version}";
        sha256 = diffHash;

        postFetch = ''
          ${pkgs.buildPackages.patchutils}/bin/filterdiff -x 'a/block/bio.c' "$out" > "$tmpfile"
          mv "$tmpfile" "$out"
        '';
      };

      extraConfig = "BCACHEFS_FS y";
    }

    {
      # Needed due to patching failure otherwise
      name = "linux-bcachefs-bio.c-fix";
      patch = ./linux-bcachefs-bio.c-fix.patch;
    }
  ] ++ kernelPatches;
}))

The only changes to your PR are the compiling in and a never commit from Kent's repo.

I'm unsure as to why the patching is working now, but it is.
I'll build, run the tests, and hopefully it'll be ready for review in an hour.

error: builder for '/nix/store/6qkiyxdrj4p2p76qsxlmrcx3v9qg8n6k-linux-5.18.13-bcachefs-unstable-2022-07-25.drv' failed with exit code 2;
       last 10 log lines:
       >   CC [M]  drivers/gpu/drm/nouveau/nouveau_led.o
       >   CC [M]  drivers/gpu/drm/nouveau/nvc0_fence.o
       >   CC [M]  drivers/gpu/drm/nouveau/nv84_fence.o
       >   CC [M]  drivers/gpu/drm/nouveau/nv50_fence.o
       >   CC [M]  drivers/gpu/drm/nouveau/nv17_fence.o
       >   CC [M]  drivers/gpu/drm/nouveau/nv10_fence.o
       >   LD [M]  drivers/gpu/drm/amd/amdgpu/amdgpu.o
       >   LD [M]  drivers/gpu/drm/nouveau/nouveau.o
       >   AR      drivers/gpu/built-in.a
       >   AR      drivers/built-in.a
       For full logs, run 'nix log /nix/store/6qkiyxdrj4p2p76qsxlmrcx3v9qg8n6k-linux-5.18.13-bcachefs-unstable-2022-07-25.drv'.

Last time this was a problem, it was solved by a kernel update. Not sure what to do in the meantime.

Turns out I was compiling a previous derivation, diffHash  didn't give me an error.
Let's see how it goes now.

Builds, tests succeed. Ready for review.
I did have to change from metadata replicas to replicas (metadata replicas and data replicas) due to the bcachefsMulti test failing every third restart. Seems to be a write error leading to a trans path overflow, but that's on kent's side.

I tested this PR on my machine and it builds and works nicely.

@ofborg eval

Looks like 5.19 fixed the weirdness.
Tests pass, had to temporarily remove "zfs" from nixos/modules/profile/base.nix to bypass ZFS not being updated to 5.19 yet.

@SuperSandro2000 Are we good for merge?

authors: Madouura cole-h jnsaff


text:
mprocs: 0.4.0 -> 0.6.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/pvolok/mprocs/releases.
meta.description for mprocs is: "A TUI tool to run multiple commands in parallel and show the output of each command separately"
meta.homepage for mprocs is: "https://github.com/pvolok/mprocs"
meta.changelog for mprocs 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
found 0.6.1 with grep in /nix/store/7vm4crb71q3gmxcg3gqa4g96qbr4qgyv-mprocs-0.6.1
found 0.6.1 in filename of file in /nix/store/7vm4crb71q3gmxcg3gqa4g96qbr4qgyv-mprocs-0.6.1

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
mprocs

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A mprocs https://github.com/r-ryantm/nixpkgs/archive/512807154e2878b0c307ccf7a9b2cd16b24b5976.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/7vm4crb71q3gmxcg3gqa4g96qbr4qgyv-mprocs-0.6.1
ls -la /nix/store/7vm4crb71q3gmxcg3gqa4g96qbr4qgyv-mprocs-0.6.1/bin

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

1 package built:

mprocs

Maintainer pings
cc @GaetanLepage @theHedgehog0 for testing.

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

1 package built:

mprocs

It seems to be fixed now: https://github.com/pvolok/mprocs/issues/49#issuecomment-1209093314.
I will try to test this soon.

Do we need to create another PR to go directly to 0.6.2 or can we change this one ?
Oh and... who is supposed to do it ? ^^

0.6.2 doesn't build for me on Darwin.

Same for me on linux: 0.6.2 doesn't build...

Link to upstream issue: https://github.com/pvolok/mprocs/issues/50

I close this PR because I opened a new one for updating to a more recent version:
https://github.com/NixOS/nixpkgs/pull/197040

authors: GaetanLepage r-ryantm smancill


text:
particl-core: 0.19.2.20 -> 0.19.2.22

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/particl/particl-core/releases.
meta.description for particl-core is: "Privacy-Focused Marketplace & Decentralized Application Platform"
meta.homepage for particl-core is: "https://particl.io/"
meta.changelog for particl-core 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
found 0.19.2.21 with grep in /nix/store/49i02h48c2s98ixwcb1fkmslg8a3a4rq-particl-core-0.19.2.21
found 0.19.2.21 in filename of file in /nix/store/49i02h48c2s98ixwcb1fkmslg8a3a4rq-particl-core-0.19.2.21

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
particl-core

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/49i02h48c2s98ixwcb1fkmslg8a3a4rq-particl-core-0.19.2.21 \
  --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 particl-core https://github.com/r-ryantm/nixpkgs/archive/f83c4c7c52d98282863027e9fa97b647736484d2.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/49i02h48c2s98ixwcb1fkmslg8a3a4rq-particl-core-0.19.2.21
ls -la /nix/store/49i02h48c2s98ixwcb1fkmslg8a3a4rq-particl-core-0.19.2.21/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:

particl-core

Maintainer pings
cc @demyanrogozhin for testing.

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

1 package marked as broken and skipped:

particl-core

It's not actually broken on darwin
Result of `nixpkgs-review pr 186000` run on x86_64-darwin [1](https://github.com/Mic92/nixpkgs-review)

  1 package built:

particl-core

It works fine too. I'll make another PR to unbreak it.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/particl/particl-core/releases.
meta.description for particl-core is: "Privacy-Focused Marketplace & Decentralized Application Platform"
meta.homepage for particl-core is: "https://particl.io/"
meta.changelog for particl-core 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
found 0.19.2.22 with grep in /nix/store/zping038c86ynn93kvngvdh4wvgxbn45-particl-core-0.19.2.22
found 0.19.2.22 in filename of file in /nix/store/zping038c86ynn93kvngvdh4wvgxbn45-particl-core-0.19.2.22

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
particl-core

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/zping038c86ynn93kvngvdh4wvgxbn45-particl-core-0.19.2.22 \
  --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 particl-core https://github.com/r-ryantm/nixpkgs/archive/a7b7f011e5309fbdf4708afcb72585e2cbabe141.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/zping038c86ynn93kvngvdh4wvgxbn45-particl-core-0.19.2.22
ls -la /nix/store/zping038c86ynn93kvngvdh4wvgxbn45-particl-core-0.19.2.22/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:

particl-core

Maintainer pings
cc @demyanrogozhin for testing.

@ofborg build particl-core

authors: onny r-ryantm viraptor


text:
bazel_6: init with a WIP implem

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.

/cc @avdv @ylecornec @the-mikedavis @uri-canva Starting here the work to get bazel_6 packaged.
This does not work yet, I have lots of trouble with "ijar" internal tool that refuses to run. Any idea ?

@r2r-dev is this of any interest for you ATM ? I would love to do some peer programming

It works for me on x86_64-darwin with this change:
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 9431ba72bb0..1fe320bbb95 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -15459,12 +15459,14 @@ with pkgs;
     bazel_self = bazel_5;
   };

-  bazel_6 = callPackage ../development/tools/build-managers/bazel/bazel_6 {
+  bazel_6 = darwin.apple_sdk_11_0.callPackage ../development/tools/build-managers/bazel/bazel_6 {
     inherit (darwin) cctools;
-    inherit (darwin.apple_sdk.frameworks) CoreFoundation CoreServices Foundation;
+    inherit (darwin.apple_sdk_11_0.frameworks) CoreFoundation CoreServices Foundation;
     buildJdk = jdk11_headless;
     runJdk = jdk11_headless;
-    stdenv = if stdenv.cc.isClang then llvmPackages.stdenv else stdenv;
+    stdenv = if stdenv.isDarwin then
+      darwin.apple_sdk_11_0.stdenv else
+      if stdenv.cc.isClang then llvmPackages.stdenv else stdenv;
     bazel_self = bazel_6;
   };

Thanks a lot @uri-canva. To be honnest I am puzzle as to why your patch works at all. I have pushed a fix that makes sense (to me) for my linux build. Would you mind trying it without your patch ? And if it fails, see if your patch still works ? That would help me a lot.
Thanks !

I still need my patch to build at all, but even with the patch I'm now hitting issues like this:
bazel-out/darwin-fastbuild/bin/external/com_google_protobuf/_javac/duration_proto/libduration_proto-speed_tmp/com/google/protobuf/Duration.java:58: error: [strict] Using type com.google.protobuf.GeneratedMessageV3 from an indirect dependency (TOOL_INFO: "@com_google_protobuf//java/core"). See command below **
    com.google.protobuf.GeneratedMessageV3 implements
                       ^
bazel-out/darwin-fastbuild/bin/external/com_google_protobuf/_javac/duration_proto/libduration_proto-speed_tmp/com/google/protobuf/Duration.java:82: error: [strict] Using type com.google.protobuf.CodedInputStream from an indirect dependency (TOOL_INFO: "@com_google_protobuf//java/core:lite_runtime_only"). See command below **
      com.google.protobuf.CodedInputStream input,
                         ^
 ** Please add the following dependencies:
  @com_google_protobuf//java/core @com_google_protobuf//java/core:lite_runtime_only to @com_google_protobuf//:duration_proto
 ** You can use the following buildozer command:
buildozer 'add deps @com_google_protobuf//java/core @com_google_protobuf//java/core:lite_runtime_only' @com_google_protobuf//:duration_proto

I tried to add build --experimental_strict_java_deps=off to the .bazelrc but it wasn't enough, I probably need to add it to compile.sh too.

Sorry was going to explain the changes then I realised they're quite big and very darwin specific so I figured I would just push them, let me know if you have any questions.

If you're happy with the changes mark the PR as ready to review. They look good to me.

ping @layus

@layus I'll go ahead and push this PR forward since I'm interested in having it merged, hope you don't mind. If you have changes you'd like to make we can fix them up in a follow up PR.

@olebedev @groodt @mboes can you help me out and review this PR? Since I wrote a lot of it I think I need another set of eyes.

@ErinvanderVeen thanks for helping with testing the PR! Did you also review the changes? Not sure why your checkmark is grey, is it because you're not in the bazel maintainers group?

@uri-canva Thanks for pushing this forward. I have no particular expectations on this PR. I already deployed the working linux version where I needed it. This is my way to share upstream.
What bugs me is that you had to patch Bazel around the "error: [strict] Using type [...] from an indirect dependency" java issue. On my side I discovered that commit https://github.com/NixOS/nixpkgs/commit/1f11d01f8a3a055b05779e8d5cc03d06821f4797 somehow fixed the bug. I wonder what part of these changes did it. Would you mind opening an issue upstream for these new patches ?
Another annoying part is that stdenv entries become darwin ones. Reading the code, it took me quite some time to understand that these darwin things are just stdenv on linux. I guess it's a nixpkgs-wide issue, but that delayed my feedback quite a lot (until I found some darwin users to discuss with).
But none of that should be a blocker for merging an unstable bazel_6 package. I have asked colleagues for a review. I will merge this once we get a proper review.

@uri-canva The reason why Erin's review is grey is because he does not have commit access. It's green otherwise. I do not like this feature as it seems to imply a difference in the review itself, when it only really about permissions. I see the use case for a green review when that reviewer could potentially merge the pr, but still...

Yeah the darwin stdenv is quite confusing, hopefully we can remove it soon. You're right, the java error is due to something in the jdk, you can see some discussion in https://github.com/bazelbuild/bazel/issues/16109. It's already fixed upstream, but the fix hasn't made it through all the different ways you can configure the jdk.

Ignore me, was using it wrong.

Got some more information upstream, I think the strict deps thing is due to our java setup: https://github.com/bazelbuild/bazel/pull/16146. I haven't been able to narrow it down any further than that, I'm ok with merging this as is and continuing looking into it later.

@uri-canva I made one cleanup commit. Let's wait CI and merge it.

@uri-canva For some reason, GH still thinks that you requested changes...

@uri-canva  x86_64-darwin tests failed. Is it something you care about ? Anything we can do to fix it ?
https://github.com/NixOS/nixpkgs/pull/186106/checks?check_run_id=8155054931
https://logs.nix.ci/?key=nixos/nixpkgs.186106&attempt_id=599b3837-eea4-4f02-886d-8a340e88539c

That's very strange, let me try to build it locally.

Oh you only did a cleanup commit after the last one, I don't think that would have caused the issue, it might be some ofborg specific issue. Since it's a new derivation, let's try to merge it as is and see if it builds on hydra.

Whoops I just realised we should have updated the name of the PR.

Done :tada: . Thanks a lot for your efforts !

Darwin built on hydra, so the failure was an ofborg specific issue: https://hydra.nixos.org/eval/1779113?filter=bazel_6&compare=1779052&full=#tabs-aborted
However linux seems to have failed, though I don't understand the failure. Is it because of sandboxing?

Seems like a transient network failure to me. Let's wait next eval ?
Le 5 septembre 2022 01:30:02 GMT+02:00, Uri Baghin @.***> a écrit :

Darwin built on hydra, so the failure was an ofborg specific issue: https://hydra.nixos.org/eval/1779113?filter=bazel_6&compare=1779052&full=#tabs-aborted
However linux seems to have failed, though I don't understand the failure. Is it because of sandboxing?
--
Reply to this email directly or view it on GitHub:
https://github.com/NixOS/nixpkgs/pull/186106#issuecomment-1236435917
You are receiving this because you were mentioned.
Message ID: @.***>

Nice, we got a green build: https://hydra.nixos.org/build/190329458.

authors: layus uri-canva


text:
python310Packages.psd-tools: 1.9.21 -> 1.9.22

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.psd-tools is: "Python package for reading Adobe Photoshop PSD files"
meta.homepage for python310Packages.psd-tools is: "https://github.com/kmike/psd-tools"
meta.changelog for python310Packages.psd-tools is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.9.22 with grep in /nix/store/bxijvbvx0yzadc9652g8dgffcp3f1sja-python3.10-psd-tools-1.9.22
found 1.9.22 in filename of file in /nix/store/bxijvbvx0yzadc9652g8dgffcp3f1sja-python3.10-psd-tools-1.9.22

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
python310Packages.psd-tools
python39Packages.psd-tools

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.psd-tools https://github.com/r-ryantm/nixpkgs/archive/aa52cc940eed21f2ba10335eccf13bbc05fbd101.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/bxijvbvx0yzadc9652g8dgffcp3f1sja-python3.10-psd-tools-1.9.22
ls -la /nix/store/bxijvbvx0yzadc9652g8dgffcp3f1sja-python3.10-psd-tools-1.9.22/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

2 packages failed to build:

python310Packages.psd-tools
python39Packages.psd-tools

Maintainer pings
cc @onny for testing.

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

2 packages built:

python310Packages.psd-tools
python39Packages.psd-tools

authors: onny r-ryantm


text:
gallia: init at 1.0.3

Description of changes
Pentesting framework with the focus on the automotive domain
https://github.com/Fraunhofer-AISEC/gallia
Related to https://github.com/NixOS/nixpkgs/issues/81418

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

3 packages built:

gallia
python310Packages.msgspec
python39Packages.msgspec

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

3 packages failed to build:

gallia
python310Packages.msgspec
python39Packages.msgspec

authors: fabaff sikmir


text:
Fix snmp exporter

Motivation for this change
Deploying with nixops to virtualbox caused error: attribute ‘snmpExporter’ missing, at /Users/hschaeidt/.nix-defexpr/channels/nixpkgs/nixos/modules/services/monitoring/prometheus/snmp-exporter.nix:6:9 even when not using prometheus.
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.

wrong merge target...


text:
libxml2: enable strictDeps and enable pythonSupport when cross

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.

Will this still work with v2.10.2, the Python detection is a bit in flux.

Will this still work with v2.10.2? The Python detection is a bit in flux.

no python changes in configure.ac so it should still work
diff --git a/configure.ac b/configure.ac
index 3b273654..9dedb3af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,7 +3,7 @@ AC_PREREQ([2.63])

 m4_define([MAJOR_VERSION], 2)
 m4_define([MINOR_VERSION], 10)
-m4_define([MICRO_VERSION], 0)
+m4_define([MICRO_VERSION], 2)

 AC_INIT([libxml2],[MAJOR_VERSION.MINOR_VERSION.MICRO_VERSION])
 AC_CONFIG_SRCDIR([entities.c])
@@ -39,7 +39,7 @@ AC_SUBST(LIBXML_VERSION_EXTRA)

 VERSION=${LIBXML_VERSION}

-AM_INIT_AUTOMAKE([1.15 foreign no-dist-gzip dist-xz])
+AM_INIT_AUTOMAKE([1.16.3 foreign no-dist-gzip dist-xz])
 AM_MAINTAINER_MODE([enable])
 AM_SILENT_RULES([yes])

Maybe I misremembered and it was actually libxslt that had the Python issues.

Maybe I misremembered and it was actually libxslt that had the Python issues.

Nope
https://github.com/NixOS/nixpkgs/commit/1c93ab362bc9c2a9275d7d2dd0a6268be86e495a

🤷♀ I guess it is fine then.
Compared py and out outputs of libxml2 and libxslt on non-cross before
and after with diffoscope and looks like it is a no-op.
On Fri, Oct 7 2022 at 15:04:07 -07:00:00, Artturi
@.***> wrote:

Maybe I misremembered and it was actually libxslt that had the
Python issues.

Nope
1c93ab3
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because your review was requested.Message ID:
@.***>

authors: Artturin jtojnar


text:
tqsl: migrate to wxGTK32

Description of changes
As in the title.
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

authors: nixos-discourse wegank


text:
grsecurity: option to disable/loosen reverse path filtering

Motivation for this change
cjdns requires it disabled to work
Things done

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

[x] NixOS
[ ] macOS
[x] Linux

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

cjdns requires it for one thing.

hmm, I'll change it to allow loose filtering too.

Don't worry, I'mma squash.

Note that we're already doing reverse path filtering by default using the rpfilter iptables module if the firewall is enabled.
It's a bit weird weird to have the definition of networking.forceReversePathFiltering on the grsecurity module. Does grsecurity enable the rp_filter sysctl by default?
Furthermore, having two options in NixOS is very confusing. I would suggest to always disable the rp_filter by default (mkDefault) as it just filters IPv4 traffic. The netfilter module has much more configurations options and features due to the fact that it is an iptables module.
@joachifm What's your opinion on this?

Ah, grsecurity does indeed enable it by default as well.
Is the iptables rpfilter configurable from nixos?

Yup, there is networking.firewall.checkReversePath and networking.firewall.logReversePathDrops.
Was the firewall disabled for your tests with cjdns?

ah damn, I somehow missed them. I guess because I was looking at the sysctls, I didn't think to look at iptables :)
Since this is implemented in two places, the firewall settings should set the sysctl setting too, I think. Do you concur? If so, I'll close the PR and start a new one.

Was the firewall disabled for your tests with cjdns?

No, it wasn't. I'm not entirely sure that the cjdns problem was due to reverse path filtering now; I made a bunch of changes to various things and it's working :) But I didn't change the firewall RP filter.

Looks to me like this is unrelated to grsecurity.

Not unrelated, because grsecurity changes the default for the sysctl rp_filter setting.

authors: fpletz joachifm spacekitteh


text:
mitmproxy2swagger: 0.7.0 -> 0.7.1

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.

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

1 package built:

mitmproxy2swagger


text:
python310Packages.teslajsonpy: 3.2.2 -> 3.3.0

Changelog: https://github.com/zabuldon/teslajsonpy/releases/tag/v3.3.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/)
23.05 Release Notes (or backporting 22.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.

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

2 packages built:

python310Packages.teslajsonpy
python39Packages.teslajsonpy


text:
signalbackup-tools: 20221130 -> 20221206-1

Description of changes
Update to latest version. No changes that effect build: https://github.com/bepaald/signalbackup-tools/compare/20221130...20221206-1
Things done

Built on platform(s)

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

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

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

1 package built:

signalbackup-tools

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

1 package built:

signalbackup-tools

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

1 package built:

signalbackup-tools


text:
python310Packages.cython: run tests

@FRidh Any idea how to fix this error?
distutils.errors.DistutilsSetupError: each element of 'ext_modules' option must be an Extension instance or 2-tuple

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/)
23.05 Release Notes (or backporting 22.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.

Confusing.
Adding debugging statements:
   checkPhase = ''
+    sed -i '1120i\            import inspect' runtests.py
+    sed -i '1121i\            print(type(build_extension).__mro__)' runtests.py
+    sed -i '1122i\            print(isinstance(build_extension.extensions[0], inspect.getmodule(type(build_extension).__mro__[1]).Extension))' runtests.py
+    sed -i '1122i\            print(inspect.getmodule(type(build_extension).__mro__[1]).Extension)' runtests.py
+    sed -i '1123i\            print(build_extension.extensions)' runtests.py
     export HOME="$NIX_BUILD_TOP"

results in e.g.
(<class '__main__.build_ext'>, <class 'distutils.command.build_ext.build_ext'>, <class 'distutils.cmd.Command'>, <class 'object'>)
<class 'setuptools.extension.Extension'>
[<setuptools.extension.Extension('a_capi') at 0x7fde1b5f90>]
True

Suggesting:

The extension passed in build_extension.extensions is a setuptools.extension.Extension
The Extension that build_ext.check_extensions_list() is type-comparing it with is also setuptools.extension.Extension
If we do the "same" isinstance check outside distutils it seems to pass ok.

authors: dotlambda risicle


text:
wordpress: 6.1.1 -> 6.2; wordpress6_2: init

Description of changes
Fixes: https://github.com/NixOS/nixpkgs/issues/224667
Supersedes: https://github.com/NixOS/nixpkgs/pull/227848
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/)
23.05 Release Notes (or backporting 22.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

[x] Fits CONTRIBUTING.md.

Also #227848.

Probably shouldn't wait any longer on account of CVEs.

authors: onny wegank


text:
nixos/tests/nfs/simple: remove shutdown time check for now

Regressed in latest kernels, but seems less critical than the channels being stuck for a week.
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)
[x] Tested, as applicable:

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

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

[x] Fits CONTRIBUTING.md.

/cc @edolstra from nixosTests.nfs3.simple.meta.maintainers, though I don't expect this maintainership "really holds in practice" (anymore).


text:
gnome-flashback: fix screenshot key and screen not locking when idle

These auto-started services are failing to start in the gnome-flashback desktop manager service, leaving warnings in the log:
gnome-flashback-clipboard
gnome-flashback-idle-monitor
gnome-flashback-media-keys
Fix the failures by removing the line from postInstall in the gnome-flashback package which is deleting the executables for those services, which the build creates in $out/libexec.
gnome-flashback-idle-monitor is responsible for sending a dbus message when the system is idle, so without it the screen never dims or locks.  When gnome-flashback-media-keys is not running, using the PrtScr key to grab screenshots does not work.
gnome-flashback-clipboard from my cursory inspection of its source deals with streaming large clipboard transfers and translating clipboard formats.  I have had copy and paste fail to work on my system before this fix, and haven't seen the problem since, but I don't have a reproducible case.
There's one more warning in the log about gnome-flashback-nm-applet failing to start, but the executable for that one is not present in $out/libexec so it seems to be a separate issue.
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)
[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

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

[x] Fits CONTRIBUTING.md.

LGTM :upside_down_face:
I applied this PR to dd3626c0365eab4280a076a638ce45c9ee1c9e99 and things became very reasonable to me, at that time there are only two bash scripts in libexec named gnome-flashback-{compiz,metacity} and both calls gnome-session. Since #53695 wants to support custom sessions, things are re-implemented in writeShellScriptBin and nothing in libexec are useful anymore.
I believe in this case there are no reasons to drop gnome-flashback-{clipboard,idle-monitor,media-keys}. I am using this PR and I can (at least) confirm the screenshot key issue is fixed. The only things is that we are re-adding libexec/gnome-flashback-metacity, with a quick look I don't aware of anything at will try exec that so we should be safe.

There's one more warning in the log about gnome-flashback-nm-applet failing to start

Looks like it looks for nm-applet (in networkmanagerapplet), but sounds like some people don't like adding that to desktop modules :confused:
@ofborg test gnome-flashback
(I plan to merge this in a day if nobody wants to review)

I would probably still remove gnome-flashback-{compiz,metacity} since having it and not being used can be confusing (e.g. people can try patching it to no effect).

Hi @gazally, I force-pushed your branch to apply the suggestions above :bow:
(gnome-flashback-compiz is gone these days)

authors: bobby285271 gazally jtojnar