Re: [oe] Splitting meta-oe?

[Patrick Ohly]

On Thu, 2018-02-22 at 07:53 +0100, Jonas Bonn wrote:
> On 21 February 2018 at 15:09, Martin Hundebøll <m...@prevas.dk>
> wrote:
> 
> > Now that the discussion branched out a bit...
> > 
> > We would like better support for this too. Our setup uses a
> > "manifest"
> > repository with git submodules to setup the layers:
> > 
> > > yocto/
> > >   meta-poky/
> > >   meta-qt5/
> > >   meta-foo/
> > >   meta-bar/
> > >   conf/
> > >    bblayers.conf
> > >    local.conf
> > >   .gitmodules
> > 
> > With this setup, customers simply need to clone our yocto repo
> > recursively, run `yocto/meta-poky/oe-init-build-env yocto` and then
> > `bitbake image-recipe`.
> > 
> > But this is rather inflexible, as it requires the "yocto" folder to
> > be the
> > build folder to activate the config files...
> > 
> > We looked into putting the configs in "meta-foo/conf/*.conf.sample" 
> > and
> > using TEMPLATECONF, but the "oe-init-build-env" script is rather
> > picky
> > about poky being the "top" directory.
> > 
> > I guess the oe-init-build-env script can be changed to look for
> > .templateconf in any parent folder?
> 
> 
> Putting together a deliverable setup that's easy for the customer to
> get
> started with is a bit tricky.  Here's the approach that's worked well
> for
> me:
> 
> /myproject
> /env<-- script
> /build
> /meta-myproject
> /bitbake
> /oe-core
> /meta-layer1
> /meta-layer2
> 
> env, build, meta-myproject are part of the myproject repo, everything
> else is a submodule.

refkit used the same approach. One thing that I would prefer to do
differently is the location of the submodule: having them in their own
directory would make it more transparent which code is "external" and
which is "internal".

> "env" is a script containing just the following:
> . ./oe-core/oe-init-build-env build/ bitbake/

We ended up with a top-level "oe-init-build-env" wrapper script around
the actual oe-core/oe-init-build-env. That way the repo could be used
the same way as poky. The script sets TEMPLATECONF, so the usual local
build setup happens based on refkit sample files.

-- 
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

Re: [oe] Splitting meta-oe?

[Patrick Ohly]

On Wed, 2018-02-21 at 20:33 +0100, Andreas Oberritter wrote:
> On Wed, 21 Feb 2018 15:58:17 +0100
> Patrick Ohly <patrick.o...@intel.com> wrote:
> > The approach used by meta-freescale works with older releases.
> > BBFILES_DYNAMIC [1] (supported by bitbake 1.36/Yocto 2.4) is a bit
> > more
> > robust.
> > 
> > [1] https://patchwork.openembedded.org/patch/140532/
> > 
> 
> That's interesting. Is it possible to express dependencies on more
> than one layer for a group of recipes with this mechanism?

No, not at the moment.

-- 
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

Re: [oe] Splitting meta-oe?

[Patrick Ohly]

On Tue, 2018-02-20 at 18:52 +, Richard Purdie wrote:
> Even once we do that, we (as in YP) can't send out a clear message
> about what we're testing and users will clone meta-oe and expect
> everything to work. So right now I do have problems trying to get to
> a point where YP can use meta-oe effectively.

We had the same issue in refkit: the bblayers.conf.sample enabled a
large amount of layers, but the distro itself only needed and could
test only a subset of the recipes in those layers.

We solved this with supported-recipes.bbclass [1] and an explicit list
of recipes that were considered part of the distro [2] and thus got
tested. A "bitbake world" only builds those recipes. Users of the
distro could enable additional recipes, but then knew that they were on
their own regarding those.

[1] 
https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/classes/supported-recipes.bbclass
[2] 
https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit/conf/distro/include/refkit-supported-recipes.txt

Note that this mechanism also allowed us to support only a subset of,
for example, OE-core: we settled on systemd as the only supported init
system, so sysvinit wasn't listed as supported. This is something that
cannot realistically be achieved by splitting up layers and/or repos
containing layers.

-- 
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

Re: [oe] Splitting meta-oe?

[Patrick Ohly]

On Wed, 2018-02-21 at 14:14 +, Burton, Ross wrote:
> > But that kind of mechanism seems highly prone to breakage and
> > likely to
> > be highly contentious even if it was shown to be reliable, so it
> > may not
> > get beyond a "that'd be nice" thing for me.
> > 
> > Unless someone else has already implemented it and I'm just not
> > aware of
> > how to use it?  :-)
> > 
> 
> meta-freescale (iirc) does this, conditionally adds
> sub-layers to BBLAYERS based on what other layers are already
> enabled.

The approach used by meta-freescale works with older releases.
BBFILES_DYNAMIC [1] (supported by bitbake 1.36/Yocto 2.4) is a bit more
robust.

[1] https://patchwork.openembedded.org/patch/140532/

-- 
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

Re: [oe] nativesdk-qtbase 5.9.2 C++11 errors with gcc 6.3?

[Patrick Ohly]

On Wed, 2018-01-17 at 12:09 +0100, Patrick Ohly wrote:
> On Tue, 2017-10-03 at 19:45 -0400, Denys Dmytriyenko wrote:
> > Martin, Khem,
> > 
> > Have you tried building Qt 5.9 with gcc 6.3 from oe-core? I'm
> > seeing
> > bunch of 
> > what seems to be C++11 related errors during do_configure of
> > nativesdk-qtbase. 
> > Target qtbase builds fine and switching to gcc 7.2 seems to resolve
> > it as well.
> > 
> > Any ideas or pointers? Thanks!
> > 
> > 
> > Errors are like these:
> > 
> > In file included from
> > ../include/QtCore/5.9.2/QtCore/private/qnumeric_p.h:1:0,
> >  from /OE/master/build/tmp-glibc/work/x86_64-
> > nativesdk-oe-linux/nativesdk-qtbase/5.9.2+gitAUTOINC+73573fce29-
> > r0/git/src/corelib/tools/qarraydata.cpp:42:
> > ../include/QtCore/5.9.2/QtCore/private/../../../../../../git/src/co
> > re
> > lib/global/qnumeric_p.h: In function 'bool
> > qnumeric_std_wrapper::__builtin_isnan(double)':
> > ../include/QtCore/5.9.2/QtCore/private/../../../../../../git/src/co
> > re
> > lib/global/qnumeric_p.h:104:45: error: '__builtin_isnan' is not a
> > member of 'std'
> >  static inline bool isnan(double d) { return std::isnan(d); }
> 
> I'm getting the same error when building qemu 2.8.0 for intel-corei7-
> 64 
> with gcc 6.3.0.
> 
> The reason seems to be that somewhere there's a
>   #define isnan __builtin_isnan
> which doesn't work in C++ because std::__builtin_isnandoes not
> exist.
> 
> I'm still looking for the define... if someone has suggestions, I'm
> all ears.

Seems to be from /usr/include/math.h, which gets included by the
corresponding C++ header /usr/include/c++/6.3.0/cmath.

C++ explicitly states that cmath exposes functionality of math.h inside
the std namespace (https://stackoverflow.com/questions/32606023/when-us
ing-c-headers-in-c-should-we-use-functions-from-std-or-the-global-na),
so the QEMU code is correct.

To me this is starting to look like a bug in the toolchain.

-- 
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

Re: [oe] nativesdk-qtbase 5.9.2 C++11 errors with gcc 6.3?

[Patrick Ohly]

On Tue, 2017-10-03 at 19:45 -0400, Denys Dmytriyenko wrote:
> Martin, Khem,
> 
> Have you tried building Qt 5.9 with gcc 6.3 from oe-core? I'm seeing
> bunch of 
> what seems to be C++11 related errors during do_configure of
> nativesdk-qtbase. 
> Target qtbase builds fine and switching to gcc 7.2 seems to resolve
> it as well.
> 
> Any ideas or pointers? Thanks!
> 
> 
> Errors are like these:
> 
> In file included from
> ../include/QtCore/5.9.2/QtCore/private/qnumeric_p.h:1:0,
>  from /OE/master/build/tmp-glibc/work/x86_64-
> nativesdk-oe-linux/nativesdk-qtbase/5.9.2+gitAUTOINC+73573fce29-
> r0/git/src/corelib/tools/qarraydata.cpp:42:
> ../include/QtCore/5.9.2/QtCore/private/../../../../../../git/src/core
> lib/global/qnumeric_p.h: In function 'bool
> qnumeric_std_wrapper::__builtin_isnan(double)':
> ../include/QtCore/5.9.2/QtCore/private/../../../../../../git/src/core
> lib/global/qnumeric_p.h:104:45: error: '__builtin_isnan' is not a
> member of 'std'
>  static inline bool isnan(double d) { return std::isnan(d); }

I'm getting the same error when building qemu 2.8.0 for intel-corei7-64 
with gcc 6.3.0.

The reason seems to be that somewhere there's a
  #define isnan __builtin_isnan
which doesn't work in C++ because std::__builtin_isnandoes not
exist.

I'm still looking for the define... if someone has suggestions, I'm all
ears.

-- 
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

Re: [oe] [meta-webserver][PATCH] meta-webserver: apache2 allow SYSTEMD_AUTO_ENABLE to be overwritten

[Patrick Ohly]

On Thu, 2017-11-16 at 15:00 -0500, Mark Asselstine wrote:
> On Thursday, November 16, 2017 7:28:06 PM EST Patrick Ohly wrote:
> > On Thu, 2017-11-16 at 10:19 -0500, Mark Asselstine wrote:
> > > The current assignment does not allow a bbappend to be used to
> > > overwrite the SYSTEMD_AUTO_ENABLE value in order to have apache2
> > > auto
> > > start.
> > 
> > Why does SYSTEMD_AUTO_ENABLE_${PN} = "enable" in a apache2_*.bb not
> > work? It works fine for me with wpa-supplicant:
> 
> Sorry. You are correct the bbappend will overwrite it, but this
> requires a bbappend. If this used "?=" you could achieve this in a
> local.conf or similar. 

SYSTEMD_AUTO_ENABLE_pn-wpa-supplicant = "enable" in local.conf also
overrides the = assignment in the .bb file.

> In general if there is a possibility for a value to be desireable to
> overwrite using "?=" makes sense. Thoughts?

I thought the same for a while, but since then I've come around to the
interpretation that for recipe-specific variables, using =? is mostly
just a cosmetic thing. I can't think of a good example where it really
matters in practice.

It's different for global variables which might get set prior to
parsing a recipe (distro config, local.conf). There it makes sense to
not overwrite a potentially existing value.

-- 
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

Re: [oe] [meta-webserver][PATCH] meta-webserver: apache2 allow SYSTEMD_AUTO_ENABLE to be overwritten

[Patrick Ohly]

On Thu, 2017-11-16 at 10:19 -0500, Mark Asselstine wrote:
> The current assignment does not allow a bbappend to be used to
> overwrite the SYSTEMD_AUTO_ENABLE value in order to have apache2 auto
> start.

Why does SYSTEMD_AUTO_ENABLE_${PN} = "enable" in a apache2_*.bb not
work? It works fine for me with wpa-supplicant:

wpa-supplicant_2.6.bb: SYSTEMD_AUTO_ENABLE = "disable"
wpa-supplicant_2.6.bbappend: SYSTEMD_AUTO_ENABLE = "enable"
=> bitbake -e shows "enable"

-- 
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

Re: [oe] [PATCH] bitbake.conf: Add sdl-config to HOSTTOOLS

[Patrick Ohly]

On Tue, 2017-10-03 at 11:40 +0200, Ricardo Ribalda Delgado wrote:
> Without this patch bitbake cannot find sdl-config
> 
> ERROR:  OE-core's config sanity checker detected a potential
> misconfiguration.
> Either fix the cause of this error or at your own risk disable the
> checker (see sanity.conf).
> Following is the list of potential problems / advisories:
> 
> libsdl-native is set to be ASSUME_PROVIDED but sdl-config can't be
> found in PATH. Please either install it, or configure qemu not to
> require sdl.

Making sdl-config available is the wrong solution. See https://bugzilla
.yoctoproject.org/show_bug.cgi?id=11725

-- 
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

[oe] [meta-oe][PATCH] autoconf-archive: move from meta-oe to OE-core

[Patrick Ohly]

This complements the corresponding patch in OE-core.

gnome-common is affected and must be modified together with the move
because of the conflict over who provides ax_code_coverage.m4 and
ax_check_enable_debug.m4. They now come from autoconf-archive in
OE-core.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 meta-oe/recipes-devtools/autoconf-archive/autoconf-archive.inc 
   | 15 ---
 
meta-oe/recipes-devtools/autoconf-archive/autoconf-archive/delete-some-m4-files.patch
 | 23 ---
 meta-oe/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb   
   | 17 -
 meta-oe/recipes-gnome/gnome-common/gnome-common_3.18.0.bb  
   | 11 +++
 4 files changed, 11 insertions(+), 55 deletions(-)
 delete mode 100644 
meta-oe/recipes-devtools/autoconf-archive/autoconf-archive.inc
 delete mode 100644 
meta-oe/recipes-devtools/autoconf-archive/autoconf-archive/delete-some-m4-files.patch
 delete mode 100644 
meta-oe/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb

diff --git a/meta-oe/recipes-devtools/autoconf-archive/autoconf-archive.inc 
b/meta-oe/recipes-devtools/autoconf-archive/autoconf-archive.inc
deleted file mode 100644
index 9684d1f..000
--- a/meta-oe/recipes-devtools/autoconf-archive/autoconf-archive.inc
+++ /dev/null
@@ -1,15 +0,0 @@
-LICENSE = "GPLv3"
-HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/;
-SECTION = "devel"
-
-DEPENDS += "m4-native"
-DEPENDS_class-native = "m4-native gnu-config-native"
-DEPENDS_class-nativesdk = "m4-nativesdk gnu-config-nativesdk"
-
-RDEPENDS_${PN} = "m4 gnu-config gnome-common"
-RDEPENDS_${PN}_class-native = "m4-native gnu-config-native"
-RDEPENDS_${PN}_class-nativesdk = "m4-nativesdk gnu-config-nativesdk"
-
-SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
-
-inherit autotools
diff --git 
a/meta-oe/recipes-devtools/autoconf-archive/autoconf-archive/delete-some-m4-files.patch
 
