# AppImage OBS Integration

**URL:** <https://discourse.appimage.org/t/appimage-obs-integration/153>\
**Category:** Creating AppImages\
**Created:** [February 27, 2017, 6:26pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153 "2017-02-27T18:26:28Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![adrianS](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/adrians/32/46_2.png) [@adrianS](https://discourse.appimage.org/u/adrianS)\
**Post date:** [February 27, 2017, 6:26pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/1 "2017-02-27T18:26:28Z")

</div>

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

What is working:

- Converting `.AppImage` files out of rpms during build of rpm. A `.spec` file is needed, a `Recipe` file is optional for AppImage specific things. ([https://build.opensuse.org/package/show/home:adrianSuSE:AppImage/rpm2appimage](https://build.opensuse.org/package/show/home:adrianSuSE:AppImage/rpm2appimage))
- Signing of AppImage files ([https://github.com/openSUSE/obs-sign/pull/9](https://github.com/openSUSE/obs-sign/pull/9))
- Publishing of AppImage files (Example: [https://download.opensuse.org/repositories/home:/adrianSuSE:/AppImage/openSUSE\_Leap\_42.1/](https://download.opensuse.org/repositories/home:/adrianSuSE:/AppImage/openSUSE_Leap_42.1/))
- Update zsync stuff is WIP
- A base project just providing the basic packages exists here ([https://build.opensuse.org/project/show/OBS:AppImage](https://build.opensuse.org/project/show/OBS:AppImage))

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 🙂

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [February 27, 2017, 7:17pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/2 "2017-02-27T19:17:59Z")

</div>

> [@adrianS](#):
>
> I have some kind of support added to OBS ([http://www.openbuildservice.org](http://www.openbuildservice.org)) for building AppImage files.

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

> 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/](http://linux-appimages.org/) could pick it up easily in an automated way.

---

<div class="post-metadata">

**Author:** ![adrianS](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/adrians/32/46_2.png) [@adrianS](https://discourse.appimage.org/u/adrianS)\
**Post date:** [February 27, 2017, 8:36pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/3 "2017-02-27T20:36:25Z")

</div>

> [@probono](#):
>
> Signing of AppImage files
> 
> Does this work automagically because OBS already has a GPG key for each user?

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

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [February 27, 2017, 9:01pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/4 "2017-02-27T21:01:09Z")

</div>

Some more observations:

- There are already many example AppImages at [https://download.opensuse.org/repositories/home:/adrianSuSE:/AppImage/openSUSE\_Leap\_42.1/](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](https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages#creating-portable-appimages))
- 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](http://mindonmind.github.io/notes/linux/change_rpath.html)
- `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](https://github.com/probonopd/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`

---

<div class="post-metadata">

**Author:** ![adrianS](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/adrians/32/46_2.png) [@adrianS](https://discourse.appimage.org/u/adrianS)\
**Post date:** [February 28, 2017, 5:36pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/5 "2017-02-28T17:36:33Z")

</div>

> [@probono](#):
>
> ./subsurface-4.6.2\_7.5.glibc2.17-x86\_64.AppImage --appimage-signature gives binary gibberish. Why?

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

---

<div class="post-metadata">

**Author:** ![adrianS](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/adrians/32/46_2.png) [@adrianS](https://discourse.appimage.org/u/adrianS)\
**Post date:** [February 28, 2017, 5:37pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/6 "2017-02-28T17:37:50Z")

</div>

> [@probono](#):
>
> ibrepilot-.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

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

---

<div class="post-metadata">

**Author:** ![adrianS](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/adrians/32/46_2.png) [@adrianS](https://discourse.appimage.org/u/adrianS)\
**Post date:** [February 28, 2017, 5:42pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/7 "2017-02-28T17:42:18Z")

</div>

> [@probono](#):
>
> 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

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 …

---

<div class="post-metadata">

**Author:** ![adrianS](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/adrians/32/46_2.png) [@adrianS](https://discourse.appimage.org/u/adrianS)\
**Post date:** [February 28, 2017, 5:45pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/8 "2017-02-28T17:45:47Z")

</div>

> [@probono](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [February 28, 2017, 8:45pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/9 "2017-02-28T20:45:23Z")

</div>

> [@adrianS](#):
>
> I tried to use linuxqtdeploy briefly, but it just tells me that a distro Qt is not supported

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

I’ve been trying `linuxdeployqt` on some real-world Qt-based applications with success, a list is [here](https://github.com/probonopd/linuxdeployqt/issues/81#issuecomment-282431960).

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [February 28, 2017, 8:47pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/10 "2017-02-28T20:47:05Z")

</div>

> [@adrianS](#):
>
> My snap(craft) support from last years hackweek followed this approach.

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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [March 2, 2017, 7:19am UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/11 "2017-03-02T07:19:16Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [March 5, 2017, 9:59pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/12 "2017-03-05T21:59:34Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [March 6, 2017, 8:27am UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/13 "2017-03-06T08:27:51Z")

</div>

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](https://build.opensuse.org/package/view_file/home:adrianSuSE:snappy/git/snapcraft.yaml?expand=1)

---

<div class="post-metadata">

**Author:** ![MichaelTunnell](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/michaeltunnell/32/51_2.png) [@MichaelTunnell](https://discourse.appimage.org/u/MichaelTunnell)\
**Post date:** [March 13, 2017, 9:46pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/14 "2017-03-13T21:46:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [March 16, 2017, 12:44pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/15 "2017-03-16T12:44:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![MichaelTunnell](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/michaeltunnell/32/51_2.png) [@MichaelTunnell](https://discourse.appimage.org/u/MichaelTunnell)\
**Post date:** [March 17, 2017, 8:01am UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/17 "2017-03-17T08:01:33Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [March 17, 2017, 4:49pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/18 "2017-03-17T16:49:08Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![MichaelTunnell](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/michaeltunnell/32/51_2.png) [@MichaelTunnell](https://discourse.appimage.org/u/MichaelTunnell)\
**Post date:** [March 18, 2017, 7:12pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/19 "2017-03-18T19:12:03Z")

</div>

> [@probono](#):
>
> The client has to ask the server whether there is a newer version available. This could be scripted to be done in regular intervals.

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.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [March 19, 2017, 9:17am UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/20 "2017-03-19T09:17:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![MichaelTunnell](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/michaeltunnell/32/51_2.png) [@MichaelTunnell](https://discourse.appimage.org/u/MichaelTunnell)\
**Post date:** [March 19, 2017, 5:41pm UTC](https://discourse.appimage.org/t/appimage-obs-integration/153/21 "2017-03-19T17:41:50Z")

</div>

> [@probono](#):
>
> 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.

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

> [@probono](#):
>
> 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.

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.

[Next page](https://discourse.appimage.org/t/appimage-obs-integration/153.md?page=2)