[meta-swupdate][PATCH 03/12] swupdate: support signed image with variable name

[Adrian Freihofer]

Support the following in a sw-description:
filename = "@@ROOTFS_IMAGE@@";
sha256 = "@@@ROOTFS_IMAGE@@";

First the @@ROOTFS_IMAGE@@ gets replaced e.g. by @my-image. Second
@my-image gets replaced by the sha256 hash.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---
classes/swupdate-common.bbclass | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/classes/swupdate-common.bbclass b/classes/swupdate-common.bbclass
index c0b302a..38f1906 100644
--- a/classes/swupdate-common.bbclass
+++ b/classes/swupdate-common.bbclass
@@ -37,22 +37,22 @@ def swupdate_expand_bitbake_variables(d, s):
for line in f:
found = False
while True:
- m = re.match(r"^(?P<before_placeholder>.+)@@(?P<bitbake_variable_name>\w+)@@(?P<after_placeholder>.+)$", line)
+ m = re.match(r"^(?P<before_placeholder>.+)@@(?P<sign_at>@?)(?P<bitbake_variable_name>\w+)@@(?P<after_placeholder>.+)$", line)
if m:
bitbake_variable_value = d.getVar(m.group('bitbake_variable_name'), True)
if bitbake_variable_value is None:
bitbake_variable_value = ""
bb.warn("BitBake variable %s not set" % (m.group('bitbake_variable_name')))
- line = m.group('before_placeholder') + bitbake_variable_value + m.group('after_placeholder')
+ line = m.group('before_placeholder') + m.group('sign_at') + bitbake_variable_value + m.group('after_placeholder')
found = True
continue
else:
- m = re.match(r"^(?P<before_placeholder>.+)@@(?P<bitbake_variable_name>.+)\[(?P<flag_var_name>.+)\]@@(?P<after_placeholder>.+)$", line)
+ m = re.match(r"^(?P<before_placeholder>.+)(?P<sign_at>@?)@@(?P<bitbake_variable_name>.+)\[(?P<flag_var_name>.+)\]@@(?P<after_placeholder>.+)$", line)
if m:
bitbake_variable_value = (d.getVarFlag(m.group('bitbake_variable_name'), m.group('flag_var_name'), True) or "")
if bitbake_variable_value is None:
bitbake_variable_value = ""
- line = m.group('before_placeholder') + bitbake_variable_value + m.group('after_placeholder')
+ line = m.group('before_placeholder') + m.group('sign_at') + bitbake_variable_value + m.group('after_placeholder')
continue

if found:
--
2.11.0

[Adrian Freihofer]

The devtool workflow does not work without setting PV properly.

To prefer the git version add the following line to the distro config:
PREFERRED_VERSION_libubootenv = "0.1+git%"

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-bsp/libubootenv/libubootenv_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-bsp/libubootenv/libubootenv_git.bb b/recipes-bsp/libubootenv/libubootenv_git.bb
index 5dba3c3..6f7c080 100644
--- a/recipes-bsp/libubootenv/libubootenv_git.bb
+++ b/recipes-bsp/libubootenv/libubootenv_git.bb
@@ -1,5 +1,5 @@
require libubootenv.inc
SRCREV = "92949816720d7af2ac722016e7a5b9a85ff141bc"
-PV_append = "+git${SRCPV}"
+PV = "0.1+git${SRCPV}"

DEFAULT_PREFERENCE = "-1"
--
2.11.0

[Adrian Freihofer]

The main goal of this patch series is to simplify the configuration of swupdate.

It's tested with systemd but not with an init script based DISTRO.

Adrian Freihofer (12):
swupdate: simplify find images added to swu
swupdate: ensure scripts are added before images
swupdate: support signed image with variable name
libubootenv: bump git srcrev
libubootenv: git define PV
swupdate git define PV
swupdate: bump git srcrev
swupdate: add missing rdepends
swupdate: improve systemd config
swupdate: update, fixes in do_install
swupdate-enc: add missing $
swupdate: install key, cert

README | 9 +-
classes/swupdate-common.bbclass | 8 +-
classes/swupdate-enc.bbclass | 28 +++++-
classes/swupdate.bbclass | 100 +++++++++++++++------
recipes-bsp/libubootenv/libubootenv_git.bb | 4 +-
.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0
recipes-support/swupdate/swupdate.inc | 60 +++++++------
recipes-support/swupdate/swupdate_2019.04.bb | 28 +++++-
recipes-support/swupdate/swupdate_git.bb | 8 +-
recipes-support/swupdate/swupdate_tools.inc | 24 -----
14 files changed, 181 insertions(+), 88 deletions(-)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)
delete mode 100644 recipes-support/swupdate/swupdate_tools.inc

--
2.11.0

[Adrian Freihofer]

Update swupdate to latest git version. This changes the filenames
of the tools binaries for several reasons:
- Binaries should not be named "client" or "progress"
(also not accepted by Debian upstream)
- Inconsistent with names referred in the service files

The swupdate_tools.inc file gets merged into swupdate.inc file. By
removing the tools file some bugs are fixed:
- The tools binaries were installed twice.
- do_compile from swupdate.inc was over written resulting in wired
behavior
- swupdate-progress.service file was part of swupdate package were the
corresponding swupdate-progress binary was part of the tools package.

The tools are now installed by the "make install" target of swupdate's
Makefile. The related code here in meta-swupdate gets removed.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-support/swupdate/swupdate.inc | 18 +++++++++++++-----
recipes-support/swupdate/swupdate_2019.04.bb | 20 +++++++++++++++++++-
recipes-support/swupdate/swupdate_git.bb | 1 -
recipes-support/swupdate/swupdate_tools.inc | 24 ------------------------
4 files changed, 32 insertions(+), 31 deletions(-)
delete mode 100644 recipes-support/swupdate/swupdate_tools.inc

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 19ccf4a..ec7091f 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -12,14 +12,22 @@ SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \
file://swupdate \
"

+PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools"
INSANE_SKIP_${PN} = "ldflags"
-PACKAGES =+ "${PN}-www ${PN}-lua"
+INSANE_SKIP_${PN}-tools = "ldflags"

FILES_${PN}-lua += "${libdir}/lua/"
FILES_${PN}-www = " \
${libdir}/swupdate/conf.d/*mongoose* \
/www/* \
"
+FILES_${PN}-tools = " \
+ ${bindir}/swupdate-client \
+ ${bindir}/swupdate-progress \
+ ${systemd_system_unitdir}/swupdate-progress.service \
+ ${bindir}/swupdate-hawkbitcfg \
+ ${bindir}/swupdate-sendtohawkbit \
+"
FILES_${PN} += " \
${libdir}/tmpfiles.d \
${libdir}/swupdate/* \
@@ -130,10 +138,7 @@ do_configure () {

do_compile() {
unset LDFLAGS
- oe_runmake swupdate_unstripped progress_unstripped
- cp swupdate_unstripped swupdate
- cp progress_unstripped progress
-
+ oe_runmake
}

do_install () {
@@ -158,3 +163,6 @@ SYSTEMD_SERVICE_${PN} = " \
swupdate.service \
swupdate-usb@.service \
"
+
+SYSTEMD_PACKAGES_append = " ${PN}-tools"
+SYSTEMD_SERVICE_${PN}-tools = "swupdate-progress.service"
diff --git a/recipes-support/swupdate/swupdate_2019.04.bb b/recipes-support/swupdate/swupdate_2019.04.bb
index 83785d7..5b0fb78 100644
--- a/recipes-support/swupdate/swupdate_2019.04.bb
+++ b/recipes-support/swupdate/swupdate_2019.04.bb
@@ -1,5 +1,4 @@
require swupdate.inc
-require swupdate_tools.inc

SRC_URI += " \
file://swupdate.service \
@@ -10,3 +9,22 @@ SRC_URI += " \
"

SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81"
+
+do_install_append () {
+ # Rename the binaries installed by make install
+ test -f ${D}${bindir}/progress && mv ${D}${bindir}/progress ${D}${bindir}/swupdate-progress
+ test -f ${D}${bindir}/client && mv ${D}${bindir}/client ${D}${bindir}/swupdate-client
+ test -f ${D}${bindir}/hawkbitcfg && mv ${D}${bindir}/hawkbitcfg ${D}${bindir}/swupdate-hawkbitcfg
+ test -f ${D}${bindir}/sendtohawkbit && mv ${D}${bindir}/sendtohawkbit ${D}${bindir}/swupdate-sendtohawkbit
+
+ install -d ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_system_unitdir}
+ if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+ install -d ${D}${libdir}/tmpfiles.d
+ install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf
+ install -d ${D}${sysconfdir}/udev/rules.d
+ install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
+ fi
+}
diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb
index a4289f6..8eef04e 100644
--- a/recipes-support/swupdate/swupdate_git.bb
+++ b/recipes-support/swupdate/swupdate_git.bb
@@ -1,5 +1,4 @@
require swupdate.inc
-require swupdate_tools.inc

DEFAULT_PREFERENCE = "-1"

diff --git a/recipes-support/swupdate/swupdate_tools.inc b/recipes-support/swupdate/swupdate_tools.inc
deleted file mode 100644
index d270dd4..0000000
--- a/recipes-support/swupdate/swupdate_tools.inc
+++ /dev/null
@@ -1,24 +0,0 @@
-PACKAGES =+ "${PN}-tools"
-
-INSANE_SKIP_${PN}-tools = "ldflags"
-
-FILES_${PN}-tools = "${bindir}/swupdate-client \
- ${bindir}/swupdate-progress \
- ${bindir}/swupdate-hawkbitcfg \
- ${bindir}/swupdate-sendtohawkbit"
-
-do_compile() {
- unset LDFLAGS
-
- oe_runmake
- cp swupdate_unstripped swupdate
-}
-
-do_install_append () {
-
- install -m 0755 tools/client_unstripped ${D}${bindir}/swupdate-client
- install -m 0755 tools/progress_unstripped ${D}${bindir}/swupdate-progress
- install -m 0755 tools/hawkbitcfg_unstripped ${D}${bindir}/swupdate-hawkbitcfg
- install -m 0755 tools/sendtohawkbit_unstripped ${D}${bindir}/swupdate-sendtohawkbit
-
-}
--
2.11.0

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

classes/swupdate-enc.bbclass | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/swupdate-enc.bbclass b/classes/swupdate-enc.bbclass
index 5e3fe79..198ae98 100644
--- a/classes/swupdate-enc.bbclass
+++ b/classes/swupdate-enc.bbclass
@@ -13,7 +13,7 @@ swu_encrypt_file() {
key=`cat ${SWUPDATE_AES_FILE} | grep ^key | cut -d '=' -f 2`
iv=`cat ${SWUPDATE_AES_FILE} | grep ^iv | cut -d '=' -f 2`
salt=`cat ${SWUPDATE_AES_FILE} | grep ^salt | cut -d '=' -f 2`
- if [ -z ${salt} ] || [ -z ${key} ] || [ -z {iv} ];then
+ if [ -z ${salt} ] || [ -z ${key} ] || [ -z ${iv} ];then
bbfatal "SWUPDATE_AES_FILE=$SWUPDATE_AES_FILE does not contain valid keys"
fi
openssl enc -aes-256-cbc -in ${input} -out ${output} -K ${key} -iv ${iv} -S ${salt}
--
2.11.0

[Adrian Freihofer]

In case of singed and/or encrypted images the corresponding keys and
certificates need to be installed into the image.

If the variables SWUPDATE_CMS_CERT and SWUPDATE_AES_FILE are set for
the image (not only for the image-update) as well, the required
certificate and key files get installed and the -k and the -K paramter
are added to the swupdate configuration.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

README | 9 ++++++++-
classes/swupdate-enc.bbclass | 26 ++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/README b/README
index ffc8f33..eb8904e 100644
--- a/README
+++ b/README
@@ -40,7 +40,14 @@ There are 3 signing mechanisms supported by meta-swupdate at the moment:

* Set variable: `SWUPDATE_SIGNING = "CMS"`

- * Set `SWUPDATE_CMS_CERT` to the full path of certificate file
+ * Set `SWUPDATE_CMS_CERT` to the full path of certificate file.
+ Settings this variable for the swu image (inherit swupdate) configures the
+ build system to create signed images.
+ Setting this variable for the image included in the swu archive, leads to
+ an image which is ready to verify the signature of an image in a swu archive
+ at run-time. The certificate gets installed and the -k parameter
+ gets added to the command line arguments for swupdate. This requires to
+ inherit swupdate-enc. This works with systemd but not with init scripts yet.

* Set `SWUPDATE_CMS_KEY ` to the full path of private key file

diff --git a/classes/swupdate-enc.bbclass b/classes/swupdate-enc.bbclass
index 198ae98..95ad636 100644
--- a/classes/swupdate-enc.bbclass
+++ b/classes/swupdate-enc.bbclass
@@ -23,3 +23,29 @@ CONVERSIONTYPES += "enc"

CONVERSION_DEPENDS_enc = "openssl-native coreutils-native"
CONVERSION_CMD_enc="swu_encrypt_file ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.enc"
+
+
+# To get the keys and certificates installed the variables SWUPDATE_CMS_CERT
+# and SWUPDATE_AES_FILE need to be defined for the image and the update-image.
+install_key_and_cert() {
+ # Install the image signature verification certificate
+ if [ "x${SWUPDATE_CMS_CERT}" != "x" ]; then
+ install -m 0600 ${SWUPDATE_CMS_CERT} ${IMAGE_ROOTFS}${libdir}/swupdate/image-signing.cert.pem
+ echo 'SWUPDATE_ARGS="${SWUPDATE_ARGS} -k /usr/lib/swupdate/image-signing.cert.pem"' > ${WORKDIR}/80-enable-sign-images
+ install -m 0644 ${WORKDIR}/80-enable-sign-images ${IMAGE_ROOTFS}${libdir}/swupdate/conf.d
+ fi
+
+ # Install the key to decrypt update images
+ if [ "x${SWUPDATE_AES_FILE}" != "x" ]; then
+ key=`grep ^key ${SWUPDATE_AES_FILE} | cut -d '=' -f 2`
+ iv=`grep ^iv ${SWUPDATE_AES_FILE} | cut -d '=' -f 2`
+ if [ -z ${key} ] || [ -z ${iv} ]; then
+ bbfatal "SWUPDATE_AES_FILE=$SWUPDATE_AES_FILE does not contain valid keys"
+ fi
+ echo "${key} ${iv}" > ${WORKDIR}/image-enc-aes.key
+ install -m 0600 ${WORKDIR}/image-enc-aes.key ${IMAGE_ROOTFS}${libdir}/swupdate
+ echo 'SWUPDATE_ARGS="${SWUPDATE_ARGS} -K /usr/lib/swupdate/image-enc-aes.key"' > ${WORKDIR}/81-enable-enc-images
+ install -m 0644 ${WORKDIR}/81-enable-enc-images ${IMAGE_ROOTFS}${libdir}/swupdate/conf.d
+ fi
+}
+ROOTFS_POSTPROCESS_COMMAND += 'install_key_and_cert;'
--
2.11.0

[Adrian Freihofer]

swupdate-www requires the swupdate-progress service from swupdate-tools
package.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-support/swupdate/swupdate.inc | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 392af31..1c863bb 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -24,6 +24,8 @@ FILES_${PN}-lua += "${libdir}/lua/"
FILES_${PN}-www = "/www/*"

FILES_${PN} += "${libdir}/tmpfiles.d"

+RDEPENDS_${PN}-www += "${PN}-tools"
+
S = "${WORKDIR}/git/"

EXTRA_OEMAKE += " HOSTCC="${BUILD_CC}" HOSTCXX="${BUILD_CXX}" LD="${CC}" DESTDIR="${D}" V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"
--
2.11.0

[Adrian Freihofer]

This includes the following changes:

75985aa Add Kconfig option for new systemd files
bdc1d3c systemd generic startup
16790d1 doc: fix broken link for talks
7c8926d ssbl_handler: fix age comparison
f130541 travis: set libwebsockets version
9409e9a Prepare 2019.11-rc1
d8d9fd4 handler: add a copy handler
21594da Add SSBL Handler
34c55f1 handlers: sort the list of modules in Makefile
ede66e7 doc: add scenarios how to use SWUpdate
a5e82b9 doc: add links to single and double copy scenarios
c744dfe Cosmetic: rename entry points in raw handler
864dedd raw handler: return error number instead of -1
e38ad73 handler: push progress status from bootloader handler
cfaec8c u-boot handler: fix removing variable
27c40c4 doc: ELC video published on YouTube
07811c7 swupdate: add pre-update command hook
da974cd doc: update list of talks with ELC 2019

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-support/swupdate/swupdate_git.bb | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb
index 3f69b87..9fea83a 100644
--- a/recipes-support/swupdate/swupdate_git.bb
+++ b/recipes-support/swupdate/swupdate_git.bb
@@ -3,5 +3,5 @@ require swupdate_tools.inc

DEFAULT_PREFERENCE = "-1"

-SRCREV ?= "a8d45381253838b34e4e035c065a1cdf429b1f09"
+SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85"
PV = "2019.04+git${SRCPV}"
--
2.11.0

[Adrian Freihofer]

For most projects starting swupdate requires some logic implemented
in shell scripts. Therefore swupdate is now started by a shell script
also in case of systemd is anabled in DISTRO_FEATURES.

The new swupdate startup script sources code snippets located in
/usr/lib/swupdate/conf.d and in /etc/swupdate/conf.d. The snippets are
executed in alphabetical order. The idea is that files in /usr are added
at build time and files in /etc might be added or modified at run-time.
If two scripts, one in /etc and one in /usr have the same file name, the
script in /usr gets skipped completely. This allows to disable code in
/usr, which is probably mounted ro, at runtime.

Code snippets are automatically generated at build-time, depending on
the configuration created by swupdate's menuconfig. But code snippets
may be created manually and added via bbappend to the
/usr/lib/swupdate/conf.d folder.

All modes (file, webserver, webclient) of swupdate are supported.
Different variables might be defined by the code snippets added to the
named folders:
- SWUPDATE_ARGS
- SWUPDATE_WEBSERVER_ARGS
- SWUPDATE_DOWNLOAD_ARGS

Finally swupdate gets started by a line similar to:

exec /usr/bin/swupdate $SWUPDATE_ARGS \
-w "$SWUPDATE_WEBSERVER_ARGS" \
-u "$SWUPDATE_DOWNLOAD_ARGS"

The default set of configuraton and service files is now installed by
the "make install" target of the swupdate Makefile. The service files
which are not used for the latest git version of swupdate are moved
to swupdate-2019.04 folder.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0

recipes-support/swupdate/swupdate.inc | 40 +++++++++-------------
recipes-support/swupdate/swupdate_2019.04.bb | 8 +++++
recipes-support/swupdate/swupdate_git.bb | 4 +++
8 files changed, 29 insertions(+), 23 deletions(-)

rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)

