Patch patchinstall.sh to --upstream-commit this is based on
Thaodan opened this issue · 8 comments
Please patchinstall.sh to the commit this is (re)based on currently and add info latest staging version this is based on to avoid errors.
What you're talking about isn't a function inherit in git, but something implemented specifically in the patchinstall.sh file used in wine-staging.
When wine-staging's patchinstall.sh script is called with the --upstream-commit argument, they return the results from a function call which contains the shasum from the upstream commit that version of staging was based on.
This value can then in turn be used with git checkout in the wine repo to change back to the wine commit that version of staging was based on.
To implement this here, we'd have to create a patch script, put the staging sha it's based on in there. And to build wine-staging with pba people would have to first pull the latest gits of all 3 repos, then remove any changes made to the wine tree and move it back to its git state, then change staging back to what pba was based on, then change wine back to what staging was based on, then run patchinstall.sh and then apply the pba patch.
It can be done. But I think it's counter-intuitive.
By that I mean that wine-staging changes frequently. And wine-pba only needs to be rebased against the new changes if those changes are to any of the few files wine-pba affect, which are all currently found in the wine/dlls/wined3d3 folder in the staging patched wine repo.
And considering how often staging actually changes, a script of this kind - though it would avoid build errors - would defeat the purpose of using git versions in the first place, because you'd be stuck at old versions most of the time. I think a better solution if a never failing patch is the purpose, is to use tagged versions of the repos and stick to specific versions instead.
I know that it isn't and that's the way I'm using it.
I thought to set the sha sum in the patchinstall script the version used in the rebase of the patch here. To prevent for example that that the applying of the patch doesn't work.
@Thaodan the tag(s) pba 'expects' are wine-3.3 and v3.3
i.e wine-staging-3.3
the 'errors' you elude to are trivial, honestly if you chase the bleeding edge you should have some basic skills
here, https://github.com/Firerat/wine-pba/wiki/patch-rebase-and-conflicts
crude wiki, but I hope it removes some mystery
Sorry but that's shit what you're saying some basic skills? There's no where mentioned is the latest version this is mentioned on.
Also nice that you made some doc if someone has issues but it's rude saying you should have some skills and link to your wiki and not that from the author.
Well, it is kind of mentioned. Not the exact sha, but at least that it's 3.3 and not 3.4. 👍
For a rocket scientist, it is considered "basic skills" to fly to the moon.... It should not mean only rocket scientists can ask a rocket scientist questions :)
I try to keep things simple, but most of the time are quickly shot down for doing that... The world of coding are filled to the brim with asshats all sitting on their own high horse :)
@SveSop not as simple , but better since it prevents issues down the road
DIR=$(dirname $0)
for each in $DIR/*.patch
do
patch -p1 < $each || ( echo "error applying $each" ;exit)
done
echo Done patching PBA!
actually, I never remember if the exit will only exit the subshell and not the whole script
yeah
DIR=$(dirname $0)
for each in $DIR/*.patch
do
patch -p1 < $each && continue || echo "error applying $each" ;exit
done
echo Done patching PBA!
that is better, still basic
I have added wine-pba to my wine-staging fork
https://github.com/Firerat/wine-staging/tree/Persistent_Buffer_Allocator
also includes a csmt toggle that makes sense.
This means patchinstall.sh --upstream-commit will output the sha the patchsets are based on
since I'm lazy I have cron running this script which will keep it up-to-date
but I will have to fix merge conflicts manually. I will also need to manually commit wine-pba upstream changes, although that could be scripted with relative ease.