!UNVBThoJtlIiVwiDjU:nixos.org

Staging

391 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/125 Servers

Load older messages

SenderMessageTime
28 Jun 2026
@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
@hexa:lossy.networkhexalmao15:43:13
@k900:0upti.meK900 I'm guessing the why is "HA lol" 15:43:21
@elvishjerricco:matrix.orgElvishJerricco

There was a previous update where bootctl update was changed to iterate over all files in $ESP/EFI/BOOT/ to see if they're systemd-boot binaries that needed updating. But it had, earlier in the code, already directly decided to update the main BOOTX64.EFI loader in there. So it got to that file, saw it was a systemd-boot binary, and tried to update it. But when bootctl update sees that a binary it tried to update is already up to date, it exits non-zero. So it was just unconditionally exiting non-zero because, even when it did update the file, it would try to update it a second time in the same invocation and obviously that's already up to date.

Anyway, this is an old bug that was fixed a long time ago, and is not necessarily related at all. I'm mentioning it because I would be very unsurprised if there was another goof a lot like that, where bootctl-install.c is just bugging out because of spaghetti logic

15:43:27
@k900:0upti.meK900And it doesn't build because it wants pkg_resources15:43:37
@hexa:lossy.networkhexasetuptools_8015:43:44

Show newer messages

Back to Room ListRoom Version: 6