diff --git a/recipes-support/swupdate/swupdate/swupdate-progress.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-progress.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb.rules b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb.rules
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb@.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb@.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
diff --git a/recipes-support/swupdate/swupdate/swupdate.service b/recipes-support/swupdate/swupdate-2019.04/swupdate.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate.service
diff --git a/recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf b/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf
similarity index 100%
rename from recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf
rename to recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf
diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 1c863bb..19ccf4a 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -10,25 +10,30 @@ inherit cml1 update-rc.d systemd pkgconfig

SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \

file://defconfig \
file://swupdate \
- file://swupdate.service \
- file://swupdate-usb.rules \
- file://swupdate-usb@.service \
- file://swupdate-progress.service \
- file://systemd-tmpfiles-swupdate.conf \
"

INSANE_SKIP_${PN} = "ldflags"

PACKAGES =+ "${PN}-www ${PN}-lua"

FILES_${PN}-lua += "${libdir}/lua/"

-FILES_${PN}-www = "/www/*"
-FILES_${PN} += "${libdir}/tmpfiles.d"
+FILES_${PN}-www = " \
+ ${libdir}/swupdate/conf.d/*mongoose* \
+ /www/* \
+"
+FILES_${PN} += " \
+ ${libdir}/tmpfiles.d \
+ ${libdir}/swupdate/* \
+ ${systemd_system_unitdir}/swupdate.socket \
+ ${systemd_system_unitdir}/swupdate.service \
+ ${systemd_system_unitdir}/swupdate-usb@.service \
+"

RDEPENDS_${PN}-www += "${PN}-tools"

S = "${WORKDIR}/git/"

-EXTRA_OEMAKE += " HOSTCC="${BUILD_CC}" HOSTCXX="${BUILD_CXX}" LD="${CC}" DESTDIR="${D}" V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"
+EXTRA_OEMAKE += " HOSTCC="${BUILD_CC}" HOSTCXX="${BUILD_CXX}" LD="${CC}" DESTDIR="${D}" V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'SYSTEMD_SYSTEM_UNITDIR=${systemd_system_unitdir}', '', d)}"

DEPENDS += "kern-tools-native"

@@ -144,23 +149,12 @@ do_install () {

install -d ${D}${sysconfdir}/init.d
install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d
-
- install -d ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_unitdir}/system
-
-
- if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
- install -d ${D}${libdir}/tmpfiles.d
- install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf
- install -d ${D}${sysconfdir}/udev/rules.d
- install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
- fi
}

INITSCRIPT_NAME = "swupdate"
INITSCRIPT_PARAMS = "defaults 70"

-SYSTEMD_SERVICE_${PN} = "swupdate.service"
-SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service swupdate-progress.service"
+SYSTEMD_SERVICE_${PN} = " \
+ swupdate.service \
+ swupdate-usb@.service \
+ "
diff --git a/recipes-support/swupdate/swupdate_2019.04.bb b/recipes-support/swupdate/swupdate_2019.04.bb
index e2eabbb..83785d7 100644
--- a/recipes-support/swupdate/swupdate_2019.04.bb
+++ b/recipes-support/swupdate/swupdate_2019.04.bb
@@ -1,4 +1,12 @@
require swupdate.inc
require swupdate_tools.inc

+SRC_URI += " \
+ file://swupdate.service \
+ file://swupdate-usb.rules \
+ file://swupdate-usb@.service \
+ file://swupdate-progress.service \
+ file://systemd-tmpfiles-swupdate.conf \
+ "
+
SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81"
diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb
index 9fea83a..a4289f6 100644
--- a/recipes-support/swupdate/swupdate_git.bb
+++ b/recipes-support/swupdate/swupdate_git.bb
@@ -5,3 +5,7 @@ DEFAULT_PREFERENCE = "-1"

SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85"
PV = "2019.04+git${SRCPV}"

+
+SYSTEMD_SERVICE_${PN} += " \
+ swupdate.socket \
+"
--
2.11.0

[adrian.f...@gmail.com]

Did not update the comment. Missing:
045a618 raw_handler: handle ro block devices
5700346 Makefile: rename tools binaries
48f22c6 add .editorconfig file
e5e7e02 doc: describe REST api

Am Mittwoch, 23. Oktober 2019 23:11:12 UTC+2 schrieb Adrian Freihofer:

This includes the following changes:

75985aa Add Kconfig option for new systemd files
bdc1d3c systemd generic startup
16790d1 doc: fix broken link for talks
7c8926d ssbl_handler: fix age comparison
f130541 travis: set libwebsockets version
9409e9a Prepare 2019.11-rc1
d8d9fd4 handler: add a copy handler
21594da Add SSBL Handler
34c55f1 handlers: sort the list of modules in Makefile
ede66e7 doc: add scenarios how to use SWUpdate
a5e82b9 doc: add links to single and double copy scenarios
c744dfe Cosmetic: rename entry points in raw handler
864dedd raw handler: return error number instead of -1
e38ad73 handler: push progress status from bootloader handler
cfaec8c u-boot handler: fix removing variable
27c40c4 doc: ELC video published on YouTube
07811c7 swupdate: add pre-update command hook
da974cd doc: update list of talks with ELC 2019

Signed-off-by: Adrian Freihofer <adrian....@siemens.com>

[Joris Offouga]

Hi Adrian,

Le 23/10/2019 à 23:10, Adrian Freihofer a écrit :

This includes the following changes:

75985aa Add Kconfig option for new systemd files
bdc1d3c systemd generic startup
16790d1 doc: fix broken link for talks
7c8926d ssbl_handler: fix age comparison
f130541 travis: set libwebsockets version
9409e9a Prepare 2019.11-rc1
d8d9fd4 handler: add a copy handler
21594da Add SSBL Handler
34c55f1 handlers: sort the list of modules in Makefile
ede66e7 doc: add scenarios how to use SWUpdate
a5e82b9 doc: add links to single and double copy scenarios
c744dfe Cosmetic: rename entry points in raw handler
864dedd raw handler: return error number instead of -1
e38ad73 handler: push progress status from bootloader handler
cfaec8c u-boot handler: fix removing variable
27c40c4 doc: ELC video published on YouTube
07811c7 swupdate: add pre-update command hook
da974cd doc: update list of talks with ELC 2019

Your changelog it's wrong, it's missing:

045a618 raw_handler: handle ro block devices

5700346 Makefile: rename tools binaries

48f22c6 add .editorconfig file

e5e7e02 doc: describe REST api

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>

---
 recipes-support/swupdate/swupdate_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb
index 3f69b87..9fea83a 100644
--- a/recipes-support/swupdate/swupdate_git.bb
+++ b/recipes-support/swupdate/swupdate_git.bb
@@ -3,5 +3,5 @@ require swupdate_tools.inc
 
 DEFAULT_PREFERENCE = "-1"
 
-SRCREV ?= "a8d45381253838b34e4e035c065a1cdf429b1f09"
+SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85"
 PV = "2019.04+git${SRCPV}"

Best Regards,

Joris

[Stefan Herbrechtsmeier]

Am 23.10.19 um 23:10 schrieb Adrian Freihofer:

> Support the following in a sw-description:
> filename = "@@ROOTFS_IMAGE@@";
> sha256 = "@@@ROOTFS_IMAGE@@";
>
> First the @@ROOTFS_IMAGE@@ gets replaced e.g. by @my-image. Second
> @my-image gets replaced by the sha256 hash.
>

Please don't use a single @ and use an obviously solution which is easy
readable. Maybe we should use ${} to support nested variables:
$${ROOTFS_IMAGE}_SHA256}

Alternative a sw-description.bbclass could create the sw-description
on-the-fly.

Regards
Stefan

[Stefan Herbrechtsmeier]

Am 23.10.19 um 23:10 schrieb Adrian Freihofer:

> swupdate-www requires the swupdate-progress service from swupdate-tools
> package.

Should we move swupdate-progress into its own package?

Regards
Stefan

[Stefan Herbrechtsmeier]

Am 23.10.19 um 23:10 schrieb Adrian Freihofer:

NACK. This is a configuration and should be setup during configuration.

Regards
Stefan

[Stefan Herbrechtsmeier]

Hi Adrian,

Am 23.10.19 um 23:11 schrieb Adrian Freihofer:

Is this the correct path for an certificate?

Regards
Stefan

[adrian.f...@gmail.com]

Hi Stefan,

That's what I've been thinking about. I only see advantages in it. But I would prefer to do it in another merge request.

Regards,

Adrian

[adrian.f...@gmail.com]

Hi Stefan,

There is an option in Kconfig but this option is not useful for a Yocto build system. Therefore the default value of Kbuild allows to provide the value like done in the line you are referring.

systemd_system_unitdir is a system specific variable provided by Yocto. Every other value as the one set by this line, would break almost everything here. What's the advantage of a configuration flag where exactly one value is valid? Or what is the other value you would like to configure?

Regards,

Adrian

> Signed-off-by: Adrian Freihofer <adrian....@siemens.com>

[Joris OFFOUGA]

Hi Adrian, 

Le jeu. 24 oct. 2019 à 12:43, <adrian.f...@gmail.com> a écrit :

Hi Stefan,

There is an option in Kconfig but this option is not useful for a Yocto build system. Therefore the default value of Kbuild allows to provide the value like done in the line you are referring.

systemd_system_unitdir is a system specific variable provided by Yocto. Every other value as the one set by this line, would break almost everything here. What's the advantage of a configuration flag where exactly one value is valid? Or what is the other value you would like to configure?

I totally agree with you.  That's why I also put the default value in my patch

Best Regards, 

Joris 

--
You received this message because you are subscribed to the Google Groups "swupdate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/swupdate/962bbe3f-6185-4c7f-b539-51af4546fbeb%40googlegroups.com.

[adrian.f...@gmail.com]

Hi Stefan,

May be yes, because it just works.

May be no, because a user has a reason to store the certificate somewhere else. This is still the default. This new way to installation the security relevant certificates is opt-in. The code here becomes active when the SWUPDATE_CMS_CERT variable is set for the image. It's up to the user to set this variable only for the swu recipe (as before) or for both (new opt-in), the swu and the image recipe. I tried to explain this in the README.

Providing a variable for the certificate path might be a potential improvement.

Regards,

Adrian

Am Donnerstag, 24. Oktober 2019 10:51:47 UTC+2 schrieb Stefan Herbrechtsmeier:

Hi Adrian,

Am 23.10.19 um 23:11 schrieb Adrian Freihofer:
> In case of singed and/or encrypted images the corresponding keys and
> certificates need to be installed into the image.
>
> If the variables SWUPDATE_CMS_CERT and SWUPDATE_AES_FILE are set for
> the image (not only for the image-update) as well, the required
> certificate and key files get installed and the -k and the -K paramter
> are added to the swupdate configuration.
>

> Signed-off-by: Adrian Freihofer <adrian....@siemens.com>

[adrian.f...@gmail.com]

Hi Stefan

Am Donnerstag, 24. Oktober 2019 10:43:37 UTC+2 schrieb Stefan Herbrechtsmeier:

Am 23.10.19 um 23:10 schrieb Adrian Freihofer:
> Support the following in a sw-description:
>    filename = "@@ROOTFS_IMAGE@@";
>    sha256 = "@@@ROOTFS_IMAGE@@";
>
> First the @@ROOTFS_IMAGE@@ gets replaced e.g. by @my-image. Second
> @my-image gets replaced by the sha256 hash.
>

Please don't use a single @ and use an obviously solution which is easy
readable. Maybe we should use ${} to support nested variables:
$${ROOTFS_IMAGE}_SHA256}

A single @ was not invented by me. It's the syntax required for the sha256 parameter. My patch just adds the possibility to combine the @@ with the already existing @. Everything else would break backward compatibility. Otherwise I would agree with your proposal.

Alternative a sw-description.bbclass could create the sw-description
on-the-fly.

Creating such a class might be a long term goal. But this class needs to support all features of the sw-description file, which is not that easy.

Regards
   Stefan

[Stefan Herbrechtsmeier]

Hi Adrian,

Am 24.10.19 um 12:43 schrieb adrian.f...@gmail.com:

> Hi Stefan,
>
> There is an option in Kconfig but this option is not useful for a Yocto
> build system.

Why?

Couldn't you append the value to the .config?

> Therefore the default value of Kbuild allows to provide
> the value like done in the line you are referring.
> systemd_system_unitdir is a system specific variable provided by Yocto.
> Every other value as the one set by this line, would break almost
> everything here. What's the advantage of a configuration flag where
> exactly one value is valid? Or what is the other value you would like to
> configure?

The problem is the break of the common design. You have three step:
configure, build, install. You break this concept because you set a
configuration option during install. All other build tools (autotools,
cmake, meson) use the configuration step to configure the installation step.

Regards
Stefan

[Stefan Herbrechtsmeier]

Hi Adrian,

Am 24.10.19 um 13:38 schrieb adrian.f...@gmail.com:

> Hi Stefan,
>
> May be yes, because it just works.

Every path will work but we should use a common one because most people
will use it. I'm wonder why you use the libdir instead of the datadir.

Regards
Stefan

[adrian.f...@gmail.com]

Am Donnerstag, 24. Oktober 2019 14:13:13 UTC+2 schrieb Stefan Herbrechtsmeier:

Hi Adrian,

Am 24.10.19 um 12:43 schrieb adrian....@gmail.com:

> Hi Stefan,
>
> There is an option in Kconfig but this option is not useful for a Yocto
> build system.

Why?

Couldn't you append the value to the .config?

The important thing is that Yocto must be the master of this information. Kbuild or the user (via menuconfig) do not have the information. My assumption is that the Kbuild system has menuconfig as the only configure input. There is nothing comparable to e.g. cmake -Dfoo=bar for the KBuild system. If you could explain me how to pass variables to the configure step of the Kbuild system, I would of course agree with you.

> Therefore the default value of Kbuild allows to provide
> the value like done in the line you are referring.
> systemd_system_unitdir is a system specific variable provided by Yocto.
> Every other value as the one set by this line, would break almost
> everything here. What's the advantage of a configuration flag where
> exactly one value is valid? Or what is the other value you would like to
> configure?

The problem is the break of the common design. You have three step:
configure, build, install. You break this concept because you set a
configuration option during install. All other build tools (autotools,
cmake, meson) use the configuration step to configure the installation step.

For example cmake takes the PREFIX variable as an install parameter. It's not exactly the same, but quite similar.

Regards,

Adrian

 

Regards
   Stefan

[Stefan Herbrechtsmeier]

Hi Adrian,

Am 24.10.19 um 16:32 schrieb adrian.f...@gmail.com:

> Am Donnerstag, 24. Oktober 2019 14:13:13 UTC+2 schrieb Stefan
> Herbrechtsmeier:
>
> Hi Adrian,
>

> Am 24.10.19 um 12:43 schrieb adrian....@gmail.com <javascript:>:

> > Hi Stefan,
> >
> > There is an option in Kconfig but this option is not useful for a
> Yocto
> > build system.
>
> Why?
>
> Couldn't you append the value to the .config?
>
> The important thing is that Yocto must be the master of this
> information. Kbuild or the user (via menuconfig) do not have the
> information. My assumption is that the Kbuild system has menuconfig as
> the only configure input. There is nothing comparable to e.g. cmake
> -Dfoo=bar for the KBuild system. If you could explain me how to pass
> variables to the configure step of the Kbuild system, I would of course
> agree with you.

Check the kernel-yocto.bbclass as example.

do_configure_append() {
echo "# Global settings from swupdate recipe" >> ${B}/.config
echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${SYSTEMD_SYSTEM_UNITDIR}\""
>> ${B}/.config

}

>
>
> > Therefore the default value of Kbuild allows to provide
> > the value like done in the line you are referring.
> > systemd_system_unitdir is a system specific variable provided by
> Yocto.
> > Every other value as the one set by this line, would break almost
> > everything here. What's the advantage of a configuration flag where
> > exactly one value is valid? Or what is the other value you would
> like to
> > configure?
>
> The problem is the break of the common design. You have three step:
> configure, build, install. You break this concept because you set a
> configuration option during install. All other build tools (autotools,
> cmake, meson) use the configuration step to configure the
> installation step.
>
> For example cmake takes the PREFIX variable as an install parameter.
> It's not exactly the same, but quite similar.

But isn't the PREFIX set in the configuration step?

Regards
Stefan

[Adrian Freihofer]

swupdate-www requires the swupdate-progress service from swupdate-tools
package.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-support/swupdate/swupdate.inc | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 392af31..1c863bb 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc

@@ -24,6 +24,8 @@ FILES_${PN}-lua += "${libdir}/lua/"
FILES_${PN}-www = "/www/*"

FILES_${PN} += "${libdir}/tmpfiles.d"

+RDEPENDS_${PN}-www += "${PN}-tools"
+

S = "${WORKDIR}/git/"

EXTRA_OEMAKE += " HOSTCC="${BUILD_CC}" HOSTCXX="${BUILD_CXX}" LD="${CC}" DESTDIR="${D}" V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"

--
2.11.0

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

classes/swupdate-enc.bbclass | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/swupdate-enc.bbclass b/classes/swupdate-enc.bbclass
index 5e3fe79..198ae98 100644
--- a/classes/swupdate-enc.bbclass
+++ b/classes/swupdate-enc.bbclass

