Is it possible to use pkg2appimage for Arch Linux packages?

[ivan-hc]

Some minutes ago I've published a script named arch-deployer. It is not much, but I know that you can made better than this. It would be nice to implement a support for Arch Linux packages in pkg2appimages because I've tried linuxdeployqt but it requires an older system to work. My goal is to have more recent software into my AppImages, all for more bleeding edge distributions.

[probonopd]

Currently it does not support Arch packages. If someone wants to implement it, I'd be open to that if it breaks nothing.

[daiyam]

pkg2appimage was working fine on arch until the release of glib2 2.70 (I think). I can make it work by cloning the repo and executing the script pkg2appimage. But, when executing the resulting AppImage, I'm still getting the error codium: symbol lookup error: /usr/lib/libgio-2.0.so.0: undefined symbol: g_module_open_full related to that glib library... :imp:

[knarfS]

pkg2appimage was working fine on arch until the release of glib2 2.70 (I think).

I've opened a PR that should fix this problem :)

[daiyam]

@knarfS With the PR, I'm still getting the error codium: symbol lookup error: /usr/lib/libgio-2.0.so.0: undefined symbol: g_module_open_full.

[daiyam]

I was able to make it work by removing the folder usr/lib/x86_64-linux-gnu generated in the AppDir. I will test if the AppImage generated on Ubuntu is still working on Arch...

[knarfS]

Removing libgmodule-2.0.so.0* from usr/lib/x86_64-linux-gnu should be enough, because that's what causes the issue. I've linked a very in depth analysis of the problem in the PR. The analysis also mentions other workarounds.

Unfortunately, I don't know how the execludelist is used in the pkg2appimage scripts exactly, but it's is also used by linuxdeploy and linuxdeployqt and the generated AppImages suffer from the same error.

[daiyam]

Removing libgmodule-2.0.so.0* from usr/lib/x86_64-linux-gnu should be enough, because that's what causes the issue. I've linked a very in depth analysis of the problem in the PR. The analysis also mentions other workarounds.

I tried but it doesn't because then I get the error codium: symbol lookup error: /usr/lib/libtracker-sparql-3.0.so.0: undefined symbol: sqlite3_expanded_sql

[daiyam]

By removing that folder, the AppImage can run on Arch, Fedora and Ubuntu when it has been built on Ubuntu 18.04.

[probonopd]

The proper solution is to build the ingredients that go into the AppImage on an older system. The other workarounds may cause other binary incompatiblities.

You can run grep -r g_module_open_full your.AppDir to find out which file(s) try to use the "too new" symbol. These were made on "too new" a system.

[daiyam]

The proper solution is to build the ingredients that go into the AppImage on an older system.

This is why I've tested with the AppImage built with Ubuntu 18.04 which use glib2 2.17.

[probonopd]

So that is the way to go.

Just because technically pkg2appimage can run on Arch Linux, it doesn't mean that doing so makes any sense. Because Arch Linux packages are generally built for "too new" systems.

[daiyam]

The main issue is that the AppImage built on Ubuntu 18.04 (without my hack) doesn't run on newer Arch or Fedora (https://github.com/VSCodium/vscodium/issues/854, https://github.com/VSCodium/vscodium/issues/919). pkg2appimage is one of the AppImage impacted by the incompatibility of glib2 or other libs.

[probonopd]

So newer versions and Arch or Fedora cannot run AppImages that are running fine on older versions or Arch and Fedora? That would be a serious issue we'd need to investigate then.

[probonopd]

https://github.com/project-slippi/Ishiiruka/issues/323 contains an analysis of what is causing and issue and a workaround. Please let me know whether the workaround works for you, then we should probably add libgmodule-2.0.so to the excludelist.

[daiyam]

On Arch, some old AppImages aren't working anymore.. I've tested Fedora 34 and 35 with the latest AppImage (of Codium) and I have the issue.

We have tried different workaround: https://github.com/VSCodium/vscodium/issues/854 When libgmodule/glib2 are patched, we are getting errors due to libsqlite3 or libffi.

