| 20 May 2026 |
 K900 | Autostart entries are not running | 12:19:30 |
| K900 | Problem kinda for upstream in weird cases, NixOS always | 12:19:38 |
| K900 | GNOME presumably uses the same standard systemd generator as everything else | 12:19:50 |
 André Lima | Right. I just checked and GNOME didn't stop supporting autostart, it just removed it's built-in service manager. Autostart entries are handled via systemd, like you said | 12:24:09 |
 Vladimír Čunát | I see context in the systemd room, which is maybe https://matrix.to/#/!SsuQHVzf59iBgk6YIm:0upti.me?via=nixos.org&via=matrix.org&via=tchncs.de (at least my Element thinks so; behaves weird) | 12:45:58 |
 hexa | firefox on nixos-unstable contains a known rce | 22:08:02 |
| hexa | 150.0.2 | 22:08:05 |
| hexa | I updated 150.0.2 -> 150.03 on May 12th fwiw | 22:08:42 |
| hexa | and -> 151.0 on may 18th | 22:09:03 |
| hexa | those delays are bonkers | 22:09:16 |
 ghpzin | Isn't it 150.0.3 on both channels now ?
Unless "known rce" part is about 150.0.3 and not 150.0.2 | 22:22:59 |
| hexa | it is about 150.0.3 | 22:29:54 |
| hexa | nixos-unstable indeed has 150.0.3 | 22:30:34 |
| hexa | through a half-cancelled eval that advanced | 22:30:47 |
| hexa | god, these are confusing | 22:30:51 |
| 21 May 2026 |
| Vladimír Čunát | I just look at the git branches for this. | 05:08:13 |
 zowoq | All of the new nspawn container nixosTests seem to be broken since staging-next was merged? e.g. https://github.com/NixOS/nixpkgs/pull/521397 | 05:44:31 |
| K900 | staging-nixos merged with xdg fixes, will start evals in a bit | 07:56:17 |
| K900 | Literally 5 minutes after a timer eval | 08:02:15 |
| K900 | Killed that, started a new one | 08:02:16 |
| Vladimír Čunát | That was manual eval by me after merging the systemd fix. | 08:04:28 |
| Vladimír Čunát | I didn't know that staging-nixos was expected. | 08:04:56 |
| K900 | Uhh | 08:05:26 |
| K900 | I merged the systemd fix into staging-nixos | 08:05:30 |
| K900 | And then staging-nixos into master | 08:05:39 |
| K900 | The only other change on staging-nixos is a ty upgrade | 08:05:48 |
| K900 | So I don't think we're going to have a problem there | 08:05:57 |
| Vladimír Čunát | Ah, I overlooked the target branch. | 08:06:28 |
 Emil Thorsøe | In file included from /nix/store/q9ksx8c79jfj1cawwwzmpq3qapvpvab7-glib-2.88.1-dev/include/glib-2.0/glib/gstring.h:37,
from /nix/store/q9ksx8c79jfj1cawwwzmpq3qapvpvab7-glib-2.88.1-dev/include/glib-2.0/glib/giochannel.h:36,
from /nix/store/q9ksx8c79jfj1cawwwzmpq3qapvpvab7-glib-2.88.1-dev/include/glib-2.0/glib.h:56,
from ../src/vtegtk.cc:44:
../src/vtegtk.cc: In function 'char* vte_terminal_get_selection(VteTerminal*)':
../src/vtegtk.cc:4362:59: error: 'to_integral' is not a member of 'vte'
4362 | return g_strdup (IMPL(terminal)->m_selection[vte::to_integral(vte::platform::ClipboardType::PRIMARY)]->str);
| ^~~~~~~~~~~
/nix/store/q9ksx8c79jfj1cawwwzmpq3qapvpvab7-glib-2.88.1-dev/include/glib-2.0/glib/gstrfuncs.h:324:38: note: in definition of macro 'g_strdup'
324 | #define g_strdup(x) g_strdup_inline (x)
Does someone recognize off-hand, why staging-next merge invoked this error, I don't know much C++, but somehow looks like internal inconsistency, that I would not expect to compile anywhere | 10:48:53 |
| Vladimír Čunát | Perhaps write at least which package is triggering this glib error? | 10:51:41 |
