Call for testing: Official AppImage

brunvonlope commented 7 months ago

Hi, @ivan-hc. 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.

ivan-hc commented 7 months ago

I'm here, for any doubt

brunvonlope commented 7 months ago

Thanks. What you do to not get any iso-codes or app icon errors? I see that your AppImage output is pretty clean:

Do you use some build-time config or path in apprun?

Our WIP AppImage, however, displays errors regarding iso-codes and app icon:

ivan-hc commented 7 months ago

Mine is not a normal AppImage, it is what I call Archimage, i.e. an Archlinux container into an AppImage, so it come with all it needs to work from the inbuilt arch Linux container.

My workflow depends on the status of the Arch Linux/AUR package, and what you shown is gimp-git, and the AUR package has issues latelly. If you see my latest workflows run, I'm unable to update the daily build because they have an issue about a missing module for Meson.

Latest workflow runs of GIMP-GIT https://github.com/ivan-hc/GIMP-appimage/actions/workflows/GIMP-GIT.yml all failed
From latest comments on AUR this seems to be a known issue https://aur.archlinux.org/packages/gimp-git

About errors, you should check this old AppRun I was using with previous deb-based AppImages:

https://github.com/ivan-hc/GIMP-appimage/blob/main/AppRun

I think you should use these on yours:

export GIMP2_LOCALEDIR="${HERE}"/usr/share/locale/
export GIMP2_DATADIR="${HERE}"/usr/share/gimp/2.0/
export GIMP2_SYSCONFDIR="${HERE}"/etc/gimp/2.0/
export GIMP2_PLUGINDIR="${HERE}"/usr/lib/gimp/2.0/
export GIMP3_LOCALEDIR="${HERE}"/usr/share/locale/
export GIMP3_DATADIR="${HERE}"/usr/share/gimp/2.99/
export GIMP3_SYSCONFDIR="${HERE}"/etc/gimp/2.99/
export GIMP3_PLUGINDIR="${HERE}"/usr/lib/gimp/2.99/
export GEGL_PATH="${HERE}"/usr/lib/x86_64-linux-gnu/gegl-0.4/
export BABL_PATH="${HERE}"/usr/lib/x86_64-linux-gnu/babl-0.1/

and maybe

export PKG_CONFIG_PATH="${HERE}"/usr/share/pkgconfig:$PKG_CONFIG_PATH

I don't use them anymore in my Archimages. All of them have the same, being this a container. All the ones based on JuNest, Arch Linux (Archimage) on this list https://github.com/ivan-hc#my-appimage-packages

brunvonlope commented 7 months ago

Thanks

brunvonlope commented 7 months ago

About the meson error, this is because we added a new gimp-data submodule. This needs to be initialized before building.

ivan-hc commented 7 months ago

About the meson error, this is because we added a new gimp-data submodule. This needs to be initialized before building.

thanks, so should I add other dependences or should I wait that the PKGBUIL is fixed?

ivan-hc commented 7 months ago

however, the way you want build the Appimage is better than mine, mine is a container, so it can't do things such as open a URL in the browser (for now)

brunvonlope commented 7 months ago

thanks, so should I add other dependencies or should I wait that the PKGBUIL is fixed?

Until the downstreamers take some action onto PKGBUILD, you can do: git submodule update --init, before meson, this is enough

ivan-hc commented 7 months ago

I think I'll wait until the upstream packager will patch this PKGBUILD, I often receive warnings about failed workflow run with both gimp-git and gimp-devel (the latter less, seems that the mantainer is more active than the other, also ChaoticAUR uses gimp-devel for its gimp-git package... and this is wrong, in my opinion).

ivan-hc commented 7 months ago

once you're at good point, I suggest to repack the AppImage using this version of appimagetool

https://github.com/probonopd/go-appimage/releases/tag/continuous

I use it for all my AppImages. Advantages:

even smaller sizes, uses a new kind of compression;
all AppImages are what I call (because heard somewhere) "Type3", i.e. no libfuse2 is needed.

