Fix KMyMoney AppImage build
Closed, ResolvedPublic


As of Jan 27, 2019 the KMyMoney appimage nightly build does not work anymore. The application compiles, links and installs, but the construction of the resulting AppImage fails.

Who can help me out on this one? I am happy to make any changes if I would just know where to look for. Any help is very much appreciated. If you know of people who have the necessary knowledge about this AppImage generation procedure feel free to add them.

So far, I have compared the two logs and noticed the following things:

Difference in tool version

161 - linuxdeployqt 5 (commit 152b8e8), build 607 built on 2018-12-30 17:03:41 UTC
162 - linuxdeployqt 5 (commit 37631e5), build 624 built on 2019-01-20 14:41:18 UTC

161 - appimagetool, continuous build (commit 6baa36d), build 2008 built on 2018-12-22 13:59:15 UTC
162 - appimagetool, continuous build (commit b80e0e0), build 2033 built on 2019-01-19 12:03:10 UTC

causing the following error in 162 right after the above log line:

fatal: Not a git repository (or any of the parent directories): .git
NOTE: Using the output of 'git rev-parse --short HEAD' as the version:
      Please set the $VERSION environment variable if this is not intended

Parallel mksquashfs: Using 12 processors
followed by
161 - Creating 4.0 filesystem on KMyMoney-x86_64.AppImage, block size 131072.
162 - Creating 4.0 filesystem on KMyMoney--x86_64.AppImage, block size 131072. Notice the extra dash here.

and later on

in 161

+ GIT_REVISION=7152278
+ VERSION=-7152278
+ cd /home/appimage//appimage-workspace/
+ APPIMAGE=kmymoney--7152278-x86_64.appimage
+ mv KMyMoney-x86_64.AppImage kmymoney--7152278-x86_64.appimage
+ mv /home/appimage//appimage-workspace/kmymoney--7152278-x86_64.appimage /home/appimage/workspace/KMyMoney_Nightly_Appimage_Build/

but in 162 this is

+ GIT_REVISION=d6c0b56
+ VERSION=-d6c0b56
+ cd /home/appimage//appimage-workspace/
+ APPIMAGE=kmymoney--d6c0b56-x86_64.appimage
+ mv KMyMoney-x86_64.AppImage kmymoney--d6c0b56-x86_64.appimage
mv: cannot stat ���KMyMoney-x86_64.AppImage���: No such file or directory

since the generated file has an extra dash.

apol added a subscriber: azubieta.Jan 31 2019, 3:18 PM
TheAssassin added subscribers: probono, TheAssassin.EditedJan 31 2019, 3:52 PM

There haven't been any changes in linuxdeployqt in between the two builds you named that could explain the difference in behavior. I suspect that there were some changes in the KDE binary factory build scripts. Where's that code located so we could have a look?

The issue with appimagetool calling git and failing to recognize the error status can be considered a bug. I'll check the appimagetool source code to identify the problematic section in the code.

It looks to me like before Jan 29, there might have been a .git directory, which is no longer available, triggering this appimagetool bug.

Upstream issue:

At the moment all of our Appimage tooling is project specific - so in the case of KMyMoney, this is found in the kmymoney repository.

The reason why the jobs have started failing is because prior to recent changes to linuxdeployqt, the appimages were always named following the convention of $appname-$arch.AppImage. This is fixed for KMyMoney in e3c27df58f0a958b949b0aa0a9a6bfe905e80836

For KMyMoney I have corrected our logic to export VERSION to linuxdeployqt as well. We've always performed the invocation of linuxdeployqt from the build directory (as the kmymoney.appdir/ folder is there) hence why it can't find the .git directory for the application.

There was also another bug which had previously been occurring but which hadn't been fatal before in our scripts. They were supposed to be capturing the version of KMyMoney itself from CMakeLists.txt, but were in the wrong working directory at the time. I have also corrected this.

It seems that at this stage, appimagetool's behaviour is unaffected, so Kdenlive and Krita haven't had to adjust their scripts (which all have the same heritage - having initially come from Krita)

bcooksley closed this task as Resolved.Feb 1 2019, 7:25 AM

This is now confirmed as fixed.