@@ -13,7 +13,7 @@ swu_encrypt_file() {
key=`cat ${SWUPDATE_AES_FILE} | grep ^key | cut -d '=' -f 2`
iv=`cat ${SWUPDATE_AES_FILE} | grep ^iv | cut -d '=' -f 2`
salt=`cat ${SWUPDATE_AES_FILE} | grep ^salt | cut -d '=' -f 2`
- if [ -z ${salt} ] || [ -z ${key} ] || [ -z {iv} ];then

+ if [ -z ${salt} ] || [ -z ${key} ] || [ -z ${iv} ];then

bbfatal "SWUPDATE_AES_FILE=$SWUPDATE_AES_FILE does not contain valid keys"

[Adrian Freihofer]

Try to make the swupdate.bbclass a little bit smarter in finding the
image files added to the swu archive. The implementation is also a bit
more Yocto like. By default, files are searched automatically whereas
MACHINE specific files get priority over files without the MACHINE in
the filename.
This makes the SWUPDATE_IMAGES_NOAPPEND_MACHINE VarFlag more optional.
Most standard use cases are expected to "just work" without setting
this flag.

Add support for files in a sub-folder of DEPLOY_DIR_IMAGE.

Add documentation to the header of the swupdate.bbclass file.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

classes/swupdate.bbclass | 77 +++++++++++++++++++++++++++++++++---------------
1 file changed, 54 insertions(+), 23 deletions(-)

diff --git a/classes/swupdate.bbclass b/classes/swupdate.bbclass
index 1d74eef..79c9aae 100644
--- a/classes/swupdate.bbclass
+++ b/classes/swupdate.bbclass
@@ -7,10 +7,30 @@
# in field.
# See also http://sbabic.github.io/swupdate/
#
+# To use this class, add swupdate to the inherit clause of the update image bb file.
+# The generated output file is an swu archive ready to be uploaded to a device running
+# swupdate.
#
-# To use, add swupdate to the inherit clause and set
-# set the images (all of them must be found in deploy directory)
-# that are part of the compound image.
+# Files listed in the SRC_URI variable are added the the swu archive.
+#
+# For each entry in the SWUPDATE_IMAGES variable an image file is searched for in the
+# ${DEPLOY_DIR_IMAGE} folder and added to the swu archive. Different types of entries
+# are supported:
+# * image name(s) and fstype(s):
+# Example:
+# SWUPDATE_IMAGES = "core-image-full-cmdline"
+# SWUPDATE_IMAGES_FSTYPES[core-image-full-cmdline] = ".ext4.gz"
+# For this example either a file core-image-full-cmdline-${MACHINE}.ext4.gz or a file
+# core-image-full-cmdline.ext4.gz gets added the swu archive. Optionally the variable
+# SWUPDATE_IMAGES_NOAPPEND_MACHINE allows to explicitley define if the MACHINE name
+# must be part of the image file name or not.
+# * image file name(s)
+# Example:
+# SWUPDATE_IMAGES = "core-image-full-cmdline.ext4.gz"
+# If SWUPDATE_IMAGES_FSTYPES is not defined for an entry in SWUPDATE_IMAGES or the
+# corresponding image files cannot be found in the ${DEPLOY_DIR_IMAGE} folder, an
+# image file with exactly the name as specified in SWUPDATE_IMAGES is searched for.
+
inherit swupdate-common.bbclass

S = "${WORKDIR}/${PN}"
@@ -74,6 +94,7 @@ python do_swuimage () {
if d.getVar('SWUPDATE_SIGNING', True):
list_for_cpio.append('sw-description.sig')

+ # Add files listed in SRC_URI to the swu file
for url in fetch.urls:
local = fetch.localpath(url)
filename = os.path.basename(local)
@@ -81,30 +102,40 @@ python do_swuimage () {
shutil.copyfile(local, os.path.join(s, "%s" % filename ))
list_for_cpio.append(filename)

-# SWUPDATE_IMAGES refers to images in the DEPLOY directory
-# If they are not there, additional file can be added
-# by fetching from URLs
+ def add_image_to_swu(deploydir, imagename, s):
+ src = os.path.join(deploydir, imagename)
+ if not os.path.isfile(src):
+ return False
+ target_imagename = os.path.basename(imagename) # allow images in subfolders of DEPLOY_DIR_IMAGE
+ dst = os.path.join(s, target_imagename)
+ shutil.copyfile(src, dst)
+ list_for_cpio.append(target_imagename)
+ return True
+
+ # Search for images listed in SWUPDATE_IMAGES in the DEPLOY directory.
deploydir = d.getVar('DEPLOY_DIR_IMAGE', True)
imgdeploydir = d.getVar('IMGDEPLOYDIR', True)
-
for image in images:
fstypes = (d.getVarFlag("SWUPDATE_IMAGES_FSTYPES", image, True) or "").split()
- if not fstypes:
- fstypes = [""]
-
- for fstype in fstypes:
-
- appendmachine = d.getVarFlag("SWUPDATE_IMAGES_NOAPPEND_MACHINE", image, True)
- if appendmachine == None:
- imagebase = image + '-' + d.getVar('MACHINE', True)
- else:
- imagebase = image
-
- imagename = imagebase + fstype
- src = os.path.join(deploydir, "%s" % imagename)
- dst = os.path.join(s, "%s" % imagename)
- shutil.copyfile(src, dst)
- list_for_cpio.append(imagename)
+ if fstypes:
+ noappend_machine = d.getVarFlag("SWUPDATE_IMAGES_NOAPPEND_MACHINE", image, True)
+ if noappend_machine == False: # Search for a file explicitely with MACHINE
+ imagebases = [ image + '-' + d.getVar('MACHINE', True) ]
+ elif noappend_machine == True: # Search for a file explicitely without MACHINE
+ imagebases = [ image ]
+ else: # None, means auto mode. Just try to find an image file with MACHINE or without MACHINE
+ imagebases = [ image + '-' + d.getVar('MACHINE', True), image ]
+ for fstype in fstypes:
+ image_found = False
+ for imagebase in imagebases:
+ image_found = add_image_to_swu(deploydir, imagebase + fstype, s)
+ if image_found:
+ break
+ if not image_found:
+ bb.fatal("swupdate cannot find image file: %s" % os.path.join(deploydir, imagebase + fstype))
+ else: # Allow also complete entries like "image.ext4.gz" in SWUPDATE_IMAGES
+ if not add_image_to_swu(deploydir, image, s):
+ bb.fatal("swupdate cannot find %s image file" % image)

prepare_sw_description(d, s, list_for_cpio)

--
2.11.0

[Adrian Freihofer]

This includes the following changes:

045a618 raw_handler: handle ro block devices
5700346 Makefile: rename tools binaries
48f22c6 add .editorconfig file
e5e7e02 doc: describe REST api

75985aa Add Kconfig option for new systemd files
bdc1d3c systemd generic startup
16790d1 doc: fix broken link for talks
7c8926d ssbl_handler: fix age comparison
f130541 travis: set libwebsockets version
9409e9a Prepare 2019.11-rc1
d8d9fd4 handler: add a copy handler
21594da Add SSBL Handler
34c55f1 handlers: sort the list of modules in Makefile
ede66e7 doc: add scenarios how to use SWUpdate
a5e82b9 doc: add links to single and double copy scenarios
c744dfe Cosmetic: rename entry points in raw handler
864dedd raw handler: return error number instead of -1
e38ad73 handler: push progress status from bootloader handler
cfaec8c u-boot handler: fix removing variable
27c40c4 doc: ELC video published on YouTube
07811c7 swupdate: add pre-update command hook
da974cd doc: update list of talks with ELC 2019

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-support/swupdate/swupdate_git.bb | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb
index 3f69b87..9fea83a 100644
--- a/recipes-support/swupdate/swupdate_git.bb
+++ b/recipes-support/swupdate/swupdate_git.bb
@@ -3,5 +3,5 @@ require swupdate_tools.inc

DEFAULT_PREFERENCE = "-1"

-SRCREV ?= "a8d45381253838b34e4e035c065a1cdf429b1f09"
+SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85"
PV = "2019.04+git${SRCPV}"

--
2.11.0

[Adrian Freihofer]

In case of singed and/or encrypted images the corresponding keys and
certificates need to be installed into the image.

If the variables SWUPDATE_CMS_CERT and SWUPDATE_AES_FILE are set for
the image (not only for the image-update) as well, the required
certificate and key files get installed and the -k and the -K paramter
are added to the swupdate configuration.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

README | 9 ++++++++-
classes/swupdate-enc.bbclass | 28 ++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/README b/README
index ffc8f33..eb8904e 100644
--- a/README
+++ b/README
@@ -40,7 +40,14 @@ There are 3 signing mechanisms supported by meta-swupdate at the moment:

* Set variable: `SWUPDATE_SIGNING = "CMS"`

- * Set `SWUPDATE_CMS_CERT` to the full path of certificate file
+ * Set `SWUPDATE_CMS_CERT` to the full path of certificate file.
+ Settings this variable for the swu image (inherit swupdate) configures the
+ build system to create signed images.
+ Setting this variable for the image included in the swu archive, leads to
+ an image which is ready to verify the signature of an image in a swu archive
+ at run-time. The certificate gets installed and the -k parameter
+ gets added to the command line arguments for swupdate. This requires to
+ inherit swupdate-enc. This works with systemd but not with init scripts yet.

* Set `SWUPDATE_CMS_KEY ` to the full path of private key file

diff --git a/classes/swupdate-enc.bbclass b/classes/swupdate-enc.bbclass
index 198ae98..a7c4916 100644
--- a/classes/swupdate-enc.bbclass
+++ b/classes/swupdate-enc.bbclass
@@ -23,3 +23,31 @@ CONVERSIONTYPES += "enc"

CONVERSION_DEPENDS_enc = "openssl-native coreutils-native"
CONVERSION_CMD_enc="swu_encrypt_file ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.enc"
+
+
+# To get the keys and certificates installed the variables SWUPDATE_CMS_CERT
+# and SWUPDATE_AES_FILE need to be defined for the image and the update-image.
+install_key_and_cert() {
+ # Install the image signature verification certificate
+ if [ "x${SWUPDATE_CMS_CERT}" != "x" ]; then

+ install -d ${IMAGE_ROOTFS}${datadir}/swupdate
+ install -m 0600 ${SWUPDATE_CMS_CERT} ${IMAGE_ROOTFS}${datadir}/swupdate/image-signing.cert.pem
+ echo "SWUPDATE_ARGS=\"\${SWUPDATE_ARGS} -k ${datadir}/swupdate/image-signing.cert.pem\"" > ${WORKDIR}/80-enable-sign-images

+ install -m 0644 ${WORKDIR}/80-enable-sign-images ${IMAGE_ROOTFS}${libdir}/swupdate/conf.d
+ fi
+
+ # Install the key to decrypt update images
+ if [ "x${SWUPDATE_AES_FILE}" != "x" ]; then
+ key=`grep ^key ${SWUPDATE_AES_FILE} | cut -d '=' -f 2`

+ iv=`grep ^iv ${SWUPDATE_AES_FILE} | cut -d '=' -f 2`
+ if [ -z ${key} ] || [ -z ${iv} ]; then
+ bbfatal "SWUPDATE_AES_FILE=$SWUPDATE_AES_FILE does not contain valid keys"
+ fi
+ install -d ${IMAGE_ROOTFS}${datadir}/swupdate

+ echo "${key} ${iv}" > ${WORKDIR}/image-enc-aes.key

+ install -m 0600 ${WORKDIR}/image-enc-aes.key ${IMAGE_ROOTFS}${datadir}/swupdate
+ echo "SWUPDATE_ARGS=\"\${SWUPDATE_ARGS} -K ${datadir}/swupdate/image-enc-aes.key\"" > ${WORKDIR}/81-enable-enc-images

[Adrian Freihofer]

The devtool workflow does not work without setting PV properly.

To prefer the git version add the following line to the distro config:
PREFERRED_VERSION_libubootenv = "0.1+git%"

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-bsp/libubootenv/libubootenv_git.bb | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-bsp/libubootenv/libubootenv_git.bb b/recipes-bsp/libubootenv/libubootenv_git.bb
index 5dba3c3..6f7c080 100644
--- a/recipes-bsp/libubootenv/libubootenv_git.bb
+++ b/recipes-bsp/libubootenv/libubootenv_git.bb
@@ -1,5 +1,5 @@
require libubootenv.inc
SRCREV = "92949816720d7af2ac722016e7a5b9a85ff141bc"
-PV_append = "+git${SRCPV}"
+PV = "0.1+git${SRCPV}"

DEFAULT_PREFERENCE = "-1"
--
2.11.0

[Adrian Freihofer]

Changes from v1 to v2:
- Fix commit comments of release bump commits (2x)
- install certificates to /usr/share/swupdate
- Set systemd_system_unitdir in config step

Adrian Freihofer (12):
swupdate: simplify find images added to swu
swupdate: ensure scripts are added before images
swupdate: support signed image with variable name
libubootenv: bump git srcrev
libubootenv: git define PV
swupdate git define PV
swupdate: bump git srcrev
swupdate: add missing rdepends
swupdate: improve systemd config
swupdate: fixes in do_install
swupdate-enc: add missing $
swupdate: install key, cert

README | 9 +-
classes/swupdate-common.bbclass | 8 +-
classes/swupdate-enc.bbclass | 30 ++++++-
classes/swupdate.bbclass | 100 +++++++++++++++------
recipes-bsp/libubootenv/libubootenv_git.bb | 4 +-

.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0

recipes-support/swupdate/swupdate.inc | 70 ++++++++-------
recipes-support/swupdate/swupdate_2019.04.bb | 28 +++++-
recipes-support/swupdate/swupdate_git.bb | 8 +-
recipes-support/swupdate/swupdate_tools.inc | 24 -----
14 files changed, 191 insertions(+), 90 deletions(-)

rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)

delete mode 100644 recipes-support/swupdate/swupdate_tools.inc

--
2.11.0

[Adrian Freihofer]

This changes the filenames of the tools binaries for several reasons:
- Binaries should not be named "client" or "progress"
(also not accepted by Debian upstream)
- Inconsistent with names referred in the service files

The swupdate_tools.inc file gets merged into swupdate.inc file. By
removing the tools file some bugs are fixed:
- The tools binaries were installed twice.
- do_compile from swupdate.inc was over written resulting in wired
behavior
- swupdate-progress.service file was part of swupdate package were the
corresponding swupdate-progress binary was part of the tools package.

The tools are now installed by the "make install" target of swupdate's
Makefile. The related code here in meta-swupdate gets removed.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-support/swupdate/swupdate.inc | 18 +++++++++++++-----
recipes-support/swupdate/swupdate_2019.04.bb | 20 +++++++++++++++++++-
recipes-support/swupdate/swupdate_git.bb | 1 -
recipes-support/swupdate/swupdate_tools.inc | 24 ------------------------
4 files changed, 32 insertions(+), 31 deletions(-)
delete mode 100644 recipes-support/swupdate/swupdate_tools.inc

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 5189078..2df98a4 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -12,14 +12,22 @@ SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \
file://swupdate \
"

+PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools"
INSANE_SKIP_${PN} = "ldflags"
-PACKAGES =+ "${PN}-www ${PN}-lua"
+INSANE_SKIP_${PN}-tools = "ldflags"

FILES_${PN}-lua += "${libdir}/lua/"

FILES_${PN}-www = " \
${libdir}/swupdate/conf.d/*mongoose* \
/www/* \
"
+FILES_${PN}-tools = " \
+ ${bindir}/swupdate-client \
+ ${bindir}/swupdate-progress \
+ ${systemd_system_unitdir}/swupdate-progress.service \
+ ${bindir}/swupdate-hawkbitcfg \
+ ${bindir}/swupdate-sendtohawkbit \
+"
FILES_${PN} += " \
${libdir}/tmpfiles.d \
${libdir}/swupdate/* \
@@ -136,10 +144,7 @@ do_configure () {

do_compile() {
unset LDFLAGS
- oe_runmake swupdate_unstripped progress_unstripped
- cp swupdate_unstripped swupdate
- cp progress_unstripped progress
-
+ oe_runmake
}

do_install () {
@@ -164,3 +169,6 @@ SYSTEMD_SERVICE_${PN} = " \
swupdate.service \
swupdate-usb@.service \
"
+
+SYSTEMD_PACKAGES_append = " ${PN}-tools"
+SYSTEMD_SERVICE_${PN}-tools = "swupdate-progress.service"
diff --git a/recipes-support/swupdate/swupdate_2019.04.bb b/recipes-support/swupdate/swupdate_2019.04.bb
index 83785d7..5b0fb78 100644
--- a/recipes-support/swupdate/swupdate_2019.04.bb
+++ b/recipes-support/swupdate/swupdate_2019.04.bb
@@ -1,5 +1,4 @@
require swupdate.inc
-require swupdate_tools.inc

SRC_URI += " \
file://swupdate.service \
@@ -10,3 +9,22 @@ SRC_URI += " \
"

SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81"
+
+do_install_append () {
+ # Rename the binaries installed by make install
+ test -f ${D}${bindir}/progress && mv ${D}${bindir}/progress ${D}${bindir}/swupdate-progress
+ test -f ${D}${bindir}/client && mv ${D}${bindir}/client ${D}${bindir}/swupdate-client
+ test -f ${D}${bindir}/hawkbitcfg && mv ${D}${bindir}/hawkbitcfg ${D}${bindir}/swupdate-hawkbitcfg
+ test -f ${D}${bindir}/sendtohawkbit && mv ${D}${bindir}/sendtohawkbit ${D}${bindir}/swupdate-sendtohawkbit
+
+ install -d ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_system_unitdir}
+ if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+ install -d ${D}${libdir}/tmpfiles.d
+ install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf
+ install -d ${D}${sysconfdir}/udev/rules.d
+ install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
+ fi
+}
diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb
index a4289f6..8eef04e 100644
--- a/recipes-support/swupdate/swupdate_git.bb
+++ b/recipes-support/swupdate/swupdate_git.bb
@@ -1,5 +1,4 @@
require swupdate.inc
-require swupdate_tools.inc

DEFAULT_PREFERENCE = "-1"

diff --git a/recipes-support/swupdate/swupdate_tools.inc b/recipes-support/swupdate/swupdate_tools.inc
deleted file mode 100644
index d270dd4..0000000
--- a/recipes-support/swupdate/swupdate_tools.inc
+++ /dev/null
@@ -1,24 +0,0 @@
-PACKAGES =+ "${PN}-tools"
-
-INSANE_SKIP_${PN}-tools = "ldflags"
-
-FILES_${PN}-tools = "${bindir}/swupdate-client \
- ${bindir}/swupdate-progress \
- ${bindir}/swupdate-hawkbitcfg \
- ${bindir}/swupdate-sendtohawkbit"
-
-do_compile() {
- unset LDFLAGS
-
- oe_runmake
- cp swupdate_unstripped swupdate
-}
-
-do_install_append () {
-
- install -m 0755 tools/client_unstripped ${D}${bindir}/swupdate-client
- install -m 0755 tools/progress_unstripped ${D}${bindir}/swupdate-progress
- install -m 0755 tools/hawkbitcfg_unstripped ${D}${bindir}/swupdate-hawkbitcfg
- install -m 0755 tools/sendtohawkbit_unstripped ${D}${bindir}/swupdate-sendtohawkbit
-
-}
--
2.11.0

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0

recipes-support/swupdate/swupdate.inc | 50 +++++++++++-----------
recipes-support/swupdate/swupdate_2019.04.bb | 8 ++++
recipes-support/swupdate/swupdate_git.bb | 4 ++
8 files changed, 37 insertions(+), 25 deletions(-)

rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)

diff --git a/recipes-support/swupdate/swupdate/swupdate-progress.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-progress.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb.rules b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb.rules
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb@.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb@.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
diff --git a/recipes-support/swupdate/swupdate/swupdate.service b/recipes-support/swupdate/swupdate-2019.04/swupdate.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate.service
diff --git a/recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf b/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf
similarity index 100%
rename from recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf
rename to recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 1c863bb..5189078 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -10,19 +10,23 @@ inherit cml1 update-rc.d systemd pkgconfig

SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \

file://defconfig \
file://swupdate \
- file://swupdate.service \
- file://swupdate-usb.rules \
- file://swupdate-usb@.service \
- file://swupdate-progress.service \
- file://systemd-tmpfiles-swupdate.conf \
"

INSANE_SKIP_${PN} = "ldflags"

PACKAGES =+ "${PN}-www ${PN}-lua"

FILES_${PN}-lua += "${libdir}/lua/"

-FILES_${PN}-www = "/www/*"
-FILES_${PN} += "${libdir}/tmpfiles.d"
+FILES_${PN}-www = " \
+ ${libdir}/swupdate/conf.d/*mongoose* \
+ /www/* \
+"
+FILES_${PN} += " \
+ ${libdir}/tmpfiles.d \
+ ${libdir}/swupdate/* \
+ ${systemd_system_unitdir}/swupdate.socket \
+ ${systemd_system_unitdir}/swupdate.service \
+ ${systemd_system_unitdir}/swupdate-usb@.service \
+"

RDEPENDS_${PN}-www += "${PN}-tools"

@@ -118,9 +122,16 @@ python () {
}

do_configure () {
- cp ${WORKDIR}/defconfig ${S}/.config
- merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
- cml1_do_configure

+ if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then

+ grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config
+ echo "# Global settings from swupdate recipe" >> ${S}/.config
+ echo "CONFIG_SYSTEMD=y" >> ${S}/.config
+ echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config
+ else
+ cp ${WORKDIR}/defconfig ${S}/.config
+ fi
+ merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
+ cml1_do_configure
}

do_compile() {
@@ -144,23 +155,12 @@ do_install () {

install -d ${D}${sysconfdir}/init.d
install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d
-
- install -d ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_unitdir}/system
-
-
- if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
- install -d ${D}${libdir}/tmpfiles.d
- install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf
- install -d ${D}${sysconfdir}/udev/rules.d
- install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
- fi
}

INITSCRIPT_NAME = "swupdate"
INITSCRIPT_PARAMS = "defaults 70"

-SYSTEMD_SERVICE_${PN} = "swupdate.service"
-SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service swupdate-progress.service"
+SYSTEMD_SERVICE_${PN} = " \
+ swupdate.service \
+ swupdate-usb@.service \
+ "

diff --git a/recipes-support/swupdate/swupdate_2019.04.bb b/recipes-support/swupdate/swupdate_2019.04.bb
index e2eabbb..83785d7 100644
--- a/recipes-support/swupdate/swupdate_2019.04.bb
+++ b/recipes-support/swupdate/swupdate_2019.04.bb

@@ -1,4 +1,12 @@
require swupdate.inc
require swupdate_tools.inc

+SRC_URI += " \
+ file://swupdate.service \
+ file://swupdate-usb.rules \
+ file://swupdate-usb@.service \
+ file://swupdate-progress.service \
+ file://systemd-tmpfiles-swupdate.conf \
+ "
+
SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81"

diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb
index 9fea83a..a4289f6 100644
--- a/recipes-support/swupdate/swupdate_git.bb
+++ b/recipes-support/swupdate/swupdate_git.bb

@@ -5,3 +5,7 @@ DEFAULT_PREFERENCE = "-1"

SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85"
PV = "2019.04+git${SRCPV}"

[Adrian Freihofer]

Support the following in a sw-description:
filename = "@@ROOTFS_IMAGE@@";
sha256 = "@@@ROOTFS_IMAGE@@";

First the @@ROOTFS_IMAGE@@ gets replaced e.g. by @my-image. Second
@my-image gets replaced by the sha256 hash.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

classes/swupdate-common.bbclass | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/classes/swupdate-common.bbclass b/classes/swupdate-common.bbclass
index c0b302a..38f1906 100644
--- a/classes/swupdate-common.bbclass
+++ b/classes/swupdate-common.bbclass
@@ -37,22 +37,22 @@ def swupdate_expand_bitbake_variables(d, s):
for line in f:
found = False
while True:
- m = re.match(r"^(?P<before_placeholder>.+)@@(?P<bitbake_variable_name>\w+)@@(?P<after_placeholder>.+)$", line)
+ m = re.match(r"^(?P<before_placeholder>.+)@@(?P<sign_at>@?)(?P<bitbake_variable_name>\w+)@@(?P<after_placeholder>.+)$", line)
if m:
bitbake_variable_value = d.getVar(m.group('bitbake_variable_name'), True)
if bitbake_variable_value is None:
bitbake_variable_value = ""
bb.warn("BitBake variable %s not set" % (m.group('bitbake_variable_name')))
- line = m.group('before_placeholder') + bitbake_variable_value + m.group('after_placeholder')
+ line = m.group('before_placeholder') + m.group('sign_at') + bitbake_variable_value + m.group('after_placeholder')
found = True
continue
else:
- m = re.match(r"^(?P<before_placeholder>.+)@@(?P<bitbake_variable_name>.+)\[(?P<flag_var_name>.+)\]@@(?P<after_placeholder>.+)$", line)
+ m = re.match(r"^(?P<before_placeholder>.+)(?P<sign_at>@?)@@(?P<bitbake_variable_name>.+)\[(?P<flag_var_name>.+)\]@@(?P<after_placeholder>.+)$", line)
if m:
bitbake_variable_value = (d.getVarFlag(m.group('bitbake_variable_name'), m.group('flag_var_name'), True) or "")
if bitbake_variable_value is None:
bitbake_variable_value = ""
- line = m.group('before_placeholder') + bitbake_variable_value + m.group('after_placeholder')
+ line = m.group('before_placeholder') + m.group('sign_at') + bitbake_variable_value + m.group('after_placeholder')
continue

if found:
--
2.11.0

[Stefano Babic]

Hi Adrian,

On 23/10/19 23:10, Adrian Freihofer wrote:
> swupdate-www requires the swupdate-progress service from swupdate-tools
> package.
>

Why ? swupdate-progress is not mandatory. I can have swupdate-www
(Website) without swupdate-progress.

Best regards,
Stefano

> Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
> ---

> recipes-support/swupdate/swupdate.inc | 2 ++
> 1 file changed, 2 insertions(+)
>

> diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
> index 392af31..1c863bb 100644
> --- a/recipes-support/swupdate/swupdate.inc
> +++ b/recipes-support/swupdate/swupdate.inc

> @@ -24,6 +24,8 @@ FILES_${PN}-lua += "${libdir}/lua/"
> FILES_${PN}-www = "/www/*"

> FILES_${PN} += "${libdir}/tmpfiles.d"
>

> +RDEPENDS_${PN}-www += "${PN}-tools"
> +
> S = "${WORKDIR}/git/"
>
> EXTRA_OEMAKE += " HOSTCC="${BUILD_CC}" HOSTCXX="${BUILD_CXX}" LD="${CC}" DESTDIR="${D}" V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"
>

--

=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Stefano Babic]

On 24/10/19 12:38, adrian.f...@gmail.com wrote:
> Hi Stefan,
>
> That's what I've been thinking about. I only see advantages in it

Agree, I've been thinking about, too.

Regards,
Stefano

>. But I
> would prefer to do it in another merge request.
>
> Regards,
> Adrian
>
> Am Donnerstag, 24. Oktober 2019 10:45:03 UTC+2 schrieb Stefan
> Herbrechtsmeier:
>
> Am 23.10.19 um 23:10 schrieb Adrian Freihofer:
> > swupdate-www requires the swupdate-progress service from
> swupdate-tools
> > package.
>
> Should we move swupdate-progress into its own package?
>
> Regards
>    Stefan
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com

> <mailto:swupdate+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/7fc9ed98-023d-400e-88e3-5a4b0410b939%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/7fc9ed98-023d-400e-88e3-5a4b0410b939%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Stefano Babic]

