[OE-core] [sumo][PATCH] sysvinit-inittab: do not use 'exit 1' to postpone to first boot

2018-05-28 Thread Manjukumar Matha
From: Alexander Kanavin 

Instead, first check if we need to do anything at all during first boot,
and if so, either postpone to first boot via pkg_postinst_ontarget()
when running on host, or run the necessary setup code when running on target.

(From OE-Core rev: 16df1717c3813ba773e0dfa2d1db471816d8b99b)

This is a backport from master

Signed-off-by: Alexander Kanavin 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Manjukumar Matha 
---
 meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb 
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index 5b9c422..8585a41 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -53,8 +53,15 @@ EOF
 }
 
 pkg_postinst_${PN} () {
+# run this on host and on target
+if [ "${SERIAL_CONSOLES_CHECK}" = "" ]; then
+   exit 0
+fi
+}
+
+pkg_postinst_ontarget_${PN} () {
 # run this on the target
-if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
+if [ -e /proc/consoles ]; then
tmp="${SERIAL_CONSOLES_CHECK}"
for i in $tmp
do
@@ -68,11 +75,7 @@ if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
done
kill -HUP 1
 else
-   if [ "${SERIAL_CONSOLES_CHECK}" = "" ]; then
-   exit 0
-   else
-   exit 1
-   fi
+   exit 1
 fi
 }
 
-- 
2.7.4

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


Re: [OE-core] [PATCH] telnetd:Fix deadlock on cleanup

2018-05-28 Thread Seiichi Ishitsuka
Dear Alex,

> The patch should go to meta-openembedded list, and it should be created 
> against the layer source tree, not against the component source
> tree.

Thank you for all your kindness.
I have created a patch for meta-networking/recipes-netkit/netkit-telnet.
Please refer to the attached patch.

Best regards,
Seiichi Ishitsuka


0001-netkit-telnet-Fix-deadlock-on-cleanup.patch
Description: 0001-netkit-telnet-Fix-deadlock-on-cleanup.patch
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 02/24] runqemu-extract-sdk: allow install debugfs on rootfs

2018-05-28 Thread Robert Yang



On 05/29/2018 09:39 AM, Robert Yang wrote:



On 05/29/2018 01:14 AM, Randy MacLeod wrote:

On 05/24/2018 10:48 PM, Robert Yang wrote:

Usually, the debugfs' (-dbg.tar.*) work follow is:

s/work follow/workflow/

1) Install regular rootfs to dir_foo
2) Install debugfs (-dbg.tar.*) to the same dir_foo

So we need allow install debugfs on rootfs.

So we need to allow installing the debugfs on top of the rootfs.


or at least, I think that's what you mean.


Thanks, done.


I meant updated in the repo:

  git://git.openembedded.org/openembedded-core-contrib rbt/fix_from_wr
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/fix_from_wr

// Robert



// Robert


../Randy


Signed-off-by: Robert Yang 
---
  scripts/runqemu-extract-sdk | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/runqemu-extract-sdk b/scripts/runqemu-extract-sdk
index 2a0dd50..f4286ef 100755
--- a/scripts/runqemu-extract-sdk
+++ b/scripts/runqemu-extract-sdk
@@ -76,7 +76,9 @@ fi
  pseudo_state_dir="$SDK_ROOTFS_DIR/../$(basename 
"$SDK_ROOTFS_DIR").pseudo_state"

  pseudo_state_dir="$(readlink -f $pseudo_state_dir)"
-if [ -e "$pseudo_state_dir" ]; then
+debug_image="`echo $ROOTFS_TARBALL | grep '\-dbg\.tar\.'`"
+
+if [ -e "$pseudo_state_dir" -a -z "$debug_image" ]; then
  echo "Error: $pseudo_state_dir already exists!"
  echo "Please delete the rootfs tree and pseudo directory manually"
  echo "if this is really what you want."





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


Re: [OE-core] [PATCH 02/24] runqemu-extract-sdk: allow install debugfs on rootfs

2018-05-28 Thread Robert Yang



On 05/29/2018 01:14 AM, Randy MacLeod wrote:

On 05/24/2018 10:48 PM, Robert Yang wrote:

Usually, the debugfs' (-dbg.tar.*) work follow is:

s/work follow/workflow/

1) Install regular rootfs to dir_foo
2) Install debugfs (-dbg.tar.*) to the same dir_foo

So we need allow install debugfs on rootfs.

So we need to allow installing the debugfs on top of the rootfs.


or at least, I think that's what you mean.


Thanks, done.

// Robert


../Randy


Signed-off-by: Robert Yang 
---
  scripts/runqemu-extract-sdk | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/runqemu-extract-sdk b/scripts/runqemu-extract-sdk
index 2a0dd50..f4286ef 100755
--- a/scripts/runqemu-extract-sdk
+++ b/scripts/runqemu-extract-sdk
@@ -76,7 +76,9 @@ fi
  pseudo_state_dir="$SDK_ROOTFS_DIR/../$(basename 
"$SDK_ROOTFS_DIR").pseudo_state"

  pseudo_state_dir="$(readlink -f $pseudo_state_dir)"
-if [ -e "$pseudo_state_dir" ]; then
+debug_image="`echo $ROOTFS_TARBALL | grep '\-dbg\.tar\.'`"
+
+if [ -e "$pseudo_state_dir" -a -z "$debug_image" ]; then
  echo "Error: $pseudo_state_dir already exists!"
  echo "Please delete the rootfs tree and pseudo directory manually"
  echo "if this is really what you want."





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


[OE-core] [rocko][PATCH] npm.bbclass: Fix building node modules with npm@5

2018-05-28 Thread Damien Riegel
From: Böszörményi Zoltán 

npm cache clear throws an error with npm@5 and suggests to
use npm cache verify instead. But our cache is actually empty,
so use npm cache clear --force.

npm install in the source directory creates symlinks with npm@5.

Use a combination of npm pack and npm install module-version.tgz
that works the same way with older and new npm versions and is
guaranteed to create actual copies instead of directory symlinks.

This change allows using nodejs 8.x LTS, tested with 8.9.4.

Signed-off-by: Zoltán Böszörményi 
Signed-off-by: Ross Burton 
---
I'm sending a request to include this patch in the rocko branch, as the
version of NodeJS included in rocko version of meta-oe is 8.4.0, so it
can definitely benefit from this patch.

 meta/classes/npm.bbclass | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index a69bedbb28..898a54eb50 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -31,7 +31,7 @@ npm_do_compile() {
fi
npm set cache ${WORKDIR}/npm_cache
# clear cache before every build
-   npm cache clear
+   npm cache clear --force
# Install pkg into ${S} without going to the registry
if [  "${NPM_INSTALL_DEV}" = "1" ]; then
npm --arch=${NPM_ARCH} --target_arch=${NPM_ARCH} --no-registry 
install
@@ -45,7 +45,8 @@ npm_do_install() {
# be created in this directory
export HOME=${WORKDIR}
mkdir -p ${NPM_INSTALLDIR}/
-   npm install --prefix ${D}${prefix} -g --arch=${NPM_ARCH} 
--target_arch=${NPM_ARCH} --production --no-registry
+   npm pack .
+   npm install --prefix ${D}${prefix} -g --arch=${NPM_ARCH} 
--target_arch=${NPM_ARCH} --production --no-registry ${PN}-${PV}.tgz
if [ -d ${D}${prefix}/etc ] ; then
# This will be empty
rmdir ${D}${prefix}/etc
-- 
2.17.0

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


Re: [OE-core] [PATCH] scripts/oe-init-bashrc: add more user-friendly oe-setup utility

2018-05-28 Thread Jens Rehsack


> Am 28.05.2018 um 21:12 schrieb Alexander Kanavin :
> 
> 2018-05-28 21:41 GMT+03:00 Jens Rehsack :
>> When I log into my build machine, I just do
>> 
>> $ oe_builddir use ~/gpw-community-bsp/gpw-yocto-platform/
>> 
>> and I'm in the right location and have all environment settings prepared to 
>> start a bitbake immediately.
> 
> oe-init-build-env does the same thing, how is this better?

It allows you to do things like changing to build-dir and setup shell 
environment atomically - for example.

>> $ oe_builddir help
>> oe_builddir  [argument]
>> Available commands:
>>use use specified build-dir, setup when local.conf and/or 
>> bblayers.conf are missing
>>setup   create default builddir
>>avail   list possible build-dir's
>>layers  list layers used in BSP
>>repos   list repositories used in BSP
>>prune   prune old builds
>>off remove all settings from oe from shell environment
>> 
>> Tells you, what could be expected (very short).
>> 
>> It's all plain shell - so everyone can adopt it easily to local 
>> requirements. Further, it supports setting flags and tools within 
>> ''oe_builddir use''.
> 
> I'd say you should look at existing tools, specifically
> oe-init-build-env and/or oe-setup-builddir, and add any desired
> functionality to them.

I did. They don't do so much. It's even not the same concept.
And - what is even more important: it is one tool, it does init and setup and 
much more - for the same thing.
It is much easier teach people one tool than teaching them pick the right out 
of 8.

Cheers
--
Jens Rehsack - rehs...@gmail.com



signature.asc
Description: Message signed with OpenPGP
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] scripts/oe-init-bashrc: add more user-friendly oe-setup utility

2018-05-28 Thread Alexander Kanavin
2018-05-28 21:41 GMT+03:00 Jens Rehsack :
> When I log into my build machine, I just do
>
> $ oe_builddir use ~/gpw-community-bsp/gpw-yocto-platform/
>
> and I'm in the right location and have all environment settings prepared to 
> start a bitbake immediately.

oe-init-build-env does the same thing, how is this better?

> $ oe_builddir help
> oe_builddir  [argument]
> Available commands:
> use use specified build-dir, setup when local.conf and/or 
> bblayers.conf are missing
> setup   create default builddir
> avail   list possible build-dir's
> layers  list layers used in BSP
> repos   list repositories used in BSP
> prune   prune old builds
> off remove all settings from oe from shell environment
>
> Tells you, what could be expected (very short).
>
> It's all plain shell - so everyone can adopt it easily to local requirements. 
> Further, it supports setting flags and tools within ''oe_builddir use''.

I'd say you should look at existing tools, specifically
oe-init-build-env and/or oe-setup-builddir, and add any desired
functionality to them.

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


[OE-core] [PATCH 1/2] cpan_build.bbclass: adopt to recent EU::MM

2018-05-28 Thread Jens Rehsack
The modern the time, the improvements in ExtUtils::MakeMaker.

Nowadays, .packlist and perllocal.pod aren't touched anymore when appropriate
flags set during configure stage. Controlling the flags globally avoids
dual-life recipes need share patching.

Further: remove prepending ${PERL_ARCHLIB} in PERL5LIB - it's wrong (search
order is site_lib, vendor_lib, core) - and ${PERL_ARCHLIB} contains core
libpath only ...

Signed-off-by: Jens Rehsack 
---
 meta/classes/cpan.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes/cpan.bbclass b/meta/classes/cpan.bbclass
index 8e079e0d55..926c6358a6 100644
--- a/meta/classes/cpan.bbclass
+++ b/meta/classes/cpan.bbclass
@@ -16,8 +16,7 @@ export PERL_ARCHLIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version
 export PERLHOSTLIB = 
"${STAGING_LIBDIR_NATIVE}/perl-native/perl/${@get_perl_version(d)}/"

 cpan_do_configure () {
-   export PERL5LIB="${PERL_ARCHLIB}"
-   yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor 
${EXTRA_CPANFLAGS}
+   yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor 
NO_PERLLOCAL=1 NO_PACKLIST=1 ${EXTRA_CPANFLAGS}

# Makefile.PLs can exit with success without generating a
# Makefile, e.g. in cases of missing configure time

--
Jens Rehsack - rehs...@gmail.com



signature.asc
Description: Message signed with OpenPGP
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 0/2] Update Perl5 handling

2018-05-28 Thread Jens Rehsack
Jens Rehsack (2):
  cpan_build.bbclass: adopt to recent EU::MM
  cpan_build.bbclass: tell Module::Build the replacement

 meta/classes/cpan.bbclass   | 3 +--
 meta/classes/cpan_build.bbclass | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)
--
Jens Rehsack - rehs...@gmail.com



signature.asc
Description: Message signed with OpenPGP
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/2] cpan_build.bbclass: tell Module::Build the replacement

2018-05-28 Thread Jens Rehsack
Instead of patching Module::Build, maybe Module::Build::Tiny and all other
similar tools, use the official way to tell them which is the target perl
on target.

Signed-off-by: Jens Rehsack 
---
 meta/classes/cpan_build.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/cpan_build.bbclass b/meta/classes/cpan_build.bbclass