b/meta-oe/recipes-devtools/autoconf-archive/autoconf-archive/delete-some-m4-files.patch
deleted file mode 100644
index 2aa788b..000
--- 
a/meta-oe/recipes-devtools/autoconf-archive/autoconf-archive/delete-some-m4-files.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-Delete two m4files ax_code_coverage.m4 and ax_check_enable_debug.m4
-to avoid installing conflicts. These two files can be installed by
-gnome-common from oe-core, even if the files in gnmoe-common is
-copied from autoconf-archive(the reason is that the old version
-autoconf-archive don't provide the two files).
-After upgrading to the new version, we need to drop them in meta-oe
-and then set rdepends to gnome-common(oe-core)
-
-Signed-off-by: Zhixiong Chi <zhixiong@windriver.com>
-
-Index: a/configure.ac
-===
 a/configure.ac 2016-09-16 06:00:00.0 +0800
-+++ b/configure.ac 2017-04-18 17:43:05.946290554 +0800
-@@ -19,7 +19,7 @@
- 
- AC_PROG_SED
- 
--M4FILES="m4_esyscmd([echo -n m4/*.m4])"
-+M4FILES="m4_esyscmd([echo -n m4/*.m4 | sed -e 's:m4/ax_code_coverage.m4 
::g'|sed -e 's:m4/ax_check_enable_debug.m4 ::g'])"
- AC_SUBST([M4FILES])
- 
- TEXIFILES="m4_esyscmd([cd m4 && echo -n *.m4 | sed -e 's/\.m4/.texi/g'])"
diff --git 
a/meta-oe/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb 
b/meta-oe/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
deleted file mode 100644
index 561b57b..000
--- a/meta-oe/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
+++ /dev/null
@@ -1,17 +0,0 @@
-require autoconf-archive.inc
-
-
-PARALLEL_MAKE = ""
-
-LICENSE = "GPLv2 & GPLv3"
-LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
-
-SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"
-SRC_URI[sha256sum] = 
"e8f2efd235f842bad2f6938bf4a72240a5e5fcd248e8444335e63beb60fabd82"
-
-SRC_URI += "\
-file://delete-some-m4-files.patch \
-"
-
-EXTRA_OECONF += "ac_cv_path_M4=m4"
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-oe/recipes-gnome/gnome-common/gnome-common_3.18.0.bb 
b/meta-oe/recipes-gnome/gnome-common/gnome-common_3.18.0.bb
index 06f3bb3..b8b9ef1 100644
--- a/meta-oe/recipes-gnome/gnome-common/gnome-common_3.18.0.bb
+++ b/meta-oe/recipes-gnome/gnome-common/gnome-common_3.18.0.bb
@@ -17,4 +17,15 @@ DEPENDS = ""
 FILES_${PN} += "${datadir}/aclocal"
 FILES_${PN}-dev = ""
 
+# ax_code_coverage.m4 and ax_check_enable_debug.m4 are in gnome-common only
+# because older versions of autoconf-archive didn't have them yet. Now they
+# are in autoconf-archive from OE-core. We depend on that below to ensure
+# that recipes which only depend on gnome-common still get them.
+do_install_appen

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

[Patrick Ohly]

On Fri, 2017-06-09 at 19:32 +0200, Patrick Ohly wrote:
> On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote:
> > On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
> > > 
> > > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly <patrick.o...@intel.com>
> > > wrote:
> > > 
> > > On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt wrote:
> > > > My guess is that the problem stems from the fact that
> > > security_flags.inc
> > > > adds -pie (which is a linker flag) to SECURITY_CFLAGS rather
> > > than
> > > > SECURITY_LDFLAGS...
> > > 
> > > I think I've seen that cause problems elsewhere when the
> > > CFLAGS came
> > > after -shared, because then the compiler ended up trying to
> > > produce a
> > > pie executable instead of a shared library.
> > > 
> > > Perhaps we should finally address that in security_flags.inc
> > > instead of
> > > working around it?
> > > 
> > > 
> > > This patch is removing -pie from compiler and linker flags which does
> > > not result in intended behavior for executable when linked they will
> > > not be using -pie
> > 
> > The patch had some syntax errors (fixed version below), but it had the
> > code which adds -pie to TARGET_LDFLAGS when it is in SECURITY_CFLAGS, so
> > conceptually the flag shouldn't get lost entirely.
> > 
> > Are you saying that one cannot rely on TARGET_LDFLAGS being used during
> > linking?
> > 
> > I've tested with m4, and it seems to work okay:
> > 
> > $ grep -w -e -pie 
> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/temp/log.do_compile
> > x86_64-refkit-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse 
> > -msse4.2 
> > --sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot
> >-O2 -pipe -g -feliminate-unused-debug-types 
> > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0=/usr/src/debug/m4/1.4.18-r0
> >  
> > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot-native=
> >  
> > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot=
> >   -fstack-protector-strong -fpie -D_FORTIFY_SOURCE=2 -Wformat 
> > -Wformat-security -Werror=format-security  -Wl,-O1 -Wl,--hash-style=gnu 
> > -Wl,--as-needed -pie -fstack-protector-strong -Wl,-z,relro,-z,now -o m4 
> > m4.o builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o 
> > path.o symtab.o ../lib/libm4.a
> > 
> > $ file 
> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4
> >  
> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4:
> >  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically 
> > linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
> > BuildID[sha1]=f10d0a26299dcb8c5bd0f1c82ed492aea2d8f0ac, stripped
> > 
> > I assume "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB
> > executable" means "pie executable"?
> 
> While I don't think my patch caused -pie to get lost, unfortunately I
> now know that it still doesn't go into the right place in all cases. For
> example, ncurses puts LDFLAGS after -shared, thus triggering the "main
> undefined" error.
> 
> The TOOLCHAIN_OPTIONS that Khem mentioned get appended directly after
> the command, so that seems like a better place for -pie than LDFLAGS.
> It's still a bit odd to pass a linker flag to all compiler invocations,
> including those that do not link, but it might be a pragmatic solution
> that is better than what we have now.
> 
> However, my patch below now causes /usr/lib/libstdc++.a-gdb.py to be
> built for gcc-runtime, which triggers an error:
> 
> ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime:
> Files/directories were installed but not shipped in any package:
>   /usr/lib/libstdc++.a-gdb.py

That's just a minor follow-up error. The real problem is that libstdc
++.so.6.0.22 was not getting built anymore. The expect .py file then is
libstdc++.so.6.0.22-gdb.py.

I'm still unsure about the root cause. Something seems to have gone
wrong when building the toolchain, because gcc-runtime doesn't even have
-pie in the compiler flags. From log.do_configure:

checking whether the x86_

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

[Patrick Ohly]

On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote:
> On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
> > 
> > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly <patrick.o...@intel.com>
> > wrote:
> > 
> > On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt wrote:
> > > My guess is that the problem stems from the fact that
> > security_flags.inc
> > > adds -pie (which is a linker flag) to SECURITY_CFLAGS rather
> > than
> > > SECURITY_LDFLAGS...
> > 
> > I think I've seen that cause problems elsewhere when the
> > CFLAGS came
> > after -shared, because then the compiler ended up trying to
> > produce a
> > pie executable instead of a shared library.
> > 
> > Perhaps we should finally address that in security_flags.inc
> > instead of
> > working around it?
> > 
> > 
> > This patch is removing -pie from compiler and linker flags which does
> > not result in intended behavior for executable when linked they will
> > not be using -pie
> 
> The patch had some syntax errors (fixed version below), but it had the
> code which adds -pie to TARGET_LDFLAGS when it is in SECURITY_CFLAGS, so
> conceptually the flag shouldn't get lost entirely.
> 
> Are you saying that one cannot rely on TARGET_LDFLAGS being used during
> linking?
> 
> I've tested with m4, and it seems to work okay:
> 
> $ grep -w -e -pie 
> tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/temp/log.do_compile
> x86_64-refkit-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse 
> -msse4.2 
> --sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot
>-O2 -pipe -g -feliminate-unused-debug-types 
> -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0=/usr/src/debug/m4/1.4.18-r0
>  
> -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot-native=
>  
> -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot=
>   -fstack-protector-strong -fpie -D_FORTIFY_SOURCE=2 -Wformat 
> -Wformat-security -Werror=format-security  -Wl,-O1 -Wl,--hash-style=gnu 
> -Wl,--as-needed -pie -fstack-protector-strong -Wl,-z,relro,-z,now -o m4 m4.o 
> builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o path.o 
> symtab.o ../lib/libm4.a
> 
> $ file 
> tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4
>  
> tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4:
>  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
> interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
> BuildID[sha1]=f10d0a26299dcb8c5bd0f1c82ed492aea2d8f0ac, stripped
> 
> I assume "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB
> executable" means "pie executable"?

While I don't think my patch caused -pie to get lost, unfortunately I
now know that it still doesn't go into the right place in all cases. For
example, ncurses puts LDFLAGS after -shared, thus triggering the "main
undefined" error.

The TOOLCHAIN_OPTIONS that Khem mentioned get appended directly after
the command, so that seems like a better place for -pie than LDFLAGS.
It's still a bit odd to pass a linker flag to all compiler invocations,
including those that do not link, but it might be a pragmatic solution
that is better than what we have now.

However, my patch below now causes /usr/lib/libstdc++.a-gdb.py to be
built for gcc-runtime, which triggers an error:

ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime:
Files/directories were installed but not shipped in any package:
  /usr/lib/libstdc++.a-gdb.py

That file is not present at all without the patch. If anyone has a clue
about what might be causing that, I'm all ears...

-- 
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

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

[Patrick Ohly]

On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
> 
> On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly <patrick.o...@intel.com>
> wrote:
> 
> On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt wrote:
> > My guess is that the problem stems from the fact that
> security_flags.inc
> > adds -pie (which is a linker flag) to SECURITY_CFLAGS rather
> than
> > SECURITY_LDFLAGS...
> 
> I think I've seen that cause problems elsewhere when the
> CFLAGS came
> after -shared, because then the compiler ended up trying to
> produce a
> pie executable instead of a shared library.
> 
> Perhaps we should finally address that in security_flags.inc
> instead of
> working around it?
> 
> 
> This patch is removing -pie from compiler and linker flags which does
> not result in intended behavior for executable when linked they will
> not be using -pie

The patch had some syntax errors (fixed version below), but it had the
code which adds -pie to TARGET_LDFLAGS when it is in SECURITY_CFLAGS, so
conceptually the flag shouldn't get lost entirely.

Are you saying that one cannot rely on TARGET_LDFLAGS being used during
linking?

I've tested with m4, and it seems to work okay:

$ grep -w -e -pie 
tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/temp/log.do_compile
x86_64-refkit-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 
--sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot
   -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0=/usr/src/debug/m4/1.4.18-r0
 
-fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot-native=
 
-fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot=
  -fstack-protector-strong -fpie -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
-Werror=format-security  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -pie 
-fstack-protector-strong -Wl,-z,relro,-z,now -o m4 m4.o builtin.o debug.o 
eval.o format.o freeze.o input.o macro.o output.o path.o symtab.o 
../lib/libm4.a

$ file 
tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4 
tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4:
 ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
BuildID[sha1]=f10d0a26299dcb8c5bd0f1c82ed492aea2d8f0ac, stripped

I assume "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB
executable" means "pie executable"?

diff --git a/meta/conf/distro/include/security_flags.inc 
b/meta/conf/distro/include/security_flags.inc
index e162abeb3d9..b1781ceab42 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -12,6 +12,9 @@ lcl_maybe_fortify = 
"${@base_conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE
 # Error on use of format strings that represent possible security problems
 SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
 
+# For history reasons and simplicity, -pie is listed here as part of CFLAGS.
+# In practice, it ends up getting used as part of LDFLAGS, as it should
+# be because it is a linker flag.
 SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie ${lcl_maybe_fortify} 
${SECURITY_STRINGFORMAT}"
 SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} 
${SECURITY_STRINGFORMAT}"
 
@@ -94,8 +97,8 @@ SECURITY_STRINGFORMAT_pn-busybox = ""
 SECURITY_STRINGFORMAT_pn-gcc = ""
 SECURITY_STRINGFORMAT_pn-oh-puzzles = ""
 
-TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
-TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
+TARGET_CFLAGS_append_class-target = " ${@ oe.utils.str_filter_out('-pie', 
'${SECURITY_CFLAGS}', d) }"
+TARGET_LDFLAGS_append_class-target = " ${@ oe.utils.str_filter('-pie', 
'${SECURITY_CFLAGS}', d) } ${SECURITY_LDFLAGS}"
 
 SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-strong"
 SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"

-- 
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

[oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

[Patrick Ohly]

On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt wrote:
> My guess is that the problem stems from the fact that security_flags.inc 
> adds -pie (which is a linker flag) to SECURITY_CFLAGS rather than 
> SECURITY_LDFLAGS...

I think I've seen that cause problems elsewhere when the CFLAGS came
after -shared, because then the compiler ended up trying to produce a
pie executable instead of a shared library.

Perhaps we should finally address that in security_flags.inc instead of
working around it?

Here's an untested patch which puts -pie where it belongs in the final
variables, without changing the pie/no pie API:

diff --git a/meta/conf/distro/include/security_flags.inc 
b/meta/conf/distro/include/security_flags.inc
index e162abeb3d9..b7b19355806 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -12,6 +12,9 @@ lcl_maybe_fortify = 
"${@base_conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE
 # Error on use of format strings that represent possible security problems
 SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
 
+# For history reasons and simplicity, -pie is listed here as part of CFLAGS.
+# In practice, it ends up getting used as part of LDFLAGS, as it should
+# be because it is a linker flag.
 SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie ${lcl_maybe_fortify} 
${SECURITY_STRINGFORMAT}"
 SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} 
${SECURITY_STRINGFORMAT}"
 
@@ -94,8 +97,8 @@ SECURITY_STRINGFORMAT_pn-busybox = ""
 SECURITY_STRINGFORMAT_pn-gcc = ""
 SECURITY_STRINGFORMAT_pn-oh-puzzles = ""
 
-TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
-TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
+TARGET_CFLAGS_append_class-target = " ${@ oe.utils.filter_out('-pie', 
'${SECURITY_CFLAGS}') }"
+TARGET_LDFLAGS_append_class-target = " ${@ oe.utils.filter('-pie', 
'${SECURITY_CFLAGS}') } ${SECURITY_LDFLAGS}"
 
 SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-strong"
 SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"

-- 
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

Re: [oe] [OE-core] State of bitbake world, Failed tasks 2017-03-27

[Patrick Ohly]

On Wed, 2017-03-29 at 12:14 +0200, Martin Jansa wrote:
> > Can individual recipes choose to be built using the normal ld?
> 
> 
> 
> yes, see example in:
> meta/recipes-bsp/u-boot/u-boot.inc
> 
> meta/recipes-support/libunwind/libunwind_git.bb

Thanks. I'll try to do something similar.

> but it was working with older binutils, so maybe worth tracking down
> where it got borken.

Before my OE-core fix, it was always using /usr/bin/gcc and thus ld. Now
that it actually uses the compiler intended for the target, it ends up
using gold, which fails.

-- 
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

Re: [oe] [OE-core] State of bitbake world, Failed tasks 2017-03-27

[Patrick Ohly]

