AppImage OBS Integration

Creating AppImages
1

JFYI and because probono asked for a discussion here. I have some kind of support added to OBS (http://www.openbuildservice.org) for building AppImage files.

What is working:

Not yet working:

  • Builds based on debian packages
  • Direct support of the meta .yml files for converting packages without the need of compiling them. Esp. useful when just new maintenance/security updates of used libraries shall get repackaged.
  • Both depends also on some cleanup/refactoring work to make our code more generic. Hopefully we can find a way for a more generic approach for offline builds.

Any feedback welcome :slight_smile:

2

Hi @adrianS and welcome to AppImage. Great to have you here.

I think OBS and AppImage are made for each other. What users like about application bundles like AppImage is that they can get an application directly from an original author’s download page, and run it without having to deal with repositories, without needing root rights, and without changing any of the system-provided libraries. AppImage gives upstream application authors the ability to reach end users directly, without going through the normal distribution process. But as always, with great power comes great responsibility: With application bundles like AppImage, the person who puts together the AppImage needs to take care that all the ingredients (e.g., executables, but also shared libraries) are updated. This can be tedious to do by hand, but luckily proven distribution mechanisms exist for doing exaxtly this, and OBS can make these very mechanisms accessible for building AppImages.

So, I think your contribution is very valuable.

Converting .AppImage files out of rpms during build of rpm.

This means that for all the applications already being built on OBS today, there is an easy way to additionally provide AppImages, which is great.

a Recipe file is optional for AppImage specific things

This should be documented a bit, using examples. I tried to get away from telling people to “just write a bash script” to using more formalized yml files, and a generic “meta” recipe that uses the variables defined in the yml file to do the actual conversion. It would be cool if the same yml file format could be used for both ppa/deb-to-AppImage and for (new) obs-repo/rpm-to-AppImage conversions.

Signing of AppImage files

Does this work automagically because OBS already has a GPG key for each user?

Publishing of AppImage files

Cool. :slight_smile:

Update zsync stuff is WIP

Excellent. I think this is actually a very important, yet often-overlooked piece to the application bundle story. Having binary delta (zsync based) updates that are super easy for both the person creating the AppImage as well as for users is key. Heck, one could even imagine that once a security update for libfoo comes out, OBS automagically rebuilds all the AppImages that use it (that’s what I mean when I say “OBS can bring the power of existing distribution tools to application bundles”).

Now, what could I imagine to make this even more useful?

  • Make the oldest still-supported LTS the default for building the ingredients that go into an AppImage. The reason is that not all dependencies should go into an AppImage, only those that cannot reasonably be expected to be part of the target system(s) in a recent enough version. Technically, the person who makes the AppImage can decide which “target systems” to consider. For all practical reasons, I recommend to target the oldest still-supported LTS distributions. The resulting AppImages will run on distributions no older than the build system used for compiling the ingredients. CentOS 6 could be a suitable choice, because it is a very mature system (read: old glibc and friends) but recent compilers are still available for it through Software Collections. I don’t know what the SUSE/openSUSE equivalent for this is, but something like it (or debian oldstable?) would definitely be good candidates.
  • Remove the requirement to (also) build rpm/deb packages (which can be more tedious at times than necessary for “just” generating an AppImage).
  • Automatically feed the metadata about the generated AppImages into AppStream feeds, so that sites like http://linux-appimages.org/ could pick it up easily in an automated way.
3

Projects can have own GPG keys which are used for signing.

1 Like
4

Some more observations:

  • There are already many example AppImages at https://download.opensuse.org/repositories/home:/adrianSuSE:/AppImage/openSUSE_Leap_42.1/
  • The server should be configured to send headers that make the browser save AppImages as files, rather than trying to display their contents in the browser
  • The first AppImage I (randomly) picked, basket5-2.50+git20160311.9c363a1_3.4.glibc2.2.5-x86_64.AppImage, runs well for me on KDE neon useredition
  • I’d love to see something like SLES_11 as the default rather than openSUSE_Leap_42.1 (reason)
  • AppStream AppImage has no *.desktop file and hence does not launch. Is it even an application, after all?
  • ./subsurface-4.6.2_7.5.glibc2.17-x86_64.AppImage --appimage-signature gives binary gibberish. Why?
  • As for naming the AppImage files, I recommend to use the value of the Name= key in the *.desktop file, with blanks replaced by “_”, followed by -$VERSION.glibc$GLIBC_NEEDED-$ARCH.AppImage

The following things likely need a bit of fine-tuning, the kind of stuff that I also encounter when doing new AppImages.

  • Companion asks “Do you want to download release 2.1.9 (2016-09-14) now ?” - I am running 2.1.9…
  • FreeCAD-0.16_13.2.glibc2.2.5-x86_64.AppImage: error while loading shared libraries: libFreeCADGui.so: cannot open shared object file: No such file or directory. Idea: resolve all dynamic libraries at build time and put in rpaths as needed
  • librepilot-.glibc2.14-x86_64.AppImage This application failed to start because it could not find or load the Qt platform plugin "xcb". - make sure to check linuxdeployqt for deploying Qt apps, it does some neat trickery to prevent things like this
  • xz-5.2.3-107.6.x86_64.AppImage Error: No .desktop files found, that was to be expected. You’d need to put in one, with Terminal=true.
  • clementine-1.3.1_102.2.glibc2.14-x86_64.AppImage: error while loading shared libraries: libprotobuf.so.11: cannot open shared object file: No such file or directory
5

I wrote the non-ascii version of the signature … fixed (but no rebuild of images yet)

1 Like
6

I tried to use linuxqtdeploy briefly, but it just tells me that a distro Qt is not supported

7

I just got rid of rpath in FreeCAD rpm build to avoid other problems … hm, maybe I will try some LD_LIBRARY_PATH hacks first …

8

I would love to support the .yml files more direct: parsing the build dependencies and maybe also parsing git URLs and downloading source. That way we can still achieve a full offline and reproducable build while still be able to reference external resources.

My snap(craft) support from last years hackweek followed this approach.

9

This is mainly because I haven’t invested the time to implement Patch hardcoded absolute qt_ paths · Issue #79 · probonopd/linuxdeployqt · GitHub yet. For the Ubuntu on Travis CI (which I have been mainly using so far) everyone uses the beineri Qt for /opt ppa anyway, so I didn’t see a good use case so far. This might change now… :slight_smile:

I’ve been trying linuxdeployqt on some real-world Qt-based applications with success, a list is here.

10

I have to admit I don’t know much about Snapcraft and how it works, but I would not be surprised at all if much of it would be applicable to generating AppImages just as well as for snaps.

11

PulseView does not launch, at least not on systems where Qt is not installed on the host:

me@host:~$ /home/me/Downloads/pulseview-0.3.0_17.2.glibc2.14-x86_64.AppImage 
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Reinstalling the application may fix this problem.
Aborted

(A subset of) usr/lib/qt*/ is missing.

In contrast, the Subsurface one has usr/lib64/qt5/plugins/platforms/libqxcb.so and is working.

12

Started a more systematic howto at https://github.com/probonopd/AppImageKit/wiki/Using-Open-Build-Service. Edits welcome!

1 Like
13

Let’s check if we can make use of the Snapcraft yaml format for defining buliding from source. Looks easier than writing spec files, at least on the surface…

https://build.opensuse.org/package/view_file/home:adrianSuSE:snappy/git/snapcraft.yaml?expand=1

14

This is super interesting!

So with OBS as a build server, could the OBS repo be added to sources list for updates? I know it wouldn’t be able to install the updates but could it keep track of updates and version data for notifications.

I think AppImages are great but they dont have update notifications so maybe this could solve that.

15

The idea with AppImages is that the information about where to get updates from travels inside of the AppImage itself, so that users do not need to manage repository URLs on the client. Please check AppImageUpdate, which is the tool that can use this information to do the updates.

1 Like
17

I understand somewhat how the Update system of AppImages work but am I correct in saying that AppImages do not support Update Notifications? I saw the cool KDE Service video so you can easily update but what about being notified that there is an update in the first place?

18

The client has to ask the server whether there is a newer version available. This could be scripted to be done in regular intervals.

19

Yea that could work. I’m mostly wondering if it would be possible to have update notifications like most package managers offer so people who’ve gotten used to that approach don’t need to implement both the Windows manual way and the Linux typical repo way.

20

It could be implemented, e.g., as a plugin for GNOME Software etc., but I am unlikely to implement it since I am not interested in using the system’s infrastructure at all. I just want to download the latest version directly from the upstream software author’s download page.

Check the Subsurface AppImage, for example, it contains a check for the latest version within the application, totally independent from the distribution. I’d rather like to see something like that, combined with AppImageUpdate delta binary updates.

21

I understand that. I wasn’t suggesting implementation with system stuff more an automation method.

Yea the Delta updates sound like they would be amazing.

Regarding the updating, does Subsurface support auto-notifying of updates or is it manual?

I dont care if I have to engage with the update itself, I just dont want to have to manually check.

For example, if an AppImage checks for an update on run-time or occasionally like once every few runs then that would be fine and it could show a message like “there is an update available for this appimage”. Then I could manually run the update process.

The only issue I have is people might not check if it is left to do it manually . . . well to be honest most people wont check at all especially people who aren’t tech savvy at all.