index fac074d610..9a2ad895ef 100644
--- a/meta/classes/cpan_build.bbclass
+++ b/meta/classes/cpan_build.bbclass
@@ -30,7 +30,7 @@ cpan_build_do_configure () {
 }

 cpan_build_do_compile () {
-perl Build verbose=1
+perl Build --perl "${bindir}/perl" verbose=1
 }

 cpan_build_do_install () {
--
Jens Rehsack - rehs...@gmail.com



signature.asc
Description: Message signed with OpenPGP
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] scripts/oe-init-bashrc: add more user-friendly oe-setup utility

2018-05-28 Thread Jens Rehsack


> Am 21.05.2018 um 21:04 schrieb Alexander Kanavin 
> :
> 
> On 05/21/2018 06:55 PM, Jens Rehsack wrote:
>> Move scripts/bashrc from meta-jens/scripts to oe-core to share user-friendly
>> oe builddir management with community. Using this script will help manage
>> multiple BSPs and targets like perl developers using perlbrew.
> 
> Please explain in detail what this does, and why is it superior to existing 
> tools. What are the typical usage scenarios? Where and how this should be 
> documented and tested? It is not a good idea to just add something into 
> scripts/, as no one will know or use it, and so it will just quietly bitrot.

Yes, the commit message is a bit ... weird.
Anyway - what it does should not be part of the commit message in detail, but 
maybe the help and the tool itself should be a bit reworked for being 
up-to-date.

However - let's prove the interest first, fixing the stuff a little bit later 
(I reserved the upcoming long weekend for Open-Source...)

When I log into my build machine, I just do

$ oe_builddir use ~/gpw-community-bsp/gpw-yocto-platform/

and I'm in the right location and have all environment settings prepared to 
start a bitbake immediately.

$ oe_builddir help
oe_builddir  [argument]
Available commands:
use use specified build-dir, setup when local.conf and/or 
bblayers.conf are missing
setup   create default builddir
avail   list possible build-dir's
layers  list layers used in BSP
repos   list repositories used in BSP
prune   prune old builds
off remove all settings from oe from shell environment

Tells you, what could be expected (very short).

It's all plain shell - so everyone can adopt it easily to local requirements. 
Further, it supports setting flags and tools within ''oe_builddir use''.
When you have a look at my layers I use for 
https://www.slideshare.net/JensRehsack/perl-onembeddeddevices - I need a 
special bitbake wrapper to build root and recoveryfs, and I have and additional 
environment variable I need to inject into recipes through bitbake.

$ cat ../sources/meta-jens/.oe-init
__oe_prepend_path "$(readlink -f $OEROOT/..)/meta-jens/scripts"
__oe_append_extrawhite "VLAN_GRP"
$ cat ../sources/meta-gpw/.oe-init
__oe_append_extrawhite "WANTED_ROOT_DEV"

When I set up the workshop environment after 2 years of abstinence - I realized 
that there are some cool improvements available, like updating all repos from 
upstream and some of the utility routines can be simplified. But this effort 
isn't sanely spent when the entire idea of a https://perlbrew.pl 
look-and-feel-alike is rejected.

>> +__oe_check_py () {
>> +# Make sure we're not using python v3.x. This check can't go into
>> +# sanity.bbclass because bitbake's source code doesn't even pass
>> +# parsing stage when used with python v3, so we catch it here so we
>> +# can offer a meaningful error message.
>> +py_v3_check=`/usr/bin/env python --version 2>&1 | grep "Python 3"`
>> +if [ "$py_v3_check" != "" ]; then
>> +echo >&2 "Bitbake is not compatible with python v3"
>> +echo >&2 "Please set up python v2 as your default python 
>> interpreter"
>> +return 1
>> +fi
> 
> Bitbake has in fact been compatible with Python 3.x for several releases. The 
> above check is not particularly useful, as /usr/bin/python nearly always 
> points to a 2.x version.

True, with many other details. I will happily fix this and all other quirks 
once we agree on above ;)

Cheers
--
Jens Rehsack - rehs...@gmail.com



signature.asc
Description: Message signed with OpenPGP
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 02/24] runqemu-extract-sdk: allow install debugfs on rootfs

2018-05-28 Thread Randy MacLeod

On 05/24/2018 10:48 PM, Robert Yang wrote:

Usually, the debugfs' (-dbg.tar.*) work follow is:

s/work follow/workflow/

1) Install regular rootfs to dir_foo
2) Install debugfs (-dbg.tar.*) to the same dir_foo

So we need allow install debugfs on rootfs.

So we need to allow installing the debugfs on top of the rootfs.


or at least, I think that's what you mean.
../Randy


Signed-off-by: Robert Yang 
---
  scripts/runqemu-extract-sdk | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/runqemu-extract-sdk b/scripts/runqemu-extract-sdk
index 2a0dd50..f4286ef 100755
--- a/scripts/runqemu-extract-sdk
+++ b/scripts/runqemu-extract-sdk
@@ -76,7 +76,9 @@ fi
  pseudo_state_dir="$SDK_ROOTFS_DIR/../$(basename 
"$SDK_ROOTFS_DIR").pseudo_state"
  pseudo_state_dir="$(readlink -f $pseudo_state_dir)"
  
-if [ -e "$pseudo_state_dir" ]; then

+debug_image="`echo $ROOTFS_TARBALL | grep '\-dbg\.tar\.'`"
+
+if [ -e "$pseudo_state_dir" -a -z "$debug_image" ]; then
echo "Error: $pseudo_state_dir already exists!"
echo "Please delete the rootfs tree and pseudo directory manually"
  echo "if this is really what you want."




--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] systemd: Add util-linux-umount to RDEPENDS

2018-05-28 Thread Mike Looijmans
Definitely, once the RDEPENDS is there, people will forget about it and it 
will still be there long after we've forgotten why it was put there...


On 18-05-18 15:20, Burton, Ross wrote:

Fixing busybox is a better solution. yes.

Ross

On 18 May 2018 at 13:24, Fabio Berton  wrote:

Yes, I tested this patch seems to work.

But bug report has:

"Yeah, this appears to be a limitation of busybox, and needs to be fixed in
busybox. We focus on util-linux proper, which has supported this option
since generations"

So, I add umount from util-linux because systemd focus on util-linux and
systemd recipe already has util-linux-mount.

If add patch to busybox is a better solution I can do this and send to list.

Fabio

On Thu, May 17, 2018 at 4:53 PM, Andre McCurdy  wrote:


On Thu, May 17, 2018 at 12:15 PM, Fabio Berton
 wrote:

Images with systemd fails on reboot with error:

[FAILED] Failed unmounting Temporary Directory (/tmp).

This happens because busybox umount command doesn't has -c
option. Add util-linux-umount that has this option to fix
this issue.

See details: https://github.com/systemd/systemd/issues/7786


That bug report mentions a fix to busybox. Since the fix is available
in upstream busybox, maybe better to just backport the patch to our
version of buysbox:


https://git.busybox.net/busybox/commit/?id=426134128112738c97a665170b21153ef0764b7d


Signed-off-by: Fabio Berton 
---
  meta/recipes-core/systemd/systemd_237.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_237.bb
b/meta/recipes-core/systemd/systemd_237.bb
index b7c2113255f..3b0f4580d49 100644
--- a/meta/recipes-core/systemd/systemd_237.bb
+++ b/meta/recipes-core/systemd/systemd_237.bb
@@ -478,7 +478,7 @@ FILES_${PN} = " ${base_bindir}/* \

  FILES_${PN}-dev += "${base_libdir}/security/*.la
${datadir}/dbus-1/interfaces/ ${sysconfdir}/rpm/macros.systemd"

-RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})
util-linux-agetty"
+RDEPENDS_${PN} += "kmod dbus util-linux-mount util-linux-umount udev (=
${EXTENDPKGV}) util-linux-agetty"
  RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG',
'serial-getty-generator', '', 'systemd-serialgetty', d)}"
  RDEPENDS_${PN} += "volatile-binds update-rc.d"

--
2.14.2

--



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



___

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




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



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


[OE-core] [PATCH 2/3] systemd: Define basename() for musl

2018-05-28 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 ...patible-basename-for-non-glibc-syste.patch | 33 +++
 meta/recipes-core/systemd/systemd_237.bb  |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0035-Define-glibc-compatible-basename-for-non-glibc-syste.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0035-Define-glibc-compatible-basename-for-non-glibc-syste.patch
 
b/meta/recipes-core/systemd/systemd/0035-Define-glibc-compatible-basename-for-non-glibc-syste.patch
new file mode 100644
index 00..736d525ad3
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0035-Define-glibc-compatible-basename-for-non-glibc-syste.patch
@@ -0,0 +1,33 @@
+From 5f1f064c81ea30acf93cfa0fb466b38f094f488c Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sun, 27 May 2018 08:36:44 -0700
+Subject: [PATCH] Define glibc compatible basename() for non-glibc systems
+
+Fixes builds with musl, even though systemd is adamant about
+using non-posix basename implementation, we have a way out
+
+Upstream-Status: Inappropriate [musl specific]
+
+Signed-off-by: Khem Raj 
+---
+ src/machine/machine-dbus.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/src/machine/machine-dbus.c b/src/machine/machine-dbus.c
+index 2d7806491b..9a3bdb1d76 100644
+--- a/src/machine/machine-dbus.c
 b/src/machine/machine-dbus.c
+@@ -29,6 +29,10 @@
+ #include 
+ #undef basename
+ 
++#if !defined(__GLIBC__)
++#define basename(src) (strrchr(src,'/') ? strrchr(src,'/')+1 : src)
++#endif
++
+ #include "alloc-util.h"
+ #include "bus-common-errors.h"
+ #include "bus-internal.h"
+-- 
+2.17.0
+
diff --git a/meta/recipes-core/systemd/systemd_237.bb 
b/meta/recipes-core/systemd/systemd_237.bb
index c4743a6b9d..2e6558ded1 100644
--- a/meta/recipes-core/systemd/systemd_237.bb
+++ b/meta/recipes-core/systemd/systemd_237.bb
@@ -53,6 +53,7 @@ SRC_URI += "file://touchscreen.rules \
file://0033-basic-macros-rename-noreturn-into-_noreturn_-8456.patch 
\
file://libmount.patch \

file://0034-Fix-format-truncation-compile-failure-by-typecasting.patch \
+   
file://0035-Define-glibc-compatible-basename-for-non-glibc-syste.patch \
"
 SRC_URI_append_qemuall = " 
file://0001-core-device.c-Change-the-default-device-timeout-to-2.patch"
 
-- 
2.17.0

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


[OE-core] [PATCH 1/3] systemd: Fix build with gcc8

2018-05-28 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 ...ange-the-default-device-timeout-to-2.patch |   9 +-
 ...ation-compile-failure-by-typecasting.patch | 173 ++
 meta/recipes-core/systemd/systemd_237.bb  |   1 +
 3 files changed, 177 insertions(+), 6 deletions(-)
 create mode 100644 
meta/recipes-core/systemd/systemd/0034-Fix-format-truncation-compile-failure-by-typecasting.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch
 
b/meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch
index b7b1ea0886..98c83620ff 100644
--- 
a/meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch
+++ 
b/meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch
@@ -1,4 +1,4 @@
-From 9820c165a9e559cf851e3beb60fad2571de4ded2 Mon Sep 17 00:00:00 2001
+From 7844e070745611a52e355b73e7890f360dd540d0 Mon Sep 17 00:00:00 2001
 From: Khem Raj 
 Date: Mon, 14 Dec 2015 04:09:19 +
 Subject: [PATCH] core/device.c: Change the default device timeout to 240 sec.
@@ -16,10 +16,10 @@ Signed-off-by: Khem Raj 
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/core/device.c b/src/core/device.c
-index 77601c552..98bf49ba2 100644
+index a43664d3b..4b16a8aec 100644
 --- a/src/core/device.c
 +++ b/src/core/device.c
