Allow global autoconnect kde-frameworks-5-qt-5-14-core18

store-requests
1

Please allow global autoconnect kde-frameworks-5-qt-5-14-core18.

This is a content Snap created by KDE but use in building KDE applications and includes Qt and KDE libraries.

We have recently rebuilt it using Qt 5.14.1, core18 and the latest KDE Frameworks and do not plan further rebuilds (we will create a new one on core20 at the appropriate time).

3 Likes
2

Just a drive-by observation: in the accompanying sdk snap, the KF5 modules have .pri files with absolute and unconfigurable paths in them:

cat ./usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_KAuth.pri
[...]
QT.KAuth.includes = /usr/include/KF5/KAuth
QT.KAuth.private_includes =
QT.KAuth.libs = /usr/lib/x86_64-linux-gnu
[...]

Whereas the corresponding cmake files respect _IMPORT_PREFIX. The Qt modules do also respect $$QT_MODULE_INCLUDE_BASE in their .pri files.

So that’s a bit hard to use as a build-snap with qmake and without symlinking tricks and the like. Is that even considered a bug and where would one file such an issue?

Edit: If someone comes across this and is interested in a dirty little workaround: introduce a part that sets up the build environment by copying the sdk’s contents over /:

kde-sdk-setup:
    plugin: nil
    build-snaps:
      - kde-frameworks-5-qt-5-14-core18-sdk
    build-packages:
      - g++
      - mesa-common-dev
      - libglvnd-dev
      - rsync
    override-build: |
      rsync -a --ignore-existing /snap/kde-frameworks-5-qt-5-14-core18-sdk/current/ /
3

Yes, file bugs on bugs.kde.org product neon

4

Thank you for making this request.

@reviewers - while kde-frameworks-5-qt-5-14-core18 does not follow our current guidelines for naming, which is typically <thing>-<version>-<ABI-hint>, I don’t think that is a problem. To date, this has not been an issue since the KDE team is free to name their private content anything they want.

The snapcraft.yaml does use this for the content attributes in its slot declarations:

  • content: kde-frameworks-5-68-qt-5-14-core18
  • content: kde-frameworks-5-qt-5-14-core18-all

If creating the snap anew today before it had any consumers, we might instead recommend ‘s/core18/1804/’ for consistency with other globally connected content snaps, but I don’t recommend this here because a) ‘core18’ reflects the base snap in use, b) this conveys “Ubuntu 18.04” at least as well as the alternative and c) there is a lot of developer and snap momentum with the existing naming.

Put simply, the name of the snap and the value of the “content” attribute in the two slots of the snap are conveying everything we require IMO.

@jriddell - rebuilds of this snap would be fine so long as they don’t break ABI, remove files, etc (ie, do anything that might break a 3rd party consumer). By your statement, I think the answer to this next question is implied, but I need to ask this explicitly: can you or someone authoritative as the KDE publisher comment on the stability of the libraries, APIs, ABIs, etc of this snap and provide any additional information related to the promise of updates to this snap not breaking 3rd party publishers?

@jriddell - you mentioned creating a new snap using core20, will this use something like the following in its snapcraft.yaml (name, base and content attribute are the key points where ‘X’, ‘Y’, ‘Z’ and ‘N’ are at your discretion):

name: kde-frameworks-X-qt-Y-Z-core20
base: core20
slots:
  kde-frameworks-X-N-qt-Y-Z-core20:
    content: kde-frameworks-X-N-qt-Y-Z-core20
    interface: content
    ...

?

Thanks!

5

can you or someone authoritative as the KDE publisher comment on the stability of the libraries, APIs, ABIs, etc of this snap and provide any additional information related to the promise of updates to this snap not breaking 3rd party publishers?

Yes, the Qt and KDE libraries used have script ABI and API stability but there’s a few addons in this content snap which could in theory break that such as libkexiv, so we will ensure that if we do need to rebuild it we’ll be mindful to check that there’s no changes to ABI or API.

Yes I can use that naming schema for the core20 content snap when we make it if you think that’s the best one.

3 Likes
6

Thanks!

+1 for global auto-connect.

@reviewers - can others please vote?

2 Likes
7

+1 for global auto-connect from me, too.

2 Likes
8

+1 from me for global auto-connect

2 Likes
9

3 votes for, 0 against. Granting global auto-connect to this snap for both “kde-frameworks-5-68-qt-5-14-core18” and “kde-frameworks-5-qt-5-14-core18-all”. This is now live.

1 Like