Neon/Snap: Difference between revisions
< Neon
No edit summary |
|||
| Line 22: | Line 22: | ||
and install suitable packages for the current content-snap SDK. By and large this is optional though. | and install suitable packages for the current content-snap SDK. By and large this is optional though. | ||
To build | 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> | ||
Building is done by running {{Input|1=<nowiki>snap run snapcraft --destructive-mode</nowiki>}} | |||
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 == | == Snapd Problems == | ||
| Line 33: | Line 32: | ||
(upstream issues ought to be filed/subscribed to and mentioned here) | (upstream issues ought to be filed/subscribed to and mentioned here) | ||
# Theming [is kind of addressed by XDG Settings portal] | |||
# Theming | |||
## How to get theme settings from the host into the snap? | ## 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 | ## QtStyles are binary plugins and so even when we know which style is configured on the host we cannot just load it | ||
| Line 53: | Line 48: | ||
### gdb/valgrind/strace need to be in the snap to be reachable | ### 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? | ## 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 | # 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 | ## we are lacking appstream ids, useful for de-duplication | ||
| Line 65: | Line 56: | ||
## https://bugs.launchpad.net/snapcraft/+bug/1711333 | ## 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 | ## https://forum.snapcraft.io/t/use-a-separate-manifest-file-or-save-everything-in-snap-snapcraft-yaml/1152 | ||
== Snapcraft Problems == | == Snapcraft Problems == | ||
| Line 73: | Line 61: | ||
## Talking with snapcraft developers, they suggested using "install: ctest ." much like in here: https://snapcraft.io/docs/build-snaps/node | ## Talking with snapcraft developers, they suggested using "install: ctest ." much like in here: https://snapcraft.io/docs/build-snaps/node | ||
## Implemented here: https://cgit.kde.org/scratch/apol/kf5-snap-env.git/plain/README.md | ## Implemented here: https://cgit.kde.org/scratch/apol/kf5-snap-env.git/plain/README.md | ||
# Content snap has problems | # Content snap has problems | ||
## Make sure that on cleanbuilds we get the deps from the Neon repo instead of ubuntu (for the things Neon implements) | ## Make sure that on cleanbuilds we get the deps from the Neon repo instead of ubuntu (for the things Neon implements) | ||
| Line 83: | Line 70: | ||
### https://github.com/snapcore/snapcraft/issues/1694 | ### 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. | ## 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] | # 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] | ||
Revision as of 09:52, 3 April 2019
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]
- 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
- Icon themes in /usr/share and ~/.local cannot be accessed from inside snaps
- Same for mouse cursor themes
- Same for fonts
- upstream is aware and working on it
- https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1585332
- Hard to debug applications
- We have huge wrapper scripts that are required for applications to run properly
- 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
- https://forum.snapcraft.io/t/support-for-appstream-id/2327
- No source code storage/retrieval for snaps
Snapcraft Problems
- No real way to run unit tests through snapcraft
- Talking with snapcraft developers, they suggested using "install: ctest ." much like in here: https://snapcraft.io/docs/build-snaps/node
- Implemented here: https://cgit.kde.org/scratch/apol/kf5-snap-env.git/plain/README.md
- Content snap has problems
- 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
- Lack of Appstream support
- 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.
- 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]