-@@ -112,7 +112,7 @@ static void device_init(Unit *u) {
+@@ -113,7 +113,7 @@ static void device_init(Unit *u) {
   * indefinitely for plugged in devices, something which cannot
   * happen for the other units since their operations time out
   * anyway. */
@@ -28,6 +28,3 @@ index 77601c552..98bf49ba2 100644
  
  u->ignore_on_isolate = true;
  }
--- 
-2.16.1
-
diff --git 
a/meta/recipes-core/systemd/systemd/0034-Fix-format-truncation-compile-failure-by-typecasting.patch
 
b/meta/recipes-core/systemd/systemd/0034-Fix-format-truncation-compile-failure-by-typecasting.patch
new file mode 100644
index 00..e56061f41b
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0034-Fix-format-truncation-compile-failure-by-typecasting.patch
@@ -0,0 +1,173 @@
+From c2b3ebe112ebfd9f9e82fb1531ee225c3152ca83 Mon Sep 17 00:00:00 2001
+From: Patrick Uiterwijk 
+Date: Thu, 22 Feb 2018 19:41:30 +0100
+Subject: [PATCH] Fix format-truncation compile failure by typecasting USB IDs
+ (#8250)
+
+This patch adds safe_atoux16 for parsing an unsigned hexadecimal 16bit int, and
+uses that for parsing USB device and vendor IDs.
+
+This fixes a compile error with gcc-8 because while we know that USB IDs are 2 
bytes,
+the compiler does not know that.
+
+../src/udev/udev-builtin-hwdb.c:80:38: error: '%04X' directive output may be
+truncated writing between 4 and 8 bytes into a region of size between 2 and 6
+[-Werror=format-truncation=]
+
+Upstream-Status: Backport 
[https://github.com/systemd/systemd/commit/5547c12503a683290eaed47954ffcfb2d1bc03cd]
+
+Signed-off-by: Adam Williamson 
+Signed-off-by: Patrick Uiterwijk 
+---
+ src/basic/parse-util.c   | 24 ++
+ src/basic/parse-util.h   |  2 ++
+ src/test/test-parse-util.c   | 39 
+ src/udev/udev-builtin-hwdb.c | 13 ++--
+ 4 files changed, 71 insertions(+), 7 deletions(-)
+
+diff --git a/src/basic/parse-util.c b/src/basic/parse-util.c
+index 97533721d..ff3fc298a 100644
+--- a/src/basic/parse-util.c
 b/src/basic/parse-util.c
+@@ -532,6 +532,30 @@ int safe_atoi16(const char *s, int16_t *ret) {
+ return 0;
+ }
+ 
++int safe_atoux16(const char *s, uint16_t *ret) {
++char *x = NULL;
++unsigned long l;
++
++assert(s);
++assert(ret);
++
++s += strspn(s, WHITESPACE);
++
++errno = 0;
++l = strtoul(s, , 16);
++if (errno > 0)
++return -errno;
++if (!x || x == s || *x != 0)
++return -EINVAL;
++if (s[0] == '-')
++return -ERANGE;
++if ((unsigned long) (uint16_t) l != l)
++return -ERANGE;
++
++*ret = (uint16_t) l;
++return 0;
++}
++
+ int safe_atod(const char *s, double *ret_d) {
+ _cleanup_(freelocalep) locale_t loc = (locale_t) 0;
+ char *x = NULL;
+diff --git a/src/basic/parse-util.h b/src/basic/parse-util.h
+index 1eda1d7f9..727422056 100644
+--- a/src/basic/parse-util.h
 b/src/basic/parse-util.h
+@@ -54,6 +54,8 @@ int safe_atou8(const char *s, uint8_t *ret);
+ int safe_atou16(const char *s, uint16_t *ret);
+ int safe_atoi16(const char *s, int16_t *ret);
+ 
++int safe_atoux16(const char *s, uint16_t *ret);
++
+ static inline int safe_atou32(const char *s, uint32_t *ret_u) {
+ assert_cc(sizeof(uint32_t) == sizeof(unsigned));
+ return safe_atou(s, (unsigned*) ret_u);
+diff --git 

[OE-core] [PATCH 3/3] rpcsvc-proto: Update to 1.4

2018-05-28 Thread Khem Raj
Bring in an important fix
https://bugzilla.redhat.com/show_bug.cgi?id=1559181

Signed-off-by: Khem Raj 
---
 meta/recipes-extended/rpcsvc-proto/rpcsvc-proto.bb  |  4 ++--
 .../0001-Use-cross-compiled-rpcgen.patch| 13 +
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-extended/rpcsvc-proto/rpcsvc-proto.bb 
b/meta/recipes-extended/rpcsvc-proto/rpcsvc-proto.bb
index fdeafe283a..cb5b288c48 100644
--- a/meta/recipes-extended/rpcsvc-proto/rpcsvc-proto.bb
+++ b/meta/recipes-extended/rpcsvc-proto/rpcsvc-proto.bb
@@ -15,9 +15,9 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=0daaf958d5531ab86169ec6e275e1517"
 SECTION = "libs"
 DEPENDS += "rpcsvc-proto-native"
 
-PV = "1.3.1+git${SRCPV}"
+PV = "1.4+git${SRCPV}"
 
-SRCREV = "abcf24a09665b3def0f54c87d2acd4796de5d83a"
+SRCREV = "9bc3b5b785723cfff459b0c01b39d87d4bed975c"
 
 SRC_URI = "git://github.com/thkukuk/${BPN} \
file://0001-Use-cross-compiled-rpcgen.patch \
diff --git 
a/meta/recipes-extended/rpcsvc-proto/rpcsvc-proto/0001-Use-cross-compiled-rpcgen.patch
 
b/meta/recipes-extended/rpcsvc-proto/rpcsvc-proto/0001-Use-cross-compiled-rpcgen.patch
index 4ee4940295..208974004b 100644
--- 
a/meta/recipes-extended/rpcsvc-proto/rpcsvc-proto/0001-Use-cross-compiled-rpcgen.patch
+++ 
b/meta/recipes-extended/rpcsvc-proto/rpcsvc-proto/0001-Use-cross-compiled-rpcgen.patch
@@ -10,17 +10,14 @@ Signed-off-by: Khem Raj 
  rpcsvc/Makefile.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
-diff --git a/rpcsvc/Makefile.am b/rpcsvc/Makefile.am
-index 83867c0..4753242 100644
 a/rpcsvc/Makefile.am
-+++ b/rpcsvc/Makefile.am
-@@ -12,5 +12,5 @@ nodist_rpcsvc_HEADERS = klm_prot.h nlm_prot.h rstat.h 
spray.h \
+Index: git/rpcsvc/Makefile.am
+===
+--- git.orig/rpcsvc/Makefile.am
 git/rpcsvc/Makefile.am
+@@ -12,5 +12,5 @@ nodist_rpcsvc_HEADERS = klm_prot.h nlm_p
nfs_prot.h rquota.h sm_inter.h
  
  %.h: %.x
 -  $(top_builddir)/rpcgen/rpcgen -h -o $@ $<
 +  rpcgen -h -o $@ $<
  
--- 
-2.17.0
-
-- 
2.17.0

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


Re: [OE-core] [bitbake-devel] Generating extensible SDK fails because of missing LAYERSERIES_CORENAMES

2018-05-28 Thread Damien Riegel

On Sat, May 26, 2018 at 08:22:39AM -0400, Damien Riegel wrote:
> Hi,
> 
> 
> When generating the extended SDK, my setup fails with the following
> error:
> 
>   ERROR: Failed to generate filtered task list for extensible SDK:
>   ERROR: bitbake failed:
>   ERROR: Unable to start bitbake server
> 
> I digged into the issue and found out why bitbake doesn't
> start.
> 
> bitbake thinks layers are incompatible because they define
> LAYERSERIES_COMPAT but LAYERSERIES_CORENAMES is not set. So this check
> in cookerdata.py fails [1].
> 
> The reason this check fails is that the core `meta` layer is not listed
> in the generated BBLAYERS, because it's treated in a special way in
> populate_sdk_ext.bbclass [2]. So as this layer is not listed in
> BBLAYERS, the compatibility check fails and bitbake cannot start.
> 
> 
> Shouldn't `meta` simply be added to BBLAYERS as any other layer? If not,
> what is the proper way to solve my bug?

I think it got confused because the `meta` layer is contained in a
folder named `meta` as well.

I managed to go further in my build with the following snippet:

--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -207,7 +207,7 @@ python copy_buildsystem () {
 sdkbblayers = []
 corebase = os.path.basename(d.getVar('COREBASE'))
 for layer in layers_copied:
-if corebase == os.path.basename(layer):
+if corebase == layer:
 conf_bbpath = os.path.join('layers', layer, 'bitbake')
 else:
 sdkbblayers.append(layer)

> 
> [1] 
> https://github.com/openembedded/bitbake/blob/master/lib/bb/cookerdata.py#L397
> [2] 
> https://github.com/openembedded/openembedded-core/blob/master/meta/classes/populate_sdk_ext.bbclass#L208
> 
> Thank you,
> -- 
> Damien
> -- 
> ___
> bitbake-devel mailing list
> bitbake-de...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/bitbake-devel

-- 
Damien Riegel 
Free Software Consultant
Tel: +1 514 276 5468 (ext: 355)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [V2][PATCH] busybox: update to 1.28.3

2018-05-28 Thread akuster808


On 05/22/2018 06:19 PM, Andre McCurdy wrote:
> On Tue, May 22, 2018 at 5:48 PM, Randy MacLeod
>  wrote:
>> On 05/22/2018 07:06 PM, Andre McCurdy wrote:
>> ...
>>> Building before and after Armin's patch and then diffing .config files
>>> in each build directory gives:
>>>
>> I didn't know what all of these configs were so I've
>> listed them below and stated a straw-man opinion as
>> to whether to keep them or not.
> Thanks for digging in to the details!
>
>>> Old 1.27.2 specific config options removed:
>>>
>>> -CONFIG_FEATURE_ADDGROUP_LONG_OPTIONS=y
>>> -CONFIG_FEATURE_ADDUSER_LONG_OPTIONS=y
>>> -CONFIG_FEATURE_ENV_LONG_OPTIONS=y
>>> -CONFIG_FEATURE_HWCLOCK_LONG_OPTIONS=y
>>> -CONFIG_FEATURE_MKDIR_LONG_OPTIONS=y
>> I'm okay with following upstream busybox wrt long options so
>> we can drop this.
> There's no real choice but to drop these (ie they disappear when you
> run "make oldconfig").

There is only LONG_OPTIONS now  with ADDGROUP, ADDUSER,  etc controlling
if its enabled.
>>> New 1.28.3 specific options added:
>>>
>>> +CONFIG_BB_ARCH=y
>>
>> Adds 'arch' which is the same output as 'uname -m' but
>> I always use arch and didn't know off-hand that uname -m was the same.
>>
>> Keep it.
>>
>>> +CONFIG_FEATURE_CATN=y
>>   This adds an option to cat:
>>-n numbers all output lines while -b numbers nonempty output lines.
>>   The commit that added this feature says:
>>  a2bdc5c55 cat: allow compiling out -n and -b
>>   so since previously the feature was always available,
>>
>> I'm okay with keeping it.
>>
>>> +CONFIG_FEATURE_SH_READ_FRAC=y
>>
>>   Enables a fractional second read timeout for the shell builtin.
>>   bool "read -t N.NNN support (+110 bytes)"
>>   Enable support for fractional second timeout in read builtin.
>>
>> Potentially useful, keep it.
>>
>>> +CONFIG_FEATURE_SWAPONOFF_LABEL=y
>>
>>   This allows for specifying a device by label or uuid, rather than by
>>   name. This feature utilizes the same functionality as blkid/findfs.
>>
>> Useful. Keep it.
>>
>>> +CONFIG_FEATURE_VOLUMEID_MINIX=y
>>
>> I don't know of a case where this would be generally useful.
>>
>> Omit.
>>
>>> +CONFIG_FEATURE_XARGS_SUPPORT_ARGS_FILE=y
>> xargs: support -a FILE
>>
>> The GNU-specific option -a lets xargs read the arguments from a file
>> rather than from stdin.
>>
>> This is particularly convenient when debugging in gdb interactively,
>> and it might be of more general use.
>>
>> Huh... what?
>> Digging through the findutils repo, I see that there's a better explaination
>> in the findutils/NEWS file from 2004(!):
>>
>> *** xargs can now read a list of arguments from a named file, allowing
>> the invoked program to use the same stdin as xargs started with
>> (for example ``xargs --arg-file=todo emacs'').
>>
>> Keep it (I suppose).
>>
>>> +CONFIG_FEATURE_XARGS_SUPPORT_PARALLEL=y
>>
>> From: https://bugs.busybox.net/show_bug.cgi?id=9511
>> Example:
>> find samplegz | xargs -n1 -P4 sh parse.sh
>>
>> Costs 241 bytes.
>>
>> Keep it.
>>
>> The next group are described below but
>> I've put my conclusions after each config.
>>
>>> +CONFIG_HEXEDIT=y
>> Drop it.
>>
>>> +CONFIG_NUKE=y
>> Drop it.
>>
>>> +CONFIG_RESUME=y
>> Drop it -- maybe?
>>
>>> +CONFIG_RUN_INIT=y
>> Drop it.
>>
>>> +CONFIG_SETFATTR=y
>> Drop it.
>>
>>> So new applets hexedit, nuke, etc, are going to sneak in to our builds
>>> unless we refresh our defconfig to disable them.
>>>
>>
>> Here is the rough estimate of the new applet sizes:
>>
>> $ git show 38da4c4420ea6d7b3cf120c0902458e7d8256560 | \
>>grep "^+//config:.*bool"
>> +//config:  bool "nuke (2.4 kb)"
>> +//config:  bool "resume (3.3 kb)"
>> +//config:  bool "run-init (7.5 kb)"
>> +//config:  bool "hexedit (20 kb)"
>> +//config:  bool "setfattr (3.6 kb)"
>>
>>
>> and the commit that added most of the applets that includes
>> a brief explanation of the applet's function:
>>
>> commit ab77e81a8527fa11a4f9392d97c2da037d6f4f98
>> Author: Denys Vlasenko 
>> Date:   Fri Aug 18 19:15:29 2017 +0200
>>
>> klibc-utils: new applets: resume, nuke, minips
>>
>> minips is a pure alias to ps,
>> just in case someone needs 100% klibc-utils compat.
>>
>> nuke is a primitive version of "rm -rf" without
>> options and error checks. ~30 bytes.
>>
>> resume is a tool for initramfs which resumes from
>> a given block device.
>>
>> function old new   delta
>> resume_main- 582+582
>> packed_usage   31640   31712 +72
>> nuke_main  -  28 +28
>> xstrtoull  -  24 +24
>> applet_names26462665 +19
>> applet_main 15321544 +12
>> applet_suid   

Re: [OE-core] [PATCH 6/8] xserver-xorg: upgrade 1.19.6 -> 1.20.0

2018-05-28 Thread akuster808


On 05/23/2018 04:01 AM, Burton, Ross wrote:
> This is breaking a number of other bits of X:
>
> - xf86-video-intel (was DRI1 removed or disabled in 1.20?)
> - xf86-input-mouse
> - xf86-video-omapfb

hmm, will double check

- armin
> Ross
>
> On 19 May 2018 at 03:13, Armin Kuster  wrote:
>> From: Armin Kuster 
>>
>> Signed-off-by: Armin Kuster 
>> ---
>>  ...1-configure.ac-Fix-check-for-CLOCK_MONOTONIC.patch | 19 
>> +--
>>  ...{xserver-xorg_1.19.6.bb => xserver-xorg_1.20.0.bb} |  4 ++--
>>  2 files changed, 11 insertions(+), 12 deletions(-)
>>  rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.19.6.bb => 
>> xserver-xorg_1.20.0.bb} (89%)
>>
>> diff --git 
>> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-configure.ac-Fix-check-for-CLOCK_MONOTONIC.patch
>>  
>> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-configure.ac-Fix-check-for-CLOCK_MONOTONIC.patch
>> index 16ec3ed..020a1cf 100644
>> --- 
>> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-configure.ac-Fix-check-for-CLOCK_MONOTONIC.patch
>> +++ 
>> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-configure.ac-Fix-check-for-CLOCK_MONOTONIC.patch
>> @@ -1,12 +1,13 @@
>> -Discover monotonic clock using compile-time check
>> +From 8a91316c4a38f20e7866289f3d779a037d27a129 Mon Sep 17 00:00:00 2001
>> +From: Jussi Kukkonen 
>> +Date: Mon, 12 Dec 2016 12:11:39 +0200
>> +Subject: [PATCH] Discover monotonic clock using compile-time check
>>
>>  monotonic clock check does not work when cross-compiling.
>>
>>  Upstream-Status: Denied [Does not work on OpenBSD]
>>  Signed-off-by: Jussi Kukkonen 
>>
>> -
>> -
>>  Original patch follows:
>>
>>  When xorg-xserver is being cross-compiled, there is currently no way
>> @@ -21,15 +22,16 @@ monotonic clock is available. This check can run just 
>> fine when we are
>>  cross-compiling.
>>
>>  Signed-off-by: David James 
>> +
>>  ---
>>   configure.ac | 17 +++--
>>   1 file changed, 7 insertions(+), 10 deletions(-)
>>
>>  diff --git a/configure.ac b/configure.ac
>> -index f7ab48c..26e85cd 100644
>> +index 2b21667..786e002 100644
>>  --- a/configure.ac
>>  +++ b/configure.ac
>> -@@ -1048,19 +1048,16 @@ if ! test "x$have_clock_gettime" = xno; then
>> +@@ -984,19 +984,16 @@ if ! test "x$have_clock_gettime" = xno; then
>>   CPPFLAGS="$CPPFLAGS -D_POSIX_C_SOURCE=200112L"
>>   fi
>>
>> @@ -54,8 +56,5 @@ index f7ab48c..26e85cd 100644
>>  -   [MONOTONIC_CLOCK="cross compiling"])
>>  +]])],[MONOTONIC_CLOCK=yes], [MONOTONIC_CLOCK=no])
>>
>> - LIBS="$LIBS_SAVE"
>> - CPPFLAGS="$CPPFLAGS_SAVE"
>> ---
>> -2.1.4
>> -
>> + if test "$MONOTONIC_CLOCK" = "cross compiling"; then
>> + AC_CHECK_DECL([CLOCK_MONOTONIC],[MONOTONIC_CLOCK="guessing 
>> yes"],[MONOTONIC_CLOCK=no],[#include ])
>> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.6.bb 
>> b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.20.0.bb
>> similarity index 89%
>> rename from meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.6.bb
>> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg_1.20.0.bb
>> index c680cf9..620eb7b 100644
>> --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.6.bb
>> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.20.0.bb
>> @@ -6,8 +6,8 @@ SRC_URI += "file://musl-arm-inb-outb.patch \
>>  file://0003-Remove-check-for-useSIGIO-option.patch \
>>  
>> file://0001-xf86pciBus.c-use-Intel-ddx-only-for-pre-gen4-hardwar.patch \
>>  "
>> -SRC_URI[md5sum] = "3e4ff034a331aed2322b078694a8"
>> -SRC_URI[sha256sum] = 
>> "a732502f1db000cf36a376cd0c010ffdbf32ecdd7f1fa08ba7f5bdf9601cc197"
>> +SRC_URI[md5sum] = "c1ca1ea0a905ea788da03c77cc38b06e"
>> +SRC_URI[sha256sum] = 
>> "9d967d185f05709274ee0c4f861a4672463986e550ca05725ce27974f550d3e6"
>>
>>  # These extensions are now integrated into the server, so declare the 
>> migration
>>  # path for in-place upgrades.
>> --
>> 2.7.4
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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


Re: [OE-core] [morty][PATCH 1/3] package.bbclass: use single quotes for path passed to file in isELF()

2018-05-28 Thread akuster808


On 05/25/2018 12:16 PM, Andre McCurdy wrote:
> Apparently there are recipes in the wild which generate files with
> filenames containing '$' characters - which cause errors during
> packaging.
>
> Instead of adding another special case to escape '$' characters when
> constructing the command passed to oe.utils.getstatusoutput(), switch
> to using single quotes to quote the path - and therefore make isELF()
> consistent with the way filenames and paths are quoted by every other
> caller of oe.utils.getstatusoutput() in oe-core.
this series in stable/pyro-mnut

- armin
> Signed-off-by: Andre McCurdy 
> Signed-off-by: Ross Burton 
> (cherry picked from commit 7877761534b0c2492da6289e9f2269d41b6ed464)
> Signed-off-by: Andre McCurdy 
> ---
>  meta/classes/package.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index a6f0a7a..531ca4a 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -892,7 +892,7 @@ python split_and_strip_files () {
>  # 16 - kernel module
>  def isELF(path):
>  type = 0
> -ret, result = oe.utils.getstatusoutput("file \"%s\"" % 
> path.replace("\"", "\\\""))
> +ret, result = oe.utils.getstatusoutput("file '%s'" % path)
>  
>  if ret:
>  msg = "split_and_strip_files: 'file %s' failed" % path

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


[OE-core] [v3][PATCH] bind: update to 9.12.1

2018-05-28 Thread Armin Kuster
[v3]
Made formating and spelling changes per Martin

[v2]
Remove python3 in default PACKACKECONFIG
include https://patchwork.openembedded.org/patch/148257/
Because of the newly added dependency on meta-python, the python(3)
packageconfig is no longer "default-on".

Signed-off-by: Martin Hundebøll 

LIC_FILES_CHKSUM changed do to updated year
Requires python-ply package in core

removed:
dont-test-on-host.patch, no longer impliemented
drop use-python3-and-fix-install-lib-path.patch, they added the ability to pass 
in lib dir loctions
drop bind-confgen-build-unix.o-once.patch, fix included in update

Refresh other patches:
add python3 flag for PACKAGECONFIG to pull in python
add new config option --with-eddsa=

Signed-off-by: Armin Kuster 
Acked-by: Martin Hundebøll 
---
 ...0001-build-use-pkg-config-to-find-libxml2.patch | 13 +++---
 ...-gen.c-extend-DIRNAMESIZE-from-256-to-512.patch | 13 +++---
 .../0001-lib-dns-gen.c-fix-too-long-error.patch| 13 +++---
 .../bind/bind/bind-confgen-build-unix.o-once.patch | 48 --
 ...-searching-for-json-headers-searches-sysr.patch | 13 +++---
 .../bind/bind/dont-test-on-host.patch  | 17 
 .../use-python3-and-fix-install-lib-path.patch | 36 
 .../bind/{bind_9.10.6.bb => bind_9.12.1.bb}| 35 +---
 8 files changed, 41 insertions(+), 147 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/bind/bind/bind-confgen-build-unix.o-once.patch
 delete mode 100644 meta/recipes-connectivity/bind/bind/dont-test-on-host.patch
 delete mode 100644 
meta/recipes-connectivity/bind/bind/use-python3-and-fix-install-lib-path.patch
 rename meta/recipes-connectivity/bind/{bind_9.10.6.bb => bind_9.12.1.bb} (78%)

diff --git 
a/meta/recipes-connectivity/bind/bind/0001-build-use-pkg-config-to-find-libxml2.patch
 
b/meta/recipes-connectivity/bind/bind/0001-build-use-pkg-config-to-find-libxml2.patch
index 1e23c0f..6d73e18 100644
--- 
a/meta/recipes-connectivity/bind/bind/0001-build-use-pkg-config-to-find-libxml2.patch
+++ 
b/meta/recipes-connectivity/bind/bind/0001-build-use-pkg-config-to-find-libxml2.patch
@@ -15,11 +15,11 @@ Signed-off-by: Kai Kang 
  configure.in | 23 +++
  1 file changed, 3 insertions(+), 20 deletions(-)
 
-diff --git a/configure.in b/configure.in
-index 4da73a4..6f2a754 100644
 a/configure.in
-+++ b/configure.in
-@@ -2282,26 +2282,9 @@ case "$use_libxml2" in
+Index: bind-9.12.1/configure.in
+===
+--- bind-9.12.1.orig/configure.in
 bind-9.12.1/configure.in
+@@ -2569,26 +2569,9 @@ case "$use_libxml2" in
DST_LIBXML2_INC=""
;;
auto|yes)
@@ -49,6 +49,3 @@ index 4da73a4..6f2a754 100644
fi
;;
  esac
--- 
-2.1.4
-
diff --git 
a/meta/recipes-connectivity/bind/bind/0001-gen.c-extend-DIRNAMESIZE-from-256-to-512.patch
 
b/meta/recipes-connectivity/bind/bind/0001-gen.c-extend-DIRNAMESIZE-from-256-to-512.patch
index 1215093..9d87303 100644
--- 
a/meta/recipes-connectivity/bind/bind/0001-gen.c-extend-DIRNAMESIZE-from-256-to-512.patch
+++ 
b/meta/recipes-connectivity/bind/bind/0001-gen.c-extend-DIRNAMESIZE-from-256-to-512.patch
@@ -7,11 +7,11 @@ Signed-off-by: Chen Qi 
  lib/dns/gen.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
-diff --git a/lib/dns/gen.c b/lib/dns/gen.c
-index 7a7dafb..51a0435 100644
 a/lib/dns/gen.c
-+++ b/lib/dns/gen.c
-@@ -148,7 +148,7 @@ static const char copyright[] =
+Index: bind-9.12.1/lib/dns/gen.c
+===
+--- bind-9.12.1.orig/lib/dns/gen.c
 bind-9.12.1/lib/dns/gen.c
+@@ -130,7 +130,7 @@ static const char copyright[] =
  #define TYPECLASSBUF (TYPECLASSLEN + 1)
  #define TYPECLASSFMT "%" STR(TYPECLASSLEN) "[-0-9a-z]_%d"
  #define ATTRIBUTESIZE 256
@@ -20,6 +20,3 @@ index 7a7dafb..51a0435 100644
  
  static struct cc {
struct cc *next;
--- 
-1.9.1
-
diff --git 
a/meta/recipes-connectivity/bind/bind/0001-lib-dns-gen.c-fix-too-long-error.patch
 
b/meta/recipes-connectivity/bind/bind/0001-lib-dns-gen.c-fix-too-long-error.patch
index 1ed858c..1e34746 100644
--- 
a/meta/recipes-connectivity/bind/bind/0001-lib-dns-gen.c-fix-too-long-error.patch
+++ 
b/meta/recipes-connectivity/bind/bind/0001-lib-dns-gen.c-fix-too-long-error.patch
@@ -13,11 +13,11 @@ Signed-off-by: Robert Yang 
  lib/dns/gen.c |4 
  1 file changed, 4 insertions(+)
 
-diff --git a/lib/dns/gen.c b/lib/dns/gen.c
-index 51a0435..3d7214f 100644
 a/lib/dns/gen.c
-+++ b/lib/dns/gen.c
-@@ -148,7 +148,11 @@ static const char copyright[] =
+Index: bind-9.12.1/lib/dns/gen.c
+===
+--- bind-9.12.1.orig/lib/dns/gen.c
 bind-9.12.1/lib/dns/gen.c
+@@ -130,7 +130,11 @@ static const char 

Re: [OE-core] [PATCH] recipe_links.bbclass: introduction

2018-05-28 Thread Mark Asselstine
On Monday, May 28, 2018 9:52:16 AM EDT Alexander Kanavin wrote:
> (don't forget devtool also has 'edit/find/update-recipe' commands).

Since it keys off the FILE and BBINCLUDED as parsed it follows along with the 
devtool workspaces just fine. There should be no confusion added and if 
anything seeing the link to the bbappend in the devtool workspace being 
included in the links should add a level of comfort.

This was sent for RFC quite a while ago, I am only now getting around to 
pushing for proper inclusion.

Mark

> 
> Alex
> 
> 2018-05-28 16:50 GMT+03:00 Alexander Kanavin :
> > 2018-05-28 16:38 GMT+03:00 Mark Asselstine 
:
> >> This is a new class which can be used (for example via USER_CLASSES in
> >> local.conf) to make your build more development friendly. When
> >> included this class will create symlinks to the various bb and
> >> bbappend files in WORKDIR.
> > 
> > I do think this is a great idea, I only want to ask, how well this
> > integrates with devtool workflows?
> > Particularly, 'devtool add/modify/upgrade' do their own recipe copying
> > and manipulation, so we should make sure this does not increase the
> > confusion.
> > 
> > Alex




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


Re: [OE-core] [PATCH] recipe_links.bbclass: introduction

2018-05-28 Thread Alexander Kanavin
(don't forget devtool also has 'edit/find/update-recipe' commands).

Alex

2018-05-28 16:50 GMT+03:00 Alexander Kanavin :
> 2018-05-28 16:38 GMT+03:00 Mark Asselstine :
>> This is a new class which can be used (for example via USER_CLASSES in
>> local.conf) to make your build more development friendly. When
>> included this class will create symlinks to the various bb and
>> bbappend files in WORKDIR.
>
> I do think this is a great idea, I only want to ask, how well this
> integrates with devtool workflows?
> Particularly, 'devtool add/modify/upgrade' do their own recipe copying
> and manipulation, so we should make sure this does not increase the
> confusion.
>
> Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] recipe_links.bbclass: introduction

2018-05-28 Thread Alexander Kanavin
2018-05-28 16:38 GMT+03:00 Mark Asselstine :
> This is a new class which can be used (for example via USER_CLASSES in
> local.conf) to make your build more development friendly. When
> included this class will create symlinks to the various bb and
> bbappend files in WORKDIR.

I do think this is a great idea, I only want to ask, how well this
integrates with devtool workflows?
Particularly, 'devtool add/modify/upgrade' do their own recipe copying
and manipulation, so we should make sure this does not increase the
confusion.

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


[OE-core] [PATCH] recipe_links.bbclass: introduction

2018-05-28 Thread Mark Asselstine
This is a new class which can be used (for example via USER_CLASSES in
local.conf) to make your build more development friendly. When
included this class will create symlinks to the various bb and
bbappend files in WORKDIR.

Normally when you are debugging or extending a package's recipe files
a developer will employ one of a few indirect techniques to determine
where bb and bbappends files associated with a recipe exist. For
example they might use bitbake-layers show-recipes or similar, or
simply rely on their experience to guide them. Even after working with
openembedded for serveral years now I find these techniques tedious
and time consuming, and sometimes even hit and miss.

Since the whereabouts of these files are already stored in various
files at parse time we can create symlinks to simplify the task of
finding these files, making them available in WORKDIR for easy
inpsection and in a convenient location if using devshel for instance.

For now this work is completely optional but we could conceivable make
this the default behavior if folks find it is convenient and the cost
of performing these operations across all builds is minimal enough.

recipe_links can safely be added to USER_CLASSES for existing builds,
care has been taken to avoid this action causing anything to be
rebuilt. After this has been added you can either 'bitbake  -C
unpack' or 'bitbake  -c create_recipe_links' to cause the
links to be created in the WORKDIR for the specified recipe.

Signed-off-by: Mark Asselstine 
---
 meta/classes/recipe_links.bbclass | 79 +++
 meta/conf/documentation.conf  |  1 +
 2 files changed, 80 insertions(+)
 create mode 100644 meta/classes/recipe_links.bbclass

diff --git a/meta/classes/recipe_links.bbclass 
b/meta/classes/recipe_links.bbclass
new file mode 100644
index 000..ea97605
--- /dev/null
+++ b/meta/classes/recipe_links.bbclass
@@ -0,0 +1,79 @@
+# Create symlink in WORKDIR to the various bb and
+# bbappend files used to define the package ops
+
+# Create a symlink given src and dst paths
+def create_link(d, src, dst):
+if os.path.islink(dst):
+try:
+os.unlink(dst)
+except OSError as err:
+bb.error("  Failed to cleanup old link %s: %s"
+ % (os.path.basename(dst), os.strerror(err.errno)))
+return False
+
+
+try:
+os.symlink(src, dst)
+except OSError as err:
+bb.error("  Failed to create file link for %s: %s"
+ % (src, os.strerror(err.errno)))
+return False
+
+return True
+
+# Ensure the work is scheduled. We do this as a func
+# to avoid sig changes causing things to be rebuilt
+# when the class is added/removed after the fact.
+do_unpack[postfuncs] += "create_recipe_links "
+do_unpack[vardepsexclude] += "create_recipe_links "
+python create_recipe_links() {
+import re
+import glob
+
+workdir = d.getVar('WORKDIR')
+
+# Main recipe file
+bb.note("Add main recipe file link:")
+bb_path = d.getVar('FILE')
+bb_filename = os.path.basename(bb_path)
+bb_destname = "%s/%s" % (workdir, bb_filename)
+bb.note("  Linking %s" % bb_path)
+if not create_link(d, bb_path, bb_destname):
+return False
+
+# Cleanup old bbappends links
+bb.note("Removing old bbappend links:")
+pn = d.getVar('PN')
+files = glob.glob('%s/[0-9][0-9]_%s.bbappend' % (workdir,pn))
+files += glob.glob('%s/[0-9][0-9]_%s_*.bbappend' % (workdir, pn))
+for filename in files:
+bb.note("  Removing: %s" % filename)
+try:
+os.unlink(filename)
+except OSError as err:
+bb.error("  Failed to cleanup old link %s: %s" %
+ (os.path.basename(filename), os.strerror(err.errno)))
+return False
+
+# Add bbappends links
+bb.note("Adding bbappend links:")
+included_files = d.getVar('BBINCLUDED').split()
+bbappend_re = re.compile( r".*/%s(_[^/]*)?\.bbappend$" % re.escape(pn))
+for filename in included_files:
+if bbappend_re.match(filename):
+bb.note("  Linking %s" % filename)
+destname = "00_%s" % (os.path.basename(filename))
+while os.path.exists("%s/%s" % (workdir, destname)):
+ destname = str(int(destname[:2]) + 1).zfill(2) + destname[2:]
+if not create_link(d, filename, "%s/%s" % (workdir, destname)):
+return False
+
+return True
+}
+
+# In addition to the func we want to make things able to be (re)run
+# easily by the user so ensure it is available as a task.
+addtask do_create_recipe_links
+python do_create_recipe_links() {
+bb.build.exec_func("create_recipe_links", d)
+}
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 254f8f1..2f6e686 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -21,6 +21,7 @@ do_devpyshell[doc] = 

[OE-core] dealing with CMake ExternalProject (was: Re: [PATCH] cmake: Export SSH_AUTH_SOCK for cmake at configure)

2018-05-28 Thread André Draszik
On Mon, 2018-05-28 at 11:55 +0300, Hannu Lounento wrote:
> On 25/05/18 18:34, Christopher Larson wrote:
> > We should probably investigate if it's possible to shift those into 
> > do_fetch eventually. Contacting upstream during do_configure is not
> > kosher.
> 
> The reason for fetching during configure is that the CMake build system 
> in the git repository in question (later referred to as the "parent 
> project") uses the ExternalProject keyword [1], which "creates a custom 
> target to drive download, update/patch, configure, build, install and 
> test steps of an external project" [1].
> 
> The external project that the aforementioned CMake build system uses is 
> gtest (later referred to as the "child project"), which is many times 
> built as part of a parent project. Usually git submodule is used to 
> clone child projects, which works nicely with Bitbake with the gitsm 
> fetcher. In this particular case the parent project uses the 
> ExternalProject keyword instead, which is one of the options suggested 
> in gtest's documentation [2]. While the parent project is not a public 
> open source project, it is not in our direct control either and hence we 
> cannot just change it to use git submodule instead.

You can simply instruct ExternalProject to refer to an existing (local)
directory, instead of a remote git repository.  Either by patching it in
your parent project's recipe, or trying to get upstream to integrate such a
change:

Something along the lines of this works fine for me here:

CMakeLists.txt:

find_path(GTEST_SRC_LOCATION
NAMES googlemock/src/gmock-all.cc googletest/src/gtest-all.cc
HINTS ENV GTEST_SRC_ROOT
PATHS "/usr/src/googletest"
NO_DEFAULT_PATH
)
if (GTEST_SRC_LOCATION)
set(GTEST_GIT_REPOSITORY "" CACHE INTERNAL "googletest git repository")
set(GTEST_GIT_TAG"" CACHE INTERNAL "googletest git tag")
else ()
set(GTEST_GIT_REPOSITORY "https://github.com/google/googletest.git; CACHE 
INTERNAL "googletest git repository")
set(GTEST_GIT_TAG"release-1.8.0" CACHE INTERNAL "googletest git 
tag")
set(GTEST_SRC_LOCATION "${CMAKE_CURRENT_BINARY_DIR}/googletest-src" CACHE 
INTERNAL "googletest source location")
endif ()
configure_file(CMakeLists.txt.in googletest-download/CMakeLists.txt)


And CMakeLists.txt.in contains (amongst others):

include(ExternalProject)
ExternalProject_Add(googletest
  GIT_REPOSITORY${GTEST_GIT_REPOSITORY}
  GIT_TAG   ${GTEST_GIT_TAG}
  SOURCE_DIR"${GTEST_SRC_LOCATION}"


This way, you can have an independent recipe that downloads gtest, and the
recipe of your parent project just needs to ensure to depend on the
downloaded gtest and set the GTEST_SRC_ROOT environment variable. There even
is a debian package for the gtest source code (hence the /usr/src/googletest
above), so not only yocto builds, but even local workstation builds outside
yocto would benefit from such a change.

No need for dramatic changes (such as switching to git submodules).


Cheers,
Andre'


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


Re: [OE-core] [PATCH] cmake: Export SSH_AUTH_SOCK for cmake at configure

2018-05-28 Thread Hannu Lounento

On 25/05/18 18:34, Christopher Larson wrote:
We should probably investigate if it's possible to shift those into 
do_fetch eventually. Contacting upstream during do_configure is not kosher.


The reason for fetching during configure is that the CMake build system 
in the git repository in question (later referred to as the "parent 
project") uses the ExternalProject keyword [1], which "creates a custom 
target to drive download, update/patch, configure, build, install and 
test steps of an external project" [1].


The external project that the aforementioned CMake build system uses is 
gtest (later referred to as the "child project"), which is many times 
built as part of a parent project. Usually git submodule is used to 
clone child projects, which works nicely with Bitbake with the gitsm 
fetcher. In this particular case the parent project uses the 
ExternalProject keyword instead, which is one of the options suggested 
in gtest's documentation [2]. While the parent project is not a public 
open source project, it is not in our direct control either and hence we 
cannot just change it to use git submodule instead.


Another option _might_ be to run CMake in two phases: the first pass 
would just run the ExternalProject keyword and the second the real 
configure step. We are not aware of a way to run CMake in multiple 
phases though. Also cmake.bbclass (currently) doesn't have anything 
related to the do_fetch step. Thirdly, I assume that running the 
ExternalProject keyword as the first pass during do_fetch would also 
configure and build the child project, which would then again conflict 
with Bitbake's later build steps such as do_configure and do_compile.


I think it would be a valid use case to support fetching by the 
ExternalProject keyword even during do_configure because a recipe 
maintainer does not necessarily have direct control over the upstream 
project.


If it is possible to resolve the issue e.g. by changing cmake.bbclass to 
call CMake differently or other means, any guidance is appreciated.


[1] https://cmake.org/cmake/help/latest/module/ExternalProject.html
[2] 
https://github.com/google/googletest/blob/master/googletest/README.md#incorporating-into-an-existing-cmake-project



Thanks,
--
Hannu Lounento
hannu.loune...@vaisala.com



On Fri, May 25, 2018 at 5:52 AM Niko Mauno > wrote:


Update cmake_do_configure() to export a set SSH_AUTH_SOCK variable
before calling cmake.

Otherwise, if cmake call during cmake_do_configure() resorts to
ExternalProject directive containing a GIT_REPOSITORY entry, and git
authentication scheme is based on SSH agent forwarding, it fails
followingly

   | Cloning into 'foo'...
   | Permission denied (publickey).
   | fatal: Could not read from remote repository.
   |
   | Please make sure you have the correct access rights
   | and the repository exists.
   |
   | ...
   |
   | CMake Error at .../tmp/foo-gitclone.cmake:66 (message):
   |   Failed to clone repository: 'ssh://...

Signed-off-by: Niko Mauno >
---
  meta/classes/cmake.bbclass | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fcfd5dda4f..82d36be8ff 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -137,6 +137,11 @@ cmake_do_configure() {
                 oecmake_sitefile=
         fi

+       # Allow cmake to perform eg. git clone in context where
authentication relies on SSH agent forwarding
+       if [ "${SSH_AUTH_SOCK}" ] ; then
+               export SSH_AUTH_SOCK=${SSH_AUTH_SOCK}
+       fi
+
         cmake \
           ${OECMAKE_GENERATOR_ARGS} \
           $oecmake_sitefile \
-- 
2.11.0


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics



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


[OE-core] [PATCH 6/7] image.bbclass, populate_sdk_base.bbclass: make all variants of qemuwrapper-cross available in sysroots

2018-05-28 Thread Alexander Kanavin
The variants are needed in particular when executing postinst_intercepts as
those may require running binaries built for different architectures and
against different sets of library paths, when multilib is in use (or nativesdk 
host
packages are installed), so a single global variant of the script was not 
working.

I do understand expanding PATH and DEPENDS in this manner is hackish, however
every other approach I could think of is worse.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/image.bbclass | 3 ++-
 meta/classes/populate_sdk_base.bbclass | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 2247b305da8..16c6b1256e2 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -11,9 +11,10 @@ POPULATE_SDK_POST_TARGET_COMMAND += 
"rootfs_sysroot_relativelinks; "
 
 LICENSE ?= "MIT"
 PACKAGES = ""
-DEPENDS += "${MLPREFIX}qemuwrapper-cross depmodwrapper-cross"
+DEPENDS += "${@' '.join(["%s-qemuwrapper-cross" % m for m in 
d.getVar("MULTILIB_VARIANTS").split()])} qemuwrapper-cross depmodwrapper-cross"
 RDEPENDS += "${PACKAGE_INSTALL} ${LINGUAS_INSTALL}"
 RRECOMMENDS += "${PACKAGE_INSTALL_ATTEMPTONLY}"
+PATH_prepend = "${@":".join(all_multilib_tune_values(d, 
'STAGING_BINDIR_CROSS').split())}:"
 
 INHIBIT_DEFAULT_DEPS = "1"
 
diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index 3da350747e2..aae6786e586 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -46,7 +46,8 @@ TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
 
 SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
-SDK_DEPENDS = "virtual/fakeroot-native xz-native cross-localedef-native 
${MLPREFIX}qemuwrapper-cross"
+SDK_DEPENDS = "virtual/fakeroot-native xz-native cross-localedef-native 
nativesdk-qemuwrapper-cross ${@' '.join(["%s-qemuwrapper-cross" % m for m in 
d.getVar("MULTILIB_VARIANTS").split()])} qemuwrapper-cross"
+PATH_prepend = 
"${STAGING_DIR_HOST}${SDKPATHNATIVE}${bindir}/crossscripts:${@":".join(all_multilib_tune_values(d,
 'STAGING_BINDIR_CROSS').split())}:"
 SDK_DEPENDS_append_libc-glibc = " nativesdk-glibc-locale"
 
 # We want the MULTIARCH_TARGET_SYS to point to the TUNE_PKGARCH, not 
