| 23 Sep 2025 |
 Grimmauld (any/all) | you could tag your PRs as "part of #445447", or just write comments | 08:57:21 |
|  kenji changed their display name from a-kenji to kenji. | 10:38:04 |
 K900 | 
Download image.png | 10:57:55 |
| K900 | Holy shit a major Qt release milestone is hit after only one reschedule | 10:58:06 |
| K900 | The temperature in hell has dropped by a few degrees | 10:58:15 |
| K900 | @Wolfgang Walther https://github.com/NixOS/nixpkgs/pull/436110 is a mass rebuild now | 12:11:24 |
| K900 | On nedxt | 12:11:53 |
 Wolfgang Walther | OK. Should I revert on master? | 12:12:21 |
| K900 | I think it's easiest to revert on master, run the merge train again, then unrevert on staging-not-next | 12:12:40 |
| K900 | The trains are running now | 12:27:12 |
| K900 | The trains are done | 12:27:37 |
| K900 | I think I'll just push a revert of revert | 12:27:47 |
| K900 | So we don't have to do another PR | 12:27:54 |
| Wolfgang Walther | Ok, thanks. | 12:28:24 |
| K900 | Oh wait no | 12:28:43 |
| K900 | We have to do a PR | 12:28:47 |
| K900 | Because the fetcher changed | 12:28:50 |
| Wolfgang Walther | Will you or shall I? | 12:28:59 |
| K900 | If you have the time | 12:29:25 |
| K900 | I am still pretty sick and busy with $work | 12:29:36 |
| Wolfgang Walther | Ok, I will look at it. | 12:29:51 |
| Wolfgang Walther | Turns out this update is already on staging as https://github.com/NixOS/nixpkgs/commit/60eb2b5686aa3a4d7f9a8f11d7757d259be9f34e. So no need to re-apply. I can't really wrap my head around how the revert was able to propagate back to staging without breaking this (by reverting back the version number), but it seems everything is alright. | 12:39:41 |
| Wolfgang Walther | (it's even on staging-next, so I assume there was a conflict to resolve when merging master to staging-next earlier?) | 12:40:19 |
| Wolfgang Walther | Which also means.. that I'm not sure whether the revert actually stopped the mass rebuild - or whether that was caused by resolving the merge conflicts? | 12:41:44 |
 Vladimír Čunát | 🤔 I think default merging will merge two same changes without conflict? | 12:41:52 |
| Vladimír Čunát | (i.e. if both sides make the same change, it just passes) | 12:42:14 |
| Vladimír Čunát | * (i.e. if both sides of the 3-way diff make the same change, it just passes) | 12:42:25 |
| Vladimír Čunát | Though I believe there's not a 100% consensus whether that's a good thing to do. | 12:42:59 |
| Wolfgang Walther | Yeah, but:
- staging changes to 1.14.0 -> 1.15.1, this is now in staging-next
- master changes the same.
- master is merged into staging-next, but now has a conflict in the fetcher.
- this conflict is resolved when manually merging. (probably in a wrong way, if that caused a mass rebuild - the right conflict resolution should have just kept what was on staging-next!)
- we revert on master.
- the revert is merged cleanly into staging-next... the diff shows "1.15.1 -> 1.14.0".
- But the file still has "1.15.1" in it.
How did the revert apply and show a diff - but not make a change?
| 12:44:38 |
| Wolfgang Walther | It seems that the merges from master->staging-next->staging after the revert didn't actually apply the revert. At least the diff for these merges doesn't show any changes to that file. | 12:46:43 |
