!UNVBThoJtlIiVwiDjU:nixos.org

Staging

397 Members
Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.11 | Review Reports: https://malob.github.io/nix-review-tools-reports/128 Servers

Load older messages

SenderMessageTime
28 Jun 2026
@pixelhamster:matrix.orgPixelHamsterIs the best way to check the staging->staging-next merges via the git log or is there a website that lists them?13:50:14
@k900:0upti.meK900No website13:54:23
@hexa:lossy.networkhexawdym check?13:54:26
@k900:0upti.meK900But you can see the commit list on the staging-next PR on github13:54:29
@hexa:lossy.networkhexabarely13:54:36
@hexa:lossy.networkhexa everything >250 commits is wishful thinking 13:54:54
@sempiternal-aurora:matrix.orgMyriaSomething like https://github.com/NixOS/nixpkgs/compare/master...staging-next could work, though you have to scroll down through all the staging commits to get to the new staging-next ones13:58:38
@k900:0upti.meK900https://github.com/pandas-dev/pandas/releases/tag/v3.0.414:07:48
@k900:0upti.meK900Tag achieved14:07:49
@sempiternal-aurora:matrix.orgMyriaWoohoo14:08:51
@sempiternal-aurora:matrix.orgMyriaNew version build correctly locally on my machine, can't test the google-cloud-monitoring because glib isn't building on darwin right now14:15:46
@k900:0upti.meK900I'm building my flake against that now14:16:11
@k900:0upti.meK900So far so no fire14:16:17
@tom:pub.solartomI built google-cloud-monitoring with pandas@main earlier today, no more segfaults during tests14:18:53
@tom:pub.solartomalthough that wasn't the patch that fixed it (also ran a build with that patch applied)14:21:26
@sempiternal-aurora:matrix.orgMyriaA lot of these might just be a result of https://hydra.nixos.org/build/333251704 and should hopefully just work with a retry?14:24:31
@sempiternal-aurora:matrix.orgMyria*33325170114:24:55
@sempiternal-aurora:matrix.orgMyriaCopying numbers isn't the best idea, oops14:25:08
@k900:0upti.meK900We'll hit restart all failed at some point probably14:26:30
@9hp71n:matrix.orgghpzin There seems to be some funny thing with systemd 261 and systemd-boot-builder.py:
https://github.com/NixOS/nixpkgs/blob/08bbeb4f13347cb830f1ad61628165c5b93c77a8/nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py#L491-L505
with 261 introducing fallbacks in:
https://github.com/systemd/systemd/commit/918c592272fb4e93b99997362a8c9ecc31e77036
there are now 2 entries and fallback is always above (at least on my machine), so regex pick it:
Available Boot Loaders on ESP:
          ESP: /boot (/dev/disk/by-partuuid/b6f5a9f2-8aa9-430e-8ca6-dfdc61aecdc0)
         File: ├─/boot//EFI/systemd/systemd-boot-fallbackx64.efi (systemd-boot 260.1)
               ├─/boot//EFI/systemd/systemd-bootx64.efi (systemd-boot 261)
               └─/boot//EFI/BOOT/BOOTX64.EFI (systemd-boot 261)