Hi Adrian,

On 23/10/19 23:11, Adrian Freihofer wrote:
> Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
> ---

> classes/swupdate-enc.bbclass | 2 +-

> 1 file changed, 1 insertion(+), 1 deletion(-)
>

> diff --git a/classes/swupdate-enc.bbclass b/classes/swupdate-enc.bbclass
> index 5e3fe79..198ae98 100644
> --- a/classes/swupdate-enc.bbclass
> +++ b/classes/swupdate-enc.bbclass

> @@ -13,7 +13,7 @@ swu_encrypt_file() {
> key=`cat ${SWUPDATE_AES_FILE} | grep ^key | cut -d '=' -f 2`
> iv=`cat ${SWUPDATE_AES_FILE} | grep ^iv | cut -d '=' -f 2`
> salt=`cat ${SWUPDATE_AES_FILE} | grep ^salt | cut -d '=' -f 2`
> - if [ -z ${salt} ] || [ -z ${key} ] || [ -z {iv} ];then

> + if [ -z ${salt} ] || [ -z ${key} ] || [ -z ${iv} ];then

> bbfatal "SWUPDATE_AES_FILE=$SWUPDATE_AES_FILE does not contain valid keys"

> fi
> openssl enc -aes-256-cbc -in ${input} -out ${output} -K ${key} -iv ${iv} -S ${salt}
>

Thanks for fixing this bug.

Acked-by: Stefano Babic <sba...@denx.de>

Best regards,
Stefano Babic

[adrian.f...@gmail.com]

Hi Stefano

Am Samstag, 26. Oktober 2019 22:16:18 UTC+2 schrieb Stefano Babic:

Hi Adrian,

On 23/10/19 23:10, Adrian Freihofer wrote:
> swupdate-www requires the swupdate-progress service from swupdate-tools
> package.
>

Why ? swupdate-progress is not mandatory. I can have swupdate-www
(Website) without swupdate-progress.

Please ignore this patch. I did not see this use case. I just realized that some features of swupdate-www did not work without haveing swupdate-progress as well.

Regards,

Adrian

Best regards,
Stefano

> Signed-off-by: Adrian Freihofer <adrian....@siemens.com>

[Stefano Babic]

Applied to -master and -warrior, thanks !

Best regards,
Stefano Babic

[Stefano Babic]

Hi Adrian,

On 24/10/19 20:56, Adrian Freihofer wrote:

> Support the following in a sw-description:
> filename = "@@ROOTFS_IMAGE@@";
> sha256 = "@@@ROOTFS_IMAGE@@";
>

Ok, but this is how it works now, see my previous e-mail. Can you better
explain the issue you found ? I do not know why it is not working on
your side.

Best regards,
Stefano Babic

[Stefano Babic]

Hi Adrian,

On 24/10/19 20:56, Adrian Freihofer wrote:

> The devtool workflow does not work without setting PV properly.
>
> To prefer the git version add the following line to the distro config:
> PREFERRED_VERSION_libubootenv = "0.1+git%"
>

I think PREFERRED_VERSION_libubootenv = "%git%" should also work.

> Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
> ---
> recipes-bsp/libubootenv/libubootenv_git.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-bsp/libubootenv/libubootenv_git.bb b/recipes-bsp/libubootenv/libubootenv_git.bb
> index 5dba3c3..6f7c080 100644
> --- a/recipes-bsp/libubootenv/libubootenv_git.bb
> +++ b/recipes-bsp/libubootenv/libubootenv_git.bb
> @@ -1,5 +1,5 @@
> require libubootenv.inc
> SRCREV = "92949816720d7af2ac722016e7a5b9a85ff141bc"
> -PV_append = "+git${SRCPV}"
> +PV = "0.1+git${SRCPV}"
>
> DEFAULT_PREFERENCE = "-1"
>

Acked-by : Stefano Babic <sba...@denx.de>

I will merge this into -master.

Best regards,
Stefano Babic

[Stefano Babic]

On 24/10/19 20:56, Adrian Freihofer wrote:

[Stefano Babic]

Hi Adrian,

On 24/10/19 20:56, Adrian Freihofer wrote:

> In case of singed and/or encrypted images the corresponding keys and
> certificates need to be installed into the image.
>
> If the variables SWUPDATE_CMS_CERT and SWUPDATE_AES_FILE are set for
> the image (not only for the image-update) as well, the required
> certificate and key files get installed and the -k and the -K paramter
> are added to the swupdate configuration.

Of course, when we use encrypted artifacts and or signed image, the next
step is where the keys must be stored.

Your proposal covers just one use case. In fact, the keys (CMS
certificate or RSA public key and AES symmetric key) are stored into the
rootfs. However, there are a lot of cases where the keys are not part of
the rootfs. Let's start with another use case. Someone wants to be able
to upgrade the certificate, someone not. For the frst case, putting them
into rootfs is ok, because each update will mean to renew the
certificates. Someone else wants to fix the certificate and push it on a
read-only device, that are set by the factory. For example, on I2C or
SPI Eprom, and the write pin of the chip is not connected. This case
will be forbidden with your changes, because certificate and AES key are
part of rootfs. So yes, this patch makes life easier for one use case,
but it makes much difficult for some other cases. So I cannot say if
keys should be part of rootfs, it depends on requirements. It looks to
me easier if CMS / RSA / AES are put into a separate package and this
can be installed into rootfs or into another image.

Best regards,
Stefano Babic

[Stefano Babic]

On 24/10/19 20:56, Adrian Freihofer wrote:

Acked-by : Stefano Babic <sba...@denx.de>

I will merge this into -master.

Best regards,
Stefano Babic

[adrian.f...@gmail.com]

Hi Stefano

Of course, there are different ways to store the keys and certificates on the device.

Would you like to add this, if I would move it to a separate class? This would enable the user to inherit the class only if it is beneficial. Further, the class might serve as an example. Otherwise I'm totally fine with adding this to my own layer.

Regarding deploying keys in packages: I do not like to have image specific stuff deployed as packages. Packages should be compiled per DISTRO. From one DISTRO we can compile several different images. Each image might have a separate key but contains the same binary packages.

Best regards,

Adrian

 

Best regards,
Stefano Babic


>
> Signed-off-by: Adrian Freihofer <adrian....@siemens.com>

[Adrian Freihofer]

This v3 does not change the code in comparison to v2.
I hope this v3 helps to clarify the current state of merging and
supports the review process.

It removes the patches already merged to master:
- swupdate: bump git srcrev
- swupdate git define PV
- libubootenv: git define PV
- libubootenv: bump git srcrev
- swupdate-enc: add missing $

It removes the patches which should not be merged:
- ensure scripts are added before images
- support signed image with variable name
- add missing rdepends

Squasehd "fixes in do_install" into "improve systemd config".
It's may be easier to review in one.

The "install key, cert" patch slighty chagnes. The code gets added as a
new class instead of extending swupdate-enc.bbclass. This makes it more
optional. But this is also easy to maintain in a project specific layer.


Adrian Freihofer (3):
swupdate: improve systemd config

swupdate: simplify find images added to swu

swupdate: install key, cert

classes/swupdate-img-add.bbclass | 35 ++++++++++
classes/swupdate.bbclass | 77 +++++++++++++++-------

.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0

recipes-support/swupdate/swupdate.inc | 68 ++++++++++---------
recipes-support/swupdate/swupdate_2019.04.bb | 28 +++++++-
recipes-support/swupdate/swupdate_git.bb | 5 +-
recipes-support/swupdate/swupdate_tools.inc | 24 -------
11 files changed, 158 insertions(+), 79 deletions(-)
create mode 100644 classes/swupdate-img-add.bbclass

rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)

[Adrian Freihofer]

Try to make the swupdate.bbclass a little bit smarter in finding the
image files added to the swu archive. The implementation is also a bit
more Yocto like. By default, files are searched automatically whereas
MACHINE specific files get priority over files without the MACHINE in
the filename.
This makes the SWUPDATE_IMAGES_NOAPPEND_MACHINE VarFlag more optional.
Most standard use cases are expected to "just work" without setting
this flag.

Add support for files in a sub-folder of DEPLOY_DIR_IMAGE.

Add documentation to the header of the swupdate.bbclass file.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

[Adrian Freihofer]

fixes in do_install

This changes the filenames of the tools binaries for several reasons:
- Binaries should not be named "client" or "progress"
(also not accepted by Debian upstream)
- Inconsistent with names referred in the service files

The swupdate_tools.inc file gets merged into swupdate.inc file. By
removing the tools file some bugs are fixed:
- The tools binaries were installed twice.
- do_compile from swupdate.inc was over written resulting in wired
behavior
- swupdate-progress.service file was part of swupdate package were the
corresponding swupdate-progress binary was part of the tools package.

The tools are now installed by the "make install" target of swupdate's
Makefile. The related code here in meta-swupdate gets removed.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0

recipes-support/swupdate/swupdate.inc | 68 ++++++++++++----------
recipes-support/swupdate/swupdate_2019.04.bb | 28 ++++++++-
recipes-support/swupdate/swupdate_git.bb | 5 +-
recipes-support/swupdate/swupdate_tools.inc | 24 --------
9 files changed, 69 insertions(+), 56 deletions(-)

rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)
delete mode 100644 recipes-support/swupdate/swupdate_tools.inc

diff --git a/recipes-support/swupdate/swupdate/swupdate-progress.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-progress.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb.rules b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb.rules
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb@.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb@.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
diff --git a/recipes-support/swupdate/swupdate/swupdate.service b/recipes-support/swupdate/swupdate-2019.04/swupdate.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate.service
diff --git a/recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf b/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf
similarity index 100%
rename from recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf
rename to recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 392af31..1e4f92e 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd pkgconfig

SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \
file://defconfig \
file://swupdate \
- file://swupdate.service \
- file://swupdate-usb.rules \
- file://swupdate-usb@.service \
- file://swupdate-progress.service \
- file://systemd-tmpfiles-swupdate.conf \
"

+PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools"
INSANE_SKIP_${PN} = "ldflags"
-PACKAGES =+ "${PN}-www ${PN}-lua"
+INSANE_SKIP_${PN}-tools = "ldflags"

FILES_${PN}-lua += "${libdir}/lua/"

-FILES_${PN}-www = "/www/*"
-FILES_${PN} += "${libdir}/tmpfiles.d"
+FILES_${PN}-www = " \
+ ${libdir}/swupdate/conf.d/*mongoose* \
+ /www/* \
+"

+FILES_${PN}-tools = " \
+ ${bindir}/swupdate-client \
+ ${bindir}/swupdate-progress \
+ ${systemd_system_unitdir}/swupdate-progress.service \
+ ${bindir}/swupdate-hawkbitcfg \
+ ${bindir}/swupdate-sendtohawkbit \

+"
+FILES_${PN} += " \
+ ${libdir}/tmpfiles.d \
+ ${libdir}/swupdate/* \
+ ${systemd_system_unitdir}/swupdate.socket \
+ ${systemd_system_unitdir}/swupdate.service \
+ ${systemd_system_unitdir}/swupdate-usb@.service \

+"

S = "${WORKDIR}/git/"

@@ -116,17 +128,21 @@ python () {

}

do_configure () {
- cp ${WORKDIR}/defconfig ${S}/.config
- merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
- cml1_do_configure
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
+ grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config
+ echo "# Global settings from swupdate recipe" >> ${S}/.config
+ echo "CONFIG_SYSTEMD=y" >> ${S}/.config
+ echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config
+ else
+ cp ${WORKDIR}/defconfig ${S}/.config
+ fi
+ merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
+ cml1_do_configure
}

