AppImages for v2.3.0 are broken

[guihkx]

As of release 2.3.0, both AppImages (Qt 5 and Qt 6) don't run anymore here on Arch Linux:

Qt 6:

$ ./Notes_2.3.0-Qt6.4.3-x86_64.AppImage
/tmp/.mount_Notes_8Cw9D3/AppRun.wrapped: /tmp/.mount_Notes_8Cw9D3/usr/bin/../lib/libQt6Core.so.6: version `Qt_6.4' not found (required by /tmp/.mount_Notes_8Cw9D3/AppRun.wrapped)

Qt 5:

$ ./Notes_2.3.0-Qt5.15.2-x86_64.AppImage
/tmp/.mount_Notes_5jNodb/AppRun.wrapped: symbol lookup error: /tmp/.mount_Notes_5jNodb/AppRun.wrapped: undefined symbol: _ZdlPvm, version Qt_5

Need to investigate why...

[guihkx]

I began the investigation on this.

After git bisect'ing through versions v2.2.1 (good) and v2.3.0 (bad), git told me the first bad commit is ad3a6a5c690c97c68015945a92396a0d601ef73a.

Here's the entire git bisect log:

git bisect start
# status: waiting for both good and bad commits
# bad: [648e488c4a321fe88df837163a7c5dd08c421f35] Update appdata xml for version 2.3.0
git bisect bad 648e488c4a321fe88df837163a7c5dd08c421f35
# status: waiting for good commit(s), bad commit known
# good: [bd69c2165261df38689a26241a3db3d3d8cd9189] fix(ci): Also run the main workflow when a version tag has been pushed
git bisect good bd69c2165261df38689a26241a3db3d3d8cd9189
# bad: [66b111b51711622dd2c307b4dda409803efded84] Implement export/import to/from .txt/.md
git bisect bad 66b111b51711622dd2c307b4dda409803efded84
# good: [be351b70a59be07d29b14dfff6f931896fcc0435] chore(ci): Update to Fedora 38
git bisect good be351b70a59be07d29b14dfff6f931896fcc0435
# bad: [419d232f7c0da836b9c6ca5f4e496dd64c36e190] Merge pull request #666 from nuttyartist/feat/zjeffer/dockerfiles
git bisect bad 419d232f7c0da836b9c6ca5f4e496dd64c36e190
# good: [ddb85cb3032f19aa4c4693eaad97d9eb7a091015] chore(ci): Only download required build artifacts for Windows
git bisect good ddb85cb3032f19aa4c4693eaad97d9eb7a091015
# good: [438b7f5b2d7fb3d7306c664c75fa364790124606] Merge pull request #663 from nuttyartist/feat/zjeffer/dockerfiles
git bisect good 438b7f5b2d7fb3d7306c664c75fa364790124606
# bad: [097bab872b8b0930fd45fec3d8a6768ac4970a3a] remove leftover debug echos
git bisect bad 097bab872b8b0930fd45fec3d8a6768ac4970a3a
# bad: [ad3a6a5c690c97c68015945a92396a0d601ef73a] Use docker images for CI/CD (fedora, opensuse, aqtinstall)
git bisect bad ad3a6a5c690c97c68015945a92396a0d601ef73a
# first bad commit: [ad3a6a5c690c97c68015945a92396a0d601ef73a] Use docker images for CI/CD (fedora, opensuse, aqtinstall)

If someone else wants to maybe take a look at the build logs, or just test the produced AppImages, you can find them on my GitHub fork.

More investigation is obviously needed, but I suspect this to be a red herring, because I remember testing the produced AppImages in PR #666 (and I'm sure @zjeffer did that, too).

So we also need to consider the possibility of breakage in some third-party tool (e.g. linuxdeploy or linuxdeploy-plugin-qt).

[guihkx]

Side note: The current Docker container set up we use in the CI for Linux is causing a chicken and egg problem.

I want to test some changes I made to the aqtinstall Qt 6 Dockerfile, but our current GitHub Actions set up makes it impossible to easily do so, because the build container is always pulled from @zjeffer's Docker page.

We need to think of a better strategy to test changes to Dockerfiles on the spot, because right now I have to:

1. Build the container locally
2. Manually copy and paste all commands from the appimage-aqtinstall job in .github/workflows/linux.yml.
3. Pull the resulting AppImage file out of the container
4. Test it on the host

[nuttyartist]

Is this problem occurs only on Arch?

[guihkx]

Nope, I've also tested both AppImages on Ubuntu 22.04 and they fail to launch with the same error. :(

The Qt 6 AppImage I managed to fix after some substantial changes.

Here's how to test these changes locally:

# build the image
docker build -t notes:ubuntu_aqtinstall_6 -f Dockerfiles/ubuntu-aqtinstall-6 .
# build Notes and create the AppImage
docker run -v $(pwd):/src -it --rm notes:ubuntu_aqtinstall_6

The resulting AppImage will be in the build directory.

I'm not really sure how to proceed from here, however.

Because our CI is currently pulling the container image from zjeffer's page, merging my changes wouldn't fix the Qt 6 AppImage right away.

In contrast, if we merged my changes, we'd also require some extra changes to the build steps of our CI, which I haven't done yet.

I need to think more about this, I guess, but I'd like to hear other's opinions too, especially @zjeffer's.

[zjeffer]

I think you could use https://github.com/nektos/act to run github actions locally, which would fix the need for manually copy-pasting commands from the github action workflow. But I'm not sure it's compatible with every type of container.

When I implemented #666 I think I always tested my changes using GitHub actions, by basically watching what the action does on GitHub every time I push my changes.

I'm not sure there are better ways to do this. I feel like GitHub really needs to develop a way to easily test github actions locally.

Because our CI is currently pulling the container image from zjeffer's page, merging my changes wouldn't fix the Qt 6 AppImage right away.

Can't you change this so it doesn't pull it from my page, and instead uses your own image?

[guihkx]

Can't you change this so it doesn't pull it from my page, and instead uses your own image?

I suppose I could, but IMO that'd be only moving the problem elsewhere instead of solving the underlying issue, which is: We can't immediately test changes made to Dockerfiles using the current CI set up.

For example, if someone sends a PR modifying any of the Dockerfiles, I'd love for our CI set up to generate build artifacts using those modified Dockerfile images.

So my idea goes more in that direction, I'm just not sure what's the best way to approach it just yet.