[daiyam]

I've retested several distros and contrary to my previous statement, Fedora 34 doesn't have the issue.

Here the result:

VSCodium	Arch	Fedora 34	Fedora 35	openSUSE Leap 15.2	openSUSE Tumbleweed	Ubuntu 18.04.5 LTS	Ubuntu 21.10
VSCodium-1.56.2.glibc2.16	✅	✅	✅	✅	✅	✅	✅
VSCodium-1.57.1.glibc2.17	❌	✅	❌	✅	❌	✅	✅
VSCodium-1.58.2.glibc2.17	❌	✅	❌	✅	❌	✅	✅
VSCodium-1.58.2.glibc2.17	❌	✅	❌	✅	❌	✅	✅
VSCodium-1.59.1.glibc2.17	❌	✅	❌	✅	❌	✅	✅
VSCodium-1.60.2.glibc2.17	❌	✅	❌	✅	❌	✅	✅
VSCodium-1.61.2.glibc2.17	❌	✅	❌	✅	❌	✅	✅
VSCodium-1.62.3.glibc2.17	❌	✅	❌	✅	❌	✅	✅
VSCodium-1.63.2.glibc2.17	❌	✅	❌	✅	❌	✅	✅
VSCodium-1.63.2-hacked.glibc2.17	✅	✅	✅	✅	✅	✅	✅

VSCodium-1.63.2-hacked.glibc2.17 is VSCodium-1.63.2.glibc2.17 without usr/lib/x86_64-linux-gnu Since 1.57.0, the latest pkg2appimage is used to build the appimage (https://github.com/VSCodium/vscodium/pull/731)

Not sure if it can help...

[probonopd]

VSCodium-1.63.2-hacked.glibc2.17 is VSCodium-1.63.2.glibc2.17 without usr/lib/x86_64-linux-gnu

WIthout the whole directory and all libraries inside it?

I am interested in what happens if you remove only libgmodule-2.0.so.

[daiyam]

Removing libgmodule-2.0.so.0* from usr/lib/x86_64-linux-gnu should be enough, because that's what causes the issue. I've linked a very in depth analysis of the problem in the PR. The analysis also mentions other workarounds.

I tried but it doesn't because then I get the error codium: symbol lookup error: /usr/lib/libtracker-sparql-3.0.so.0: undefined symbol: sqlite3_expanded_sql

[daiyam]

I will try to pinpoint which lib is causing the issue...

[daiyam]

grep -r g_module_open_full . doesn't give any result.

Removing libgmodule-2.0.so, give me: codium: symbol lookup error: /usr/lib/libtracker-sparql-3.0.so.0: undefined symbol: sqlite3_expanded_sql Then removing libsqlite3.so, the app is running.

The libsqlite3 is weird. On my system and AppRoot both have a libsqlite3.so.0.8.6 lib. The AppRoot's one doesn't have the symbol sqlite3_expanded_sql in it (grep sqlite3_expanded_sql libsqlite3.so.0). While the one on my system does have the symbol...

• Arch:

squashfs-root $ ldd usr/share/codium/codium | grep gio
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f49d674a000)
squashfs-root $ ldd usr/share/codium/codium | grep sqlite3
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007fdfae363000)

• Ubuntu 18.04/21.10

squashfs-root $ ldd usr/share/codium/codium | grep gio
libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f245229e000)
squashfs-root $ ldd usr/share/codium/codium | grep sqlite3

• Fedora 35

squashfs-root $ ldd usr/share/codium/codium | grep gio
libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f2432312000)
squashfs-root $ ldd usr/share/codium/codium | grep sqlite3
libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007fbb49857000)

[ivan-hc]

Hi folks, I've finally completed Arch-deployer, you can get a try by downloading the script.

https://github.com/ivan-hc/Arch-Deployer

Usage

1. Download the script:

   wget https://raw.githubusercontent.com/ivan-hc/Arch-Deployer/main/arch-deployer

2. Made the script executable:

   chmod a+x ./arch-deployer