On Wed, 2017-03-29 at 11:14 +0200, Martin Jansa wrote:
> On Wed, Mar 29, 2017 at 10:35:23AM +0200, Patrick Ohly wrote:
> > On Wed, 2017-03-29 at 09:23 +0200, Martin Jansa wrote:
> > > INFO: jenkins-job.sh-1.8.19 Complete log available at 
> > > http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.report.20170328_014155.log
> > 
> > That used OE-core 552bd78, if I read this right:
> > 
> > == Tested changes (not included in master yet) - openembedded-core 
> > ==
> > latest upstream commit: 
> > 552bd78 wic: use kernel_dir to find systemd-efi bootloader
> > 
> > > * openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb:do_compile
> > 
> > http://errors.yoctoproject.org/Errors/Details/135202/
> > 
> > "gcc-ar: not found" - that should have been fixed by OE-core 23a12d87a6
> > "fix toolchain selection", which is included in OE-core 552bd78 and thus
> > should have been included in the build.
> > 
> > However, the error above was "Submitted on: 11/03/17 10:13", which was a
> > while ago and in particular before that fix.
> > 
> > Did ovmf really fail in the latest world build?
> 
> The report shows:
> http://errors.yoctoproject.org/Errors/Build/34933/
> which leads to:
> 
> http://errors.yoctoproject.org/Errors/Details/138261/
> Submitted on: 27/03/17 05:31

Got it. I followed the wrong link at some point.

> So yes it failed again, but this time with different error:
> TOPDIR/tmp-glibc/work/i586-oe-linux/ovmf/git-r0/recipe-sysroot-native/usr/bin/i586-oe-linux/../../libexec/i586-oe-linux/gcc/i586-oe-linux/6.3.0/ld:
> internal error in do_layout, at ../../gold/object.cc:1821

Hmm, internal error in gold. Not sure what to do about that :-/

Can individual recipes choose to be built using the normal ld?

-- 
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

Re: [oe] [OE-core] State of bitbake world, Failed tasks 2017-03-27

[Patrick Ohly]

On Wed, 2017-03-29 at 09:23 +0200, Martin Jansa wrote:
> INFO: jenkins-job.sh-1.8.19 Complete log available at 
> http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.report.20170328_014155.log

That used OE-core 552bd78, if I read this right:

== Tested changes (not included in master yet) - openembedded-core ==
latest upstream commit: 
552bd78 wic: use kernel_dir to find systemd-efi bootloader

> * openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb:do_compile

http://errors.yoctoproject.org/Errors/Details/135202/

"gcc-ar: not found" - that should have been fixed by OE-core 23a12d87a6
"fix toolchain selection", which is included in OE-core 552bd78 and thus
should have been included in the build.

However, the error above was "Submitted on: 11/03/17 10:13", which was a
while ago and in particular before that fix.

Did ovmf really fail in the latest world build?

-- 
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

[oe] [meta-oe][PATCH v2 1/2] lvm2: libdevicemapper package needs udev rules and dmsetup

[Patrick Ohly]

Applications like kpartx and cryptsetup were broken by moving only
libdevicemapper itself into a separate package: as a result of that
change, lvm2 was not getting pulled into images anymore although
libdevicemapper depends on dmsetup and udev rules to be fully
functional.

For example, "kpartx -as" started to hang while waiting for the udev
rules to trigger, which is what creates the /dev/mapper/ entries for
the new partitions (see also
https://github.com/docker/docker/issues/22025#issuecomment-243943728).

Putting udev rules and dmsetup also into libdevicemapper is perhaps
counter-intuitive, but necessary to keep the package functioning. A
full lvm2 installation is guaranteed to pull them in, too, both
because of implicit library dependencies and (just to be sure) an
explicit RDEPENDS.

lvm2-native doesn't have packages, so this RDEPENDS must be limited to
the target case.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 3e79552..cfa74d4 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -83,14 +83,17 @@ SYSTEMD_AUTO_ENABLE = "disable"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
-FILES_${PN} += "${libdir}/device-mapper/*.so ${nonarch_base_libdir}/udev"
+FILES_${PN} += "${libdir}/device-mapper/*.so"
 FILES_${PN}-scripts = " \
 ${sbindir}/blkdeactivate \
 ${sbindir}/fsadm \
 ${sbindir}/lvmconf \
 ${sbindir}/lvmdump \
 "
-FILES_libdevmapper = "${libdir}/libdevmapper.so.*"
+# Specified explicitly for the udev rules, just in case that it does not get 
picked
+# up automatically:
+RDEPENDS_${PN}_append_class-target = " libdevmapper"
+FILES_libdevmapper = "${sbindir}/dmsetup ${libdir}/libdevmapper.so.* 
${nonarch_base_libdir}/udev/rules.d"
 FILES_libdevmapper-dev = " \
 ${libdir}/libdevmapper.so \
 ${libdir}/pkgconfig/devmapper.pc \

base-commit: 6c584374a599f6f8d3607f20ecfc13a67ccf1da1
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH v2 2/2] lvm2: fix lvm2-native RRECOMMENDS problem

[Patrick Ohly]

lvm2-native doesn't have packages, so the RRECOMMENDS must be limited
to the target case. This fixes:

ERROR: Nothing RPROVIDES 'lvm2-native-scripts-native' (but 
virtual:native:.../meta-openembedded/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb
 RDEPENDS on or otherwise requires it)

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index cfa74d4..d0be296 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -103,6 +103,6 @@ FILES_libdevmapper-dev = " \
 RDEPENDS_${PN}-scripts = "${PN} (= ${EXTENDPKGV}) bash"
 RDEPENDS_${PN} = " bash"
 RDEPENDS_libdevmapper-dev = "libdevmapper (= ${EXTENDPKGV})"
-RRECOMMENDS_${PN} = "${PN}-scripts (= ${EXTENDPKGV})"
+RRECOMMENDS_${PN}_class-target = "${PN}-scripts (= ${EXTENDPKGV})"
 
 CONFFILES_${PN} += "${sysconfdir}/lvm/lvm.conf"
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH] lvm2: libdevicemapper package needs udev rules and dmsetup

[Patrick Ohly]

Applications like kpartx and cryptsetup were broken by moving only
libdevicemapper itself into a separate package: as a result of that
change, lvm2 was not getting pulled into images anymore although
libdevicemapper depends on dmsetup and udev rules to be fully
functional.

For example, "kpartx -as" started to hang while waiting for the udev
rules to trigger, which is what creates the /dev/mapper/ entries for
the new partitions (see also
https://github.com/docker/docker/issues/22025#issuecomment-243943728).

Putting udev rules and dmsetup also into libdevicemapper is perhaps
counter-intuitive, but necessary to keep the package functioning. A
full lvm2 installation is guaranteed to pull them in, too, both
because of implicit library dependencies and (just to be sure) an
explicit RDEPENDS.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 3e79552..c0fe755 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -83,14 +83,17 @@ SYSTEMD_AUTO_ENABLE = "disable"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
-FILES_${PN} += "${libdir}/device-mapper/*.so ${nonarch_base_libdir}/udev"
+FILES_${PN} += "${libdir}/device-mapper/*.so"
 FILES_${PN}-scripts = " \
 ${sbindir}/blkdeactivate \
 ${sbindir}/fsadm \
 ${sbindir}/lvmconf \
 ${sbindir}/lvmdump \
 "
-FILES_libdevmapper = "${libdir}/libdevmapper.so.*"
+# Specified explicitly for the udev rules, just in case that it does not get 
picked
+# up automatically:
+RDEPENDS_${PN} += "libdevmapper"
+FILES_libdevmapper = "${sbindir}/dmsetup ${libdir}/libdevmapper.so.* 
${nonarch_base_libdir}/udev/rules.d"
 FILES_libdevmapper-dev = " \
 ${libdir}/libdevmapper.so \
 ${libdir}/pkgconfig/devmapper.pc \

base-commit: 6c584374a599f6f8d3607f20ecfc13a67ccf1da1
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 8/8] lvm2: Move libdevmapper to a separate package

[Patrick Ohly]

On Thu, 2017-03-16 at 16:42 +0100, Patrick Ohly wrote:
> On Sat, 2017-02-18 at 03:10 +0100, Peter Kjellerstedt wrote:
> > This allows, e.g., cryptsetup to use libdevmapper without having to
> > pull in all of lvm2.
> 
> I'm experiencing an issue where both kpartx and cryptsetup hang
> infinitely. For kpartx, I traced it down to the lack of dmsetup udev
> rules in the rootfs, the same problem as in
> https://github.com/docker/docker/issues/22025#issuecomment-243943728
> 
> Adding lvm2 to my image fixed it, but that defeats the purpose of this
> patch... ;-}
> 
> Peter, do you know which parts of lvm2 are needed for kpartx
> +libdevicemapper to work correctly? My initial attempt with moving just
> the udev rules to the libdevicemapper packages was either flawed or
> incomplete.

The rules call dmsetup. Moving that also to libdevicemapper works for
me, see below. Shall I submit that as patch?

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index b25d775f1..4804b6fb3 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -83,14 +83,17 @@ SYSTEMD_AUTO_ENABLE = "disable"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
-FILES_${PN} += "${libdir}/device-mapper/*.so ${nonarch_base_libdir}/udev"
+FILES_${PN} += "${libdir}/device-mapper/*.so"
 FILES_${PN}-scripts = " \
 ${sbindir}/blkdeactivate \
 ${sbindir}/fsadm \
 ${sbindir}/lvmconf \
 ${sbindir}/lvmdump \
 "
-FILES_libdevmapper = "${libdir}/libdevmapper.so.*"
+# Specified explicitly for the udev rules, just in case that it does not get 
picked
+# up automatically:
+RDEPENDS_${PN} += "libdevmapper"
+FILES_libdevmapper = "${sbindir}/dmsetup ${libdir}/libdevmapper.so.* 
${nonarch_base_libdir}/udev/rules.d"
 FILES_libdevmapper-dev = " \
 ${libdir}/libdevmapper.so \
 ${libdir}/pkgconfig/devmapper.pc \


-- 
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

Re: [oe] [meta-oe][PATCH 8/8] lvm2: Move libdevmapper to a separate package

[Patrick Ohly]

On Sat, 2017-02-18 at 03:10 +0100, Peter Kjellerstedt wrote:
> This allows, e.g., cryptsetup to use libdevmapper without having to
> pull in all of lvm2.

I'm experiencing an issue where both kpartx and cryptsetup hang
infinitely. For kpartx, I traced it down to the lack of dmsetup udev
rules in the rootfs, the same problem as in
https://github.com/docker/docker/issues/22025#issuecomment-243943728

Adding lvm2 to my image fixed it, but that defeats the purpose of this
patch... ;-}

Peter, do you know which parts of lvm2 are needed for kpartx
+libdevicemapper to work correctly? My initial attempt with moving just
the udev rules to the libdevicemapper packages was either flawed or
incomplete.

-- 
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

Re: [oe] [PATCH] yocto-compat-layer: improve error handling in signature creation

[Patrick Ohly]

On Wed, 2017-03-15 at 10:48 +0100, Patrick Ohly wrote:
> When "bitbake -k -S none world" failed, the error printed by
> yocto-compat-layer.py contained the stack trace multiple times and did not
> contain the stderr output from bitbake, making the error hard to understand
> and debug

Sorry, wrong list. I closed the patch in patchwork, too.

-- 
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

[oe] [PATCH] yocto-compat-layer: improve error handling in signature creation

[Patrick Ohly]

When "bitbake -k -S none world" failed, the error printed by
yocto-compat-layer.py contained the stack trace multiple times and did not
contain the stderr output from bitbake, making the error hard to understand
and debug:

  INFO: ==
  INFO: ERROR: test_signatures (common.CommonCompatLayer)
  INFO: --
  INFO: Traceback (most recent call last):
File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 144, in 
get_signatures
  stderr=subprocess.PIPE)
File "/usr/lib/python3.4/subprocess.py", line 620, in check_output
  raise CalledProcessError(retcode, process.args, output=output)
  subprocess.CalledProcessError: Command 'bitbake -k -S none world' returned 
non-zero exit status 1

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "/fast/work/poky/scripts/lib/compatlayer/cases/common.py", line 51, in 
test_signatures
  curr_sigs = get_signatures(self.td['builddir'], failsafe=True)
File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 149, in 
get_signatures
  raise RuntimeError(msg)
  RuntimeError: Traceback (most recent call last):
File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 144, in 
get_signatures
  stderr=subprocess.PIPE)
File "/usr/lib/python3.4/subprocess.py", line 620, in check_output
  raise CalledProcessError(retcode, process.args, output=output)
  subprocess.CalledProcessError: Command 'bitbake -k -S none world' returned 
non-zero exit status 1

  Loading cache...done.
  Loaded 1328 entries from dependency cache.
  NOTE: Resolving any missing task queue dependencies
  NOTE: Runtime target 'zlib-qat' is unbuildable, removing...
  Missing or unbuildable dependency chain was: ['zlib-qat']
  ...
  Summary: There were 5 ERROR messages shown, returning a non-zero exit code.

The yocto-compat-layer.log was incomplete, it only had the first part
without the command output.

stderr was missing due to stderr=subprocess.PIPE.

Instead of the complicated try/except construct it's better to check
the return code ourselves and raise just a single exception. The
output (both on stderr and in the yocto-compat-layer.log) now is:

  INFO: ==
  INFO: ERROR: test_signatures (common.CommonCompatLayer)
  INFO: --
  INFO: Traceback (most recent call last):
File "/fast/work/poky/scripts/lib/compatlayer/cases/common.py", line 51, in 
test_signatures
  curr_sigs = get_signatures(self.td['builddir'], failsafe=True)
File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 147, in 
get_signatures
  raise RuntimeError(msg)
  RuntimeError: Generating signatures failed. This might be due to some parse 
error and/or general layer incompatibilities.
  Command: bitbake -k -S none world
  Output:
  Loading cache...done.
  Loaded 1328 entries from dependency cache.
  NOTE: Resolving any missing task queue dependencies
  ERROR: Nothing PROVIDES 'qat16' (but 
/fast/work/meta-intel/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb
 DEPENDS on or otherwise requires it)
  ERROR: qat16 was skipped: incompatible with machine qemux86 (not in 
COMPATIBLE_MACHINE)
  ...
  Missing or unbuildable dependency chain was: ['openssl-qat-dev']
  ...
  Summary: There were 5 ERROR messages shown, returning a non-zero exit code.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 scripts/lib/compatlayer/__init__.py | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index b3a166aa9ab..a7eb8625310 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -135,17 +135,15 @@ def get_signatures(builddir, failsafe=False):
 
 sigs = {}
 
