Neon/Snap: Difference between revisions

Latest revision as of 06:04, 21 September 2023

Note

This page has old content. See page history.

2023 Status

Snaps are now build in invent.kde.org, see the https://invent.kde.org/packaging/snapcraft-kde-applications/ repo. They use KDE neon packages.

Reading Material

Snap & Snapcraft Documentation: https://docs.snapcraft.io
Snap Guide: Guidelines_and_HOWTOs/Snap
Content Snap: Neon/Snap/KF5Content

Usage

To use them

https://apachelog.wordpress.com/2017/01/30/kde-applications-in-ubuntu-snap-store/

sudo snap install kblocks

No sudo

To drop the requirement to have to sudo everything you need to login using ubuntu login credentials first.

sudo snap login

After that you should have a ~/.snap/auth.json file and snap should work without sudo.

Building

The snapcraft.yamls we have in our packaging repositories are generally meant to be built via our tooling and the respective Jenkins jobs. Generally they can however also be built manually as the tooling only extends them a bit to build from git and install suitable packages for the current content-snap SDK. By and large this is optional though.

To build you need a working snapd (for containerized use LXD is recommended because it has native systemd support). You'll also want latest snapcraft: snap install --classic snapcraft

Building is done by running

snap run snapcraft --destructive-mode

It's destructive because it needs to change your system. By default snapcraft since 2019 would try to throw builds in a VM, since snaps mostly need neon's repos to build that isn't useful for us in its current form.

Snapd Problems

(upstream issues ought to be filed/subscribed to and mentioned here)

Theming [is kind of addressed by XDG Settings portal]
1. How to get theme settings from the host into the snap?
2. QtStyles are binary plugins and so even when we know which style is configured on the host we cannot just load it
3. Icon themes in /usr/share and ~/.local cannot be accessed from inside snaps
4. Same for mouse cursor themes
5. Same for fonts
6. upstream is aware and working on it
7. https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1585332
Hard to debug applications
1. We have huge wrapper scripts that are required for applications to run properly
  1. https://cgit.kde.org/scratch/apol/kf5-snap-env.git/tree/
  2. https://forum.snapcraft.io/t/custom-environment-variables-for-parts/1639/10
2. It's hard to reach out to debugging tools
  1. should be easy-ish to use gdb-server
  2. gdb/valgrind/strace need to be in the snap to be reachable
3. Possibly needs a way to catch and send cores and then retrace them server-side with (externally) generated debug symbol dumps?
Discover Software Center integration isn't at the level of PackageKit or Flatpak. Mostly boils down to some appstream support
1. we are lacking appstream ids, useful for de-duplication
2. cannot use snaps for the featured applications list (apps are listed as appstream ids)
3. AppStream ID as id for reviews https://forum.snapcraft.io/t/best-way-to-key-a-snap-for-reviewing/854/2
4. https://forum.snapcraft.io/t/support-for-appstream-id/2327
No source code storage/retrieval for snaps
1. https://bugs.launchpad.net/snapcraft/+bug/1711333
2. https://forum.snapcraft.io/t/use-a-separate-manifest-file-or-save-everything-in-snap-snapcraft-yaml/1152

Snapcraft Problems

No real way to run unit tests through snapcraft
1. Talking with snapcraft developers, they suggested using "install: ctest ." much like in here: https://snapcraft.io/docs/build-snaps/node
2. Implemented here: https://cgit.kde.org/scratch/apol/kf5-snap-env.git/plain/README.md
Content snap has problems
1. Make sure that on cleanbuilds we get the deps from the Neon repo instead of ubuntu (for the things Neon implements)
2. Related https://bugs.kde.org/show_bug.cgi?id=385062
3. https://bugs.launchpad.net/snapcraft/+bug/1719928
Lack of Appstream support
1. Substantial metadata duplication. snap metadata excessively duplicates appstream metadata such as license, summary, version, icon. Makes it undesirable to maintain the data in snapcraft.yaml so it will simply go out of date at some point.
  1. https://forum.snapcraft.io/t/extracting-existing-data-from-projects-to-feed-into-snap-yaml/2285
  2. https://github.com/snapcore/snapcraft/issues/1694
