applications using ubuntu-app-platform should exclude Qt libraries from their snap

[dinamic]

xenial + overlay

$ snap info ubuntu-app-platform
name: ubuntu-app-platform
summary: "Ubuntu app platform for running apps on a shared platform of libraries"
publisher: canonical
description: |
  Ubuntu app platform is an optional package your app can use to minimize the
  disk space the app takes. The platform offers you shared content which
  includes Qt 5.6.2 with Ubuntu's backported fixes, Ubuntu UI Toolkit, PIM
  libraries and Oxide web browser engine among else.

  It is recommended to use the associated cloud part desktop-ubuntu-app-platform
  to make the usage easy. Note that for developing a package targeting to use
  ubuntu-app-platform, you will need to use Ubuntu 16.04 LTS added with the
  "stable-phone-overlay" PPA which includes the newer Qt and other packages!
tracking: edge
installed: 1 (26) 157MB -
refreshed: 2017-01-27 15:18:59 +0200 EET
channels:
  stable: 1 (22) 154MB -
  candidate: 1 (26) 157MB -
  beta: 1 (26) 157MB -
  edge: 1 (26) 157MB -

ubuntu-terminal-app edge: 0.11 (33) 21MB devmode
camera-app edge: 3.0.0+17.04.20170106-0ubuntu1 (11) 61MB devmode
ubuntu-filemanager-app edge: 0.4 (11) 34MB devmode

when trying to "snap run ubuntu-terminal-app" (or camera etc) i get

Cannot mix incompatible Qt library (version 0x50602) with this library (version 0x50601)
Aborted (core dumped)

[Ted Gould (ted)]

Happened with Dekko as well. Had to revert the ubuntu-app-platform version.

[Andrew Hayzen (ahayzen)]

Added ubuntu-app-platform to the bug, for me this affects many snaps and now requires a rebuild of them:
- mediaplayer-app
- ubuntu-calculator-app
- ubuntu-docviewer-app
- ubuntu-filemanager-app
- ubuntu-terminal-app
- volleyball2d

[Timo Jyrinki (timo-jyrinki)]

Stable channel is now back to #22 (last version with Qt 5.6.1).

The check in question is on the upstream side, and is a bit unfortunate given that there should not be any compatibility issues.

This should AFAIK only be visible if some Qt _module_ is not recompiled. QA tested xenial overlay based arm64 image fine where no-change compilations were done to eg qtmir, qtubuntu which are Qt modules.

So maybe it's just that eg Unity 8 snap should be fully refreshed based on overlay PPA contents?

[Timo Jyrinki (timo-jyrinki)]

So just to give the summary:

- Qt 5.6.2 has been overlay PPA since Friday, when QA finished testing it (deb based xenial+overlay on frieza_arm64 and desktop)
- ubuntu-app-platform #22 remained in stable channel until today (and is again the version in stable channel), which was built before overlay PPA was upgraded
- ubuntu-app-platform #26 is a no-change rebuild to refresh binaries from overlay PPA, with Qt 5.6.2

I can think of following possible mismatches, which are different:
1. When using Unity 8 snap, some eg Mir QPA module is/was still built against Qt 5.6.1 so when #26 got into stable things started not working.
2. When using deb based xenial+overlay Unity 8 and running snap apps, right now if the system is fully upgraded #26 would be _required_ as only #26 is what matches the current overlay contents. On #22 one would get Qt 5.6.2 rebulds of QPA modules from overlay but some 5.6.1 content from platform snap.

Can someone support or not these theories?

So I think there is a missing bit somewhere that should be recompiled against Qt 5.6.2 still (or simply allow new binaries from overlay PPA to be staged), after which the #26 platform snap should actually be declared stable.

As long as there are multiple sources for QPA modules instead of eg ubuntu-app-platform providing them all, there is room for problems if not everything is upgraded at the same time.

[Dan Chapman  (dpniel)]

Could this also be because of Qt libraries being in the application snap? and these are taking priority over the Qt libs in the ubuntu-app-platform? See the content's of the Dekko snap here http://paste.ubuntu.com/23894123/. lines 364-374

I see there are libraries for QtCore etc which I presume are brought in by snapcraft's ld crawling? Which at the time of packaging the overlay ppa was still on 5.6.1.

[Dan Chapman  (dpniel)]

I see vollyball2d is also shiiping a fair amount of 5.6.1 qt libraries in it's snap as well.

[Ted Gould (ted)]