Usage:

wget -q $(wget -q $HeaderAuthWithGITPAT https://api.github.com/repos/probonopd/go-appimage/releases -O - | grep -v zsync | grep -i continuous | grep -i appimagetool | grep -i "$(uname -m)" | grep browser_download_url | cut -d '"' -f 4 | head -1) -O appimagetoo
chmod a+x ./appimagetool
ARCH="$(uname -m)" VERSION=$(./appimagetool -v | grep -o '[[:digit:]]*') ./appimagetool -s gimp.AppDir

where gimp.AppDir is the appdir (I guess) of your extracted AppImage

brunvonlope commented 7 months ago

Thanks 🤝. I'm already using it

ivan-hc commented 7 months ago

Hi, I've downloaded the latest release and got stuck at this:

Istantanea_2024-04-04_21-17-14

ivan-hc commented 7 months ago

By running it with LD_DEBUG=libs this is the last part of the long log

     22560: /lib/x86_64-linux-gnu/libxapp.so.1: error: symbol lookup error: undefined symbol: g_string_free_and_steal (fatal)
     22560: gimp-script-fu-interpreter-3.0: error: symbol lookup error: undefined symbol: gtk_progress_get_type (fatal)
Gtk-Message: 21:19:52.646: Failed to load module "xapp-gtk3-module"

brunvonlope commented 7 months ago

Are you sure that isn't libgvfs that is causing the stuckness? We have another tester who noticed the lack of libxapp but this wasn't causing stuckness.

ivan-hc commented 7 months ago

I can only report what I see, I've googled a bit and found that also Inkscape had a similar issue, due to the old Ubuntu build whith which was built their AppImage.

I use Debian Testing, and "libxapp-gtk3-module" and "libxapp1" are installed on the host. Also gvfs-libs/backend/common/daemon/fuse are installed.

ivan-hc commented 7 months ago

I'm trying to tweak your AppRun in several ways since I reported this issue, same message, no way.

May you need to add libgvfsdbus or something? Are you missing an LD_PRELOAD variable to export?

I'm trying also the dirtiest tricks without success.

I also tried to add libunionpreload or tried to share hosts libraries or including PYTHONHOME as a variable... the only thing I can't do is to use the command glib-compile-schemas ./usr/share/glib-2.0/schemas/ || echo "No ./usr/share/glib-2.0/schemas/" that I use in my DEB-based AppImages, because glib-compile-schemas is in conflict with other libraries in Debian Testing, now.

ivan-hc commented 7 months ago

UPDATE: I replaced your AppRun with mine

#!/bin/sh
HERE="$(dirname "$(readlink -f "${0}")")"
export UNION_PRELOAD="${HERE}"
export PATH="${HERE}"/usr/bin/:"${HERE}"/usr/sbin/:"${HERE}"/usr/games/:"${HERE}"/bin/:"${HERE}"/sbin/:"${PATH}"
export LD_LIBRARY_PATH="${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/usr/lib32/:"${HERE}"/usr/lib64/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${HERE}"/lib32/:"${HERE}"/lib64/:"${LD_LIBRARY_PATH}"
export PKG_CONFIG_PATH="${HERE}"/usr/share/pkgconfig:$PKG_CONFIG_PATH
export GIMP2_LOCALEDIR="${HERE}"/usr/share/locale/
export GIMP2_DATADIR="${HERE}"/usr/share/gimp/2.0/
export GIMP2_SYSCONFDIR="${HERE}"/etc/gimp/2.0/
export GIMP2_PLUGINDIR="${HERE}"/usr/lib/gimp/2.0/
export GIMP3_LOCALEDIR="${HERE}"/usr/share/locale/
export GIMP3_DATADIR="${HERE}"/usr/share/gimp/2.99/
export GIMP3_SYSCONFDIR="${HERE}"/etc/gimp/2.99/
export GIMP3_PLUGINDIR="${HERE}"/usr/lib/gimp/2.99/
export GEGL_PATH="${HERE}"/usr/lib/x86_64-linux-gnu/gegl-0.4/
export BABL_PATH="${HERE}"/usr/lib/x86_64-linux-gnu/babl-0.1/
if ! $(exec ${HERE}/usr/bin/gimp "$@" 2> /dev/null); then
    export LD_LIBRARY_PATH=/lib64:/usr/lib:/lib:/usr/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu/:"${HERE}"/usr/lib/:"${HERE}"/usr/lib/i386-linux-gnu/:"${HERE}"/usr/lib/x86_64-linux-gnu/:"${HERE}"/usr/lib32/:"${HERE}"/usr/lib64/:"${HERE}"/lib/:"${HERE}"/lib/i386-linux-gnu/:"${HERE}"/lib/x86_64-linux-gnu/:"${HERE}"/lib32/:"${HERE}"/lib64/:"${LD_LIBRARY_PATH}"
    exec ${HERE}/usr/bin/gimp-2.99 "$@"  2> /dev/null
fi

and worked

it is the same I linked above, but with gimp 2.99 in /usr/bin instead of gimp

https://github.com/ivan-hc/GIMP-appimage/assets/88724353/0d9b3048-24ef-4ecb-a41c-7f9571d974e2

ivan-hc commented 7 months ago

The only issue I had at first start was this

Istantanea_2024-04-04_22-20-41

ivan-hc commented 7 months ago

NOTE: I've also launched it "isolated" (command HOME=./ before I launched it) so it can't use my configuration files :wink:

ivan-hc commented 7 months ago

OK, it was my fault... I had another gimp version installed and the AppImage was taken advantage of it using the if condition at the end of my AppRun

nope, it really does not work

brunvonlope commented 7 months ago

Thanks for noticing the lack of gio (+gvfs). I updated the AppImage. The latest pipeline now contain gio. Also, includes the xapp module.

Also, the first problems that I commented here (not finding iso-codes and appicon) were solved.

brunvonlope commented 7 months ago

About the config folder problem, I would suggest to take a look at the latest comment in the MR, this can be helpful to better understand if it is the same problem: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440#note_2073893

ivan-hc commented 7 months ago

About the config folder problem, I would suggest ot take a look at the latest comment in the MR, this can be helpful to better understand if it is the same problem: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440#note_2073893

Thanks, I know that the issue is related to /etc into the AppImage (I had this too the early days, when I worked with deb packages to build GIMP).

However, I started this new artifact and the issue is still the same:

/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
This is a development version of GIMP.  Debug messages may appear here.

gimp_font_factory_load_names: 78 unsupported fonts were ignored. Set the GIMP_DEBUG_FONTS environment variable for a listing.
set device 'Virtual core XTEST pointer' to mode: disabled
set device 'PIXART USB OPTICAL MOUSE' to mode: disabled
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so

before I tried to include the gvfs-related .deb packages from Debian, but I was stuck until "libgvfsdbus.so" (and the xapp* module).

Also, I noticed that the latest times I had to shut down the PC I had "A Start Job run..." issue that delayed my PC... and an amount od CPU usage... finally I discovered that it was gimp-scriptfu that also eats 70-80% of my CPU.

brunvonlope commented 7 months ago

@ivan-hc The latest commit probably fixed the gvfs warning.

But some systems are complaining about "xdg-run/gvfs". See: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1440#note_2075698

ivan-hc commented 7 months ago

Just tried the last build and still does not work for me, it stucks, this is the normal output:

This is a development version of GIMP.  Debug messages may appear here.

gimp_font_factory_load_names: 78 unsupported fonts were ignored. Set the GIMP_DEBUG_FONTS environment variable for a listing.
set device 'Virtual core XTEST pointer' to mode: disabled
set device 'PIXART USB OPTICAL MOUSE' to mode: disabled

and this is the last part using LD_DEBUG=libs

3476:     trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/sample-colorize/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/sample-colorize/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/screenshot/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/screenshot/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/screenshot/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/script-fu/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/script-fu/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/script-fu/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/script-fu-server/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/script-fu-server/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/script-fu-server/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/selection-to-path/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/selection-to-path/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/selection-to-path/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/smooth-palette/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/smooth-palette/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/smooth-palette/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/sparkle/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/sparkle/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/sparkle/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/sphere-designer/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/sphere-designer/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/sphere-designer/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/tile/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/tile/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/tile/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/tile-small/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/tile-small/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/tile-small/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/unit-editor/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/unit-editor/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/unit-editor/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/van-gogh-lic/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/van-gogh-lic/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/van-gogh-lic/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/warp/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/warp/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/warp/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/wavelet-decompose/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/wavelet-decompose/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/wavelet-decompose/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/web-browser/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/web-browser/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gimp/2.99/plug-ins/web-browser/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/./glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/./glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/./libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gvfs/glibc-hwcaps/x86-64-v3/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gvfs/glibc-hwcaps/x86-64-v2/libgvfscommon.so
      3476:   trying file=/tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gvfs/libgvfscommon.so
      3476: 
      3476: 
      3476: calling init: /tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/../../gvfs/libgvfscommon.so
      3476: 
      3476: 
      3476: calling init: /tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so
      3476: 
      3476: /tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal)
      3476: /tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal)
      3476: /tmp/.mount_GNU_ImLwtBkB/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so: error: symbol lookup error: undefined symbol: g_io_remote_volume_monitor_load (fatal)