PACKAGE_ARCH as it
-- 
2.17.0

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


[OE-core] [PATCH 5/7] qemuwrapper-cross: enable multilib and nativesdk variants of the script

2018-05-28 Thread Alexander Kanavin
Previously only one global variant of the script was created,
which caused numerous issues:

1) multilib was not properly supported due to multilib variants each
needing their own version of the qemu binary and library paths to be set
2) nativesdk was not properly supported for the same reason

This patch also moves setting LD_LIBRARY_PATH directly into the
recipe, as passing it down from other recipes did not work when
said recipes were allarch, and adjusts calls to qemuwrapper from
postinst-intercepts, so that its correct variant is selected.

Also, the various qemu fallbacks in qemuwrapper script are all removed,
as they are no longer necessary.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/fontcache.bbclass|  2 +-
 meta/classes/pixbufcache.bbclass  |  2 +-
 .../qemu/qemuwrapper-cross_1.0.bb | 37 +--
 scripts/postinst-intercepts/update_font_cache |  3 +-
 .../update_gio_module_cache   |  3 +-
 .../update_gtk_immodules_cache|  6 +--
 .../postinst-intercepts/update_pixbuf_cache   |  3 +-
 7 files changed, 17 insertions(+), 39 deletions(-)

diff --git a/meta/classes/fontcache.bbclass b/meta/classes/fontcache.bbclass
index e76331131ee..f71a754a4dd 100644
--- a/meta/classes/fontcache.bbclass
+++ b/meta/classes/fontcache.bbclass
@@ -17,7 +17,7 @@ FONTCONFIG_CACHE_PARAMS ?= "-v"
 FONTCONFIG_CACHE_ENV ?= "FC_DEBUG=1"
 fontcache_common() {
 if [ -n "$D" ] ; then
-   $INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} 
mlprefix=${MLPREFIX} \
+   $INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} 
mlprefix=${MLPREFIX} binprefix=${MLPREFIX} \
'bindir="${bindir}"' \
'libdir="${libdir}"' \
'base_libdir="${base_libdir}"' \
diff --git a/meta/classes/pixbufcache.bbclass b/meta/classes/pixbufcache.bbclass
index b3e507f61b6..3378ff2c806 100644
--- a/meta/classes/pixbufcache.bbclass
+++ b/meta/classes/pixbufcache.bbclass
@@ -12,7 +12,7 @@ PACKAGE_WRITE_DEPS += "qemu-native gdk-pixbuf-native"
 
 pixbufcache_common() {
 if [ "x$D" != "x" ]; then
-   $INTERCEPT_DIR/postinst_intercept update_pixbuf_cache ${PKG} 
mlprefix=${MLPREFIX} libdir=${libdir} \
+   $INTERCEPT_DIR/postinst_intercept update_pixbuf_cache ${PKG} 
mlprefix=${MLPREFIX} binprefix=${MLPREFIX} libdir=${libdir} \
bindir=${bindir} base_libdir=${base_libdir}
 else
 
diff --git a/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb 
b/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb
index c983fbae667..4b1b46d0bb3 100644
--- a/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb
+++ b/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb
@@ -13,38 +13,21 @@ do_populate_sysroot[depends] = ""
 do_install () {
install -d ${D}${bindir_crossscripts}/
 
-   echo "#!/bin/sh" > ${D}${bindir_crossscripts}/qemuwrapper
qemu_binary=${@qemu_target_binary(d)}
-   qemu_options='${QEMU_OPTIONS}'
-   echo "$qemu_binary $qemu_options \"\$@\"" >> 
${D}${bindir_crossscripts}/qemuwrapper
-   fallback_qemu_bin=
-   case $qemu_binary in
-   "qemu-i386")
-   fallback_qemu_bin=qemu-x86_64
-   ;;
-   "qemu-x86_64")
-   fallback_qemu_bin=qemu-i386
-   ;;
-   *)
-   ;;
-   esac
-
-   if [ -n "$fallback_qemu_bin" ]; then
-
-   cat >> ${D}${bindir_crossscripts}/qemuwrapper << EOF
-rc=\$?
-if [ \$rc = 255 ]; then
-   $fallback_qemu_bin "\$@"
-   rc=\$?
-fi
-exit \$rc
-EOF
+   qemu_options='${QEMU_OPTIONS} -E 
LD_LIBRARY_PATH=$D${libdir}:$D${base_libdir}'
+
+   cat >> ${D}${bindir_crossscripts}/${MLPREFIX}qemuwrapper << EOF
+#!/bin/sh
+set -x
 
