| 23 Sep 2025 |
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 |
vcunat | 🤔 I think default merging will merge two same changes without conflict? | 12:41:52 |
vcunat | (i.e. if both sides make the same change, it just passes) | 12:42:14 |
vcunat | * (i.e. if both sides of the 3-way diff make the same change, it just passes) | 12:42:25 |
vcunat | 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 |
vcunat | Ah, you reverted too fast. | 12:49:18 |
vcunat | So staging-next never knew this merge+revert. | 12:49:36 |
vcunat | i.e. the merge base (for master->staging-next) always seemed like master didn't change anything and staging-next updated it. | 12:50:29 |
Wolfgang Walther | Ah, that was a misunderstanding on my part, then. | 12:50:40 |
Wolfgang Walther | I thought this was already in staging-next. | 12:50:47 |
Wolfgang Walther | But it was what caused the merge conflict and never made it there. | 12:50:55 |
Wolfgang Walther | After the revert, the state was clean again. | 12:51:00 |
Wolfgang Walther | (there was never a manual merge) | 12:51:07 |
vcunat | It is in staging-next now, but there was no auto-merge on the state between merging the PR and reverting it. | 12:51:58 |
vcunat | * It is in staging-next now, but there was no merge on the state between merging the PR and reverting it. | 12:52:10 |
Wolfgang Walther | yes. | 12:52:15 |
Wolfgang Walther | It only came in as merge+revert = no-op. I see. | 12:52:22 |
K900 | Yeah | 12:52:35 |
Wolfgang Walther | In any case, the update is already there, so nothing to do for me :D | 12:52:54 |
vcunat | Rarely you run into such "problems" resulting from the dumbness of 3-way merging. | 12:53:05 |
vcunat | If the auto-merge timing was different, it would resolve differently. | 12:53:21 |
vcunat | Or "luckily" it wouldn't merge cleanly because of the fetcher rewrite. | 12:54:31 |
Wolfgang Walther | exactly | 12:54:43 |
vcunat | So, when are we switching to pijul? 😆 | 12:58:38 |
Fabián Heredia | Hi, for cmake 4 I want to pull a patch from sourceforge but I can't seem to find an easy way to do that and seems like other maintainers have opted to inline / commit the patch into a file in nikpkgs. wsid?
https://sourceforge.net/p/panotools/libpano13/ci/698e20b4d296c1dbde9d010c3fb8d54050e56ddb/ | 15:03:10 |
Fabián Heredia | * Hi, for cmake 4 I want to pull a patch from sourceforge but I can't seem to find an easy way to do that and seems like other maintainers have opted to inline / commit the patch into a file in nikpkgs. What should I do?
https://sourceforge.net/p/panotools/libpano13/ci/698e20b4d296c1dbde9d010c3fb8d54050e56ddb/ | 15:03:21 |