the output is too long to find the exact missing library.

ivan-hc commented 7 months ago

My Archimages have only 2 flaws: they have no hardware acceleration and they can't call other applications (for example, they can't open the browser).

The last of these two flaws would also be easy to fix, you would need to find the directories on the host connected to XDG to open applications outside the container. I remember some time ago, with a normal installation of JuNest on Debian, I was able to open other apps installed on the host with Pamac, the graphical frontend of PacMan/YAY.

Only the graphics acceleration would remain to be fixed, but unfortunately I'm alone, and the JuNest developer doesn't seem very convinced in wanting to implement these features, also if there are already similar projects that can do that, for example Conty, WINE AppImage and Distrobox.

I tell you this because Archimages are very simple to compile and have much greater compatibility with the old GNU/Linux distributions, you just need to have at least the 2.6 kernel, which no one uses anymore.

I notice a certain difficulty in trying to compile the Appimage you are trying to create, and in general AppImages are very difficult to create, between environment variables to guess and other mechanisms that instead, using a container, work out of the box.

Since I invented Archimage I have packaged "the impossible", so to speak (GIMP Stable/Dev/GIT, VLC Stable/GIT, MPV, OBS Studio... even Bottles).

It's not a perfect project, but one that needs perfecting, which, I repeat, is difficult when you're alone.