-   fi
+$qemu_binary $qemu_options "\$@"
+EOF
 
-   chmod +x ${D}${bindir_crossscripts}/qemuwrapper
+   chmod +x ${D}${bindir_crossscripts}/${MLPREFIX}qemuwrapper
 }
 
 SYSROOT_DIRS += "${bindir_crossscripts}"
 
 INHIBIT_DEFAULT_DEPS = "1"
+
+BBCLASSEXTEND = "nativesdk"
diff --git a/scripts/postinst-intercepts/update_font_cache 
b/scripts/postinst-intercepts/update_font_cache
index bf65e19a41d..20e9048adfc 100644
--- a/scripts/postinst-intercepts/update_font_cache
+++ b/scripts/postinst-intercepts/update_font_cache
@@ -2,6 +2,5 @@
 
 set -e
 
-PSEUDO_UNLOAD=1 qemuwrapper -L $D -E 
LD_LIBRARY_PATH=$D/${libdir}:$D/${base_libdir} \
-   -E ${fontconfigcacheenv} 
$D${bindir}/fc-cache --sysroot=$D --system-only ${fontconfigcacheparams}
+PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D -E ${fontconfigcacheenv} 
$D${bindir}/fc-cache --sysroot=$D --system-only ${fontconfigcacheparams}
 chown -R root:root $D${fontconfigcachedir}