-try:
-cmd = 'bitbake '
-if failsafe:
-cmd += '-k '
-cmd += '-S none world'
-output = subprocess.check_output(cmd, shell=True,
-stderr=subprocess.PIPE)
-except subprocess.CalledProcessError as e:
-import traceback
-exc = traceback.format_exc()
-msg = '%s\n%s\n' % (exc, e.output.decode('utf-8'))
+cmd = 'bitbake '
+if failsafe:
+cmd += '-k '
+cmd += '-S none world'
+p = subprocess.Popen(cmd, shell=True,
+ stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+output, _ = p.communicate()
+if p.returncode:
+msg = "Generating signatures failed. This might be due to some parse 
error and/or general layer incompatibilities.\nCommand: %s\nOutput:\n%s" % 
(cmd, output.

[oe] [meta-oe][PATCH] acpica: moved to OE-core

[Patrick Ohly]

This revision of the recipe was moved to OE-core in openemedded-core
commit 020f7ea3aa5 and enhance there since then. It now needs to be
removed here to avoid issues when the older copy from meta-oe gets
picked for building things like ovmf.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 meta-oe/recipes-extended/acpica/acpica_20150515.bb  |  46 +-
 meta-oe/recipes-extended/acpica/acpitests/aapits-linux.patch| 336 +---
 meta-oe/recipes-extended/acpica/acpitests/aapits-makefile.patch |  34 +-
 meta-oe/recipes-extended/acpica/acpitests_20140828.bb   |  35 +-
 meta-oe/recipes-extended/acpica/files/no-werror.patch   |  32 +-
 5 files changed, 483 deletions(-)
 delete mode 100644 meta-oe/recipes-extended/acpica/acpica_20150515.bb
 delete mode 100644 meta-oe/recipes-extended/acpica/acpitests/aapits-linux.patch
 delete mode 100644 
meta-oe/recipes-extended/acpica/acpitests/aapits-makefile.patch
 delete mode 100644 meta-oe/recipes-extended/acpica/acpitests_20140828.bb
 delete mode 100644 meta-oe/recipes-extended/acpica/files/no-werror.patch

diff --git a/meta-oe/recipes-extended/acpica/acpica_20150515.bb 
b/meta-oe/recipes-extended/acpica/acpica_20150515.bb
deleted file mode 100644
index de897e1..000
--- a/meta-oe/recipes-extended/acpica/acpica_20150515.bb
+++ /dev/null
@@ -1,46 +0,0 @@
-SUMMARY = "ACPICA tools for the development and debug of ACPI tables"
-DESCRIPTION = "The ACPI Component Architecture (ACPICA) project provides an \
-OS-independent reference implementation of the Advanced Configuration and \
-Power Interface Specification (ACPI). ACPICA code contains those portions of \
-ACPI meant to be directly integrated into the host OS as a kernel-resident \
-subsystem, and a small set of tools to assist in developing and debugging \
-ACPI tables."
-
-HOMEPAGE = "http://www.acpica.org/;
-SECTION = "console/tools"
-
-LICENSE = "BSD | GPLv2"
-LIC_FILES_CHKSUM = 
"file://generate/unix/readme.txt;md5=204407e197c1a01154a48f6c6280c3aa"
-
-COMPATIBLE_HOST = "(i.86|x86_64|arm|aarch64).*-linux"
-
-DEPENDS = "bison flex"
-
-SRC_URI = "https://acpica.org/sites/acpica/files/acpica-unix2-${PV}.tar.gz \
-file://no-werror.patch \
-"
-SRC_URI[md5sum] = "2bc4a7ccc82de9df9fa964f784ecb29c"
-SRC_URI[sha256sum] = 
"61204ec56d71bc9bfa2ee2ade4c66f7e8541772ac72ef8ccc20b3f339cc96374"
-
-S = "${WORKDIR}/acpica-unix2-${PV}"
-
-EXTRA_OEMAKE = "CC='${CC}' 'OPT_CFLAGS=-Wall'"
-
-do_install() {
-install -D -p -m0755 generate/unix/bin*/iasl ${D}${bindir}/iasl
-install -D -p -m0755 generate/unix/bin*/acpibin ${D}${bindir}/acpibin
-install -D -p -m0755 generate/unix/bin*/acpiexec ${D}${bindir}/acpiexec
-install -D -p -m0755 generate/unix/bin*/acpihelp ${D}${bindir}/acpihelp
-install -D -p -m0755 generate/unix/bin*/acpinames ${D}${bindir}/acpinames
-install -D -p -m0755 generate/unix/bin*/acpisrc ${D}${bindir}/acpisrc
-install -D -p -m0755 generate/unix/bin*/acpixtract ${D}${bindir}/acpixtract
-}
-
-# iasl*.bb is a subset of this recipe, so RREPLACE it
-PROVIDES = "iasl"
-RPROVIDES_${PN} += "iasl"
-RREPLACES_${PN} += "iasl"
-RCONFLIGHTS_${PN} += "iasl"
-
-NATIVE_INSTALL_WORKS = "1"
-BBCLASSEXTEND = "native"
diff --git a/meta-oe/recipes-extended/acpica/acpitests/aapits-linux.patch 
b/meta-oe/recipes-extended/acpica/acpitests/aapits-linux.patch
deleted file mode 100644
index 7c5d6b0..000
--- a/meta-oe/recipes-extended/acpica/acpitests/aapits-linux.patch
+++ /dev/null
@@ -1,336 +0,0 @@
-From: Al Stone <a...@ahs3.net>
-Date: Mon, 7 Apr 2014 19:09:37 +
-Subject: [PATCH 1/2] Fixup aapits build
-
-From http://git.linaro.org/people/al.stone/acpica-tools.git
-Upstream-status: Unknown
-
-diff -urN acpica-unix2-20130626/tests/aapits/atexec.c 
acpica-unix2-20130626-aapits/tests/aapits/atexec.c
 acpica-unix2-20130626/tests/aapits/atexec.c2013-01-17 
12:48:28.0 -0700
-+++ acpica-unix2-20130626-aapits/tests/aapits/atexec.c 2013-07-25 
13:44:23.023894441 -0600
-@@ -639,6 +639,7 @@
- }
- 
- 
-+#if ACPI_MACHINE_WIDTH == 32
- 
/***
-  *
-  * FUNCTION:AtBuildLocalRSDT
-@@ -757,8 +758,9 @@
- LocalRSDT->Header.Checksum = (UINT8)~LocalRSDT->Header.Checksum;
- }
- }
-+#endif
- 
- 
- 
/***
-  *
-  * FUNCTION:AtBuildLocalXSDT
-@@ -1424,7 +1426,7 @@
- ACPI_WARNING ((AE_INFO,
- "Request on [%4.4s] is beyond region limit Req-%X+%X, Base=%X, 
Len-%X\n",
- (RegionObject->Region.Node)->Name.Ascii, (UINT32) Address,
--ByteWidth, (UINT32) BufferAddress, Length));
-+ByteWidth, (UINT32) BufferAddress, (UINT32) L

Re: [oe] [OE-core] Patchwork not picking changes from the ML

[Patrick Ohly]

On Wed, 2017-02-22 at 15:56 -0600, Jose Lamego wrote:
> 
> On 02/22/2017 02:55 PM, Michael Halstead wrote:
> > I've seen several issues with hooks. I was working on them yesterday and
> > will continue today.
> > 
> > These are currently managed by hand but we are moving them into
> > configuration management which should help keep them working consistently.
> 
> Michael: one syntax error in patchwork code was pulled into production
> yesterday. This is the cause for missing patches. The error is fixed in
> the Yocto repo now, please perform a server code update ASAP.
> 
> Martin: I will look at the UI issue you are describing and file a bug if
> needed.

Would it perhaps make sense to reply to the original author with an
email confirming that his patch is now in Patchwork? It should include a
link to the patch series, too.

This could have several advantages:
  * submitters not aware of Patchwork or whether their target
currently uses it learn about it and then can follow the
progress of their patch
  * everyone gets a confirmation that the submission made it through
the various mail servers and Patchwork itself

It still relies on the original submitter to watch out for breakages in
the processes, but I guess that can't be avoided with an asynchronous,
mail-based process.

-- 
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

[oe] [meta-oe][PATCH v2] multipath-tools: fix ARM build failure

[Patrick Ohly]

Updating to 0.6.4 introduced a build failure on ARM when thumb was
enabled because of the embedded valgrind.h macro calls. The easiest
solution and thus the one used here is to disable thumb for this
particular recipe for affected machines.

The more elaborate solution would be to patch the macro calls out of
the code when compiling for ARM with thumb.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb | 10 +--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb 
b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
index 6706bec..effd92e 100644
--- a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
+++ b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
@@ -27,6 +27,14 @@ PV = "0.6.4+git${@'${SRCPV}'.split('+')[-1]}"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
+# multipath-tools includes a copy of the valgrind.h header
+# file and uses the macros to suppress some false positives. However,
+# that only works on ARM when thumb is disabled. Otherwise one gets:
+#   Error: shifts in CMP/MOV instructions are only supported in unified syntax 
-- `mov r12,r12,ror#3'
+#   ../Makefile.inc:66: recipe for target 'debug.o' failed
+ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
+
 # The exact version of SYSTEMD does not matter but should be greater than 209.
 #
 EXTRA_OEMAKE = 'MULTIPATH_VERSION=${PV} DESTDIR=${D} syslibdir=${base_libdir} \
@@ -59,5 +67,3 @@ FILES_kpartx = "${base_sbindir}/kpartx \
"
 
 RDEPENDS_${PN} += "kpartx"
-
-PNBLACKLIST[multipath-tools] ?= "Fails to build with RSS 
http://errors.yoctoproject.org/Errors/Details/130529/;

base-commit: 044e5189549de11b2a94efd29a6009a76162b8f1
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] multipath-tools: fix ARM build failure

[Patrick Ohly]

On Thu, 2017-02-16 at 02:42 -0800, Andre McCurdy wrote:
> On Thu, Feb 16, 2017 at 2:29 AM, Patrick Ohly <patrick.o...@intel.com> wrote:
> > Updating to 0.6.4 introduced a build failure on ARM when thumb was
> > enabled because of the embedded valgrind.h macro calls. The easiest
> > solution and thus the one used here is to disable thumb for this
> > particular recipe.
> >
> > The more elaborate solution would be to patch the macro calls out of
> > the code when compiling for ARM with thumb.
> >
> > Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
> > ---
> >  meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb |  9 +--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb 
> > b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
> > index 6706bec..a3b33b6 100644
> > --- a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
> > +++ b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
> > @@ -27,6 +27,13 @@ PV = "0.6.4+git${@'${SRCPV}'.split('+')[-1]}"
> >
> >  TARGET_CC_ARCH += "${LDFLAGS}"
> >
> > +# multipath-tools includes a copy of the valgrind.h header
> > +# file and uses the macros to suppress some false positives. However,
> > +# that only works on ARM when thumb is disabled. Otherwise one gets:
> > +#   Error: shifts in CMP/MOV instructions are only supported in unified 
> > syntax -- `mov r12,r12,ror#3'
> > +#   ../Makefile.inc:66: recipe for target 'debug.o' failed
> > +ARM_INSTRUCTION_SET = "arm"
> 
> Since the problem is presumably Thumb1 specific, you should only force
> the ARM instruction set for ARM cores which don't support Thumb2, ie
> use:
> 
> ARM_INSTRUCTION_SET_armv4 = "arm"
> ARM_INSTRUCTION_SET_armv5 = "arm"

I'm no ARM expert, so I'm not certain which ARM cores are affected, but
I'll follow your suggestion and send a V2 of the patch.

-- 
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

Re: [oe] [meta-swupd][PATCH] swupd-image.bbclass: add missing expand arg in getVars

[Patrick Ohly]

On Tue, 2017-02-14 at 10:20 -0700, Aaron Zinghini wrote:
> Add "True" to d.getVar() to avoid forking a little while longer.
> 
> The expand arg has been set to true by default in master branch and breaks 
> compatibility with branches.

Thanks, applied to master-next (not pushed yet). The right mailing list
for future patches is yo...@yoctoproject.org - I had gotten that wrong
when summarizing the patch submission procedure for you.

-- 
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

[oe] [meta-oe][PATCH] multipath-tools: fix ARM build failure

[Patrick Ohly]

Updating to 0.6.4 introduced a build failure on ARM when thumb was
enabled because of the embedded valgrind.h macro calls. The easiest
solution and thus the one used here is to disable thumb for this
particular recipe.

The more elaborate solution would be to patch the macro calls out of
the code when compiling for ARM with thumb.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb |  9 +--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb 
b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
index 6706bec..a3b33b6 100644
--- a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
+++ b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
@@ -27,6 +27,13 @@ PV = "0.6.4+git${@'${SRCPV}'.split('+')[-1]}"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
+# multipath-tools includes a copy of the valgrind.h header
+# file and uses the macros to suppress some false positives. However,
+# that only works on ARM when thumb is disabled. Otherwise one gets:
+#   Error: shifts in CMP/MOV instructions are only supported in unified syntax 
-- `mov r12,r12,ror#3'
+#   ../Makefile.inc:66: recipe for target 'debug.o' failed
+ARM_INSTRUCTION_SET = "arm"
+
 # The exact version of SYSTEMD does not matter but should be greater than 209.
 #
 EXTRA_OEMAKE = 'MULTIPATH_VERSION=${PV} DESTDIR=${D} syslibdir=${base_libdir} \
@@ -59,5 +66,3 @@ FILES_kpartx = "${base_sbindir}/kpartx \
"
 
 RDEPENDS_${PN} += "kpartx"
-
-PNBLACKLIST[multipath-tools] ?= "Fails to build with RSS 
http://errors.yoctoproject.org/Errors/Details/130529/;

base-commit: 044e5189549de11b2a94efd29a6009a76162b8f1
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH v2][master-next 0/4] python-m2crypto now rdepend on python-typing

[Patrick Ohly]

On Tue, 2017-02-14 at 22:48 +0100, Max Krummenacher wrote:
> For native packages the rdepends do not get automatically installed in the 
> recipe
> specific sysroot.

I'm still not certain whether that RDEPENDS problem is intentional or a
bug which needs to be fixed - see "[OE-core] Does recipe specific
sysrooot (or whatelse in current oe) break native dependencies?"

I don't know how long it might take to resolve this, nor how urgent this
problem is for you, therefore I don't have an opinion whether merging a
(temporary?) workaround is better than waiting.

-- 
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

Re: [oe] multipath-tools on arm (was: Re: [OE-core] State of bitbake world, Failed tasks 2017-02-08)

[Patrick Ohly]

On Tue, 2017-02-14 at 21:06 +0100, Martin Jansa wrote:
> Or you can try to force arm mode for multipath-tools build (by setting
> ARM_INSTRUCTION_SET in the recipe).

That's probably the easiest solution - I'll do that. Thanks for the
hint.

-- 
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

Re: [oe] multipath-tools on arm (was: Re: [OE-core] State of bitbake world, Failed tasks 2017-02-08)

[Patrick Ohly]

On Tue, 2017-02-14 at 19:08 +0100, Martin Jansa wrote:
> Have you tried to reproduce it in qemuarm build after enabling thumb
> in poky?
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9213

No, I haven't. I'm not familiar with the exact configuration of these
tests, and from http://errors.yoctoproject.org/Errors/Details/130529/
it's not obvious that one needs anything besides MACHINE=qemuarm to
replicate the problem.

Bug #9213 doesn't say how thumb can be enabled, and the bug #7717 that
it links to isn't very clear about it either. Ross suggested on IRC:

PREFERRED_ARM_INSTRUCTION_SET ?= "thumb"
ARM_INSTRUCTION_SET = "${PREFERRED_ARM_INSTRUCTION_SET}"

Is that right? Yes, seems to be - using it I can reproduce the problem.

It seems to be a known problem. valgrind is marked as incompatible with
older ARM, so the solution has to be to disable the use of these
valgrind macros. Should I do that unconditionally?

Doing it conditionally would imply copying the logic from valgrind.bb:

# valgrind supports armv7 and above
COMPATIBLE_HOST_armv4 = 'null'
COMPATIBLE_HOST_armv5 = 'null'
COMPATIBLE_HOST_armv6 = 'null'

-- 
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

Re: [oe] multipath-tools on arm (was: Re: [OE-core] State of bitbake world, Failed tasks 2017-02-08)

[Patrick Ohly]

[dropping OE-core mailing list]

On Tue, 2017-02-14 at 16:35 +0100, Patrick Ohly wrote:
> On Fri, 2017-02-10 at 09:28 +0100, Martin Jansa wrote:
> > *
> > meta-openembedded/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb:do_compile
> 
> This is http://errors.yoctoproject.org/Errors/Details/130529/ and now
> blacklisted with the comment "Fails to build with RSS
> http://errors.yoctoproject.org/Errors/Details/130529/;
> 
> However, the error isn't about RSS. It looks like an inline-assembler or
> compiler bug:
> 
> {standard input}: Assembler messages:
> {standard input}:80: Error: shifts in CMP/MOV instructions are only supported 
> in unified syntax -- `mov r12,r12,ror#3'
> {standard input}:80: Error: shifts in CMP/MOV instructions are only supported 
> in unified syntax -- `mov r12,r12,ror#13'
> ...
> ../Makefile.inc:66: recipe for target 'debug.o' failed
> make[1]: *** [debug.o] Error 1
> 
> Does anyone know what this could be? I'll also fire up a build in the
> meantime.

I've not been able to reproduce that error based on current Poky
(OE-Core d1109378d73, bitbake 95deecab, meta-openembedded 044e518954),
neither with DISTRO = "poky" nor without it :-/

Martin, can we try reverting this in meta-openembedded to see whether
the problem comes back?

-- 
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

[oe] multipath-tools on arm (was: Re: [OE-core] State of bitbake world, Failed tasks 2017-02-08)

[Patrick Ohly]

On Fri, 2017-02-10 at 09:28 +0100, Martin Jansa wrote:
> *
> meta-openembedded/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb:do_compile

This is http://errors.yoctoproject.org/Errors/Details/130529/ and now
blacklisted with the comment "Fails to build with RSS
http://errors.yoctoproject.org/Errors/Details/130529/;

However, the error isn't about RSS. It looks like an inline-assembler or
compiler bug:

{standard input}: Assembler messages:
{standard input}:80: Error: shifts in CMP/MOV instructions are only supported 
in unified syntax -- `mov r12,r12,ror#3'
{standard input}:80: Error: shifts in CMP/MOV instructions are only supported 
in unified syntax -- `mov r12,r12,ror#13'
...
../Makefile.inc:66: recipe for target 'debug.o' failed
make[1]: *** [debug.o] Error 1

Does anyone know what this could be? I'll also fire up a build in the
meantime.

-- 
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

Re: [oe] [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.



-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] 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.o...@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.



-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Patrick Ohly]

On Wed, 2017-02-08 at 20:21 +, 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.



-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH] procmail: avoid bashism in do_install

[Patrick Ohly]

Found with verify-bashisms.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 meta-oe/recipes-support/procmail/procmail_3.22.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta-oe/recipes-support/procmail/procmail_3.22.bb 
b/meta-oe/recipes-support/procmail/procmail_3.22.bb
index 1063654..9bbd410 100644
--- a/meta-oe/recipes-support/procmail/procmail_3.22.bb
+++ b/meta-oe/recipes-support/procmail/procmail_3.22.bb
@@ -38,7 +38,8 @@ do_compile() {
 
 do_install() {
 install -d ${D}${bindir}
-install -d ${D}${mandir}/man{1,5}
+install -d ${D}${mandir}/man1
+install -d ${D}${mandir}/man5
 oe_runmake -i BASENAME=${D}/usr MANDIR=${D}${mandir} install
 install -m 0644 debian/mailstat.1 ${D}${mandir}/man1
 }

base-commit: dd0494206e2ad08f5b9e969c94da66fd10c51e9c
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [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.o...@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
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [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.o...@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
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [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.o...@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
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [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.o...@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..000
--- 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

[oe] [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
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Patchwork-Status via email

[Patrick Ohly]

On Tue, 2017-02-07 at 12:32 -0600, Jose Lamego wrote:
> 
> On 02/07/2017 04:59 AM, Patrick Ohly wrote:
> > What about this use case here: the original author wants to retract a
> > patch. Can he do that via email and/or the web interface?
> > 
> Patch submitter (and project maintainers) can update status manually
> through the web interface.

I suspect that this makes the email interface less useful that it could
be. May I suggest that we relax the permission check so that also patch
authors can change the status of a patch?

-- 
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

[oe] Patchwork-Status via email (was: Re: [meta-networking][PATCH] crda: fix build issue do to missing python module)

[Patrick Ohly]

On Tue, 2017-02-07 at 11:25 +0100, Martin Jansa wrote:
> On Tue, Feb 07, 2017 at 08:41:14AM +0100, Patrick Ohly wrote:
> > On Mon, 2017-02-06 at 09:10 -0800, akuster808 wrote:
> > > please drop. this is fixed via a change in master-next.
> > > 
> > > http://cgit.openembedded.org/meta-openembedded/commit/?h=master-next=2e83e33c592543045a7761907d8cd62937e1e60d
> > 
> > Let's see whether the magic keyword works :-)
> > 
> > [Patchwork-Status: Superseded]
> > 
> > https://patchwork.openembedded.org/patch/136794/
> > 
> > -- 
> > 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.
> 
> If it was supposed to update status on Patchwork, then it didn't work
> it's still in "New" state.

Jose, in your "parsemail: Set patch state from email metadata" patch you
said that it "allows project maintainers to change a patch status
directly from an email message".

Can you clarify who the "project maintainers" are who can use this email
interface?

What about this use case here: the original author wants to retract a
patch. Can he do that via email and/or the web interface?

I wasn't the original author and probably also no project maintainer, so
I guess that's why my email had no effect. Can we enable some kind of
error response for such cases?

-- 
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

Re: [oe] [meta-networking][PATCH] crda: fix build issue do to missing python module

[Patrick Ohly]

On Mon, 2017-02-06 at 09:10 -0800, akuster808 wrote:
> please drop. this is fixed via a change in master-next.
> 
> http://cgit.openembedded.org/meta-openembedded/commit/?h=master-next=2e83e33c592543045a7761907d8cd62937e1e60d

Let's see whether the magic keyword works :-)

[Patchwork-Status: Superseded]

https://patchwork.openembedded.org/patch/136794/

-- 
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

Re: [oe] [PATCH] multipath-tools: update to 0.6.4

[Patrick Ohly]

On Mon, 2017-01-30 at 13:18 +0100, Martin Jansa wrote:
> On Fri, Jan 27, 2017 at 11:11:23AM +0100, Patrick Ohly wrote:
> > No particular reason for updating besides following upstream.
> > 
> > Only kpartx has been tested after updating! Seems to work as before;
> > unfortunately that means that as in 0.5.0, "kpartx -d" doesn't do
> > anything.
> > 
> > Upstream refreshed the COPYING file, hence the checksum change:
> > $ git log --oneline 0.5.0..HEAD COPYING
> > bf05f63 multipath-tools: replace COPYING with a fresh copy from gnu.org
> > 1d6c88a Update FSF address
> > 
> > The QA error that do-not-link-libmpathpersist-to-TMPDIR.patch fixes
> > no longer occurs because upstream changed that particular part of
> > the Makefile.
> > 
> > A new patch is needed to avoid building libcheckerrdb, which depends
> > on the (currently) unavailable librados.
> 
> FWIW: it would be even better if you mark
> https://patchwork.openembedded.org/patch/136518/
> as Superseded as patchwork is where I take patches for master-next and I
> need to remember that there was e-mail reply for this one that it should
> be ignored.

Thanks, I'll try to remember that going forward. Would have been a nice
testcase for

[Patchwork-Status: Superseded]

-- 
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

Re: [oe] [PATCH] multipath-tools: update to 0.6.4

[Patrick Ohly]

On Fri, 2017-01-27 at 11:11 +0100, Patrick Ohly wrote:
> No particular reason for updating besides following upstream.

Please ignore. It's a duplicate of the same patch from the patch series.

-- 
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

[oe] [meta-oe][PATCH 1/2] multipath-tools: fix building of shared objects

[Patrick Ohly]

When -pie is in CFLAGS, it overrides the -shared compiler
flag, leading to link errors (undefined main) for shared
objects. Parameters must be ordered so that -shared comes
last.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 
meta-oe/recipes-support/multipath-tools/files/shared-libs-avoid-linking-.so-as-executable.patch
 | 49 +
 meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb 
 |  1 +
 2 files changed, 50 insertions(+)
 create mode 100644 
meta-oe/recipes-support/multipath-tools/files/shared-libs-avoid-linking-.so-as-executable.patch

diff --git 
a/meta-oe/recipes-support/multipath-tools/files/shared-libs-avoid-linking-.so-as-executable.patch
 
b/meta-oe/recipes-support/multipath-tools/files/shared-libs-avoid-linking-.so-as-executable.patch
new file mode 100644
index 000..ae6bb89
--- /dev/null
+++ 
b/meta-oe/recipes-support/multipath-tools/files/shared-libs-avoid-linking-.so-as-executable.patch
@@ -0,0 +1,49 @@
+From 4311856200480288494df8df737f71ea316592d0 Mon Sep 17 00:00:00 2001
+From: Patrick Ohly <patrick.o...@intel.com>
+Date: Thu, 26 Jan 2017 15:28:34 +0100
+Subject: [PATCH] shared libs: avoid linking .so as executable
+
+When the OE build systems sets CFLAGS including -pie, gcc overrides
+the earlier -shared parameter and tries to link a binary, leading to
+errors about missing functions like main().
+
+Reordering the parameters so that -shared comes after CFLAGS
+fixes this.
+
+Upstream-Status: Inappropriate [OE specific, -pie shouldn't be in CFLAGS?!]
+
+Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
+---
+ libmpathpersist/Makefile | 2 +-
+ libmultipath/Makefile| 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libmpathpersist/Makefile b/libmpathpersist/Makefile
+index c4ec1c5..790692a 100644
+--- a/libmpathpersist/Makefile
 b/libmpathpersist/Makefile
+@@ -20,7 +20,7 @@ all: $(LIBS)
+ 
+ $(LIBS): 
+   $(CC) -Wall -fPIC -c $(CFLAGS) *.c 
+-  $(CC)  -shared $(LIBDEPS) -Wl,-soname=$@ $(CFLAGS) -o $@ $(OBJS)
++  $(CC) $(LIBDEPS) $(CFLAGS) $(SHARED_FLAGS) -Wl,-soname=$@ -o $@ $(OBJS)
+   ln -s $(LIBS) $(DEVLIB)
+   $(GZIP) mpath_persistent_reserve_in.3 > 
mpath_persistent_reserve_in.3.gz
+   $(GZIP) mpath_persistent_reserve_out.3 > 
mpath_persistent_reserve_out.3.gz  
+diff --git a/libmultipath/Makefile b/libmultipath/Makefile
+index fc0f3d6..2287d91 100644
+--- a/libmultipath/Makefile
 b/libmultipath/Makefile
+@@ -55,7 +55,7 @@ endif
+ all: $(LIBS)
+ 
+ $(LIBS): $(OBJS)
+-  $(CC) $(LDFLAGS) $(SHARED_FLAGS) -Wl,-soname=$@ $(CFLAGS) -o $@ $(OBJS) 
$(LIBDEPS)
++  $(CC) $(LDFLAGS) $(CFLAGS) $(SHARED_FLAGS) -Wl,-soname=$@ -o $@ $(OBJS) 
$(LIBDEPS)
+   ln -sf $@ $(DEVLIB)
+ 
+ install:
+-- 
+2.11.0
+
diff --git a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb 
b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
index 6bd6118..2ab4dad 100644
--- a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
+++ b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
@@ -11,6 +11,7 @@ SRC_URI = 
"git://git.opensvc.com/multipath-tools/.git;protocol=http \
file://always-use-libdevmapper-kpartx.patch \
file://do-not-link-libmpathpersist-to-TMPDIR.patch \
file://0001-multipathd.service-Error-fix.patch \
+   file://shared-libs-avoid-linking-.so-as-executable.patch \
"
 # 0.5.0
 #
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH 2/2] multipath-tools: update to 0.6.4

[Patrick Ohly]

No particular reason for updating besides following upstream.

Only kpartx has been tested after updating! Seems to work as before;
unfortunately that means that as in 0.5.0, "kpartx -d" doesn't do
anything.

Upstream refreshed the COPYING file, hence the checksum change:
$ git log --oneline 0.5.0..HEAD COPYING
bf05f63 multipath-tools: replace COPYING with a fresh copy from gnu.org
1d6c88a Update FSF address

The QA error that do-not-link-libmpathpersist-to-TMPDIR.patch fixes
no longer occurs because upstream changed that particular part of
the Makefile.

A new patch is needed to avoid building libcheckerrdb, which depends
on the (currently) unavailable librados.

The other patches had to be refreshed.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 
meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
   | 10 +-
 
meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
  | 25 -
 meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper.patch
 | 53 +
 
meta-oe/recipes-support/multipath-tools/files/checkers-disable-libcheckrbd.so.patch
 | 31 +++
 
meta-oe/recipes-support/multipath-tools/files/do-not-link-libmpathpersist-to-TMPDIR.patch
   | 30 --
 meta-oe/recipes-support/multipath-tools/files/makefile_inc.patch   
 | 38 +-
 
meta-oe/recipes-support/multipath-tools/files/shared-libs-avoid-linking-.so-as-executable.patch
 | 44 +---
 meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb 
 | 32 +++-
 8 files changed, 146 insertions(+), 117 deletions(-)
 create mode 100644 
meta-oe/recipes-support/multipath-tools/files/checkers-disable-libcheckrbd.so.patch
 delete mode 100644 
meta-oe/recipes-support/multipath-tools/files/do-not-link-libmpathpersist-to-TMPDIR.patch

diff --git 
a/meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
 
b/meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
index 1e48e1c..60c3c0a 100644
--- 
a/meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
+++ 
b/meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
@@ -1,4 +1,4 @@
-From 74ff5e1cf8ef83dabcf6e6b92f87d6761f7f4d51 Mon Sep 17 00:00:00 2001
+From 630483b9738349c8b3e637a00879b96834a33cdb Mon Sep 17 00:00:00 2001
 From: Li xin <lixin.f...@cn.fujitsu.com>
 Date: Tue, 7 Jul 2015 11:34:36 +0900
 Subject: [PATCH] multipathd.service: Error fix
@@ -13,10 +13,10 @@ Signed-off-by: Li Xin <lixin.f...@cn.fujitsu.com>
  1 file changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/multipathd/multipathd.service b/multipathd/multipathd.service
-index be3ba3f..b8d3ecd 100644
+index e3d6f91..a7e00b2 100644
 --- a/multipathd/multipathd.service
 +++ b/multipathd/multipathd.service
-@@ -6,11 +6,12 @@ DefaultDependencies=no
+@@ -8,11 +8,12 @@ Wants=local-fs-pre.target multipathd.socket 
blk-availability.service
  Conflicts=shutdown.target
  
  [Service]
@@ -25,12 +25,12 @@ index be3ba3f..b8d3ecd 100644
  NotifyAccess=main
  LimitCORE=infinity
 +PIDFile=/var/run/multipathd.pid
- ExecStartPre=/sbin/modprobe dm-multipath
+ ExecStartPre=/sbin/modprobe -a scsi_dh_alua scsi_dh_emc scsi_dh_rdac 
dm-multipath
 -ExecStart=/sbin/multipathd -d -s
 +ExecStart=/sbin/multipathd
  ExecReload=/sbin/multipathd reconfigure
  
  [Install]
 -- 
-1.8.4.2
+2.11.0
 
diff --git 
a/meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
 
b/meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
index a16a854..803e52c 100644
--- 
a/meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
+++ 
b/meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
@@ -1,4 +1,7 @@
-Always use devmapper for kpartx
+From 7267cf235fc052eaa1ca36e437096576edacb131 Mon Sep 17 00:00:00 2001
+From: Aws Ismail <aws.ism...@windriver.com>
+Date: Mon, 22 Sep 2014 17:22:32 -0700
+Subject: [PATCH] Always use devmapper for kpartx
 
 Do not try to compute the LIBDM_API_COOKIE make variable
 from host information when cross-compiling.
@@ -7,23 +10,27 @@ Upstream-Status: Inappropriate [embedded specific]
 
 Signed-off-by: Aws Ismail <aws.ism...@windriver.com>
 Signed-off-by: Joe Slater <joe.sla...@windriver.com>
+---
+ kpartx/Makefile | 6 +-
+ 1 file changed, 1 insertion(+), 5 deletions(-)
 
 diff --git a/kpartx/Makefile b/kpartx/Makefile
-index 2a07334..24bdabc 100644
+index e8a59f2..e694a65 100644
 --- a/kpartx/Makefile
 +++ b/kpartx/Makefile
-@@ -4,13 +4,7 @@
- #
- include 

[oe] [PATCH] multipath-tools: update to 0.6.4

[Patrick Ohly]

No particular reason for updating besides following upstream.

Only kpartx has been tested after updating! Seems to work as before;
unfortunately that means that as in 0.5.0, "kpartx -d" doesn't do
anything.

Upstream refreshed the COPYING file, hence the checksum change:
$ git log --oneline 0.5.0..HEAD COPYING
bf05f63 multipath-tools: replace COPYING with a fresh copy from gnu.org
1d6c88a Update FSF address

The QA error that do-not-link-libmpathpersist-to-TMPDIR.patch fixes
no longer occurs because upstream changed that particular part of
the Makefile.

A new patch is needed to avoid building libcheckerrdb, which depends
on the (currently) unavailable librados.

The other patches had to be refreshed.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 .../files/0001-multipathd.service-Error-fix.patch  | 10 ++--
 .../files/always-use-libdevmapper-kpartx.patch | 25 ++
 .../files/always-use-libdevmapper.patch| 53 ++
 .../files/checkers-disable-libcheckrbd.so.patch| 31 +
 .../do-not-link-libmpathpersist-to-TMPDIR.patch| 30 
 .../multipath-tools/files/makefile_inc.patch   | 38 
 ...ared-libs-avoid-linking-.so-as-executable.patch | 44 ++
 .../multipath-tools/multipath-tools_git.bb | 32 +++--
 8 files changed, 146 insertions(+), 117 deletions(-)
 create mode 100644 
meta-oe/recipes-support/multipath-tools/files/checkers-disable-libcheckrbd.so.patch
 delete mode 100644 
meta-oe/recipes-support/multipath-tools/files/do-not-link-libmpathpersist-to-TMPDIR.patch

diff --git 
a/meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
 
b/meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
index 1e48e1c5f..60c3c0aec 100644
--- 
a/meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
+++ 
b/meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
@@ -1,4 +1,4 @@
-From 74ff5e1cf8ef83dabcf6e6b92f87d6761f7f4d51 Mon Sep 17 00:00:00 2001
+From 630483b9738349c8b3e637a00879b96834a33cdb Mon Sep 17 00:00:00 2001
 From: Li xin <lixin.f...@cn.fujitsu.com>
 Date: Tue, 7 Jul 2015 11:34:36 +0900
 Subject: [PATCH] multipathd.service: Error fix
@@ -13,10 +13,10 @@ Signed-off-by: Li Xin <lixin.f...@cn.fujitsu.com>
  1 file changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/multipathd/multipathd.service b/multipathd/multipathd.service
-index be3ba3f..b8d3ecd 100644
+index e3d6f91..a7e00b2 100644
 --- a/multipathd/multipathd.service
 +++ b/multipathd/multipathd.service
-@@ -6,11 +6,12 @@ DefaultDependencies=no
+@@ -8,11 +8,12 @@ Wants=local-fs-pre.target multipathd.socket 
blk-availability.service
  Conflicts=shutdown.target
  
  [Service]
@@ -25,12 +25,12 @@ index be3ba3f..b8d3ecd 100644
  NotifyAccess=main
  LimitCORE=infinity
 +PIDFile=/var/run/multipathd.pid
- ExecStartPre=/sbin/modprobe dm-multipath
+ ExecStartPre=/sbin/modprobe -a scsi_dh_alua scsi_dh_emc scsi_dh_rdac 
dm-multipath
 -ExecStart=/sbin/multipathd -d -s
 +ExecStart=/sbin/multipathd
  ExecReload=/sbin/multipathd reconfigure
  
  [Install]
 -- 
-1.8.4.2
+2.11.0
 
diff --git 
a/meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
 
b/meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
index a16a85405..803e52c10 100644
--- 
a/meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
+++ 
b/meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
@@ -1,4 +1,7 @@
-Always use devmapper for kpartx
+From 7267cf235fc052eaa1ca36e437096576edacb131 Mon Sep 17 00:00:00 2001
+From: Aws Ismail <aws.ism...@windriver.com>
+Date: Mon, 22 Sep 2014 17:22:32 -0700
+Subject: [PATCH] Always use devmapper for kpartx
 
 Do not try to compute the LIBDM_API_COOKIE make variable
 from host information when cross-compiling.
@@ -7,23 +10,27 @@ Upstream-Status: Inappropriate [embedded specific]
 
 Signed-off-by: Aws Ismail <aws.ism...@windriver.com>
 Signed-off-by: Joe Slater <joe.sla...@windriver.com>
+---
+ kpartx/Makefile | 6 +-
+ 1 file changed, 1 insertion(+), 5 deletions(-)
 
 diff --git a/kpartx/Makefile b/kpartx/Makefile
-index 2a07334..24bdabc 100644
+index e8a59f2..e694a65 100644
 --- a/kpartx/Makefile
 +++ b/kpartx/Makefile
-@@ -4,13 +4,7 @@
- #
- include ../Makefile.inc
+@@ -7,11 +7,7 @@ CFLAGS += -I. -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
+ 
+ LIBDEPS += -ldevmapper
  
--CFLAGS += -I. -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
--
 -LIBDM_API_COOKIE = $(shell grep -Ecs '^[a-z]*[[:space:]]+dm_task_set_cookie' 
/usr/include/libdevmapper.h)
 -
 -ifneq ($(strip $(LIBDM_API_COOKIE)),0)
 -  CFLAGS += -DLIBDM_API_COOKIE
 -endif
-+CFLAGS += -I. -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DLIBDM_API_COOKIE
++CFLAGS += -DLIBDM_API_COOKIE
  
- LDFLAGS = -ldev

[oe] [meta-oe][PATCH 0/2] multipath: fix build and update

[Patrick Ohly]

I recently started using kpartx from multipath-tools. The build failed
for me when linking shared objects as executables. Changing the order
of compiler parameter avoids that (first patch).

I have a problem where "kpartx -d" does not do anything, so I wanted
to try out the latest upstream. Unfortunately, that has the same
issue. 0.5.0 is fairly old, so it may be worthwhile to update the
recipe just for the sake of it.

However, beware that I have done absolutely no testing of anything
besides kpartx! But as the recipe didn't even build, it's probably
currently unused and further testing can be done once someone starts
using it again.

If you disagree, then please at least merge the compile fix.

Patrick Ohly (2):
  multipath-tools: fix building of shared objects
  multipath-tools: update to 0.6.4

 
meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
   | 10 +-
 
meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper-kpartx.patch
  | 25 -
 meta-oe/recipes-support/multipath-tools/files/always-use-libdevmapper.patch
 | 53 +
 
meta-oe/recipes-support/multipath-tools/files/checkers-disable-libcheckrbd.so.patch
 | 31 +++
 
meta-oe/recipes-support/multipath-tools/files/do-not-link-libmpathpersist-to-TMPDIR.patch
   | 30 --
 meta-oe/recipes-support/multipath-tools/files/makefile_inc.patch   
 | 38 +-
 
meta-oe/recipes-support/multipath-tools/files/shared-libs-avoid-linking-.so-as-executable.patch
 | 55 +++
 meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb 
 | 33 -
 8 files changed, 177 insertions(+), 98 deletions(-)
 create mode 100644 
meta-oe/recipes-support/multipath-tools/files/checkers-disable-libcheckrbd.so.patch
 delete mode 100644 
meta-oe/recipes-support/multipath-tools/files/do-not-link-libmpathpersist-to-TMPDIR.patch
 create mode 100644 
meta-oe/recipes-support/multipath-tools/files/shared-libs-avoid-linking-.so-as-executable.patch

base-commit: fa65be9ba7943a68b988b5e1a3a37cda7ac74c37
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java][PATCH] move from bb.data.getVar(x, d, 1) to d.getVar(x, True)

[Patrick Ohly]

On Tue, 2016-11-29 at 13:16 -0700, Christopher Larson wrote:
> On Tue, Nov 29, 2016 at 9:48 AM, Cody P Schafer  wrote:
> 
> > bb.data.getVar was removed, need to use the modern mechanism.
> >
> > Signed-off-by: Cody P Schafer 
> > ---
> >  classes/java-library.bbclass  |  4 ++--
> >  recipes-core/icedtea/icedtea7-native.inc  |  2 +-
> >  recipes-core/openjdk/openjdk-7-common.inc |  2 +-
> >  recipes-core/openjdk/openjdk-8-common.inc | 10 +-
> >  recipes-core/openjdk/openjdk-common.inc   |  6 +++---
> >  5 files changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/classes/java-library.bbclass b/classes/java-library.bbclass
> > index 144cd2f..58d5a40 100644
> > --- a/classes/java-library.bbclass
> > +++ b/classes/java-library.bbclass
> > @@ -23,8 +23,8 @@ def java_package_name(d):
> >pre=""
> >post=""
> >
> > -  bpn = bb.data.getVar('BPN', d, 1)
> > -  ml = bb.data.getVar('MLPREFIX', d, 1)
> > +  bpn = d.getVar('BPN', True)
> > +  ml = d.getVar('MLPREFIX', True)
> >
> 
> If you’re working on master, even the ‘, True’ is no longer needed, FYI.

I suspect that meta-java master is meant to work with more than just
bitbake master, so keeping the parameter makes sense.

I think the change is okay and I'd love to see it merged as soon as
possible. In Ostro OS, updating to bitbake and OE-core master is blocked
by this meta-java incompatibility with bitbake master.

Can someone with commit rights to meta-java please merge it?

Bye, Patrick

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java] icedtea7-native - IOException constructor compile error

[Patrick Ohly]

On Fri, 2016-09-09 at 15:10 +0200, Ricardo Ribalda Delgado wrote:
> I am struggling with te same issue. Did you manage to fix it on your side?

It hasn't happened again. So no, I haven't fixed anything, it just works
now. No-one was able to explain how the actual bootstrapping works, i.e.
which IOException.java is meant to be used when compiling openjdk-boot.

-- 
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

[oe] [meta-java][PATCH] do_unpackpost: explicitly set working directory

[Patrick Ohly]

bitbake rev 67a7b8b02 "build: don't use $B as the default cwd for
functions" (included in current bitbake master) breaks the assumption
that do_unpackpost runs inside the build directory. Now that has to be
set explicitly, which is also okay for older bitbake versions.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 recipes-core/ecj/libecj-bootstrap.inc   | 1 +
 recipes-core/jakarta-commons/jakarta-commons.inc| 1 +
 recipes-core/junit/junit_3.8.2.bb   | 1 +
 recipes-core/servlet-api/jsp2.0_5.5.26.bb   | 1 +
 recipes-core/servlet-api/servlet2.3_4.1.37.bb   | 1 +
 recipes-core/servlet-api/servlet2.4_5.5.26.bb   | 1 +
 recipes-core/xerces-j/xerces-j_2.11.0.bb| 1 +
 recipes-core/xml-commons/xml-commons-resolver1.1_1.2.bb | 1 +
 8 files changed, 8 insertions(+)

diff --git a/recipes-core/ecj/libecj-bootstrap.inc 
b/recipes-core/ecj/libecj-bootstrap.inc
index 020b8d3..dde09c6 100644
--- a/recipes-core/ecj/libecj-bootstrap.inc
+++ b/recipes-core/ecj/libecj-bootstrap.inc
@@ -15,6 +15,7 @@ S = "${WORKDIR}"
 
 JAR = "ecj-bootstrap-${PV}.jar"
 
+do_unpackpost[dirs] = "${B}"
 do_unpackpost() {
   if [ ! -d source ]; then
 mkdir source
diff --git a/recipes-core/jakarta-commons/jakarta-commons.inc 
b/recipes-core/jakarta-commons/jakarta-commons.inc
index 5968164..5a22f1e 100644
--- a/recipes-core/jakarta-commons/jakarta-commons.inc
+++ b/recipes-core/jakarta-commons/jakarta-commons.inc
@@ -22,6 +22,7 @@ FINDARGS = "-name '*.properties'"
 CLEAN_PATH = ""
 
 # Some projects have a replaceable version number in their manifest template.
+do_unpackpost[dirs] = "${B}"
 do_unpackpost() {
 if [ -d src/conf ]
 then
diff --git a/recipes-core/junit/junit_3.8.2.bb 
b/recipes-core/junit/junit_3.8.2.bb
index bae022d..90ffd66 100644
--- a/recipes-core/junit/junit_3.8.2.bb
+++ b/recipes-core/junit/junit_3.8.2.bb
@@ -13,6 +13,7 @@ DEPENDS += "unzip-native"
 
 inherit java-library
 
+do_unpackpost[dirs] = "${B}"
 do_unpackpost() {
mkdir -p src
# Prevent deletion by do_removebinaries.
diff --git a/recipes-core/servlet-api/jsp2.0_5.5.26.bb 
b/recipes-core/servlet-api/jsp2.0_5.5.26.bb
index e831501..98e3468 100644
--- a/recipes-core/servlet-api/jsp2.0_5.5.26.bb
+++ b/recipes-core/servlet-api/jsp2.0_5.5.26.bb
@@ -18,6 +18,7 @@ IMPL_REVISION = "public_draft"
 JARFILENAME = "jsp-api-2.0.${IMPL_REVISION}.jar"
 ALTJARFILENAMES = "jsp-api-2.0.jar jsp-api.jar"
 
+do_unpackpost[dirs] = "${B}"
 do_unpackpost() {
   sed -i -e "s|@implementation.version@|${IMPL_REVISION}|" src/etc/manifest
 }
diff --git a/recipes-core/servlet-api/servlet2.3_4.1.37.bb 
b/recipes-core/servlet-api/servlet2.3_4.1.37.bb
index fbda5c8..1fa12f8 100644
--- a/recipes-core/servlet-api/servlet2.3_4.1.37.bb
+++ b/recipes-core/servlet-api/servlet2.3_4.1.37.bb
@@ -18,6 +18,7 @@ IMPL_REVISION = "1"
 JARFILENAME = "servlet-2.3.${IMPL_REVISION}.jar"
 ALTJARFILENAMES = "servlet-2.3.jar servlet2.3.jar"
 
+do_unpackpost[dirs] = "${B}"
 do_unpackpost() {
   sed -i -e "s|@implementation.version@|${IMPL_REVISION}|" src/etc/manifest
 }
diff --git a/recipes-core/servlet-api/servlet2.4_5.5.26.bb 
b/recipes-core/servlet-api/servlet2.4_5.5.26.bb
index b34b23d..f9259aa 100644
--- a/recipes-core/servlet-api/servlet2.4_5.5.26.bb
+++ b/recipes-core/servlet-api/servlet2.4_5.5.26.bb
@@ -17,6 +17,7 @@ IMPL_REVISION = "1"
 JARFILENAME = "servlet-api-2.4.${IMPL_REVISION}.jar"
 ALTJARFILENAMES = "servlet-api-2.4.jar servlet-api.jar servlet2.4.jar"
 
+do_unpackpost[dirs] = "${B}"
 do_unpackpost() {
   sed -i -e "s|2.3.@implementation.version@|2.4.${IMPL_REVISION}|" 
src/etc/manifest
 }
diff --git a/recipes-core/xerces-j/xerces-j_2.11.0.bb 
b/recipes-core/xerces-j/xerces-j_2.11.0.bb
index f9e497e..4a0cc91 100644
--- a/recipes-core/xerces-j/xerces-j_2.11.0.bb
+++ b/recipes-core/xerces-j/xerces-j_2.11.0.bb
@@ -26,6 +26,7 @@ DEPENDS_virtclass-native = "fastjar-native jaxp1.3-native 
xml-commons-resolver1.
 RDEPENDS_${PN} = "libjaxp1.3-java libxml-commons-resolver1.1-java"
 RDEPENDS_${PN}_virtclass-native = ""
 
+do_unpackpost[dirs] = "${B}"
 do_unpackpost() {
   find src -exec \
 sed -i -e "s|@impl.name@|Xerces-J ${PV}|" \
diff --git a/recipes-core/xml-commons/xml-commons-resolver1.1_1.2.bb 
b/recipes-core/xml-commons/xml-commons-resolver1.1_1.2.bb
index 5853895..77556fc 100644
--- a/recipes-core/xml-commons/xml-commons-resolver1.1_1.2.bb
+++ b/recipes-core/xml-commons/xml-commons-resolver1.1_1.2.bb
@@ -13,6 +13,7 @@ S = "${WORKDIR}/xml-commons-resolver-${PV}"
 DEPENDS = "fastjar-native jaxp1.3"
 DEPENDS_virtclass-native = "fastjar-native jaxp1.3-native"
 
+do_unpackpost[dirs] = "${B}"
 do_unpackpost() {
   find src -exec \
 sed -i -e "s|@impl.name@|XmlResolver|" \
-- 
2.1.4

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-java][PATCH] openjdk-8: fix compiler detection

[Patrick Ohly]

When GCC is at version 4 or 5, parsing the recipe fails with:

ERROR: ExpansionError during parsing
.../ostro-os/meta-java/recipes-core/openjdk/openjdk-8_72b05.bb
...
bb.data_smart.ExpansionError: Failure expanding variable CFLAGS,
expression was  -O2 -pipe -g -feliminate-unused-debug-types
-fdebug-prefix-map=.../ostro-os/build/tmp-glibc/work/corei7-64-ostro-
linux/openjdk-8/72b05-r0=/usr/src/debug/openjdk-8/72b05-r0
-fdebug-prefix-map=.../ostro-os/build/tmp-glibc/sysroots/x86_64-linux=
-fdebug-prefix-map=.../ostro-os/build/tmp-glibc/sysroots/intel-corei7-64=
 -fstack-protector-strong -D_FORTIFY_SOURCE=2
${  version_specific_cflags(d)} -Wno-error=deprecated-declarations which
triggered exception TypeError: can only join an iterable

That's because FLAGS_GCC may be unset, thus leading to
d.getVar() returning None and ''.join(extraflags) failing.

The join() is also redundant: extraflags already is a string. It
happened to work because Python treats a string as sequence of
single-character strings, and thus ''.join() re-created the original
string.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 recipes-core/openjdk/openjdk-8-common.inc | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/recipes-core/openjdk/openjdk-8-common.inc 
b/recipes-core/openjdk/openjdk-8-common.inc
index 089f907..7ad802a 100644
--- a/recipes-core/openjdk/openjdk-8-common.inc
+++ b/recipes-core/openjdk/openjdk-8-common.inc
@@ -271,10 +271,8 @@ def version_specific_cflags(d):
 # doesn't work anyway.
 version = d.getVar('GCCVERSION', expand=True)[0]
 
-if int(version) >= 4:
-extraflags = d.getVar('FLAGS_GCC%d' % int(version), True)
-
-return ''.join(extraflags)
+extraflags = d.getVar('FLAGS_GCC%d' % int(version), True) or ''
+return extraflags
 
 CFLAGS_append = " ${@version_specific_cflags(d)}"
 CXXFLAGS_append = " ${@version_specific_cflags(d)}"
-- 
2.1.4

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java][PATCH] openjdk-8: Detect compiler version

[Patrick Ohly]

Dan McGregor  gmail.com> writes:


> From: Daniel McGregor  vecima.com>
> 
> Some supported hosts still use GCC 4.X. These don't support the flags
> needed to make GCC 6 work, so check the GCC version and add appropriate
> compiler flags.
> 
> This implementation will append flags for any gcc version, but it's only
> used for GCC 6 right now.

Now I am getting an error directly when bitbake parses the updated
recipes in meta-java:

ERROR: ExpansionError during parsing
.../ostro-os/meta-java/recipes-core/openjdk/openjdk-8_72b05.bb
...
bb.data_smart.ExpansionError: Failure expanding variable CFLAGS,
expression was  -O2 -pipe -g -feliminate-unused-debug-types
-fdebug-prefix-map=.../ostro-os/build/tmp-glibc/work/corei7-64-ostro-
linux/openjdk-8/72b05-r0=/usr/src/debug/openjdk-8/72b05-r0
-fdebug-prefix-map=.../ostro-os/build/tmp-glibc/sysroots/x86_64-linux=
-fdebug-prefix-map=.../ostro-os/build/tmp-glibc/sysroots/intel-corei7-64=
 -fstack-protector-strong -D_FORTIFY_SOURCE=2 
${@version_specific_cflags(d)} -Wno-error=deprecated-declarations which
triggered exception TypeError: can only join an iterable

> +def version_specific_cflags(d):
> +extraflags = None
> +version = None
> +
> +if bb.data.inherits_class('native', d):
> +from subprocess import Popen, PIPE
> +
> +cmd = d.expand('${CPP} -P -').split()
> +cc = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE)
> +# This check is GCC specific. Clang always returns 4. For Clang
> +# __clang_major__ and __clang_minor__ need to be checked. Ideally
> +# __GNUC_MINOR__ would be checked as well, but for this recipe
> +# GCC major is all we care about.
> +version = cc.communicate(b'__GNUC__')[0].decode('utf-8')[0]
> +else:
> +# in the cross case, trust that GCCVERSION is correct. This won't
> +# work if the native toolchain is Clang, but as of this writing that
> +# doesn't work anyway.
> +version = d.getVar('GCCVERSION', expand=True)[0]
> +
> +if int(version) >= 4:
> +extraflags = d.getVar('FLAGS_GCC%d' % int(version), True)
> +
> +return ''.join(extraflags)

The code above only works when FLAGS_GCC is set. In Ostro OS, we
are using GCCVERSION ?= "5.%" because of these unsolveed build breakages
with gcc6, and thus extraflags becomes None, which then triggers the 
exception.

The same problem should also appear when gcc on the host is older than v6.
Has the patch actually been tested on a system where the problem occurs?

As I said in the other mail thread, fixing flags for openjdk-native is one
part of the problem. The other part is distinguishing between flags for the
host compiler and and target compiler when building openjdk - that part is
unsolved, and thus I'd expect compilation to still fail when building on a
host with gcc 4.x and default target gcc.

Bye, Patrick

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java][PATCH] openjdk-8: make GCC6 happy

[Patrick Ohly]

Dan McGregor  gmail.com> writes: 
> On 11 July 2016 at 05:29, Patrick Ohly  intel.com> wrote:
> > Dan McGregor  gmail.com> writes:
> >> From: Daniel McGregor  vecima.com>
> >>
> >> GCC 6 sets the default C++ standard to C++14 and introduces dead store
> >> elimination by default. OpenJDK 8 is not ready for either of these
> >> changes, so set the C++ standard back to gnu++98 and disable dead
> >> store elimination.
> >>
> >> Switched to using --with-extra-cflags, cxxflags, and ldflags. The added
> >> patch fixes building when using those flags, and are needed to get
> >> CFLAGS into the JDK build in the native case.
> >
> > Has anyone tested this on a host system where gcc is still 4.x, like 4.9.2
> > on Debian Wheezy?
> >
> > I'm finding that -fno-lifetime-dse is also getting passed to the gcc used
> > for compiling native binaries (obviously in openjdk-8-native, but also for
> > some helper executables in openjdk-8). This then breaks the compilation
> > because older gcc rejects that flag.
> >
> > I've briefly toyed with the patch below which worked for openjdk-8-native,
> > but not for openjdk-8. I'm just going to work around it by staying on gcc
> > 5.x and clearing these extra flags.
> >
> > I'm not familiar enough with the openjdk-8 build process to propose a better
> > solution, but perhaps someone else has an idea?
> >
[...]
> This regex doesn't work in the cross case because the version string
> doesn't start with "gcc". It starts with '-gcc', so
> that should be checked instead.
> 
> I'll fiddle with this patch some more. It looks like a good short-term
> solution to building OpenJDK on GCC 4 hosts.

Thanks for taking this further. But please really test on such an older 
system, because the patch alone is not enough. Something also needs to
be done when configuring openjdk-8 such that it uses different flags
when invoking the host compiler (old gcc) and the target compiler (gcc 6).

I haven't found a solution for that (not familiar enough with the Java
build system).

Bye, Patrick

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java][PATCH] openjdk-8: make GCC6 happy

[Patrick Ohly]

Dan McGregor  gmail.com> writes:
> From: Daniel McGregor  vecima.com>
> 
> GCC 6 sets the default C++ standard to C++14 and introduces dead store
> elimination by default. OpenJDK 8 is not ready for either of these
> changes, so set the C++ standard back to gnu++98 and disable dead
> store elimination.
> 
> Switched to using --with-extra-cflags, cxxflags, and ldflags. The added
> patch fixes building when using those flags, and are needed to get
> CFLAGS into the JDK build in the native case.

Has anyone tested this on a host system where gcc is still 4.x, like 4.9.2
on Debian Wheezy?

I'm finding that -fno-lifetime-dse is also getting passed to the gcc used
for compiling native binaries (obviously in openjdk-8-native, but also for
some helper executables in openjdk-8). This then breaks the compilation
because older gcc rejects that flag.

I've briefly toyed with the patch below which worked for openjdk-8-native,
but not for openjdk-8. I'm just going to work around it by staying on gcc
5.x and clearing these extra flags.

I'm not familiar enough with the openjdk-8 build process to propose a better
solution, but perhaps someone else has an idea?

diff --git a/meta-java/recipes-core/openjdk/openjdk-8-common.inc
b/meta-java/recipes-core/openjdk/openjdk-8-common.inc
index dd3d397..060d828 100644
--- a/meta-java/recipes-core/openjdk/openjdk-8-common.inc
+++ b/meta-java/recipes-core/openjdk/openjdk-8-common.inc
@@ -237,6 +237,25 @@ EXTRA_OECONF_append = "\
 --with-update-version=${OPENJDK_UPDATE_VERSION} \
 "
 
-CFLAGS_append = " -fno-lifetime-dse -fno-delete-null-pointer-checks"
-CXXFLAGS_append = " -fno-lifetime-dse -fno-delete-null-pointer-checks"
+# GCC 6 sets the default C++ standard to C++14 and introduces dead store
+# elimination by default. OpenJDK 8 is not ready for either of these
+# changes.
+FLAGS_GCC6 = "-fno-lifetime-dse -fno-delete-null-pointer-checks"
+
+# All supported cross compilers support the compiler flags that were
+# added to make compilation with gcc6 work. But the host compiler for
+# native compilation is a different story: it may be too old (for example,
+# gcc 4.9.2 on Debian Wheezy). In that case we need to check what the
+# version is and unset the flags when gcc is not yet GCC 6.
+python () {
+if d.getVar('PN', True).endswith('-native'):
+import re, subprocess
+version = subprocess.check_output(d.expand('${CC}
--version').split()).decode('utf-8')
+m = re.search(r'^gcc.* (\d+)(\.\d+)*$', version, re.MULTILINE)
+if m and int(m.group(1)) < 6:
+d.setVar('FLAGS_GCC6', '')
+}
+
+CFLAGS_append = " ${FLAGS_GCC6}"
+CXXFLAGS_append = " ${FLAGS_GCC6}"
 CXX_append = " -std=gnu++98"

Bye, Patrick

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-java] icedtea7-native - IOException constructor compile error

[Patrick Ohly]

Hello!

I'm trying to build openjdk8, using the master branches of OE and
meta-java. Distro is Ostro, which configures:

PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native"
PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

In this configuration, cacao-initial-native ecj-initial-native
classpath-native ecj-bootstrap-native jikes-initial-native get build
before icedtea7-native fails to compile with:

build-bootstrap-javac:
[javac] Compiling 1 source file to 
/fast/build/ostro/x86/tmp-glibc/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk.build-boot/langtools/build/bootstrap/classes
[javac] --
[javac] 1. ERROR in 
/fast/build/ostro/x86/tmp-glibc/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot/langtools/src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
 (at line 1169)
[javac] super(message, cause);
[javac] ^^
[javac] The constructor IOException(String, Throwable) is undefined
[javac] --
[javac] 1 problem (1 error)

BUILD FAILED

/fast/build/ostro/x86/tmp-glibc/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot/langtools/make/build.xml:446:
 The following error occurred while executing this line:

/fast/build/ostro/x86/tmp-glibc/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot/langtools/make/build.xml:789:
 Compile failed; see the compiler error output for details.

Total time: 2 seconds
Makefile:201: recipe for target 'build' failed

Sure enough, classpath_0.99 only has IOException with a constructor that
takes a single parameter
(classpath-native/0.99-r6.0/classpath-0.99/java/io/IOException.java):

public class IOException extends Exception
{
  /**
   * Compatible with JDK 1.0+.
   */
  private static final long serialVersionUID = 7818375828146090155L;

  /**
   * Create an exception without a descriptive error message.
   */
  public IOException()
  {
  }

  /**
   * Create an exception with a descriptive error message.
   *
   * @param message the descriptive error message
   */
  public IOException(String message)
  {
super(message);
  }
} // class IOException