and every nixos-rebuild switch attempt fails with:
updating systemd-boot from 260.1 to 261
Skipping "/boot/EFI/systemd/systemd-bootx64.efi", same boot loader version in place already.
Skipping "/boot/EFI/BOOT/BOOTX64.EFI", same boot loader version in place already.
Traceback (most recent call last):
  File "/nix/store/0v7rngj7lhw6fnbpvimaxcwrmd2sly4h-systemd-boot/bin/systemd-boot", line 682, in <module>
    main()
    ~~~~^^
  File "/nix/store/0v7rngj7lhw6fnbpvimaxcwrmd2sly4h-systemd-boot/bin/systemd-boot", line 660, in main
    install_bootloader(args)
    ~~~~~~~~~~~~~~~~~~^^^^^^
  File "/nix/store/0v7rngj7lhw6fnbpvimaxcwrmd2sly4h-systemd-boot/bin/systemd-boot", line 526, in install_bootloader
    run(
    ~~~^
        [f"{SYSTEMD}/bin/bootctl", f"--esp-path={EFI_SYS_MOUNT_POINT}"]
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        + bootctl_flags
        ^^^^^^^^^^^^^^^
        + ["update"]
        ^^^^^^^^^^^^
    )
    ^
  File "/nix/store/0v7rngj7lhw6fnbpvimaxcwrmd2sly4h-systemd-boot/bin/systemd-boot", line 243, in run
    return subprocess.run(cmd, check=True, text=True, stdout=stdout, stderr=sys.stderr)
           ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/jxyrvv4gbpnp3ap5iy7wxwl1sg4x2x88-python3-3.14.6/lib/python3.14/subprocess.py", line 578, in run
    raise CalledProcessError(retcode, process.args,
                             output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/nix/store/k0k82yla4xvxzx3hbc9gaqbfm67hmqfk-systemd-261/bin/bootctl', '--esp-path=/boot', 'update']' returned non-zero exit status 1.
Failed to install bootloader
15:19:04
@9hp71n:matrix.orgghpzin There seems to be some funny thing with systemd 261 and systemd-boot-builder.py:
https://github.com/NixOS/nixpkgs/blob/08bbeb4f13347cb830f1ad61628165c5b93c77a8/nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py#L491-L505
with 261 introducing fallbacks in:
https://github.com/systemd/systemd/commit/918c592272fb4e93b99997362a8c9ecc31e77036
there are now 2 entries and fallback is always above (at least on my machine), so regex pick it:
Available Boot Loaders on ESP:
          ESP: /boot (/dev/disk/by-partuuid/b6f5a9f2-8aa9-430e-8ca6-dfdc61aecdc0)
         File: ├─/boot//EFI/systemd/systemd-boot-fallbackx64.efi (systemd-boot 260.1)
               ├─/boot//EFI/systemd/systemd-bootx64.efi (systemd-boot 261)
               └─/boot//EFI/BOOT/BOOTX64.EFI (systemd-boot 261)
and every nixos-rebuild attempt without --install-bootloader fails with:
updating systemd-boot from 260.1 to 261
Skipping "/boot/EFI/systemd/systemd-bootx64.efi", same boot loader version in place already.
Skipping "/boot/EFI/BOOT/BOOTX64.EFI", same boot loader version in place already.
Traceback (most recent call last):
  File "/nix/store/0v7rngj7lhw6fnbpvimaxcwrmd2sly4h-systemd-boot/bin/systemd-boot", line 682, in <module>
    main()
    ~~~~^^
  File "/nix/store/0v7rngj7lhw6fnbpvimaxcwrmd2sly4h-systemd-boot/bin/systemd-boot", line 660, in main
    install_bootloader(args)
    ~~~~~~~~~~~~~~~~~~^^^^^^
  File "/nix/store/0v7rngj7lhw6fnbpvimaxcwrmd2sly4h-systemd-boot/bin/systemd-boot", line 526, in install_bootloader
    run(
    ~~~^
        [f"{SYSTEMD}/bin/bootctl", f"--esp-path={EFI_SYS_MOUNT_POINT}"]
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        + bootctl_flags
        ^^^^^^^^^^^^^^^
        + ["update"]
        ^^^^^^^^^^^^
    )
    ^
  File "/nix/store/0v7rngj7lhw6fnbpvimaxcwrmd2sly4h-systemd-boot/bin/systemd-boot", line 243, in run
    return subprocess.run(cmd, check=True, text=True, stdout=stdout, stderr=sys.stderr)
           ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/jxyrvv4gbpnp3ap5iy7wxwl1sg4x2x88-python3-3.14.6/lib/python3.14/subprocess.py", line 578, in run
    raise CalledProcessError(retcode, process.args,
                             output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/nix/store/k0k82yla4xvxzx3hbc9gaqbfm67hmqfk-systemd-261/bin/bootctl', '--esp-path=/boot', 'update']' returned non-zero exit status 1.
Failed to install bootloader
15:25:38
@k900:0upti.meK900That's not what's happening here15:25:57
@k900:0upti.meK900 It's bootctl update that fails 15:26:03
@k900:0upti.meK900Which is very sus15:26:05
@9hp71n:matrix.orgghpzin Iirc that is a very old thing.
Skips exit with status code 1, unless you add --graceful 		15:29:25
@k900:0upti.meK900 hexa do you know why our python3Packages.plexapi is ancient 15:36:17
@hexa:lossy.networkhexawill look in a bit, fixing opentelemetry mess first15:36:43
@k900:0upti.meK900Oh wait15:40:17
@k900:0upti.meK900It's specifically ancient plexapi pinned in HA15:40:22
@hexa:lossy.networkhexathen I know why15:43:11

Show newer messages

Back to Room ListRoom Version: 6