Is it possible to use pkg2appimage for Arch Linux packages?

Question

Is it possible to use pkg2appimage for Arch Linux packages?

ivan-hc opened this issue 3 years ago · 27 comments

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.

Answer 1 · 2021-09-22T19:19:23.000Z

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

Answer 2 · 2021-11-30T11:46:37.000Z

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... 👿

Answer 3 · 2021-12-17T13:21:09.000Z

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 :)

Answer 4 · 2021-12-17T18:21:45.000Z

@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.

Answer 5 · 2021-12-17T19:04:18.000Z

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...

Answer 6 · 2021-12-17T19:13:00.000Z

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.

Answer 7 · 2021-12-17T20:03:12.000Z

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

Answer 8 · 2021-12-17T22:16:43.000Z

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

Answer 9 · 2021-12-18T10:43:17.000Z

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.

Answer 10 · 2021-12-18T10:53:24.000Z

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.

Answer 11 · 2021-12-18T10:55:33.000Z

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.

Answer 12 · 2021-12-18T11:03:15.000Z

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

Answer 13 · 2021-12-18T14:44:54.000Z

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.

Answer 14 · 2021-12-18T14:55:32.000Z

project-slippi/Ishiiruka#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.

Answer 15 · 2021-12-18T15:05:07.000Z

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: VSCodium/vscodium#854
When libgmodule/glib2 are patched, we are getting errors due to libsqlite3 or libffi.

Answer 16 · 2021-12-19T14:51:46.000Z

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 (VSCodium/vscodium#731)

Not sure if it can help...

Answer 17 · 2021-12-19T21:58:50.000Z

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.

Answer 18 · 2021-12-20T00:52:34.000Z

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

Answer 19 · 2021-12-20T00:53:56.000Z

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

Answer 20 · 2021-12-20T10:10:57.000Z

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)

Answer 21 · 2021-12-30T19:01:20.000Z

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

Download the script:

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

chmod a+x ./arch-deployer
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.

Answer 22 · 2022-01-02T11:38:39.000Z

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!

Answer 23 · 2022-01-15T11:30:08.000Z

@probonopd Were my feedbacks useful?

Answer 24 · 2022-01-15T12:13:17.000Z

@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.

Answer 25 · 2022-01-15T13:55:49.000Z

@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...

Answer 26 · 2022-06-09T20:17:38.000Z

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

Answer 27 · 2023-07-15T16:55:48.000Z

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.