2. Should be extracting the icon and desktop file from the package. Now it's copied in the packaging.
GPG verification of incoming content is not supported. This breaks the signing chain from tag -> tarball -> pkg -> user. Only applies to tarballs. [Supposedly the tarball is somewhere in the build tree, so we could build custom rigging to download the gpg after snapcraft ran and verify the tarball snapcraft got is the signed one and abort if not]

@@ Line 1: / Line 1: @@
+{{Note|This page has old content. See page history.}}
 __TOC__
+== 2023 Status ==
+Snaps are now build in invent.kde.org, see the https://invent.kde.org/packaging/snapcraft-kde-applications/ repo.  They use KDE neon packages.
+== Reading Material ==
+* Snap & Snapcraft Documentation: https://docs.snapcraft.io
+* Snap Guide: [[Guidelines_and_HOWTOs/Snap]]
+* Content Snap: [[Neon/Snap/KF5Content]]
 == Usage ==
@@ Line 7: / Line 19: @@
 https://apachelog.wordpress.com/2017/01/30/kde-applications-in-ubuntu-snap-store/
 {{Input|1=<nowiki>
-sudo snap install kde-frameworks-5
 sudo snap install kblocks</nowiki>}}
-ISOs from August 11 2017 already come shipped with kde-frameworks-5, this is a simple tar made by Jonathan by using a freshly installed virtual machine, running sudo snap install kde-frameworks-5 and putting /snap, /var/lib/snap and /var/snap into a tar http://embra.edinburghlinux.co.uk/~jr/snapd-kde-frameworks.tar.gz It adds about 600MB to the images.
 === No sudo ===
@@ Line 22: / Line 31: @@
 == Building ==
-The snapcraft.yamls we have in our pacakging repositories are generally meant to be built via our tooling and the respective Jenkins jobs. Genearally they can however also be built manually as the tooling only extends them a bit to build from git
+The snapcraft.yamls we have in our packaging repositories are generally meant to be built via our tooling and the respective Jenkins jobs. Generally they can however also be built manually as the tooling only extends them a bit to build from git
 and install suitable packages for the current content-snap SDK. By and large this is optional though.