do_compile() {

unset LDFLAGS
- oe_runmake swupdate_unstripped progress_unstripped
- cp swupdate_unstripped swupdate
- cp progress_unstripped progress
-
+ oe_runmake
}

do_install () {

@@ -142,23 +158,15 @@ do_install () {

install -d ${D}${sysconfdir}/init.d
install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d
-
- install -d ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_unitdir}/system
-
-
- if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
- install -d ${D}${libdir}/tmpfiles.d
- install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf
- install -d ${D}${sysconfdir}/udev/rules.d
- install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
- fi
}

INITSCRIPT_NAME = "swupdate"
INITSCRIPT_PARAMS = "defaults 70"

-SYSTEMD_SERVICE_${PN} = "swupdate.service"
-SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service swupdate-progress.service"
+SYSTEMD_SERVICE_${PN} = " \
+ swupdate.service \
+ swupdate-usb@.service \
+ "

+
+SYSTEMD_PACKAGES_append = " ${PN}-tools"
+SYSTEMD_SERVICE_${PN}-tools = "swupdate-progress.service"

diff --git a/recipes-support/swupdate/swupdate_2019.04.bb b/recipes-support/swupdate/swupdate_2019.04.bb
index e2eabbb..5b0fb78 100644
--- a/recipes-support/swupdate/swupdate_2019.04.bb
+++ b/recipes-support/swupdate/swupdate_2019.04.bb
@@ -1,4 +1,30 @@
require swupdate.inc
-require swupdate_tools.inc
+

+SRC_URI += " \
+ file://swupdate.service \
+ file://swupdate-usb.rules \
+ file://swupdate-usb@.service \
+ file://swupdate-progress.service \
+ file://systemd-tmpfiles-swupdate.conf \
+ "

SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81"
+
+do_install_append () {
+ # Rename the binaries installed by make install
+ test -f ${D}${bindir}/progress && mv ${D}${bindir}/progress ${D}${bindir}/swupdate-progress
+ test -f ${D}${bindir}/client && mv ${D}${bindir}/client ${D}${bindir}/swupdate-client
+ test -f ${D}${bindir}/hawkbitcfg && mv ${D}${bindir}/hawkbitcfg ${D}${bindir}/swupdate-hawkbitcfg
+ test -f ${D}${bindir}/sendtohawkbit && mv ${D}${bindir}/sendtohawkbit ${D}${bindir}/swupdate-sendtohawkbit
+

+ install -d ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_system_unitdir}
+ if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+ install -d ${D}${libdir}/tmpfiles.d
+ install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf
+ install -d ${D}${sysconfdir}/udev/rules.d
+ install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
+ fi
+}
diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb
index 9fea83a..8eef04e 100644
--- a/recipes-support/swupdate/swupdate_git.bb
+++ b/recipes-support/swupdate/swupdate_git.bb
@@ -1,7 +1,10 @@

require swupdate.inc
-require swupdate_tools.inc

DEFAULT_PREFERENCE = "-1"

SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85"
PV = "2019.04+git${SRCPV}"

+
+SYSTEMD_SERVICE_${PN} += " \
+ swupdate.socket \
+"

[Adrian Freihofer]

In case of singed and/or encrypted images the corresponding keys and
certificates need to be installed into the image.

If the variables SWUPDATE_CMS_CERT and SWUPDATE_AES_FILE are set for
the image (not only for the image-update) as well, the required
certificate and key files get installed and the -k and the -K paramter
are added to the swupdate configuration.

This new class covers only one simple use case: Installing into rootfs.
There are several other use cases supported by swupdate whic are not
yet addressed by this new class.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

classes/swupdate-img-add.bbclass | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 classes/swupdate-img-add.bbclass

diff --git a/classes/swupdate-img-add.bbclass b/classes/swupdate-img-add.bbclass
new file mode 100644
index 0000000..43c7464
--- /dev/null
+++ b/classes/swupdate-img-add.bbclass
@@ -0,0 +1,35 @@
+# This class might be inherited by an image which gets included into an swu archive.
+#
+# If the variable SWUPDATE_CMS_CERT is defined, the singing certificate gets installed
+# into the image and swupdate gets configured (-k) to verify the signature of swu updates.
+#
+# If the variable SWUPDATE_AES_FILE is defined, the AES key for decrypting encrypted
+# update images gets installed into the rootfs and swupdate gets configured (-K) to
+# use the key for decryting images.
+#
+# This works with systemd but not with init scripts yet.
+

2.11.0

[Stefano Babic]

Hi Adrian,

On 29/10/19 11:01, Adrian Freihofer wrote:
> In case of singed and/or encrypted images the corresponding keys and
> certificates need to be installed into the image.
>
> If the variables SWUPDATE_CMS_CERT and SWUPDATE_AES_FILE are set for
> the image (not only for the image-update) as well, the required
> certificate and key files get installed and the -k and the -K paramter
> are added to the swupdate configuration.
>

SWUpdate supports RSA and CMS verification - the RSA case is not touched
by this class.

> This new class covers only one simple use case: Installing into rootfs.
> There are several other use cases supported by swupdate whic are not
> yet addressed by this new class.

Right - at least with PKI, it works different. On the target the CA
public certificate must be installed, not the own certificate.

Best regards,
Stefano

[Stefano Babic]

Hi Adrian,

On 29/10/19 11:01, Adrian Freihofer wrote:

I think this is not correct. Even if systemd is listed in the features
for DISTRO, a user can select SystemV as init manager. The check should
be based on VIRTUAL-RUNTIME_init_manager instead of DISTRO.

> + grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config
> + echo "# Global settings from swupdate recipe" >> ${S}/.config
> + echo "CONFIG_SYSTEMD=y" >> ${S}/.config
> + echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config

I understand the logic, but I have an understanding problem. In fact,
who is the master ?

In current implementation, defconfig is the master. If a user run
"bitbake -c menuconfig swupdate" or add fragments to the configuration,
this becomes the master. In fact, the current recipes do not try to
change defconfig, but set OE to reflect the values in defconfig. This is
the reason for the anonymous python function in swupdate.inc. This adds
DEPENDS to the list, quite an exception in OE. Because the list of
depends can be short or long, on depends of the configuration.

However, the single case above seems "quite" ok to me. CONFIG_SYSTEMD
comes from defconfig. But should not be responsibility of the user to
set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ?

A question that was raised more as one time on this list is if we have
to split services into different packages. Not only swupdate-progress,
but what about if a USB update is forbidden on the target ? A project
should be able to decide which services should be installed and which not.

Agree to remove swupdate-tools.inc, it was introduced once to be
compatible with previous versions. We do not need to bother anymore.

[Stefano Babic]

Hi Adrian,

On 29/10/19 11:01, Adrian Freihofer wrote:

> Try to make the swupdate.bbclass a little bit smarter in finding the
> image files added to the swu archive. The implementation is also a bit
> more Yocto like. By default, files are searched automatically whereas
> MACHINE specific files get priority over files without the MACHINE in
> the filename.
> This makes the SWUPDATE_IMAGES_NOAPPEND_MACHINE VarFlag more optional.
> Most standard use cases are expected to "just work" without setting
> this flag.

Agree - and I have never seen a case where both files (with and without
MACHINE in name) are in DEPLOYDIR. I introduced
SWUPDATE_IMAGES_NOAPPEND_MACHINE as a trick for some files, typically
kernel (uIMage), but it is much better if the recipe finds itself the
correct one.

Looks great for me.

Acked-by: Stefano Babic <sba...@denx.de>

Best regards,
Stefano Babic

[adrian.f...@gmail.com]

Hi Stefano

> Signed-off-by: Adrian Freihofer <adrian....@siemens.com>

Will be changed with v4, thanks.

> +        grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config
> +        echo "# Global settings from swupdate recipe" >> ${S}/.config
> +        echo "CONFIG_SYSTEMD=y" >> ${S}/.config
> +        echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config

I understand the logic, but I have an understanding problem. In fact,
who is the master ?

In current implementation, defconfig is the master. If a user run
"bitbake -c menuconfig swupdate" or add fragments to the configuration,
this becomes the master. In fact, the current recipes do not try to
change defconfig, but set OE to reflect the values in defconfig. This is
the reason for the anonymous python function in swupdate.inc. This adds
DEPENDS to the list, quite an exception in OE. Because the list of
depends can be short or long, on depends of the configuration.

However, the single case above seems "quite" ok to me. CONFIG_SYSTEMD
comes from defconfig. But should not be responsibility of the user to
set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ?

I have the same question. That's the reason why I initially came up with a different implementation.

At least with Yocto, it does not make sense to ask the user about the systemd_system_unitdir variable which is in fact not configurable.

The build system knows the variable. In this case, menuconfig just enables the user to break the build, without providing any flexibility.

I would still  prefer to pass systemd_system_unitdir directly to the make install target as an environment variable.

However, I see the argument about passing variables to the configure step instead of passing a variable to the install step.

But passing variables to the configure step seems not really supported by the kbuild build system.

Patching the config file is probably the only way to define the variable during the configure step.

I think the current implementation is not wrong and it could be merged. But we could also go back to the line of code in my first patch version.

Shortly tried to implement that on top of this MR. It's easy, but not backward compatible.

Therefore, I would like to discuss this in another MR. Probably not many users are following these details here any more.

Thank you and regards,

Adrian

[Adrian Freihofer]

Changes in comparison to v3:
- check for VIRTUAL-RUNTIME_init_manager instead of DISTRO_FEATURES
- Removed the key/cert install patch. It does not cover relevant use
cases yet.

Adrian Freihofer (2):

swupdate: improve systemd config
swupdate: simplify find images added to swu

classes/swupdate.bbclass | 77 +++++++++++++++-------

.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0

recipes-support/swupdate/swupdate.inc | 68 ++++++++++---------
recipes-support/swupdate/swupdate_2019.04.bb | 28 +++++++-

recipes-support/swupdate/swupdate_git.bb | 5 +-
recipes-support/swupdate/swupdate_tools.inc | 24 -------

10 files changed, 123 insertions(+), 79 deletions(-)

rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)
delete mode 100644 recipes-support/swupdate/swupdate_tools.inc

--
2.11.0

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>

---
.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0

recipes-support/swupdate/swupdate.inc | 68 ++++++++++++----------
recipes-support/swupdate/swupdate_2019.04.bb | 28 ++++++++-
recipes-support/swupdate/swupdate_git.bb | 5 +-
recipes-support/swupdate/swupdate_tools.inc | 24 --------
9 files changed, 69 insertions(+), 56 deletions(-)

rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)
delete mode 100644 recipes-support/swupdate/swupdate_tools.inc

diff --git a/recipes-support/swupdate/swupdate/swupdate-progress.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-progress.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb.rules b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb.rules
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb@.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb@.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
diff --git a/recipes-support/swupdate/swupdate/swupdate.service b/recipes-support/swupdate/swupdate-2019.04/swupdate.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate.service
diff --git a/recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf b/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf
similarity index 100%
rename from recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf
rename to recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf
diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc

index 392af31..805416e 100644

+ if [ "${VIRTUAL-RUNTIME_init_manager}" == "systemd" ]; then

+ grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config
+ echo "# Global settings from swupdate recipe" >> ${S}/.config
+ echo "CONFIG_SYSTEMD=y" >> ${S}/.config
+ echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config

--
2.11.0

[Adrian Freihofer]

Try to make the swupdate.bbclass a little bit smarter in finding the
image files added to the swu archive. The implementation is also a bit
more Yocto like. By default, files are searched automatically whereas
MACHINE specific files get priority over files without the MACHINE in
the filename.
This makes the SWUPDATE_IMAGES_NOAPPEND_MACHINE VarFlag more optional.
Most standard use cases are expected to "just work" without setting
this flag.

Add support for files in a sub-folder of DEPLOY_DIR_IMAGE.

Add documentation to the header of the swupdate.bbclass file.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

--
2.11.0

[Stefan Herbrechtsmeier]

Hi Adrian and Stefano,

Am 02.11.19 um 22:48 schrieb adrian.f...@gmail.com:

> Hi Stefano
>
> Am Samstag, 2. November 2019 14:39:48 UTC+1 schrieb Stefano Babic:
>
> On 29/10/19 11:01, Adrian Freihofer wrote:

[snip]

> > diff --git a/recipes-support/swupdate/swupdate.inc
> b/recipes-support/swupdate/swupdate.inc
> > index 392af31..1e4f92e 100644
> > --- a/recipes-support/swupdate/swupdate.inc
> > +++ b/recipes-support/swupdate/swupdate.inc
> > @@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd pkgconfig
> >  SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https

> <http://github.com/sbabic/swupdate.git;protocol=https> \

NACK. The init manager could be image specific. It is a common pattern
do enable systemd support via DISTRO feature. We could use a variable
like PACKAGECONFIG or a option like CONFIG_SYSTEMD in the defconfig to
give the user the possibility to control it. The later leads to the
problem that a distro feature (systemd) is controlled by machine
specific file.

> > +        grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig >
> ${S}/.config
> > +        echo "# Global settings from swupdate recipe" >>
> ${S}/.config
> > +        echo "CONFIG_SYSTEMD=y" >> ${S}/.config
> > +        echo
> "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >>
> ${S}/.config
>
> I understand the logic, but I have an understanding problem. In fact,
> who is the master ?

Usually the recipe is the master in OE but this is only partially true
for kconfig recipes.

>
>
> In current implementation, defconfig is the master.

This is the problem because the defconfig couldn't depend on the distro
and machine together. Furthermore it couldn't be influence by OE variables.

> If a user run
> "bitbake -c menuconfig swupdate" or add fragments to the configuration,
> this becomes the master. In fact, the current recipes do not try to
> change defconfig, but set OE to reflect the values in defconfig.
> This is
> the reason for the anonymous python function in swupdate.inc. This adds
> DEPENDS to the list, quite an exception in OE. Because the list of
> depends can be short or long, on depends of the configuration.

What was the reason to use this exception instead of a list of
PACKAGECONFIGs and a generated configuration?

> However, the single case above seems "quite" ok to me. CONFIG_SYSTEMD
> comes from defconfig. But should not be responsibility of the user to
> set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ?

This option is managed by OE / distro and shouldn't be set via the user.
Especially not via a machine specific and distro independent file.

> I have the same question. That's the reason why I initially came up with
> a different implementation.
> At least with Yocto, it does not make sense to ask the user about the
> systemd_system_unitdir variable which is in fact not configurable.

This is a generic problem of distro specific configurations and meta
build systems. How should the configuration tool knows that some
configurations are managed by the meta build system?

> The build system knows the variable. In this case, menuconfig just
> enables the user to break the build, without providing any flexibility.

We could use "sed" to replace the value in the .config or we could use a
cfg file to make the problem visible to the user.

> I would still  prefer to pass systemd_system_unitdir directly to the
> make install target as an environment variable.

What would be next? We pass the LUAPKG directly to make and all system
directories to make install?

Please don't break common and widely-used rules because it is simple to
do so.

> However, I see the argument about passing variables to the configure
> step instead of passing a variable to the install step.
> But passing variables to the configure step seems not really supported
> by the kbuild build system.

This is the real problem and maybe the reason why OE create the
configuration on the fly from the recipe for all other build tools
(autotools, cmake, meson).

Do we really need the menuconfig or could this be handled by a list of
PACKAGECONFIGs?

Maybe it is possible to hide some options in menuconfig when it is
started by OE.

> Patching the config file is probably the only way to define the variable
> during the configure step.

Other recipes do the same.

> I think the current implementation is not wrong and it could be merged.
> But we could also go back to the line of code in my first patch version.

NACK

ACK

Regards
Stefan

[Stefano Babic]

Hi Stefan, Adrian,

You are right - this is also a common pattern.

> It is a common pattern
> do enable systemd support via DISTRO feature.

Enable is one point, if systemd is active is another point, and a
package cannot know (and should be unaware) which init manager will run.
It should provide support for both.

> We could use a variable
> like PACKAGECONFIG or a option like CONFIG_SYSTEMD in the defconfig to
> give the user the possibility to control it.

But then we want to add dependencies between SWUpdate as project itself
and the environment (with or without systemd) where it will run.
SWUpdate should be unaware of it. What about to install always systemd
related files but put them in a sparate package (swupdate-systemd) ?

> The later leads to the
> problem that a distro feature (systemd) is controlled by machine
> specific file.

Not always.

What about if systemd is in DISTRO_FEATURES for my own distro (in my
layer), but I need to build an image for another distro, for example:

DISTRO=mydistro bitbake my-imgae
DISTRO=poky bitbake my-imgae

Poky uses as default SystemV, my-distro (set in one of configuration
file) sets systemd. The above example is not built, it makes sense with
SWUpdate in case of rescue image because systemd adds a significant
overload.

>
>>      > +        grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig >
>>     ${S}/.config
>>      > +        echo "# Global settings from swupdate recipe" >>
>>     ${S}/.config
>>      > +        echo "CONFIG_SYSTEMD=y" >> ${S}/.config
>>      > +        echo
>>     "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >>
>>     ${S}/.config
>>
>>     I understand the logic, but I have an understanding problem. In fact,
>>     who is the master ?
>
> Usually the recipe is the master in OE but this is only partially true
> for kconfig recipes.

I would say it is not true - see kernel class and build for busybox.
IMHO in these cases the defconfig is the master.

>
>>
>>
>>     In current implementation, defconfig is the master.
>
> This is the problem because the defconfig couldn't depend on the distro
> and machine together. Furthermore it couldn't be influence by OE variables.
>
>>     If a user run
>>     "bitbake -c menuconfig swupdate" or add fragments to the
>> configuration,
>>     this becomes the master. In fact, the current recipes do not try to
>>     change defconfig, but set OE to reflect the values in defconfig.
>>     This is
>>     the reason for the anonymous python function in swupdate.inc. This
>> adds
>>     DEPENDS to the list, quite an exception in OE. Because the list of
>>     depends can be short or long, on depends of the configuration.
>
> What was the reason to use this exception instead of a list of
> PACKAGECONFIGs and a generated configuration?

As far as I know this does not work together with defconfig and
fragments. Using fragments is supported in meta-swupdate, as well as
"bitbake -c menuconfig swupdate". If there is a solution to not break
these workflow, we can take it.

Please consider that OE is not the only buildsystem supported, even if a
lot of changes are thought for OE and I confess I use OE for most of my
projects (but not all..). Buildroot and debian are supported and must be
supported in future, too.

>
>>     However, the single case above seems "quite" ok to me. CONFIG_SYSTEMD
>>     comes from defconfig. But should not be responsibility of the user to
>>     set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ?
>
> This option is managed by OE / distro and shouldn't be set via the user.
> Especially not via a machine specific and distro independent file.