brunvonlope commented 7 months ago

@ivan-hc Your latest stacktrace is very informative. I probably willn't know what to do with it, but depending on how the thing goes some GIMP core dev can take a look to finalize the AppImage. We're not alone :-), at least in GIMP repo.

About the way I choose to make the AppImage: an official package in the GIMP repo needs to follow certain rules (they are listed in the MR description and I personally like them). Anyway, I have a compromisse in only shipping the AppImage if:

it is able to run with all features in the oldest supported Ubuntu (14.04?) and newest (23.10)
it is able to run with all features in the newest supported Fedora (39).

But if it can't be deployed with our Debian runner, I'm fine in giving up.

ivan-hc commented 7 months ago

Don't give up, there are several ways to package AppImages, trust me. Just because the creator of AppImage dictated a method, doesn't mean it's the only way forward. I didn't follow a conventional path, and you see how many AppImages I created.

PS: in this moment I've tried to launch the browser from my AppImge of GIMP and worked. The internal container needed three libraries from JuNest/Arch Linux (gio-launch-desktop, librt.so* and libgtk-*) and now I'm able to launch the browser.

ivan-hc commented 7 months ago

@ivan-hc Your latest stacktrace is very informative. I probably willn't know what to do with it, but depending on how the thing goes some GIMP core dev can take a look to finalize the AppImage. We're not alone :-), at least in GIMP repo.

