| 29 Nov 2025 |
 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 |
| Grimmauld (any/all) | In reply to @robert:funklause.de
I don't understand. Which merge are you worried might create another conflict? Its more about accidental discards of commits. We had merge conflicts resolved on staging-next by creating a merge commit. But then the next automerge after got a new conflict, requiring manual resolution again. But because the staging side of that second co flict didn't have the base resolution, mistakes happened and some hunks were lost in the process. Cleaning that up took some got magic. Its just less error prone to make sure merges made to staging-next propagate immediately, e.g. by kicking the action. If the cobflict is in next -> staging, its less bad of a concern though | 00:32:26 |
| dotlambda | I could also test that manually by merging my local branches but sure, I'll start the automatic merge jobs again | 00:33:26 |
| Grimmauld (any/all) | I mean, it might well be voodoo, git can be weird sometimes. My understanding is probably a bit off here. | 00:36:04 |
| dotlambda | Actually, it looks like the job didn't create new commits cause no commits were made to master in the meantime | 00:39:37 |