Shouldn't does not mean forbidden or that there are not cases where it
makes sense. IMHO we have to split between CONFIG_ that are part of
SWUPdate's configuration because internal behavior of SWUpdate changes
(like CONFIG_SYSTEMD because notifications are sent), and CONFIG_ that
define environmnet where SWUpdate will run, like
CONFIG_SYSTEMD_SYSTEM_UNITDIR, because no changes in code is requested:
this just install units into the system.

>
>> I have the same question. That's the reason why I initially came up
>> with a different implementation.
>> At least with Yocto, it does not make sense to ask the user about the
>> systemd_system_unitdir variable which is in fact not configurable.
>
> This is a generic problem of distro specific configurations and meta
> build systems. How should the configuration tool knows that some
> configurations are managed by the meta build system?

Right.

>
>> The build system knows the variable. In this case, menuconfig just
>> enables the user to break the build, without providing any flexibility.
>
> We could use "sed" to replace the value in the .config or we could use a
> cfg file to make the problem visible to the user.
>
>> I would still  prefer to pass systemd_system_unitdir directly to the
>> make install target as an environment variable.
>
> What would be next? We pass the LUAPKG directly to make and all system
> directories to make install?
>
> Please don't break common and widely-used rules because it is simple to
> do so.

Not searching for easy solution, but also I do not want to break current
workflow.

>
>> However, I see the argument about passing variables to the configure
>> step instead of passing a variable to the install step.
>> But passing variables to the configure step seems not really supported
>> by the kbuild build system.
>
> This is the real problem

Exactly.

> and maybe the reason why OE create the
> configuration on the fly from the recipe for all other build tools
> (autotools, cmake, meson).>
> Do we really need the menuconfig or could this be handled by a list of
> PACKAGECONFIGs?

See above. There were already a patch for PACKAGECONFIG, but it breaks
using menuconfig and fragments.

>
> Maybe it is possible to hide some options in menuconfig when it is
> started by OE.

Mhhh...good idea. Ye, this is possible, too.

Ok, let's proceed in this way.

[adrian.f...@gmail.com]

Hi Stefano, hi Stefan

There are, in my opinion, two points which should be reconsidered.

1) Is kbuild the right build-system for swupdate?

The kbuild system is fine e.g. for the kernel or for uboot, but not ideal for a user-space application such as swupdate.

With the kbuild system I do not know the "right" answers to the questions we are currently discussing about. Compromises are required to proceed here.

Let's assume, there would be a cmake implementation providing a -D parameter for each CONFIG_ option provided by the current kbuild based implementation.

For Yocto, for each -D parameter, the corresponding PACKAGECONFIG option needs to be provided.The default config could be defined like:

PACKAGECONFIG ?= "${SWUPDATE_PACKAGECONFIG_MACHINE}".

This would probably (I've not seen something similar so far) allow to define the MACHINE specific parameters (e.g. CONFIG_UBOOT, CONFIG_MTD) in the machine.conf files.

SWUPDATE_PACKAGECONFIG_MACHINE = "uboot mtd".

Distro specific flags (e.g. CONFIG_SURICATTA_HAWKBIT) could be enabled and disabled in the distro.conf file.

PACKAGECONFIG_append_pn-swupdate = " suricatta-hawkbit"

This example is very Yocto specific. But the logic behind applies to other distros and build systems as well.

2) The init system is image specific

I absolutely disagree.

The Init Manager is a variable defined at the DISTRO level, not at the image level. Changing the init system has a potential impact on the build steps of each package. These build steps are executed before the image is assembled. They should therefore be the same for all images that can be created with one DISTRO.

If a project requires two images, for example one with systemd and one with busybox init, two DISTROs are required. Two DISTROs practically mean two separate build folders. Only the sstate cache can be shared.
With recent Yocto versions "multiconfig" was introduced. As far as I understand, it addresses exactly the use case we are discussing here.

This is probably also the reason why poky does not split packages for sysv scripts and systemd service files. Splitting packages would solve just one problem among many to make the init system an image-level configuration.

This also means that v4 of my patch is based on a misunderstanding, v3 was better. I propose to merge v3 of:

- "swupdate: improve systemd config"

- "swupdate: simplify find images added to swu"

Please let us proceed with a pragmatic implementation and solve the more fundamental problems later (e.g. kbuild or cmake or meson).

Please let us stop the discussion about fixing my patches to support different init systems on image level. This is not how Yocto is supposed to work.

Please let us focus on the best compromise to deal with kbuild. The "perfect solution" is probably not possible with kbuild.

Thank you for your valuable feedback.

Best regards,

Adrian

Am Sonntag, 3. November 2019 11:41:15 UTC+1 schrieb Stefano Babic:

Hi Stefan, Adrian,

On 03/11/19 09:48, Stefan Herbrechtsmeier wrote:
> Hi Adrian and Stefano,
>

> Am 02.11.19 um 22:48 schrieb adrian....@gmail.com:

[adrian.f...@gmail.com]

Hi Stefano, hi Stefan

After thinking about everything for another hour, I remembered a project (implemented by Stefano) which would break with my changes.

Installing always sysv and systemd scripts, but splitting the init system related files to separate packages, would probably solve this specific problem.

It would allow to build a big systemd based image and a minimal sysv based rescue image out of one DISTRO.

However, the solution would be very special. The user would have to add swupdate and one of swupdate-systemd or swupdate-svinit packages to the image.

To simplify the default use case with one image, we could add something like the following to the recipe:

# Set this variable to an empty string in a bbappend, if you need support for sysv and systemd image based systems with one common swupdate build.

# This requires to explicitly add one of swupdate-sysv or swupdate-systemd packages to IMAGE_INSTALL

SWUPDATE_ACTIVE_INIT ?= "${VIRTUAL-RUNTIME_init_manager}"

RDEPENDS_${PN} += "swupdate-${SWUPDATE_ACTIVE_INIT}"

If we slightly adapt the current sysv script to source the new /usr/lib/swupdate/swupdate.sh script instead of directly calling the swupdate binary, the sysv case would become more generic and more equal to the systemd case. Basically only the socket-file, the service-file and the init script would be split out, but not the new shell script snippets in /usr/lib/swupdate.

What do you think? Should I send a v5 based on this idea?

Regards,

Adrian

[Stefano Babic]

Hi Adrian,

On 03/11/19 18:22, adrian.f...@gmail.com wrote:
> Hi Stefano, hi Stefan
>
> After thinking about everything for another hour, I remembered a project
> (implemented by Stefano) which would break with my changes.

You anticipate my answer - I wanted to write exactly this.

> Installing always sysv and systemd scripts, but splitting the init
> system related files to separate packages, would probably solve this
> specific problem.
> It would allow to build a big systemd based image and a minimal sysv
> based rescue image out of one DISTRO.

Right - this is also the solution you find in busybox's recipe.

>
> However, the solution would be very special. The user would have to add
> swupdate and one of swupdate-systemd or swupdate-svinit packages to the
> image.

Yes, but user must already add specific swupdate packages, like
swupdate-tools or swupdate-ww. I think it is not so bad. If we compare
with QT with a big bunch of packages, it is not a lot..

> To simplify the default use case with one image, we could add something
> like the following to the recipe:
>
> # Set this variable to an empty string in a bbappend, if you need
> support for sysv and systemd image based systems with one common
> swupdate build.
> # This requires to explicitly add one of swupdate-sysv or
> swupdate-systemd packages to IMAGE_INSTALL
> SWUPDATE_ACTIVE_INIT ?= "${VIRTUAL-RUNTIME_init_manager}"
>
> RDEPENDS_${PN} += "swupdate-${SWUPDATE_ACTIVE_INIT}"
>
>
> If we slightly adapt the current sysv script to source the new
> /usr/lib/swupdate/swupdate.sh script instead of directly calling the
> swupdate binary, the sysv case would become more generic and more equal
> to the systemd case. Basically only the socket-file, the service-file
> and the init script would be split out, but not the new shell script
> snippets in /usr/lib/swupdate.
>
> What do you think? Should I send a v5 based on this idea?

Splitting in packages was also my intention. I propose:

- you send a stand-alone patch for the renaming of tools
(swupdate-client, and so on.). I will integrate this very soon because
building from TOT is currently broken.

- send a V5 related to what you proposed for review. I will answer to
your previous e-mail, too.

Regards,

[Stefano Babic]

Hi Adrian,

On 03/11/19 15:53, adrian.f...@gmail.com wrote:
> Hi Stefano, hi Stefan
>
> There are, in my opinion, two points which should be reconsidered.
>
> 1) Is kbuild the right build-system for swupdate?
>

Who knows..

> The kbuild system is fine e.g. for the kernel or for uboot, but not
> ideal for a user-space application such as swupdate.

Well, I think nobody wants to start a big discussion about replacing
build-system in kernel. Anyway, I think that the chosen build-system has
not a lot to do if the target is kernel, bootloader or user space
(application or library).

Remembering U-Boot history, U-Boot had no build system at all.
Configuration was done (and switch to Kbuild is not yet completed) with
header files. This seemed simple at the early beginning, but it is bad
to factorize and mistakes are very simple. I guess there is still a lot
of "dead" code and defines in U-Boot. When the build system was discuss
on U-Boot's ML, the logical conclusion was to take Kbuild because kernel
has it. U-Boot takes a lot of things (drivers, and so on) from kernel.
But this does not mean that U-Boot could not built using cmake, for
example.

In case of SWUpdate, I decided for Kbuild looking at busybox. As busybox
is the Swiss knife for Unix tools, SWUpdate can be a SWiss knife for an
updater. And because SWUpdate belongs to the low-level tools, a build
system near to the kernel seemed a good compromize.

Could be done with cmake ? Of course, yes. I am not so fixed to say that
nothing can be changed. But please taken into account that this requires
time, and surely this cannot happen before 2019.11 release.

> With the kbuild system I do not know the "right" answers to the
> questions we are currently discussing about. Compromises are required to
> proceed here.
>
> Let's assume, there would be a cmake implementation providing a -D
> parameter for each CONFIG_ option provided by the current kbuild based
> implementation.
> For Yocto, for each -D parameter, the corresponding PACKAGECONFIG option
> needs to be provided.The default config could be defined like:
>
> PACKAGECONFIG ?= "${SWUPDATE_PACKAGECONFIG_MACHINE}".
>

With cmake a packageconfig, the way is quite clear. There are lot of
examples.

> This would probably (I've not seen something similar so far) allow to
> define the MACHINE specific parameters (e.g. CONFIG_UBOOT, CONFIG_MTD)
> in the machine.conf files.
>
> SWUPDATE_PACKAGECONFIG_MACHINE = "uboot mtd".

Not sure here.

>
> Distro specific flags (e.g. CONFIG_SURICATTA_HAWKBIT) could be enabled
> and disabled in the distro.conf file.

No. This is project specific or image specific. It can be that an image
is defined to use Hawkbit, another image just the Webserver or local update.

>
> PACKAGECONFIG_append_pn-swupdate = " suricatta-hawkbit"
>
> This example is very Yocto specific. But the logic behind applies to
> other distros and build systems as well.

If we change this, we should be sure to support again other
buildsystems. I do not see issues with Debian-packaging, but Buildroot
must be supported again.

>
>
> 2) The init system is image specific
>
> I absolutely disagree.
>
> The Init Manager is a variable defined at the DISTRO level, not at the
> image level. Changing the init system has a potential impact on the
> build steps of each package. These build steps are executed before the
> image is assembled. They should therefore be the same for all images
> that can be created with one DISTRO.
>
> If a project requires two images, for example one with systemd and one
> with busybox init, two DISTROs are required. Two DISTROs practically
> mean two separate build folders. Only the sstate cache can be shared.
> With recent Yocto versions "multiconfig" was introduced. As far as I
> understand, it addresses exactly the use case we are discussing here.

Well, I cannot replicate as my example in previous e-mail uses two
DISTROs (mydistro with systemd and poky with SystemV).

>
> This is probably also the reason why poky does not split packages for
> sysv scripts and systemd service files. Splitting packages would solve
> just one problem among many to make the init system an image-level
> configuration.
>
>
>
> This also means that v4 of my patch is based on a misunderstanding, v3
> was better. I propose to merge v3 of:
> - "swupdate: improve systemd config"
> - "swupdate: simplify find images added to swu"
>
> Please let us proceed with a pragmatic implementation and solve the more
> fundamental problems later (e.g. kbuild or cmake or meson).

As I said: I do not stick with the build system, but it should be done
after release. The main question is what we win or we lose. I do not
currently see many issues with Kbuild, just that the integration could
be simplified. IMHO it is important that SWUpdate can adapt itself to
any project (this is nowadays), and not that projects must adapt
themselves to SWUpdate because SWUpdate (or build in meta-swupdate) does
not allow some setup. At the moment, it is very flexible even if it is
maybe not intuitive.

> Please let us stop the discussion about fixing my patches to support
> different init systems on image level. This is not how Yocto is supposed
> to work.
> Please let us focus on the best compromise to deal with kbuild. The
> "perfect solution" is probably not possible with kbuild.
>

Best regards,
Stefano

> Thank you for your valuable feedback.
> Best regards,
> Adrian
>
>
>
> Am Sonntag, 3. November 2019 11:41:15 UTC+1 schrieb Stefano Babic:
>
> Hi Stefan, Adrian,
>
> On 03/11/19 09:48, Stefan Herbrechtsmeier wrote:
> > Hi Adrian and Stefano,
> >

> > Am 02.11.19 um 22:48 schrieb adrian....@gmail.com <javascript:>:

> >> Hi Stefano
> >>
> >> Am Samstag, 2. November 2019 14:39:48 UTC+1 schrieb Stefano Babic:
> >>
> >>     On 29/10/19 11:01, Adrian Freihofer wrote:
> >
> > [snip]
> >
> >>      > diff --git a/recipes-support/swupdate/swupdate.inc
> >>     b/recipes-support/swupdate/swupdate.inc
> >>      > index 392af31..1e4f92e 100644
> >>      > --- a/recipes-support/swupdate/swupdate.inc
> >>      > +++ b/recipes-support/swupdate/swupdate.inc
> >>      > @@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd
> pkgconfig
> >>      >  SRC_URI =
> "git://github.com/sbabic/swupdate.git;protocol=https
> <http://github.com/sbabic/swupdate.git;protocol=https>

> >>     <http://github.com/sbabic/swupdate.git;protocol=https

> sba...@denx.de <javascript:>
> =====================================================================
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/bb994447-4b2e-49fd-ba30-c3ee7e07f8a2%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/bb994447-4b2e-49fd-ba30-c3ee7e07f8a2%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Adrian Freihofer]

Changes in comparison to v4:
- Improve package splitting: see commit message
- swupdate package is now agnostic to the init system at image level.
(This is really atypic for Yocto but beneficial for swupdate)
- Remove the INSANE_SKIP_${PN} = "ldflags". Seems obsolete.

Notes:
- sysv system is not run-time tested yet, but splitting seems reasonable.

Adrian Freihofer (2):
swupdate: improve systemd config

swupdate: simplify find images added to swu

classes/swupdate.bbclass | 77 ++++++++++++-----

.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0

recipes-support/swupdate/swupdate.inc | 98 +++++++++++++++-------
recipes-support/swupdate/swupdate_2019.04.bb | 28 ++++++-

recipes-support/swupdate/swupdate_git.bb | 5 +-
recipes-support/swupdate/swupdate_tools.inc | 24 ------

10 files changed, 151 insertions(+), 81 deletions(-)

rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)
delete mode 100644 recipes-support/swupdate/swupdate_tools.inc

--
2.11.0

[Adrian Freihofer]

For most projects starting swupdate requires some logic implemented
in shell scripts. Therefore swupdate is now started by a shell script

if systemd is enabled in DISTRO_FEATURES.

The new swupdate startup script sources code snippets located in
/usr/lib/swupdate/conf.d and in /etc/swupdate/conf.d. The snippets are
executed in alphabetical order. The idea is that files in /usr are added
at build time and files in /etc might be added or modified at run-time.
If two scripts, one in /etc and one in /usr have the same file name, the
script in /usr gets skipped completely. This allows to disable code in
/usr, which is probably mounted ro, at runtime.

Code snippets are automatically generated at build-time, depending on
the configuration created by swupdate's menuconfig. But code snippets
may be created manually and added via bbappend to the

/usr/lib/swupdate/conf.d folder as well.

All modes (file, webserver, webclient) of swupdate are supported.
Different variables might be defined by the code snippets added to the
named folders:
- SWUPDATE_ARGS
- SWUPDATE_WEBSERVER_ARGS
- SWUPDATE_DOWNLOAD_ARGS

Finally swupdate gets started by a line similar to:

exec /usr/bin/swupdate $SWUPDATE_ARGS \
-w "$SWUPDATE_WEBSERVER_ARGS" \
-u "$SWUPDATE_DOWNLOAD_ARGS"

The default set of configuraton and service files is now installed by
the "make install" target of the swupdate Makefile. The service files
which are not used for the latest git version of swupdate are moved
to swupdate-2019.04 folder.

Fixes in do_install
- This changes the filenames of the tools binaries for several reasons:

- Binaries should not be named "client" or "progress"
(also not accepted by Debian upstream)
- Inconsistent with names referred in the service files

- The swupdate_tools.inc file gets merged into swupdate.inc file. By

removing the tools file some bugs are fixed:
- The tools binaries were installed twice.
- do_compile from swupdate.inc was over written resulting in wired
behavior
- swupdate-progress.service file was part of swupdate package were
the corresponding swupdate-progress binary was part of the tools
package.

Improve package splitting
- New packages are: swupdate-client, swupdate-progress, swupdate-usb,
swupdate-tools-hawkbit.
- Additionally swupdate-sd, swupdate-sv, swupdate-usb-sd and
swupdate-progress-sd have been introduced. The purpose of the -sd
and -sv packages is to provide the systemd service files or the
sysv init scripts. Splitting the init scripts and service files is
very atypical for Yocto, but it offers the flexibility to build a
second minimal rescue image with sysv, just capable to run swupdate,
out of the same DISTRO.
By default (if not changed by a bbappend file) the rdepends are
set e.g. from swupdate-usb to swupdate-sd, if systemd is enabled.
- The swupdate-tools package is an empty meta package now. It provides
backward compatibility for setups installing swupdate-tools. It
depends on swupdate-client, swupdate-progress, swupdate-usb,
swupdate-tools-hawkbit packages.

Remove the INSANE_SKIP_${PN} = "ldflags". Seems obsolete.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

.../swupdate-progress.service | 0
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 0
.../systemd-tmpfiles-swupdate.conf | 0
recipes-support/swupdate/swupdate.inc | 98 +++++++++++++++-------
recipes-support/swupdate/swupdate_2019.04.bb | 28 ++++++-
recipes-support/swupdate/swupdate_git.bb | 5 +-
recipes-support/swupdate/swupdate_tools.inc | 24 ------

9 files changed, 97 insertions(+), 58 deletions(-)

rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%)
rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%)
delete mode 100644 recipes-support/swupdate/swupdate_tools.inc

