| 21 Nov 2025 |
 K900 | Maybe just try running less builds at a time | 10:42:58 |
| K900 | They tend to be weirdly timing sensitive | 10:43:06 |
 uep | it's trying a lot in parallel.. 36c/72t makes it greedy i guess | 10:44:15 |
| uep | nah, gjs blows up every time | 10:56:35 |
| uep | > Gjs-Message: 10:54:41.636: Profiler started
> Gjs-Message: 10:54:41.636: Profiler stopped
> Trace/breakpoint trap (core dumped)
> Trace/breakpoint trap (core dumped)
>
> (gjs-console:2804): Gjs-CRITICAL **: 10:54:42.406: Attempting to run a JS callback during garbage collection. This is most likely caused by destroying a Clutter actor or GTK widget with ::destroy signal connected, or using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked.
> The offending callback was destroy(), a vfunc.
> == Stack trace for context 0x5555555b36c0 ==
> Gjs-Message: 10:54:42.497: Wrote coverage statistics to /build/gjs-1.86.0/build/coverage.lcov
> Trace/breakpoint trap (core dumped)
| 10:57:45 |
| uep | yuck | 10:57:47 |
| uep | going to try building just staging-next first | 11:01:15 |
 vcunat | You're atop staging-next now? | 11:02:06 |
| vcunat | So the gjs build is this one?
/nix/store/p8qi0c1z1mv0x67pwd9p0s64y4dsma9z-gjs-1.86.0.drv
| 11:02:16 |
 Grimmauld (any/all) | i do in theory have 5 builders and intel igpu, i do not have to build musl... What is it you need to test? Just gtk4 apps? | 11:02:17 |
| K900 | Yes | 11:02:22 |
| Grimmauld (any/all) | does my system mesa also need to be from staging-next ? | 11:03:51 |
| K900 | No | 11:04:00 |
| K900 | 25.3 from master is fine | 11:04:03 |
| Grimmauld (any/all) | is zenity enough to reproduce whatever issues? | 11:04:58 |
| vcunat | staging-next has the advantage that it gets more things in cache (assuming you do the gtk4 update) | 11:05:06 |
| Grimmauld (any/all) | its the cheapest gtk4 app one can build | 11:05:13 |
| uep | error: Cannot build '/nix/store/p8qi0c1z1mv0x67pwd9p0s64y4dsma9z-gjs-1.86.0.drv'.
| 11:05:29 |
| Grimmauld (any/all) | actually zenity on staging-next is already cached | 11:05:34 |
| uep | yep, that's the one, and it dies in plain staging-next too | 11:05:42 |
| vcunat | you can download it:
https://hydra.nixos.org/build/314110198 | 11:05:53 |
| Grimmauld (any/all) | launches for me | 11:06:18 |
| Grimmauld (any/all) | 
Download image.png | 11:06:19 |
| uep | bitten by negative cache i guess, but i'm more worried why it's failing | 11:06:23 |
| Grimmauld (any/all) | just current staging-next | 11:06:37 |
| vcunat | (I don't know what's wrong with the build, but it's surely unrelated to the issue at hand.) | 11:06:38 |
| uep | yeah | 11:06:52 |
| Grimmauld (any/all) | we really should consider nulling out zenity in sdl3. Its there to display an error emssage if sdl3 fails to create a wayland window, and to act as a file picker when portals are unavailable. Both not super critical. | 11:08:08 |
| Grimmauld (any/all) | https://github.com/NixOS/nixpkgs/pull/459808 will help too, but not for this issue here | 11:09:07 |
| Grimmauld (any/all) | the sdl closure is a mess rn | 11:09:14 |
