"Nightly" demo AppImage for QGIS by converting .deb packages from their '2.99' nightly repository?

[KurtPfeifle]

QGIS is currently preparing their 3.0 release, which is a heavily re-factored new version using Qt5.

It looks like the developers are open to offer AppImage builds, once they get some help. I saw they provide a repository of 2.99 "nightly" builds for various Ubuntu and Debian versions: https://qgis.org/ubuntugis-nightly/

Hence it should be quite easy to use these for automatic AppImage creation, similar to how it is done by LibreOffice, and there would be a good chance for the QGIS community to eventually take over maintenance.

I'm interested in working on this, but in the next two months I've extremely little additional time. Maybe this "issue" triggers someone else to start working on it?

---

^{(I've also a personal interest in getting a QGIS AppImage which makes use of the semi-automatic zsync2 "delta" update mechnism. QGIS is a beast, size-wise: if you want all bells and whistles it's around 500 MByte of .deb downloads, and usually I'm on a very slow internet connection...)}

[probonopd]

Added https://github.com/AppImage/AppImages/blob/master/recipes/QGIS.yml

[KurtPfeifle]

Thanks!!!

And let me tell you this: I'm totally stunned, puzzled, stumbed, baffled, flummoxed, amazed, flabbergasted, astounded, dumbfounded, blownaway, perplexed, astounded, consternated, stupefied, bamboozled and gobsmacked about how fast this was implemented (and how easy it seems to have been for you).... 1/2

[KurtPfeifle]

2/2

...however, this recipe did build a QGIS version 2.0.1 'Dufour' for me, dated as released on Monday September 0, 2013 and built against Qt-4.8.6.

This is a bit un-expected.

What I did:

• Git clone https://github.com/AppImage/AppImages
• Running 'bash -ex ./pkg2appimage recipes/QGIS.yml' from inside my local repo clone.

Seems I simply had mis-read what the QGIS folks announce here: https://qgis.org/en/site/forusers/alldownloads.html#debian-ubuntu when I expected to get a 2.99 pre-release.

However, with that repo I'm still confused why I do get a v2.0.1 QGIS AppImage: After all, the repo holds v2.1.17 Debian packages in https://qgis.org/ubuntugis-nightly/pool/main/q/qgis/ and no v2.0.1 ones?

So what was going on? Did it fetch the .debs from the official Ubuntu Trusty repos, or what? (I cannot scroll back in the terminal to see the build process output messages, which were too long; and re-building isn't an option now due to slow internet connection...)

[probonopd]

OK, maybe this line is wrong:

https://github.com/AppImage/AppImages/blob/fe8e2980d0989f79dedbd1fd755b772dda34b1d9/recipes/QGIS.yml#L7

But the QGIS documentation doesn't tell me in clear terms what to put in there...

[KurtPfeifle]

@probonopd:

I created (locally) a QGIS-xenial.yml file, which has all mentions of 'trusty' replaced by 'xenial' and run this instead. (Because in https://qgis.org/ubuntugis-nightly/pool/main/q/qgis/ there are v2.99 .debs tagged carrying 'xenial' in their names).

Took more than 80 minutes to complete (due to slow downloading)... Instead of a

QGIS_Desktop-2.0.1.glibc2.14-x86_64.AppImage

it created a

QGIS_Desktop-2.0.1.glibc2.15-x86_64.AppImage...

[KurtPfeifle]

BTW, question: why is AppImageAssistant still being used here?

https://github.com/AppImage/AppImages/blame/master/functions.sh#L188

I thought that app is deprecated?

[probonopd]

BTW, question: why is AppImageAssistant still being used here?

generate_appimage() is deprecated as well, we should use generate_type2_appimage() these days everywhere.

[probonopd]

I created (locally) a QGIS-xenial.yml file, which has all mentions of 'trusty' replaced by 'xenial'

Currently trusty is the oldest still-supported LTS version, and hence is the recommended baseline version for AppImages. Using xenial ingredients means that the AppImage will not run on systems older than Xenial.

[KurtPfeifle]

"Currently trusty is the oldest still-supported LTS version, and hence is the recommended baseline version for AppImages. Using xenial ingredients means that the AppImage will not run on systems older than Xenial."

Yes, I know...

But YOU seem to have missed my statements where I hint at the contents of https://qgis.org/ubuntugis-nightly/pool/main/q/qgis/ : there, there are v2.99 QGIS .debs for Xenial only, but none for Trusty.

• That's what made me theorize that my resulting AppImage (an old v2.0.1) might have been built with ingredients from the standard Debian repo, not from the ubuguntis-nightly repo...
• That's why I tried it with the *-xenial variant in the hope it would build there at least. That hope was in vain. (I wouldn't care about older-than-Xenial systems in this case anyway, because I just wanted a proof of concept and wouldn't try to distribute that specific AppImage, only use it privately...)

In any case there is some issue which makes the build process NOT use ingredients from the named ubuguntis-nightly repo.

[probonopd]

there are v2.99 QGIS .debs for Xenial only, but none for Trusty

Then we cannot build an AppImage that would run on trusty from those ingredients; at least not without bundling every single dependency, down to and including glibc.

That's why I tried it with the *-xenial variant in the hope it would build there at least.

Did you also change

https://github.com/AppImage/AppImages/blob/fe8e2980d0989f79dedbd1fd755b772dda34b1d9/recipes/QGIS.yml#L6

to Xenial? (I have never tried to do this since I want my AppImages to run on all still-supported versions of Ubuntu.)

[KurtPfeifle]

Yes, I also changed my local recipes/my-QGIS.yml file to refer to "xenial main universe".

[probonopd]

I see. Currently I cannot give a solution because I have never tried to use Xenial ingredients for pkg2appimage; it may well not be working at the moment. It is not recommended, and I am not interested in using Xenial ingredients because I am not interested in producing AppImages that cannot run on systems older than Xenial.

The proper solution is to compile on trusty.

[Lvaskz]

Any progress?

[probonopd]

Please ask the QGIS project. We are happy to help them if they have questions on where to start or encounter difficulties using our tools.