diff --git a/recipes-support/swupdate/swupdate/swupdate-progress.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-progress.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb.rules b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb.rules
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
diff --git a/recipes-support/swupdate/swupdate/swupdate-usb@.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate-usb@.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
diff --git a/recipes-support/swupdate/swupdate/swupdate.service b/recipes-support/swupdate/swupdate-2019.04/swupdate.service
similarity index 100%
rename from recipes-support/swupdate/swupdate/swupdate.service
rename to recipes-support/swupdate/swupdate-2019.04/swupdate.service
diff --git a/recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf b/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf
similarity index 100%
rename from recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf
rename to recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 392af31..238d96a 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -10,19 +10,53 @@ inherit cml1 update-rc.d systemd pkgconfig
SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \

file://defconfig \
file://swupdate \
- file://swupdate.service \
- file://swupdate-usb.rules \
- file://swupdate-usb@.service \
- file://swupdate-progress.service \
- file://systemd-tmpfiles-swupdate.conf \
"

-INSANE_SKIP_${PN} = "ldflags"

-PACKAGES =+ "${PN}-www ${PN}-lua"

-
+PACKAGES =+ " \
+ ${PN}-client \
+ ${PN}-lua \
+ ${PN}-progress \
+ ${PN}-progress-sd \
+ ${PN}-sd \
+ ${PN}-sv \
+ ${PN}-tools \
+ ${PN}-tools-hawkbit \
+ ${PN}-usb \
+ ${PN}-usb-sd \
+ ${PN}-www \
+"
+
+FILES_${PN}-client = "${bindir}/swupdate-client"

FILES_${PN}-lua += "${libdir}/lua/"
-FILES_${PN}-www = "/www/*"
-FILES_${PN} += "${libdir}/tmpfiles.d"

+FILES_${PN}-progress = "${bindir}/swupdate-progress"
+FILES_${PN}-progress-sd = "${systemd_system_unitdir}/swupdate-progress.service"
+FILES_${PN}-sd = " \

+ ${systemd_system_unitdir}/swupdate.socket \
+ ${systemd_system_unitdir}/swupdate.service \
+"

+FILES_${PN}-sv = "${sysconfdir}/init.d/*"
+FILES_${PN}-usb = "${sysconfdir}/udev/rules.d/swupdate-usb.rules"
+FILES_${PN}-usb-sd = "${systemd_system_unitdir}/swupdate-usb@.service"
+FILES_${PN}-tools-hawkbit = " \

+ ${bindir}/swupdate-hawkbitcfg \
+ ${bindir}/swupdate-sendtohawkbit \
+"
+FILES_${PN} += " \
+ ${libdir}/tmpfiles.d \
+ ${libdir}/swupdate/* \
+"

+FILES_${PN}-www = " \
+ ${libdir}/swupdate/conf.d/*mongoose* \
+ /www/* \
+"
+

+RDEPENDS_${PN}-progress += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'swupdate-progress-sd', '', d)}"
+RDEPENDS_${PN}-usb += "${PN}-client ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'swupdate-usb-sd', '', d)}"
+RDEPENDS_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'swupdate-sd', 'swupdate-sv', d)}"
+
+# The tools package is deprecated, it is an empty meta package for backward compatibility
+RDEPENDS_${PN}-tools += "${PN}-client ${PN}-progress ${PN}-tools-hawkbit ${PN}-usb"

+

S = "${WORKDIR}/git/"

@@ -116,17 +150,20 @@ python () {

}

do_configure () {
- cp ${WORKDIR}/defconfig ${S}/.config
- merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
- cml1_do_configure

+ # Always install systemd support and the swupdate.sh shell wrapper.
+ # This allows to build swupdate packages init manager agnostic and splitt the file to separate packages.

+ grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config
+ echo "# Global settings from swupdate recipe" >> ${S}/.config
+ echo "CONFIG_SYSTEMD=y" >> ${S}/.config
+ echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config

+

+ merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
+ cml1_do_configure
}

do_compile() {
unset LDFLAGS
- oe_runmake swupdate_unstripped progress_unstripped
- cp swupdate_unstripped swupdate
- cp progress_unstripped progress
-
+ oe_runmake
}

do_install () {

@@ -142,23 +179,20 @@ do_install () {

install -d ${D}${sysconfdir}/init.d
install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d
-
- install -d ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_unitdir}/system
- install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_unitdir}/system
-
-
- if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
- install -d ${D}${libdir}/tmpfiles.d
- install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf
- install -d ${D}${sysconfdir}/udev/rules.d
- install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
- fi
}

INITSCRIPT_NAME = "swupdate"
INITSCRIPT_PARAMS = "defaults 70"

-SYSTEMD_SERVICE_${PN} = "swupdate.service"
-SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service swupdate-progress.service"

+SYSTEMD_PACKAGES_append = " ${PN}-sd ${PN}-progress-sd ${PN}-usb-sd"
+SYSTEMD_SERVICE_${PN}-sd = "swupdate.service"
+SYSTEMD_SERVICE_${PN}-progress-sd = "swupdate-progress.service"
+SYSTEMD_SERVICE_${PN}-usb-sd = "swupdate-usb@.service"
+
+# Prevents the systemd.bbclass from deleting scripts or service files.
+rm_systemd_unitdir () {
+ return 0
+}
+rm_sysvinit_initddir () {
+ return 0
+}

diff --git a/recipes-support/swupdate/swupdate_2019.04.bb b/recipes-support/swupdate/swupdate_2019.04.bb
index e2eabbb..5b0fb78 100644
--- a/recipes-support/swupdate/swupdate_2019.04.bb
+++ b/recipes-support/swupdate/swupdate_2019.04.bb
@@ -1,4 +1,30 @@
require swupdate.inc
-require swupdate_tools.inc
+
+SRC_URI += " \
+ file://swupdate.service \
+ file://swupdate-usb.rules \
+ file://swupdate-usb@.service \
+ file://swupdate-progress.service \
+ file://systemd-tmpfiles-swupdate.conf \
+ "

SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81"
+
+do_install_append () {
+ # Rename the binaries installed by make install
+ test -f ${D}${bindir}/progress && mv ${D}${bindir}/progress ${D}${bindir}/swupdate-progress
+ test -f ${D}${bindir}/client && mv ${D}${bindir}/client ${D}${bindir}/swupdate-client
+ test -f ${D}${bindir}/hawkbitcfg && mv ${D}${bindir}/hawkbitcfg ${D}${bindir}/swupdate-hawkbitcfg
+ test -f ${D}${bindir}/sendtohawkbit && mv ${D}${bindir}/sendtohawkbit ${D}${bindir}/swupdate-sendtohawkbit
+

+ install -d ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_system_unitdir}

+ if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then

- cp swupdate_unstripped swupdate
-}

[Adrian Freihofer]

Try to make the swupdate.bbclass a little bit smarter in finding the
image files added to the swu archive. The implementation is also a bit
more Yocto like. By default, files are searched automatically whereas
MACHINE specific files get priority over files without the MACHINE in
the filename.
This makes the SWUPDATE_IMAGES_NOAPPEND_MACHINE VarFlag more optional.
Most standard use cases are expected to "just work" without setting
this flag.

Add support for files in a sub-folder of DEPLOY_DIR_IMAGE.

Add documentation to the header of the swupdate.bbclass file.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

[Stefano Babic]

Hi Adrian,

after some tests on projects using SysVInit als init manager, I applied
your patches with a restriction:

With this, SWUpdate cannot be built. Suricatta includes header from
systemd and because systemd is not in DEPENDS (and it cannot be because
there is no systemd on this device), compieler stops with error.

So I have currently set again do_configure() as before and I can build
clean. A deeper test I will do in next days, because on this device I
have replaced (as I am used to) the startup script with an own one.

The issue above can be solved on follow-up patch - at the moment, I am
glad to provide a clean build with current TOT and meta-swupdate.

Best regards,
Stefano

[Adrian Freihofer]

Hi Stefano

!!!!! This v6 is probably not ready for merging. It's not tested yet. !!!!!!
I'm sending this to get your opinion about the idea in general.

Probably we should go one step back and remove the -sd / -sv packages again.
It seems simply not possible to provide one common binary package for a systemd
and a sysv based systems out of one DISTRO. The clean Yocto way is to have two
DISTROs; one configured with systemd and one configured with sysv.

However, one more idea came to my mind, how we could get rid of the systemd
dependency, even if swupdate is built as part of a systemd enabled DISTRO.
We might add a second variant of the recipe. The second patch is a first proof
of concept implementation. Let me know if you have any concerns about the idea.
Otherwise I will test it further.

Thank you for testing and merging v5.

Best regards,
Adrian

Adrian Freihofer (2):
swupdate: back to init system specific packaging
swupdate-rescue: add separate package

.../swupdate/{swupdate => files}/swupdate | 0
recipes-support/swupdate/swupdate-rescue/defconfig | 100 +++++++++++++++++++++
recipes-support/swupdate/swupdate-rescue_git.bb | 28 ++++++
recipes-support/swupdate/swupdate.inc | 58 +++++-------
recipes-support/swupdate/swupdate_git.bb | 2 +
5 files changed, 153 insertions(+), 35 deletions(-)
rename recipes-support/swupdate/{swupdate => files}/swupdate (100%)
create mode 100644 recipes-support/swupdate/swupdate-rescue/defconfig
create mode 100644 recipes-support/swupdate/swupdate-rescue_git.bb

--
2.11.0

[Stefano Babic]

Hi Adrian,

On 10/11/19 20:46, Adrian Freihofer wrote:
> Hi Stefano
>
> !!!!! This v6 is probably not ready for merging. It's not tested yet. !!!!!!
> I'm sending this to get your opinion about the idea in general.
>
> Probably we should go one step back and remove the -sd / -sv packages again.
> It seems simply not possible to provide one common binary package for a systemd
> and a sysv based systems out of one DISTRO. The clean Yocto way is to have two
> DISTROs; one configured with systemd and one configured with sysv.
>
> However, one more idea came to my mind, how we could get rid of the systemd
> dependency, even if swupdate is built as part of a systemd enabled DISTRO.
> We might add a second variant of the recipe. The second patch is a first proof
> of concept implementation. Let me know if you have any concerns about the idea.
> Otherwise I will test it further.
>
> Thank you for testing and merging v5.
>

I am quite unhappy with the current status. In fact, I get several
broken build if systemd is not used. Several issues are due to the fact
that install for services is now done directly in SWUpdate's Makefile,
and it cannot know if they are used or not. For example, if systemd is
not used and CONFIG_SYSTEMD_SYSTEM_UNITDIR is not set, I get error
because SYSTEMD_SERVICE_swupdate is set and the service.socket is not
found. This constrain to always set CONFIG_SYSTEMD_SYSTEM_UNITDID, but
this is also nonsense. Should we not step back and move back the service
units into recipes ? This is also what the most packages in OE are doing
(service are in meta- and not in sources).

Regarding your patches: I do not think that swupdate-rescue is a good
idea. There is already a recipe for a rescue (swupdate-image) and it is
impossible to have a defconfig working for any case. In some cases, it
is not required to have a different configuration as productive systems,
in some cases is strictly required. A generalization is not possible.


Best regards,
Stefano

> Best regards,
> Adrian
>
> Adrian Freihofer (2):
> swupdate: back to init system specific packaging
> swupdate-rescue: add separate package
>
> .../swupdate/{swupdate => files}/swupdate | 0
> recipes-support/swupdate/swupdate-rescue/defconfig | 100 +++++++++++++++++++++
> recipes-support/swupdate/swupdate-rescue_git.bb | 28 ++++++
> recipes-support/swupdate/swupdate.inc | 58 +++++-------
> recipes-support/swupdate/swupdate_git.bb | 2 +
> 5 files changed, 153 insertions(+), 35 deletions(-)
> rename recipes-support/swupdate/{swupdate => files}/swupdate (100%)
> create mode 100644 recipes-support/swupdate/swupdate-rescue/defconfig
> create mode 100644 recipes-support/swupdate/swupdate-rescue_git.bb
>

--

[Adrian Freihofer]

This patches move the service files back to meta-swupdate.
As already discussed, the sysv related part is not tested yet.

To apply the patches, please do:
1. apply the patch for swupdate repo, which is available on the mailing
list (remove the service files install part)
2. update swupdate to the latest version
3. apply these two patches

Adrian Freihofer (2):
swupdate: back to init system specific packaging

swupdate: config via conf.d folder

recipes-support/swupdate/swupdate.inc | 132 +++++++++++++--------
recipes-support/swupdate/swupdate/10-mongoose-args | 1 +
recipes-support/swupdate/swupdate/swupdate | 4 +-
.../swupdate-progress.service | 5 +-
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 4 +-
recipes-support/swupdate/swupdate/swupdate.sh | 28 +++++
.../swupdate/swupdate/swupdate.socket.tmpl | 11 ++
.../tmpfiles-swupdate.conf} | 1 -
recipes-support/swupdate/swupdate_2019.04.bb | 19 ---
recipes-support/swupdate/swupdate_git.bb | 4 -
12 files changed, 128 insertions(+), 81 deletions(-)
create mode 100644 recipes-support/swupdate/swupdate/10-mongoose-args
rename recipes-support/swupdate/{swupdate-2019.04 => swupdate}/swupdate-progress.service (61%)
rename recipes-support/swupdate/{swupdate-2019.04 => swupdate}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate-2019.04 => swupdate}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate-2019.04 => swupdate}/swupdate.service (59%)
create mode 100644 recipes-support/swupdate/swupdate/swupdate.sh
create mode 100644 recipes-support/swupdate/swupdate/swupdate.socket.tmpl
rename recipes-support/swupdate/{swupdate-2019.04/systemd-tmpfiles-swupdate.conf => swupdate/tmpfiles-swupdate.conf} (60%)

--
2.11.0

[Adrian Freihofer]

This is a followup for: 135d46bc1446b49971f8f153c3cc55c2fec1e52f

Adding the systemd service files and the init scripts back to this
repository resolves the circular dependencies between menuconfig and the
Yocto build-system.

In addition the conf.d folder is now also supported for sysv init based
systems.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-support/swupdate/swupdate.inc | 85 +++++++++++++++++-----

recipes-support/swupdate/swupdate/10-mongoose-args | 1 +
recipes-support/swupdate/swupdate/swupdate | 4 +-
.../swupdate-progress.service | 5 +-
.../swupdate-usb.rules | 0
.../swupdate-usb@.service | 0
.../swupdate.service | 4 +-

recipes-support/swupdate/swupdate/swupdate.sh | 28 +++++++
.../swupdate/swupdate/swupdate.socket.tmpl | 11 +++
.../tmpfiles-swupdate.conf} | 1 -
recipes-support/swupdate/swupdate_2019.04.bb | 19 -----
recipes-support/swupdate/swupdate_git.bb | 4 -
12 files changed, 114 insertions(+), 48 deletions(-)

create mode 100644 recipes-support/swupdate/swupdate/10-mongoose-args
rename recipes-support/swupdate/{swupdate-2019.04 => swupdate}/swupdate-progress.service (61%)
rename recipes-support/swupdate/{swupdate-2019.04 => swupdate}/swupdate-usb.rules (100%)
rename recipes-support/swupdate/{swupdate-2019.04 => swupdate}/swupdate-usb@.service (100%)
rename recipes-support/swupdate/{swupdate-2019.04 => swupdate}/swupdate.service (59%)
create mode 100644 recipes-support/swupdate/swupdate/swupdate.sh
create mode 100644 recipes-support/swupdate/swupdate/swupdate.socket.tmpl
rename recipes-support/swupdate/{swupdate-2019.04/systemd-tmpfiles-swupdate.conf => swupdate/tmpfiles-swupdate.conf} (60%)

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index ad18ed2..e411c46 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -8,9 +8,17 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3"

inherit cml1 update-rc.d systemd pkgconfig

SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \

- file://defconfig \
- file://swupdate \
- "
+ file://defconfig \
+ file://swupdate \
+ file://swupdate.sh \
+ file://swupdate.service \
+ file://swupdate.socket.tmpl \

+ file://swupdate-usb.rules \
+ file://swupdate-usb@.service \
+ file://swupdate-progress.service \

+ file://tmpfiles-swupdate.conf \
+ file://10-mongoose-args \
+"

PACKAGES =+ " \
${PN}-client \
@@ -137,12 +145,32 @@ python () {
depends = d.getVar('DEPENDS', False)
d.setVar('DEPENDS', depends + ' librsync')

+ if 'CONFIG_MONGOOSE=y\n' in features:
+ d.setVar('SWUPDATE_MONGOOSE', 'true')
+ else:
+ d.setVar('SWUPDATE_MONGOOSE', 'false')
+
if 'CONFIG_MONGOOSE_WEB_API_V2=y\n' in features:
d.setVar('SWUPDATE_WWW', 'webapp')

if 'CONFIG_BOOTLOADER_EBG=y\n' in features:
depends = d.getVar('DEPENDS', False)
d.setVar('DEPENDS', depends + ' efibootguard')
+
+ # Values not used here might be used in a bbappend
+ for feature in features:
+ if feature.startswith('CONFIG_SOCKET_CTRL_PATH='):
+ ctrl_path = feature.split('=')[1].strip()
+ d.setVar('SWUPDATE_SOCKET_CTRL_PATH', ctrl_path)
+ elif feature.startswith('CONFIG_SOCKET_PROGRESS_PATH='):
+ prog_path = feature.split('=')[1].strip()
+ d.setVar('SWUPDATE_SOCKET_PROGRESS_PATH', prog_path)
+ elif feature.startswith('CONFIG_HW_COMPATIBILITY_FILE='):
+ hwrev_file = feature.split('=')[1].strip()
+ d.setVar('SWUPDATE_HW_COMPATIBILITY_FILE', hwrev_file)
+ elif feature.startswith('CONFIG_SW_VERSIONS_FILE='):
+ swver_file = feature.split('=')[1].strip()
+ d.setVar('SWUPDATE_SW_VERSIONS_FILE', swver_file)
}

