[meta-oe][PATCH 0/4] native cryptsetup and fuse

[meta-oe][PATCH 0/4] native cryptsetup and fuse

[Patrick Ohly]

I have some experimental code which enables dm-verity integrity
protection in an image. This relies on cryptsetup-native and thus
lvm2-native.

swtpm-native (in its current form - if time permits I hope to modify
it so that it works without CUSE) needs fuse-native.

While (accidentally) building the old lvm2 2.02.138 I noticed a build
error; let's remove it.

Patrick Ohly (4):
  lvm2: remove unbuildable 2.02.138
  fuse: support native compilation
  lvm2: enable native compilation
  cryptsetup: enable native compilation

 meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb    |  6 +-
 meta-oe/recipes-support/cryptsetup/cryptsetup_1.7.2.bb |  2 +-
 meta-oe/recipes-support/lvm2/lvm2.inc                  | 28 +++++++++--
 meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb          |  4 +--
 meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb          |  2 +-
 5 files changed, 31 insertions(+), 11 deletions(-)
 delete mode 100644 meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb

base-commit: c162c9102881ae97772e56ca779ffedbc445aca0
-- 
git-series 0.9.1

[meta-oe][PATCH 1/4] lvm2: remove unbuildable 2.02.138

[Patrick Ohly]

The patches defined in lvm2.inc no longer apply cleanly to 2.02.138
and as no-one has complained, the old version is probably obsolete
and can be removed.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb | 4 ----
 1 file changed, 4 deletions(-)
 delete mode 100644 meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb

diff --git a/meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb b/meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb
deleted file mode 100644
index 13a866e..0000000
--- a/meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb
+++ /dev/null
@@ -1,4 +0,0 @@
-require lvm2.inc
-
-SRC_URI[md5sum] = "c660e02ad4586a1d297b6befbe85556d"
-SRC_URI[sha256sum] = "93878a4ba4f70d9f2d0d919eb85bc51652a58776b5428ec8e7e32769d332f596"
-- 
git-series 0.9.1

[meta-oe][PATCH 2/4] fuse: support native compilation

[Patrick Ohly]

This is required for swtpm-native (from meta-security) and
simulating a virtual TPM in qemu. Right now, accessing
swtpm only works via CUSE and thus needs fuse.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb b/meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb
index 8cc6dbd..9a2dc11 100644
--- a/meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb
+++ b/meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb
@@ -30,9 +30,9 @@ DEPENDS = "gettext-native"
 PACKAGES =+ "fuse-utils-dbg fuse-utils libulockmgr libulockmgr-dev libulockmgr-dbg"
 
 # Fusermount requires features from the util-linux version of mount.
-RDEPENDS_${PN} += "util-linux-mount"
+RDEPENDS_${PN}_class-target += "util-linux-mount"
 
-RRECOMMENDS_${PN} = "kernel-module-fuse libulockmgr fuse-utils"
+RRECOMMENDS_${PN}_class-target = "kernel-module-fuse libulockmgr fuse-utils"
 
 FILES_${PN} += "${libdir}/libfuse.so.*"
 FILES_${PN}-dev += "${libdir}/libfuse*.la"
@@ -62,3 +62,5 @@ do_install_append() {
         install -m 0644 ${WORKDIR}/fuse.conf ${D}${sysconfdir}/modules-load.d
     fi
 }
+
+BBCLASSEXTEND = "native nativesdk"
-- 
git-series 0.9.1

[meta-oe][PATCH 3/4] lvm2: enable native compilation

[Patrick Ohly]

Required for cryptsetup-native, which useful for setting up dm-verity
during a build.

"native-sdk" gets added just in case that this may also be used in an
SDK.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 meta-oe/recipes-support/lvm2/lvm2.inc         | 28 ++++++++++++++++----
 meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb |  2 +-
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc b/meta-oe/recipes-support/lvm2/lvm2.inc
index 7bd26c0..333223a 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -1,6 +1,6 @@
 SECTION = "utils"
 DESCRIPTION = "LVM2 is a set of utilities to manage logical volumes in Linux."
-DEPENDS = "udev"
+DEPENDS_append_class-target = " udev"
 LICENSE = "GPLv2 & LGPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=12713b4d9386533feeb07d6e4831765a \
                     file://COPYING.LIB;md5=fbc093901857fcd118f065f900982c24"
@@ -16,11 +16,20 @@ S = "${WORKDIR}/LVM2.${PV}"
 
 inherit autotools-brokensep pkgconfig systemd
 
-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)} \
+PACKAGECONFIG_class-target ??= " \
+                   ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)} \
                    thin-provisioning-tools \
                    odirect \
 "
 
+# odirect is enabled by default also for native compilation because
+# there's currently a bug in lib/device/dev-io.c which prevents
+# compiling without it. It is better to stick to configurations that
+# were actually tested by upstream...
+PACKAGECONFIG ??= " \
+                   odirect \
+"
+
 PACKAGECONFIG[readline] = "--enable-readline,--disable-readline,readline"
 PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux"
 PACKAGECONFIG[thin-provisioning-tools] = "--with-thin=internal,--with-thin=none,,thin-provisioning-tools"
