| 29 Nov 2025 |
 K900 | That's a "we don't know what this is" type | 13:25:17 |
 dramforever | i think that makes sense if the entire struct has been memset(0xe5)'d | 13:25:36 |
| K900 | Oh yeah | 13:25:46 |
| dramforever | including the refcnt 3857049062 which is 0xe5e5e5e6 | 13:26:01 |
| K900 | Bumped by one | 13:26:22 |
| K900 | Yeah | 13:26:23 |
| K900 | Conditional breakpoint time? | 13:26:39 |
| dramforever | oh dear | 13:28:38 |
| dramforever | wait i don't have to run it with refcnt log now, if i can just break on the function | 13:29:09 |
| K900 | Well you don't know what the function is | 13:33:54 |
| K900 | But you can break on refcnt_add probably | 13:33:59 |
| dramforever | i have a backtrace | 13:34:58 |
| dramforever | last 2000 lines of refcnt.log for reference https://gist.github.com/dramforever/7689f686881cb863039614ef1ef1e0e0 | 13:35:22 |
| K900 | I want to see when it's created | 13:38:13 |
| K900 | Not when it's dereferenced | 13:38:16 |
| dramforever | oh good point | 13:40:28 |
| 30 Nov 2025 |
 hexa | https://github.com/NixOS/nixpkgs/issues/466417 | 00:11:01 |
| hexa | That sound like the same Firefox issue, no? | 00:11:25 |
 dotlambda | Do the automatic merges master -> staging-next and staging-next -> staging only happen if both succeed? | 00:17:09 |
 André Lima | Looking at the workflow file, I'd say they're independent | 00:19:39 |
| dotlambda | I was expecting the merges to have happened just now but neither did. However, only the staging-next -> staging one has a merge conflict | 00:20:02 |
| dotlambda | Oh, it just appeared 🎉 | 00:20:43 |
| André Lima | Master -> staging-next just finished | 00:20:52 |
| André Lima | staging-next -> staging failed | 00:21:03 |
| dotlambda | I'll do that one manually | 00:21:44 |
 Grimmauld (any/all) | In reply to @robert:funklause.de
I was expecting the merges to have happened just now but neither did. However, only the staging-next -> staging one has a merge conflict Committers can manually launch the action BTW, so it you are ever waiting for something specific you can just be impatient and kick it | 00:22:02 |
| Grimmauld (any/all) | Doesn't work if there is conflicts ofc | 00:22:18 |
| Grimmauld (any/all) | But if you do resolve conflicts it's a good idea to kick it manually still, just to male sure that merge commit propagates. Conflicts on conflicts are no fun. | 00:23:01 |
| Grimmauld (any/all) | * But if you do resolve conflicts it's a good idea to kick it manually afterwards still, just to make sure that merge commit propagates. Conflicts on conflicts are no fun. | 00:23:26 |
| dotlambda | I don't understand. Which merge are you worried might create another conflict? | 00:25:01 |