diff --git a/scripts/postinst-intercepts/update_gio_module_cache 
b/scripts/postinst-intercepts/update_gio_module_cache
index fc3f9d0d6ce..d1f0140947e 100644
--- 

[OE-core] [PATCH 7/7] package_manager.py: rework postinst_intercept failures

2018-05-28 Thread Alexander Kanavin
Previously a warning was printed regardless of context and nature
of the failure, and because it was only a warning, it was mostly ignored.

Now, the following is considered when a failure happens:
1) whether we are installing packages into a target image, or populating
a SDK with host or target packages.
2) whether the failure was due to qemu not supporting the target machine.

Accordingly, warnings, notes, and failures are printed, and postponing
to first boot happens if possible.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/package_manager.py| 19 ---
 meta/lib/oe/sdk.py| 12 ++--
 .../qemu/qemuwrapper-cross_1.0.bb |  5 +
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 516630b5cfb..f87f76fec99 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -370,7 +370,7 @@ class PackageManager(object, metaclass=ABCMeta):
 self._handle_intercept_failure(registered_pkgs)
 
 
-def run_intercepts(self):
+def run_intercepts(self, populate_sdk=None):
 intercepts_dir = self.intercepts_dir
 
 bb.note("Running intercept scripts:")
@@ -392,9 +392,22 @@ class PackageManager(object, metaclass=ABCMeta):
 output = subprocess.check_output(script_full, 
stderr=subprocess.STDOUT)
 if output: bb.note(output.decode("utf-8"))
 except subprocess.CalledProcessError as e:
-bb.warn("The postinstall intercept hook '%s' failed, details 
in %s/log.do_%s" % (script, self.d.getVar('T'), 
self.d.getVar('BB_CURRENTTASK')))
 bb.note("Exit code %d. Output:\n%s" % (e.returncode, 
e.output.decode("utf-8")))
-self._postpone_to_first_boot(script_full)
+if populate_sdk == 'host':
+bb.warn("The postinstall intercept hook '%s' failed, 
details in %s/log.do_%s" % (script, self.d.getVar('T'), 
self.d.getVar('BB_CURRENTTASK')))
+elif populate_sdk == 'target':
+if "qemuwrapper: qemu usermode is not supported" in 
e.output.decode("utf-8"):
+bb.warn("The postinstall intercept hook '%s' could not 
be executed due to missing qemu usermode support, details in %s/log.do_%s"
+% (script, self.d.getVar('T'), 
self.d.getVar('BB_CURRENTTASK')))
+else:
+bb.fatal("The postinstall intercept hook '%s' failed, 
details in %s/log.do_%s" % (script, self.d.getVar('T'), 
self.d.getVar('BB_CURRENTTASK')))
+else:
+if "qemuwrapper: qemu usermode is not supported" in 
e.output.decode("utf-8"):
+bb.note("The postinstall intercept hook '%s' could not 
be executed due to missing qemu usermode support, details in %s/log.do_%s"
+% (script, self.d.getVar('T'), 
self.d.getVar('BB_CURRENTTASK')))
+self._postpone_to_first_boot(script_full)
+else:
+bb.fatal("The postinstall intercept hook '%s' failed, 
details in %s/log.do_%s" % (script, self.d.getVar('T'), 
self.d.getVar('BB_CURRENTTASK')))
 
 @abstractmethod
 def update(self):