-To build run
+To build you need a working snapd (for containerized use LXD is recommended because it has native systemd support).  You'll also want latest snapcraft:  <code>snap install --classic snapcraft</code>
-{{Input|1=<nowiki>
-SNAPCRAFT_PARTS_URI=http://metadata.neon.kde.org/snap/parts.yaml snapcraft</nowiki>}}
+Building is done by running {{Input|1=<nowiki>snap run snapcraft --destructive-mode</nowiki>}}
-The environment variable sets a different remote parts URI to load the -dev and -env parts from. Long term these should be
+It's destructive because it needs to change your system. By default snapcraft since 2019 would try to throw builds in  a VM, since snaps mostly need neon's repos to build that isn't useful for us in its current form.
-added to the upstream default parts.yaml though.
 == Snapd Problems ==
@@ Line 36: / Line 44: @@
 (upstream issues ought to be filed/subscribed to and mentioned here)
-# Content snap not getting installed if snap depending on it gets installed https://bugs.launchpad.net/snapcraft/+bug/1711329
+# Theming [is kind of addressed by XDG Settings portal]
-# Installing a content snap into the core ISO requires snapd which requires systemd which cannot (?) run in a docker/lxc/chroot
-## current solution is to tar up /snap etc and extract that when generating the ISO.
-## This needs the tar to be easy/automatically updated
-## Needs openQA tests that it still works
-# Theming
 ## How to get theme settings from the host into the snap?
 ## QtStyles are binary plugins and so even when we know which style is configured on the host we cannot just load it
@@ Line 47: / Line 50: @@
 ## Same for mouse cursor themes
 ## Same for fonts
-# There are no debug snaps making debugging of crashes nigh impossible. Possibly needs a way to catch and send cores and then retrace them server-side with (externally) generated debug symbol dumps?
+## upstream is aware and working on it
-# xdg-desktop-portals (with patches) + snapd (with patches). Needs landing or something
+## https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1585332
-## FIleIO
+# Hard to debug applications
-## Printing
+## We have huge wrapper scripts that are required for applications to run properly
+### https://cgit.kde.org/scratch/apol/kf5-snap-env.git/tree/
+### https://forum.snapcraft.io/t/custom-environment-variables-for-parts/1639/10
+## It's hard to reach out to debugging tools
+### should be easy-ish to use gdb-server
+### gdb/valgrind/strace need to be in the snap to be reachable
+## Possibly needs a way to catch and send cores and then retrace them server-side with (externally) generated debug symbol dumps?
 # Discover Software Center integration isn't at the level of PackageKit or Flatpak. Mostly boils down to some appstream support
 ## we are lacking appstream ids, useful for de-duplication
 ## cannot use snaps for the featured applications list (apps are listed as appstream ids)
 ## AppStream ID as id for reviews https://forum.snapcraft.io/t/best-way-to-key-a-snap-for-reviewing/854/2
-# No source code storage/retrieval for snaps https://bugs.launchpad.net/snapcraft/+bug/1711333
+## https://forum.snapcraft.io/t/support-for-appstream-id/2327
-# Dolphin and kfileopen are cluttered with loopback mounts from snapd  https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1714941
+# No source code storage/retrieval for snaps
+## https://bugs.launchpad.net/snapcraft/+bug/1711333
+## https://forum.snapcraft.io/t/use-a-separate-manifest-file-or-save-everything-in-snap-snapcraft-yaml/1152
 == Snapcraft Problems ==
-# No real way to run unit tests through snapcraft (do we need to?)
+# No real way to run unit tests through snapcraft
-# Content snap has "external" dev tarball which we utilize to build snaps off of the content snap, problem is that snapcraft does not like files diverging, so whenever a snap stages-packages something that is in the dev tarball (e.g. as part of a runtime dep) but binary different (e.g. newer build) the snapcraft will fail. On auto generated snaps this was worked around by maintaining an exclusion list of packages to not install, this may be auto-injectable into manual builds BUT won't be doable for non-infrastructure builds (i.e. a dev running snapcraft on their system).
+## Talking with snapcraft developers, they suggested using "install: ctest ." much like in here: https://snapcraft.io/docs/build-snaps/node
-# snapcraft does not work easily on non-apt-based systems
+## Implemented here: https://cgit.kde.org/scratch/apol/kf5-snap-env.git/plain/README.md
-## Further investigation on LXD-based builds is required.
+# Content snap has problems
-# Content snap makes development super hard! A locally installed snap cannot connect to the content snap if it was installed from the store, conversely, a locally installed content snap cannot be used by snaps installed from the store. So, either everything needs to be installed locally or through the store, the store round trip makes development of new snaps a right chore and lengthens the feedback cycle considerably. Possible workarounds include maintaining fully-standalone snapcraft.yaml files and having the CI tooling mangle it to base it on the content snap for store uploads.
+## Make sure that on cleanbuilds we get the deps from the Neon repo instead of ubuntu (for the things Neon implements)
 ## Related https://bugs.kde.org/show_bug.cgi?id=385062
 ## https://bugs.launchpad.net/snapcraft/+bug/1719928
-# Substantial metadata duplication. snap metadata excessively duplicates appstream metadata such as license, summary, version, icon. Makes it undesirable to maintain the data in snapcraft.yaml so it will simply go out of date at some point.
+# Lack of Appstream support
-# Excessive data duplication for the setup/gui/ directories. As snapcraft has no ability to pull desktop files and/or icons out of the stage itself one needs to manually keep copies of the relevant artefacts in the setup/gui/ directory for snapcraft to pick them up. This is extremely meh and unsustainable without extra code that grabs and updates the desktop file from somewhere as the file contains translations which change/grow all the time.
+## Substantial metadata duplication. snap metadata excessively duplicates appstream metadata such as license, summary, version, icon. Makes it undesirable to maintain the data in snapcraft.yaml so it will simply go out of date at some point.
-# Icons do not appear to get installed into hicolor nor hardcoded absolute paths in the desktop files, making icon availability entirely theme-dependent.
+### https://forum.snapcraft.io/t/extracting-existing-data-from-projects-to-feed-into-snap-yaml/2285
+### https://github.com/snapcore/snapcraft/issues/1694
+## Should be extracting the icon and desktop file from the package. Now it's copied in the packaging.
 # GPG verification of incoming content is not supported. This breaks the signing chain from tag -> tarball -> pkg -> user. Only applies to tarballs. [Supposedly the tarball is somewhere in the build tree, so we could build custom rigging to download the gpg after snapcraft ran and verify the tarball snapcraft got is the signed one and abort if not]
+== Other Problems ==
+# kdoctools requires docbook-* packages in /usr always https://bugs.kde.org/show_bug.cgi?id=406177