@@ -32,12 +41,9 @@ EXTRA_OECONF = "--with-user= \
                 --enable-realtime \
                 --enable-applib \
                 --enable-cmdlib \
-                --enable-udev_sync \
-                --enable-udev_rules \
                 --enable-pkgconfig \
                 --enable-dmeventd \
                 --enable-lvmetad \
-                --with-udev-prefix= \
                 --with-usrlibdir=${libdir} \
                 --with-systemdsystemunitdir=${systemd_system_unitdir} \
                 --disable-thin_check_needs_check \
@@ -45,12 +51,24 @@ EXTRA_OECONF = "--with-user= \
                 --with-thin-dump=${sbindir}/thin_dump \
                 --with-thin-repair=${sbindir}/thin_repair \
                 --with-thin-restore=${sbindir}/thin_restore \
+                ${EXTRA_OECONF_UDEV} \
+"
+
+EXTRA_OECONF_UDEV = " \
+                --disable-udev_sync \
+                --disable-udev_rules \
+"
+EXTRA_OECONF_UDEV_class-target = " \
+                --enable-udev_sync \
+                --enable-udev_rules \
+                --with-udev-prefix= \
 "
 
 CACHED_CONFIGUREVARS += "MODPROBE_CMD=${base_sbindir}/modprobe"
 
 do_install_append() {
     # Install machine specific configuration file
+    install -d ${D}${sysconfdir}/lvm
     install -m 0644 ${WORKDIR}/lvm.conf ${D}${sysconfdir}/lvm/lvm.conf
     sed -i -e 's:@libdir@:${libdir}:g' ${D}${sysconfdir}/lvm/lvm.conf
     if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
diff --git a/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb b/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb
index 8476b01..6983bca 100644
--- a/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb
+++ b/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb
@@ -4,3 +4,5 @@ SRC_URI[md5sum] = "c5a54ee0b86703daaad6e856439e115a"
 SRC_URI[sha256sum] = "e120b066b85b224552efda40204488c5123de068725676fd6e5c8bc655051b94"
 
 DEPENDS += "autoconf-archive"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
git-series 0.9.1

[meta-oe][PATCH 4/4] cryptsetup: enable native compilation

[Patrick Ohly]

Useful for setting up dm-verity during a build.

"native-sdk" gets added just in case that this may also be used in an
SDK.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 meta-oe/recipes-support/cryptsetup/cryptsetup_1.7.2.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-oe/recipes-support/cryptsetup/cryptsetup_1.7.2.bb b/meta-oe/recipes-support/cryptsetup/cryptsetup_1.7.2.bb
index d560625..38470ac 100644
--- a/meta-oe/recipes-support/cryptsetup/cryptsetup_1.7.2.bb
+++ b/meta-oe/recipes-support/cryptsetup/cryptsetup_1.7.2.bb
@@ -32,3 +32,5 @@ RRECOMMENDS_${PN} = "kernel-module-aes-generic \
 "
 
 EXTRA_OECONF = "--enable-static"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
git-series 0.9.1

Re: [meta-oe][PATCH 1/4] lvm2: remove unbuildable 2.02.138

[Khem Raj]

Can you check if this is the last gpl2 version


On Wed, Feb 8, 2017 at 1:39 AM Patrick Ohly <patrick.ohly@intel.com> wrote:

> The patches defined in lvm2.inc no longer apply cleanly to 2.02.138
> and as no-one has complained, the old version is probably obsolete
> and can be removed.
>
> Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
> ---
>  meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb | 4 ----
>  1 file changed, 4 deletions(-)
>  delete mode 100644 meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb
>
> diff --git a/meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb
> b/meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb
> deleted file mode 100644
> index 13a866e..0000000
> --- a/meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -require lvm2.inc
> -
> -SRC_URI[md5sum] = "c660e02ad4586a1d297b6befbe85556d"
> -SRC_URI[sha256sum] =
> "93878a4ba4f70d9f2d0d919eb85bc51652a58776b5428ec8e7e32769d332f596"
> --
> git-series 0.9.1
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

Re: [meta-oe][PATCH 1/4] lvm2: remove unbuildable 2.02.138

[Patrick Ohly]

On Wed, 2017-02-08 at 20:21 +0000, Khem Raj wrote:
> Can you check if this is the last gpl2 version

According to the recipe, both 2.02.138 and 2.02.166 are under LICENSE =
"GPLv2 & LGPLv2", and that also seems to be what the current code is
licensed under: https://git.fedorahosted.org/cgit/lvm2.git/tree/

So GPLv2 vs. GPLv3 wasn't the reason for keeping the old version.

BTW, do all mails from openembedded-devel have Reply-To:
<openembedded-devel@lists.openembedded.org> set? openembedded-core
doesn't seem to have that.

I have a mail filter in place which will bring personal replies to my
attention sooner, but Reply-To to the list defeats that.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [meta-oe][PATCH 1/4] lvm2: remove unbuildable 2.02.138

[Khem Raj]

On Thu, Feb 9, 2017 at 9:11 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Wed, 2017-02-08 at 20:21 +0000, Khem Raj wrote:
>> Can you check if this is the last gpl2 version
>
> According to the recipe, both 2.02.138 and 2.02.166 are under LICENSE =
> "GPLv2 & LGPLv2", and that also seems to be what the current code is
> licensed under: https://git.fedorahosted.org/cgit/lvm2.git/tree/
>
> So GPLv2 vs. GPLv3 wasn't the reason for keeping the old version.
>

Thanks for confirming.

> BTW, do all mails from openembedded-devel have Reply-To:
> <openembedded-devel@lists.openembedded.org> set? openembedded-core
> doesn't seem to have that.

yeah I guess reply-all will send to all but I never tried that
>
> I have a mail filter in place which will bring personal replies to my
> attention sooner, but Reply-To to the list defeats that.
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Reply-To (was: Re: [meta-oe][PATCH 1/4] lvm2: remove unbuildable 2.02.138)

[Patrick Ohly]

On Thu, 2017-02-09 at 09:17 -0800, Khem Raj wrote:
> On Thu, Feb 9, 2017 at 9:11 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > BTW, do all mails from openembedded-devel have Reply-To:
> > <openembedded-devel@lists.openembedded.org> set? openembedded-core
> > doesn't seem to have that.
> 
> yeah I guess reply-all will send to all but I never tried that

Depends on the client, but typically "Reply-To" sends a very strong
message that the only intended reply is to the given address. For
example, I always do group-reply in Evolution, and for this list it only
picks the list address, as it should.

See
http://www.unicom.com/pw/reply-to-harmful.html

Does anyone remember why the list is set up this way?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [meta-oe][PATCH 1/4] lvm2: remove unbuildable 2.02.138

[Martin Jansa]

It seems to be buildable when you add:

EXTRA_OECONF += "--disable-selinux \
                 --with-cluster=none \
                "
at least that's what one of my .bbappends does.

On Thu, Feb 9, 2017 at 6:17 PM, Khem Raj <raj.khem@gmail.com> wrote:

> On Thu, Feb 9, 2017 at 9:11 AM, Patrick Ohly <patrick.ohly@intel.com>
> wrote:
> > On Wed, 2017-02-08 at 20:21 +0000, Khem Raj wrote:
> >> Can you check if this is the last gpl2 version
> >
> > According to the recipe, both 2.02.138 and 2.02.166 are under LICENSE =
> > "GPLv2 & LGPLv2", and that also seems to be what the current code is
> > licensed under: https://git.fedorahosted.org/cgit/lvm2.git/tree/
> >
> > So GPLv2 vs. GPLv3 wasn't the reason for keeping the old version.
> >
>
> Thanks for confirming.
>
> > BTW, do all mails from openembedded-devel have Reply-To:
> > <openembedded-devel@lists.openembedded.org> set? openembedded-core
> > doesn't seem to have that.
>
> yeah I guess reply-all will send to all but I never tried that
> >
> > I have a mail filter in place which will bring personal replies to my
> > attention sooner, but Reply-To to the list defeats that.
> >
> > --
> > Best Regards, Patrick Ohly
> >
> > The content of this message is my personal opinion only and although
> > I am an employee of Intel, the statements I make here in no way
> > represent Intel's position on the issue, nor am I authorized to speak
> > on behalf of Intel on this matter.
> >
> >
> >
> > --
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

Re: [meta-oe][PATCH 1/4] lvm2: remove unbuildable 2.02.138

[Patrick Ohly]

On Sat, 2017-02-11 at 00:15 +0100, Martin Jansa wrote:
> It seems to be buildable when you add:
> 
> EXTRA_OECONF += "--disable-selinux \
>                  --with-cluster=none \
>                 "
> at least that's what one of my .bbappends does.

That's odd, for me it is do_patch which fails already, i.e. configure
arguments aren't even used:

ERROR: lvm2-2.02.138-r0 do_patch: Command Error: 'quilt
--quiltrc /fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/lvm2/2.02.138-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0  Output:
Applying patch 0001-implement-libc-specific-reopen_stream.patch
patching file lib/log/log.c
Hunk #1 FAILED at 161.
Hunk #2 succeeded at 209 with fuzz 2 (offset 2 lines).
1 out of 2 hunks FAILED -- rejects in file lib/log/log.c
patching file tools/lvmcmdline.c
Hunk #1 succeeded at 1744 (offset -74 lines).
Hunk #2 succeeded at 1754 (offset -74 lines).
Hunk #3 succeeded at 1762 (offset -74 lines).
Patch 0001-implement-libc-specific-reopen_stream.patch does not apply
(enforce with -f)
ERROR: lvm2-2.02.138-r0 do_patch: Function failed: patch_do_patch
ERROR: Logfile of failure stored
in: /fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/lvm2/2.02.138-r0/temp/log.do_patch.2472
ERROR: Task
(/work/iot-ref-kit//meta-openembedded/meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb:do_patch) failed with exit code '1'

Perhaps that is one of those cases where it depends on the native patch
tool whether patching still works?

Anyway, the changes that I'd like to see merged are the others. So if
there's no consensus that 2.02.138 can and/or should be removed, let's
keep it.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.