diff --git a/meta/lib/oe/sdk.py b/meta/lib/oe/sdk.py
index d6a503372a3..0d39ea8a91e 100644
--- a/meta/lib/oe/sdk.py
+++ b/meta/lib/oe/sdk.py
@@ -209,7 +209,7 @@ class RpmSdk(Sdk):
 
 
self.target_pm.install_complementary(self.d.getVar('SDKIMAGE_INSTALL_COMPLEMENTARY'))
 
-self.target_pm.run_intercepts()
+self.target_pm.run_intercepts(populate_sdk='target')
 
 execute_pre_post_process(self.d, 
self.d.getVar("POPULATE_SDK_POST_TARGET_COMMAND"))
 
@@ -220,7 +220,7 @@ class RpmSdk(Sdk):
 self._populate_sysroot(self.host_pm, self.host_manifest)
 self.install_locales(self.host_pm)
 
-self.host_pm.run_intercepts()
+self.host_pm.run_intercepts(populate_sdk='host')
 
 execute_pre_post_process(self.d, 
self.d.getVar("POPULATE_SDK_POST_HOST_COMMAND"))
 
@@ -297,7 +297,7 @@ class OpkgSdk(Sdk):
 
 
self.target_pm.install_complementary(self.d.getVar('SDKIMAGE_INSTALL_COMPLEMENTARY'))
 
-self.target_pm.run_intercepts()
+self.target_pm.run_intercepts(populate_sdk='target')
 
 execute_pre_post_process(self.d, 
self.d.getVar("POPULATE_SDK_POST_TARGET_COMMAND"))
 
@@ -308,7 +308,7 @@ class OpkgSdk(Sdk):
 self._populate_sysroot(self.host_pm, self.host_manifest)
 self.install_locales(self.host_pm)
 
-self.host_pm.run_intercepts()
+self.host_pm.run_intercepts(populate_sdk='host')
 
 execute_pre_post_process(self.d, 
self.d.getVar("POPULATE_SDK_POST_HOST_COMMAND"))
 
@@ -386,7 +386,7 @@ class DpkgSdk(Sdk):
 
 

[OE-core] [PATCH 4/7] udev: only run qemu from postinst scripts if qemu usermode is supported

2018-05-28 Thread Alexander Kanavin
Otherwise, there would be a failure at image creation time; avoid
that by postponing to first boot explicitly.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-core/systemd/systemd_237.bb | 10 +++---
 meta/recipes-core/udev/eudev_3.2.5.bb|  8 ++--
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_237.bb 
b/meta/recipes-core/systemd/systemd_237.bb
index b7c2113255f..91783f2ffbe 100644
--- a/meta/recipes-core/systemd/systemd_237.bb
+++ b/meta/recipes-core/systemd/systemd_237.bb
@@ -580,9 +580,13 @@ pkg_prerm_${PN} () {
 PACKAGE_WRITE_DEPS += "qemu-native"
 pkg_postinst_udev-hwdb () {
if test -n "$D"; then
-   ${@qemu_run_binary(d, '$D', '${base_bindir}/udevadm')} hwdb 
--update \
-   --root $D
-   chown root:root $D${sysconfdir}/udev/hwdb.bin
+   if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 
'true','false', d)}; then
+   ${@qemu_run_binary(d, '$D', '${base_bindir}/udevadm')} 
hwdb --update \
+   --root $D
+   chown root:root $D${sysconfdir}/udev/hwdb.bin
+   else
+   $INTERCEPT_DIR/postinst_intercept delay_to_first_boot 
${PKG} mlprefix=${MLPREFIX}
+   fi
else
udevadm hwdb --update
fi
diff --git a/meta/recipes-core/udev/eudev_3.2.5.bb 
b/meta/recipes-core/udev/eudev_3.2.5.bb
index 88ad8f1b375..75617c8d4ec 100644
--- a/meta/recipes-core/udev/eudev_3.2.5.bb
+++ b/meta/recipes-core/udev/eudev_3.2.5.bb
@@ -80,8 +80,12 @@ RPROVIDES_eudev-hwdb += "udev-hwdb"
 PACKAGE_WRITE_DEPS += "qemu-native"
 pkg_postinst_eudev-hwdb () {
 if test -n "$D"; then
-${@qemu_run_binary(d, '$D', '${bindir}/udevadm')} hwdb --update --root 
$D
-chown root:root $D${sysconfdir}/udev/hwdb.bin
+if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 
'true','false', d)}; then
+${@qemu_run_binary(d, '$D', '${bindir}/udevadm')} hwdb --update 
--root $D
+chown root:root $D${sysconfdir}/udev/hwdb.bin
+else
+$INTERCEPT_DIR/postinst_intercept delay_to_first_boot ${PKG} 
mlprefix=${MLPREFIX}
+fi
 else
 udevadm hwdb --update
 fi
-- 
2.17.0

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


[OE-core] [PATCH 3/7] lib/oe/package_manager: turn postinst failure warnings into bitbake failures

2018-05-28 Thread Alexander Kanavin
Sumo release provides a transition period so that deferrals to first boot
via 'exit 1' can be converted to pkg_postinst_ontarget(). For the next release
however, postinst script failures should be treated as such.

