path: root/recipes-core/swupd-server
AgeCommit message (Collapse)AuthorFilesLines
2016-08-04swupd-server: upgrade to 3.2.5Joshua Lock1-2/+2
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-05-13swupd-server: fix fullfiles patch for swupd-server-2.53Joshua Lock1-0/+66
Rebasing the fullfiles.c-work-around-pseudo-bug.patch patch for newer swupd 3.x branches prevents it from being applied cleanly to the 2.53 version. Resolve this by keeping a separate copy of the original patch for swupd-server-2.53 Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-05-13swupd-server: bump to 3.2.3Joshua Lock7-123/+118
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-04-12swupd-server: inherit pkgconfigJoshua Lock2-2/+2
The configure.ac uses PKG_CHECK, inherit pkgconfig to ensure we have pkg-config built before swupd-server. Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-04-06swupd-server: better align 3.1.2 recipe with 2.53 recipeJoshua Lock6-4/+6
Switch 3.1.2 recipe to using bsdtar and include the patch to work around hardlink extended attribute issues when running under pseudo. Move 2.53 specific patches to the swupd-server-2.53 directory. Unify DEPENDS, RDEPENDS and EXTRA_OECONF settings. Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-04-04swupd-server: add recipe for 3.1.2Joshua Lock6-0/+25
Add a new recipe to track the latest version, 3.1.2, from github. We'll keep the older version around for now whilst we do some testing. Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-03-30swupd-server: work around pseudo xattr hardlink bugPatrick Ohly2-0/+67
swupd-server relies on hardlinks to create a temporary directory with the original file for the external tar command. Creating hardlinks under pseudo leads to copies which (incorrectly) do not share the original file's xattrs. To work around this bug, we explicitly copy the xattrs. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2016-03-30swupd-client: Update the client and server to use bsdtarDmitry Rozhkov4-2/+250
This patch adds bsdtar support to swupd-client and swupd-server and enables it. The reason why it's done this way is that: - bsdtar works better with IMA (opens files only once and then updates content and xattrs together); - swupd remains fully functional, including xattrs support, even when a distro disables GPLv3 licensed code. Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
2016-03-21swupd-server: always use xattrs when calculating hashesJoshua Lock2-0/+33
Backport a patch from swupd-server upstream to ensure that xattrs are always used when calculating file hashes. This is the behaviour swupd-client expects. Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-03-14swupd-server: Add patch fixing freeing dangling pointersDmitry Rozhkov6-34/+82
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
2016-02-25Initial populationJoshua Lock5-0/+1043
This initial layer version provides an initial set of metadata to enable integration of the swupd (https://clearlinux.org/features/software-update) software updater into an image. Approach: An image that inherits the swupd-image bbclass will automatically have bundle 'chroots' created which contain the filesystem contents of the specified bundles, with the contents of the inheriting image forming the default os-core bundle. The mechanism to achieve this is that several virtual image recipes are created using the swupdbundle class, one for each defined bundle plus a 'mega' image recipe. The 'mega' image contains the base image plus the contents of all of the bundles, whilst bundle images contain only the base image plus the contents of a single bundle. We build the mega image first, then the base image (the one which inherits this class) and finally all of the bundle images. Each non-mega image has a manifest generated that lists the file contents of the image. We took the approach of building images, rather than populating the chroot-like bundle directories with a package manager, because various layers and recipes make changes to the rootfs contents outside of the package manager, particularly with IMAGE_POSTPROCESS_COMMAND, etc. Once the images and their manifests have been created each bundle image manifest is compared to the base image manifest in order to generate a list of files in the bundle image which don't exist in the base image. Files in this list are then preserved in the bundle directory for processing by swupd-server in order to generate update artefacts. Finally the binaries from swupd-server are called on the bundle directories to generate the artefacts for consumption by a swupd client. How to: * inherit the swupd-image class in your core OS image. swupd-based OS's use bundles, the primary one of which, os-core, is defined as the contents of this image. * Assign a list of names for bundles you wish to generate to the SWUPD_BUNDLES variable i.e. SWUPD_BUNDLES = "feature_one feature_two" * Assign a list of packages for which their content should be included in a bundle to a varflag of BUNDLE_CONTENTS which matches the bundle name i.e. BUNDLE_CONTENTS[feature_one] = "package_one package_three package_six" * Ensure the OS_VERSION variable is assigned an integer value and increased before each image build which should generate swupd update artefacts. This variable must echo the same version number as is used to set the VERSION_ID field of os-release as swupd-client will use it to check for updates. * Publish the contents of ${DEPLOY_DIR}/swupd/${MACHINE}/${IMAGE_BASENAME}/www on a server for consumption by swupd-client * Use swupd client sub-commands with the -u argument pointing to the contents published above Known issues: * shared pseudo database: the bundle chroot-like directories are generated per-recipe and processed by a task of the inheriting recipe. In order for the files generated outside of the base recipe to have correct permissions when processed by swupd-server we need to share a pseudo database across the recipes. This database is currently never cleaned up, which is likely to cause headaches due to the way pseudo operates on inodes that could be reused outside of pseudo's influence. We have yet to determine an appropriate time to perform housekeeping on this database (we essentially need the database to be removed when DEPLOY_DIR_SWUPD is removed). * oe-swupd-helpers: this recipe provides stub implementations only of some swupd-client helpers. Anyone wishing to utilise swupd in a deployed image will need to at least override kernel_updater.sh and systemdboot_updater.sh. * hard-coded paths: swupd assumes Clear Linux as a host OS and hard-codes several paths to directories, programs and configuration files on Clear. * builds a lot of images: due to the approach taken there are n+2 images built, where n is the number of bundles defined in SWUPD_BUNDLES. * creates a lot of duplicate files: due to the way swupd works by processing chroot-like bundle directories on each os release we potentially end up carrying a lot of duplicate files in DEPLOY_DIR_SWUPD. We intend to look at using the hardlink program to replace duplicate files in that directory with hard links in order to save disk space. * requires far more testing: there are a lot of combinations of bundle contents, rootfs modification commands (IMAGE_POSTPROCESS_COMMAND, IMAGE_PREPROCESS_COMMAND, etc) that can affect the inputs to swupd and our testing has likely missed areas of issue. * OS_VERSION: introduces a new variable for the OS version number when we already have a DISTRO_VERSION variable. This was done because swupd makes various assumptions about the version number which aren't necessarily true for traditional DISTRO_VERSION values in OE et al. Co-authored-by: Mariano Lopez <mariano.lopez@linux.intel.com> Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>