On Mon, 2017-01-30 at 15:26 +0000, Timo Jyrinki wrote:
> So I think there is a missing bit somewhere that should be recompiled
> against Qt 5.6.2 still (or simply allow new binaries from overlay PPA
> to
> be staged), after which the #26 platform snap should actually be
> declared stable.
>
> As long as there are multiple sources for QPA modules instead of eg
> ubuntu-app-platform providing them all, there is room for problems if
> not everything is upgraded at the same time.
>
I think that it's not the QPA modules as much as the other libraries
that are pulled into the snap along with building it.
It seems like any update to Qt will require a name change of the snap
so that they can be installed in parallel to allow apps to use the one
they need.

[Cris Dywan (kalikiana)]

> Could this also be because of Qt libraries being in the application snap?
> and these are taking priority over the Qt libs in the ubuntu-app-platform?
> See the content's of the Dekko snap here http://paste.ubuntu.com/23894123/. lines 364-374

What snap is "the" Dekko snap here? It's not in the store. Does it use the ubuntu-app-platform as a plug? There should be none if those libQt5*.so in there if it's using it.

[Cris Dywan (kalikiana)]

> What snap is "the" Dekko snap here?

Answering my own questions:
Was bitten by snap's misleading false negative again, "snap install --edge --devmode dekko" does install Dekko.
So yes, Dekko's using uap, and so something's wrong with the snapping because it has a load of libQt5*.so files in there.

[Timo Jyrinki (timo-jyrinki)]

We need to update apps that are supposed to be using ubuntu-app-platform to not ship their own Qt libraries. Ideally of course somehow it would be autodetected to not ship any of the libraries that exist in ubuntu-app-platform, but that would need feature development in tools.

For now, maybe add prime: entries with items like "- -usr/lib/$ARCH/libQt5*" for exclusion?

[Andrew Hayzen (ahayzen)]

But what about that apps that *do* need to ship Qt libraries that aren't within the ubuntu-app-platform? How will these work?

For example, I've been working on the printing, and at the moment this isn't within the ubuntu-app-platform (it probably will be later, but this is just an example), so I'm having to add a dependency on libqt5printsupport5. This then brings in the specific version of that library, and as an app developer I would expect my snap to *always* work. So it seems that the ubuntu-app-platform needs a version bump every time the qt version is bumped to prevent this?

[Timo Jyrinki (timo-jyrinki)]

@Andrew Those apps should not use ubuntu-app-platform since they ship their own. There's no use for ubuntu-app-platform if the app ships its own libraries. But if ubuntu-app-platform is in use, one shouldn't mix a module from different Qt version and a module from ubuntu-app-platform's version.

ubuntu-app-platform should be expanded to include what's generally needed within Qt 5.6 series, so that only applications that require newer Qt like 5.7 or 5.9 ship their own Qt. Definitely all modules from Qt Base source like print support belong in the platform snap.

I've just confirmed that ubuntu-terminal-app also ships its own Qt version.

[Pat McGowan (pat-mcgowan)]

From the mailing list

request:
if my snap uses other snaps via content-sharing, the providing snaps would be automatically unpacked during the build and used to satisfy depends so the libs are not copied into my snap
reply:
This is why I told the SDK team to build a "release tarball" of whatever their framework is, with this people would just `after` it and it would just work. This will avoid the need for adding build packages equivalent to those of whatever that snap provides or for you guys to depend on a PPA to be able to build.

[Pat McGowan (pat-mcgowan)]

Also

>> There is a way around that, but it’s rather counter-intuitive and
>> error-prone: add the packages containing those libs to the list of
>> stage-packages, then explicitly exclude them from the resulting snap
>> using the prime/snap keyword. You won’t be able to exclude them if you
>> didn’t include them through the stage packages first.
>
> Isn't this what Kyle fixed by adding build-attributes: [no-system-libraries] ?
>
> http://snapcraft.io/docs/build-snaps/syntax#parts

Yes, that seems to be it, indeed. Thanks for the pointer Leo, I wasn’t
aware of this new feature. With this, no need to artificially add
stage packages. Neat!

[Cris Dywan (kalikiana)]

For reference, snaps using no-system-libraries successfully now:

https://git.launchpad.net/dekko/commit/?id=e90a5606e0841cb9ab2b9997a4a3889f128954c1
https://github.com/kalikiana/quassel/commit/6676e32ad08d97b7cc17fde9b6f7e032d73d0743

[Timo Jyrinki (timo-jyrinki)]

I can also confirm ubuntu-terminal-app is now fixed with commit http://bazaar.launchpad.net/~ubuntu-terminal-dev/ubuntu-terminal-app/trunk/revision/350 - starts with both stable and edge channel ubuntu-app-platform.

[Timo Jyrinki (timo-jyrinki)]

Terminal now fixed too.

[Timo Jyrinki (timo-jyrinki)]

(rev 42)