@brunolopesdsilv Sorry, there was some confusion here (I often use Google Translate). By "being alone" I was referring to me. My packaging method has only me as an assiduous researcher, and only recently someone else participated in the experiments, but nothing significant.

Yet there are many users who use Archimage (for personal use, I guess) https://github.com/ivan-hc/ArchImage

I'm not criticizing your method, it would mean criticizing everyone's, when in fact almost all AppImages, including the ones I use, are made like this, the way you're trying to do it: the classic Appimage's construction.

I'm just saying that my project is one more OPTION, which I think is worth exploring. Just another option, nothing else. If I published it on Github it was to share it with everyone and have it analyzed by those who are more expert than me, and especially from you!

I also wrote this tool for you, hoping to see these days, that are now! When you finally have contacted me!

You say you use Debian as a basis for working on the compatibility of the older and still supported Ubuntu LTS and modern Fedora (for compatibility with GLIBC), I'm using a portable Arch Linux container (with its own GLIBC) and it should work too with distributions dating back more than 10 years.

But the biggest difference is that the AppImage I produced is something I DO NOT INTEND TO KEEP. It is upstream's job to create an official one, until then I can only try to imitate you, but I will never reach your efficiency.

I don't care if everything works in my unofficial AppImage or not, but if I made it (and people appreciated it, it's my most successful AppImage) it's because THIS IS A GIFT THAT I WANT TO GIVE TO YOU, GIMP TEAM, FOR ALL THE AMAZING WORK YOU HAVE DONE SO FAR!

I want you to take care of my creature. I entrust it to you. And if it works more than it should now, I'm happy about that, it will mean there's a lot less work to do. I wanted to push you to create one, and the fact that you and I are talking, here, in my repository, is a huge win! For me and for all users who want an official GIMP AppImage.

I won't stay in software development forever, I don't have the basics, nor a qualification, nor the skills, nor sufficient knowledge to do these things. I have always only worked in supermarkets, at the food counter. What you see here is just a pastime for me, as I am unemployed.

I am honored to have been contacted by you, it was exactly what I wanted: an official AppImage! Made by you!

And as an amateur packager I realized how difficult it is to maintain them, and I am a private citizen, I am not part of your Team or any other project.

I'm not a developer, I'm just someone who wanted to propose an idea to you. And reading "But if it can't be deployed with our Debian runner, I'm fine in giving up"... this really hurts me. It means that I fought in vain to convince you to adopt the AppImage format.

I'm not at all good at compiling from source, if you see my AppImages they are all very simple to create.

I'm rooting for you and I hope you succeed in your endeavor... but please, if you don't succeed, consider other ways. "All roads lead to Rome", right? Don't abandon a goal just because a tree blocks your path, try to go around.

PS: Sorry if I'm so talkative, I really care about the work you are doing, but out of my tools, I don't really know how to help you.

brunvonlope commented 7 months ago

@ivan-hc I didn't mean to express ingratitude with my last sentence, sorry. In short, what I'm saying is that if the packaging format, after all attempts, doesn't allow us to package in our preferred "development-oriented distro", that's a bad sign and I'm not willing to go much further. We could choose another distro or use your scripts, but this doesn't have parity of integration, simplicity and stability. We've seen this story before in our repos (e.g. JHBuild, Jenkins, macOS in part) and it would probably repeat itself again if afferrero's AppImage or yours were somehow merged. I will not develop this last sentence technically to avoid sounding like criticism.

As I am also unemployed and my programming knowledge is very basic (I am a lawyer), I would particularly prefer the format to "dictate" how to make the AppImage rather than this current brainstorming (linuxdeployqt, appimagetool, go-appimagetool, recipes, etc.). I'm making an MS Store version (which will probably be merged this week) and the experience is being well balanced: the tools are dictated by MS (makepri, makeappx and signtool) but they work after all and leave me free to make relatively simple scripts without using Visual Studio .

