This repository was archived by the owner on Aug 5, 2022. It is now read-only.
meta-flatpak: a flatpak layer with basic flatpak support. #188
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
klihub
force-pushed
the
flatpak-layer
branch
2 times, most recently
from
d995870 to
7774bec
Compare
klihub
force-pushed
the
flatpak-layer
branch
8 times, most recently
from
f5db01d to
2074439
Compare
klihub
changed the title
mythi
reviewed
Jun 16, 2017
| ##OEROOT##/../meta-security-isafw \ | ||
| ##OEROOT##/../meta-intel-realsense \ | ||
| ##OEROOT##/../meta-clang \ | ||
| ##OEROOT##/../meta-flatpak \ |
Contributor
There was a problem hiding this comment.
This justifies LCONF_VERSION bump.
Contributor
Author
Contributor
Contributor
There was a problem hiding this comment.
Hmm... even 26ee25f is not enough. For some reason the bblayer.conf incompatiblity goes unnoticed and bitbake fails with missing flatpak.inc (since I don't have meta-flatpak enabled)
Contributor
|
On Fri, 2017-06-16 at 01:04 -0700, Mikko Ylinen wrote:
@mythi commented on this pull request.
______________________________________________________________________
In meta-refkit/conf/bblayers.conf.sample:
> @@ -20,6 +20,7 @@ REFKIT_LAYERS = " \
##OEROOT##/../meta-security-isafw \
##OEROOT##/../meta-intel-realsense \
##OEROOT##/../meta-clang \
+ ##OEROOT##/../meta-flatpak \
This justifies LCONF_VERSION bump.
Beware that LCONF_VERSION needs to be bumped to 8 unless we get my
OE-core patch "bblayers sanity: bblayers.conf.sample specific update
code" merged first.
See
pohly@8806100
|
pohly
reviewed
Jun 16, 2017
meta-flatpak/conf/layer.conf
Outdated
| LAYERDEPENDS_flatpak-layer = "core openembedded-layer filesystems-layer" | ||
|
|
||
| # Set a variable for easy access to the top directory of the flatpak layer. | ||
| FLATPAK_LAYERDIR = '${@os.path.normpath("${LAYERDIR}/../meta-flatpak")}' |
Contributor
There was a problem hiding this comment.
Why not just '${@os.path.normpath("${LAYERDIR}")}' ?
Contributor
Author
There was a problem hiding this comment.
Good point, fixed this one.
Closed
klihub
force-pushed
the
flatpak-layer
branch
3 times, most recently
from
a792458 to
4a81b55
Compare
Currently the ROS image (genmsg in particular) fails to build if usrmerge DISTRO_FEATURE is enabled. Therefore we only inherit refkit-image if it is not, letting the image recipe degenrate to a NOP otherwise. Yuck... and sorry. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Flatpack based refkit application framework demands merging of root
folders(/bin, /sbin, /lib*) to their /usr counterparts. This requires the
changes to default bitbake configuration to point all base_{lib,bin,sbin}dir
variables to /usr.
Signed-off-by: Amarnath Valluri <amarnath.valluri@intel.com>
Prepare the root symlinks required for runtime at the time of rootfs creation. The assumption is that in usrmerged distro, no package installs files in /bin,/sbin and /lib* folders. Upstream Patches: http://lists.openembedded.org/pipermail/openembedded-core/2017-February/133166.html Signed-off-by: Amarnath Valluri <amarnath.valluri@intel.com>
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
… latter. Move inclusion of usrmerge.inc from meta-refkit/conf/distro/refkit.conf to meta-refkit-core/conf/distro/include/enable-refkit.conf. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Get rid of conflicting /usr/sbin/nologin when usrmerge DISTRO_FEATURE is enabled and also refkit-config. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
quilts autodetection of awk seems to incorrectly pick up gawk (haven't checked but I guess from the host) even when we don't have gawk enabled. Override autodetection by manually setting it to /usr/bin/awk, if refkit-config distro override is on. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
pohly
reviewed
Jun 16, 2017
| DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} ${REFKIT_DEFAULT_DISTRO_FEATURES}" | ||
|
|
||
| require conf/distro/include/usrmerge.inc | ||
| require conf/distro/include/flatpak.inc |
Contributor
There was a problem hiding this comment.
enable-refkit-config.inc must be usable even when meta-flatpak is not used (because meta-refkit-core and thus enable-refkit-config.inc must be usable without that layer).
This is causing the "bitbake fails with missing flatpak.inc" error.
Try "include conf/distro/include/flatpak.inc" instead.
Contributor
Author
There was a problem hiding this comment.
Interesting. All the tests passed in my test build without any such failures (at least I did not stop any). I don't want to interfere now/any more with Mikkos release attempts if he's willing to take this as such, but I change these to includes and do queue them for my next PR.
Contributor
Author
There was a problem hiding this comment.
Okay, changed the require to an include.
Added meta-flatpak layer and bumped LCONF_VERSION to 8. Here is an apt explanation of why bumping directly to 8 is necessary from Patrick Ohly <patrick.ohly@intel.com> who discovered the problem. """ Version numbers >= 4 and <= 7 have a special meaning in OE-core's sanity.bbclass in the code which updates bblayers.conf. We inherit that code and cannot disable it (currently; patch for OE-core in preparation). By bumping directly to 8 we ensure that the OE-core update code at least eventually aborts and prints the desired error message (for some reasons, twice). However, the output now is a bit confusing when updating from bblayers.conf with version 4: NOTE: Your conf/bblayers.conf has been automatically updated. NOTE: Your conf/bblayers.conf has been automatically updated. NOTE: Your conf/bblayers.conf has been automatically updated. ERROR: Your version of bblayers.conf has the wrong LCONF_VERSION (has 7, expecting 8). Please compare your file against bblayers.conf.sample and merge any changes before continuing. "meld conf/bblayers.conf /fast/work/intel-iot-refkit//meta-refkit/conf/bblayers.conf.sample" is a good way to visualise the changes. ERROR: Your version of bblayers.conf has the wrong LCONF_VERSION (has 7, expecting 8). Please compare your file against bblayers.conf.sample and merge any changes before continuing. "meld conf/bblayers.conf /fast/work/intel-iot-refkit//meta-refkit/conf/bblayers.conf.sample" is a good way to visualise the changes. """ Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Set up HAVE_META_FLATPAK (and use it as aliasen for HAVE_OSTREE and HAVE_FLATPAK). Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Set MOUNT_FUSE_PATH explicitly to ${base_sbindir} before configure.
Making this explicit will let people override base_sbindir with the
desired effect, for instance when ussrmerge DISTRO_FEATURE is enabled.
Upstream-Status: Submitted [openembedded-devel@lists.openembedded.org]
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
…ing). Added bbappends with native support (where needed), and declared as supported recipes gpgme and gnupg along with its missing dependencies libksba, npth, and pinentry. These are necessary to support signing commits in ostree. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added bbappends to provide native packages and declared as supported recipes. These are needed by ostree-native. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added recipe for ostree and declared it as a supported recipes. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added recipe for bubblewrap and declared it as a supported recipe. It is needed by flatpak. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
…bbclass. Added a variant of systemd.bbclass which checks that systemd is among DISTRO_FEATURES for class-target recipes. This can be used by recipes that not only support systemd but require it to save an extra explicit required distro feature check. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added recipe for flatpak and declared it as a supported recipe. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added basic flatpak packagegroup. Only pulls in flatpak with its dependencies. We'll add another dedicated one (probably along with a dedicated DISTRO_FEATURE) for flatpak-session. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added a recipe for flatpak-image-runtime, a simple systemd service which emulates a flatpak runtime for the currently running image using a bunch of read-only bind mounts. Also declared the recipe as a supported one. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added a native-only recipe for gnupg1. We'll use this to generate keys and sign (ostree) repository commits during bitbake/image building in connection with ostree and flatpak repositories. While gnupg2 can be beaten to working obedience with hacks, it is somewhat of a PITA to use both in non-interactive batch mode and in the Yocto relocated native environment. Instead of dealing with those problems we generate/import signing keys and sign repository commits using gnupg1, and check signatures on client devices using gnupg2. The 'native-only' aspect is currently implemented by a prepended class-target configure scriptlet which bails out with an error status. If necessary this can be changed and the recipe easily converted to a genuine native-only recipe. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added a script for generating GPG keys, primarily intended for generating signing keys for ostree/flatpak repositories. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added a class for generating or importing signing keys using GPG. Currently we use this to generate signing keys for flatpak ostree repositories. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added a workhorse script for generating/populating a primary flatpak repository for an image. The script can also replicate this repository to another archive-z2 repository which can then be exposed over HTTP for consumption by flatpak clients. This will be necessary for building flatpaks for/against a flatpak-enabled refkit image. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Added three classes for supporting building flatpak-enabled images, and creating/publishing repositories with flatpak platform and SDK runtimes for such images. flatpak-config.bbclass contains the flatpak-related bitbake/configuration variables. It is separated to a class of its own because we'll probably need to inherit it in a recipe which will support pre-populating an image with pre-declared flatpak application repositories. flatpak-image-variants.bbclass declares two image variants: flatpak- runtime and flatpak-sdk. flatpak-runtime is our flatpak-enabled runtime image variant. It is supposed to get flashed to client devices that need flatpak support. flatpak-sdk is a corresponding image which we use to populate a flatpak repository with a flatpak SDK runtime which can then be used to compile/generate flatpaks for the flatpak-runtime variant. flatpak-repository.bbclass takes care of the details of populating and exporting flatpak repositories with images. Signed-off-by: Krisztian Litkey <kli@iki.fi>
If included/required, enable DISTRO_FEATURES (usrmerge, systemd, pam, and flatpak) necessary for basic flatpak support, and also set user-session PACKAGECONFIG for D-Bus. Signed-off-by: Krisztian Litkey <kli@iki.fi>
…port. If meta-flatpak is available and the DISTRO_FEATURE is on inherit flatpak-image-variant and flatpak-repository to enable building flatpak-enabled images and generating corresponding flatpak repositories. Signed-off-by: Krisztian Litkey <kli@iki.fi>
Enable basic flatpak support in enable-refkit-config.inc. Signed-off-by: Krisztian Litkey <kli@iki.fi>
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Contributor
|
On Fri, 2017-06-16 at 13:38 -0700, Krisztian Litkey wrote:
Interesting. All the tests passed in my test build without any such
failures (at least I did not stop any).
It only triggers when a developer doesn't already have meta-flatpak in
their bblayers.conf - you always had that, and thus never saw this.
|
Contributor
|
On Sat, Jun 17, 2017 at 10:21 PM, Patrick Ohly <notifications@github.com>
wrote:
On Fri, 2017-06-16 at 13:38 -0700, Krisztian Litkey wrote:
> Interesting. All the tests passed in my test build without any such
> failures (at least I did not stop any).
It only triggers when a developer doesn't already have meta-flatpak in
their bblayers.conf - you always had that, and thus never saw this.
What's not quite right is that bitbake only gave the flatpak.inc parse
error but did
not check layer conf version.
|
Contributor
|
On Sun, 2017-06-18 at 22:13 -0700, Mikko Ylinen wrote:
On Sat, Jun 17, 2017 at 10:21 PM, Patrick Ohly
***@***.***>
wrote:
> On Fri, 2017-06-16 at 13:38 -0700, Krisztian Litkey wrote:
> > Interesting. All the tests passed in my test build without any
such
> > failures (at least I did not stop any).
>
> It only triggers when a developer doesn't already have meta-flatpak
in
> their bblayers.conf - you always had that, and thus never saw this.
>
>
What's not quite right is that bitbake only gave the flatpak.inc parse
error but did not check layer conf version.
I agree, that could be improved - not sure whether that's possible,
though.
The reason is that the version check only triggers after parsing the
base configuration, but that already fails in a fatal way.
|
pohly
reviewed
Jun 27, 2017
| gnu-config@core | ||
| gnu-efi@core | ||
| gnupg@core | ||
| gnupg1@refkit-core |
Contributor
There was a problem hiding this comment.
There's no gnupg1 in meta-refkit-core, is there?
Please remove again.
| inherit image-mode-variants | ||
|
|
||
| # Enable flatpak image variant and repository generation. | ||
| inherit ${@'flatpak-image-variants' if \ |
Contributor
There was a problem hiding this comment.
inherit can inherit two classes at once. The if check is the same, so these two inherit lines can be merged:
inherit ${@'flatpak-image-variants flatpak-repository' if \
....
| -flatpak-runtime (image variant with flatpak support enabled) | ||
| -flatpak-sdk (image variant used as a flatpak BaseSdk for | ||
| building flatpaks suitable to be used on the | ||
| corresponding -flatpak-runtime image variant) |
Contributor
There was a problem hiding this comment.
Are you going to write documentation on how to use flatpak, in particular this "flatpak BaseSdk"?
I'm also wondering about the use of image variants. For flatpak it probably makes sense, because one really has to (?) build two images for the same base image. But one cannot create image variants of image variants, so OSTree cannot use the same mechanism.
Have you tested enabling OSTree and Flatpak in the same image?
| # | ||
| # To make sure all the necessary keys get generated list them in your | ||
| # local.conf (or some other global configuration file) by setting | ||
| # REFKIT_SIGNING_KEYS to necessary key IDs. |
Contributor
There was a problem hiding this comment.
Is meta-flatpak really the right place for this?
The class seems to be all about refkit (REFKIT_SIGNING_KEYS...). Or should the variables be named differently?
| " | ||
|
|
||
| # Enable D-Bus session bus support, needed by flatpak. | ||
| PACKAGECONFIG_append_pn-dbus_refkit-config = " user-session" |
Contributor
There was a problem hiding this comment.
How does this flatpak.inc work for people not using refkit? Should this .inc file perhaps be moved to meta-refkit-core?
| REFKIT_SIGNING_GPGDIR ?= "${DEPLOY_DIR}/gnupg" | ||
|
|
||
| # How long we let two parallel key generation tasks clash. | ||
| REFKIT_SIGNING_TIMEOUT ?= "60" |
Contributor
There was a problem hiding this comment.
Is it meant to be possible to customize these variables per image recipe? For example, for using different signing keys in different OSTree images?
My actual use case is slightly different: I want to trigger the creation of a default OSTree signing key in ostree-image.bbclass by extending REFKIT_SIGNING_KEYS. But then if that class isn't active in some other image recipe, we end up with different REFKIT_SIGNING_KEYS in different images.
The locking code below (IMHO) doesn't cope with that at the moment. It assumes that if some other task has locked the directory, that all keys will be generated once that other task is done. But that won't be the case when that other tasks has a different REFKIT_SIGNING_KEYS.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patchset adds the usrmerge patchset from @avalluri, a few minor fixes in top of that and a new meta-flatpak layer. meta-flatpak adds support for building flatpak-enabled runtime and SDK images as well as for generating and populating a corresponding flatpak ostree repository with related branches. These are generally referred to as the BasePlatform and BaseSdk runtimes in the flatpak nomenclature. The BaseSdk runtime can then be used to generate (IOW compile/cross-compile, package and publish) applications as flatpaks for a flatpak enabled runtime image.
This patchset contains basic flatpak support, including
exporting it to clients (and development hosts) for consumption using flatpak
There is another patchset landing on top of this which adds