[YOCTO #12607]

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/package_manager.py   | 22 +++-
 meta/lib/oeqa/selftest/cases/runtime_test.py |  4 ++--
 2 files changed, 9 insertions(+), 17 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 5ac729455e9..516630b5cfb 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -84,10 +84,10 @@ def opkg_query(cmd_output):
 
 return output
 
-# Note: this should be bb.fatal in the future.
-def failed_postinsts_warn(pkgs, log_path):
-bb.warn("""Intentionally failing postinstall scriptlets of %s to defer 
them to first boot is deprecated. Please place them into 
pkg_postinst_ontarget_${PN} ().
-If deferring to first boot wasn't the intent, then scriptlet failure may mean 
an issue in the recipe, or a regression elsewhere.
+def failed_postinsts_abort(pkgs, log_path):
+bb.fatal("""Postinstall scriptlets of %s have failed. If the intention is 
to defer them to first boot,
+then please place them into pkg_postinst_ontarget_${PN} ().
+Deferring to first boot via 'exit 1' is no longer supported.
 Details of the failure are in %s.""" %(pkgs, log_path))
 
 class Indexer(object, metaclass=ABCMeta):
@@ -789,9 +789,7 @@ class RpmPM(PackageManager):
 failed_scriptlets_pkgnames[line.split()[-1]] = True
 
 if len(failed_scriptlets_pkgnames) > 0:
-failed_postinsts_warn(list(failed_scriptlets_pkgnames.keys()), 
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
-for pkg in failed_scriptlets_pkgnames.keys():
-self.save_rpmpostinst(pkg)
+failed_postinsts_abort(list(failed_scriptlets_pkgnames.keys()), 
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
 
 def remove(self, pkgs, with_dependencies = True):
 if len(pkgs) == 0:
@@ -1269,7 +1267,7 @@ class OpkgPM(OpkgDpkgPM):
 bb.warn(line)
 failed_pkgs.append(line.split(".")[0])
 if failed_pkgs:
-failed_postinsts_warn(failed_pkgs, 
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
+failed_postinsts_abort(failed_pkgs, 
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
 except subprocess.CalledProcessError as e:
 (bb.fatal, bb.warn)[attempt_only]("Unable to install packages. "
   "Command '%s' returned %d:\n%s" %
@@ -1519,7 +1517,6 @@ class DpkgPM(OpkgDpkgPM):
 os.environ['INTERCEPT_DIR'] = self.intercepts_dir
 os.environ['NATIVE_ROOT'] = self.d.getVar('STAGING_DIR_NATIVE')
 
-failed_pkgs = []
 for pkg_name in installed_pkgs:
 for control_script in control_scripts:
 p_full = os.path.join(info_dir, pkg_name + 
control_script.suffix)
@@ -1534,12 +1531,7 @@ class DpkgPM(OpkgDpkgPM):
 bb.warn("%s for package %s failed with %d:\n%s" %
 (control_script.name, pkg_name, e.returncode,
 e.output.decode("utf-8")))
-failed_postinsts_warn([pkg_name], 
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
-failed_pkgs.append(pkg_name)
-break
-
-if len(failed_pkgs):
-self.mark_packages("unpacked", failed_pkgs)
+failed_postinsts_abort([pkg_name], 
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
 
 def update(self):
 os.environ['APT_CONFIG'] = self.apt_conf_file
diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py 
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 9c9b4b34111..21e2c405df1 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -249,8 +249,8 @@ class Postinst(OESelftestTestCase):
 features = 'CORE_IMAGE_EXTRA_INSTALL = 
"postinst-rootfs-failing"\n'
 features += 'PACKAGE_CLASSES = "%s"\n' % classes
 self.write_config(features)
-bb_result = bitbake('core-image-minimal')
-self.assertGreaterEqual(bb_result.output.find("Intentionally 
failing postinstall scriptlets of ['postinst-rootfs-failing'] to defer them to 
first boot is deprecated."), 0,
+bb_result = bitbake('core-image-minimal', ignore_status=True)
+self.assertGreaterEqual(bb_result.output.find("Postinstall 
scriptlets of ['postinst-rootfs-failing'] have failed."), 0,
 "Warning about a failed scriptlet not found in bitbake 
output: %s" %(bb_result.output))
 
 self.assertTrue(os.path.isfile(os.path.join(hosttestdir, 

[OE-core] [PATCH 2/7] gtk-immodules-cache.bbclass: convert cache creation to postinst_intercept mechanism

2018-05-28 Thread Alexander Kanavin
This has the following benefits:
- consistent with how the other caches are created into target rootfs
- only runs once per package manager transaction, instead of once per every 
immodule package
- correctly postpones to first boot if qemu is not working; from postinst itself
this would've required special arrangements to avoid what is now a do_rootfs 
failure.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/gtk-immodules-cache.bbclass  | 70 ---
 .../update_gtk_immodules_cache| 18 +
 2 files changed, 46 insertions(+), 42 deletions(-)
 create mode 100644 scripts/postinst-intercepts/update_gtk_immodules_cache

diff --git a/meta/classes/gtk-immodules-cache.bbclass 
b/meta/classes/gtk-immodules-cache.bbclass
index 3d82dbe9e34..9bb0af8b26a 100644
--- a/meta/classes/gtk-immodules-cache.bbclass
+++ b/meta/classes/gtk-immodules-cache.bbclass
@@ -10,53 +10,39 @@ GTKIMMODULES_PACKAGES ?= "${PN}"
 
 gtk_immodule_cache_postinst() {
 if [ "x$D" != "x" ]; then
-if [ -x $D${bindir}/gtk-query-immodules-2.0 ]; then
-IMFILES=$(ls $D${libdir}/gtk-2.0/*/immodules/*.so)
-${@qemu_run_binary(d, '$D', '${bindir}/gtk-query-immodules-2.0')} \
-$IMFILES > $D${libdir}/gtk-2.0/2.10.0/immodules.cache 
2>/dev/null &&
-sed -i -e "s:$D::" $D${libdir}/gtk-2.0/2.10.0/immodules.cache
-fi
-if [ -x $D${bindir}/gtk-query-immodules-3.0 ]; then
-IMFILES=$(ls $D${libdir}/gtk-3.0/*/immodules/*.so)
-${@qemu_run_binary(d, '$D', '${bindir}/gtk-query-immodules-3.0')} \
-$IMFILES > $D${libdir}/gtk-3.0/3.0.0/immodules.cache 
2>/dev/null &&
-sed -i -e "s:$D::" $D${libdir}/gtk-3.0/3.0.0/immodules.cache
-fi
-
-[ $? -ne 0 ] && exit 1
-exit 0
-fi
-if [ ! -z `which gtk-query-immodules-2.0` ]; then
-gtk-query-immodules-2.0 > ${libdir}/gtk-2.0/2.10.0/immodules.cache
-fi
-if [ ! -z `which gtk-query-immodules-3.0` ]; then
-gtk-query-immodules-3.0 > ${libdir}/gtk-3.0/3.0.0/immodules.cache
+$INTERCEPT_DIR/postinst_intercept update_gtk_immodules_cache ${PKG} \
+mlprefix=${MLPREFIX} \
+binprefix=${MLPREFIX} \
+libdir=${libdir} \
+libexecdir=${libexecdir} \
+base_libdir=${base_libdir} \
+bindir=${bindir}
+else
+if [ ! -z `which gtk-query-immodules-2.0` ]; then
+gtk-query-immodules-2.0 > ${libdir}/gtk-2.0/2.10.0/immodules.cache
+fi
+if [ ! -z `which gtk-query-immodules-3.0` ]; then
+gtk-query-immodules-3.0 > ${libdir}/gtk-3.0/3.0.0/immodules.cache
+fi
 fi
 }
 
 gtk_immodule_cache_postrm() {
 if [ "x$D" != "x" ]; then
-if [ -x $D${bindir}/gtk-query-immodules-2.0 ]; then
-IMFILES=$(ls $D${libdir}/gtk-2.0/*/immodules/*.so)
-${@qemu_run_binary(d, '$D', '${bindir}/gtk-query-immodules-2.0')} \
-$IMFILES > $D${libdir}/gtk-2.0/2.10.0/immodules.cache 
2>/dev/null &&
-sed -i -e "s:$D::" $D${libdir}/gtk-2.0/2.10.0/immodules.cache
-fi
-if [ -x $D${bindir}/gtk-query-immodules-3.0 ]; then
-IMFILES=$(ls $D${libdir}/gtk-3.0/*/immodules/*.so)
-${@qemu_run_binary(d, '$D', '${bindir}/gtk-query-immodules-3.0')} \
-$IMFILES > $D${libdir}/gtk-3.0/3.0.0/immodules.cache 
2>/dev/null &&
-sed -i -e "s:$D::" $D${libdir}/gtk-3.0/3.0.0/immodules.cache
-fi
-
-[ $? -ne 0 ] && exit 1
-exit 0
-fi
-if [ ! -z `which gtk-query-immodules-2.0` ]; then
-gtk-query-immodules-2.0 > ${libdir}/gtk-2.0/2.10.0/immodules.cache
-fi
-if [ ! -z `which gtk-query-immodules-3.0` ]; then
-gtk-query-immodules-3.0 > ${libdir}/gtk-3.0/3.0.0/immodules.cache
+$INTERCEPT_DIR/postinst_intercept update_gtk_immodules_cache ${PKG} \
+mlprefix=${MLPREFIX} \
+binprefix=${MLPREFIX} \
+libdir=${libdir} \
+libexecdir=${libexecdir} \
+base_libdir=${base_libdir} \
+bindir=${bindir}
+else
+if [ ! -z `which gtk-query-immodules-2.0` ]; then
+gtk-query-immodules-2.0 > ${libdir}/gtk-2.0/2.10.0/immodules.cache
+fi
+if [ ! -z `which gtk-query-immodules-3.0` ]; then
+gtk-query-immodules-3.0 > ${libdir}/gtk-3.0/3.0.0/immodules.cache
+fi
 fi
 }
 
diff --git a/scripts/postinst-intercepts/update_gtk_immodules_cache 
b/scripts/postinst-intercepts/update_gtk_immodules_cache
new file mode 100644
index 000..e2b9ff74382
--- /dev/null
+++ b/scripts/postinst-intercepts/update_gtk_immodules_cache
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+set -e
+
+if [ -x $D${bindir}/gtk-query-immodules-2.0 ]; then
+PSEUDO_UNLOAD=1 qemuwrapper -L $D -E 
LD_LIBRARY_PATH=$D${libdir}:$D${base_libdir} \
+$D/${bindir}/gtk-query-immodules-2.0 \
+> $D${libdir}/gtk-2.0/2.10.0/immodules.cache &&
+sed -i -e "s:$D::" 

[OE-core] [PATCH 1/7] package_manager.py: get rid of ROOTFS_RPM_DEBUG in RpmPM()

2018-05-28 Thread Alexander Kanavin
This was undocumented, and it's better to just always enable
full debug output, as this allows immediate generation of logs
with full diagnostics when things go not as expected.

Also, change the output of dnf from note to debug level; this
does not affect what is written to log file, but does reduce the
verbosity of bitbake -v.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/package_manager.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 1cba5ee9688..5ac729455e9 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -888,7 +888,7 @@ class RpmPM(PackageManager):
 os.environ['RPM_ETCCONFIGDIR'] = self.target_rootfs
 
 dnf_cmd = bb.utils.which(os.getenv('PATH'), "dnf")
-standard_dnf_args = (["-v", "--rpmverbosity=debug"] if 
self.d.getVar('ROOTFS_RPM_DEBUG') else []) + ["-y",
+standard_dnf_args = ["-v", "--rpmverbosity=debug", "-y",
  "-c", oe.path.join(self.target_rootfs, 
"etc/dnf/dnf.conf"),
  "--setopt=reposdir=%s" 
%(oe.path.join(self.target_rootfs, "etc/yum.repos.d")),
  "--repofrompath=oe-repo,%s" % (self.rpm_repo_dir),
@@ -900,7 +900,7 @@ class RpmPM(PackageManager):
 try:
 output = 
subprocess.check_output(cmd,stderr=subprocess.STDOUT).decode("utf-8")
 if print_output:
-bb.note(output)
+bb.debug(1, output)
 return output
 except subprocess.CalledProcessError as e:
 if print_output:
-- 
2.17.0

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


Re: [OE-core] [PATCH] telnetd:Fix deadlock on cleanup

2018-05-28 Thread Alexander Kanavin

On 05/28/2018 09:27 AM, Seiichi Ishitsuka wrote:

I was able to reproduce the old problems shown below with netkit-telnet_0.17.bb.

https://patchwork.openembedded.org/patch/96727/
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455


The patch should go to meta-openembedded list, and it should be created  
against the layer source tree, not against the component source tree.


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


Re: [OE-core] [PATCH 01/24] base.bbclass: Add buildcfg multilib values

2018-05-28 Thread Robert Yang



On 05/28/2018 01:23 PM, Alexander Kanavin wrote:

2018-05-28 6:24 GMT+03:00 Robert Yang :


Thanks for the reply, but I'm afraid that all_multlilib_tune_values() isn't
suitable for this case, what need to display is something like:

lib32:  DEFAULTTUNE   = "x86"
lib32:  TARGET_SYS= "i686-pokymllib32-linux"
lib32:  TUNE_FEATURES = "m32"

But all_multlilib_tune_values() returns all values, e.g:

DEFAULTTUNE   = "core2-64 x86"


That's right, but you should still use get_multilib_datastore()
instead of setting up localdata manually


Thanks, make sense, updated in the repo:

+def buildcfg_multilibs(d):
+variants = d.getVar("MULTILIB_VARIANTS", True) or ""
+for variant in variants.split():
+localdata = get_multilib_datastore(variant, d)
+statusvars = oe.data.typed_value('BUILDCFG_VARS', d)
+for var in statusvars:
+origvalue = d.getVar(var, True)
+variantvalue = localdata.getVar(var, True)
+if origvalue and variantvalue and origvalue != variantvalue:
+yield '%-7s %-17s = "%s"' % (variant + ":", var, variantvalue)
+

// Robert



Alex


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


[OE-core] [PATCH] meta-toolchain: Added dnf-nativesdk into cross-development toolchain.

2018-05-28 Thread Zheng Ruoqin
To make dnf work on cross-development environment.

Signed-off-by: Zheng Ruoqin 
---
 meta/classes/toolchain-scripts.bbclass |  1 +
 .../nativesdk-packagegroup-sdk-host.bb |  4 +++
 meta/recipes-core/update-rc.d/update-rc.d_0.7.bb   |  2 +-
 .../createrepo-c/createrepo-c_git.bb   |  7 -
 meta/recipes-devtools/file/file_5.32.bb|  2 ++
 meta/recipes-devtools/rpm/rpm_4.14.1.bb| 34 ++
 .../newt/libnewt-python_0.52.20.bb |  2 +-
 meta/recipes-extended/newt/libnewt_0.52.20.bb  |  2 +-
 meta/recipes-extended/slang/slang_2.3.2.bb |  2 +-
 9 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index 71da5e5..58dd00e 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -97,6 +97,7 @@ toolchain_shared_env_script () {
echo 'export CPPFLAGS="${TARGET_CPPFLAGS}"' >> $script
echo 'export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"' >> $script
echo 'export OECORE_DISTRO_VERSION="${DISTRO_VERSION}"' >> $script
+echo 'export MACHINE_ARCH=${MACHINE_ARCH}' >> $script
echo 'export OECORE_SDK_VERSION="${SDK_VERSION}"' >> $script
echo 'export ARCH=${ARCH}' >> $script
echo 'export CROSS_COMPILE=${TARGET_PREFIX}' >> $script
diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index e2f6169..1370a82 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -25,6 +25,10 @@ RDEPENDS_${PN} = "\
 nativesdk-cmake \
 ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', 
'', d)} \
 nativesdk-sdk-provides-dummy \
+nativesdk-libnewt-python \
+nativesdk-createrepo-c \
+nativesdk-gpgme \
+nativesdk-update-rc.d \
 "
 
 RDEPENDS_${PN}_darwin = "\
diff --git a/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb 
b/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb
index 76d4312..d3d3e2f 100644
--- a/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb
+++ b/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb
@@ -30,4 +30,4 @@ do_install() {
install -m 0755 ${S}/update-rc.d ${D}${sbindir}/update-rc.d
 }
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb 
b/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
index 3176136..9be9f9e 100644
--- a/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
+++ b/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
@@ -21,7 +21,7 @@ inherit cmake pkgconfig bash-completion distutils3-base
 
 EXTRA_OECMAKE = " -DPYTHON_INSTALL_DIR=${PYTHON_SITEPACKAGES_DIR} 
-DPYTHON_DESIRED=3"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
 
 # Direct createrepo to read rpm configuration from our sysroot, not the one it 
was compiled in
 do_install_append_class-native() {
@@ -29,3 +29,8 @@ do_install_append_class-native() {
 RPM_CONFIGDIR=${STAGING_LIBDIR_NATIVE}/rpm
 }
 
+do_install_append_class-nativesdk() {
+create_wrapper ${D}/${bindir}/createrepo_c \
+RPM_CONFIGDIR=${SDKPATHNATIVE}${libdir_nativesdk}/rpm
+rm -rf ${D}/etc
+}
diff --git a/meta/recipes-devtools/file/file_5.32.bb 
b/meta/recipes-devtools/file/file_5.32.bb
index 5e15925..9b13261 100644
--- a/meta/recipes-devtools/file/file_5.32.bb
+++ b/meta/recipes-devtools/file/file_5.32.bb
@@ -43,6 +43,8 @@ do_install_append_class-nativesdk() {
 
 BBCLASSEXTEND = "native nativesdk"
 PROVIDES_append_class-native = " file-replacement-native"
+PROVIDES_append_class-nativesdk = " file-replacement-nativesdk"
+
 # Don't use NATIVE_PACKAGE_PATH_SUFFIX as that hides libmagic from anyone who
 # depends on file-replacement-native.
 bindir_append_class-native = "/file-native"
diff --git a/meta/recipes-devtools/rpm/rpm_4.14.1.bb 
b/meta/recipes-devtools/rpm/rpm_4.14.1.bb
index d49530e..abcad9f 100644
--- a/meta/recipes-devtools/rpm/rpm_4.14.1.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.14.1.bb
@@ -50,6 +50,7 @@ S = "${WORKDIR}/git"
 
 DEPENDS = "nss libarchive db file popt xz bzip2 dbus elfutils python3"
 DEPENDS_append_class-native = " file-replacement-native 
bzip2-replacement-native"
+DEPENDS_append_class-nativesdk = " file-replacement-nativesdk"
 
 inherit autotools gettext pkgconfig python3native
 export PYTHON_ABI
@@ -67,6 +68,7 @@ EXTRA_OECONF_append_libc-musl = " --disable-nls"
 # Disable dbus for native, so that rpm doesn't attempt to inhibit shutdown via 
session dbus even when plugins support is enabled.
 # Also disable plugins by default for native.
 EXTRA_OECONF_append_class-native = " --sysconfdir=/etc --localstatedir=/var 
--without-dbus --disable-plugins"

[OE-core] [PATCH] telnetd:Fix deadlock on cleanup

2018-05-28 Thread Seiichi Ishitsuka
Hi all,

I was able to reproduce the old problems shown below with netkit-telnet_0.17.bb.

https://patchwork.openembedded.org/patch/96727/
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455

The evaluated environment is,
 glibc  :2.2 
 kernel :4.4.32

How to reproduce:

Run the script more than once in the background, and
please adjust CPU usage to 100%.

#!/bin/sh

HOST="host.target"
USER="root"
PASS="password"

while :
  do
  expect -c "
  set timeout 10
  spawn telnet $HOST
  expect login:\  ; send \"$USER\r\"
  expect sword:\  ; send \"$PASS\r\"
  expect \"# \" ; send \"exit\r\"
  " > /dev/null
  done


Best regards,
Seiichi Ishitsuka


0001-telnetd-Fix-deadlock-on-cleanup.patch
Description: 0001-telnetd-Fix-deadlock-on-cleanup.patch
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core