I must emphasize that, despite the shortcomings the format has, I understand that this is due to historical reasons (it was the first sandbox-like format) and I do not intend to "fight against" the status quo just to say that GIMP have an AppImage. This is due not only to my principles and the quick history of GIMP building that I explained above but also to the fact that some projects did this, were left without a maintainer and the AppImage was (shamefully) discontinued. I hope I don't have to give up, I still have some things to test. In the worst case, the AppImage will only be for internal use in daily builds, so you can propose your scripts for an official AppImage.

brunvonlope commented 6 months ago

Hi, @ivan-hc. 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 gio modules (e.g. gvfs) and the config folder, 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!

Samueru-sama commented 5 months ago

@brunvonlope I took a look and your script for the gimp appimage and noticed some interesting stuff that I think you should know:

You are using go-appimage to deploy the gimp appimage, which is interesting because I've never managed to get go-appimage to deploy a working appimage on my end, as it usually breaks a lib or complains that something is missing, and even when using it as just appimagetool I got it segfault because the AppDir had an svg for an icon.

I instead use linuxdeploy static (not linuxdeployqt) and for gimp you will likely also need to bundle the linuxdeploy-gtk plugin, if you want to get an idea of how that is here is part of the template that I use to make appimages:

ARCH=x86_64
APP=GIMP
APPDIR="$APP.AppDir"
EXEC=gimp
LINUXDEPLOY="https://github.com/linuxdeploy/linuxdeploy/releases/download/continuous/linuxdeploy-static-x86_64.AppImage"
APPIMAGETOOL=$(wget -q https://api.github.com/repos/probonopd/go-appimage/releases -O - | sed 's/"/ /g; s/ /\n/g' | grep -o 'https.*continuous.*tool.*86_64.*mage$')
PLUG="https://raw.githubusercontent.com/linuxdeploy/linuxdeploy-plugin-gtk/master/linuxdeploy-plugin-gtk.sh"

wget "$LINUXDEPLOY" -O linuxdeploy && wget -q "$APPIMAGETOOL" -O ./appimagetool && wget "$PLUG" && chmod a+x ./linuxdeploy ./appimagetool ./*.sh \
&& ./linuxdeploy --appdir "$APPDIR" --plugin gtk --executable "$APPDIR"/usr/bin/"$EXEC" && VERSION="$APPVERSION" ./appimagetool -s ./"$APPDIR"

EDIT: $APPVERSION would be the output of gimp --version btw

I also noticed that you are not using go-appimagetool to make the appimage due to a bug in go-appimagetool, in that case you should be able to just add --output appimage iirc at the end of the linuxdeploy command to also build the appimage at once using its built in legacy appimagetool.

brunvonlope commented 5 months ago

Thanks. I didn't know that linuxdeploy (without the qt suffix) existed. I will make some tests

Samueru-sama commented 5 hours ago

@brunvonlope The reason the current gimp appimage doesn't work outside debian is because the ld-linux.so isn't being called.

The last line in the AppRun has to be like this:

"$HERE"/usr/lib64/ld-linux-x86-64.so.2 "$HERE"/usr/bin/gimp-3.0 "$@" and that's all it took for it to launch of my system.

And also the ld-linux.so didn'tt have exec perms for some reason?

Instead you have this

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc.so.6 "$HERE"/usr/bin/gimp-3.0 "$@"

With that said, I don't know if there was a specific reason to preload the libc library like that.

brunvonlope commented 2 hours ago

@Samueru-sama Originally, the .appimage had that code so was allowed to open in other distros but suddenly this made it get stuck on Debian so I removed the portable code and added the preloading: https://gitlab.gnome.org/GNOME/gimp/-/commit/bad250429c1e7eb11d08e15dd8e188be21cfadb0

Recently (some weeks ago), I tested the portable and observed that Debian didn't got stuck so I will revert this commit.

ivan-hc / GIMP-appimage

Call for testing: Official AppImage #21