Call for testing: Official AppImage

[brunvonlope]

Hi, @aferrero2707, @probonopd and @azubieta. Following #9 discussion, we are trying to build an official AppImage upstream: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440 😃

Help is appreciated regarding some little bugs.

[probonopd]

Great initiative @brunolopesdsilv, appreciate it very much.

When using this build

https://gitlab.gnome.org/GNOME/gimp/-/jobs/3746033/artifacts/file/build/linux/appimage/_Output/GNU_Image_Manipulation_Program-x86_64.AppImage

then (yes, I know...) On Windows 11 WSL2, I get:

LD_DEBUG=libs Downloads/GNU_Image_Manipulation_Program-x86_64.AppImage
(...)
       781:       trying file=/tmp/.mount_GNU_Imtp5SVz/usr//lib/libpcre2-8.so.0
       781:       trying file=/tmp/.mount_GNU_Imtp5SVz/usr//lib/x86_64-linux-gnu/libpcre2-8.so.0
       781:
       781:
       781:     calling init: /tmp/.mount_GNU_Imtp5SVz/usr//lib/x86_64-linux-gnu/libc.so.6
       781:
Segmentation fault
user@DESKTOP-4U17RT8:/mnt/c/Users/User$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Unfortunately I don't know the reason yet. Does it run on a real Focal Live ISO?

[brunvonlope]

This is probably due this AppImage being generated in Debian Bookworm. I am downloading Focal ISO to be sure.

[probonopd]

Indeed. As per https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440/diffs#587d266bb27a4dc3022bbed44dfa19849df3044c_30_32, Debian Bookworm is used. This means that (unless you privately bundle any and all libraries, down to and including glibc) the resulting AppImage will not run on distributions older than Debian Bookworm, which is still very new (released on June 10, 2023). Is there any chance this could be built on the oldest still-supported LTS release of Ubuntu, or at least on Debian oldstable?

[brunvonlope]

