Created attachment 128105 [details] kdesrc-build logs from my failed kactivitymanagerd run SUMMARY dfaure reports that kdesrc-build can consider a module failed to update (even though it successfully fetches updates from the git server and successfully rebases the module to the updated 'master' branch). It complains about being unable to restore stashed local changes. See https://invent.kde.org/snippets/868. The pertinent error: user@localhost:~/release-tools$ cd ../src && ./kdesrc-build --src-only Updating kde-build-metadata (to branch master) Local changes detected, stashing them away... Module updated, reapplying your local changes. * * Unable to re-apply stashed changes to kde-build-metadata! * * These changes were saved using the name "kdesrc-build auto-stash at 2020-05-02-21:48" * and should still be available using the name stash@{0}, the command run * to re-apply was git stash pop --index. Resolve this before you run * kdesrc-build to update this module again. * * If you do not desire to keep your local changes, then you can generally run * git reset --hard HEAD, or simply delete the source directory for * kde-build-metadata. Developers be careful, doing either of these options will remove * any of your local work. * Unable to download required metadata for build process * Will attempt to press onward... * Exception message: Runtime Error: Failed to re-apply stashed changes for kde-build-metadata STEPS TO REPRODUCE 1. Change to desired config directory 2. Run kdesrc-build --src-only OBSERVED RESULT Modules randomly fail to update complaining of re-application of stashed changes. Different modules fail on subsequent builds. [18:17] <dfaure> thanks [18:17] <dfaure> it seems like ot happened randomly in various repos [18:17] <dfaure> it [18:17] <dfaure> git version 2.26.1, if it matters [18:33] <dfaure> mpyne happened twice in a row upon "kdesrc-build frameworks", but on different modules every time [18:34] <mpyne> thanks [18:34] <dfaure> mpyne: once kde-build-metadata, once kio and kdesrc-build itself... pretty random In my own testing from an old checkout, applying to master as of 2020-05-02, I had one module fail for this reason, kactivitymanagerd. I believe this may be related to a commit that removed a file, but I cannot understand what situation kactivitymanagerd had been in before that would have led kdesrc-build to think a local change had occurred. I was not able to reproduce random modules having this failure. EXPECTED RESULT The source code modules cleanly update, since there were no local modifications to worry about. SOFTWARE/OS VERSIONS kdesrc-build: v19.12-44-geaf569d ADDITIONAL INFORMATION There have been recent changes to git-stash handling to fix other "fake local change detected" bugs.
David, I'm not able to immediately resolve so entering a bug. I will update kdesrc-build to include 'git-status' output before update and stash operations to potentially improve on the error reporting available. I suspect something to do with long periods of changes between updates. For clarity in case you look yourself, the basic sequence kdesrc-build for updates to existing modules is: cd $srcdir git fetch --tags $remote DO_STASH = git diff-index --quiet HEAD != 0 if DO_STASH: git stash save --quiet git checkout $branch ; unconditionally done git rebase origin/$branch if DO_STASH: git stash pop
Git commit 5019317f41977d67f1932cacb68850bda83ec73b by Michael Pyne. Committed on 02/05/2020 at 23:21. Pushed by mpyne into branch 'master'. git: Capture basic git-status info before error-prone ops. There have long been bug reports around git-stash handling. I just had to enter another one, but it's hard to troubleshoot what git was seeing after the fetch and rebase has already happened, even if you try to rewind with reflog. For now this will just run a simple 'git-status' as a smoke check before the update, and optionally if a stash or error occur. My hope is this will permit more detail to be provided with subsequent bug reports. M +6 -0 modules/ksb/Updater/Git.pm https://invent.kde.org/kde/kdesrc-build/commit/5019317f41977d67f1932cacb68850bda83ec73b
This issue has gotten much worse. Since commit ccd8d4cff3547bb62de87, kdesrc-build just stashes away all my changes, unconditionally. This has made me lose changes all over the place. I maintain 80 frameworks and occasionally hack on others, like akonadi. If I add some debug output in akonadi for a rare bug, hoping it will happen again one day, I don't want kdesrc-build to just stash that away on the next update. The commit says "Leave it up to the user to recover the stashed changes", that's not reasonable for a use case like the above. I'm supposed to keep a list of the repos in which I have local changes, and once kdesrc-build is finished, go into those, stash pop and rebuild? Talk about an automated tool.... I don't understand why kdesrc-build is having so much trouble doing the "stash, pull rebase, stash pop" dance. My simple http://www.davidfaure.fr/2020/gitup hasn't failed in years. If there's a conflict, there's a conflict, but otherwise it does not lead to "Unable to re-apply stashed changes" with no stashed changed. There's also git's newer autostash feature, but I haven't tried that. If it works OK, I'd be fine with kdesrc-build depending on that feature (and doing the current just-stash if git is older).
My suggested fix is https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/61
A possibly relevant merge request was started @ https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/62
Git commit c4ad3dbb9038f9e0339f898a75fa48ce4fdc9cea by Michael Pyne. Committed on 11/10/2020 at 22:36. Pushed by mpyne into branch 'master'. git: Automatically reapply stashed changes if possible. In the event that the stash does not apply a "post-build" message is issued to warn the user. Otherwise there is an in-situ message. This addresses user feedback I have received on Invent and IRC. In particular re-fixes #42 and bug 420933, and fixes #49. All that I do here is to use the existing logic and add "git stash pop" after the update phase has completed. I've previously tried --autostash (see !32 and !45) and that had issues of its own. Using this approach allows us to use rely on git directly without risk of missing a merge conflict that git sometimes seems to generate with `git pull --autostash` (see https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/32#note_46926). The merge request !61 may still be applicable. I haven't looked long enough to tell if there's more on it than the --autostash feature which still causes us problems... it's possible that there's a more reliable method than what we're doing though we've already taken pains to simplify this routine because of the recurring stash failures that we've seen previously. M +18 -7 modules/ksb/Updater/Git.pm https://invent.kde.org/sdk/kdesrc-build/commit/c4ad3dbb9038f9e0339f898a75fa48ce4fdc9cea