fix(cores): pin libretro-uae to the 2.6.1 branch it actually tracks - #19
Merged
Conversation
My mass pin in #18 clobbered an existing pin. libretro-uae is not built from the default branch - libretro-uae_BRANCH = 2.6.1 makes the clone track a release branch - but the pin I added pointed at the default branch HEAD, and _HASH is checked out after the clone, so it won. 2.6.1 sets TARGET_NAME := puae2021 and master sets TARGET_NAME := puae, so the build produced puae_libretro.so while the makefile went looking for puae2021_libretro.so: mv: cannot stat 'src/libretro-uae/puae2021_libretro.so': No such file Repin to 6636d5f, the tip of 2.6.1, which keeps the reproducibility #18 was after without moving the core off its release branch. Both platform patches apply there, and its Makefile sets TARGET_NAME := puae2021 as expected. libretro-uae is the only core with a _BRANCH override, so it is the only one affected. The verification script behind #18 fetched origin HEAD unconditionally and so could not have caught this - noted in #16 for the automation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes a regression I introduced in #18.
mainis currently red because of it.What I broke
libretro-uaewas already pinned — not by a SHA, but by a branch:libretro-uae_BRANCH = 2.6.1The clone rule honours that, but the
_HASHcheckout runs after the clone, so a SHA silently wins over the branch. The mass pin in #18 added a_HASHpointing at the default branch HEAD, which moved the core off its release branch.The consequence is not a compile error, which is why it took a while to spot:
TARGET_NAME2.6.1(intended)puae2021puae2021_libretro.so✅puaepuae_libretro.so❌The core built fine. It just built under a different name than
libretro-uae_COREand the top-level makefile expect.The fix
Repin to
6636d5f, the tip of the2.6.1branch. That keeps the reproducibility #18 was after without moving the core off its release branch, and adds a comment so the next person doesn't repeat it.Verified: both platform patches apply at
6636d5f, and itsMakefilesetsTARGET_NAME := puae2021.Blast radius
libretro-uaeis the only core with a_BRANCHoverride — checked across both platform makefiles — so it's the only one affected. Every other pin in #18 targets a repo with no branch indirection.Why my verification missed it
The script behind #18 fetched
origin HEADunconditionally and tested whether the patch applied. Both were true here — the patch is compatible with either branch — so it reported OK. It never checked which ref the build was supposed to use, and it can't catch a "builds, but the artifact is named differently" failure at all, since it doesn't build anything.Noted in #16 so the proposed bump automation respects
_BRANCHand treats a missing expected output as a failure, not just a non-zero exit.