| 7 May 2026 |
 ElvishJerricco | I know GDM wants to use userdb so it can have N GDM users instead of 1 GDM user, but have no idea how that works. Would not be surprised if either it 1) doesn't need systemd-userdbd specifically at all and has its own userdb-JSON-record-serving-daemon (userdb is just a directory of sockets and can be backed by arbitrarily many such services), or 2) creates JSON record files that it expects systemd-userdbd specifically to handle. | 14:26:33 |
| ElvishJerricco | in either case I'm not sure why there would be PAM issues, since AFAIK PAM should just be happy using NSS stuff. Maybe something is starting before nscd.service, and historically fell back on /etc/passwd if that wasn't up? | 14:28:18 |
| ElvishJerricco | (hey look, potentially another reason that nscd makes me want to build volcanoes instead of computers) | 14:29:27 |
 emily | https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/ explains the userdbd dependency | 14:46:47 |
| emily | it needs io.systemd.Multiplexer, getpwent workign for userdbd users, and the userdb API working for /etc/passwd users | 14:47:35 |
 winston | worst case we could revert https://gitlab.gnome.org/GNOME/gdm/-/commit/c3747f1c14b777e1a42b9e5d903214c39e2c0462 to get hardcoded users to work again, at least for 50, but I'd like to avoid kicking the can further down the road if possible | 14:51:15 |
 Ihar Hrachyshka | (alert: I don't have particular interest in gnome the DE.)
Going forward, it would be nice if we could separate bumps for stuff like glib that has nothing to do with gnome fate, I was building my own glib / qemu for the last months because I needed a fix for Darwin. So I'm kinda glad this merged, though of course not happy about what it may mean for gnome. | 17:59:13 |
 hexa | I have Python 3.14.5 | 18:01:20 |
| hexa | shouldn't throw a wrench in the stdenvs at least | 18:02:03 |
| hexa | hm, nvm its still rc1 | 18:06:14 |
| hexa | for some reason (thanks github) the release is late | 18:06:23 |
| hexa | https://chaos.social/@hugovk@mastodon.social/116528979328303745 | 18:06:39 |
 Emil Thorsøe | in gerrit, you download pr metadata with git, at leasti it has that going for it | 18:36:59 |
| Emil Thorsøe | * in gerrit, you download pr metadata with git, at least it has that going for it | 18:37:10 |
| 8 May 2026 |
|  anadon_ joined the room. | 04:54:27 |
| anadon_ | Is there some place I can peer in on what is going on with staging-next without bothering people? I made an admittedly terribad PR to update libbpf to v1.7.0 because I need that update for a project I'm making, and I'd like keep track of movement on it and when things land. Reading the linked documentation on Nix branches linked to me, I didn't see a way to do this. | 05:01:38 |
 K900 | There is no staging-next currently | 06:21:21 |
| K900 | There should be one in the coming days | 06:21:25 |
 vcunat | I didn't post a PR+comment, but Hydra is already working on staging-next. | 06:23:25 |
| vcunat | (for 12h now) | 06:23:58 |
| vcunat | This is the last staging* to reach 26.05, I suppose? | 06:25:46 |
| vcunat | * This must be the last staging* to reach 26.05. | 06:26:04 |
| vcunat | Opened as https://github.com/NixOS/nixpkgs/pull/517946 | 06:28:06 |
 leona | (the release TL says something about a second cycle, but IMO that's not going to happen if there aren't some major problems. we also didn't do that second cycle the last two releases) | 06:29:44 |
| vcunat | I think even the timing of the current staging-next... won't be comfortable. | 06:30:46 |
| vcunat | Branch-off is planned in 10 days from now (!) | 06:31:44 |
| vcunat | Normal staging-next takes about 14 days. | 06:32:01 |
| vcunat | (OK, counted from yesterday, I guess, as Hydra has been working on it already.) | 06:32:34 |
| vcunat | * (OK, 14 counted from yesterday, I guess, as Hydra has been working on it already.) | 06:32:42 |
| leona | likely the timeline for branchoff needs to shift a few days and probably the release too. (that's why it's planned for 25.25. :P) | 06:34:11 |