(unless you privately bundle any and all libraries, down to and including glibc

What do you mean, exactly? I would need to do objcopy to detect libc dependencies?

---

Is there any chance this could be built on the oldest still-supported LTS release of Ubuntu, or at least on Debian oldstable?

Ubuntu unfortunately isn't a option since our build is based on Debian in both stable and dev branches. The most that I could do is using Bullseye (used by the stable branch) but this would require custom building some deps... making too hard to maintain.

[probonopd]

What do you mean, exactly?

Most AppImages don't ship private copies of "basic" libraries such as glibc, which is assumed to be present in every distribution. The upside of this approach is, among other things, to save a few megabytes. But the downside is that an AppImage built this way will no run on target systems older than the build system. Hence it is recommended to build on one of the oldest still-supported long term support Linux distributions.

If you have to use a more recent build system and still would like users of less recent distributions to be able to run the application, then you need to bundle all libraries privately inside the AppImage. This will lead to a few MB overhead but is possibly worth it.

Unfortunately, bundling a private copy of glibc can be a bit tricky, as it involves multiple files. go-appimage appimagetool -s deploy can privately bundle all libraries (including glibc).

Inkscape, for example, is using it.

[brunvonlope]

I am already using this option:

https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440/diffs#0ecf94caf0ea41aaebfa4076c8e54a5984fdddb4_0_91

[brunvonlope]

So, I wonder if there is something wrong in AppRun. We don't use the generated AppRun since it doesn't suit GIMP needs. Can you take a look at it? https://gitlab.gnome.org/GNOME/gimp/-/blob/79579d3acaf766e8c5a1add235b9b2009ad54a28/build/linux/appimage/AppRun

[probonopd]

Sorry I didn't realize you were already using -s deploy. In this case, there is no need to build on an older system, it should work this way. On first sight your AppRun looks reasonable to me. So, did you already test the AppImage on a couple of distributions and note down on which ones it worked and on which ones it didn't? This might possibly give us some clues about what is going on.

What looks a bit concerning to me is that you are doing manual copy operations ("Copy babl, GEGL and GIMP") after running appimagetool -s deploy. That means that the dependencies of the manually copied files might not get deployed? Try running appimagetool -s deploy after everything else that populates the AppDir in your script.

[brunvonlope]

I began to testing very hardcore with Ubuntu 14.04 but the distro got broken so I am using 18.04 to testing now.

The seg fault occurs in mkdir command. So, I will edit the AppRun to run all the coreutils commands via the Linux lib that go-imagetool copy.

According to the generated AppRun (that i only use a bit of code), running things with the Linux lib makes the AppImage work in every distro, and actually only GIMP runs (if mkdir didn't crashed) via the Linux lib.

[brunvonlope]

What looks a bit concerning to me is that you are doing manual copy operations ("Copy babl, GEGL and GIMP") after running appimagetool -s deploy. That means that the dependencies of the manually copied files might not get deployed? Try running appimagetool -s deploy after everything else that populates the AppDir in your script

Thanks. I will reorder the gjs, lua and python copying to before the deploy command.

Just to note: gimp, babl and gegl are builded inside AppDir/usr before calling the deploy.

[brunvonlope]

@probonopd :)

[probonopd]

Very cool @brunolopesdsilv. So the remaining issues are

• [ ] Lua can't be found
• [ ] ScriptFu interpreter don't work (related to /usr/bin/env)

?

[brunvonlope]

Yes, @probonopd. I actually have no clue about the Lua issue since the Ivan AppImage, which is maintained, don't work with Lua too.

But ScriptFu interpreter is more serious. I simply can't run GIMP in Fedora because all the plug-ins crashes.

[probonopd]

And this doesn't happen in, say, Ubuntu? Are you putting the directory in which the ScriptFu interpreter lives onto the $PATH in the ÀppRun script? (What is the path to that interpreter?)

[brunvonlope]

And this doesn't happen in, say, Ubuntu?

This happens in Ubuntu too but there GIMP don't get enraged like in Fedora, which complaing about glibc version (since ScriptFu insists in calling the system env).

---

Are you putting the directory in which the ScriptFu interpreter lives onto the $PATH in the ÀppRun script? (What is the path to that interpreter?)

Yes. ScriptFu is stored by default in AppDir/usr/bin and this dir is set in PATH

[brunvonlope]

For example:

[probonopd]

Based on the output above, the system's /usr/bin/env needs a newer glibc than the one that is bundled inside the AppImage. So we must prevent LD_LIBRARY_PATH from spilling out from the inside of the AppDir to binaries outside of it. In other words, we want LD_LIBRARY_PATH to apply only to the binaries inisde the AppDir.

Turns out that this can be done by the use of appimage-exec-wrapper, and this had been discussed in the context of the GIMP a while ago: https://github.com/AppImage/AppImageKit/issues/396

(Or, maybe even better, not use LD_LIBRARY_PATH at all and instead use something like patchelf to set the rpath on the binaries inside the AppDir so that they know where to load libraries from).

Hope this helps!

[probonopd]

In https://gitlab.gnome.org/GNOME/gimp/-/jobs/3776951/artifacts/file/build/linux/appimage/_Output/GNU_Image_Manipulation_Program-x86_64.AppImage it seems that I no longer get the crash on WSL2, but the find command seems to search outside of the AppImage, which takes forever and eventually fails. Something related to AppRun?

/mnt/c/Users/User$ Downloads/GNU_Image_Manipulation_Program-x86_64.AppImage
/tmp/.mount_GNU_ImGfQWdL/usr/bin/find: ‘./AppData/Local/Temp/WinSAT’: Permission denied

[probonopd]

Commented out this:

#"${LD_LINUX}" --inhibit-cache --library-path "$LD_LIBRARY_PATH" "${HERE}/usr/bin/find" "." "-name" "libgtk-4*"
#if [ $? -eq '0' ]; then
#  case "${DE}" in
#    *GNOME*|*gnome*)
#      export SYSTEM_THEME=$(exec "${LD_LINUX}" --inhibit-cache --library-path "$LD_LIBRARY_PATH" "${HERE}/usr/bin/gsettings" "get" "org.gnome.desktop.interface" "gtk-theme" | exec "${LD_LINUX}" --inhibit-cache --library-path "$LD_LIBRARY_PATH" "${HERE}/usr/bin/sed" "s/'//g")
#      export GTK_THEME=$SYSTEM_THEME
#  esac
#fi

...and we are running on Windows:

[brunvonlope]

Hi, @probonopd. Good to know that the core app is at least initializing. But I see that the plug-ins don't initialize. I plan to try to fix the plug-ins problems soon.

About WSL, please see this discussion: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440#note_2076759

[probonopd]

I understand that you won't spend time on supporting WSL specifically, but maybe you can fix/remove that "find" invocation anyway. For me, running AppImages on FreeBSD (Linuxulator) and Windows is a great way of testing their robustness ;-)

[brunvonlope]

Hi, @probonopd. I will be closing this issue for a more focused discussion on: https://gitlab.gnome.org/GNOME/gimp/-/issues/7661#note_2086877

Thanks to your valorable feedback regarding 'appimagetool -s deploy' position and the necessity of an exec wrapper, I managed to understand and develop an AppImage that works at least for internal testing in the same Debian version used by the CI, which is not a official package yet but it is an first step bigger than you can imagine. See more details on the link above.

Thank you very much!

[probonopd]

Hello @brunvonlope, maybe it would be a good idea to mention the AppImage on https://www.gimp.org/downloads/devel/ - I could imagine this would result in more testers trying out the AppImage. Thanks for your consideration, and thanks for your great work!

[brunvonlope]

Hello @brunvonlope, maybe it would be a good idea to mention the AppImage on https://www.gimp.org/downloads/devel/ - I could imagine this would result in more testers trying out the AppImage. Thanks for your consideration, and thanks for your great work!

After LGM I will do a post on gimp.org explaining the process of constructing the appimage, people involved and how more people can be involved.