do_configure () {
@@ -152,29 +180,50 @@ do_configure () {
}

do_compile() {
- unset LDFLAGS
- oe_runmake
+ unset LDFLAGS
+ oe_runmake
}

do_install () {
-
- oe_runmake install
-
- install -m 0755 -d ${D}/www
- if [ -d ${S}/web-app ];then
- cp -R --no-dereference --preserve=mode,links -v ${S}/examples/www/v2/* ${D}/www
- else
- install -m 0755 ${S}/www/* ${D}/www
- fi
-
- install -d ${D}${sysconfdir}/init.d
- install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d
+ oe_runmake install
+
+ install -m 0755 -d ${D}/www
+ if [ -d ${S}/web-app ];then
+ cp -R --no-dereference --preserve=mode,links -v ${S}/examples/www/v2/* ${D}/www
+ else
+ install -m 0755 ${S}/www/* ${D}/www
+ fi
+
+ install -d ${D}${sysconfdir}/init.d
+ install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d
+
+ # shell based configuration loader allows to place code snippets into this folder
+ install -d ${D}${libdir}/swupdate/conf.d
+ install -m 755 ${WORKDIR}/swupdate.sh ${D}${libdir}/swupdate
+ if ${SWUPDATE_MONGOOSE}; then
+ install -m 644 ${WORKDIR}/10-mongoose-args ${D}${libdir}/swupdate/conf.d/
+ fi
+ install -d ${D}${systemd_unitdir}/system

+ install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_system_unitdir}

+ install -m 644 ${WORKDIR}/swupdate.socket.tmpl ${D}${systemd_system_unitdir}/swupdate.socket
+ sed -e "s,@@SWUPDATE_SOCKET_CTRL_PATH@@,${SWUPDATE_SOCKET_CTRL_PATH},g" \
+ -e "s,@@SWUPDATE_SOCKET_PROGRESS_PATH@@,${SWUPDATE_SOCKET_PROGRESS_PATH},g" \
+ -i ${D}${systemd_system_unitdir}/swupdate.socket

+ install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_system_unitdir}
+ install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_system_unitdir}
+
+ if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+ install -d ${D}${libdir}/tmpfiles.d

+ install -m 0644 ${WORKDIR}/tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf

+ install -d ${D}${sysconfdir}/udev/rules.d
+ install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
+ fi
}

INITSCRIPT_NAME = "swupdate"
INITSCRIPT_PARAMS = "defaults 70"

SYSTEMD_PACKAGES = "${PN} ${PN}-progress ${PN}-usb"
-SYSTEMD_SERVICE_${PN} = "swupdate.service"
+SYSTEMD_SERVICE_${PN} = "swupdate.service swupdate.socket"
SYSTEMD_SERVICE_${PN}-progress = "swupdate-progress.service"
SYSTEMD_SERVICE_${PN}-usb = "swupdate-usb@.service"
diff --git a/recipes-support/swupdate/swupdate/10-mongoose-args b/recipes-support/swupdate/swupdate/10-mongoose-args
new file mode 100644
index 0000000..896e66b
--- /dev/null
+++ b/recipes-support/swupdate/swupdate/10-mongoose-args
@@ -0,0 +1 @@
+SWUPDATE_WEBSERVER_ARGS="-r /www ${SWUPDATE_MONGOOSE_EXTRA_ARGS:--p 8080}"
diff --git a/recipes-support/swupdate/swupdate/swupdate b/recipes-support/swupdate/swupdate/swupdate
index 5e31864..5ef894f 100644
--- a/recipes-support/swupdate/swupdate/swupdate
+++ b/recipes-support/swupdate/swupdate/swupdate
@@ -30,7 +30,7 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin

DESC="swupdate"
NAME="swupdate"
-DAEMON=/usr/bin/swupdate
+DAEMON=/usr/lib/swupdate/swupdate.sh
PIDFILE=/var/run/$NAME.pid

. /etc/init.d/functions || exit 1
@@ -57,7 +57,7 @@ do_start() {
*)
echo "Starting $DESC ..."
cd /home/root
- exec $DAEMON -v -w "-r /www $SWUPDATE_MONGOOSE_EXTRA_ARGS" $SWUPDATE_EXTRA_ARGS &
+ exec $DAEMON &
exit 0
;;
esac
diff --git a/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service b/recipes-support/swupdate/swupdate/swupdate-progress.service
similarity index 61%
rename from recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
rename to recipes-support/swupdate/swupdate/swupdate-progress.service
index de80b16..212d151 100644
--- a/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service
+++ b/recipes-support/swupdate/swupdate/swupdate-progress.service
@@ -1,6 +1,9 @@
[Unit]
Description=swupdate progress service
-Requires=swupdate.service
+Before=swupdate.service

[Service]
ExecStart=/usr/bin/swupdate-progress -r -w
+
+[Install]
+WantedBy=swupdate.service
diff --git a/recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules b/recipes-support/swupdate/swupdate/swupdate-usb.rules
similarity index 100%
rename from recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules
rename to recipes-support/swupdate/swupdate/swupdate-usb.rules
diff --git a/recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service b/recipes-support/swupdate/swupdate/swupdate-usb@.service
similarity index 100%
rename from recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service
rename to recipes-support/swupdate/swupdate/swupdate-usb@.service
diff --git a/recipes-support/swupdate/swupdate-2019.04/swupdate.service b/recipes-support/swupdate/swupdate/swupdate.service
similarity index 59%
rename from recipes-support/swupdate/swupdate-2019.04/swupdate.service
rename to recipes-support/swupdate/swupdate/swupdate.service
index b585616..a3d8d19 100644
--- a/recipes-support/swupdate/swupdate-2019.04/swupdate.service
+++ b/recipes-support/swupdate/swupdate/swupdate.service
@@ -4,9 +4,7 @@ Documentation=https://github.com/sbabic/swupdate
Documentation=https://sbabic.github.io/swupdate

[Service]
-ExecStartPre=-/usr/bin/swupdate-env
-EnvironmentFile=-/tmp/swupdate.env
-ExecStart=/usr/bin/swupdate -v -w "-r /www" $SWUPDATE_EXTRA_ARGS
+ExecStart=/usr/lib/swupdate/swupdate.sh
KillMode=mixed

[Install]
diff --git a/recipes-support/swupdate/swupdate/swupdate.sh b/recipes-support/swupdate/swupdate/swupdate.sh
new file mode 100644
index 0000000..d93ec85
--- /dev/null
+++ b/recipes-support/swupdate/swupdate/swupdate.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+# Override these variables in sourced script(s) located
+# in /usr/lib/swupdate/conf.d or /etc/swupdate/conf.d
+SWUPDATE_ARGS="-v ${SWUPDATE_EXTRA_ARGS}"
+SWUPDATE_WEBSERVER_ARGS=""
+SWUPDATE_DOWNLOAD_ARGS=""
+
+# source all files from /etc/swupdate/conf.d and /usr/lib/swupdate/conf.d/
+# A file found in /etc replaces the same file in /usr
+for f in `(test -d /usr/lib/swupdate/conf.d/ && ls -1 /usr/lib/swupdate/conf.d/; test -d /etc/swupdate/conf.d && ls -1 /etc/swupdate/conf.d) | sort -u`; do
+ if [ -f /etc/swupdate/conf.d/$f ]; then
+ . /etc/swupdate/conf.d/$f
+ else
+ . /usr/lib/swupdate/conf.d/$f
+ fi
+done
+
+# handle variable escaping in a simmple way. Use exec to forward open filedescriptors from systemd open.
+if [ "$SWUPDATE_WEBSERVER_ARGS" != "" -a "$SWUPDATE_DOWNLOAD_ARGS" != "" ]; then
+ exec /usr/bin/swupdate $SWUPDATE_ARGS -w "$SWUPDATE_WEBSERVER_ARGS" -u "$SWUPDATE_DOWNLOAD_ARGS"
+elif [ "$SWUPDATE_WEBSERVER_ARGS" != "" ]; then
+ exec /usr/bin/swupdate $SWUPDATE_ARGS -w "$SWUPDATE_WEBSERVER_ARGS"
+elif [ "$SWUPDATE_DOWNLOAD_ARGS" != "" ]; then
+ exec /usr/bin/swupdate $SWUPDATE_ARGS -d "$SWUPDATE_DOWNLOAD_ARGS"
+else
+ exec /usr/bin/swupdate $SWUPDATE_ARGS
+fi
diff --git a/recipes-support/swupdate/swupdate/swupdate.socket.tmpl b/recipes-support/swupdate/swupdate/swupdate.socket.tmpl
new file mode 100644
index 0000000..5dbcbbd
--- /dev/null
+++ b/recipes-support/swupdate/swupdate/swupdate.socket.tmpl
@@ -0,0 +1,11 @@
+[Unit]
+Description=SWUpdate socket listener
+Documentation=https://github.com/sbabic/swupdate
+Documentation=https://sbabic.github.io/swupdate
+
+[Socket]
+ListenStream=@@SWUPDATE_SOCKET_CTRL_PATH@@
+ListenStream=@@SWUPDATE_SOCKET_PROGRESS_PATH@@
+
+[Install]
+WantedBy=sockets.target
diff --git a/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf b/recipes-support/swupdate/swupdate/tmpfiles-swupdate.conf
similarity index 60%
rename from recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf
rename to recipes-support/swupdate/swupdate/tmpfiles-swupdate.conf
index b374ddc..4743672 100644
--- a/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf
+++ b/recipes-support/swupdate/swupdate/tmpfiles-swupdate.conf
@@ -1,3 +1,2 @@
X /tmp/datadst
X /tmp/scripts
-X /tmp/swupdate.env
diff --git a/recipes-support/swupdate/swupdate_2019.04.bb b/recipes-support/swupdate/swupdate_2019.04.bb
index 5b0fb78..9d1528e 100644
--- a/recipes-support/swupdate/swupdate_2019.04.bb
+++ b/recipes-support/swupdate/swupdate_2019.04.bb
@@ -1,13 +1,5 @@
require swupdate.inc

-SRC_URI += " \

- file://swupdate.service \
- file://swupdate-usb.rules \
- file://swupdate-usb@.service \
- file://swupdate-progress.service \
- file://systemd-tmpfiles-swupdate.conf \
- "

-
SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81"

do_install_append () {
@@ -16,15 +8,4 @@ do_install_append () {

test -f ${D}${bindir}/client && mv ${D}${bindir}/client ${D}${bindir}/swupdate-client

test -f ${D}${bindir}/hawkbitcfg && mv ${D}${bindir}/hawkbitcfg ${D}${bindir}/swupdate-hawkbitcfg

test -f ${D}${bindir}/sendtohawkbit && mv ${D}${bindir}/sendtohawkbit ${D}${bindir}/swupdate-sendtohawkbit

-
- install -d ${D}${systemd_system_unitdir}
- install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_system_unitdir}
- install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_system_unitdir}
- install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_system_unitdir}

- if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
- install -d ${D}${libdir}/tmpfiles.d
- install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf
- install -d ${D}${sysconfdir}/udev/rules.d
- install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/
- fi
}

diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb
index 8eef04e..5f95580 100644
--- a/recipes-support/swupdate/swupdate_git.bb
+++ b/recipes-support/swupdate/swupdate_git.bb
@@ -4,7 +4,3 @@ DEFAULT_PREFERENCE = "-1"

SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85"
PV = "2019.04+git${SRCPV}"

-
-SYSTEMD_SERVICE_${PN} += " \
- swupdate.socket \
-"
--
2.11.0

[Adrian Freihofer]

Splitting the init scripts and service files into separate packages does
not work. There are other build dependencies on systemd even if a DISTRO
with sysv init system is built.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-support/swupdate/swupdate.inc | 49 +++++++++++------------------------
1 file changed, 15 insertions(+), 34 deletions(-)

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 65df706..ad18ed2 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -16,27 +16,22 @@ PACKAGES =+ " \
${PN}-client \
${PN}-lua \
${PN}-progress \
- ${PN}-progress-sd \
- ${PN}-sd \
- ${PN}-sv \
${PN}-tools \
${PN}-tools-hawkbit \
${PN}-usb \
- ${PN}-usb-sd \
${PN}-www \

"

FILES_${PN}-client = "${bindir}/swupdate-client"
FILES_${PN}-lua += "${libdir}/lua/"

-FILES_${PN}-progress = "${bindir}/swupdate-progress"
-FILES_${PN}-progress-sd = "${systemd_system_unitdir}/swupdate-progress.service"
-FILES_${PN}-sd = " \
- ${systemd_system_unitdir}/swupdate.socket \
- ${systemd_system_unitdir}/swupdate.service \
+FILES_${PN}-progress = " \

+ ${bindir}/swupdate-progress \
+ ${systemd_system_unitdir}/swupdate-progress.service \
+"

+FILES_${PN}-usb = " \
+ ${sysconfdir}/udev/rules.d/swupdate-usb.rules \
+ ${systemd_system_unitdir}/swupdate-usb@.service \
"
-FILES_${PN}-sv = "${sysconfdir}/init.d/*"
-FILES_${PN}-usb = "${sysconfdir}/udev/rules.d/swupdate-usb.rules"
-FILES_${PN}-usb-sd = "${systemd_system_unitdir}/swupdate-usb@.service"
FILES_${PN}-tools-hawkbit = " \
${bindir}/swupdate-hawkbitcfg \
${bindir}/swupdate-sendtohawkbit \
@@ -44,15 +39,16 @@ FILES_${PN}-tools-hawkbit = " \
FILES_${PN} += " \
${libdir}/tmpfiles.d \
${libdir}/swupdate/* \

+ ${systemd_system_unitdir}/swupdate.socket \
+ ${systemd_system_unitdir}/swupdate.service \

+ ${sysconfdir}/init.d/* \
"
FILES_${PN}-www = " \
${libdir}/swupdate/conf.d/*mongoose* \
/www/* \
"

-RDEPENDS_${PN}-progress += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'swupdate-progress-sd', '', d)}"
-RDEPENDS_${PN}-usb += "${PN}-client ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'swupdate-usb-sd', '', d)}"
-RDEPENDS_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'swupdate-sd', 'swupdate-sv', d)}"

+RDEPENDS_${PN}-usb += "${PN}-client"

# The tools package is deprecated, it is an empty meta package for backward compatibility

RDEPENDS_${PN}-tools += "${PN}-client ${PN}-progress ${PN}-tools-hawkbit ${PN}-usb"
@@ -150,13 +146,6 @@ python () {
}

do_configure () {
- # Always install systemd support and the swupdate.sh shell wrapper.
- # This allows to build swupdate packages init manager agnostic and splitt the file to separate packages.
- #grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config
- #echo "# Global settings from swupdate recipe" >> ${S}/.config
- #echo "CONFIG_SYSTEMD=y" >> ${S}/.config
- #echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config

-
cp ${WORKDIR}/defconfig ${S}/.config

merge_config.sh -m .config ${@" ".join(find_cfgs(d))}

cml1_do_configure
@@ -185,15 +174,7 @@ do_install () {

INITSCRIPT_NAME = "swupdate"
INITSCRIPT_PARAMS = "defaults 70"

-SYSTEMD_PACKAGES_append = " ${PN}-sd ${PN}-progress-sd ${PN}-usb-sd"
-SYSTEMD_SERVICE_${PN}-sd = "swupdate.service"
-SYSTEMD_SERVICE_${PN}-progress-sd = "swupdate-progress.service"
-SYSTEMD_SERVICE_${PN}-usb-sd = "swupdate-usb@.service"
-
-# Prevents the systemd.bbclass from deleting scripts or service files.
-rm_systemd_unitdir () {
- return 0
-}
-rm_sysvinit_initddir () {
- return 0
-}
+SYSTEMD_PACKAGES = "${PN} ${PN}-progress ${PN}-usb"
+SYSTEMD_SERVICE_${PN} = "swupdate.service"
+SYSTEMD_SERVICE_${PN}-progress = "swupdate-progress.service"
+SYSTEMD_SERVICE_${PN}-usb = "swupdate-usb@.service"
--
2.11.0

[Adrian Freihofer]

Splitting the init scripts and service files into separate packages does
not work. There are other build dependencies on systemd even if a DISTRO
with sysv init system is built.

Signed-off-by: Adrian Freihofer <adrian.f...@siemens.com>
---

recipes-support/swupdate/swupdate.inc | 52 ++++++++++++-----------------------
1 file changed, 18 insertions(+), 34 deletions(-)

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 65df706..9f40881 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -16,27 +16,25 @@ PACKAGES =+ " \

${PN}-client \
${PN}-lua \
${PN}-progress \
- ${PN}-progress-sd \
- ${PN}-sd \
- ${PN}-sv \
${PN}-tools \
${PN}-tools-hawkbit \
${PN}-usb \
- ${PN}-usb-sd \
${PN}-www \
"

+# tools is now an empty meta package for backward compatibility
+ALLOW_EMPTY_${PN}-tools = "1"
+

FILES_${PN}-client = "${bindir}/swupdate-client"
FILES_${PN}-lua += "${libdir}/lua/"
-FILES_${PN}-progress = "${bindir}/swupdate-progress"
-FILES_${PN}-progress-sd = "${systemd_system_unitdir}/swupdate-progress.service"
-FILES_${PN}-sd = " \
- ${systemd_system_unitdir}/swupdate.socket \
- ${systemd_system_unitdir}/swupdate.service \
+FILES_${PN}-progress = " \
+ ${bindir}/swupdate-progress \
+ ${systemd_system_unitdir}/swupdate-progress.service \
+"
+FILES_${PN}-usb = " \
+ ${sysconfdir}/udev/rules.d/swupdate-usb.rules \
+ ${systemd_system_unitdir}/swupdate-usb@.service \
"
-FILES_${PN}-sv = "${sysconfdir}/init.d/*"
-FILES_${PN}-usb = "${sysconfdir}/udev/rules.d/swupdate-usb.rules"
-FILES_${PN}-usb-sd = "${systemd_system_unitdir}/swupdate-usb@.service"
FILES_${PN}-tools-hawkbit = " \
${bindir}/swupdate-hawkbitcfg \
${bindir}/swupdate-sendtohawkbit \

@@ -44,15 +42,16 @@ FILES_${PN}-tools-hawkbit = " \

FILES_${PN} += " \
${libdir}/tmpfiles.d \
${libdir}/swupdate/* \
+ ${systemd_system_unitdir}/swupdate.socket \
+ ${systemd_system_unitdir}/swupdate.service \
+ ${sysconfdir}/init.d/* \
"
FILES_${PN}-www = " \
${libdir}/swupdate/conf.d/*mongoose* \
/www/* \
"

-RDEPENDS_${PN}-progress += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'swupdate-progress-sd', '', d)}"
-RDEPENDS_${PN}-usb += "${PN}-client ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'swupdate-usb-sd', '', d)}"
-RDEPENDS_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'swupdate-sd', 'swupdate-sv', d)}"
+RDEPENDS_${PN}-usb += "${PN}-client"

# The tools package is deprecated, it is an empty meta package for backward compatibility
RDEPENDS_${PN}-tools += "${PN}-client ${PN}-progress ${PN}-tools-hawkbit ${PN}-usb"

@@ -150,13 +149,6 @@ python () {

}

do_configure () {
- # Always install systemd support and the swupdate.sh shell wrapper.
- # This allows to build swupdate packages init manager agnostic and splitt the file to separate packages.
- #grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config
- #echo "# Global settings from swupdate recipe" >> ${S}/.config
- #echo "CONFIG_SYSTEMD=y" >> ${S}/.config
- #echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config
-
cp ${WORKDIR}/defconfig ${S}/.config
merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
cml1_do_configure

@@ -185,15 +177,7 @@ do_install () {