Re: [OE-Core][RFC PATCH v3 02/13] systemd: Package udev rules explicitly
On 2020-03-27 18:25, Alex Kiernan wrote:
> udev is packaged before systemd so any wildcard inclusions in FILES will
> override later specifics. List all udev rules explicitly so that the
> systemd specific rules, packaged alongside systemd, appear in the
> correct package.
>
> Signed-off-by: Alex Kiernan
Just found that this fix broke our Plymouth based splash screen. It
seems that Plymouth relies systemd/logind style "seat" TAGS to identify
the DRM devices to show the splash screen on. So far our
initramfs-framework based initramfs just installed udev, which in turn
installed system's 71-seat.rules which set up those tags accordingly.
However, now that 71-seat.rules is no longer part of the udev package,
the "seat" TAGS isn't present anymore, and the splash screen does not
show any longer.
Not sure what the proper fix is for this, maybe creating a
systemd-udev-rules package which contains the udev rules separately, so
that they can be installed in case needed...
FWIW, I think this patch is correct. This message is more meant as a FYI
for others stumble upon such an issue and information gathering.
--
Stefan
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> meta/recipes-core/systemd/systemd_244.3.bb | 28 +-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/systemd/systemd_244.3.bb
> b/meta/recipes-core/systemd/systemd_244.3.bb
> index f0cf102dc250..809dbcb9a69b 100644
> --- a/meta/recipes-core/systemd/systemd_244.3.bb
> +++ b/meta/recipes-core/systemd/systemd_244.3.bb
> @@ -599,7 +599,33 @@ FILES_udev += "${base_sbindir}/udevd \
> ${rootlibexecdir}/udev/scsi_id \
> ${rootlibexecdir}/udev/v4l_id \
> ${rootlibexecdir}/udev/keymaps \
> - ${rootlibexecdir}/udev/rules.d/*.rules \
> + ${rootlibexecdir}/udev/rules.d/50-udev-default.rules \
> +
> ${rootlibexecdir}/udev/rules.d/60-autosuspend-chromiumos.rules \
> + ${rootlibexecdir}/udev/rules.d/60-block.rules \
> + ${rootlibexecdir}/udev/rules.d/60-cdrom_id.rules \
> + ${rootlibexecdir}/udev/rules.d/60-drm.rules \
> + ${rootlibexecdir}/udev/rules.d/60-evdev.rules \
> + ${rootlibexecdir}/udev/rules.d/60-fido-id.rules \
> + ${rootlibexecdir}/udev/rules.d/60-input-id.rules \
> + ${rootlibexecdir}/udev/rules.d/60-persistent-alsa.rules \
> + ${rootlibexecdir}/udev/rules.d/60-persistent-input.rules \
> + ${rootlibexecdir}/udev/rules.d/60-persistent-storage.rules \
> +
> ${rootlibexecdir}/udev/rules.d/60-persistent-storage-tape.rules \
> + ${rootlibexecdir}/udev/rules.d/60-persistent-v4l.rules \
> + ${rootlibexecdir}/udev/rules.d/60-sensor.rules \
> + ${rootlibexecdir}/udev/rules.d/60-serial.rules \
> + ${rootlibexecdir}/udev/rules.d/61-autosuspend-manual.rules \
> + ${rootlibexecdir}/udev/rules.d/64-btrfs.rules \
> + ${rootlibexecdir}/udev/rules.d/70-joystick.rules \
> + ${rootlibexecdir}/udev/rules.d/70-mouse.rules \
> + ${rootlibexecdir}/udev/rules.d/70-power-switch.rules \
> + ${rootlibexecdir}/udev/rules.d/70-touchpad.rules \
> + ${rootlibexecdir}/udev/rules.d/75-net-description.rules \
> + ${rootlibexecdir}/udev/rules.d/75-probe_mtd.rules \
> + ${rootlibexecdir}/udev/rules.d/78-sound-card.rules \
> + ${rootlibexecdir}/udev/rules.d/80-drivers.rules \
> + ${rootlibexecdir}/udev/rules.d/80-net-setup-link.rules \
> + ${rootlibexecdir}/udev/rules.d/90-vconsole.rules \
> ${sysconfdir}/udev \
> ${sysconfdir}/init.d/systemd-udevd \
> ${systemd_unitdir}/system/*udev* \
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#141633):
https://lists.openembedded.org/g/openembedded-core/message/141633
Mute This Topic: https://lists.openembedded.org/mt/72592771/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] ✗ patchtest: failure for Handle OFD lock flags (rev2)
I guess I should have prefixed that one with [pseudo]. -- Stefan On 2020-07-20 11:02, Patchwork wrote: > == Series Details == > > Series: Handle OFD lock flags (rev2) > Revision: 2 > URL : https://patchwork.openembedded.org/series/15665/ > State : failure > > == Summary == > > > Thank you for submitting this patch series to OpenEmbedded Core. This is > an automated response. Several tests have been executed on the proposed > series by patchtest resulting in the following failures: > > > > * Issue Series does not apply on top of target branch > [test_series_merge_on_head] > Suggested fixRebase your series on top of targeted branch > Targeted branch master (currently at 532ae127c5) > > * Patch[v2] Handle OFD lock flags > Issue Shortlog does not follow expected format > [test_shortlog_format] > Suggested fixCommit shortlog (first line of commit message) > should follow the format ": " > > > > If you believe any of these test results are incorrect, please reply to the > mailing list (openembedded-core@lists.openembedded.org) raising your concerns. > Otherwise we would appreciate you correcting the issues and submitting a new > version of the patchset if applicable. Please ensure you add/increment the > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> > [PATCH v3] -> ...). > > --- > Guidelines: > https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140802): https://lists.openembedded.org/g/openembedded-core/message/140802 Mute This Topic: https://lists.openembedded.org/mt/75678408/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] Handle OFD lock flags
Linux 3.15 and newer introduced new open file description locks. Currently pseudo prints a warning if fcntl is used with OFD locks: unknown fcntl argument 37, assuming long argument. However, calls to fcntl with a OFC lock set need a struct flock pointer. Treat F_OFD_GETLK (and friends) like F_GETLK (and friends). This issue has been observed with ostree. Comparing strace output between two runs with/without this patch shows the same fcntl calls, hence it seems not to matter in practice. Signed-off-by: Stefan Agner --- ports/linux/guts/fcntl.c | 5 + 1 file changed, 5 insertions(+) diff --git a/ports/linux/guts/fcntl.c b/ports/linux/guts/fcntl.c index 4dd9796..434c7f3 100644 --- a/ports/linux/guts/fcntl.c +++ b/ports/linux/guts/fcntl.c @@ -52,6 +52,11 @@ case F_GETLK: case F_SETLK: case F_SETLKW: +#ifdef F_OFD_GETLK + case F_OFD_GETLK: + case F_OFD_SETLK: + case F_OFD_SETLKW: +#endif rc = real_fcntl(fd, cmd, lock); break; #if defined(F_GETLK64) && (F_GETLK64 != F_GETLK) -- 2.27.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140800): https://lists.openembedded.org/g/openembedded-core/message/140800 Mute This Topic: https://lists.openembedded.org/mt/75678228/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] busybox: udhcpc: fix IPv6 support when using udhcpc
On 2020-06-16 11:50, Quentin Schulz wrote: > Hi all, > > On Wed, Jan 22, 2020 at 11:06:55AM +0100, Quentin Schulz wrote: >> > > The reason why I didn't bother to send a patch to busybox before pinging >> > > on this patch was that we're already different from the upstream >> > > simple.script >> > > so it didn't make sense to me to add the Upstream-Status: pending or >> > > something on the patch (in some ways, since it's patching the file >> > > directly and not adding a patch in SRC_URI). Anyway, digressing. Do you >> > > want a patch to be sent to busybox ML (or PR or whatever they use) >> > > before taking this patch? >> > > >> > >> > I think the problem this patch fixes is generic and somewhere the >> > script OE has is also derived from >> > that example, so while the patch in itself is enough for OE, it would >> > be better if it was in upstream too >> > perhaps one less thing to worry about when we cherry pick changes from >> > upstream script in future. >> > >> >> Agreed, I'll put it on my TODO-list. If I do not send an answer on this >> mail with the link to the PR or patch in the next week, anyone, please ping >> me. >> > > *cough* Took a bit more *cough* than a week *cough* > > http://lists.busybox.net/pipermail/busybox/2020-June/088028.html Cool, thx for upstreaming! -- Stefan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139589): https://lists.openembedded.org/g/openembedded-core/message/139589 Mute This Topic: https://lists.openembedded.org/mt/72391372/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] initramfs-framework: check successful mount using mountpoint
From: Stefan Agner
Instead of checking for existence of /dev in the mounted file system use
mountpoint to check if a root file system has been mounted. This allows
to use the rootfs module for OSTree based rootfs as well, where the file
system rootfs does not have any of the regular directories (at least
when using the modern layout).
Signed-off-by: Stefan Agner
---
Note that the finish module is checking for existence of /dev again, but
we are not using this module for the OSTree case.
Another alternative to this patch would be to check for lost+found, which
I found a bit ad-hoc as well.
We could also check the exit code of the mount command, but I am not sure
if that is a reliable way. mount(8) documents two exit code which sound
like mount has succeeded (0 and 64, "some mount succeeded"). Also, if we
want to retain the option that a module before the rootfs module mounts
$ROOTFS_DIR, we would still have to use a mountpoint check.
meta/recipes-core/initrdscripts/initramfs-framework/rootfs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/rootfs
b/meta/recipes-core/initrdscripts/initramfs-framework/rootfs
index 748c9391c0..ee24e82af3 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework/rootfs
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/rootfs
@@ -13,7 +13,7 @@ rootfs_run() {
C=0
delay=${bootparam_rootdelay:-1}
timeout=${bootparam_roottimeout:-5}
- while [ ! -d $ROOTFS_DIR/dev ]; do
+ while ! mountpoint -q $ROOTFS_DIR; do
if [ $(( $C * $delay )) -gt $timeout ]; then
fatal "root '$bootparam_root' doesn't exist or does not
contain a /dev."
fi
@@ -61,7 +61,7 @@ rootfs_run() {
flags="$flags -t$bootparam_rootfstype"
fi
mount $flags $bootparam_root $ROOTFS_DIR
- if [ -d $ROOTFS_DIR/dev ]; then
+ if mountpoint -q $ROOTFS_DIR; then
break
else
# It is unlikely to change, but keep
trying anyway.
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139188):
https://lists.openembedded.org/g/openembedded-core/message/139188
Mute This Topic: https://lists.openembedded.org/mt/74657708/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] kernel-yocto.bbclass: fix a wrong inter-task dependency
From: Ming Liu
do_kernel_checkout and do_symlink_kernsrc are both modifying ${S}, they
could conflict with eacher other, move do_kernel_checkout after
do_symlink_kernsrc does fix that.
Signed-off-by: Ming Liu
Signed-off-by: Stefan Agner
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 44863adc27..d71ce212a8 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -317,7 +317,7 @@ do_kernel_checkout() {
}
do_kernel_checkout[dirs] = "${S}"
-addtask kernel_checkout before do_kernel_metadata after do_unpack
+addtask kernel_checkout before do_kernel_metadata after do_symlink_kernsrc
addtask kernel_metadata after do_validate_branches do_unpack before do_patch
do_kernel_metadata[depends] = "kern-tools-native:do_populate_sysroot"
do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot"
--
2.25.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] psplash: add systemd support
From: Stefan Agner
Make use of the recently added systemd support in psplash. The utility
psplash-systemd communicates boot progress to the splash screen. The
splash is disabled once systemd consideres the system fully booted
(progress is at 1.0). Note that this can take a while if systemd is
stuck on a failing unit.
This change adds two systemd services. One service starts psplash itself
(psplash-start.service) and the second service starts the helper utility
psplash-systemd (psplash-systemd.service). The units are written such
that psplash-systemd.service can be used indepenendenly. This is useful
when starting psplash in initramfs (not using systemd).
Signed-off-by: Stefan Agner
---
Note that this does *not* move to the very latest version of psplash.
The latest changes from Yann Dirson change how the header files for
the splash logo and progress bar are generated which needs more work
on the recipe side.
In fact, we probably could get rid of most of the logic which generates
the header files in the recipe and make use of the built-in functionality
now. It also would somewhat brake the recipe "API" as we probably would
allow to define header files directly through file:// anymore.
I currently do not plan to work on this.
--
Stefan
meta/recipes-core/psplash/files/psplash-init | 8 ++--
.../psplash/files/psplash-start.service | 10 +
.../psplash/files/psplash-systemd.service | 10 +
meta/recipes-core/psplash/psplash_git.bb | 38 +++
4 files changed, 47 insertions(+), 19 deletions(-)
create mode 100644 meta/recipes-core/psplash/files/psplash-start.service
create mode 100644 meta/recipes-core/psplash/files/psplash-systemd.service
diff --git a/meta/recipes-core/psplash/files/psplash-init
b/meta/recipes-core/psplash/files/psplash-init
index 4bee866b0d..f58e043733 100755
--- a/meta/recipes-core/psplash/files/psplash-init
+++ b/meta/recipes-core/psplash/files/psplash-init
@@ -23,10 +23,10 @@ for x in $CMDLINE; do
esac
done
-export TMPDIR=/mnt/.psplash
-[ -d $TMPDIR ] || mkdir -p $TMPDIR
-if ! mountpoint -q $TMPDIR; then
- mount tmpfs -t tmpfs $TMPDIR -o,size=40k
+export PSPLASH_FIFO_DIR=/mnt/.psplash
+[ -d $PSPLASH_FIFO_DIR ] || mkdir -p $PSPLASH_FIFO_DIR
+if ! mountpoint -q $PSPLASH_FIFO_DIR; then
+ mount tmpfs -t tmpfs $PSPLASH_FIFO_DIR -o,size=40k
fi
rotation=0
diff --git a/meta/recipes-core/psplash/files/psplash-start.service
b/meta/recipes-core/psplash/files/psplash-start.service
new file mode 100644
index 00..9de8f6321a
--- /dev/null
+++ b/meta/recipes-core/psplash/files/psplash-start.service
@@ -0,0 +1,10 @@
+[Unit]
+Description=Start psplash boot splash screen
+DefaultDependencies=no
+Requires=psplash-systemd.service
+
+[Service]
+ExecStart=/usr/bin/psplash
+
+[Install]
+WantedBy=sysinit.target
diff --git a/meta/recipes-core/psplash/files/psplash-systemd.service
b/meta/recipes-core/psplash/files/psplash-systemd.service
new file mode 100644
index 00..e14f42032d
--- /dev/null
+++ b/meta/recipes-core/psplash/files/psplash-systemd.service
@@ -0,0 +1,10 @@
+[Unit]
+Description=Start psplash-systemd progress communication helper
+DefaultDependencies=no
+After=systemd-start.service
+
+[Service]
+ExecStart=/usr/bin/psplash-systemd
+
+[Install]
+WantedBy=sysinit.target
diff --git a/meta/recipes-core/psplash/psplash_git.bb
b/meta/recipes-core/psplash/psplash_git.bb
index 56734c1582..6ff0393194 100644
--- a/meta/recipes-core/psplash/psplash_git.bb
+++ b/meta/recipes-core/psplash/psplash_git.bb
@@ -3,14 +3,16 @@ DESCRIPTION = "PSplash is a userspace graphical boot splash
screen for mainly em
HOMEPAGE = "http://git.yoctoproject.org/cgit/cgit.cgi/psplash";
SECTION = "base"
LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM =
"file://psplash.h;beginline=1;endline=16;md5=840fb2356b10a85bed78dd09dc7745c6"
+LIC_FILES_CHKSUM =
"file://psplash.h;beginline=1;endline=8;md5=8f232c1e95929eacab37f00900580224"
-SRCREV = "2015f7073e98dd9562db0936a254af5ef56356cf"
+SRCREV = "773a3977d255e8f59a741ad6ce37c4d40f1feaa1"
PV = "0.1+git${SRCPV}"
PR = "r15"
SRC_URI = "git://git.yoctoproject.org/${BPN} \
file://psplash-init \
+ file://psplash-start.service \
+ file://psplash-systemd.service \
${SPLASH_IMAGES}"
UPSTREAM_CHECK_COMMITS = "1"
@@ -66,7 +68,11 @@ python __anonymous() {
S = "${WORKDIR}/git"
-inherit autotools pkgconfig update-rc.d update-alternatives
+inherit autotools pkgconfig update-rc.d update-alternatives systemd
+
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
+
+PACKAGECONFIG[systemd] = "--with-systemd,--without-systemd,systemd"
ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_LINK_NAME[psplash] = "${bindir}/psplash"
@@ -97,8 +103,17 @@ python do_compile
Re: [OE-core] busybox: udhcpc: fix IPv6 support when using udhcpc
On 2020-01-20 13:32, Quentin Schulz wrote: > Hi all, > > On Mon, Jan 13, 2020 at 03:57:31PM +0100, Quentin Schulz wrote: >> Hi all, >> >> On Mon, May 14, 2018 at 04:44:15PM +0200, Stefan Agner wrote: >> > From: Stefan Agner >> > >> > The udhcpc script calls ip addr flush .. which flushes addresses >> > of any address family, including IPv6. However, busybox udhcpc is >> > IPv4 only and should not influence IPv6 addressing. Hence use ip >> > addr flush with family constrait. >> > >> > The script particularly broke IPv6 SLAAC: Typically when udhcpc >> > calls the script the kernel already assigned the IPv6 link-local >> > address. The flush removes the link-local IPv6 address again and >> > prohibits proper IPv6 operation such as SLAAC since neighbor >> > discovery protocol relies on IPv6 link-local addressing. >> > >> > Signed-off-by: Stefan Agner >> > --- >> > meta/recipes-core/busybox/files/simple.script | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/meta/recipes-core/busybox/files/simple.script >> > b/meta/recipes-core/busybox/files/simple.script >> > index 6ed0293525..8b5eb53633 100644 >> > --- a/meta/recipes-core/busybox/files/simple.script >> > +++ b/meta/recipes-core/busybox/files/simple.script >> > @@ -28,7 +28,7 @@ case "$1" in >> >fi >> >if ! root_is_nfs ; then >> > if [ $have_bin_ip -eq 1 ]; then >> > -/SBIN_DIR/ip addr flush dev $interface >> > +/SBIN_DIR/ip -4 addr flush dev $interface >> > /SBIN_DIR/ip link set dev $interface up >> > else >> > /SBIN_DIR/ifconfig $interface 0.0.0.0 >> >> Kindly pinging, happened to us as well many times. >> > > Kindly pinging. Just checked, we still override that script in our layer, so definitely would be happy if this gets merged upstream so I can get rid of our custom script downstream. -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 2/2] image_types: add Zstandard conversion support
Hi,
I am a bit confused on which direction we are going here. It seems that
this second patch now got merged, but not the first one (instead
disabling testing tar.zstd). I am fine with that, but in this case we
need to readd zstd to meta-oe (since there it already had been removed,
probably accidentally).
--
Stefan
On 2019-11-20 13:41, Stefan Agner wrote:
> From: Stefan Agner
>
> Add Zstandard (or just Zstd) compression support. This allows to
> create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
>
> Signed-off-by: Stefan Agner
> ---
> meta/classes/image_types.bbclass | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> index 2eeffbb366..de00492932 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
>
> ZIP_COMPRESSION_LEVEL ?= "-9"
>
> +ZSTD_COMPRESSION_LEVEL ?= "-3"
> +
> JFFS2_SUM_EXTRA_ARGS ?= ""
> IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
> --output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
> ${EXTRA_IMAGECMD}"
>
> @@ -269,7 +271,7 @@ IMAGE_TYPES = " \
> hddimg \
> squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
> ubi ubifs multiubi \
> -tar tar.gz tar.bz2 tar.xz tar.lz4 \
> +tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
> cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
> wic wic.gz wic.bz2 wic.lzma \
> container \
> @@ -282,7 +284,7 @@ IMAGE_TYPES = " \
> # CONVERSION_CMD/DEPENDS.
> COMPRESSIONTYPES ?= ""
>
> -CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum
> sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2
> base64 ${COMPRESSIONTYPES}"
> +CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum
> sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2
> base64 ${COMPRESSIONTYPES}"
> CONVERSION_CMD_lzma = "lzma -k -f -7
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
> CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> @@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c
> ${XZ_COMPRESSION_LEVEL} ${XZ_DEFAULTS} --check=
> CONVERSION_CMD_lz4 = "lz4 -9 -z -l
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
> CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> +CONVERSION_CMD_zst = "zstd -f -k -T0 -c ${ZSTD_COMPRESSION_LEVEL}
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
> CONVERSION_CMD_sum = "sumtool -i
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
> CONVERSION_CMD_md5sum = "md5sum
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
> CONVERSION_CMD_sha1sum = "sha1sum
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
> @@ -310,6 +313,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
> CONVERSION_DEPENDS_lz4 = "lz4-native"
> CONVERSION_DEPENDS_lzo = "lzop-native"
> CONVERSION_DEPENDS_zip = "zip-native"
> +CONVERSION_DEPENDS_zst = "zstd-native"
> CONVERSION_DEPENDS_sum = "mtd-utils-native"
> CONVERSION_DEPENDS_bmap = "bmap-tools-native"
> CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Using timestamps (DATETIME) in PV
Hi,
tl;dr: Afaict, using DATETIME in PV is currently impossible due to
commit 9ca2fad2 ("image: Expand PV to avoid AUTOREV parsing failures").
Do not use DATETIME in PV.
In an effort to use timestamps for development builds we tried to use
DATETIME in the PV variable of an image recipe (basically PV =
"${DATETIME}", although my real use case is a bit more involved, but
this is the part which matters). Unfortunately this lead to basehash
value changed errors:
ERROR: When reparsing
/build/ags/torizon-master/build-colibri-imx7/conf/../../layers/meta-toradex-torizon/recipes-images/images/torizon-core-docker.bb:do_patch,
the basehash value changed from
9d65be87aee58d81c6310c5d4a09e1ab94115074c2076766e5bb87267b6257ed to
3b069c8e23e86f778350cd91f17edd00ac71be5fb95a512b1fd567c31dcab46d. The
metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake torizon-core-docker -cdo_patch -Snone
ERROR: Then:
ERROR: $ bitbake torizon-core-docker -cdo_patch -Sprintdiff
Normally this can be fixed by excluding the variable from the
dependencies like this:
PV[vardepsexclude] += "DATETIME"
However, it did not help in this case. I then did what Richard suggests
in [1] and fired up bitbake-diffsigs using the two hashes from the error
showed. This revealed that it is still PV which is an issue:
NOTE: Starting bitbake server...
basehash changed from
4bf60537ad6dbcf8d54972bd81d51ea49d968600cebb6b198c25f4766ae2d31c to
4897cf911d1a75dcdd7f5cbead00d15fd8e419e9e647d49be4585640c67dd0a4
Variable PV value changed from '20191125160227' to '20191125160240'
I found three issues here.
1. sstate.bbclass sets PV[vardepvalue] = "${PV}" to explicitly evaluate
PV (see [2]). This can be easily fixed by clearing vardepvalue, e.g.
PV[vardepvalue] = "".
However, with this fixed we still see issue in custom image tasks.
2. image.bbclass uses localdata.setVar('PV', d.getVar('PV')) to
basically do the same (see [3]). Unfortunately I found no way to easily
alter this behavior from my layer. Since we make use of custom image
tasks we use IMAGE_CMD_x.
3. I also get "The postinstall intercept hook 'update_udev_hwdb' failed,
details in ...temp/log.do_rootfs", it says "chown: invalid user:
‘root:root’". It seems like a pseudo issue, however PSEUDO_LOCALSTATEDIR
seems to be setup correctly. It seems that PSEUDO_LOCALSTATEDIR has a
slight different timestamp then where the rootfs is located but I am not
sure if that is an issue. Anyways, this problem remains unsolved at this
point.
Maybe 2 could be solved differently such that the behavior can be
controlled from an image?
Especially since PV is part of the WORKDIR (which also seems to cause
the third issue) I am not sure how many more problems along those lines
waiting to be found. I plan to move to a different/custom variable to
accomplish my goal. However, since I did all the research so far I
wanted to post this anyway.
--
Stefan
[1]
https://git.openembedded.org/bitbake/commit/?id=857829048c14338132784326ba98a71f12192db8&h=master
[2]
https://git.openembedded.org/openembedded-core/commit/?id=918646ca803d56004fb0ab7c21e86cc9cb14513d&h=master
[3]
https://git.openembedded.org/openembedded-core/commit/?id=9ca2fad2e569597f460e6bcbbd96077c8b8cfce9&h=master
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base-files: set ptmxmode to 666
Hi, On 2019-11-15 17:09, Stefan Agner wrote: > From: Stefan Agner > > Make sure that the (newer) /dev/pts/ptmx is accessible by users. This > is useful e.g. when running containers which symlink /dev/ptmx to > /dev/pts/ptmx on start. The default mode (000) does not allow to > create ptys inside the container. > > Using 666 when symlinking /dev/ptmx is also recommended by the kernel > documentation when /dev/ptmx is symlinked: > https://www.kernel.org/doc/Documentation/filesystems/devpts.txt > > Also buildroot uses ptmxmode=0666. The patch introducing the change > explains related use cases why this is necessary a bit more in depth: > https://github.com/buildroot/buildroot/commit/8196b299ba12bd6741bf7f4462cad180dab77fb0#diff-2d4604b9e565eb19fa52ce31f282f06c > Any thought about this? From what I can tell it did not make it into oe-core yet? -- Stefan > Signed-off-by: Stefan Agner > --- > meta/recipes-core/base-files/base-files/fstab | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-core/base-files/base-files/fstab > b/meta/recipes-core/base-files/base-files/fstab > index d79a01602f..70e400f567 100644 > --- a/meta/recipes-core/base-files/base-files/fstab > +++ b/meta/recipes-core/base-files/base-files/fstab > @@ -2,7 +2,7 @@ > > /dev/root/auto defaults 1 > 1 > proc /procproc defaults 0 > 0 > -devpts /dev/pts devpts mode=0620,gid=5 0 > 0 > +devpts /dev/pts devpts > mode=0620,ptmxmode=0666,gid=5 0 0 > tmpfs/run tmpfs > mode=0755,nodev,nosuid,strictatime 0 0 > tmpfs/var/volatiletmpfs defaults 0 > 0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] rpcbind: use upstream systemd service
From: Stefan Agner
Use upstream systemd service files instead of our own service files.
This also makes sure that /run/rpcbind.sock is used which fixes the
following systemd warning:
/usr/lib/systemd/system/rpcbind.socket:5: ListenStream= references a
path below legacy directory /var/run/, updating /var/run/rpcbind.sock
\xe2\x86\x92 /run/rpcbind.sock; please update the unit file accordingly.
Signed-off-by: Stefan Agner
---
.../0001-systemd-use-EnvironmentFile.patch| 42 +++
.../rpcbind/rpcbind/rpcbind.conf | 2 +-
.../rpcbind/rpcbind/rpcbind.service | 12 --
.../rpcbind/rpcbind/rpcbind.socket| 8
.../recipes-extended/rpcbind/rpcbind_1.2.5.bb | 13 +-
5 files changed, 45 insertions(+), 32 deletions(-)
create mode 100644
meta/recipes-extended/rpcbind/rpcbind/0001-systemd-use-EnvironmentFile.patch
delete mode 100644 meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
delete mode 100644 meta/recipes-extended/rpcbind/rpcbind/rpcbind.socket
diff --git
a/meta/recipes-extended/rpcbind/rpcbind/0001-systemd-use-EnvironmentFile.patch
b/meta/recipes-extended/rpcbind/rpcbind/0001-systemd-use-EnvironmentFile.patch
new file mode 100644
index 00..b92f2cf7b1
--- /dev/null
+++
b/meta/recipes-extended/rpcbind/rpcbind/0001-systemd-use-EnvironmentFile.patch
@@ -0,0 +1,42 @@
+From da528d5d60137f13202102b53cf178aba45849a5 Mon Sep 17 00:00:00 2001
+From: Stefan Agner
+Date: Sun, 6 Oct 2019 00:05:54 +0200
+Subject: [PATCH] systemd: use EnvironmentFile
+
+Use OE specific environment file.
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Stefan Agner
+---
+ configure.ac | 2 ++
+ systemd/rpcbind.service.in | 2 +-
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 2dd9471..47a46c0 100644
+--- a/configure.ac
b/configure.ac
+@@ -69,5 +69,7 @@ AC_CHECK_HEADERS([nss.h rpcsvc/mount.h])
+ # 2 "evals" needed to expand variable names
+ AC_SUBST([_sbindir])
+ AC_CONFIG_COMMANDS_PRE([eval eval _sbindir=$sbindir])
++AC_SUBST([_sysconfdir])
++AC_CONFIG_COMMANDS_PRE([eval eval _sysconfdir=$sbindir])
+
+ AC_OUTPUT([Makefile systemd/rpcbind.service])
+diff --git a/systemd/rpcbind.service.in b/systemd/rpcbind.service.in
+index 7b1c74b..f45ee1e 100644
+--- a/systemd/rpcbind.service.in
b/systemd/rpcbind.service.in
+@@ -11,7 +11,7 @@ Wants=rpcbind.target
+
+ [Service]
+ Type=notify
+-# distro can provide a drop-in adding EnvironmentFile=-/??? if needed.
++EnvironmentFile=-@_sysconfdir@/rpcbind.conf
+ ExecStart=@_sbindir@/rpcbind $RPCBIND_OPTIONS -w -f
+
+ [Install]
+--
+2.23.0
+
diff --git a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.conf
b/meta/recipes-extended/rpcbind/rpcbind/rpcbind.conf
index 2a4dfbcfbc..f423ac1788 100644
--- a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.conf
+++ b/meta/recipes-extended/rpcbind/rpcbind/rpcbind.conf
@@ -1,3 +1,3 @@
# Optional arguments passed to rpcbind.
#
-RPCBIND_OPTS=""
+RPCBIND_OPTIONS=""
diff --git a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
b/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
deleted file mode 100644
index 9cdade4959..00
--- a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
+++ /dev/null
@@ -1,12 +0,0 @@
-[Unit]
-Description=RPC Bind Service
-Requires=rpcbind.socket
-
-[Service]
-Type=forking
-EnvironmentFile=-@SYSCONFDIR@/rpcbind.conf
-ExecStart=@SBINDIR@/rpcbind $RPCBIND_OPTS
-SuccessExitStatus=2
-
-[Install]
-Also=rpcbind.socket
diff --git a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.socket
b/meta/recipes-extended/rpcbind/rpcbind/rpcbind.socket
deleted file mode 100644
index d63c1d9720..00
--- a/meta/recipes-extended/rpcbind/rpcbind/rpcbind.socket
+++ /dev/null
@@ -1,8 +0,0 @@
-[Unit]
-Description=RPCbind Server Activation Socket
-
-[Socket]
-ListenStream=/var/run/rpcbind.sock
-
-[Install]
-WantedBy=sockets.target
diff --git a/meta/recipes-extended/rpcbind/rpcbind_1.2.5.bb
b/meta/recipes-extended/rpcbind/rpcbind_1.2.5.bb
index 19d778b6d1..aff00e56e6 100644
--- a/meta/recipes-extended/rpcbind/rpcbind_1.2.5.bb
+++ b/meta/recipes-extended/rpcbind/rpcbind_1.2.5.bb
@@ -13,9 +13,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=b46486e4c4a416602693a711bb5bfa39 \
SRC_URI = "${SOURCEFORGE_MIRROR}/rpcbind/rpcbind-${PV}.tar.bz2 \
file://init.d \
file://rpcbind.conf \
- file://rpcbind.socket \
- file://rpcbind.service \
file://rpcbind_add_option_to_fix_port_number.patch \
+ file://0001-systemd-use-EnvironmentFile.patch \
"
SRC_URI[md5sum] = "ed46f09b9c0fa2d49015f6431bc5ea7b"
SRC_URI[sha256sum] =
"2ce360683963b35c19c43f0ee2c7f18aa5b81ef41c3fdbd15ffcb00b8bffda7a"
@@ -28,7 +27,7 @@ PACKAGECONFIG[tcp-wrappers] =
"--enable-libwrap,--disable-libwrap,tcp-wrappers"
INITSCRIPT_NAME = "rpcbind"
INITSCRIPT_PARA
[OE-core] [PATCH v5 2/2] image_types: add Zstandard conversion support
From: Stefan Agner
Add Zstandard (or just Zstd) compression support. This allows to
create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
Signed-off-by: Stefan Agner
---
meta/classes/image_types.bbclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2eeffbb366..de00492932 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
ZIP_COMPRESSION_LEVEL ?= "-9"
+ZSTD_COMPRESSION_LEVEL ?= "-3"
+
JFFS2_SUM_EXTRA_ARGS ?= ""
IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
--output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
${EXTRA_IMAGECMD}"
@@ -269,7 +271,7 @@ IMAGE_TYPES = " \
hddimg \
squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
ubi ubifs multiubi \
-tar tar.gz tar.bz2 tar.xz tar.lz4 \
+tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
wic wic.gz wic.bz2 wic.lzma \
container \
@@ -282,7 +284,7 @@ IMAGE_TYPES = " \
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
CONVERSION_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
${XZ_DEFAULTS} --check=
CONVERSION_CMD_lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD_zst = "zstd -f -k -T0 -c ${ZSTD_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
@@ -310,6 +313,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_zst = "zstd-native"
CONVERSION_DEPENDS_sum = "mtd-utils-native"
CONVERSION_DEPENDS_bmap = "bmap-tools-native"
CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 1/2] zstd: move recipe to oe-core from meta-oe
From: Stefan Agner
Zstd is a very fast compression algorithm and has gained quite some
popularity recently. An upcoming patch allows to compress rootfs
using Zstd. Moving Zstd to oe-core allows this new conversion formats
to be automatically tested by the oe-selftest
imagefeatures.ImageFeatures.test_image_fstypes test.
Furthermore there are three packages in oe-core which allow to enable
Zstd support through packageconfig currently.
Signed-off-by: Stefan Agner
---
meta/conf/distro/include/maintainers.inc | 1 +
meta/recipes-extended/zstd/zstd_1.4.4.bb | 35
2 files changed, 36 insertions(+)
create mode 100644 meta/recipes-extended/zstd/zstd_1.4.4.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index d85e5b697f..dff7ce28f8 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -774,3 +774,4 @@ RECIPE_MAINTAINER_pn-xwininfo = "Armin Kuster
"
RECIPE_MAINTAINER_pn-xz = "Denys Dmytriyenko "
RECIPE_MAINTAINER_pn-zip = "Denys Dmytriyenko "
RECIPE_MAINTAINER_pn-zlib = "Denys Dmytriyenko "
+RECIPE_MAINTAINER_pn-zstd = "Alex Kiernan "
diff --git a/meta/recipes-extended/zstd/zstd_1.4.4.bb
b/meta/recipes-extended/zstd/zstd_1.4.4.bb
new file mode 100644
index 00..eb201f4139
--- /dev/null
+++ b/meta/recipes-extended/zstd/zstd_1.4.4.bb
@@ -0,0 +1,35 @@
+SUMMARY = "Zstandard - Fast real-time compression algorithm"
+DESCRIPTION = "Zstandard is a fast lossless compression algorithm, targeting \
+real-time compression scenarios at zlib-level and better compression ratios. \
+It's backed by a very fast entropy stage, provided by Huff0 and FSE library."
+HOMEPAGE = "http://www.zstd.net/";
+SECTION = "console/utils"
+
+LICENSE = "BSD-3-Clause & GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=c7f0b161edbe52f5f345a3d1311d0b32 \
+file://COPYING;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+SRC_URI = "git://github.com/facebook/zstd.git;nobranch=1"
+
+SRCREV = "10f0e6993f9d2f682da6d04aa2385b7d53cbb4ee"
+UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)"
+
+S = "${WORKDIR}/git"
+
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[lz4] = "HAVE_LZ4=1,HAVE_LZ4=0,lz4"
+PACKAGECONFIG[lzma] = "HAVE_LZMA=1,HAVE_LZMA=0,xz"
+PACKAGECONFIG[zlib] = "HAVE_ZLIB=1,HAVE_ZLIB=0,zlib"
+
+# See programs/README.md for how to use this
+ZSTD_LEGACY_SUPPORT ??= "4"
+
+do_compile () {
+oe_runmake ${PACKAGECONFIG_CONFARGS}
ZSTD_LEGACY_SUPPORT=${ZSTD_LEGACY_SUPPORT}
+}
+
+do_install () {
+oe_runmake install 'DESTDIR=${D}'
+}
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 2/2] image_types: add Zstandard conversion support
On 2019-11-20 11:49, Alex Kiernan wrote:
> On Wed, Nov 20, 2019 at 9:13 AM Stefan Agner wrote:
>>
>> From: Stefan Agner
>>
>> Add Zstandard (or just Zstd) compression support. This allows to
>> create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
>>
>> Signed-off-by: Stefan Agner
>> ---
>> meta/classes/image_types.bbclass | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/image_types.bbclass
>> b/meta/classes/image_types.bbclass
>> index 2eeffbb366..d29b9c5787 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
>>
>> ZIP_COMPRESSION_LEVEL ?= "-9"
>>
>> +ZSTD_COMPRESSION_LEVEL ?= "-3"
>> +
>> JFFS2_SUM_EXTRA_ARGS ?= ""
>> IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
>> --output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
>> ${EXTRA_IMAGECMD}"
>>
>> @@ -269,7 +271,7 @@ IMAGE_TYPES = " \
>> hddimg \
>> squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
>> ubi ubifs multiubi \
>> -tar tar.gz tar.bz2 tar.xz tar.lz4 \
>> +tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
>> cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
>> wic wic.gz wic.bz2 wic.lzma \
>> container \
>> @@ -282,7 +284,7 @@ IMAGE_TYPES = " \
>> # CONVERSION_CMD/DEPENDS.
>> COMPRESSIONTYPES ?= ""
>>
>> -CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
>> sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
>> ${COMPRESSIONTYPES}"
>> +CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum
>> sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
>> ${COMPRESSIONTYPES}"
>> CONVERSION_CMD_lzma = "lzma -k -f -7
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
>> CONVERSION_CMD_bz2 = "pbzip2 -f -k
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> @@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
>> ${XZ_DEFAULTS} --check=
>> CONVERSION_CMD_lz4 = "lz4 -9 -z -l
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
>> CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> +CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
>
> Add -T0 so we default to parallel?
Sensible, will send a v5.
--
Stefan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 1/2] zstd: move recipe to oe-core from meta-oe
From: Stefan Agner
Zstd is a very fast compression algorithm and has gained quite some
popularity recently. An upcoming patch allows to compress rootfs
using Zstd. Moving Zstd to oe-core allows this new conversion formats
to be automatically tested by the oe-selftest
imagefeatures.ImageFeatures.test_image_fstypes test.
Furthermore there are three packages in oe-core which allow to enable
Zstd support through packageconfig currently.
Signed-off-by: Stefan Agner
---
meta/conf/distro/include/maintainers.inc | 1 +
meta/recipes-extended/zstd/zstd_1.4.4.bb | 35
2 files changed, 36 insertions(+)
create mode 100644 meta/recipes-extended/zstd/zstd_1.4.4.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index d85e5b697f..dff7ce28f8 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -774,3 +774,4 @@ RECIPE_MAINTAINER_pn-xwininfo = "Armin Kuster
"
RECIPE_MAINTAINER_pn-xz = "Denys Dmytriyenko "
RECIPE_MAINTAINER_pn-zip = "Denys Dmytriyenko "
RECIPE_MAINTAINER_pn-zlib = "Denys Dmytriyenko "
+RECIPE_MAINTAINER_pn-zstd = "Alex Kiernan "
diff --git a/meta/recipes-extended/zstd/zstd_1.4.4.bb
b/meta/recipes-extended/zstd/zstd_1.4.4.bb
new file mode 100644
index 00..eb201f4139
--- /dev/null
+++ b/meta/recipes-extended/zstd/zstd_1.4.4.bb
@@ -0,0 +1,35 @@
+SUMMARY = "Zstandard - Fast real-time compression algorithm"
+DESCRIPTION = "Zstandard is a fast lossless compression algorithm, targeting \
+real-time compression scenarios at zlib-level and better compression ratios. \
+It's backed by a very fast entropy stage, provided by Huff0 and FSE library."
+HOMEPAGE = "http://www.zstd.net/";
+SECTION = "console/utils"
+
+LICENSE = "BSD-3-Clause & GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=c7f0b161edbe52f5f345a3d1311d0b32 \
+file://COPYING;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+SRC_URI = "git://github.com/facebook/zstd.git;nobranch=1"
+
+SRCREV = "10f0e6993f9d2f682da6d04aa2385b7d53cbb4ee"
+UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)"
+
+S = "${WORKDIR}/git"
+
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[lz4] = "HAVE_LZ4=1,HAVE_LZ4=0,lz4"
+PACKAGECONFIG[lzma] = "HAVE_LZMA=1,HAVE_LZMA=0,xz"
+PACKAGECONFIG[zlib] = "HAVE_ZLIB=1,HAVE_ZLIB=0,zlib"
+
+# See programs/README.md for how to use this
+ZSTD_LEGACY_SUPPORT ??= "4"
+
+do_compile () {
+oe_runmake ${PACKAGECONFIG_CONFARGS}
ZSTD_LEGACY_SUPPORT=${ZSTD_LEGACY_SUPPORT}
+}
+
+do_install () {
+oe_runmake install 'DESTDIR=${D}'
+}
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 2/2] image_types: add Zstandard conversion support
From: Stefan Agner
Add Zstandard (or just Zstd) compression support. This allows to
create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
Signed-off-by: Stefan Agner
---
meta/classes/image_types.bbclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2eeffbb366..d29b9c5787 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
ZIP_COMPRESSION_LEVEL ?= "-9"
+ZSTD_COMPRESSION_LEVEL ?= "-3"
+
JFFS2_SUM_EXTRA_ARGS ?= ""
IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
--output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
${EXTRA_IMAGECMD}"
@@ -269,7 +271,7 @@ IMAGE_TYPES = " \
hddimg \
squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
ubi ubifs multiubi \
-tar tar.gz tar.bz2 tar.xz tar.lz4 \
+tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
wic wic.gz wic.bz2 wic.lzma \
container \
@@ -282,7 +284,7 @@ IMAGE_TYPES = " \
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
CONVERSION_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
${XZ_DEFAULTS} --check=
CONVERSION_CMD_lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
@@ -310,6 +313,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_zst = "zstd-native"
CONVERSION_DEPENDS_sum = "mtd-utils-native"
CONVERSION_DEPENDS_bmap = "bmap-tools-native"
CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 1/2] zstd: move recipe to oe-core from meta-oe
On 2019-11-19 17:18, Alex Kiernan wrote: > On Mon, Nov 18, 2019 at 6:39 PM Stefan Agner wrote: >> >> [adding Alex, he maintained the recipe in meta-oe so far] >> >> On 2019-11-18 13:19, Richard Purdie wrote: >> > On Thu, 2019-11-14 at 15:47 +0100, Stefan Agner wrote: >> >> On 2019-11-08 10:14, Stefan Agner wrote: >> >> > From: Stefan Agner >> >> > >> >> > Zstd is a very fast compression algorithm and has gained quite some >> >> > popularity recently. An upcoming patch allows to compress rootfs >> >> > using Zstd. Moving Zstd to oe-core allows this new conversion >> >> > formats >> >> > to be automatically tested by the oe-selftest >> >> > imagefeatures.ImageFeatures.test_image_fstypes test. >> >> > >> >> > Furthermore there are three packages in oe-core which allow to >> >> > enable >> >> > Zstd support through packageconfig currently. >> >> >> >> Any update/thoughts on this? >> > >> > I've not made a final decision on whether to merge it fails selftests >> > due to a lack of a maintainer: >> >> Alex, would you be OK with you listed as maintainer? >> > > I'm fine with that - it's very low overhead. Thanks Alex, will send a v4 with you as maintainer. -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 1/2] zstd: move recipe to oe-core from meta-oe
[adding Alex, he maintained the recipe in meta-oe so far] On 2019-11-18 13:19, Richard Purdie wrote: > On Thu, 2019-11-14 at 15:47 +0100, Stefan Agner wrote: >> On 2019-11-08 10:14, Stefan Agner wrote: >> > From: Stefan Agner >> > >> > Zstd is a very fast compression algorithm and has gained quite some >> > popularity recently. An upcoming patch allows to compress rootfs >> > using Zstd. Moving Zstd to oe-core allows this new conversion >> > formats >> > to be automatically tested by the oe-selftest >> > imagefeatures.ImageFeatures.test_image_fstypes test. >> > >> > Furthermore there are three packages in oe-core which allow to >> > enable >> > Zstd support through packageconfig currently. >> >> Any update/thoughts on this? > > I've not made a final decision on whether to merge it fails selftests > due to a lack of a maintainer: Alex, would you be OK with you listed as maintainer? -- Stefan > > 2019-11-16 20:13:49,922 - oe-selftest - INFO - > distrodata.Distrodata.test_maintainers (subunit.RemotedTestCase) > 2019-11-16 20:13:49,922 - oe-selftest - INFO - ... FAIL > 2019-11-16 20:13:49,923 - oe-selftest - INFO - 2: 29/40 153/378 > (109.44s) (distrodata.Distrodata.test_maintainers) > 2019-11-16 20:13:49,923 - oe-selftest - INFO - > testtools.testresult.real._StringException: Traceback (most recent > call last): > File > "/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/selftest/cases/distrodata.py", > line 84, in test_maintainers > """ + "\n".join(['%s (%s)' % i for i in no_maintainer_list])) > File "/usr/lib/python3.6/unittest/case.py", line 670, in fail > raise self.failureException(msg) > AssertionError: > The following recipes do not have a maintainer assigned to them. > Please add an entry to meta/conf/distro/include/maintainers.inc file. > zstd > (/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/recipes-extended/zstd/zstd_1.4.4.bb) > > To reproduce, run: "oe-selftest -r distrodata.Distrodata.test_maintainers" > > Cheers, > > Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 1/2] zstd: move recipe to oe-core from meta-oe
On 2019-11-18 17:53, Ross Burton wrote: > On 18/11/2019 16:47, akuster808 wrote: >> Does a possible Poky LTS have any factor in deciding to add more >> packages to core? > > Even without the LTS there's a (relatively) long-term commitment to > maintain recipes. > > Personally, I'm happy with Zstd being in meta-oe for now, and possibly > re-evaluating in the next cycle. Not having it in oe-core would mean we would have to exclude it from build testing [1]. >From what I can tell, that would be a first: Every other compression conversion is part of oe-core. It had quite some adoption lately, e.g. Fedora 31 uses zstd by default to compress their rpm packages [2]. IMHO, this are good arguments for adding it to oe-core now. [1] http://lists.openembedded.org/pipermail/openembedded-core/2019-November/22.html [2] https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] base-files: set ptmxmode to 666
From: Stefan Agner Make sure that the (newer) /dev/pts/ptmx is accessible by users. This is useful e.g. when running containers which symlink /dev/ptmx to /dev/pts/ptmx on start. The default mode (000) does not allow to create ptys inside the container. Using 666 when symlinking /dev/ptmx is also recommended by the kernel documentation when /dev/ptmx is symlinked: https://www.kernel.org/doc/Documentation/filesystems/devpts.txt Also buildroot uses ptmxmode=0666. The patch introducing the change explains related use cases why this is necessary a bit more in depth: https://github.com/buildroot/buildroot/commit/8196b299ba12bd6741bf7f4462cad180dab77fb0#diff-2d4604b9e565eb19fa52ce31f282f06c Signed-off-by: Stefan Agner --- meta/recipes-core/base-files/base-files/fstab | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/base-files/base-files/fstab b/meta/recipes-core/base-files/base-files/fstab index d79a01602f..70e400f567 100644 --- a/meta/recipes-core/base-files/base-files/fstab +++ b/meta/recipes-core/base-files/base-files/fstab @@ -2,7 +2,7 @@ /dev/root/auto defaults 1 1 proc /procproc defaults 0 0 -devpts /dev/pts devpts mode=0620,gid=5 0 0 +devpts /dev/pts devpts mode=0620,ptmxmode=0666,gid=5 0 0 tmpfs/run tmpfs mode=0755,nodev,nosuid,strictatime 0 0 tmpfs/var/volatiletmpfs defaults 0 0 -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 1/2] zstd: move recipe to oe-core from meta-oe
On 2019-11-08 10:14, Stefan Agner wrote:
> From: Stefan Agner
>
> Zstd is a very fast compression algorithm and has gained quite some
> popularity recently. An upcoming patch allows to compress rootfs
> using Zstd. Moving Zstd to oe-core allows this new conversion formats
> to be automatically tested by the oe-selftest
> imagefeatures.ImageFeatures.test_image_fstypes test.
>
> Furthermore there are three packages in oe-core which allow to enable
> Zstd support through packageconfig currently.
Any update/thoughts on this?
--
Stefan
>
> Signed-off-by: Stefan Agner
> ---
> meta/recipes-extended/zstd/zstd_1.4.4.bb | 35
> 1 file changed, 35 insertions(+)
> create mode 100644 meta/recipes-extended/zstd/zstd_1.4.4.bb
>
> diff --git a/meta/recipes-extended/zstd/zstd_1.4.4.bb
> b/meta/recipes-extended/zstd/zstd_1.4.4.bb
> new file mode 100644
> index 00..eb201f4139
> --- /dev/null
> +++ b/meta/recipes-extended/zstd/zstd_1.4.4.bb
> @@ -0,0 +1,35 @@
> +SUMMARY = "Zstandard - Fast real-time compression algorithm"
> +DESCRIPTION = "Zstandard is a fast lossless compression algorithm, targeting
> \
> +real-time compression scenarios at zlib-level and better compression ratios.
> \
> +It's backed by a very fast entropy stage, provided by Huff0 and FSE library."
> +HOMEPAGE = "http://www.zstd.net/";
> +SECTION = "console/utils"
> +
> +LICENSE = "BSD-3-Clause & GPLv2"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=c7f0b161edbe52f5f345a3d1311d0b32 \
> +file://COPYING;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
> +
> +SRC_URI = "git://github.com/facebook/zstd.git;nobranch=1"
> +
> +SRCREV = "10f0e6993f9d2f682da6d04aa2385b7d53cbb4ee"
> +UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)"
> +
> +S = "${WORKDIR}/git"
> +
> +PACKAGECONFIG ??= ""
> +PACKAGECONFIG[lz4] = "HAVE_LZ4=1,HAVE_LZ4=0,lz4"
> +PACKAGECONFIG[lzma] = "HAVE_LZMA=1,HAVE_LZMA=0,xz"
> +PACKAGECONFIG[zlib] = "HAVE_ZLIB=1,HAVE_ZLIB=0,zlib"
> +
> +# See programs/README.md for how to use this
> +ZSTD_LEGACY_SUPPORT ??= "4"
> +
> +do_compile () {
> +oe_runmake ${PACKAGECONFIG_CONFARGS}
> ZSTD_LEGACY_SUPPORT=${ZSTD_LEGACY_SUPPORT}
> +}
> +
> +do_install () {
> +oe_runmake install 'DESTDIR=${D}'
> +}
> +
> +BBCLASSEXTEND = "native nativesdk"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] dbus: drop unused group netdev
From: Stefan Agner
The whole D-Bus source has no reference to the netdev group. It
seems that the netdev group is nowhere used. Early avahi package
versions used this group for the D-Bus specific rules. However,
today avahi uses --with-avahi-priv-access-group=adm and hence
uses the adm group for its D-Bus policy rules.
If a package is using the netdev group in its D-Bus policy rules,
that package should add the group instead.
Signed-off-by: Stefan Agner
---
meta/recipes-core/dbus/dbus_1.12.16.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-core/dbus/dbus_1.12.16.bb
b/meta/recipes-core/dbus/dbus_1.12.16.bb
index f4fec2365c..96b5036870 100644
--- a/meta/recipes-core/dbus/dbus_1.12.16.bb
+++ b/meta/recipes-core/dbus/dbus_1.12.16.bb
@@ -32,7 +32,6 @@ python __anonymous() {
}
USERADD_PACKAGES = "${PN}"
-GROUPADD_PARAM_${PN} = "-r netdev"
USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
--no-create-home --shell /bin/false \
--user-group messagebus"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 2/2] image_types: add Zstandard conversion support
From: Stefan Agner
Add Zstandard (or just Zstd) compression support. This allows to
create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
Signed-off-by: Stefan Agner
---
meta/classes/image_types.bbclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2eeffbb366..d29b9c5787 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
ZIP_COMPRESSION_LEVEL ?= "-9"
+ZSTD_COMPRESSION_LEVEL ?= "-3"
+
JFFS2_SUM_EXTRA_ARGS ?= ""
IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
--output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
${EXTRA_IMAGECMD}"
@@ -269,7 +271,7 @@ IMAGE_TYPES = " \
hddimg \
squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
ubi ubifs multiubi \
-tar tar.gz tar.bz2 tar.xz tar.lz4 \
+tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
wic wic.gz wic.bz2 wic.lzma \
container \
@@ -282,7 +284,7 @@ IMAGE_TYPES = " \
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
CONVERSION_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
${XZ_DEFAULTS} --check=
CONVERSION_CMD_lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
@@ -310,6 +313,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_zst = "zstd-native"
CONVERSION_DEPENDS_sum = "mtd-utils-native"
CONVERSION_DEPENDS_bmap = "bmap-tools-native"
CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 1/2] zstd: move recipe to oe-core from meta-oe
From: Stefan Agner
Zstd is a very fast compression algorithm and has gained quite some
popularity recently. An upcoming patch allows to compress rootfs
using Zstd. Moving Zstd to oe-core allows this new conversion formats
to be automatically tested by the oe-selftest
imagefeatures.ImageFeatures.test_image_fstypes test.
Furthermore there are three packages in oe-core which allow to enable
Zstd support through packageconfig currently.
Signed-off-by: Stefan Agner
---
meta/recipes-extended/zstd/zstd_1.4.4.bb | 35
1 file changed, 35 insertions(+)
create mode 100644 meta/recipes-extended/zstd/zstd_1.4.4.bb
diff --git a/meta/recipes-extended/zstd/zstd_1.4.4.bb
b/meta/recipes-extended/zstd/zstd_1.4.4.bb
new file mode 100644
index 00..eb201f4139
--- /dev/null
+++ b/meta/recipes-extended/zstd/zstd_1.4.4.bb
@@ -0,0 +1,35 @@
+SUMMARY = "Zstandard - Fast real-time compression algorithm"
+DESCRIPTION = "Zstandard is a fast lossless compression algorithm, targeting \
+real-time compression scenarios at zlib-level and better compression ratios. \
+It's backed by a very fast entropy stage, provided by Huff0 and FSE library."
+HOMEPAGE = "http://www.zstd.net/";
+SECTION = "console/utils"
+
+LICENSE = "BSD-3-Clause & GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=c7f0b161edbe52f5f345a3d1311d0b32 \
+file://COPYING;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+SRC_URI = "git://github.com/facebook/zstd.git;nobranch=1"
+
+SRCREV = "10f0e6993f9d2f682da6d04aa2385b7d53cbb4ee"
+UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)"
+
+S = "${WORKDIR}/git"
+
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[lz4] = "HAVE_LZ4=1,HAVE_LZ4=0,lz4"
+PACKAGECONFIG[lzma] = "HAVE_LZMA=1,HAVE_LZMA=0,xz"
+PACKAGECONFIG[zlib] = "HAVE_ZLIB=1,HAVE_ZLIB=0,zlib"
+
+# See programs/README.md for how to use this
+ZSTD_LEGACY_SUPPORT ??= "4"
+
+do_compile () {
+oe_runmake ${PACKAGECONFIG_CONFARGS}
ZSTD_LEGACY_SUPPORT=${ZSTD_LEGACY_SUPPORT}
+}
+
+do_install () {
+oe_runmake install 'DESTDIR=${D}'
+}
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] image_types: add Zstandard conversion support
On 2019-11-07 09:01, Richard Purdie wrote:
> On Wed, 2019-11-06 at 13:43 +0000, Stefan Agner wrote:
>> From: Stefan Agner
>>
>> Add Zstandard (or just Zstd) compression support. This allows to
>> create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
>>
>> Signed-off-by: Stefan Agner
>> ---
>> meta/classes/image_types.bbclass | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/image_types.bbclass
>> b/meta/classes/image_types.bbclass
>> index 2eeffbb366..d29b9c5787 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
>>
>> ZIP_COMPRESSION_LEVEL ?= "-9"
>>
>> +ZSTD_COMPRESSION_LEVEL ?= "-3"
>> +
>> JFFS2_SUM_EXTRA_ARGS ?= ""
>> IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
>> --output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
>> ${EXTRA_IMAGECMD}"
>>
>> @@ -269,7 +271,7 @@ IMAGE_TYPES = " \
>> hddimg \
>> squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
>> ubi ubifs multiubi \
>> -tar tar.gz tar.bz2 tar.xz tar.lz4 \
>> +tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
>> cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
>> wic wic.gz wic.bz2 wic.lzma \
>> container \
>> @@ -282,7 +284,7 @@ IMAGE_TYPES = " \
>> # CONVERSION_CMD/DEPENDS.
>> COMPRESSIONTYPES ?= ""
>>
>> -CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
>> sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
>> ${COMPRESSIONTYPES}"
>> +CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum
>> sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
>> ${COMPRESSIONTYPES}"
>> CONVERSION_CMD_lzma = "lzma -k -f -7
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
>> CONVERSION_CMD_bz2 = "pbzip2 -f -k
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> @@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
>> ${XZ_DEFAULTS} --check=
>> CONVERSION_CMD_lz4 = "lz4 -9 -z -l
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
>> CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> +CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
>> CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> -o ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
>> CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
>> CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
>> @@ -310,6 +313,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
>> CONVERSION_DEPENDS_lz4 = "lz4-native"
>> CONVERSION_DEPENDS_lzo = "lzop-native"
>> CONVERSION_DEPENDS_zip = "zip-native"
>> +CONVERSION_DEPENDS_zst = "zstd-native"
>> CONVERSION_DEPENDS_sum = "mtd-utils-native"
>> CONVERSION_DEPENDS_bmap = "bmap-tools-native"
>> CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
>
> I was ok with this despite not having zstd-native in OE-Core however
> our automated testing is cleverer than I remembered:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/467
>
> so we may need to skip this option in the test...
>
> (oe-selftest -r imagefeatures.ImageFeatures.test_image_fstypes should
> reproduce)
Hm, I see, so we could fix that test.
However, how about moving zstd into core? There are already several
recipe in core making use of Zstd (optionally): mtd-utils, btrfs-tools
and squashfs-tools...
--
Stefan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] image_types: add Zstandard conversion support
From: Stefan Agner
Add Zstandard (or just Zstd) compression support. This allows to
create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
Signed-off-by: Stefan Agner
---
meta/classes/image_types.bbclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2eeffbb366..d29b9c5787 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
ZIP_COMPRESSION_LEVEL ?= "-9"
+ZSTD_COMPRESSION_LEVEL ?= "-3"
+
JFFS2_SUM_EXTRA_ARGS ?= ""
IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
--output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
${EXTRA_IMAGECMD}"
@@ -269,7 +271,7 @@ IMAGE_TYPES = " \
hddimg \
squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
ubi ubifs multiubi \
-tar tar.gz tar.bz2 tar.xz tar.lz4 \
+tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
wic wic.gz wic.bz2 wic.lzma \
container \
@@ -282,7 +284,7 @@ IMAGE_TYPES = " \
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
CONVERSION_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
${XZ_DEFAULTS} --check=
CONVERSION_CMD_lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
@@ -310,6 +313,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_zst = "zstd-native"
CONVERSION_DEPENDS_sum = "mtd-utils-native"
CONVERSION_DEPENDS_bmap = "bmap-tools-native"
CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] image_types: add Zstandard conversion support
Hi Andre,
On 2019-11-06 02:25, Andre McCurdy wrote:
> On Tue, Nov 5, 2019 at 3:13 PM Stefan Agner wrote:
>>
>> From: Stefan Agner
>>
>> Add Zstandard (or just Zstd) compression support. This allows to
>> create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
>>
>> Signed-off-by: Stefan Agner
>> ---
>> meta/classes/image_types.bbclass | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/image_types.bbclass
>> b/meta/classes/image_types.bbclass
>> index 2eeffbb366..eeae652e02 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -269,7 +269,7 @@ IMAGE_TYPES = " \
>> hddimg \
>> squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
>> ubi ubifs multiubi \
>> -tar tar.gz tar.bz2 tar.xz tar.lz4 \
>> +tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
>> cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
>> wic wic.gz wic.bz2 wic.lzma \
>> container \
>> @@ -282,7 +282,7 @@ IMAGE_TYPES = " \
>> # CONVERSION_CMD/DEPENDS.
>> COMPRESSIONTYPES ?= ""
>>
>> -CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
>> sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
>> ${COMPRESSIONTYPES}"
>> +CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum
>> sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
>> ${COMPRESSIONTYPES}"
>> CONVERSION_CMD_lzma = "lzma -k -f -7
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
>> CONVERSION_CMD_bz2 = "pbzip2 -f -k
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> @@ -290,6 +290,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
>> ${XZ_DEFAULTS} --check=
>> CONVERSION_CMD_lz4 = "lz4 -9 -z -l
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
>> CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> +CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
>
> Where is ZSTD_COMPRESSION_LEVEL defined?
>
Oh good catch, I got distracted halfway during the implementation it
seem :-)
I guess since it was not defined it did not break...
Will send a v2.
--
Stefan
>> CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> -o ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
>> CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
>> CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
>> @@ -310,6 +311,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
>> CONVERSION_DEPENDS_lz4 = "lz4-native"
>> CONVERSION_DEPENDS_lzo = "lzop-native"
>> CONVERSION_DEPENDS_zip = "zip-native"
>> +CONVERSION_DEPENDS_zst = "zstd-native"
>> CONVERSION_DEPENDS_sum = "mtd-utils-native"
>> CONVERSION_DEPENDS_bmap = "bmap-tools-native"
>> CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
>> --
>> 2.17.1
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image_types: add Zstandard conversion support
From: Stefan Agner
Add Zstandard (or just Zstd) compression support. This allows to
create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
Signed-off-by: Stefan Agner
---
meta/classes/image_types.bbclass | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2eeffbb366..eeae652e02 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -269,7 +269,7 @@ IMAGE_TYPES = " \
hddimg \
squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
ubi ubifs multiubi \
-tar tar.gz tar.bz2 tar.xz tar.lz4 \
+tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
wic wic.gz wic.bz2 wic.lzma \
container \
@@ -282,7 +282,7 @@ IMAGE_TYPES = " \
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
${COMPRESSIONTYPES}"
CONVERSION_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -290,6 +290,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
${XZ_DEFAULTS} --check=
CONVERSION_CMD_lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
@@ -310,6 +311,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_zst = "zstd-native"
CONVERSION_DEPENDS_sum = "mtd-utils-native"
CONVERSION_DEPENDS_bmap = "bmap-tools-native"
CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] uninative: check .done file instead of tarball
Also add Richard.
On 2019-10-11 11:06, Stefan Agner wrote:
> From: Stefan Agner
>
> In case multiple builds share UNINATIVE_DLDIR's location, one build
> might be in the process of downloading the tarball while another is
> just checking whether the tarball exists. Check for the done file
> instead and rely on the fetchers lockfile mechanism in case two
> builds are running.
>
> Signed-off-by: Stefan Agner
> ---
> meta/classes/uninative.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
> index 3326c0db3d..9f8645a36a 100644
> --- a/meta/classes/uninative.bbclass
> +++ b/meta/classes/uninative.bbclass
> @@ -45,7 +45,7 @@ python uninative_event_fetchloader() {
> tarballdir = os.path.join(d.getVar("UNINATIVE_DLDIR"), chksum)
> tarballpath = os.path.join(tarballdir, tarball)
>
> -if not os.path.exists(tarballpath):
> +if not os.path.exists(tarballpath + ".done"):
> bb.utils.mkdirhier(tarballdir)
> if d.getVar("UNINATIVE_URL") == "unset":
> bb.fatal("Uninative selected but not configured,
> please set UNINATIVE_URL")
> --
> 2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] uninative: check .done file instead of tarball
From: Stefan Agner
In case multiple builds share UNINATIVE_DLDIR's location, one build
might be in the process of downloading the tarball while another is
just checking whether the tarball exists. Check for the done file
instead and rely on the fetchers lockfile mechanism in case two
builds are running.
Signed-off-by: Stefan Agner
---
meta/classes/uninative.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 3326c0db3d..9f8645a36a 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -45,7 +45,7 @@ python uninative_event_fetchloader() {
tarballdir = os.path.join(d.getVar("UNINATIVE_DLDIR"), chksum)
tarballpath = os.path.join(tarballdir, tarball)
-if not os.path.exists(tarballpath):
+if not os.path.exists(tarballpath + ".done"):
bb.utils.mkdirhier(tarballdir)
if d.getVar("UNINATIVE_URL") == "unset":
bb.fatal("Uninative selected but not configured, please set
UNINATIVE_URL")
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] uninative: Update to 2.7 release
On 2019-10-11 10:26, Stefan Agner wrote:
> On 2019-10-07 18:47, Michael Halstead wrote:
>> The 2.7 release updates glibc to version 2.30. Recently added to openSUSE
>> Tumbleweed and needed for Fedora Core 31.
>
> Since we updated master to include this commit we see regularly the following
> issues:
>
>
> WARNING: Disabling uninative as unable to install uninative tarball:
> Command 'mkdir -p /workdir/oe/tmp/sysroots-uninative; cd
> /workdir/oe/tmp/sysroots-uninative; tar -xJf
> /workdir/downloads/uninative//9498d8bba04749a7310ac2576d0796461184965351a56f6d32c888a1f216/x86_64-nativesdk-libc.tar.xz;
> /workdir/oe/tmp/sysroots-uninative/relocate_sdk.py
> /workdir/oe/tmp/sysroots-uninative/x86_64-linux
> /workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
>
> /workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
>
> /workdir/oe/tmp/sysroots-uninative/x86_64-linux//usr/bin/patchelf-uninative
>
> /workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/libc*.so' returned
> non-zero exit status 1.
> WARNING: To build your own uninative loader, please bitbake
> uninative-tarball and set UNINATIVE_TARBALL appropriately.
>
> [...]
>
> ERROR: ldconfig-native-2.12.1-r2 do_populate_sysroot_setscene: Error
> executing a python function in exec_python_func() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function:
> 0001:
> *** 0002:uninative_changeinterp(d)
> 0003:
> File:
> '/workdir/oe/build/conf/../../layers/openembedded-core/meta/classes/uninative.bbclass',
> lineno: 165, function: uninative_changeinterp
> 0161:continue
> 0162:if not elf.isDynamic():
> 0163:continue
> 0164:
> *** 0165:subprocess.check_output(("patchelf-uninative",
> "--set-interpreter", d.getVar("UNINATIVE_LOADER"), f),
> stderr=subprocess.STDOUT)
> 0166:}
> File: '/usr/lib/python3.6/subprocess.py', lineno: 336, function: check_output
> 0332:# empty string. That is maintained here for
> backwards compatibility.
> 0333:kwargs['input'] = '' if
> kwargs.get('universal_newlines', False) else b''
> 0334:
> 0335:return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
> *** 0336: **kwargs).stdout
> 0337:
> 0338:
> 0339:class CompletedProcess(object):
> 0340:"""A process that has finished running.
> File: '/usr/lib/python3.6/subprocess.py', lineno: 403, function: run
> 0399:if 'stdin' in kwargs:
> 0400:raise ValueError('stdin and input arguments may
> not both be used.')
> 0401:kwargs['stdin'] = PIPE
> 0402:
> *** 0403:with Popen(*popenargs, **kwargs) as process:
> 0404:try:
> 0405:stdout, stderr = process.communicate(input,
> timeout=timeout)
> 0406:except TimeoutExpired:
> 0407:process.kill()
> File: '/usr/lib/python3.6/subprocess.py', lineno: 709, function: __init__
> 0705:startupinfo, creationflags, shell,
> 0706:p2cread, p2cwrite,
> 0707:c2pread, c2pwrite,
> 0708:errread, errwrite,
> *** 0709:restore_signals, start_new_session)
> 0710:except:
> 0711:# Cleanup if the child failed starting.
> 0712:for f in filter(None, (self.stdin, self.stdout,
> self.stderr)):
> 0713:try:
> File: '/usr/lib/python3.6/subprocess.py', lineno: 1344, function:
> _execute_child
> 1340:if errno_num != 0:
> 1341:err_msg = os.strerror(errno_num)
> 1342:if errno_num == errno.ENOENT:
> 1343:err_msg += ': ' + repr(err_filename)
> *** 1344:raise child_exception_type(errno_num,
> err_msg, err_filename)
> 1345:raise child_exception_type(err_msg)
> 1346:
> 1347:
> 1348:def _handle_exitstatus(self, sts,
> _WIFSIGNALED=os.WIFSIGNALED,
> Exception: FileNotFoundError: [Errno 2] No such file or directory:
> 'patchelf-uninative': 'patchelf-uninative'
>
> ERROR: Logfile of failure stored in:
> /workdir/oe/tmp/work/x8
Re: [OE-core] [PATCH v2] uninative: Update to 2.7 release
On 2019-10-07 18:47, Michael Halstead wrote:
> The 2.7 release updates glibc to version 2.30. Recently added to openSUSE
> Tumbleweed and needed for Fedora Core 31.
Since we updated master to include this commit we see regularly the following
issues:
WARNING: Disabling uninative as unable to install uninative tarball: Command
'mkdir -p /workdir/oe/tmp/sysroots-uninative; cd
/workdir/oe/tmp/sysroots-uninative; tar -xJf
/workdir/downloads/uninative//9498d8bba04749a7310ac2576d0796461184965351a56f6d32c888a1f216/x86_64-nativesdk-libc.tar.xz;
/workdir/oe/tmp/sysroots-uninative/relocate_sdk.py
/workdir/oe/tmp/sysroots-uninative/x86_64-linux
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
/workdir/oe/tmp/sysroots-uninative/x86_64-linux//usr/bin/patchelf-uninative
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/libc*.so' returned non-zero
exit status 1.
WARNING: To build your own uninative loader, please bitbake uninative-tarball
and set UNINATIVE_TARBALL appropriately.
[...]
ERROR: ldconfig-native-2.12.1-r2 do_populate_sysroot_setscene: Error executing
a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function:
0001:
*** 0002:uninative_changeinterp(d)
0003:
File:
'/workdir/oe/build/conf/../../layers/openembedded-core/meta/classes/uninative.bbclass',
lineno: 165, function: uninative_changeinterp
0161:continue
0162:if not elf.isDynamic():
0163:continue
0164:
*** 0165:subprocess.check_output(("patchelf-uninative",
"--set-interpreter", d.getVar("UNINATIVE_LOADER"), f), stderr=subprocess.STDOUT)
0166:}
File: '/usr/lib/python3.6/subprocess.py', lineno: 336, function: check_output
0332:# empty string. That is maintained here for backwards
compatibility.
0333:kwargs['input'] = '' if kwargs.get('universal_newlines',
False) else b''
0334:
0335:return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
*** 0336: **kwargs).stdout
0337:
0338:
0339:class CompletedProcess(object):
0340:"""A process that has finished running.
File: '/usr/lib/python3.6/subprocess.py', lineno: 403, function: run
0399:if 'stdin' in kwargs:
0400:raise ValueError('stdin and input arguments may not both
be used.')
0401:kwargs['stdin'] = PIPE
0402:
*** 0403:with Popen(*popenargs, **kwargs) as process:
0404:try:
0405:stdout, stderr = process.communicate(input,
timeout=timeout)
0406:except TimeoutExpired:
0407:process.kill()
File: '/usr/lib/python3.6/subprocess.py', lineno: 709, function: __init__
0705:startupinfo, creationflags, shell,
0706:p2cread, p2cwrite,
0707:c2pread, c2pwrite,
0708:errread, errwrite,
*** 0709:restore_signals, start_new_session)
0710:except:
0711:# Cleanup if the child failed starting.
0712:for f in filter(None, (self.stdin, self.stdout,
self.stderr)):
0713:try:
File: '/usr/lib/python3.6/subprocess.py', lineno: 1344, function: _execute_child
1340:if errno_num != 0:
1341:err_msg = os.strerror(errno_num)
1342:if errno_num == errno.ENOENT:
1343:err_msg += ': ' + repr(err_filename)
*** 1344:raise child_exception_type(errno_num, err_msg,
err_filename)
1345:raise child_exception_type(err_msg)
1346:
1347:
1348:def _handle_exitstatus(self, sts, _WIFSIGNALED=os.WIFSIGNALED,
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'patchelf-uninative': 'patchelf-uninative'
ERROR: Logfile of failure stored in:
/workdir/oe/tmp/work/x86_64-linux/ldconfig-native/2.12.1-r2/temp/log.do_populate_sysroot_setscene.14967
Looking into the directory shows that uninative only got extracted half-way:
$ find /workdir/oe/tmp/sysroots-uninative
/workdir/oe/tmp/sysroots-uninative
/workdir/oe/tmp/sysroots-uninative/x86_64-linux
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/libresolv-2.30.so
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/libnsl.so.1
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/libanl.so.1
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/libnss_compat-2.30.so
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/libpthread-2.30.so
/workdir/oe/tmp/sysroots-uninative/x86_64-linux/lib/l
Re: [OE-core] ✗ patchtest: failure for zram: properly implement systemd service
Hi all, As an on and off contributor I rely on the instructions in the OE wiki. Unfortunately the example for meta-oe is just next of an example using the openembedded-core@lists.openembedded.org. Maybe the second example should contain the correct address for meta-oe as well? http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Sending_patches -- Stefan On 2019-10-05 23:31, Patchwork wrote: > == Series Details == > > Series: zram: properly implement systemd service > Revision: 1 > URL : https://patchwork.openembedded.org/series/20315/ > State : failure > > == Summary == > > > Thank you for submitting this patch series to OpenEmbedded Core. This is > an automated response. Several tests have been executed on the proposed > series by patchtest resulting in the following failures: > > > > * Issue Series sent to the wrong mailing list or some > patches from the series correspond to different mailing lists > [test_target_mailing_list] > Suggested fixSend the series again to the correct mailing list (ML) > Suggested ML openembedded-de...@lists.openembedded.org > [http://git.openembedded.org/meta-openembedded/] > Patch's path:meta-oe/recipes-extended/zram/zram/dev-zram0.swap > > * Issue Series does not apply on top of target branch > [test_series_merge_on_head] > Suggested fixRebase your series on top of targeted branch > Targeted branch master (currently at 520c6f30cd) > > > > If you believe any of these test results are incorrect, please reply to the > mailing list (openembedded-core@lists.openembedded.org) raising your concerns. > Otherwise we would appreciate you correcting the issues and submitting a new > version of the patchset if applicable. Please ensure you add/increment the > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> > [PATCH v3] -> ...). > > --- > Guidelines: > https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] zram: properly implement systemd service
From: Stefan Agner
The systemd service points ot a script which is not installed by
zram or any of its dependencies. It seems that the service got
migrated without the necessary script.
The sysvinit script seems rather dated and initializes multiple
zram instances to support multiprocessor systems. This is no
longer necessary with modern implementations as newer kernel
version support multiple streams by default.
Create a modern implementation based on Fedoras zram package.
Make use of systemd swap unit files instead of enabling swap
directly.
This removes the need for util-linux-swaponoff (since swap is
now handled by systemd, which presumably depends on swaponoff).
However, it adds the dependency to util-linux for zramctl.
Signed-off-by: Stefan Agner
---
.../recipes-extended/zram/zram/dev-zram0.swap | 10
.../zram/zram/zram-swap-deinit| 19 +++
.../recipes-extended/zram/zram/zram-swap-init | 26 ++
.../zram/zram/zram-swap.service | 10
.../recipes-extended/zram/zram/zram.service | 12 -
meta-oe/recipes-extended/zram/zram/zramstop | 5 ++
meta-oe/recipes-extended/zram/zram_0.1.bb | 33 -
meta-oe/recipes-extended/zram/zram_0.2.bb | 49 +++
8 files changed, 119 insertions(+), 45 deletions(-)
create mode 100644 meta-oe/recipes-extended/zram/zram/dev-zram0.swap
create mode 100755 meta-oe/recipes-extended/zram/zram/zram-swap-deinit
create mode 100755 meta-oe/recipes-extended/zram/zram/zram-swap-init
create mode 100644 meta-oe/recipes-extended/zram/zram/zram-swap.service
delete mode 100644 meta-oe/recipes-extended/zram/zram/zram.service
create mode 100644 meta-oe/recipes-extended/zram/zram/zramstop
delete mode 100644 meta-oe/recipes-extended/zram/zram_0.1.bb
create mode 100644 meta-oe/recipes-extended/zram/zram_0.2.bb
diff --git a/meta-oe/recipes-extended/zram/zram/dev-zram0.swap
b/meta-oe/recipes-extended/zram/zram/dev-zram0.swap
new file mode 100644
index 0..05eae7eed
--- /dev/null
+++ b/meta-oe/recipes-extended/zram/zram/dev-zram0.swap
@@ -0,0 +1,10 @@
+[Unit]
+Description=Enable compressed swap in memory using zram
+Requires=zram-swap.service
+After=zram-swap.service
+
+[Swap]
+What=/dev/zram0
+
+[Install]
+WantedBy=swap.target
diff --git a/meta-oe/recipes-extended/zram/zram/zram-swap-deinit
b/meta-oe/recipes-extended/zram/zram/zram-swap-deinit
new file mode 100755
index 0..46248c401
--- /dev/null
+++ b/meta-oe/recipes-extended/zram/zram/zram-swap-deinit
@@ -0,0 +1,19 @@
+#!/bin/sh
+set -e
+
+device=$1
+if [ "$device" = "" ]; then
+echo "Usage: zram-swap-deinit "
+exit 1
+fi
+
+sysblockdev=/sys/block/$(basename $device)
+if [ ! -d $sysblockdev ]; then
+echo "Block device not found in sysfs"
+exit 1
+fi
+
+# zramctl -r is not suitable as it also removes the actual device. Recreating
+# it is non-trivial, especially if not /dev/zram0 is used...
+echo 1 > ${sysblockdev}/reset
+
diff --git a/meta-oe/recipes-extended/zram/zram/zram-swap-init
b/meta-oe/recipes-extended/zram/zram/zram-swap-init
new file mode 100755
index 0..0643dbca2
--- /dev/null
+++ b/meta-oe/recipes-extended/zram/zram/zram-swap-init
@@ -0,0 +1,26 @@
+#!/bin/sh
+set -e
+
+device=$1
+if [ "$device" = "" ]; then
+echo "Usage: zram-swap-init "
+exit 1
+fi
+
+# Allocate zram to be size of actual system memory
+# Note: zram is only allocated when used. When swapped pages compress with a
+# a 2:1 ratio zram will require 50% of system memory (while allowing to use
+# 150% memory).
+ZRAM_SIZE_PERCENT=100
+ZRAM_ALGORITHM=lz4
+
+[ -f /etc/default/zram ] && ./etc/default/zram || true
+
+memtotal=$(grep MemTotal /proc/meminfo | awk ' { print $2 } ')
+memzram=$(($memtotal*${ZRAM_SIZE_PERCENT}/100))
+
+# Try loading zram module
+modprobe -q zram || true
+
+zramctl -a ${ZRAM_ALGORITHM} -s ${memzram}KB $device
+mkswap -L "zram-swap" $device
diff --git a/meta-oe/recipes-extended/zram/zram/zram-swap.service
b/meta-oe/recipes-extended/zram/zram/zram-swap.service
new file mode 100644
index 0..7bb9e0a45
--- /dev/null
+++ b/meta-oe/recipes-extended/zram/zram/zram-swap.service
@@ -0,0 +1,10 @@
+[Unit]
+Description=Create compressed swap in memory using zram
+DefaultDependencies=no
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+TimeoutStartSec=30sec
+ExecStart=/usr/libexec/zram-swap-init /dev/zram0
+ExecStop=/usr/libexec/zram-swap-deinit /dev/zram0
diff --git a/meta-oe/recipes-extended/zram/zram/zram.service
b/meta-oe/recipes-extended/zram/zram/zram.service
deleted file mode 100644
index 4a19367d9..0
--- a/meta-oe/recipes-extended/zram/zram/zram.service
+++ /dev/null
@@ -1,12 +0,0 @@
-[Unit]
-Description=Enable zram compressed in-memory swap.
-After=multi-user.target
-
-[Service]
-RemainAfterExit=yes
-ExecStart=/usr/bin/zram-load.sh --load
-ExecStop=/usr/bin/zram-load.sh --unload
-
Re: [OE-core] [PATCH v2 4/4] weston: Set depends to the virtual needed not explicitly on Mesa
On 2019-09-17 15:10, Andrew F. Davis via Openembedded-core wrote:
> The dependency is for EGL and GLES2 libraries. On some systems these
> are not provided by Mesa, list what is actually needed so the system
> can choose the correct provider.
Unfortunately I saw that a bit late, but this is breaking our use case.
Weston works perfectly fine on non-GPU systems without EGL/OpenGL ES
using pixman renderer. Currently libgbm is still a compile time
dependency, but I have a merge request pending which should drop this
dependency, then the DRM backend can be compiled fine with only KMS
support.
--
Stefan
>
> Signed-off-by: Andrew F. Davis
> Acked-by: Denys Dmytriyenko
> ---
>
> Changes from v1:
> - s/gles2/libgles2
>
> meta/recipes-graphics/wayland/weston_7.0.0.bb | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-graphics/wayland/weston_7.0.0.bb
> b/meta/recipes-graphics/wayland/weston_7.0.0.bb
> index 5d2a9336f3..f9efdbd20a 100644
> --- a/meta/recipes-graphics/wayland/weston_7.0.0.bb
> +++ b/meta/recipes-graphics/wayland/weston_7.0.0.bb
> @@ -36,9 +36,9 @@ PACKAGECONFIG ??=
> "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'kms fbdev
> # Compositor choices
> #
> # Weston on KMS
> -PACKAGECONFIG[kms] = "-Dbackend-drm=true,-Dbackend-drm=false,drm udev
> virtual/mesa virtual/libgbm mtdev"
> +PACKAGECONFIG[kms] = "-Dbackend-drm=true,-Dbackend-drm=false,drm udev
> virtual/egl virtual/libgles2 virtual/libgbm mtdev"
> # Weston on Wayland (nested Weston)
> -PACKAGECONFIG[wayland] =
> "-Dbackend-wayland=true,-Dbackend-wayland=false,virtual/mesa"
> +PACKAGECONFIG[wayland] =
> "-Dbackend-wayland=true,-Dbackend-wayland=false,virtual/egl
> virtual/libgles2"
> # Weston on X11
> PACKAGECONFIG[x11] =
> "-Dbackend-x11=true,-Dbackend-x11=false,virtual/libx11 libxcb libxcb
> libxcursor cairo"
> # Headless Weston
> --
> 2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston: change to use meson build system
Hi Ming,
Thanks for working on that!
On 2019-07-25 13:41, liu.min...@gmail.com wrote:
> From: Ming Liu
>
> The changes include:
> - Drop all autotools related patches.
> - Move weston-launch setuid-install to do_install task since it's not
> supported yet by meson build.
> - Drop cairo-glesv2 package config, it's not supported by meson build,
> it is hardcoded to cairo-image for now in weston source.
It seem that upstream recommends cairo image anyway (see README.md). I
am not exactly sure why, but this bug seems to indicate that using the
image backend is more efficient?
https://gitlab.freedesktop.org/wayland/weston/issues/46
I actually realized that meta-freescale uses the cairo-glesv2 package
config.
[added Tom to CC who added the package config a while ago]
I guess we should send a patch to remove that.
Otherwise the patch looks good to me. I like the fact that this patch
mostly migrates 1:1 to Meson without changing anything else.
--
Stefan
> - Introduce remoting package config, without it meson would run into a
> build error.
>
> Signed-off-by: Stefan Agner
> Signed-off-by: Ming Liu
> ---
> .../wayland/weston/0001-make-error-portable.patch | 34
> ...ch-Provide-a-default-version-that-doesn-t.patch | 93
> ++
> meta/recipes-graphics/wayland/weston_6.0.0.bb | 48 +--
> 3 files changed, 101 insertions(+), 74 deletions(-)
>
> diff --git
> a/meta/recipes-graphics/wayland/weston/0001-make-error-portable.patch
> b/meta/recipes-graphics/wayland/weston/0001-make-error-portable.patch
> index 0eb3d95..acea9db 100644
> --- a/meta/recipes-graphics/wayland/weston/0001-make-error-portable.patch
> +++ b/meta/recipes-graphics/wayland/weston/0001-make-error-portable.patch
> @@ -9,27 +9,14 @@ kind of systemsi e.g. musl.
> Upstream-Status: Submitted
>
> Signed-off-by: Khem Raj
> -
> +Signed-off-by: Ming Liu
> ---
> - configure.ac | 2 ++
> libweston/weston-error.h | 20
> libweston/weston-launch.c | 2 +-
> - 3 files changed, 23 insertions(+), 1 deletion(-)
> + meson.build | 1 +
> + 3 files changed, 22 insertions(+), 1 deletion(-)
> create mode 100644 libweston/weston-error.h
>
> -diff --git a/configure.ac b/configure.ac
> -index c05ad01..6da6e04 100644
> a/configure.ac
> -+++ b/configure.ac
> -@@ -126,6 +126,8 @@ AC_CHECK_DECL(CLOCK_MONOTONIC,[],
> - [AC_MSG_ERROR("CLOCK_MONOTONIC is needed to compile weston")],
> - [[#include ]])
> -
> -+AC_CHECK_HEADERS([error.h])
> -+
> - AC_CHECK_FUNCS([mkostemp strchrnul initgroups posix_fallocate])
> -
> - # check for libdrm as a build-time dependency only
> diff --git a/libweston/weston-error.h b/libweston/weston-error.h
> new file mode 100644
> index 000..2089d02
> @@ -76,3 +63,18 @@ index bf73e0d..9064439 100644
>
> #define DRM_MAJOR 226
>
> +diff --git a/meson.build b/meson.build
> +index 2155b7b..baa52d9 100644
> +--- a/meson.build
> b/meson.build
> +@@ -94,6 +94,7 @@ foreach func : optional_libc_funcs
> + endforeach
> +
> + optional_system_headers = [
> ++'error.h',
> + 'linux/sync_file.h'
> + ]
> + foreach hdr : optional_system_headers
> +--
> +2.7.4
> +
> diff --git
> a/meta/recipes-graphics/wayland/weston/0001-weston-launch-Provide-a-default-version-that-doesn-t.patch
> b/meta/recipes-graphics/wayland/weston/0001-weston-launch-Provide-a-default-version-that-doesn-t.patch
> index a2f61bf..81cc025 100644
> ---
> a/meta/recipes-graphics/wayland/weston/0001-weston-launch-Provide-a-default-version-that-doesn-t.patch
> +++
> b/meta/recipes-graphics/wayland/weston/0001-weston-launch-Provide-a-default-version-that-doesn-t.patch
> @@ -15,44 +15,46 @@ Upstream-Status: Pending
> Signed-off-by: Tom Hochstein
> Signed-off-by: Jussi Kukkonen
> Signed-off-by: Denys Dmytriyenko
> -
> +Signed-off-by: Ming Liu
> ---
> - configure.ac | 9 +++--
> + libweston/meson.build | 16
> libweston/weston-launch.c | 20
> - 2 files changed, 27 insertions(+), 2 deletions(-)
> + meson_options.txt | 7 +++
> + 3 files changed, 39 insertions(+), 4 deletions(-)
>
> -diff --git a/configure.ac b/configure.ac
> -index 6da6e04..681f7c8 100644
> a/configure.ac
> -+++ b/configure.ac
> -@@ -515,13 +515,17 @@ AC_ARG_ENABLE(resize-optimization,
> - AS_IF([test "x$enable_resize_optimization" = "xyes"],
> - [AC_DEFINE([USE_RESIZE_POOL], [1], [Use resize memory pool as
> a performance optimization])])
> -
> -+AC_ARG_WITH(pam,
> -+AS_HELP_STRING([
Re: [OE-core] [PATCH] weston: change to use meson build system
On 2019-07-25 14:21, Burton, Ross wrote: > On Thu, 25 Jul 2019 at 12:42, wrote: >> - Introduce remoting package config, without it meson would run into a >> build error. What do you mean by that exactly, I guess it does build at all with remoting, and by introducing a packaging config you disable it for now? > > Did you tell upstream about this? There is actually Weston 6.0.1 with some Meson related fixed, also remoting: https://gitlab.freedesktop.org/wayland/weston/commits/6.0.1 We probably should upgrade to 6.0.1 too. -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] psplash: create psplash tmpfs mount directory in psplash-init
From: Stefan Agner
The psplash binary uses TMPDIR as directory to store the FIFO to
communicate with the psplash tools. This directory can be in any
location an init system determines to be suitable, psplash-init
uses /mnt/ for it. Rather than creating the mount directory in
the recipe, just create it in the init script itself. This allows
other init scripts to use a different location without having
an unnecessary .psplash directory in /mnt.
Signed-off-by: Stefan Agner
---
meta/recipes-core/psplash/files/psplash-init | 1 +
meta/recipes-core/psplash/psplash_git.bb | 3 ---
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-core/psplash/files/psplash-init
b/meta/recipes-core/psplash/files/psplash-init
index 0bce1de536..fee23e681c 100755
--- a/meta/recipes-core/psplash/files/psplash-init
+++ b/meta/recipes-core/psplash/files/psplash-init
@@ -24,6 +24,7 @@ for x in $CMDLINE; do
done
export TMPDIR=/mnt/.psplash
+[ -d $TMPDIR ] || mkdir -p $TMPDIR
mount tmpfs -t tmpfs $TMPDIR -o,size=40k
rotation=0
diff --git a/meta/recipes-core/psplash/psplash_git.bb
b/meta/recipes-core/psplash/psplash_git.bb
index 3161a5e3f1..56734c1582 100644
--- a/meta/recipes-core/psplash/psplash_git.bb
+++ b/meta/recipes-core/psplash/psplash_git.bb
@@ -97,7 +97,6 @@ python do_compile () {
}
do_install_append() {
- install -d ${D}/mnt/.psplash/
install -d ${D}${sysconfdir}/init.d/
install -m 0755 ${WORKDIR}/psplash-init
${D}${sysconfdir}/init.d/psplash.sh
install -d ${D}${bindir}
@@ -107,8 +106,6 @@ do_install_append() {
rm -f ${D}${bindir}/psplash
}
-FILES_${PN} += "/mnt/.psplash"
-
INITSCRIPT_NAME = "psplash.sh"
INITSCRIPT_PARAMS = "start 0 S . stop 20 0 1 6 ."
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] psplash: create psplash tmpfs mount directory in psplash-init
From: Stefan Agner
The psplash binary uses TMPDIR as directory to store the FIFO to
communicate with the psplash tools. This directory can be in any
location an init system determines to be suitable, psplash-init
uses /mnt/ for it. Rather than creating the mount directory in
the recipe, just create it in the init script itself. This allows
other init scripts to use a different location without having
an unnecessary .psplash directory in /mnt.
Signed-off-by: Stefan Agner
---
meta/recipes-core/psplash/files/psplash-init | 1 +
meta/recipes-core/psplash/psplash_git.bb | 3 ---
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-core/psplash/files/psplash-init
b/meta/recipes-core/psplash/files/psplash-init
index 0bce1de536..7a3902a7e0 100755
--- a/meta/recipes-core/psplash/files/psplash-init
+++ b/meta/recipes-core/psplash/files/psplash-init
@@ -24,6 +24,7 @@ for x in $CMDLINE; do
done
export TMPDIR=/mnt/.psplash
+mkdir -p $TMPDIR
mount tmpfs -t tmpfs $TMPDIR -o,size=40k
rotation=0
diff --git a/meta/recipes-core/psplash/psplash_git.bb
b/meta/recipes-core/psplash/psplash_git.bb
index 3161a5e3f1..56734c1582 100644
--- a/meta/recipes-core/psplash/psplash_git.bb
+++ b/meta/recipes-core/psplash/psplash_git.bb
@@ -97,7 +97,6 @@ python do_compile () {
}
do_install_append() {
- install -d ${D}/mnt/.psplash/
install -d ${D}${sysconfdir}/init.d/
install -m 0755 ${WORKDIR}/psplash-init
${D}${sysconfdir}/init.d/psplash.sh
install -d ${D}${bindir}
@@ -107,8 +106,6 @@ do_install_append() {
rm -f ${D}${bindir}/psplash
}
-FILES_${PN} += "/mnt/.psplash"
-
INITSCRIPT_NAME = "psplash.sh"
INITSCRIPT_PARAMS = "start 0 S . stop 20 0 1 6 ."
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: udhcpc: fix IPv6 support when using udhcpc
Hi, Any comment on this patch? Just stumbled upon that problem today again :-) -- Stefan On 14.05.2018 16:44, Stefan Agner wrote: > From: Stefan Agner > > The udhcpc script calls ip addr flush .. which flushes addresses > of any address family, including IPv6. However, busybox udhcpc is > IPv4 only and should not influence IPv6 addressing. Hence use ip > addr flush with family constrait. > > The script particularly broke IPv6 SLAAC: Typically when udhcpc > calls the script the kernel already assigned the IPv6 link-local > address. The flush removes the link-local IPv6 address again and > prohibits proper IPv6 operation such as SLAAC since neighbor > discovery protocol relies on IPv6 link-local addressing. > > Signed-off-by: Stefan Agner > --- > meta/recipes-core/busybox/files/simple.script | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-core/busybox/files/simple.script > b/meta/recipes-core/busybox/files/simple.script > index 6ed0293525..8b5eb53633 100644 > --- a/meta/recipes-core/busybox/files/simple.script > +++ b/meta/recipes-core/busybox/files/simple.script > @@ -28,7 +28,7 @@ case "$1" in > fi > if ! root_is_nfs ; then > if [ $have_bin_ip -eq 1 ]; then > -/SBIN_DIR/ip addr flush dev $interface > +/SBIN_DIR/ip -4 addr flush dev $interface > /SBIN_DIR/ip link set dev $interface up > else > /SBIN_DIR/ifconfig $interface 0.0.0.0 > -- > 2.13.6 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [thud][PATCH] opkg-utils: backport a patch to fix a sstate timestamp issue
On 05.04.2019 16:22, liu.min...@gmail.com wrote:
> From: Ming Liu
>
> When using sstate, two parallel builds can produce two packages
> with the same mtime but different checksums. When later one of
> those two builds fetches the others ipk, the package index does
> not get udpated properly (since mtime matches). This ends up with
> messages such as:
> Downloading file:/../tmp/work/../image/...ipk.
> Removing corrupt package file /../sysroot/../var/cache/opkg/volatile/...ipk
>
> However, in that case, ctime is different. Use ctime instead of
> mtime to prevent failures like this.
FWIW,
Acked-by Stefan Agner
I fixed this in master, and it actually helps us resolving issues we see
on CI on thud branch.
--
Stefan
>
> Signed-off-by: Ming Liu
> ---
> ...pkg-make-index-use-ctime-instead-of-mtime.patch | 59
> ++
> .../opkg-utils/opkg-utils_0.3.6.bb | 1 +
> 2 files changed, 60 insertions(+)
> create mode 100644
> meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-make-index-use-ctime-instead-of-mtime.patch
>
> diff --git
> a/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-make-index-use-ctime-instead-of-mtime.patch
> b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-make-index-use-ctime-instead-of-mtime.patch
> new file mode 100644
> index 000..19778ac
> --- /dev/null
> +++
> b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-make-index-use-ctime-instead-of-mtime.patch
> @@ -0,0 +1,59 @@
> +From 0cd38bb1bdcdbfc091014a1f39d015a1586a33e6 Mon Sep 17 00:00:00 2001
> +From: Stefan Agner
> +Date: Fri, 19 Oct 2018 17:38:21 +0200
> +Subject: [PATCH] opkg-make-index: use ctime instead of mtime
> +
> +Upstream-Status: Backport
> +
> +When using sstate, two parallel builds can produce two packages
> +with the same mtime but different checksums. When later one of
> +those two builds fetches the others ipk, the package index does
> +not get udpated properly (since mtime matches). This ends up with
> +messages such as:
> + Downloading file:/../tmp/work/../image/...ipk.
> + Removing corrupt package file /../sysroot/../var/cache/opkg/volatile/...ipk
> +
> +However, in that case, ctime is different. Use ctime instead of
> +mtime to prevent failures like this.
> +
> +Suggested-by: Khem Raj
> +Signed-off-by: Stefan Agner
> +Acked-by: Richard Purdie
> +Acked-by: Khem Raj
> +Signed-off-by: Alejandro del Castillo
> +Signed-off-by: Ming Liu
> +---
> + opkg-make-index | 6 +++---
> + 1 file changed, 3 insertions(+), 3 deletions(-)
> +
> +diff --git a/opkg-make-index b/opkg-make-index
> +index 3227fc0..db7bf64 100755
> +--- a/opkg-make-index
> b/opkg-make-index
> +@@ -115,12 +115,12 @@ for abspath in files:
> + pkg = None
> + fnameStat = os.stat(abspath)
> + if filename in old_pkg_hash:
> +- if filename in pkgsStamps and int(fnameStat.st_mtime) ==
> pkgsStamps[filename]:
> ++ if filename in pkgsStamps and int(fnameStat.st_ctime) ==
> pkgsStamps[filename]:
> + if (verbose):
> +sys.stderr.write("Found %s in Packages\n" % (filename,))
> + pkg = old_pkg_hash[filename]
> + else:
> +- sys.stderr.write("Found %s in Packages, but mtime
> differs - re-reading\n" % (filename,))
> ++ sys.stderr.write("Found %s in Packages, but ctime
> differs - re-reading\n" % (filename,))
> +
> + if not pkg:
> + if (verbose):
> +@@ -137,7 +137,7 @@ for abspath in files:
> + else:
> + old_filename = ""
> + s = packages.add_package(pkg, opt_a)
> +- pkgsStamps[filename] = fnameStat.st_mtime
> ++ pkgsStamps[filename] = fnameStat.st_ctime
> + if s == 0:
> + if old_filename:
> +# old package was displaced by newer
> +--
> +2.7.4
> +
> diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.6.bb
> b/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.6.bb
> index 4c41774..41cf11c 100644
> --- a/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.6.bb
> +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.6.bb
> @@ -14,6 +14,7 @@ SRC_URI =
> "http://git.yoctoproject.org/cgit/cgit.cgi/${BPN}/snapshot/${BPN}-${PV
> file://threaded-xz.patch \
> file://pigz.patch \
> file://0001-update-alternatives-Fix-link-relocation-support.patch
> \
> + file://0001-opkg-make-index-use-ctime-instead-of-mtime.patch \
> "
> SRC_URI_append_class-native = " file://tar_ignore_error.patch"
> UPSTREAM_CHECK_URI =
> "http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/refs/";
> --
> 2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: export XDG_DATA_DIRS in wrappers
0119:else:
*** 0120:with open(src, 'rb') as fsrc:
0121:with open(dst, 'wb') as fdst:
0122:copyfileobj(fsrc, fdst)
0123:return dst
0124:
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/workdir/oe/tmp/work/cortexa7t2hf-neon-torizon-linux-gnueabi/psplash/0.1+gitAUTOINC+2015f7073e-r15/torizon-blue-img.h'
Note that the error is somewhat misleading since the real problem
happened in the convert script, where the header did not get created due
to gdk-pixbuf-csource not recognizing the png file (Couldn't recognize
the image file format for file ..). This patch fixes the problem!
Tested-by: Stefan Agner
Thanks Ming for looking into this!
--
Stefan
>
> Signed-off-by: Ming Liu
> ---
> meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb
> b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb
> index 3a544bd..a5bd7c6 100644
> --- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb
> +++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb
> @@ -112,19 +112,24 @@ do_install_append_class-native() {
> find ${D}${libdir} -name "libpixbufloader-*.la" -exec rm \{\} \;
>
> create_wrapper ${D}/${bindir}/gdk-pixbuf-csource \
> + XDG_DATA_DIRS=${STAGING_DATADIR} \
>
>
> GDK_PIXBUF_MODULE_FILE=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/loaders.cache
>
> create_wrapper ${D}/${bindir}/gdk-pixbuf-pixdata \
> + XDG_DATA_DIRS=${STAGING_DATADIR} \
>
>
> GDK_PIXBUF_MODULE_FILE=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/loaders.cache
>
> create_wrapper ${D}/${bindir}/gdk-pixbuf-print-mime-types \
> + XDG_DATA_DIRS=${STAGING_DATADIR} \
>
>
> GDK_PIXBUF_MODULE_FILE=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/loaders.cache
>
> create_wrapper ${D}/${libdir}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \
> + XDG_DATA_DIRS=${STAGING_DATADIR} \
>
>
> GDK_PIXBUF_MODULE_FILE=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/loaders.cache
> \
>
> GDK_PIXBUF_MODULEDIR=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/loaders
>
> create_wrapper ${D}/${bindir}/gdk-pixbuf-query-loaders \
> + XDG_DATA_DIRS=${STAGING_DATADIR} \
>
>
> GDK_PIXBUF_MODULE_FILE=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/loaders.cache
> \
>
> GDK_PIXBUF_MODULEDIR=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/loaders
> }
> --
> 2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On 01.03.2019 20:15, Stefan Agner wrote: > On 23.02.2019 13:29, Richard Purdie wrote: >> On Wed, 2019-02-20 at 21:10 +0100, Alexander Kanavin wrote: >>> Drop autotools-specific patches. >>> >>> Rework jku's thumbnailer patch into meson configuration. >>> >>> Signed-off-by: Alexander Kanavin >> >> We've seen it before but its happened again: >> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/326 >> >> I went into the failed build directory and ran "bitbake core-image-sato >> -c testsdkext" and it succeeded so I'm not sure sure how we're going to >> debug this one... > > I am not sure if it is related, but we see psplash failing with a custom > png recently. > > failed to load ".../splashscreen-blue.png": Couldn’t recognize the image > file format for file “.../splashscreen-blue.png” > > The psplash calls gdk-pixbuf-csource (through make-image-header.sh). We > only saw it failing when building in a Ubuntu 18.04 container, but then > reproducible. > > I also noticed this (probably unrelated) in do_configure log: > > DEBUG: Executing shell function do_configure > gtkdocize: neither configure.ac nor configure.in exist > NOTE: Executing meson -Denable_jpeg=true -Denable_jasper=false > -Denable_png=true -Denable_tiff=false -Dx11=false > -Dinstalled_tests=false... > The Meson build system > Version: 0.49.2 > Source dir: > /workdir/oe/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/gdk-pixbuf-2.38.0 > Build dir: > /workdir/oe/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/build > Build type: native build > WARNING: Unknown options: "enable_jasper, enable_jpeg, enable_png, > enable_tiff > ... FWIW, I sent a patch to fix this particular warning just above. However, my issue persists. The problem is definitly gdk-pixbuf related, but reverting the two patches from this patchset did not resolve the issue. -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gdk-pixbuf: fix Meson variable names
From: Stefan Agner
With 2.38.0 gdk-pixbuf dopped the enable_ prefix from the Meson
build options.
Signed-off-by: Stefan Agner
---
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb
index 3a544bd8a6..448e8ab40e 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.38.0.bb
@@ -58,10 +58,10 @@ PACKAGECONFIG ??= "${GDK_PIXBUF_LOADERS}"
PACKAGECONFIG_linuxstdbase = "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}
${GDK_PIXBUF_LOADERS}"
PACKAGECONFIG_class-native = "${GDK_PIXBUF_LOADERS}"
-PACKAGECONFIG[png] = "-Denable_png=true,-Denable_png=false,libpng"
-PACKAGECONFIG[jpeg] = "-Denable_jpeg=true,-Denable_jpeg=false,jpeg"
-PACKAGECONFIG[tiff] = "-Denable_tiff=true,-Denable_tiff=false,tiff"
-PACKAGECONFIG[jpeg2000] = "-Denable_jasper=true,-Denable_jasper=false,jasper"
+PACKAGECONFIG[png] = "-Dpng=true,-Dpng=false,libpng"
+PACKAGECONFIG[jpeg] = "-Djpeg=true,-Djpeg=false,jpeg"
+PACKAGECONFIG[tiff] = "-Dtiff=true,-Dtiff=false,tiff"
+PACKAGECONFIG[jpeg2000] = "-Djasper=true,-Djasper=false,jasper"
PACKAGECONFIG[x11] = "-Dx11=true,-Dx11=false,virtual/libx11"
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] psplash: improve make-image-header.sh call
From: Stefan Agner
Simplify make-image-header.sh call and make sure it gets called in
the current working directory. Also check the return value of the
function call.
Signed-off-by: Stefan Agner
---
meta/recipes-core/psplash/psplash_git.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/psplash/psplash_git.bb
b/meta/recipes-core/psplash/psplash_git.bb
index 3ad1ef4815..3161a5e3f1 100644
--- a/meta/recipes-core/psplash/psplash_git.bb
+++ b/meta/recipes-core/psplash/psplash_git.bb
@@ -74,7 +74,6 @@ ALTERNATIVE_LINK_NAME[psplash] = "${bindir}/psplash"
python do_compile () {
import shutil
import subprocess
-import shlex
# Build a separate executable for each splash image
workdir = d.getVar('WORKDIR')
@@ -84,9 +83,10 @@ python do_compile () {
outputfiles = d.getVar('SPLASH_INSTALL').split()
for localfile, outputfile in zip(localfiles, outputfiles):
if localfile.endswith(".png"):
-subprocess.call(shlex.split('%s %s POKY' % (convertscript,
os.path.join(workdir, localfile
+if subprocess.call([ convertscript, os.path.join(workdir,
localfile), 'POKY' ], cwd=workdir):
+bb.fatal("Error calling convert script '%s'" % (convertscript))
fbase = os.path.splitext(localfile)[0]
-shutil.copyfile("%s-img.h" % fbase, destfile)
+shutil.copyfile(os.path.join(workdir, "%s-img.h" % fbase),
destfile)
else:
shutil.copyfile(os.path.join(workdir, localfile), destfile)
# For some reason just updating the header is not enough, we have to
touch the .c
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On 23.02.2019 13:29, Richard Purdie wrote: > On Wed, 2019-02-20 at 21:10 +0100, Alexander Kanavin wrote: >> Drop autotools-specific patches. >> >> Rework jku's thumbnailer patch into meson configuration. >> >> Signed-off-by: Alexander Kanavin > > We've seen it before but its happened again: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/326 > > I went into the failed build directory and ran "bitbake core-image-sato > -c testsdkext" and it succeeded so I'm not sure sure how we're going to > debug this one... I am not sure if it is related, but we see psplash failing with a custom png recently. failed to load ".../splashscreen-blue.png": Couldn’t recognize the image file format for file “.../splashscreen-blue.png” The psplash calls gdk-pixbuf-csource (through make-image-header.sh). We only saw it failing when building in a Ubuntu 18.04 container, but then reproducible. I also noticed this (probably unrelated) in do_configure log: DEBUG: Executing shell function do_configure gtkdocize: neither configure.ac nor configure.in exist NOTE: Executing meson -Denable_jpeg=true -Denable_jasper=false -Denable_png=true -Denable_tiff=false -Dx11=false -Dinstalled_tests=false... The Meson build system Version: 0.49.2 Source dir: /workdir/oe/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/gdk-pixbuf-2.38.0 Build dir: /workdir/oe/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/build Build type: native build WARNING: Unknown options: "enable_jasper, enable_jpeg, enable_png, enable_tiff ... -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] consolekit: enable polkit if polkit distro feature is set
From: Stefan Agner
Enable polkit depending on whether polkit distro feature is set.
Signed-off-by: Stefan Agner
---
meta/recipes-support/consolekit/consolekit_0.4.6.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/consolekit/consolekit_0.4.6.bb
b/meta/recipes-support/consolekit/consolekit_0.4.6.bb
index 15b39046e3..a17f739d4d 100644
--- a/meta/recipes-support/consolekit/consolekit_0.4.6.bb
+++ b/meta/recipes-support/consolekit/consolekit_0.4.6.bb
@@ -23,7 +23,7 @@ SRC_URI[sha256sum] =
"b41d17e06f80059589fbeefe96ad07bcc564c49e65516da1caf9751464
S = "${WORKDIR}/ConsoleKit-${PV}"
-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'pam systemd', d)}"
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'pam systemd polkit',
d)}"
PACKAGECONFIG[pam] = "--enable-pam-module
--with-pam-module-dir=${base_libdir}/security,--disable-pam-module,libpam"
PACKAGECONFIG[polkit] = "--with-polkit,--without-polkit,polkit"
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] gconf: rename policykit to polkit
From: Stefan Agner
PolicyKit has been renamed to Polkit since quite a while. Rename
the PACKAGECONFIG accordingly.
Signed-off-by: Stefan Agner
---
meta/recipes-gnome/gnome/gconf_3.2.6.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-gnome/gnome/gconf_3.2.6.bb
b/meta/recipes-gnome/gnome/gconf_3.2.6.bb
index 120ae3e021..1e8ca2e5d2 100644
--- a/meta/recipes-gnome/gnome/gconf_3.2.6.bb
+++ b/meta/recipes-gnome/gnome/gconf_3.2.6.bb
@@ -22,12 +22,12 @@ S = "${WORKDIR}/GConf-${PV}"
EXTRA_OECONF = "--enable-shared --disable-static \
--disable-orbit --with-openldap=no --disable-gtk"
-# Disable PolicyKit by default
+# Disable Polkit by default
PACKAGECONFIG ??= ""
-# We really don't want PolicyKit for native
+# We really don't want Polkit for native
PACKAGECONFIG_class-native = ""
-PACKAGECONFIG[policykit] =
"--enable-defaults-service,--disable-defaults-service,polkit"
+PACKAGECONFIG[polkit] =
"--enable-defaults-service,--disable-defaults-service,polkit"
PACKAGECONFIG[debug] = "--enable-debug=yes, --enable-debug=minimum"
do_install_append() {
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] gconf: enable polkit if polkit distro feature is set
From: Stefan Agner
Enable polkit depending on whether polkit distro feature is set.
Signed-off-by: Stefan Agner
---
meta/recipes-gnome/gnome/gconf_3.2.6.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/recipes-gnome/gnome/gconf_3.2.6.bb
b/meta/recipes-gnome/gnome/gconf_3.2.6.bb
index 1e8ca2e5d2..e6742f37d8 100644
--- a/meta/recipes-gnome/gnome/gconf_3.2.6.bb
+++ b/meta/recipes-gnome/gnome/gconf_3.2.6.bb
@@ -22,8 +22,7 @@ S = "${WORKDIR}/GConf-${PV}"
EXTRA_OECONF = "--enable-shared --disable-static \
--disable-orbit --with-openldap=no --disable-gtk"
-# Disable Polkit by default
-PACKAGECONFIG ??= ""
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'polkit', d)}"
# We really don't want Polkit for native
PACKAGECONFIG_class-native = ""
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] Add polkit distro feature
From: Stefan Agner This patchset adds Polkit (formerly known as PolicyKit) as a distro feature. Polkit is used to centrally manage system policies and allows non-privileged processes access privileged operations. Since various packages such as systemd, ConnMan or NetworkManager allow building with/without Polkit support it is sensible to have a global policy by using a distro feature to descide whether to use Polkit. Currently there is NetworkManager and xfce4 which enable polkit if systemd is enabled. Using Polkit as a distro feature allows to easily prevent any Polkit use while still using systemd. I plan to send another patch to wire this up in various packages in meta-openembedded as well as documentation update. -- Stefan Stefan Agner (5): systemd: only enable polkit if DISTRO_FEATURES asks for polkit gconf: rename policykit to polkit gconf: enable polkit if polkit distro feature is set consolekit: rename policykit to polkit consolekit: enable polkit if polkit distro feature is set meta/recipes-core/systemd/systemd_239.bb| 3 +-- meta/recipes-gnome/gnome/gconf_3.2.6.bb | 7 +++ meta/recipes-support/consolekit/consolekit_0.4.6.bb | 4 ++-- 3 files changed, 6 insertions(+), 8 deletions(-) -- 2.13.6 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] consolekit: rename policykit to polkit
From: Stefan Agner
PolicyKit has been renamed to Polkit since quite a while. Rename
the PACKAGECONFIG accordingly.
Signed-off-by: Stefan Agner
---
meta/recipes-support/consolekit/consolekit_0.4.6.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/consolekit/consolekit_0.4.6.bb
b/meta/recipes-support/consolekit/consolekit_0.4.6.bb
index 80d48bf84f..15b39046e3 100644
--- a/meta/recipes-support/consolekit/consolekit_0.4.6.bb
+++ b/meta/recipes-support/consolekit/consolekit_0.4.6.bb
@@ -26,7 +26,7 @@ S = "${WORKDIR}/ConsoleKit-${PV}"
PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'pam systemd', d)}"
PACKAGECONFIG[pam] = "--enable-pam-module
--with-pam-module-dir=${base_libdir}/security,--disable-pam-module,libpam"
-PACKAGECONFIG[policykit] = "--with-polkit,--without-polkit,polkit"
+PACKAGECONFIG[polkit] = "--with-polkit,--without-polkit,polkit"
PACKAGECONFIG[systemd] =
"--with-systemdsystemunitdir=${systemd_unitdir}/system/,--with-systemdsystemunitdir="
FILES_${PN} += "${exec_prefix}/lib/ConsoleKit \
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] systemd: only enable polkit if DISTRO_FEATURES asks for polkit
From: Stefan Agner
Only add polkit to PACKAGECONFIG if polkit is in DISTRO_FEATURES.
Signed-off-by: Stefan Agner
---
meta/recipes-core/systemd/systemd_239.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd_239.bb
b/meta/recipes-core/systemd/systemd_239.bb
index be836ffa42..586ef65299 100644
--- a/meta/recipes-core/systemd/systemd_239.bb
+++ b/meta/recipes-core/systemd/systemd_239.bb
@@ -76,7 +76,7 @@ PAM_PLUGINS = " \
"
PACKAGECONFIG ??= " \
-${@bb.utils.filter('DISTRO_FEATURES', 'efi ldconfig pam selinux usrmerge',
d)} \
+${@bb.utils.filter('DISTRO_FEATURES', 'efi ldconfig pam selinux usrmerge
polkit', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '', d)} \
acl \
@@ -94,7 +94,6 @@ PACKAGECONFIG ??= " \
myhostname \
networkd \
nss \
-polkit \
quotacheck \
randomseed \
resolved \
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Handle OFD lock flags
Linux 3.15 and newer introduced new open file description locks.
Currently pseudo prints a warning if fcntl is used with OFD locks:
unknown fcntl argument 37, assuming long argument.
However, calls to fcntl with a OFC lock set need a struct flock
pointer. Treat F_OFD_GETLK (and friends) like F_GETLK (and friends).
This issue has been observed with ostree. Comparing strace output
between two runs with/without this patch shows the same fcntl calls,
hence it seems not to matter in practice.
Signed-off-by: Stefan Agner
---
Hi,
I noticed this when using meta-updater which uses ostree to commit
the root file system. We observe this warnings on every build, but
the last error message only rather seldom:
...
unknown fcntl argument 37, assuming long argument.
unknown fcntl argument 37, assuming long argument.
unknown fcntl argument 37, assuming long argument.
error: Locking repo exclusive failed: Resource temporarily unavailable
Looking at a strace it seems that with pseudo in place the fcntl
seems to pass the argument properly nontheless:
fcntl(7, F_OFD_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0})
= 0
fcntl(7, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0})
= 0
So this effectively just gets rid of the warnings.
--
Stefan
ports/linux/guts/fcntl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ports/linux/guts/fcntl.c b/ports/linux/guts/fcntl.c
index 639fd24..3991e25 100644
--- a/ports/linux/guts/fcntl.c
+++ b/ports/linux/guts/fcntl.c
@@ -50,6 +50,9 @@
case F_GETLK:
case F_SETLK:
case F_SETLKW:
+ case F_OFD_GETLK:
+ case F_OFD_SETLK:
+ case F_OFD_SETLKW:
rc = real_fcntl(fd, cmd, lock);
break;
#if defined(F_GETLK64) && (F_GETLK64 != F_GETLK)
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [opkg-devel] [opkg-utils PATCH] opkg-make-index: use ctime instead of mtime
Hi Alejandro,
On 22.10.2018 16:45, Alejandro Del Castillo wrote:
> makes sense, sounds like this is going to fix a bunch of nasty
> intermittent failures, thanks!
>
> merged
Thanks for merging!
With the merge in opkg-utils this is not yet actively used in OE of
course. So my question: Is there a new release of opkg-utils planned
anytime soon? Or should that be added as a patch in the OE recipe for
now?
--
Stefan
>
> On 10/19/18 10:38 AM, Stefan Agner wrote:
>> From: Stefan Agner
>>
>> When using sstate, two parallel builds can produce two packages
>> with the same mtime but different checksums. When later one of
>> those two builds fetches the others ipk, the package index does
>> not get udpated properly (since mtime matches). This ends up with
>> messages such as:
>>Downloading file:/../tmp/work/../image/...ipk.
>>Removing corrupt package file
>> /../sysroot/../var/cache/opkg/volatile/...ipk
>>
>> However, in that case, ctime is different. Use ctime instead of
>> mtime to prevent failures like this.
>>
>> Suggested-by: Khem Raj
>> Signed-off-by: Stefan Agner
>> ---
>> This addresses the issue discussed here:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openembedded.org_pipermail_openembedded-2Dcore_2018-2DOctober_156348.html&d=DwIBaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ&m=Innit37H69hUyZPGuuhwO6R5CbUNNTfXQwxbqsEA2NE&s=oFvqASrFTgasDqZ901HeIBFSsf6Cn4FcBieOOBU4MdI&e=
>>
>> opkg-make-index | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/opkg-make-index b/opkg-make-index
>> index 3227fc0..db7bf64 100755
>> --- a/opkg-make-index
>> +++ b/opkg-make-index
>> @@ -115,12 +115,12 @@ for abspath in files:
>>pkg = None
>>fnameStat = os.stat(abspath)
>>if filename in old_pkg_hash:
>> - if filename in pkgsStamps and int(fnameStat.st_mtime) ==
>> pkgsStamps[filename]:
>> + if filename in pkgsStamps and int(fnameStat.st_ctime) ==
>> pkgsStamps[filename]:
>> if (verbose):
>> sys.stderr.write("Found %s in Packages\n" % (filename,))
>> pkg = old_pkg_hash[filename]
>> else:
>> - sys.stderr.write("Found %s in Packages, but mtime differs -
>> re-reading\n" % (filename,))
>> + sys.stderr.write("Found %s in Packages, but ctime differs -
>> re-reading\n" % (filename,))
>>
>>if not pkg:
>> if (verbose):
>> @@ -137,7 +137,7 @@ for abspath in files:
>>else:
>> old_filename = ""
>>s = packages.add_package(pkg, opt_a)
>> - pkgsStamps[filename] = fnameStat.st_mtime
>> + pkgsStamps[filename] = fnameStat.st_ctime
>>if s == 0:
>> if old_filename:
>> # old package was displaced by newer
>>
>
> --
> Cheers,
>
> Alejandro
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Lock external repository in custom FSTYPE
On 01.11.2018 23:27, Stefan Agner wrote:
> On 29.10.2018 14:01, Khem Raj wrote:
>> On Mon, Oct 29, 2018 at 5:31 AM Stefan Agner wrote:
>>>
>>> Hi,
>>>
>>> We use meta-updater, which has a custom FSTYPE to build a OSTree
>>> repository. We share that repository across multiple bitbake executions.
>>> The underlying OSTree tools lock the OSTree repository before trying to
>>> interact, and if it fails ("error: Locking repo exclusive failed:
>>> Resource temporarily unavailable") then the complete build fails (see
>>> also https://github.com/advancedtelematic/meta-updater/issues/412).
>>>
>>> Now I'd rather prefer that two bitbake tasks would serialize the access
>>> to the OSTree repository. Is there a mechanism in bitbake to lock (and
>>> wait) for the repository to be not in use?
>>>
>>> We tried using bb.utils.lockfile, but the task is written in shell. Also
>>> inline Python would not work since locking/unlocking need to be done
>>> within one Python script as far as I understand.
>>>
>>
>> perhaps you could use lockfiles something like
>>
>> do_foo[lockfiles] = ...
>
> Wasn't aware of the lockfiles varflag, also seems not to appear in any
> documentation. Reading lib/bb/build.py suggests that it really is
I take that back:
https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#variable-flags
--
Stefan
> locking the complete task, exactly what we need.
>
> Added the lockfiles varflag to the do_image_ostree task in
> image_types_ostree.bbclass:
> do_image_ostree[lockfiles] += "${OSTREE_REPO}/ostree.lock"
>
> And run two builds, the OSTree lock issues seem to be gone. Thanks Khem!
>
> --
> Stefan
>
>>
>>> --
>>> Stefan
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Lock external repository in custom FSTYPE
On 29.10.2018 14:01, Khem Raj wrote:
> On Mon, Oct 29, 2018 at 5:31 AM Stefan Agner wrote:
>>
>> Hi,
>>
>> We use meta-updater, which has a custom FSTYPE to build a OSTree
>> repository. We share that repository across multiple bitbake executions.
>> The underlying OSTree tools lock the OSTree repository before trying to
>> interact, and if it fails ("error: Locking repo exclusive failed:
>> Resource temporarily unavailable") then the complete build fails (see
>> also https://github.com/advancedtelematic/meta-updater/issues/412).
>>
>> Now I'd rather prefer that two bitbake tasks would serialize the access
>> to the OSTree repository. Is there a mechanism in bitbake to lock (and
>> wait) for the repository to be not in use?
>>
>> We tried using bb.utils.lockfile, but the task is written in shell. Also
>> inline Python would not work since locking/unlocking need to be done
>> within one Python script as far as I understand.
>>
>
> perhaps you could use lockfiles something like
>
> do_foo[lockfiles] = ...
Wasn't aware of the lockfiles varflag, also seems not to appear in any
documentation. Reading lib/bb/build.py suggests that it really is
locking the complete task, exactly what we need.
Added the lockfiles varflag to the do_image_ostree task in
image_types_ostree.bbclass:
do_image_ostree[lockfiles] += "${OSTREE_REPO}/ostree.lock"
And run two builds, the OSTree lock issues seem to be gone. Thanks Khem!
--
Stefan
>
>> --
>> Stefan
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Lock external repository in custom FSTYPE
Hi,
We use meta-updater, which has a custom FSTYPE to build a OSTree
repository. We share that repository across multiple bitbake executions.
The underlying OSTree tools lock the OSTree repository before trying to
interact, and if it fails ("error: Locking repo exclusive failed:
Resource temporarily unavailable") then the complete build fails (see
also https://github.com/advancedtelematic/meta-updater/issues/412).
Now I'd rather prefer that two bitbake tasks would serialize the access
to the OSTree repository. Is there a mechanism in bitbake to lock (and
wait) for the repository to be not in use?
We tried using bb.utils.lockfile, but the task is written in shell. Also
inline Python would not work since locking/unlocking need to be done
within one Python script as far as I understand.
--
Stefan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [opkg-utils PATCH] opkg-make-index: use ctime instead of mtime
From: Stefan Agner
When using sstate, two parallel builds can produce two packages
with the same mtime but different checksums. When later one of
those two builds fetches the others ipk, the package index does
not get udpated properly (since mtime matches). This ends up with
messages such as:
Downloading file:/../tmp/work/../image/...ipk.
Removing corrupt package file /../sysroot/../var/cache/opkg/volatile/...ipk
However, in that case, ctime is different. Use ctime instead of
mtime to prevent failures like this.
Suggested-by: Khem Raj
Signed-off-by: Stefan Agner
---
This addresses the issue discussed here:
http://lists.openembedded.org/pipermail/openembedded-core/2018-October/156348.html
opkg-make-index | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/opkg-make-index b/opkg-make-index
index 3227fc0..db7bf64 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -115,12 +115,12 @@ for abspath in files:
pkg = None
fnameStat = os.stat(abspath)
if filename in old_pkg_hash:
- if filename in pkgsStamps and int(fnameStat.st_mtime) ==
pkgsStamps[filename]:
+ if filename in pkgsStamps and int(fnameStat.st_ctime) ==
pkgsStamps[filename]:
if (verbose):
sys.stderr.write("Found %s in Packages\n" % (filename,))
pkg = old_pkg_hash[filename]
else:
- sys.stderr.write("Found %s in Packages, but mtime differs -
re-reading\n" % (filename,))
+ sys.stderr.write("Found %s in Packages, but ctime differs -
re-reading\n" % (filename,))
if not pkg:
if (verbose):
@@ -137,7 +137,7 @@ for abspath in files:
else:
old_filename = ""
s = packages.add_package(pkg, opt_a)
- pkgsStamps[filename] = fnameStat.st_mtime
+ pkgsStamps[filename] = fnameStat.st_ctime
if s == 0:
if old_filename:
# old package was displaced by newer
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Build failure with parallel build and opkg
On 02.10.2018 15:12, Stefan Agner wrote: > On 02.10.2018 10:46, Stefan Agner wrote: >> On 26.09.2018 11:34, Stefan Agner wrote: >>> Hi, >>> >>> On 12.09.2018 00:49, Stefan Agner wrote: >> >>> We discussed the issue at Linaro Connect a bit. >>> >>> To recap, we do build in two steps: >>> >>> 1. bitbake full-container-image >>> 2. bitbake -c populate_sdk full-container-image >>> >>> The issue always happens in the second step. >>> >>> We also see that in the second step, the do_package_write_ipk_setscene >>> task for every recipe is executed. >>> >>> The current assumption is >>> >>> I tried to reproduce by building a recipe using openembedded-core master >>> only in two build directories with shared sstate manually: >>> >>> 1. build1 $ bitbake eudev >>> 2. build2 $ bitbake -c cleansstate eudev >>> 3. build2 $ bitbake eudev >>> 4. build1 $ bitbake core-image-minimal >>> >>> This sequence seems not to have triggered a >>> do_package_write_ipk_setscene for eudev. >>> >>> I then tried >>> 5. build1 $ bitbake -c populate_sdk core-image-minimal >>> >>> Which did trigger a do_package_write_ipk_setscene. However, the issue >>> did not appear... >>> >>> I even tried to rebuild and replace the file manually, and run bitbake >>> -c populate_sdk -f core-image-minimal, but it just seems not to appear. >>> >>> Last time I have seen it was with oe-core >>> f6634581fa0a81c4d68dc9179a755ad7b9d99357, I will revert to this version >>> again to see whether that helps reproducing the issue. >> >> Using the older OE version did not make a difference. >> >> >> So Max and I discussed a bit further. We realized that when OE rebuilds, >> the opkg package index is refreshed for a package only if the mtime (in >> seconds) is different between the previous file and the file on disk >> currently (see opkg-make-index). Can it be that two simultaneously >> started builds create two ipk with same mtime? >> >> So I built two core-image-minimal builds (on the same machine) at the >> *very* same time. First try did not cause a collision, but already on >> the second try I managed to reproduce multiple collision. This output >> shows all the packages with the same unix mtime stamp according to the >> Packages.stamps file (generated by opkg-make-index): >> >> $ comm -1 -2 <(sort build1/tmp-glibc/deploy/ipk/i586/Packages.stamps) <(sort >> build2/tmp-glibc/deploy/ipk/i586/Packages.stamps) >> kages.stamps) >> 1538424250 glibc-binary-localedata-de-it_2.27-r0_i586.ipk >> 1538425082 libreadline-staticdev_7.0-r0_i586.ipk >> 1538425162 bash-bashbug_4.4.18-r0_i586.ipk >> 1538425162 bash-completion_2.8-r0_i586.ipk >> 1538425162 bash-completion-dbg_2.8-r0_i586.ipk >> 1538425162 bash-completion-dev_2.8-r0_i586.ipk >> 1538425162 bash-loadable_4.4.18-r0_i586.ipk >> 1538425163 bash_4.4.18-r0_i586.ipk >> 1538425163 bash-completion-extra_2.8-r0_i586.ipk >> 1538425164 bash-doc_4.4.18-r0_i586.ipk >> 1538425167 bash-dbg_4.4.18-r0_i586.ipk >> 1538425233 util-linux-locale-hr_2.32-r0_i586.ipk >> 1538425233 util-linux-locale-id_2.32-r0_i586.ipk >> 1538425233 util-linux-locale-it_2.32-r0_i586.ipk >> 1538425233 util-linux-locale-sl_2.32-r0_i586.ipk >> 1538425233 util-linux-locale-zh-tw_2.32-r0_i586.ipk >> 1538425234 util-linux-dev_2.32-r0_i586.ipk >> 1538425234 util-linux-findfs_2.32-r0_i586.ipk >> 1538425234 util-linux-ionice_2.32-r0_i586.ipk >> 1538425234 util-linux-locale-ca_2.32-r0_i586.ipk >> 1538425234 util-linux-locale-pl_2.32-r0_i586.ipk >> 1538425234 util-linux-locale-pt-br_2.32-r0_i586.ipk >> 1538425234 util-linux-locale-ru_2.32-r0_i586.ipk >> 1538425234 util-linux-locale-sv_2.32-r0_i586.ipk >> 1538425234 util-linux-locale-tr_2.32-r0_i586.ipk >> 1538425234 util-linux-locale-vi_2.32-r0_i586.ipk >> 1538425234 util-linux-locale-zh-cn_2.32-r0_i586.ipk >> 1538425234 util-linux-mountpoint_2.32-r0_i586.ipk >> 1538425235 util-linux-locale-fr_2.32-r0_i586.ipk >> 1538425236 util-linux-blkid_2.32-r0_i586.ipk >> 1538425236 util-linux-fsck_2.32-r0_i586.ipk >> 1538425236 util-linux-fsck.cramfs_2.32-r0_i586.ipk >> 1538425236 util-linux-fstrim_2.32-r0_i586.ipk >> 1538425236 util-linux-lscpu_2.32-r0_i586.ipk >> 1538425236 util-linux-mkfs_2.32-r0_i586.ipk >> 1538425236 util-linux-mount_2.32-r0_i586.ipk >> 1538425236 util-linux-partx_2.32-r0_i586.ipk >> 1538425236
[OE-core] [PATCH] linux-firmware: use ${nonarch_base_libdir} for all firmware
From: Stefan Agner
Replace the remaining hardcoded '/lib' in kernel firmware installation
path with ${nonarch_base_libdir}.
Signed-off-by: Stefan Agner
---
meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 7829c24579..2525545bdd 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -811,9 +811,9 @@ LICENSE_${PN}-ibt-misc= "Firmware-ibt_firmware"
FILES_${PN}-ibt-license =
"${nonarch_base_libdir}/firmware/LICENCE.ibt_firmware"
FILES_${PN}-ibt-hw-37-7 =
"${nonarch_base_libdir}/firmware/intel/ibt-hw-37.7*.bseq"
FILES_${PN}-ibt-hw-37-8 =
"${nonarch_base_libdir}/firmware/intel/ibt-hw-37.8*.bseq"
-FILES_${PN}-ibt-11-5= "${nonarch_base_libdir}/firmware/intel/ibt-11-5.sfi
/lib/firmware/intel/ibt-11-5.ddc"
-FILES_${PN}-ibt-12-16 = "${nonarch_base_libdir}/firmware/intel/ibt-12-16.sfi
/lib/firmware/intel/ibt-12-16.ddc"
-FILES_${PN}-ibt-17 = "${nonarch_base_libdir}/firmware/intel/ibt-17-*.sfi
/lib/firmware/intel/ibt-17-*.ddc"
+FILES_${PN}-ibt-11-5= "${nonarch_base_libdir}/firmware/intel/ibt-11-5.sfi
${nonarch_base_libdir}/firmware/intel/ibt-11-5.ddc"
+FILES_${PN}-ibt-12-16 = "${nonarch_base_libdir}/firmware/intel/ibt-12-16.sfi
${nonarch_base_libdir}/firmware/intel/ibt-12-16.ddc"
+FILES_${PN}-ibt-17 = "${nonarch_base_libdir}/firmware/intel/ibt-17-*.sfi
${nonarch_base_libdir}/firmware/intel/ibt-17-*.ddc"
FILES_${PN}-ibt-misc= "${nonarch_base_libdir}/firmware/ibt-*"
RDEPENDS_${PN}-ibt-hw-37-7 = "${PN}-ibt-license"
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Build failure with parallel build and opkg
On 02.10.2018 10:46, Stefan Agner wrote: > On 26.09.2018 11:34, Stefan Agner wrote: >> Hi, >> >> On 12.09.2018 00:49, Stefan Agner wrote: > >> We discussed the issue at Linaro Connect a bit. >> >> To recap, we do build in two steps: >> >> 1. bitbake full-container-image >> 2. bitbake -c populate_sdk full-container-image >> >> The issue always happens in the second step. >> >> We also see that in the second step, the do_package_write_ipk_setscene >> task for every recipe is executed. >> >> The current assumption is >> >> I tried to reproduce by building a recipe using openembedded-core master >> only in two build directories with shared sstate manually: >> >> 1. build1 $ bitbake eudev >> 2. build2 $ bitbake -c cleansstate eudev >> 3. build2 $ bitbake eudev >> 4. build1 $ bitbake core-image-minimal >> >> This sequence seems not to have triggered a >> do_package_write_ipk_setscene for eudev. >> >> I then tried >> 5. build1 $ bitbake -c populate_sdk core-image-minimal >> >> Which did trigger a do_package_write_ipk_setscene. However, the issue >> did not appear... >> >> I even tried to rebuild and replace the file manually, and run bitbake >> -c populate_sdk -f core-image-minimal, but it just seems not to appear. >> >> Last time I have seen it was with oe-core >> f6634581fa0a81c4d68dc9179a755ad7b9d99357, I will revert to this version >> again to see whether that helps reproducing the issue. > > Using the older OE version did not make a difference. > > > So Max and I discussed a bit further. We realized that when OE rebuilds, > the opkg package index is refreshed for a package only if the mtime (in > seconds) is different between the previous file and the file on disk > currently (see opkg-make-index). Can it be that two simultaneously > started builds create two ipk with same mtime? > > So I built two core-image-minimal builds (on the same machine) at the > *very* same time. First try did not cause a collision, but already on > the second try I managed to reproduce multiple collision. This output > shows all the packages with the same unix mtime stamp according to the > Packages.stamps file (generated by opkg-make-index): > > $ comm -1 -2 <(sort build1/tmp-glibc/deploy/ipk/i586/Packages.stamps) <(sort > build2/tmp-glibc/deploy/ipk/i586/Packages.stamps) > kages.stamps) > > 1538424250 glibc-binary-localedata-de-it_2.27-r0_i586.ipk > > 1538425082 libreadline-staticdev_7.0-r0_i586.ipk > > 1538425162 bash-bashbug_4.4.18-r0_i586.ipk > > 1538425162 bash-completion_2.8-r0_i586.ipk > > 1538425162 bash-completion-dbg_2.8-r0_i586.ipk > > 1538425162 bash-completion-dev_2.8-r0_i586.ipk > > 1538425162 bash-loadable_4.4.18-r0_i586.ipk > > 1538425163 bash_4.4.18-r0_i586.ipk > > 1538425163 bash-completion-extra_2.8-r0_i586.ipk > 1538425164 bash-doc_4.4.18-r0_i586.ipk > 1538425167 bash-dbg_4.4.18-r0_i586.ipk > 1538425233 util-linux-locale-hr_2.32-r0_i586.ipk > 1538425233 util-linux-locale-id_2.32-r0_i586.ipk > 1538425233 util-linux-locale-it_2.32-r0_i586.ipk > 1538425233 util-linux-locale-sl_2.32-r0_i586.ipk > 1538425233 util-linux-locale-zh-tw_2.32-r0_i586.ipk > 1538425234 util-linux-dev_2.32-r0_i586.ipk > 1538425234 util-linux-findfs_2.32-r0_i586.ipk > 1538425234 util-linux-ionice_2.32-r0_i586.ipk > 1538425234 util-linux-locale-ca_2.32-r0_i586.ipk > 1538425234 util-linux-locale-pl_2.32-r0_i586.ipk > 1538425234 util-linux-locale-pt-br_2.32-r0_i586.ipk > 1538425234 util-linux-locale-ru_2.32-r0_i586.ipk > 1538425234 util-linux-locale-sv_2.32-r0_i586.ipk > 1538425234 util-linux-locale-tr_2.32-r0_i586.ipk > 1538425234 util-linux-locale-vi_2.32-r0_i586.ipk > 1538425234 util-linux-locale-zh-cn_2.32-r0_i586.ipk > 1538425234 uti
Re: [OE-core] Build failure with parallel build and opkg
On 26.09.2018 11:34, Stefan Agner wrote: > Hi, > > On 12.09.2018 00:49, Stefan Agner wrote: > We discussed the issue at Linaro Connect a bit. > > To recap, we do build in two steps: > > 1. bitbake full-container-image > 2. bitbake -c populate_sdk full-container-image > > The issue always happens in the second step. > > We also see that in the second step, the do_package_write_ipk_setscene > task for every recipe is executed. > > The current assumption is > > I tried to reproduce by building a recipe using openembedded-core master > only in two build directories with shared sstate manually: > > 1. build1 $ bitbake eudev > 2. build2 $ bitbake -c cleansstate eudev > 3. build2 $ bitbake eudev > 4. build1 $ bitbake core-image-minimal > > This sequence seems not to have triggered a > do_package_write_ipk_setscene for eudev. > > I then tried > 5. build1 $ bitbake -c populate_sdk core-image-minimal > > Which did trigger a do_package_write_ipk_setscene. However, the issue > did not appear... > > I even tried to rebuild and replace the file manually, and run bitbake > -c populate_sdk -f core-image-minimal, but it just seems not to appear. > > Last time I have seen it was with oe-core > f6634581fa0a81c4d68dc9179a755ad7b9d99357, I will revert to this version > again to see whether that helps reproducing the issue. Using the older OE version did not make a difference. So Max and I discussed a bit further. We realized that when OE rebuilds, the opkg package index is refreshed for a package only if the mtime (in seconds) is different between the previous file and the file on disk currently (see opkg-make-index). Can it be that two simultaneously started builds create two ipk with same mtime? So I built two core-image-minimal builds (on the same machine) at the *very* same time. First try did not cause a collision, but already on the second try I managed to reproduce multiple collision. This output shows all the packages with the same unix mtime stamp according to the Packages.stamps file (generated by opkg-make-index): $ comm -1 -2 <(sort build1/tmp-glibc/deploy/ipk/i586/Packages.stamps) <(sort build2/tmp-glibc/deploy/ipk/i586/Packages.stamps) kages.stamps) 1538424250 glibc-binary-localedata-de-it_2.27-r0_i586.ipk 1538425082 libreadline-staticdev_7.0-r0_i586.ipk 1538425162 bash-bashbug_4.4.18-r0_i586.ipk 1538425162 bash-completion_2.8-r0_i586.ipk 1538425162 bash-completion-dbg_2.8-r0_i586.ipk 1538425162 bash-completion-dev_2.8-r0_i586.ipk 1538425162 bash-loadable_4.4.18-r0_i586.ipk 1538425163 bash_4.4.18-r0_i586.ipk 1538425163 bash-completion-extra_2.8-r0_i586.ipk 1538425164 bash-doc_4.4.18-r0_i586.ipk 1538425167 bash-dbg_4.4.18-r0_i586.ipk 1538425233 util-linux-locale-hr_2.32-r0_i586.ipk 1538425233 util-linux-locale-id_2.32-r0_i586.ipk 1538425233 util-linux-locale-it_2.32-r0_i586.ipk 1538425233 util-linux-locale-sl_2.32-r0_i586.ipk 1538425233 util-linux-locale-zh-tw_2.32-r0_i586.ipk 1538425234 util-linux-dev_2.32-r0_i586.ipk 1538425234 util-linux-findfs_2.32-r0_i586.ipk 1538425234 util-linux-ionice_2.32-r0_i586.ipk 1538425234 util-linux-locale-ca_2.32-r0_i586.ipk 1538425234 util-linux-locale-pl_2.32-r0_i586.ipk 1538425234 util-linux-locale-pt-br_2.32-r0_i586.ipk 1538425234 util-linux-locale-ru_2.32-r0_i586.ipk 1538425234 util-linux-locale-sv_2.32-r0_i586.ipk 1538425234 util-linux-locale-tr_2.32-r0_i586.ipk 1538425234 util-linux-locale-vi_2.32-r0_i586.ipk 1538425234 util-linux-locale-zh-cn_2.32-r0_i586.ipk 1538425234 util-linux-mountpoint_2.32-r0_i586.ipk 1538425235 util-linux-locale-fr_2.32-r0_i586.ipk 1538425236 util-linux-blkid_2.32-r0_i586.ipk 1538425236 util-linux-fsck_2.32-r0_i586.ipk 1538425236 util-linux-fsck.cramfs_2.32-r0_i586.ipk 1538425236 util-linux-fstrim_2.32-r0_i586.ipk 1538425236 util-linux-lscpu_2.32-r0_i586.ipk 1538425236 util-linux-mkfs_2.32-r0_i586.ipk 1538425236 util-linux-mount_2.32-r0_i586.ipk 1538425236 util-linux-partx_2.32-r0_i586.ipk 1538425236 util-linux-readprofile_
Re: [OE-core] Build failure with parallel build and opkg
Hi, On 12.09.2018 00:49, Stefan Agner wrote: > Hi, > > We experience build errors as follows every now and then: > > ... > ERROR: full-container-image-0.1-r0 do_populate_sdk: Unable to install > packages. Command > '/workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/recipe-sysroot-native/usr/bin/opkg > --volatile-cache -f > /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/opkg.conf > -t > /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/temp/ipktemp/ > -o > /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/sdk/image/usr/local/tordy-x86_64/sysroots/armv7at2hf-neon-lmp-linux-gnueabi > --force_postinstall --prefer-arch-to-version install 96boards-tools > aktualizr aktualizr-host-tools aktualizr-runtime-prov base-passwd > coreutils cpufrequtils docker gptfdisk haveged hostapd htop iptables > kernel-modules ldd less lmp-device-register networkmanager > networkmanager-nmtui openssh-sftp-server os-release ostree > packagegroup-base-extended packagegroup-core-boot > packagegroup-core-full-cmdline-extended > packagegroup-core-full-cmdline-multiuser > packagegroup-core-full-cmdline-utils packagegroup-core-ssh-openssh > packagegroup-core-standalone-sdk-target pciutils python3-compression > python3-distutils python3-docker python3-docker-compose python3-json > python3-netclient python3-pkgutil python3-shell python3-unixadmin rsync > run-postinsts shadow sshfs-fuse strace sudo target-sdk-provides-dummy > tcpdump vim-tiny' returned 255: > ... > Downloading > file:/workdir/oe/tmp/deploy/ipk/armv7at2hf-neon/nss_3.38-r0_armv7at2hf-neon.ipk. > Removing corrupt package file > /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/sdk/image/usr/local/tordy-x86_64/sysroots/armv7at2hf-neon-lmp-linux-gnueabi//var/cache/opkg/volatile/8e392ecd3611e24a6a49a8b22ad6e1ff_nss_3.38-r0_armv7at2hf-neon.ipk. > ... > Installing pam-plugin-faildelay (1.3.0) on root > Downloading > file:/workdir/oe/tmp/deploy/ipk/armv7at2hf-neon/pam-plugin-faildelay_1.3.0-r5_armv7at2hf-neon.ipk. > Removing corrupt package file > /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/sdk/image/usr/local/tordy-x86_64/sysroots/armv7at2hf-neon-lmp-linux-gnueabi//var/cache/opkg/volatile/0df6a8bc594a581f6ca3bcfa55e860e2_pam-plugin-faildelay_1.3.0-r5_armv7at2hf-neon.ipk. > ... > Collected errors: > * opkg_install_pkg: Failed to download nss. Perhaps you need to run > 'opkg update'? > * opkg_install_pkg: Failed to download pam-plugin-faildelay. Perhaps > you need to run 'opkg update'? > . > ... > > We build our own OpenEmbedded core based distribution currently based on > a recent master state. But we have seen this on and off back since > rocko. > > We build the image using Jenkins with multiple builders running in > parallel and sharing sstate. I think the fact that we run similar images > in parallel is the culprit: Looking closer at the failed build directory > reveals that the tmp-glibc/deploy/ipk/armv7at2hf-neon/Packages has a > different MD5Sum than the actual package. We start with two builders > simultaneously building an image, and it seems that they build the same > package around the same time. I assume that the two builders somehow > have a race between when the package get assembled and when the Package > index gets built... > > We start with a clean sstate, and this typically only happens for the > very first builds, when the sstate is cold. We discussed the issue at Linaro Connect a bit. To recap, we do build in two steps: 1. bitbake full-container-image 2. bitbake -c populate_sdk full-container-image The issue always happens in the second step. We also see that in the second step, the do_package_write_ipk_setscene task for every recipe is executed. The current assumption is I tried to reproduce by building a recipe using openembedded-core master only in two build directories with shared sstate manually: 1. build1 $ bitbake eudev 2. build2 $ bitbake -c cleansstate eudev 3. build2 $ bitbake eudev 4. build1 $ bitbake core-image-minimal This sequence seems not to have triggered a do_package_write_ipk_setscene for eudev. I then tried 5. build1 $ bitbake -c populate_sdk core-image-minimal Which did trigger a do_package_write_ipk_setscene. However, the issue did not appear... I even tried to rebuild and replace the file manually, and run bitbake -c populate_sdk -f core-image-minimal, but it just seems not to appear. Last time I have seen it was with oe-core f6634581fa0a81c4d68dc9179a755ad7b9d99357, I will revert to this version again to see whether that helps reproducing the issue. -- Stefan > > I guess there is some race/asynchronous
Re: [OE-core] [oe] Fwd: [openembedded][wayland][weston]: How to configure screen resolution
I think weston is using KMS connector names.
Try HDMI-A-1.
Otherwise, running weston with --log=weston.log will produce a helpful
logfile.
--
Stefan
On 11.09.2018 02:02, Mohamed Dawod wrote:
> -- Forwarded message -
> From: Mohamed Dawod
> Date: Mon, Sep 10, 2018 at 1:15 PM
> Subject: Re: [oe] [openembedded][wayland][weston]: How to configure screen
> resolution
> To:
>
>
>
> I typed the following weston.ini and weston-init.bbappend file but no thing
> change
>
>
> This is my weston.ini file :
> ===
> [core]
> idle-time=0
>
> [shell]
> locking=false
>
> [screensaver]
> path=""
>
> [output]
> name=HDMI1
> transform=0
> mode=1920x1080
>
> and this is my weston-init.bbappend file :
> ===
> DESCRIPTION = "Installation of weston.ini config file"
> LICENSE = "CLOSED"
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI_append = " file://weston.ini"
>
> do_install_append() {
> WESTON_INI_CONFIG=${sysconfdir}/xdg/weston
> #WESTON_INI_CONFIG=/root/.conf
> #WESTON_INI_CONFIG=/.config
> #WESTON_INI_CONFIG=/run/user/root/weston
> install -d ${D}${WESTON_INI_CONFIG}
> install -m 0644 ${WORKDIR}/weston.ini ${D}${WESTON_INI_CONFIG}
> }
>
> PACKAGES += "${PN}-ini"
> FILES_${PN}-ini = "${sysconfdir}/xdg"
> ---
>
> Thank you for your help,
>
>
>
>
>
>
>
>
> On Mon, Sep 10, 2018 at 10:30 AM Leon Anavi wrote:
>
>> Hi Mohamed,
>>
>>
>> On 9.09.2018 14:10, Mohamed Dawod wrote:
>> > Hello,
>> >
>> > I want to know how to change the screen resolution using weston.ini file
>> ?
>>
>> You can set the resolution size width and height in pixels with property
>> mode in the output section of weston.ini. For example:
>>
>> [output]
>> mode=1680x1050
>>
>> Please have a look at weston documentation for details.
>>
>>
>> > How to generate this file and use it for my image?
>>
>> You can update or provide your version of weston.ini through a bbappend
>> file.
>>
>> Best regards,
>> Leon
>>
>> >
>> > Thanks,
>> >
>>
>> --
>> Leon Anavi
>> Software Engineer
>> konsulko.com
>>
>>
>>
>
> --
>
> Mohamed Dawod
> Computer Engineering Department
> Faculty of Engineering
> Cairo University
>
>
> --
>
> Mohamed Dawod
> Computer Engineering Department
> Faculty of Engineering
> Cairo University
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Build failure with parallel build and opkg
Hi, We experience build errors as follows every now and then: ... ERROR: full-container-image-0.1-r0 do_populate_sdk: Unable to install packages. Command '/workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/opkg.conf -t /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/temp/ipktemp/ -o /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/sdk/image/usr/local/tordy-x86_64/sysroots/armv7at2hf-neon-lmp-linux-gnueabi --force_postinstall --prefer-arch-to-version install 96boards-tools aktualizr aktualizr-host-tools aktualizr-runtime-prov base-passwd coreutils cpufrequtils docker gptfdisk haveged hostapd htop iptables kernel-modules ldd less lmp-device-register networkmanager networkmanager-nmtui openssh-sftp-server os-release ostree packagegroup-base-extended packagegroup-core-boot packagegroup-core-full-cmdline-extended packagegroup-core-full-cmdline-multiuser packagegroup-core-full-cmdline-utils packagegroup-core-ssh-openssh packagegroup-core-standalone-sdk-target pciutils python3-compression python3-distutils python3-docker python3-docker-compose python3-json python3-netclient python3-pkgutil python3-shell python3-unixadmin rsync run-postinsts shadow sshfs-fuse strace sudo target-sdk-provides-dummy tcpdump vim-tiny' returned 255: ... Downloading file:/workdir/oe/tmp/deploy/ipk/armv7at2hf-neon/nss_3.38-r0_armv7at2hf-neon.ipk. Removing corrupt package file /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/sdk/image/usr/local/tordy-x86_64/sysroots/armv7at2hf-neon-lmp-linux-gnueabi//var/cache/opkg/volatile/8e392ecd3611e24a6a49a8b22ad6e1ff_nss_3.38-r0_armv7at2hf-neon.ipk. ... Installing pam-plugin-faildelay (1.3.0) on root Downloading file:/workdir/oe/tmp/deploy/ipk/armv7at2hf-neon/pam-plugin-faildelay_1.3.0-r5_armv7at2hf-neon.ipk. Removing corrupt package file /workdir/oe/tmp/work/colibri_imx7-lmp-linux-gnueabi/full-container-image/0.1-r0/sdk/image/usr/local/tordy-x86_64/sysroots/armv7at2hf-neon-lmp-linux-gnueabi//var/cache/opkg/volatile/0df6a8bc594a581f6ca3bcfa55e860e2_pam-plugin-faildelay_1.3.0-r5_armv7at2hf-neon.ipk. ... Collected errors: * opkg_install_pkg: Failed to download nss. Perhaps you need to run 'opkg update'? * opkg_install_pkg: Failed to download pam-plugin-faildelay. Perhaps you need to run 'opkg update'? . ... We build our own OpenEmbedded core based distribution currently based on a recent master state. But we have seen this on and off back since rocko. We build the image using Jenkins with multiple builders running in parallel and sharing sstate. I think the fact that we run similar images in parallel is the culprit: Looking closer at the failed build directory reveals that the tmp-glibc/deploy/ipk/armv7at2hf-neon/Packages has a different MD5Sum than the actual package. We start with two builders simultaneously building an image, and it seems that they build the same package around the same time. I assume that the two builders somehow have a race between when the package get assembled and when the Package index gets built... We start with a clean sstate, and this typically only happens for the very first builds, when the sstate is cold. I guess there is some race/asynchronous operation going on around building index/getting package from sstate/pushing package to sstate. It seems an issue others have seen in the past too: https://www.yoctoproject.org/irc/%23yocto.2018-07-05.log.html#t2018-07-05T10:07:25 Any idea? -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/3] postinst fixes for opgk/dpkg
On 04.06.2018 18:18, Alexander Kanavin wrote: > On 06/04/2018 07:06 PM, Stefan Agner wrote: > >> Anything holding us back merging this changes? > > Please read the Yocto project status mail: > > " · Patch review/merging was slow over the past week due to > Ross being on vacation and changes in Richard’s employment/hardware > situation but at least some of the backlog was resolved over the > weekend and the hardware issues should be worked around now." > Gentle ping on that again. This week it read: "Due to the milestone, patch merging is slowing to stabilize." Also, there have been patches merged which were posted after this patchset... It is really rather important for us since it is hard to fix in lower layers... So I am getting nervous whether it still makes it? -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/3] postinst fixes for opgk/dpkg
On 16.05.2018 11:13, Stefan Agner wrote: > From: Stefan Agner > > Hi, > > This follows up on the discussion a while ago: > https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg104996.html > > Patch 1 is rather simple and really fixes the main issue. The patch > by itself has been tested with the relevant self test and passes. > > Patch 2/3 get rid of /etc/*-postinsts script in cases where the package > management is present. This avoids a bunch of unnecessary scripts to be > present on the rootfs. It also avoids the systemd service to be present > forever with in case no postinst scripts have been deployed: > Condition: start condition failed at Tue 2018-05-15 10:57:43 UTC; 42s ago >└─ ConditionPathExistsGlob=/etc/*-postinsts was not met > > Self test executed using: > $ oe-selftest --run-tests runtime_test.Postinst.test_postinst_rootfs_and_boot Anything holding us back merging this changes? -- Stefan > > Changes since v1: > - Note that patches are specific for opkg/dpkg > > Stefan Agner (3): > opkg: avoid running postinst scripts twice when using systemd > run-postinsts: for dpkg/opkg, do not rely on /etc/*-postinsts > rootfs.py: for dpkg/opkg, don't install postinsts if package > management is present > > meta/lib/oe/rootfs.py | 3 +++ > .../opkg/opkg/opkg-configure.service| 17 - > meta/recipes-devtools/opkg/opkg_0.3.6.bb| 14 -- > .../run-postinsts/run-postinsts/run-postinsts | 21 > - > .../run-postinsts/run-postinsts.service | 1 - > 5 files changed, 15 insertions(+), 41 deletions(-) > delete mode 100644 meta/recipes-devtools/opkg/opkg/opkg-configure.service -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/3] opkg: avoid running postinst scripts twice when using systemd
From: Stefan Agner
OpenEmbedded has a built-in mechanism to run postinst scripts offline
at build time or, if necessary, on first boot (delayed execution). If
the latter is the case and systemd is in use, two services end up
doing the same thing:
- opkg-configure.service starts "opkg configure" directly.
- run-postinsts.service starts "/usr/sbin/run-postinsts" which runs
postinst scripts stored in /etc/ipk-postinsts/ or "opkg configure"
if package management is installed.
Since the run-postinsts.service is also used in cases where no
package management is in use, it is the primary means of handling
postinsts.
Get rid of the opkg-configure.service to avoid duplicate opkg
configure execution.
Signed-off-by: Stefan Agner
---
meta/recipes-devtools/opkg/opkg/opkg-configure.service | 17 -
meta/recipes-devtools/opkg/opkg_0.3.6.bb | 14 --
2 files changed, 31 deletions(-)
delete mode 100644 meta/recipes-devtools/opkg/opkg/opkg-configure.service
diff --git a/meta/recipes-devtools/opkg/opkg/opkg-configure.service
b/meta/recipes-devtools/opkg/opkg/opkg-configure.service
deleted file mode 100644
index 432c3ddc28..00
--- a/meta/recipes-devtools/opkg/opkg/opkg-configure.service
+++ /dev/null
@@ -1,17 +0,0 @@
-[Unit]
-Description=Opkg first boot configure
-DefaultDependencies=no
-After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount
-Before=sysinit.target
-
-[Service]
-Type=oneshot
-EnvironmentFile=-@SYSCONFDIR@/default/postinst
-ExecStart=-@BASE_BINDIR@/sh -c " if [ $POSTINST_LOGGING = '1' ]; then
@BINDIR@/opkg configure > $LOGFILE 2>&1; else @BINDIR@/opkg configure; fi"
-ExecStartPost=@BASE_BINDIR@/systemctl --no-reload disable
opkg-configure.service
-StandardOutput=syslog
-RemainAfterExit=No
-
-[Install]
-WantedBy=basic.target
-WantedBy=sysinit.target
diff --git a/meta/recipes-devtools/opkg/opkg_0.3.6.bb
b/meta/recipes-devtools/opkg/opkg_0.3.6.bb
index 70f20af739..579b51166c 100644
--- a/meta/recipes-devtools/opkg/opkg_0.3.6.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.3.6.bb
@@ -12,7 +12,6 @@ DEPENDS = "libarchive"
PE = "1"
SRC_URI =
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz \
- file://opkg-configure.service \
file://opkg.conf \
file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
"
@@ -22,8 +21,6 @@ SRC_URI[sha256sum] =
"f607f0e61be8cf8a3bbd0d2dccd9ec9e9b6c21dd4307b671c600d6eeaf
inherit autotools pkgconfig systemd
-SYSTEMD_SERVICE_${PN} = "opkg-configure.service"
-
target_localstatedir := "${localstatedir}"
OPKGLIBDIR = "${target_localstatedir}/lib"
@@ -46,16 +43,6 @@ do_install_append () {
# We need to create the lock directory
install -d ${D}${OPKGLIBDIR}/opkg
-
- if
${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};then
- install -d ${D}${systemd_unitdir}/system
- install -m 0644 ${WORKDIR}/opkg-configure.service
${D}${systemd_unitdir}/system/
- sed -i -e 's,@BASE_BINDIR@,${base_bindir},g' \
- -e 's,@SYSCONFDIR@,${sysconfdir},g' \
- -e 's,@BINDIR@,${bindir},g' \
- -e 's,@SYSTEMD_UNITDIR@,${systemd_unitdir},g' \
- ${D}${systemd_unitdir}/system/opkg-configure.service
- fi
}
RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} opkg-arch-config
libarchive"
@@ -68,7 +55,6 @@ RPROVIDES_${PN} = "opkg-collateral"
PACKAGES =+ "libopkg"
FILES_libopkg = "${libdir}/*.so.* ${OPKGLIBDIR}/opkg/"
-FILES_${PN} += "${systemd_unitdir}/system/"
BBCLASSEXTEND = "native nativesdk"
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/3] run-postinsts: for dpkg/opkg, do not rely on /etc/*-postinsts
From: Stefan Agner
Start opkg/dpkg as soon as the respective package managers status
file is present, no matter whether /etc/$pm-postinsts exists. This
decouples the implicit link between postinsts scripts in /etc and
the package manager: Currently the package manager is only started
if those scripts are present, although the package manager does not
use those scripts at all! Package managers install their own set of
postinst scripts.
The behavior when using rpm packages stays the same.
Note that using the package managers capability to execute postinst
scripts is preferred for good reasons: It makes sure that the
package managers database reflects that the packages have been
completely installed and configured.
This change allows to drop installation of the postinsts scripts
when package management is present. This will be done in a separate
change.
Note: Before commit 5aae19959a44 ("rootfs.py: Change logic to
unistall packages") rootfs.py did not install /etc/$pm-postinsts
when package management is installed! The change caused YOCTO #8235
which lead to the behavior change of run-postinsts in first place.
Signed-off-by: Stefan Agner
---
.../run-postinsts/run-postinsts/run-postinsts | 21 -
.../run-postinsts/run-postinsts.service | 1 -
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
index 307feb7187..95eff04e17 100755
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
@@ -6,7 +6,8 @@
#
# The following script will run all the scriptlets found in
#SYSCONFDIR#/deb-postinsts,
-# #SYSCONFDIR#/ipk-postinsts or #SYSCONFDIR#/rpm-postinsts.
+# #SYSCONFDIR#/ipk-postinsts or #SYSCONFDIR#/rpm-postinsts or the package
manager in
+# case available.
# the order of this list is important, do not change!
backend_list="rpm deb ipk"
@@ -14,27 +15,29 @@ backend_list="rpm deb ipk"
pm_installed=false
for pm in $backend_list; do
- pi_dir="#SYSCONFDIR#/$pm-postinsts"
-
- if [ ! -d $pi_dir ]; then
- continue
- fi
-
# found the package manager, it has postinsts
case $pm in
"deb")
if [ -s "#LOCALSTATEDIR#/lib/dpkg/status" ]; then
pm_installed=true
+ break
fi
;;
"ipk")
if [ -s "#LOCALSTATEDIR#/lib/opkg/status" ]; then
pm_installed=true
+ break
fi
;;
esac
- break
+
+ pi_dir="#SYSCONFDIR#/$pm-postinsts"
+
+ # found postinsts directory
+ if [ -d $pi_dir ]; then
+ break
+ fi
done
remove_rcsd_link () {
@@ -43,7 +46,7 @@ remove_rcsd_link () {
fi
}
-if ! [ -d $pi_dir ]; then
+if ! [ -d $pi_dir ] && ! $pm_installed; then
remove_rcsd_link
exit 0
fi
diff --git
a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
index 1b71a1f8be..d42addf510 100644
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
@@ -3,7 +3,6 @@ Description=Run pending postinsts
DefaultDependencies=no
After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount
Before=sysinit.target
-ConditionPathExistsGlob=#SYSCONFDIR#/*-postinsts
[Service]
Type=oneshot
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 3/3] rootfs.py: for dpkg/opkg, don't install postinsts if package management is present
From: Stefan Agner
If package management is present opkg/dpkg will bring the original
copy of the postinsts scripts with the metadata and will be able to
handle postinsts just fine. In fact, it is preferred to let package
management handle the postinsts scripts in this case since it will
keep the package managers database up-to-date too. The run-postinsts
scripts will make sure the package manager gets invoked instead of
the scripts directly.
Note: Before commit 5aae19959a44 ("rootfs.py: Change logic to
unistall packages") rootfs.py did not install /etc/$pm-postinsts
too. It is not clear whether that change was intentionally or just
a bug. This commit fixes/reverts that aspect of the commit.
Signed-off-by: Stefan Agner
---
meta/lib/oe/rootfs.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index f8f717c050..0a57d87f71 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -560,6 +560,9 @@ class DpkgOpkgRootfs(Rootfs):
return pkg_list
def _save_postinsts_common(self, dst_postinst_dir, src_postinst_dir):
+if bb.utils.contains("IMAGE_FEATURES", "package-management",
+ True, False, self.d):
+return
num = 0
for p in self._get_delayed_postinsts():
bb.utils.mkdirhier(dst_postinst_dir)
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 0/3] postinst fixes for opgk/dpkg
From: Stefan Agner Hi, This follows up on the discussion a while ago: https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg104996.html Patch 1 is rather simple and really fixes the main issue. The patch by itself has been tested with the relevant self test and passes. Patch 2/3 get rid of /etc/*-postinsts script in cases where the package management is present. This avoids a bunch of unnecessary scripts to be present on the rootfs. It also avoids the systemd service to be present forever with in case no postinst scripts have been deployed: Condition: start condition failed at Tue 2018-05-15 10:57:43 UTC; 42s ago └─ ConditionPathExistsGlob=/etc/*-postinsts was not met Self test executed using: $ oe-selftest --run-tests runtime_test.Postinst.test_postinst_rootfs_and_boot Changes since v1: - Note that patches are specific for opkg/dpkg Stefan Agner (3): opkg: avoid running postinst scripts twice when using systemd run-postinsts: for dpkg/opkg, do not rely on /etc/*-postinsts rootfs.py: for dpkg/opkg, don't install postinsts if package management is present meta/lib/oe/rootfs.py | 3 +++ .../opkg/opkg/opkg-configure.service| 17 - meta/recipes-devtools/opkg/opkg_0.3.6.bb| 14 -- .../run-postinsts/run-postinsts/run-postinsts | 21 - .../run-postinsts/run-postinsts.service | 1 - 5 files changed, 15 insertions(+), 41 deletions(-) delete mode 100644 meta/recipes-devtools/opkg/opkg/opkg-configure.service -- 2.13.6 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] postinsts fixes
On 15.05.2018 17:03, Alexander Kanavin wrote: > On 05/15/2018 05:04 PM, Stefan Agner wrote: >> This follows up on the discussion a while ago: >> https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg104996.html > > Took me a moment to realize all three patches are specific to > opkg/dpkg and do not change how rpm (or general 'postinst handling') > works. Perhaps you could amend the commit messages to emphasize that? Patch 1 has opkg in the subject. Patch 2/3 mention opkg/dpkg in the commit log. Patch 3 also really edits the DpkgOpkgRootfs class, which should make it rather obvious. But I agree for patch 2 it would be good to emphasize it. How about adding this after the first paragraph: The behavior for rpm stays the same. -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] opkg: avoid running postinst scripts twice when using systemd
From: Stefan Agner
OpenEmbedded has a built-in mechanism to run postinst scripts offline
at build time or, if necessary, on first boot (delayed execution). If
the latter is the case and systemd is in use, two services end up
doing the same thing:
- opkg-configure.service starts "opkg configure" directly.
- run-postinsts.service starts "/usr/sbin/run-postinsts" which runs
postinst scripts stored in /etc/ipk-postinsts/ or "opkg configure"
if package management is installed.
Since the run-postinsts.service is also used in cases where no
package management is in use, it is the primary means of handling
postinsts.
Get rid of the opkg-configure.service to avoid duplicate opkg
configure execution.
Signed-off-by: Stefan Agner
---
meta/recipes-devtools/opkg/opkg/opkg-configure.service | 17 -
meta/recipes-devtools/opkg/opkg_0.3.6.bb | 14 --
2 files changed, 31 deletions(-)
delete mode 100644 meta/recipes-devtools/opkg/opkg/opkg-configure.service
diff --git a/meta/recipes-devtools/opkg/opkg/opkg-configure.service
b/meta/recipes-devtools/opkg/opkg/opkg-configure.service
deleted file mode 100644
index 432c3ddc28..00
--- a/meta/recipes-devtools/opkg/opkg/opkg-configure.service
+++ /dev/null
@@ -1,17 +0,0 @@
-[Unit]
-Description=Opkg first boot configure
-DefaultDependencies=no
-After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount
-Before=sysinit.target
-
-[Service]
-Type=oneshot
-EnvironmentFile=-@SYSCONFDIR@/default/postinst
-ExecStart=-@BASE_BINDIR@/sh -c " if [ $POSTINST_LOGGING = '1' ]; then
@BINDIR@/opkg configure > $LOGFILE 2>&1; else @BINDIR@/opkg configure; fi"
-ExecStartPost=@BASE_BINDIR@/systemctl --no-reload disable
opkg-configure.service
-StandardOutput=syslog
-RemainAfterExit=No
-
-[Install]
-WantedBy=basic.target
-WantedBy=sysinit.target
diff --git a/meta/recipes-devtools/opkg/opkg_0.3.6.bb
b/meta/recipes-devtools/opkg/opkg_0.3.6.bb
index 70f20af739..579b51166c 100644
--- a/meta/recipes-devtools/opkg/opkg_0.3.6.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.3.6.bb
@@ -12,7 +12,6 @@ DEPENDS = "libarchive"
PE = "1"
SRC_URI =
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz \
- file://opkg-configure.service \
file://opkg.conf \
file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
"
@@ -22,8 +21,6 @@ SRC_URI[sha256sum] =
"f607f0e61be8cf8a3bbd0d2dccd9ec9e9b6c21dd4307b671c600d6eeaf
inherit autotools pkgconfig systemd
-SYSTEMD_SERVICE_${PN} = "opkg-configure.service"
-
target_localstatedir := "${localstatedir}"
OPKGLIBDIR = "${target_localstatedir}/lib"
@@ -46,16 +43,6 @@ do_install_append () {
# We need to create the lock directory
install -d ${D}${OPKGLIBDIR}/opkg
-
- if
${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};then
- install -d ${D}${systemd_unitdir}/system
- install -m 0644 ${WORKDIR}/opkg-configure.service
${D}${systemd_unitdir}/system/
- sed -i -e 's,@BASE_BINDIR@,${base_bindir},g' \
- -e 's,@SYSCONFDIR@,${sysconfdir},g' \
- -e 's,@BINDIR@,${bindir},g' \
- -e 's,@SYSTEMD_UNITDIR@,${systemd_unitdir},g' \
- ${D}${systemd_unitdir}/system/opkg-configure.service
- fi
}
RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} opkg-arch-config
libarchive"
@@ -68,7 +55,6 @@ RPROVIDES_${PN} = "opkg-collateral"
PACKAGES =+ "libopkg"
FILES_libopkg = "${libdir}/*.so.* ${OPKGLIBDIR}/opkg/"
-FILES_${PN} += "${systemd_unitdir}/system/"
BBCLASSEXTEND = "native nativesdk"
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] rootfs.py: Don't install postinsts if package management is present
From: Stefan Agner
If package management is present opkg/dpkg will bring the original
copy of the postinsts scripts with the metadata and will be able to
handle postinsts just fine. In fact, it is preferred to let package
management handle the postinsts scripts in this case since it will
keep the package managers database up-to-date too. The run-postinsts
scripts will make sure the package manager gets invoked instead of
the scripts directly.
Note: Before commit 5aae19959a44 ("rootfs.py: Change logic to
unistall packages") rootfs.py did not install /etc/$pm-postinsts
too. It is not clear whether that change was intentionally or just
a bug. This commit fixes/reverts that aspect of the commit.
Signed-off-by: Stefan Agner
---
meta/lib/oe/rootfs.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index f8f717c050..0a57d87f71 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -560,6 +560,9 @@ class DpkgOpkgRootfs(Rootfs):
return pkg_list
def _save_postinsts_common(self, dst_postinst_dir, src_postinst_dir):
+if bb.utils.contains("IMAGE_FEATURES", "package-management",
+ True, False, self.d):
+return
num = 0
for p in self._get_delayed_postinsts():
bb.utils.mkdirhier(dst_postinst_dir)
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] run-postinsts: Do not rely on /etc/*-postinsts
From: Stefan Agner
Start opkg/dpkg as soon as the respective package managers status
file is present, no matter whether /etc/$pm-postinsts exists. This
decouples the implicit link between postinsts scripts in /etc and
the package manager: Currently the package manager is only started
if those scripts are present, although the package manager does not
use those scripts at all! Package managers install their own set of
postinst scripts.
Note that using the package managers capability to execute postinst
scripts is preferred for good reasons: It makes sure that the
package managers database reflects that the packages have been
completely installed and configured.
This change allows to drop installation of the postinsts scripts
when package management is present. This will be done in a separate
change.
Note: Before commit 5aae19959a44 ("rootfs.py: Change logic to
unistall packages") rootfs.py did not install /etc/$pm-postinsts
when package management is installed! The change caused YOCTO #8235
which lead to the behavior change of run-postinsts in first place.
Signed-off-by: Stefan Agner
---
.../run-postinsts/run-postinsts/run-postinsts | 21 -
.../run-postinsts/run-postinsts.service | 1 -
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
index 307feb7187..95eff04e17 100755
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
@@ -6,7 +6,8 @@
#
# The following script will run all the scriptlets found in
#SYSCONFDIR#/deb-postinsts,
-# #SYSCONFDIR#/ipk-postinsts or #SYSCONFDIR#/rpm-postinsts.
+# #SYSCONFDIR#/ipk-postinsts or #SYSCONFDIR#/rpm-postinsts or the package
manager in
+# case available.
# the order of this list is important, do not change!
backend_list="rpm deb ipk"
@@ -14,27 +15,29 @@ backend_list="rpm deb ipk"
pm_installed=false
for pm in $backend_list; do
- pi_dir="#SYSCONFDIR#/$pm-postinsts"
-
- if [ ! -d $pi_dir ]; then
- continue
- fi
-
# found the package manager, it has postinsts
case $pm in
"deb")
if [ -s "#LOCALSTATEDIR#/lib/dpkg/status" ]; then
pm_installed=true
+ break
fi
;;
"ipk")
if [ -s "#LOCALSTATEDIR#/lib/opkg/status" ]; then
pm_installed=true
+ break
fi
;;
esac
- break
+
+ pi_dir="#SYSCONFDIR#/$pm-postinsts"
+
+ # found postinsts directory
+ if [ -d $pi_dir ]; then
+ break
+ fi
done
remove_rcsd_link () {
@@ -43,7 +46,7 @@ remove_rcsd_link () {
fi
}
-if ! [ -d $pi_dir ]; then
+if ! [ -d $pi_dir ] && ! $pm_installed; then
remove_rcsd_link
exit 0
fi
diff --git
a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
index 1b71a1f8be..d42addf510 100644
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
@@ -3,7 +3,6 @@ Description=Run pending postinsts
DefaultDependencies=no
After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount
Before=sysinit.target
-ConditionPathExistsGlob=#SYSCONFDIR#/*-postinsts
[Service]
Type=oneshot
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] postinsts fixes
From: Stefan Agner Hi, This follows up on the discussion a while ago: https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg104996.html Patch 1 is rather simple and really fixes the main issue. The patch by itself has been tested with the relevant self test and passes. Patch 2/3 get rid of /etc/*-postinsts script in cases where the package management is present. This avoids a bunch of unnecessary scripts to be present on the rootfs. It also avoids the systemd service to be present forever with in case no postinst scripts have been deployed: Condition: start condition failed at Tue 2018-05-15 10:57:43 UTC; 42s ago └─ ConditionPathExistsGlob=/etc/*-postinsts was not met Self test executed using: $ oe-selftest --run-tests runtime_test.Postinst.test_postinst_rootfs_and_boot Stefan Agner (3): opkg: avoid running postinst scripts twice when using systemd run-postinsts: Do not rely on /etc/*-postinsts rootfs.py: Don't install postinsts if package management is present meta/lib/oe/rootfs.py | 3 +++ .../opkg/opkg/opkg-configure.service| 17 - meta/recipes-devtools/opkg/opkg_0.3.6.bb| 14 -- .../run-postinsts/run-postinsts/run-postinsts | 21 - .../run-postinsts/run-postinsts.service | 1 - 5 files changed, 15 insertions(+), 41 deletions(-) delete mode 100644 meta/recipes-devtools/opkg/opkg/opkg-configure.service -- 2.13.6 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] busybox: udhcpc: fix IPv6 support when using udhcpc
From: Stefan Agner The udhcpc script calls ip addr flush .. which flushes addresses of any address family, including IPv6. However, busybox udhcpc is IPv4 only and should not influence IPv6 addressing. Hence use ip addr flush with family constrait. The script particularly broke IPv6 SLAAC: Typically when udhcpc calls the script the kernel already assigned the IPv6 link-local address. The flush removes the link-local IPv6 address again and prohibits proper IPv6 operation such as SLAAC since neighbor discovery protocol relies on IPv6 link-local addressing. Signed-off-by: Stefan Agner --- meta/recipes-core/busybox/files/simple.script | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/busybox/files/simple.script b/meta/recipes-core/busybox/files/simple.script index 6ed0293525..8b5eb53633 100644 --- a/meta/recipes-core/busybox/files/simple.script +++ b/meta/recipes-core/busybox/files/simple.script @@ -28,7 +28,7 @@ case "$1" in fi if ! root_is_nfs ; then if [ $have_bin_ip -eq 1 ]; then -/SBIN_DIR/ip addr flush dev $interface +/SBIN_DIR/ip -4 addr flush dev $interface /SBIN_DIR/ip link set dev $interface up else /SBIN_DIR/ifconfig $interface 0.0.0.0 -- 2.13.6 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [rocko][PATCH v3 4/4] openssl: fix runtime errors with Thumb2 when using binutils 2.29
From: Stefan Agner
When compiling OpenSSL with binutils 2.29 for ARM with Thumb2 enabled
crashes and unexpected behavior occurs. E.g. connecting to a OpenSSH
server using the affected binary fails with:
ssh_dispatch_run_fatal: Connection to 192.168.10.171 port 22: incorrect
signature
Backport upstream bugfix:
https://github.com/openssl/openssl/issues/4659
Signed-off-by: Stefan Agner
Acked-by: Otavio Salvador
---
...-armv4-bsaes-armv7-.pl-make-it-work-with-.patch | 88 ++
.../recipes-connectivity/openssl/openssl_1.1.0g.bb | 1 +
2 files changed, 89 insertions(+)
create mode 100644
meta/recipes-connectivity/openssl/openssl/0001-aes-asm-aes-armv4-bsaes-armv7-.pl-make-it-work-with-.patch
diff --git
a/meta/recipes-connectivity/openssl/openssl/0001-aes-asm-aes-armv4-bsaes-armv7-.pl-make-it-work-with-.patch
b/meta/recipes-connectivity/openssl/openssl/0001-aes-asm-aes-armv4-bsaes-armv7-.pl-make-it-work-with-.patch
new file mode 100644
index 00..bb0a1689ed
--- /dev/null
+++
b/meta/recipes-connectivity/openssl/openssl/0001-aes-asm-aes-armv4-bsaes-armv7-.pl-make-it-work-with-.patch
@@ -0,0 +1,88 @@
+From bcc096a50811bf0f0c4fd34b2993fed7a7015972 Mon Sep 17 00:00:00 2001
+From: Andy Polyakov
+Date: Fri, 3 Nov 2017 23:30:01 +0100
+Subject: [PATCH] aes/asm/{aes-armv4|bsaes-armv7}.pl: make it work with
+ binutils-2.29.
+
+It's not clear if it's a feature or bug, but binutils-2.29[.1]
+interprets 'adr' instruction with Thumb2 code reference differently,
+in a way that affects calculation of addresses of constants' tables.
+
+Upstream-Status: Backport
+
+Reviewed-by: Tim Hudson
+Reviewed-by: Bernd Edlinger
+Signed-off-by: Stefan Agner
+(Merged from https://github.com/openssl/openssl/pull/4669)
+
+(cherry picked from commit b82acc3c1a7f304c9df31841753a0fa76b5b3cda)
+---
+ crypto/aes/asm/aes-armv4.pl | 6 +++---
+ crypto/aes/asm/bsaes-armv7.pl | 6 +++---
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/crypto/aes/asm/aes-armv4.pl b/crypto/aes/asm/aes-armv4.pl
+index 16d79aae53..c6474b8aad 100644
+--- a/crypto/aes/asm/aes-armv4.pl
b/crypto/aes/asm/aes-armv4.pl
+@@ -200,7 +200,7 @@ AES_encrypt:
+ #ifndef __thumb2__
+ sub r3,pc,#8@ AES_encrypt
+ #else
+- adr r3,AES_encrypt
++ adr r3,.
+ #endif
+ stmdb sp!,{r1,r4-r12,lr}
+ #ifdef__APPLE__
+@@ -450,7 +450,7 @@ _armv4_AES_set_encrypt_key:
+ #ifndef __thumb2__
+ sub r3,pc,#8@ AES_set_encrypt_key
+ #else
+- adr r3,AES_set_encrypt_key
++ adr r3,.
+ #endif
+ teq r0,#0
+ #ifdef__thumb2__
+@@ -976,7 +976,7 @@ AES_decrypt:
+ #ifndef __thumb2__
+ sub r3,pc,#8@ AES_decrypt
+ #else
+- adr r3,AES_decrypt
++ adr r3,.
+ #endif
+ stmdb sp!,{r1,r4-r12,lr}
+ #ifdef__APPLE__
+diff --git a/crypto/aes/asm/bsaes-armv7.pl b/crypto/aes/asm/bsaes-armv7.pl
+index 9f288660ef..a27bb4a179 100644
+--- a/crypto/aes/asm/bsaes-armv7.pl
b/crypto/aes/asm/bsaes-armv7.pl
+@@ -744,7 +744,7 @@ $code.=<<___;
+ .type _bsaes_decrypt8,%function
+ .align4
+ _bsaes_decrypt8:
+- adr $const,_bsaes_decrypt8
++ adr $const,.
+ vldmia $key!, {@XMM[9]}@ round 0 key
+ #ifdef__APPLE__
+ adr $const,.LM0ISR
+@@ -843,7 +843,7 @@ _bsaes_const:
+ .type _bsaes_encrypt8,%function
+ .align4
+ _bsaes_encrypt8:
+- adr $const,_bsaes_encrypt8
++ adr $const,.
+ vldmia $key!, {@XMM[9]}@ round 0 key
+ #ifdef__APPLE__
+ adr $const,.LM0SR
+@@ -951,7 +951,7 @@ $code.=<<___;
+ .type _bsaes_key_convert,%function
+ .align4
+ _bsaes_key_convert:
+- adr $const,_bsaes_key_convert
++ adr $const,.
+ vld1.8 {@XMM[7]}, [$inp]! @ load round 0 key
+ #ifdef__APPLE__
+ adr $const,.LM0
+--
+2.15.0
+
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
index 5f3e9a9dfa..1649bffaa1 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
@@ -18,6 +18,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz
\
file://openssl-c_rehash.sh \
file://0001-Take-linking-flags-from-LDFLAGS-env-var.patch \
file://0001-Remove-test-that-requires-running-as-non-root.patch \
+
file://0001-aes-asm-aes-armv4-bsaes-armv7-.pl-make-it-work-with-.patch \
"
S = "${WORKDIR}/openssl-${PV}"
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [rocko][PATCH v3 3/4] openssl: Upgrade 1.1.0f -> 1.1.0g
From: Stefan Agner
Deals with two CVEs:
* bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
* Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
Signed-off-by: Stefan Agner
Acked-by: Otavio Salvador
---
.../openssl/{openssl_1.1.0f.bb => openssl_1.1.0g.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-connectivity/openssl/{openssl_1.1.0f.bb =>
openssl_1.1.0g.bb} (96%)
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
similarity index 96%
rename from meta/recipes-connectivity/openssl/openssl_1.1.0f.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
index 711a95985a..5f3e9a9dfa 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
@@ -10,8 +10,8 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=cae6da10f4ffd9703214776d2aabce32"
BBCLASSEXTEND = "native nativesdk"
-SRC_URI[md5sum] = "7b521dea79ab159e8ec879d269fa"
-SRC_URI[sha256sum] =
"12f746f3f2493b2f39da7ecf63d7ee19c6ac9ec6a4fcd8c229da8a522cb12765"
+SRC_URI[md5sum] = "ba5f1b8b835b88cadbce9b35ed9531a6"
+SRC_URI[sha256sum] =
"de4d501267da39310905cb6dc8c6121f7a2cad45a7707f76df828fe1b85073af"
SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
file://run-ptest \
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [rocko][PATCH v3 1/4] openssl10: Upgrade 1.0.2l -> 1.0.2m
From: Stefan Agner
Deals with two CVEs:
* bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
* Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
Signed-off-by: Stefan Agner
Acked-by: Otavio Salvador
---
Changes since v2:
- Rebased to rocko-next
.../0001-Fix-build-with-clang-using-external-assembler.patch | 0
.../0001-openssl-force-soft-link-to-avoid-rare-race.patch | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/Makefiles-ptest.patch | 0
.../Use-SHA256-not-MD5-as-default-digest.patch| 0
.../{openssl-1.0.2l => openssl-1.0.2m}/configure-musl-target.patch| 0
.../{openssl-1.0.2l => openssl-1.0.2m}/configure-targets.patch| 0
.../{openssl-1.0.2l => openssl-1.0.2m}/debian/c_rehash-compat.patch | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/debian/ca.patch| 0
.../{openssl-1.0.2l => openssl-1.0.2m}/debian/debian-targets.patch| 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/debian/man-dir.patch | 0
.../{openssl-1.0.2l => openssl-1.0.2m}/debian/man-section.patch | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/debian/no-rpath.patch | 0
.../{openssl-1.0.2l => openssl-1.0.2m}/debian/no-symbolic.patch | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/debian/pic.patch | 0
.../{openssl-1.0.2l => openssl-1.0.2m}/debian/version-script.patch| 0
.../debian1.0.2/block_digicert_malaysia.patch | 0
.../debian1.0.2/block_diginotar.patch | 0
.../{openssl-1.0.2l => openssl-1.0.2m}/debian1.0.2/soname.patch | 0
.../debian1.0.2/version-script.patch | 0
.../engines-install-in-libdir-ssl.patch | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/find.pl| 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/oe-ldflags.patch | 0
.../{openssl-1.0.2l => openssl-1.0.2m}/openssl-1.0.2a-x32-asm.patch | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/openssl-c_rehash.sh| 0
.../openssl-fix-des.pod-error.patch | 0
.../openssl-util-perlpath.pl-cwd.patch| 0
.../{openssl-1.0.2l => openssl-1.0.2m}/openssl_fix_for_x32.patch | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/parallel.patch | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/ptest-deps.patch | 0
.../{openssl-1.0.2l => openssl-1.0.2m}/ptest_makefile_deps.patch | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/run-ptest | 0
.../openssl/{openssl-1.0.2l => openssl-1.0.2m}/shared-libs.patch | 0
.../openssl/{openssl_1.0.2l.bb => openssl_1.0.2m.bb} | 4 ++--
33 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/0001-Fix-build-with-clang-using-external-assembler.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/0001-openssl-force-soft-link-to-avoid-rare-race.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/Makefiles-ptest.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/Use-SHA256-not-MD5-as-default-digest.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/configure-musl-target.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/configure-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian/c_rehash-compat.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian/ca.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian/debian-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian/man-dir.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian/man-section.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian/no-rpath.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian/no-symbolic.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian/pic.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian/version-script.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian1.0.2/block_digicert_malaysia.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian1.0.2/block_diginotar.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2l =>
openssl-1.0.2m}/debian1.0.2/soname.pa
[OE-core] [rocko][PATCH v3 2/4] openssl10: fix runtime errors with Thumb2 when using binutils 2.29
From: Stefan Agner
When compiling OpenSSL with binutils 2.29 for ARM with Thumb2 enabled
crashes and unexpected behavior occurs. E.g. connecting to a OpenSSH
server using the affected binary fails with:
ssh_dispatch_run_fatal: Connection to 192.168.10.171 port 22: incorrect
signature
Backport upstream bugfix:
https://github.com/openssl/openssl/issues/4659
Signed-off-by: Stefan Agner
Acked-by: Otavio Salvador
---
...saes-armv7-sha256-armv4-.pl-make-it-work-.patch | 100 +
.../recipes-connectivity/openssl/openssl_1.0.2m.bb | 1 +
2 files changed, 101 insertions(+)
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.2m/0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
diff --git
a/meta/recipes-connectivity/openssl/openssl-1.0.2m/0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
b/meta/recipes-connectivity/openssl/openssl-1.0.2m/0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
new file mode 100644
index 00..2ce0320c49
--- /dev/null
+++
b/meta/recipes-connectivity/openssl/openssl-1.0.2m/0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
@@ -0,0 +1,100 @@
+From d1d6c69b6fd25e71dbae67fad17b2c7737f6b2dc Mon Sep 17 00:00:00 2001
+From: Andy Polyakov
+Date: Sun, 5 Nov 2017 17:08:16 +0100
+Subject: [PATCH] {aes-armv4|bsaes-armv7|sha256-armv4}.pl: make it work with
+ binutils-2.29
+
+It's not clear if it's a feature or bug, but binutils-2.29[.1]
+interprets 'adr' instruction with Thumb2 code reference differently,
+in a way that affects calculation of addresses of constants' tables.
+
+Upstream-Status: Backport
+
+Reviewed-by: Bernd Edlinger
+Reviewed-by: Kurt Roeckx
+Signed-off-by: Stefan Agner
+(Merged from https://github.com/openssl/openssl/pull/4673)
+---
+ crypto/aes/asm/aes-armv4.pl| 6 +++---
+ crypto/aes/asm/bsaes-armv7.pl | 6 +++---
+ crypto/sha/asm/sha256-armv4.pl | 2 +-
+ 3 files changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/crypto/aes/asm/aes-armv4.pl b/crypto/aes/asm/aes-armv4.pl
+index 4f8917089f..c1b5e352d7 100644
+--- a/crypto/aes/asm/aes-armv4.pl
b/crypto/aes/asm/aes-armv4.pl
+@@ -184,7 +184,7 @@ AES_encrypt:
+ #if __ARM_ARCH__<7
+ sub r3,pc,#8@ AES_encrypt
+ #else
+- adr r3,AES_encrypt
++ adr r3,.
+ #endif
+ stmdb sp!,{r1,r4-r12,lr}
+ mov $rounds,r0 @ inp
+@@ -430,7 +430,7 @@ _armv4_AES_set_encrypt_key:
+ #if __ARM_ARCH__<7
+ sub r3,pc,#8@ AES_set_encrypt_key
+ #else
+- adr r3,private_AES_set_encrypt_key
++ adr r3,.
+ #endif
+ teq r0,#0
+ #if __ARM_ARCH__>=7
+@@ -952,7 +952,7 @@ AES_decrypt:
+ #if __ARM_ARCH__<7
+ sub r3,pc,#8@ AES_decrypt
+ #else
+- adr r3,AES_decrypt
++ adr r3,.
+ #endif
+ stmdb sp!,{r1,r4-r12,lr}
+ mov $rounds,r0 @ inp
+diff --git a/crypto/aes/asm/bsaes-armv7.pl b/crypto/aes/asm/bsaes-armv7.pl
+index 70b3f9656f..ec66b0502a 100644
+--- a/crypto/aes/asm/bsaes-armv7.pl
b/crypto/aes/asm/bsaes-armv7.pl
+@@ -724,7 +724,7 @@ $code.=<<___;
+ .type _bsaes_decrypt8,%function
+ .align4
+ _bsaes_decrypt8:
+- adr $const,_bsaes_decrypt8
++ adr $const,.
+ vldmia $key!, {@XMM[9]}@ round 0 key
+ add $const,$const,#.LM0ISR-_bsaes_decrypt8
+
+@@ -819,7 +819,7 @@ _bsaes_const:
+ .type _bsaes_encrypt8,%function
+ .align4
+ _bsaes_encrypt8:
+- adr $const,_bsaes_encrypt8
++ adr $const,.
+ vldmia $key!, {@XMM[9]}@ round 0 key
+ sub $const,$const,#_bsaes_encrypt8-.LM0SR
+
+@@ -923,7 +923,7 @@ $code.=<<___;
+ .type _bsaes_key_convert,%function
+ .align4
+ _bsaes_key_convert:
+- adr $const,_bsaes_key_convert
++ adr $const,.
+ vld1.8 {@XMM[7]}, [$inp]! @ load round 0 key
+ sub $const,$const,#_bsaes_key_convert-.LM0
+ vld1.8 {@XMM[15]}, [$inp]! @ load round 1 key
+diff --git a/crypto/sha/asm/sha256-armv4.pl b/crypto/sha/asm/sha256-armv4.pl
+index 4fee74d832..750216eb42 100644
+--- a/crypto/sha/asm/sha256-armv4.pl
b/crypto/sha/asm/sha256-armv4.pl
+@@ -205,7 +205,7 @@ sha256_block_data_order:
+ #if __ARM_ARCH__<7
+ sub r3,pc,#8@ sha256_block_data_order
+ #else
+- adr r3,sha256_block_data_order
++ adr r3,.
+ #endif
+ #if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
+ ldr r12,.LOPENSSL_armcap
+--
+2.15.0
+
diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2m.bb
b/meta/recipes-connectivity/openssl/openssl_1.0.2m.bb
index 04763ac346..9270f52bc6 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.2m.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.2m.bb
@@ -42,6 +42,7 @@ SRC_URI += "file://find.pl;subdir=openssl-${PV}/ut
[OE-core] [PATCH] busybox: udhcpc: fix IPv6 support when using udhcpc
From: Stefan Agner The udhcpc script calls ip addr flush .. which flushes addresses of any address family, including IPv6. However, busybox udhcpc is IPv4 only and should not influence IPv6 addressing. Hence use ip addr flush with family constrait. The script particularly broke IPv6 SLAAC: Typically when udhcpc calls the script the kernel already assigned the IPv6 link-local address. The flush removes the link-local IPv6 address again and prohibits proper IPv6 operation such as SLAAC since neighbor discovery protocol relies on IPv6 link-local addressing. Signed-off-by: Stefan Agner --- meta/recipes-core/busybox/files/simple.script | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/busybox/files/simple.script b/meta/recipes-core/busybox/files/simple.script index 6ed0293525..8b5eb53633 100644 --- a/meta/recipes-core/busybox/files/simple.script +++ b/meta/recipes-core/busybox/files/simple.script @@ -28,7 +28,7 @@ case "$1" in fi if ! root_is_nfs ; then if [ $have_bin_ip -eq 1 ]; then -/SBIN_DIR/ip addr flush dev $interface +/SBIN_DIR/ip -4 addr flush dev $interface /SBIN_DIR/ip link set dev $interface up else /SBIN_DIR/ifconfig $interface 0.0.0.0 -- 2.13.6 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
On 2017-12-14 19:04, Alexander Kanavin wrote: > On 12/14/2017 07:49 PM, Alexander Kanavin wrote: >> On 12/14/2017 07:40 PM, Stefan Agner wrote: >> >>> Oh, I see, well that simplifies it, doesn't it? E.g. >>> >>> # If package managers support postinsts and the package manager is >>> present on the >>> # rootfs, then it will handle postinsts just fine, no need to deploy >>> scripts again. >>> if delayed_postinsts and not runtime_pkgmanage: >>> self._save_postinsts() >>> >>> And with that it will be as it used to be before the above commit, and >>> the way it should be. >> >> Sorry, but no. You are making an implicit assumption about how rpmrootfs >> child class behaves here, which is not a good thing to do in a parent class. > > What you *can* do however is move the "and not runtime_pkgmanage" > check into the child classes for opkg and dpkg. I'm fine with that. > That sounds sensible. Will send a patchset. -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
On 2017-12-14 18:28, Alexander Kanavin wrote: > On 12/14/2017 07:16 PM, Stefan Agner wrote: > >> Are you sure that rpm has no such facility? Maybe there is some other >> mechanism around... > > You are welcome to find it. rpm does not distinguish between unpacking > and configuring steps, and just does everything in a single > installation step. > >> If rpm really does not handle it, would mean that delayed postinst would >> have been broken back when we did not ship /etc/*-postinsts: >> http://git.openembedded.org/openembedded-core/commit/meta/lib/oe/rootfs.py?id=5aae19959a443c6ac4b0feef10715c8acf3c6376 > > Rpm had a special way to save postinstall scripts (due to the same > problem I described just above), and still does, which means > _save_postinsts() did (and does) nothing in rpm case. > Oh, I see, well that simplifies it, doesn't it? E.g. # If package managers support postinsts and the package manager is present on the # rootfs, then it will handle postinsts just fine, no need to deploy scripts again. if delayed_postinsts and not runtime_pkgmanage: self._save_postinsts() And with that it will be as it used to be before the above commit, and the way it should be. -- Stefan >> If there is special case handling needed it is not particularly nice due >> to the additional condition. >> >> But IMHO still better, it can easily be explained in rootfs.py with a >> comment like: >> >> # deb/ipk package management is able to handle postinsts on first >> boot. > > Please no; the class in question is the generic Rootfs(), and I do not > want to add packagemanager-specific clauses there. > > Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
On 2017-12-14 17:59, Alexander Kanavin wrote: > On 12/14/2017 06:46 PM, Stefan Agner wrote: > >> Suggestion: >> - Still remove systemd opkg service as proposed, since run-postinsts >> gets run with systemd and should/will handle package manager just fine > > Yes. > >> - Change run-postinsts to behave sane: Detect package management by >> checking /var/lib/dpkg/status and /var/lib/opkg/status only (remove the >> if [ ! -d $pi_dir ]; then continue; fi...) > > Maybe; you need to explain this carefully in the commit message. > >> - Stop deploying /etc/*-postinsts when package management is installed > > Probably not; rpm does not have a facility for 'delayed postinst > execution' the way dpkg/opkg do, and this would create more confusion > and special-casing than achieve any real improvement imo. Are you sure that rpm has no such facility? Maybe there is some other mechanism around... If rpm really does not handle it, would mean that delayed postinst would have been broken back when we did not ship /etc/*-postinsts: http://git.openembedded.org/openembedded-core/commit/meta/lib/oe/rootfs.py?id=5aae19959a443c6ac4b0feef10715c8acf3c6376 If there is special case handling needed it is not particularly nice due to the additional condition. But IMHO still better, it can easily be explained in rootfs.py with a comment like: # deb/ipk package management is able to handle postinsts on first boot. if ... I will do some tests with rpm and send a patchset. > > Jussi left Intel several months ago. I see. -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
On 2017-12-14 16:14, Alexander Kanavin wrote: > On 12/14/2017 04:57 PM, Stefan Agner wrote: >> On 2017-12-14 15:55, Alexander Kanavin wrote: >>> On 12/14/2017 04:41 PM, Stefan Agner wrote: >>> >>>> I think removing the Opkg first boot systemd service (as the initial >>>> patch does) is the correct first step. >>>> >>>> However, it currently still leads to a second copy of the postinst >>>> scripts in /etc if package management is enabled. >>>> I am pretty sure that adding if delayed_postinsts and not >>>> runtime_pkgmanage: should resolve the problem for ipk/deb fully: With >>>> that run-postinsts will run "opkg configure"/"dpkg --configure -a" >>>> respectively when package management is installed, and those command >>>> will run all postinst correctly. >>> >>> Why is the second copy a problem? Can you elaborate? Don't describe >>> the fix, describe the issue. >>> >>> From what I can see, run-postinsts will execute opkg configure if opkg >>> is available, or run the scripts directly if opkg is not available - >>> which is fine. Why do you need to avoid saving the scripts in /etc if >>> opkg is installed? >> >> No, it will call the scripts in /etc/*-postinsts (it bails out of the >> for loop if the post inst dir is there...) > > Let's look at the code. Can you point out what the faulty code path is? > > # the order of this list is important, do not change! > backend_list="rpm deb ipk" > > pm_installed=false > > for pm in $backend_list; do > pi_dir="#SYSCONFDIR#/$pm-postinsts" > > if [ ! -d $pi_dir ]; then > continue > fi I need to admit that parts of my testing was using morty, and I looked at the code which was on that platform. That logic got changed... It used to looked like that in morty: http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts?h=morty#n16 The change has been made due to the same issue I mentioned above: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10478 So yes, it actually works right now. The systemd service still seems superfluous though, since run-postinsts does the opkg configure. But then, digging a bit deeper, I come to following findings: IMHO, Jussi came to the wrong conclusion that the break is the bug (Comment #4 in the above bug). The "break" was intentionally: The intention was to let run-postinsts handle the scripts *always* if there were script in the rootfs. And a little bit earlier meta/lib/oe/rootfs.py did exectly what I proposed: http://git.openembedded.org/openembedded-core/tree/meta/lib/oe/rootfs.py?id=b198a189228648057c3be7d068598f50841b3bf9#n131 -> It only installed postinst if package management was disabled and delayed postinsts were necessary. I think the order of events was that the removing with package management got broken with this commit: http://git.openembedded.org/openembedded-core/commit/meta/lib/oe/rootfs.py?id=5aae19959a443c6ac4b0feef10715c8acf3c6376 Judging from the commit log that was not intentionally. So from then on, we installed /etc/*-postinsts even when using package management... At that lead to the the issue #10478, which fixed the issue at runtime... Anyway, I think it is not sensible to deploy scripts we just delete on first boot when we could have not deployed them in first place! Also, we rely on some scripts in /etc/*-postinsts to be present to call the package manager, although the package manger has no direct relation to those scripts... Suggestion: - Still remove systemd opkg service as proposed, since run-postinsts gets run with systemd and should/will handle package manager just fine - Change run-postinsts to behave sane: Detect package management by checking /var/lib/dpkg/status and /var/lib/opkg/status only (remove the if [ ! -d $pi_dir ]; then continue; fi...) - Stop deploying /etc/*-postinsts when package management is installed -- Stefan > > # found the package manager, it has postinsts > case $pm in > "deb") > if [ -s "#LOCALSTATEDIR#/lib/dpkg/status" ]; then > pm_installed=true > fi > ;; > > "ipk") > if [ -s "#LOCALSTATEDIR#/lib/opkg/status" ]; then > pm_installed=true > fi > ;; > esac > break > done > > > > if $pm_installed; then > case $pm in >
Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
On 2017-12-14 15:55, Alexander Kanavin wrote: > On 12/14/2017 04:41 PM, Stefan Agner wrote: > >> I think removing the Opkg first boot systemd service (as the initial >> patch does) is the correct first step. >> >> However, it currently still leads to a second copy of the postinst >> scripts in /etc if package management is enabled. >> I am pretty sure that adding if delayed_postinsts and not >> runtime_pkgmanage: should resolve the problem for ipk/deb fully: With >> that run-postinsts will run "opkg configure"/"dpkg --configure -a" >> respectively when package management is installed, and those command >> will run all postinst correctly. > > Why is the second copy a problem? Can you elaborate? Don't describe > the fix, describe the issue. > > From what I can see, run-postinsts will execute opkg configure if opkg > is available, or run the scripts directly if opkg is not available - > which is fine. Why do you need to avoid saving the scripts in /etc if > opkg is installed? No, it will call the scripts in /etc/*-postinsts (it bails out of the for loop if the post inst dir is there...) Then opkg status file still shows the packages as just "unpacked". When running the package manager (e.g. to install an unrelated package) opkg starts to handle the postinst again... Rather than updating the package managers database etc I rather feel we should just not do the OE specific postinst if package management can handle it. -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
On 2017-12-14 15:24, Alexander Kanavin wrote: > On 12/14/2017 03:59 PM, Stefan Agner wrote: > >> That at least contradicts my testing with opkg/ipk. >> >> If /etc/ipk-postinsts is not there and /var/lib/opkg/status is there >> (package management installed), then run-postinst runs "opkg configure", >> which takes care of postinsts just fine. >> >> Reading the code at least let me to believe that this is true for deb as >> well. >> >> Not sure how it works with rpm though. How do you came to the conclusion >> that this only happens when using rpm? > > I think there was confusion between what happens at image creation > time vs what happens at first boot :) > > So what's the issue again that your RFC patch doesn't resolve? I read > your followup and I still don't get it. I think removing the Opkg first boot systemd service (as the initial patch does) is the correct first step. However, it currently still leads to a second copy of the postinst scripts in /etc if package management is enabled. I am pretty sure that adding if delayed_postinsts and not runtime_pkgmanage: should resolve the problem for ipk/deb fully: With that run-postinsts will run "opkg configure"/"dpkg --configure -a" respectively when package management is installed, and those command will run all postinst correctly. So for me the only question is what will happen with rpm... Will package managment do something on first boot? And if yes, what mechanism? If rpm needs /etc/*-postinsts even with package management, then maybe we need to add: if delayed_postinsts and (not runtime_pkgmanage or rpm): self._save_postinsts() -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
On 2017-12-14 14:52, Alexander Kanavin wrote: > On 12/14/2017 03:11 PM, Stefan Agner wrote: >> >>> I don't think this is correct. Some postinsts are intentionally >>> deferred to first boot, and they need to be run regardless of whether >>> the image supports runtime package management or not. >> >> Yes I know, the mentioned opkg-keyrings is such a case. >> >> If there is no package management, then scripts get deployed via >> /etc/*-postinsts, if package management is available then it will take >> care of it. > > From reading the code, that only happens when using rpm. In other > cases you need to execute _save_postinsts(), regardless of whether > package management is available on image or not. That at least contradicts my testing with opkg/ipk. If /etc/ipk-postinsts is not there and /var/lib/opkg/status is there (package management installed), then run-postinst runs "opkg configure", which takes care of postinsts just fine. Reading the code at least let me to believe that this is true for deb as well. Not sure how it works with rpm though. How do you came to the conclusion that this only happens when using rpm? > > Whatever changes you try, do run oe-selftest's > 'test_postinst_rootfs_and_boot' test against them and make sure it > doesn't regress. Yeah will do when I have a solution which I am happy with. Before that, I rather prefer understanding the whole issue and try to come up with a solution that works on first regression test (rather than try and error)... -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
On 2017-12-14 14:10, Alexander Kanavin wrote:
> On 12/13/2017 08:29 PM, Stefan Agner wrote:
>
>> Maybe it needs something like this?
>>
>>
>> runtime_pkgmanage = bb.utils.contains("IMAGE_FEATURES",
>> "package-management",
>>True, False, self.d)
>> if delayed_postinsts and not runtime_pkgmanage:
>> self._save_postinsts()
>> if image_rorfs:
>> bb.warn("There are post install scripts "
>> "in a read-only rootfs")
>
> I don't think this is correct. Some postinsts are intentionally
> deferred to first boot, and they need to be run regardless of whether
> the image supports runtime package management or not.
Yes I know, the mentioned opkg-keyrings is such a case.
If there is no package management, then scripts get deployed via
/etc/*-postinsts, if package management is available then it will take
care of it.
--
Stefan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
On 2017-12-13 19:06, Stefan Agner wrote:
> From: Stefan Agner
>
> OpenEmbedded has a built-in mechanism to run postinst scripts offline
> at build time or, if necessary, on first boot (delayed execution). If
> the latter is the case and systemd is in use, two services end up
> doing the same thing:
> - opkg-configure.service starts "opkg configure" which in turn parses
> /var/lib/opkg/status and runs the postinst scripts stored in
> /var/lib/opkg/info/.
> - run-postinsts.service starts "/usr/sbin/run-postinsts" which runs
> postinst scripts stored in /etc/ipk-postinsts/. Those scripts get
> prepared by meta/lib/oe/rootfs.py (see also _save_postinsts of the
> OpkgRootfs class)
>
> This can be seen when using a distro using ipk and systemd, then
> installing opkg-keyrings and enable package management. The resulting
> rootfs has both services and will run opkg-keyrings.postinst twice.
>
> Moreover, because the two services have similar dependency, they
> typically get executed almost at the same time:
> Dec 13 14:47:25 colibri-imx6 systemd[1]: Starting Opkg first boot
> configure...
> ...
> Dec 13 14:47:25 colibri-imx6 systemd[1]: Starting Run pending postinsts...
>
> This leads to executions of the same postinst scripts racing with each
> other! In practise update-alternative has been proven to be suspectable
> to such races.
>
> Get rid of the opkg service to avoid dupplicate postinst execution.
With this applied there is one problem though: opkg status file still
shows the packages as just "unpacked". When running the package manager
(e.g. to install an unrelated package) opkg starts to handle the
postinst nonetheless.
So there is another issue basically. Looking at /usr/sbin/run-postinsts
I see that "opkg configure" is actually triggered if there are no
scripts in /etc/ipk-postinsts. However, meta/lib/oe/rootfs.py calls
_save_postinsts() no matter whether there is package management or no:
...
if delayed_postinsts:
self._save_postinsts()
if image_rorfs:
bb.warn("There are post install scripts "
"in a read-only rootfs")
...
Maybe it needs something like this?
runtime_pkgmanage = bb.utils.contains("IMAGE_FEATURES",
"package-management",
True, False, self.d)
if delayed_postinsts and not runtime_pkgmanage:
self._save_postinsts()
if image_rorfs:
bb.warn("There are post install scripts "
"in a read-only rootfs")
But then, this is common code for all supported package formats. It
seems that /usr/sbin/run-postinsts only supports package manager
postinst processing for deb and ipk...
Comments appreciated.
--
Stefan
>
> Signed-off-by: Stefan Agner
> ---
> meta/recipes-devtools/opkg/opkg/opkg-configure.service | 17 -
> meta/recipes-devtools/opkg/opkg_0.3.5.bb | 13 -
> 2 files changed, 30 deletions(-)
> delete mode 100644 meta/recipes-devtools/opkg/opkg/opkg-configure.service
>
> diff --git a/meta/recipes-devtools/opkg/opkg/opkg-configure.service
> b/meta/recipes-devtools/opkg/opkg/opkg-configure.service
> deleted file mode 100644
> index 432c3ddc28..00
> --- a/meta/recipes-devtools/opkg/opkg/opkg-configure.service
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -[Unit]
> -Description=Opkg first boot configure
> -DefaultDependencies=no
> -After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount
> -Before=sysinit.target
> -
> -[Service]
> -Type=oneshot
> -EnvironmentFile=-@SYSCONFDIR@/default/postinst
> -ExecStart=-@BASE_BINDIR@/sh -c " if [ $POSTINST_LOGGING = '1' ]; then
> @BINDIR@/opkg configure > $LOGFILE 2>&1; else @BINDIR@/opkg configure;
> fi"
> -ExecStartPost=@BASE_BINDIR@/systemctl --no-reload disable
> opkg-configure.service
> -StandardOutput=syslog
> -RemainAfterExit=No
> -
> -[Install]
> -WantedBy=basic.target
> -WantedBy=sysinit.target
> diff --git a/meta/recipes-devtools/opkg/opkg_0.3.5.bb
> b/meta/recipes-devtools/opkg/opkg_0.3.5.bb
> index 3e511b6bb6..fb36e8b866 100644
> --- a/meta/recipes-devtools/opkg/opkg_0.3.5.bb
> +++ b/meta/recipes-devtools/opkg/opkg_0.3.5.bb
> @@ -22,8 +22,6 @@ SRC_URI[sha256sum] =
> "734bc21dea11262113fa86b928d09812618b3966f352350cf916a6ae0d
>
> inherit autotools pkgconfig systemd
>
> -SYSTEMD_SERVICE_${PN} = "opkg-configure.service"
> -
> target_localstatedir := "${localstatedir}"
> OPKGLIBDIR = "${target_localstatedir}/lib"
>
> @@ -46,16 +44,6 @@ do_install_app
[OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd
From: Stefan Agner
OpenEmbedded has a built-in mechanism to run postinst scripts offline
at build time or, if necessary, on first boot (delayed execution). If
the latter is the case and systemd is in use, two services end up
doing the same thing:
- opkg-configure.service starts "opkg configure" which in turn parses
/var/lib/opkg/status and runs the postinst scripts stored in
/var/lib/opkg/info/.
- run-postinsts.service starts "/usr/sbin/run-postinsts" which runs
postinst scripts stored in /etc/ipk-postinsts/. Those scripts get
prepared by meta/lib/oe/rootfs.py (see also _save_postinsts of the
OpkgRootfs class)
This can be seen when using a distro using ipk and systemd, then
installing opkg-keyrings and enable package management. The resulting
rootfs has both services and will run opkg-keyrings.postinst twice.
Moreover, because the two services have similar dependency, they
typically get executed almost at the same time:
Dec 13 14:47:25 colibri-imx6 systemd[1]: Starting Opkg first boot configure...
...
Dec 13 14:47:25 colibri-imx6 systemd[1]: Starting Run pending postinsts...
This leads to executions of the same postinst scripts racing with each
other! In practise update-alternative has been proven to be suspectable
to such races.
Get rid of the opkg service to avoid dupplicate postinst execution.
Signed-off-by: Stefan Agner
---
meta/recipes-devtools/opkg/opkg/opkg-configure.service | 17 -
meta/recipes-devtools/opkg/opkg_0.3.5.bb | 13 -
2 files changed, 30 deletions(-)
delete mode 100644 meta/recipes-devtools/opkg/opkg/opkg-configure.service
diff --git a/meta/recipes-devtools/opkg/opkg/opkg-configure.service
b/meta/recipes-devtools/opkg/opkg/opkg-configure.service
deleted file mode 100644
index 432c3ddc28..00
--- a/meta/recipes-devtools/opkg/opkg/opkg-configure.service
+++ /dev/null
@@ -1,17 +0,0 @@
-[Unit]
-Description=Opkg first boot configure
-DefaultDependencies=no
-After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount
-Before=sysinit.target
-
-[Service]
-Type=oneshot
-EnvironmentFile=-@SYSCONFDIR@/default/postinst
-ExecStart=-@BASE_BINDIR@/sh -c " if [ $POSTINST_LOGGING = '1' ]; then
@BINDIR@/opkg configure > $LOGFILE 2>&1; else @BINDIR@/opkg configure; fi"
-ExecStartPost=@BASE_BINDIR@/systemctl --no-reload disable
opkg-configure.service
-StandardOutput=syslog
-RemainAfterExit=No
-
-[Install]
-WantedBy=basic.target
-WantedBy=sysinit.target
diff --git a/meta/recipes-devtools/opkg/opkg_0.3.5.bb
b/meta/recipes-devtools/opkg/opkg_0.3.5.bb
index 3e511b6bb6..fb36e8b866 100644
--- a/meta/recipes-devtools/opkg/opkg_0.3.5.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.3.5.bb
@@ -22,8 +22,6 @@ SRC_URI[sha256sum] =
"734bc21dea11262113fa86b928d09812618b3966f352350cf916a6ae0d
inherit autotools pkgconfig systemd
-SYSTEMD_SERVICE_${PN} = "opkg-configure.service"
-
target_localstatedir := "${localstatedir}"
OPKGLIBDIR = "${target_localstatedir}/lib"
@@ -46,16 +44,6 @@ do_install_append () {
# We need to create the lock directory
install -d ${D}${OPKGLIBDIR}/opkg
-
- if
${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};then
- install -d ${D}${systemd_unitdir}/system
- install -m 0644 ${WORKDIR}/opkg-configure.service
${D}${systemd_unitdir}/system/
- sed -i -e 's,@BASE_BINDIR@,${base_bindir},g' \
- -e 's,@SYSCONFDIR@,${sysconfdir},g' \
- -e 's,@BINDIR@,${bindir},g' \
- -e 's,@SYSTEMD_UNITDIR@,${systemd_unitdir},g' \
- ${D}${systemd_unitdir}/system/opkg-configure.service
- fi
}
RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} opkg-arch-config
libarchive"
@@ -68,7 +56,6 @@ RPROVIDES_${PN} = "opkg-collateral"
PACKAGES =+ "libopkg"
FILES_libopkg = "${libdir}/*.so.* ${OPKGLIBDIR}/opkg/"
-FILES_${PN} += "${systemd_unitdir}/system/"
BBCLASSEXTEND = "native nativesdk"
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] waf.bbclass: explicitly pass bindir and libdir if supported
From: Stefan Agner
On some build hosts distros (e.g. Fedora 26) waf tries to be
smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
This obviously is not what we want for 32-bit targets and usually
fails in the do_package phase:
WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in
any package:
/usr/lib64/libgstimxcommon.so.0
...
Depending on version, waf knows prefix or prefix, bindir and
libdir as default options. Explicitly pass the right set of
arguments.
Signed-off-by: Stefan Agner
---
meta/classes/waf.bbclass | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/meta/classes/waf.bbclass b/meta/classes/waf.bbclass
index c4698e910a..acbda278a2 100644
--- a/meta/classes/waf.bbclass
+++ b/meta/classes/waf.bbclass
@@ -25,8 +25,23 @@ def get_waf_parallel_make(d):
return ""
+python waf_preconfigure() {
+from distutils.version import StrictVersion
+srcsubdir = d.getVar('S')
+wafbin = os.path.join(srcsubdir, 'waf')
+status, result = oe.utils.getstatusoutput(wafbin + " --version")
+if status != 0:
+bb.warn("Unable to execute waf --version, exit code %d. Assuming waf
version without bindir/libdir support." % status)
+return
+version = result.split()[1]
+if StrictVersion(version) >= StrictVersion("1.8.7"):
+d.setVar("WAF_EXTRA_CONF", "--bindir=${bindir} --libdir=${libdir}")
+}
+
+do_configure[prefuncs] += "waf_preconfigure"
+
waf_do_configure() {
- ${S}/waf configure --prefix=${prefix} ${EXTRA_OECONF}
+ ${S}/waf configure --prefix=${prefix} ${WAF_EXTRA_CONF} ${EXTRA_OECONF}
}
waf_do_compile() {
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir
On 2017-12-12 17:04, Vincent Prince wrote:
> As waf_do_configure takes care of EXTRA_OECONF, maybe we can only fix
> gstreamer1.0-plugins-imx_0.13.0.bb by adding libdir ?
> It is much a bug fix than a longterm solution, but if any waf version breaks
> options, it can be a nightmare to handle...
For me, that definitly would work too.
But then, since all version of waf > 1.8.6 seem to use this
autodetection it is quite likely that other packages fail/will fail.
I am about to send a v3 with version detection, lets see if we can agree
on such a solution (and backport it to rocko).
--
Stefan
>
> 2017-12-12 16:56 GMT+01:00 Stefan Agner :
>
>> On 2017-12-12 16:47, Otavio Salvador wrote:
>>> On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner wrote:
>>>> On 2017-12-12 15:13, Burton, Ross wrote:
>>>>
>>>>> On 12 December 2017 at 14:03, Stefan Agner wrote:
>>>>>
>>>>>> On 2017-12-12 15:00, Burton, Ross wrote:
>>>>>>
>>>>>>> On 12 December 2017 at 13:27, Stefan Agner wrote:
>>>>>>>
>>>>>>>> On some build hosts distros (e.g. Fedora 26) waf tries to be
>>>>>>>> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
>>>>>>>> This obviously is not what we want for 32-bit targets and usually
>>>>>>>> fails in the do_package phase:
>>>>>>>> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
>>>>>>>> gstreamer1.0-plugins-imx: Files/directories were installed but not
>>>>>>>> shipped in any package:
>>>>>>>> /usr/lib64/libgstimxcommon.so.0
>>>>>>>>
>>>>>>>> Waf knows prefix, bindir and libdir as default options. Explicitly
>>>>>>>> pass those three.
>>>>>>>
>>>>>>> Obviously not.
>>>>>>>
>>>>>>> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure
>>>>>>> (log file is located at
>>>>>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
>>>>>>> ERROR: Logfile of failure stored in:
>>>>>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
>>>>>>> Log data follows:
>>>>>>> | DEBUG: Executing shell function do_configure
>>>>>>> | waf [commands] [options]
>>>>>>> |
>>>>>>> | Main commands (example: ./waf build -j4)
>>>>>>> | build: executes the build
>>>>>>> | clean: cleans the project
>>>>>>> | configure: configures the project
>>>>>>> | dist : makes a tarball for redistributing the sources
>>>>>>> | distcheck: checks if the project compiles (tarball from 'dist')
>>>>>>> | distclean: removes the build directory
>>>>>>> | install : installs the targets on the system
>>>>>>> | list : lists the targets to execute
>>>>>>> | step : executes tasks in a step-by-step fashion, for debugging
>>>>>>> | uninstall: removes the targets installed
>>>>>>> | update : updates the plugins from the *waflib/extras* directory
>>>>>>> |
>>>>>>> | waf: error: no such option: --bindir
>>>>>>>
>>>>>> Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific.
>>>>>>
>>>>>> It seems bindir/libdir got added in 1.8 series:
>>>>>> https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py
>>>>>>
>>>>>> Make version specific variables?
>>>>>
>>>>> That neatly shows where the "clever code" that was breaking libdir
>>>>> earlier is:
>>>>>
>>>>> https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0ab003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237
>>>>>
>>>>
>>>> Yeah that seems to be it.
>>>>
>>>> That go added in the 1.8.6 dev cycle afaik.
>>>>
>>>> I am thinking about adding some kind of version autodetection
>>>>
>>>> WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-9]*
>>>> (.*//};q')
>>>>
>>>> if [ $WAFMINOR -gt "7" ] ...
>>>>
>>>> Maybe there is a nicer way of doing this?
>>>
>>> What about we provide a package waf version and replace the binaries
>>> prior building? So we know what version we'd be using. Kinda
>>> autoreconf run in autotools class.
>> Waf seems to be extensible using wscript. I don't know how exactly
>> wscript depends on waf (version) and whether the API is considered
>> stable...
>>
>> I'd rather prefer not taking chances...
>>
>> --
>> Stefan
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir
On 2017-12-12 16:47, Otavio Salvador wrote:
> On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner wrote:
>> On 2017-12-12 15:13, Burton, Ross wrote:
>>
>>> On 12 December 2017 at 14:03, Stefan Agner wrote:
>>>
>>>> On 2017-12-12 15:00, Burton, Ross wrote:
>>>>
>>>>> On 12 December 2017 at 13:27, Stefan Agner wrote:
>>>>>
>>>>>> On some build hosts distros (e.g. Fedora 26) waf tries to be
>>>>>> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
>>>>>> This obviously is not what we want for 32-bit targets and usually
>>>>>> fails in the do_package phase:
>>>>>> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
>>>>>> gstreamer1.0-plugins-imx: Files/directories were installed but not
>>>>>> shipped in any package:
>>>>>> /usr/lib64/libgstimxcommon.so.0
>>>>>>
>>>>>> Waf knows prefix, bindir and libdir as default options. Explicitly
>>>>>> pass those three.
>>>>>
>>>>> Obviously not.
>>>>>
>>>>> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure
>>>>> (log file is located at
>>>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
>>>>> ERROR: Logfile of failure stored in:
>>>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
>>>>> Log data follows:
>>>>> | DEBUG: Executing shell function do_configure
>>>>> | waf [commands] [options]
>>>>> |
>>>>> | Main commands (example: ./waf build -j4)
>>>>> | build: executes the build
>>>>> | clean: cleans the project
>>>>> | configure: configures the project
>>>>> | dist : makes a tarball for redistributing the sources
>>>>> | distcheck: checks if the project compiles (tarball from 'dist')
>>>>> | distclean: removes the build directory
>>>>> | install : installs the targets on the system
>>>>> | list : lists the targets to execute
>>>>> | step : executes tasks in a step-by-step fashion, for debugging
>>>>> | uninstall: removes the targets installed
>>>>> | update : updates the plugins from the *waflib/extras* directory
>>>>> |
>>>>> | waf: error: no such option: --bindir
>>>>>
>>>> Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific.
>>>>
>>>> It seems bindir/libdir got added in 1.8 series:
>>>> https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py
>>>>
>>>> Make version specific variables?
>>>
>>> That neatly shows where the "clever code" that was breaking libdir earlier
>>> is:
>>>
>>> https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0ab003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237
>>>
>>
>> Yeah that seems to be it.
>>
>> That go added in the 1.8.6 dev cycle afaik.
>>
>> I am thinking about adding some kind of version autodetection
>>
>> WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-9]*
>> (.*//};q')
>>
>> if [ $WAFMINOR -gt "7" ] ...
>>
>> Maybe there is a nicer way of doing this?
>
> What about we provide a package waf version and replace the binaries
> prior building? So we know what version we'd be using. Kinda
> autoreconf run in autotools class.
Waf seems to be extensible using wscript. I don't know how exactly
wscript depends on waf (version) and whether the API is considered
stable...
I'd rather prefer not taking chances...
--
Stefan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir
On 2017-12-12 15:13, Burton, Ross wrote:
> On 12 December 2017 at 14:03, Stefan Agner wrote:
>
>> On 2017-12-12 15:00, Burton, Ross wrote:
>>
>>> On 12 December 2017 at 13:27, Stefan Agner wrote:
>>>
>>>> On some build hosts distros (e.g. Fedora 26) waf tries to be
>>>> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
>>>> This obviously is not what we want for 32-bit targets and usually
>>>> fails in the do_package phase:
>>>> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
>>>> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped
>>>> in any package:
>>>> /usr/lib64/libgstimxcommon.so.0
>>>>
>>>> Waf knows prefix, bindir and libdir as default options. Explicitly
>>>> pass those three.
>>>
>>> Obviously not.
>>>
>>> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure
>>> (log file is located at
>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
>>> ERROR: Logfile of failure stored in:
>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
>>> Log data follows:
>>> | DEBUG: Executing shell function do_configure
>>> | waf [commands] [options]
>>> |
>>> | Main commands (example: ./waf build -j4)
>>> | build: executes the build
>>> | clean: cleans the project
>>> | configure: configures the project
>>> | dist : makes a tarball for redistributing the sources
>>> | distcheck: checks if the project compiles (tarball from 'dist')
>>> | distclean: removes the build directory
>>> | install : installs the targets on the system
>>> | list : lists the targets to execute
>>> | step : executes tasks in a step-by-step fashion, for debugging
>>> | uninstall: removes the targets installed
>>> | update : updates the plugins from the *waflib/extras* directory
>>> |
>>> | waf: error: no such option: --bindir
>>>
>> Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific.
>>
>> It seems bindir/libdir got added in 1.8 series:
>> https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py
>>
>> Make version specific variables?
>
> That neatly shows where the "clever code" that was breaking libdir earlier
> is:
>
> https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0ab003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237
>
>
Yeah that seems to be it.
That go added in the 1.8.6 dev cycle afaik.
I am thinking about adding some kind of version autodetection
WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-9]*
(.*//};q')
if [ $WAFMINOR -gt "7" ] ...
Maybe there is a nicer way of doing this?
--
Stefan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir
On 2017-12-12 15:06, Vincent Prince wrote: > Hi Ross, > > Does it fail with V1? The waf version which comes with eglinfo says it will fail: configure options: -o OUT, --out=OUT build dir for the project -t TOP, --top=TOP src dir for the project --prefix=PREFIX installation prefix [default: '/usr/local/'] --download try to download the tools if missing .. No libdir to be seen. -- Stefan > Best regards, > Vincent > > 2017-12-12 15:00 GMT+01:00 Burton, Ross : > > On 12 December 2017 at 13:27, Stefan Agner wrote: > > On some build hosts distros (e.g. Fedora 26) waf tries to be > smart about libdir detection and defaults to [EXEC_PREFIX/lib64]. > This obviously is not what we want for 32-bit targets and usually > fails in the do_package phase: > WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: > gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in > any package: > /usr/lib64/libgstimxcommon.so.0 > > Waf knows prefix, bindir and libdir as default options. Explicitly > pass those three. > > Obviously not. > > ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure (log > file is located at > /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278) > > ERROR: Logfile of failure stored in: > /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278 > > Log data follows: > | DEBUG: Executing shell function do_configure > | waf [commands] [options] > | > | Main commands (example: ./waf build -j4) > | build: executes the build > | clean: cleans the project > | configure: configures the project > | dist : makes a tarball for redistributing the sources > | distcheck: checks if the project compiles (tarball from 'dist') > | distclean: removes the build directory > | install : installs the targets on the system > | list : lists the targets to execute > | step : executes tasks in a step-by-step fashion, for debugging > | uninstall: removes the targets installed > | update : updates the plugins from the *waflib/extras* directory > | > | waf: error: no such option: --bindir > > Ross > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir
On 2017-12-12 15:00, Burton, Ross wrote: > On 12 December 2017 at 13:27, Stefan Agner wrote: > >> On some build hosts distros (e.g. Fedora 26) waf tries to be >> smart about libdir detection and defaults to [EXEC_PREFIX/lib64]. >> This obviously is not what we want for 32-bit targets and usually >> fails in the do_package phase: >> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: >> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped >> in any package: >> /usr/lib64/libgstimxcommon.so.0 >> >> Waf knows prefix, bindir and libdir as default options. Explicitly >> pass those three. > > Obviously not. > > ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure (log > file is located at > /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278) > > ERROR: Logfile of failure stored in: > /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278 > > Log data follows: > | DEBUG: Executing shell function do_configure > | waf [commands] [options] > | > | Main commands (example: ./waf build -j4) > | build: executes the build > | clean: cleans the project > | configure: configures the project > | dist : makes a tarball for redistributing the sources > | distcheck: checks if the project compiles (tarball from 'dist') > | distclean: removes the build directory > | install : installs the targets on the system > | list : lists the targets to execute > | step : executes tasks in a step-by-step fashion, for debugging > | uninstall: removes the targets installed > | update : updates the plugins from the *waflib/extras* directory > | > | waf: error: no such option: --bindir > Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific. It seems bindir/libdir got added in 1.8 series: https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py Make version specific variables? -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir
From: Stefan Agner
On some build hosts distros (e.g. Fedora 26) waf tries to be
smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
This obviously is not what we want for 32-bit targets and usually
fails in the do_package phase:
WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in
any package:
/usr/lib64/libgstimxcommon.so.0
Waf knows prefix, bindir and libdir as default options. Explicitly
pass those three.
Signed-off-by: Stefan Agner
---
meta/classes/waf.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/waf.bbclass b/meta/classes/waf.bbclass
index c4698e910a..d0de6fe729 100644
--- a/meta/classes/waf.bbclass
+++ b/meta/classes/waf.bbclass
@@ -26,7 +26,7 @@ def get_waf_parallel_make(d):
return ""
waf_do_configure() {
- ${S}/waf configure --prefix=${prefix} ${EXTRA_OECONF}
+ ${S}/waf configure --prefix=${prefix} --bindir=${bindir}
--libdir=${libdir} ${EXTRA_OECONF}
}
waf_do_compile() {
--
2.13.6
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