3. Run the script by adding the name of the program (for example $PROGRAM), this way:

   ./arch-deployer $PROGRAM

At the end of the process, all the packages will be extracted and the folders placed into an .AppDir directory, so you can work on an AppImage.

After this all you have to do is to add the AppRun, the launcher and the icon. I hope you enjoy it.

[probonopd]

Hi @ivan-hc please test your AppImages on at least Ubuntu bionic. Only AppImages that can run there (or whatever is the oldest still-supported version of Ubuntu at any given point in time) are considered to be working. Just because you can generate an AppImage that runs on Arch does not magically mean it is a "good" AppImage that can run on all still-supported Linux distributions and pass the tests for https://appimage.github.io/. So please consider doing some binary compatibility testing with different (especially older) distributions. Thanks!

[ivan-hc]

Hi @probonopd , this is just a script I have provided, not an AppImage, so those who want to create AppImages with this will be the testers. I'm not submitting AppImages nowhere. So consider Arch Deployer another helper with wich people can try to create AppImages (just like pkg2appimage), regardless of the version of the operating system. If they then want to add it to AppImageHub or to any other third-party repository, also if dedicated only to GNU/Linux distributions with more recent libraries and not for older distributions, it will be only their choice.

PS: you said that the advantage of AppImage is that everyone is free to use multiple versions of the same program, and I agree, that's great, I love AppImage (and I really hate Snaps/Flatpaks)... but personally I prefer to use the latest version of the programs, with or without compatibility with the Ubuntu version from the year 2018. Maybe the version I want to use won't be good for Ubuntu 18.04, but at least it will be good for me and others aiming to stay up to date. Ubuntu itself releases an LTS version every two years, the next Ubuntu 22.04 LTS will be released in a few months, but the shenario is that we linux users represent just over 1-2% of the PC desktop/laptop market and can choose from over 270 distributions still active, so why on earth an Ubuntu user in 2022 should rely on the 2018 LTS and not on a 20.04 release, a Linux Mint, a Manjaro, a Debian Stable... given the evolution of technology, multimedia and hardware support? This would make sense on servers, but I haven't seen many AppImage pointing to that kind of work, and shell-based command line tools are the basic and universal language in GNU / Linux.

[daiyam]

@probonopd Were my feedbacks useful?

[probonopd]

@daiyam generally I cannot recommended to use "rolling" distributions like Arch Linux packages as input for AppImages, because they are ususally built on far too new systems and as a result the AppImages are broken on some still-supported Linux distritbutions, especially Enterprise and LTS ones. As a general rule, I recommend to build the ingredients for AppImages on the oldest still-supported Ubuntu LTS or CentOS.

[daiyam]

@probonopd All my tests were done with AppImages built on Ubuntu 18.04. Even then, the AppImages weren't running on Fedora, openSUSE or Arch. Maybe I should move my issue to a new one...

[sign-out]

Still an issue as far as I am seeing also with images from 20.04 dont seem to work on arch/Manjaro specifically

[ivan-hc]

ArchImage solves this issue https://github.com/ivan-hc/ArchImage

The apps are built including JuNest, lightweight version of Arch Linux. This means that the app will work standalone, the minimal requirement of the host is a Linux kernel not lower than 2.6 (are you still using it?).

I've already built some ArchImages this way:

• Abiword https://github.com/ivan-hc/Abiword-appimage
• Gnumeric https://github.com/ivan-hc/Gnumeric-appimage
• Handbrake https://github.com/ivan-hc/Handbrake-appimage
• MPV https://github.com/ivan-hc/MPV-appimage
• OBS Studio https://github.com/ivan-hc/OBS-Studio-appimage

You're free to test them.

On the contrary of classic workflow with pkg2appimage and deb2appdir or other similar tools using .deb packages... all we have to do is not to guess the right environment variable or files needed. The AppImage (or ArchImage) is ready! All you have to do is to remove all unneeded stuff from the final package.

NOTE, this works on Linux... but seems not to work on freeBSD.

I think I can close this. Thank you for partecipating.