| 28 Jun 2026 |
 K900 | That's not what's happening here | 15:25:57 |
| K900 | It's bootctl update that fails | 15:26:03 |
| K900 | Which is very sus | 15:26:05 |
 ghpzin | Iirc that is a very old thing.
Skips exit with status code 1, unless you add --graceful | 15:29:25 |
| K900 | hexa do you know why our python3Packages.plexapi is ancient | 15:36:17 |
 hexa | will look in a bit, fixing opentelemetry mess first | 15:36:43 |
| K900 | Oh wait | 15:40:17 |
| K900 | It's specifically ancient plexapi pinned in HA | 15:40:22 |
| hexa | then I know why | 15:43:11 |
| hexa | lmao | 15:43:13 |
| K900 | I'm guessing the why is "HA lol" | 15:43:21 |
 ElvishJerricco | 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 | And it doesn't build because it wants pkg_resources | 15:43:37 |
| hexa | setuptools_80 | 15:43:44 |
| hexa | but not suitable for propagation | 15:44:01 |
| K900 | It wants it at setup.py time | 15:44:10 |
| hexa | good | 15:44:14 |
| K900 | So HOPEFULLY I can just chuck it into nativeBuildInputs | 15:44:17 |
| ElvishJerricco | (unfortunately I don't think I can look into it today) | 15:44:30 |
| ghpzin | Yes, that is what I remember it from:
https://github.com/NixOS/nixpkgs/issues/331170
https://github.com/systemd/systemd/issues/33392
In this case because of regex version check after first update all other invocation actually don't update anything (both non-fallback files are up to date).
So I think from systemd side it is correct ? | 15:49:30 |
 Randy Eckenrode | I reverted it locally and can confirm glib built again. | 15:50:50 |
| ghpzin | Yes, that is what I remember it from:
https://github.com/NixOS/nixpkgs/issues/331170
https://github.com/systemd/systemd/issues/33392
In this case because of regex version check after first update all other invocation actually don't update anything (both non-fallback files are up to date).
So I think from systemd side it is correct (update exits with 1 if it updated nothing) ? | 15:51:14 |
| ghpzin | Yes, that is what I remember it from:
https://github.com/NixOS/nixpkgs/issues/331170
https://github.com/systemd/systemd/issues/33392
In this case because of regex version check after first update all other invocation actually don't update anything (both non-fallback files are up to date).
So I think from systemd side it is correct (update exits with 1 if it updated nothing). | 15:52:43 |
| ElvishJerricco | ah, I see, I misunderstood your previous message a bit. If the issue is just that the regex picks the wrong file, that's probably our issue. Really wish there was just a bootctl check command to check if an update was needed | 15:57:06 |
| ElvishJerricco | actually | 15:57:07 |
| ElvishJerricco | can we just patch that in and submit it upstream? | 15:57:21 |
| ElvishJerricco | that seems way better, assuming they'll take it upstream | 15:57:29 |
| ElvishJerricco | which it seems like something reasonable for them to have | 15:57:39 |
 emily | Randy Eckenrode: put up https://github.com/NixOS/nixpkgs/pull/536363 | 16:45:08 |
| emily | and https://github.com/NixOS/nixpkgs/pull/536365 | 16:54:09 |