The code which doesn't compile is
icedtea-2.1.3/build/openjdk-boot/langtools/src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java:

static final class ZipFormatException extends IOException {
private static final long serialVersionUID = 8000196834066748623L;
protected ZipFormatException(String message) {
super(message);
}

protected ZipFormatException(String message, Throwable cause) {
super(message, cause);
}
}

So I'm not surprised that it fails; this can't work. The questions are:
what combination does work, and when did the combination above stop
working?

[please reply also directly, I'm not receiving list emails]

-- 
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

Re: [oe] [meta-oe][PATCH 1/2] libgphoto2: fix compatibility with libjpeg-turbo

[Patrick Ohly]

On Wed, 2016-06-15 at 17:08 +0200, Patrick Ohly wrote:
> +Upstream-Status: Submitted [https://github.com/gphoto/libgphoto2/pull/64]

FWIW, the patch was merged, so "Backported" is now more accurate.

-- 
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

[oe] [meta-oe][PATCH 2/2] v4l-utils: fix compatibility with libjpeg-turbo

[Patrick Ohly]

The libjpeg-turbo update to 1.5.0 broke components which embedd their
own, conflicting definitions of the jpeg_mem functions.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 .../jpeg_memsrcdest-extend-feature-check.patch | 62 ++
 .../recipes-multimedia/v4l2apps/v4l-utils_1.6.2.bb |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 
meta-oe/recipes-multimedia/v4l2apps/v4l-utils/jpeg_memsrcdest-extend-feature-check.patch

diff --git 
a/meta-oe/recipes-multimedia/v4l2apps/v4l-utils/jpeg_memsrcdest-extend-feature-check.patch
 
b/meta-oe/recipes-multimedia/v4l2apps/v4l-utils/jpeg_memsrcdest-extend-feature-check.patch
new file mode 100644
index 000..17f8ba9
--- /dev/null
+++ 
b/meta-oe/recipes-multimedia/v4l2apps/v4l-utils/jpeg_memsrcdest-extend-feature-check.patch
@@ -0,0 +1,62 @@
+From c40f7873d89fd88b0485fd94f45c139be41e1899 Mon Sep 17 00:00:00 2001
+From: Patrick Ohly <patrick.o...@intel.com>
+Date: Wed, 15 Jun 2016 10:33:24 +0200
+Subject: [PATCH] jpeg_memsrcdest: extend feature check
+
+libjpeg.h in OpenEmbedded master (from libjpeg-turbo 1.5.0) provides
+these methods if "JPEG_LIB_VERSION >= 80 ||
+defined(MEM_SRCDST_SUPPORTED)".
+
+The support for the jpeg_mem functions was added even when not
+emulating the libjpeg8 API, controlled via the MEM_SRCDST_SUPPORTED
+define, so checking for the version alone is not enough anymore.
+
+See 
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/ab70623eb29e09e67222be5b9e1ea320fe5aa0e9
+
+This fixes errors about conflicting declarations (signed vs. unsigned
+char).
+
+Upstream-Status: Submitted 
[http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/102965]
+
+Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
+---
+ lib/libv4lconvert/jpeg_memsrcdest.c | 4 ++--
+ lib/libv4lconvert/jpeg_memsrcdest.h | 4 
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/lib/libv4lconvert/jpeg_memsrcdest.c 
b/lib/libv4lconvert/jpeg_memsrcdest.c
+index b70af8e..8ada421 100644
+--- a/lib/libv4lconvert/jpeg_memsrcdest.c
 b/lib/libv4lconvert/jpeg_memsrcdest.c
+@@ -26,8 +26,8 @@
+ #include "jpeg_memsrcdest.h"
+ 
+ /* libjpeg8 and later come with their own (API compatible) memory source
+-   and dest */
+-#if JPEG_LIB_VERSION < 80
++   and dest, and older versions may have it backported */
++#if JPEG_LIB_VERSION < 80 && !defined(MEM_SRCDST_SUPPORTED)
+ 
+ /* Expanded data source object for memory input */
+ 
+diff --git a/lib/libv4lconvert/jpeg_memsrcdest.h 
b/lib/libv4lconvert/jpeg_memsrcdest.h
+index e971182..b13bf3f 100644
+--- a/lib/libv4lconvert/jpeg_memsrcdest.h
 b/lib/libv4lconvert/jpeg_memsrcdest.h
+@@ -1,5 +1,7 @@
+ #include 
+ 
++#if JPEG_LIB_VERSION < 80 && !defined(MEM_SRCDST_SUPPORTED)
++
+ void
+ jpeg_mem_src (j_decompress_ptr cinfo, unsigned char * buffer,
+   unsigned long bufsize);
+@@ -7,3 +9,5 @@ jpeg_mem_src (j_decompress_ptr cinfo, unsigned char * buffer,
+ void
+ jpeg_mem_dest (j_compress_ptr cinfo, unsigned char ** outbuffer,
+   unsigned long * outsize);
++
++#endif
+-- 
+2.1.4
+
diff --git a/meta-oe/recipes-multimedia/v4l2apps/v4l-utils_1.6.2.bb 
b/meta-oe/recipes-multimedia/v4l2apps/v4l-utils_1.6.2.bb
index 75a42a2..46cd942 100644
--- a/meta-oe/recipes-multimedia/v4l2apps/v4l-utils_1.6.2.bb
+++ b/meta-oe/recipes-multimedia/v4l2apps/v4l-utils_1.6.2.bb
@@ -16,6 +16,7 @@ SRC_URI = 
"http://linuxtv.org/downloads/v4l-utils/v4l-utils-${PV}.tar.bz2 \

file://0001-Revert-media-ctl-Don-t-install-libmediactl-and-libv4.patch \
file://mediactl-pkgconfig.patch \
file://export-mediactl-headers.patch \
+   file://jpeg_memsrcdest-extend-feature-check.patch \
   "
 SRC_URI[md5sum] = "9cb3c178f937954e65bf30920af433ef"
 SRC_URI[sha256sum] = 
"d3d6eb1f0204fb11f3d318bfca35d5f73cc077f88fac7665a47856a16496be7d"
-- 
2.1.4

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH 1/2] libgphoto2: fix compatibility with libjpeg-turbo

[Patrick Ohly]

The libjpeg-turbo update to 1.5.0 broke components which embedd their
own, conflicting definitions of the jpeg_mem functions.

Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
 .../jpeg_memsrcdest-extend-feature-check.patch | 97 ++
 .../recipes-graphics/gphoto2/libgphoto2_2.5.8.bb   |  1 +
 2 files changed, 98 insertions(+)
 create mode 100644 
meta-oe/recipes-graphics/gphoto2/libgphoto2-2.5.8/jpeg_memsrcdest-extend-feature-check.patch

diff --git 
a/meta-oe/recipes-graphics/gphoto2/libgphoto2-2.5.8/jpeg_memsrcdest-extend-feature-check.patch
 
b/meta-oe/recipes-graphics/gphoto2/libgphoto2-2.5.8/jpeg_memsrcdest-extend-feature-check.patch
new file mode 100644
index 000..810d025
--- /dev/null
+++ 
b/meta-oe/recipes-graphics/gphoto2/libgphoto2-2.5.8/jpeg_memsrcdest-extend-feature-check.patch
@@ -0,0 +1,97 @@
+From d4f7fdc9de00562d796287a365408b4c24de5db2 Mon Sep 17 00:00:00 2001
+From: Patrick Ohly <patrick.o...@intel.com>
+Date: Wed, 15 Jun 2016 10:33:24 +0200
+Subject: [PATCH] jpeg_memsrcdest: extend feature check
+
+libjpeg.h in OpenEmbedded master (from libjpeg-turbo 1.5.0) provides
+these methods if "JPEG_LIB_VERSION >= 80 ||
+defined(MEM_SRCDST_SUPPORTED)".
+
+The support for the jpeg_mem functions was added even when not
+emulating the libjpeg8 API, controlled via the MEM_SRCDST_SUPPORTED
+define, so checking for the version alone is not enough anymore.
+
+See 
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/ab70623eb29e09e67222be5b9e1ea320fe5aa0e9
+
+This fixes errors about conflicting declarations (signed vs. unsigned
+char).
+
+Upstream-Status: Submitted [https://github.com/gphoto/libgphoto2/pull/64]
+
+Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
+---
+ camlibs/ax203/jpeg_memsrcdest.c   | 4 ++--
+ camlibs/ax203/jpeg_memsrcdest.h   | 4 
+ camlibs/jl2005c/jpeg_memsrcdest.c | 4 ++--
+ camlibs/jl2005c/jpeg_memsrcdest.h | 4 
+ 4 files changed, 12 insertions(+), 4 deletions(-)
+
+diff --git a/camlibs/ax203/jpeg_memsrcdest.c b/camlibs/ax203/jpeg_memsrcdest.c
+index 0ed83b1..5614573 100644
+--- a/camlibs/ax203/jpeg_memsrcdest.c
 b/camlibs/ax203/jpeg_memsrcdest.c
+@@ -25,8 +25,8 @@
+ #include "jpeg_memsrcdest.h"
+ 
+ /* libjpeg8 and later come with their own (API compatible) memory source
+-   and dest */
+-#if JPEG_LIB_VERSION < 80
++   and dest, and older versions may have it backported */
++#if JPEG_LIB_VERSION < 80 && !defined(MEM_SRCDST_SUPPORTED)
+ 
+ /* Expanded data source object for memory input */
+ 
+diff --git a/camlibs/ax203/jpeg_memsrcdest.h b/camlibs/ax203/jpeg_memsrcdest.h
+index e971182..b13bf3f 100644
+--- a/camlibs/ax203/jpeg_memsrcdest.h
 b/camlibs/ax203/jpeg_memsrcdest.h
+@@ -1,5 +1,7 @@
+ #include 
+ 
++#if JPEG_LIB_VERSION < 80 && !defined(MEM_SRCDST_SUPPORTED)
++
+ void
+ jpeg_mem_src (j_decompress_ptr cinfo, unsigned char * buffer,
+   unsigned long bufsize);
+@@ -7,3 +9,5 @@ jpeg_mem_src (j_decompress_ptr cinfo, unsigned char * buffer,
+ void
+ jpeg_mem_dest (j_compress_ptr cinfo, unsigned char ** outbuffer,
+   unsigned long * outsize);
++
++#endif
+diff --git a/camlibs/jl2005c/jpeg_memsrcdest.c 
b/camlibs/jl2005c/jpeg_memsrcdest.c
+index 321f926..b65310e 100644
+--- a/camlibs/jl2005c/jpeg_memsrcdest.c
 b/camlibs/jl2005c/jpeg_memsrcdest.c
+@@ -25,8 +25,8 @@
+ #include "jpeg_memsrcdest.h"
+ 
+ /* libjpeg8 and later come with their own (API compatible) memory source
+-   and dest */
+-#if JPEG_LIB_VERSION < 80
++   and dest, and older versions may have it backported */
++#if JPEG_LIB_VERSION < 80 && !defined(MEM_SRCDST_SUPPORTED)
+ 
+ /* Expanded data source object for memory input */
+ 
+diff --git a/camlibs/jl2005c/jpeg_memsrcdest.h 
b/camlibs/jl2005c/jpeg_memsrcdest.h
+index e971182..b13bf3f 100644
+--- a/camlibs/jl2005c/jpeg_memsrcdest.h
 b/camlibs/jl2005c/jpeg_memsrcdest.h
+@@ -1,5 +1,7 @@
+ #include 
+ 
++#if JPEG_LIB_VERSION < 80 && !defined(MEM_SRCDST_SUPPORTED)
++
+ void
+ jpeg_mem_src (j_decompress_ptr cinfo, unsigned char * buffer,
+   unsigned long bufsize);
+@@ -7,3 +9,5 @@ jpeg_mem_src (j_decompress_ptr cinfo, unsigned char * buffer,
+ void
+ jpeg_mem_dest (j_compress_ptr cinfo, unsigned char ** outbuffer,
+   unsigned long * outsize);
++
++#endif
+-- 
+2.1.4
+
diff --git a/meta-oe/recipes-graphics/gphoto2/libgphoto2_2.5.8.bb 
b/meta-oe/recipes-graphics/gphoto2/libgphoto2_2.5.8.bb
index 3de6942..25c82cb 100644
--- a/meta-oe/recipes-graphics/gphoto2/libgphoto2_2.5.8.bb
+++ b/meta-oe/recipes-graphics/gphoto2/libgphoto2_2.5.8.bb
@@ -14,6 +14,7 @@ SRC_URI = 
"${SOURCEFORGE_MIRROR}/gphoto/libgphoto2-${PV}.tar.bz2;name=libgphoto2
file://10-camera-libgphoto2.fdi \
file://40-libgphoto2.rules \
file://0001-configure.ac-remove-AM_PO_SUBDIRS.patch \
+   file://jpeg_memsrcdest-extend-feature-check.patch \
 "
 
 SRC_URI[libgphoto2.md5sum] =