| 30 Nov 2025 |
 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 |
| 1 Dec 2025 |
 Fabián Heredia | thanks <3 | 01:59:21 |
| Fabián Heredia | 
Download image.png | 02:04:51 |
| Fabián Heredia | no rush but if someone with eval priviledges could start another one for gcc-15 I would appreciate it (cherry-picked a fix that should address about 40% of breakage)
| 02:04:52 |
 Sergei Zimmerman (xokdvium) | Kicked it | 02:47:53 |
| Fabián Heredia | Thanks <3 | 04:51:12 |
 ghpzin | @Fabián Heredia
I kind of missed it, but are the current plans to merged gcc15 into current staging ?
And if so where is the better place to push new fixes to, seeing as you cherry-pick them for jobset purposes ? | 04:51:32 |
| Fabián Heredia | Those that were cherry-picked are already in staging, the idea is to catch any big breakages before merging to staging (though I'm not sure if it is going to be before the next staging-next cycle, staging is rolling though an only gets restricted near releases) | 04:53:01 |
| Fabián Heredia | Oh, btw thanks for all the PRs/fixes for different packages ghpzin , really appreciate it I think this is mostly ready to be merged into staging. Was going over the list that Alyssa Ross and Yureka (she/her) | 05:17:18 |
| Fabián Heredia | * Oh, btw thanks for all the PRs/fixes for different packages ghpzin , really appreciate it I think this is mostly ready to be merged into staging. Was going over the list that Alyssa Ross and Yureka (she/her) made on the PR about breakages and only big-ish thing is berkleyDB | 05:19:01 |
| Fabián Heredia | * Oh, btw thanks for all the PRs/fixes for different packages ghpzin , really appreciate it I think this is mostly ready to be merged into staging. Was going over the list that Alyssa Ross and Yureka (she/her) made on the PR about breakages and only big-ish pending thing is berkleyDB | 05:19:14 |
 uep | classic, didn't that break on last gcc too? | 05:19:35 |
| Fabián Heredia | * Oh, btw thanks for all the PRs/fixes for different packages ghpzin , really appreciate it I think this is mostly ready to be merged into staging. Was going over the list that Alyssa Ross and Yureka (she/her) made on the PR about breakages and only big-ish pending thing is berkleyDB 5.3.z | 05:19:37 |
| Fabián Heredia | yeah, probably | 05:19:48 |
| ghpzin | Okay, I will try to create PRs for leftover fixes I have this week, they should cover most things.
Would be nice to have somebody who uses pkgsMusl to get involved, seeing as a lot of things break there. I know some required things, just not whether they are "correct to do".
Also there is a pretty scary thing printed in hydra tests and linux_5_10 breaks again with unresolved symbol filp_close after recent kernel update. | 05:22:26 |
| ghpzin | Okay, I will try to create PRs for leftover fixes I have this week, they should cover most things.
Would be nice to have somebody who uses pkgsMusl to get involved, seeing as a lot of things break there. I know some required things, just not whether they are "correct to do".
Also there is a pretty scary thing printed in hydra tests and linux_5_10 breaks again with unresolved symbol filp_close after recent kernel update (but that one was probably just a matter of time, seeing as it pops up every other kernel/gcc update). | 05:25:53 |
| Grimmauld (any/all) | is there a PR against which i should build? | 09:23:30 |
| Grimmauld (any/all) | i was building the fancy llvm-native stuff, but a lot of things are broken there. | 09:23:55 |
| ghpzin | You mean musl with gcc15 ? | 09:26:00 |
