Re: [OE-core] backfill mechanism

2017-12-01 Thread Peter Kjellerstedt
Be careful with the _remove operator in common configuration files. 
Once it has been used there is absolutely no way of getting the 
removed value back in, for testing or for real. 

E.g., if you were to change the:

DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"

in poky-tiny.conf to: 

DISTRO_FEATURES_remove = "sysvinit"

then it would be impossible to use the poky-tiny distro in a 
configuration where you also would like to enable sysvinit.

Also, after having looked at the Git history for when the backfill 
feature was implemented, I do not think DISTRO_FEATURES_remove will 
work, for the same reason DISTRO_FEATURES_append is not used to add 
the backfilled values (the first implementation actually did use 
_append). The reason it was changed is because the _append (and 
_remove) are evaluated too late. I.e., code like this that use a 
conditional based on DISTRO_FEATURES to do inherit would not 
work as intended for a backfilled value:

inherit ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', '', 'systemd', d)}

A better solution for how to replace the backfill considered 
mechanism would be to use individual variables for the backfilled 
values. E.g., the current definition in bitbake.conf:

MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" 

could be replaced with something like:

MACHINE_FEATURES_BACKFILL = " \
${MACHINE_FEATURES_BACKFILL_qemu-usermode} \
${MACHINE_FEATURES_BACKFILL_rtc} \
"
MACHINE_FEATURES_BACKFILL_qemu-usermode = "qemu-usermode"
MACHINE_FEATURES_BACKFILL_rtc = "rtc"

Then to do the equivalent of:

MACHINE_FEATURES_BACKFILL_CONSIDERED += "rtc"

one would instead do:

MACHINE_FEATURES_BACKFILL_rtc = ""

Alternatively one could use variable flags:

MACHINE_FEATURES_BACKFILL[qemu-usermode] = "1"
MACHINE_FEATURES_BACKFILL[rtc] = "1"

and then simply set it to 0 if one does not want a feature:

MACHINE_FEATURES_BACKFILL[rtc] = "0"

That would of course take a little bit of Python code to 
convert the variable flags into actual features:

MACHINE_FEATURES_BACKFILL = "${@' '.join(sorted(key for key in 
d.getVarFlags('MACHINE_FEATURES_BACKFILL').keys() if 
d.getVarFlag('MACHINE_FEATURES_BACKFILL', key) == '1'))}"

(By explicitly testing for "1" we also avoid converting 
MACHINE_FEATURES_BACKFILL[doc] into a feature.)

I also have a hunch that something like this would be needed:

MACHINE_FEATURES_BACKFILL[vardepvalue] = "${MACHINE_FEATURES_BACKFILL}"

which probably leads to recursion unless the key "vardepvalue" is 
explicitly avoided in the if test above. Meh...

//Peter

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Slater, Joseph
> Sent: den 21 november 2017 20:11
> To: Andre McCurdy 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] backfill mechanism
> 
> The problem is that when backfilling is done, TUNE_FEATURES, etc, all
> have values associated with the base arch, not the current multilib.
> The "generic" solution, below, should work, although I would still use
> overrides when available.
> 
> Beyond what actually works, if the special backfill processing can be
> eliminated and regular constructs used I think that would be desirable.
> 
> Joe
> 
> From: Andre McCurdy [armccu...@gmail.com]
> Sent: Monday, November 20, 2017 7:24 PM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] backfill mechanism
> 
> On Fri, Nov 17, 2017 at 3:32 PM, Slater, Joseph
>  wrote:
> > The backfill mechanism is not compatible with multilib.
> 
> Did anyone ever explain why?
> 
> > This could possibly
> > be fixed, but the backfill_considered functionality is also obscure,
> so I
> > think in at least the machine related .inc files we should replace
> lines
> > like
> >
> > MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> > ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '',
> d)}"
> >
> > with lines like
> >
> > MACHINE_FEATURES_remove_mipsarchn32 = " qemu-usermode"
> 
> That only works for TUNE_FEATURES which happen to have a corresponding
> over-ride, so may not be a generic solution. Does something like:
> 
>   MACHINE_FEATURES_remove = "${@bb.utils.contains('TUNE_FEATURES',
> 'n32', 'qemu-usermode', '', d)}"
> 
> work for multilib?
> 
> > There are two advantages:  the second line works for multilib, and it
> is far
> > more readable.
> >
> > Joe
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 4/5] musl: Update to 1.1.18

2017-12-01 Thread Andre McCurdy
On Fri, Dec 1, 2017 at 4:37 PM, Khem Raj  wrote:
> On Fri, Dec 1, 2017 at 4:31 PM, Andre McCurdy  wrote:
>> On Wed, Nov 8, 2017 at 5:58 PM, Khem Raj  wrote:
>>> Rich Felker (9):
>>>   fix access by setjmp and longjmp to __hwcap on arm built as thumb2
>>>   for executing init array functions, use function type with prototype
>>>   fix read-after-free type error in pthread_detach
>>>   fix incorrect base name offset from nftw when pathname ends in 
>>> slash(es)
>>>   in dns parsing callback, enforce MAXADDRS to preclude overflow
>>>   release 1.1.17
>>>   fix regression in glob with literal . or .. path component
>>>   fix build regression on ARM for ISA levels less than v5
>>>   release 1.1.18
>>>
>>> Szabolcs Nagy (1):
>>>   math: rewrite fma with mostly int arithmetics
>>>
>>> Will Dietz (1):
>>>   posix_spawn: use larger stack to cover worst-case in execvpe
>>
>> With the version of musl currently included in rocko, various apps
>> (including bash) segfault at startup when compiled as Thumb2. The "fix
>> access by setjmp and longjmp to __hwcap on arm built as thumb2" commit
>> from musl 1.1.18 fixes that.
>>
>> However the other changes in musl 1.1.18 look pretty useful too, so
>> unless there's strong objection, I'd like to suggest aligning rocko
>> with the musl 1.1.18 release. ie cherry-picking the following two
>> commits from oe-core master to rocko:
>>
>>   c3f0a70 musl: Update to 1.1.18
>>   3953c54 musl: Update to latest
>
> It seems good to me. Please send a pull and CC Armin

Armin, please consider the following two commits for rocko:

  c3f0a70 musl: Update to 1.1.18
  3953c54 musl: Update to latest

>>
>>> Signed-off-by: Khem Raj 
>>> ---
>>>  meta/recipes-core/musl/musl_git.bb | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/meta/recipes-core/musl/musl_git.bb 
>>> b/meta/recipes-core/musl/musl_git.bb
>>> index 671de326fb..932c9a27a0 100644
>>> --- a/meta/recipes-core/musl/musl_git.bb
>>> +++ b/meta/recipes-core/musl/musl_git.bb
>>> @@ -3,9 +3,9 @@
>>>
>>>  require musl.inc
>>>
>>> -SRCREV = "48be5b6313d7b827acf555769e93b389fa9f6307"
>>> +SRCREV = "eb03bde2f24582874cb72b56c7811bf51da0c817"
>>>
>>> -PV = "1.1.16+git${SRCPV}"
>>> +PV = "1.1.18+git${SRCPV}"
>>>
>>>  # mirror is at git://github.com/kraj/musl.git
>>>
>>> --
>>> 2.15.0
>>>
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 4/5] musl: Update to 1.1.18

2017-12-01 Thread Khem Raj
On Fri, Dec 1, 2017 at 4:31 PM, Andre McCurdy  wrote:
> On Wed, Nov 8, 2017 at 5:58 PM, Khem Raj  wrote:
>> Rich Felker (9):
>>   fix access by setjmp and longjmp to __hwcap on arm built as thumb2
>>   for executing init array functions, use function type with prototype
>>   fix read-after-free type error in pthread_detach
>>   fix incorrect base name offset from nftw when pathname ends in 
>> slash(es)
>>   in dns parsing callback, enforce MAXADDRS to preclude overflow
>>   release 1.1.17
>>   fix regression in glob with literal . or .. path component
>>   fix build regression on ARM for ISA levels less than v5
>>   release 1.1.18
>>
>> Szabolcs Nagy (1):
>>   math: rewrite fma with mostly int arithmetics
>>
>> Will Dietz (1):
>>   posix_spawn: use larger stack to cover worst-case in execvpe
>
> With the version of musl currently included in rocko, various apps
> (including bash) segfault at startup when compiled as Thumb2. The "fix
> access by setjmp and longjmp to __hwcap on arm built as thumb2" commit
> from musl 1.1.18 fixes that.
>
> However the other changes in musl 1.1.18 look pretty useful too, so
> unless there's strong objection, I'd like to suggest aligning rocko
> with the musl 1.1.18 release. ie cherry-picking the following two
> commits from oe-core master to rocko:
>
>   c3f0a70 musl: Update to 1.1.18
>   3953c54 musl: Update to latest
>

It seems good to me. Please send a pull and CC Armin

>
>> Signed-off-by: Khem Raj 
>> ---
>>  meta/recipes-core/musl/musl_git.bb | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-core/musl/musl_git.bb 
>> b/meta/recipes-core/musl/musl_git.bb
>> index 671de326fb..932c9a27a0 100644
>> --- a/meta/recipes-core/musl/musl_git.bb
>> +++ b/meta/recipes-core/musl/musl_git.bb
>> @@ -3,9 +3,9 @@
>>
>>  require musl.inc
>>
>> -SRCREV = "48be5b6313d7b827acf555769e93b389fa9f6307"
>> +SRCREV = "eb03bde2f24582874cb72b56c7811bf51da0c817"
>>
>> -PV = "1.1.16+git${SRCPV}"
>> +PV = "1.1.18+git${SRCPV}"
>>
>>  # mirror is at git://github.com/kraj/musl.git
>>
>> --
>> 2.15.0
>>
>> --
>> ___
>> 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] [morty][RESEND][PATCH] gnutls_3.5.3.bb: Fix native build on distro with kernel < 3.4.17

2017-12-01 Thread Martin Jansa
From: Khem Raj 

When using distros which use old kernels gnutls fails to build
due to missing SYS_getrandom, therefore we need to check for this
before using it.
Fixes errorr e.g.

| ../../../gnutls-3.5.3/lib/nettle/rnd-linux.c: In function 'have_getrandom':
| ../../../gnutls-3.5.3/lib/nettle/rnd-linux.c:59:42: error: 'SYS_getrandom' 
undeclared (first use in this function)
|  #  define getrandom(dst,s,flags) syscall(SYS_getrandom, (void*)dst, 
(size_t)s, (unsigned int)flags)

Signed-off-by: Khem Raj 
Signed-off-by: Martin Jansa 
---
 .../gnutls/gnutls/check_SYS_getrandom.patch| 35 ++
 meta/recipes-support/gnutls/gnutls_3.5.3.bb|  1 +
 2 files changed, 36 insertions(+)
 create mode 100644 meta/recipes-support/gnutls/gnutls/check_SYS_getrandom.patch

diff --git a/meta/recipes-support/gnutls/gnutls/check_SYS_getrandom.patch 
b/meta/recipes-support/gnutls/gnutls/check_SYS_getrandom.patch
new file mode 100644
index 000..535c22a
--- /dev/null
+++ b/meta/recipes-support/gnutls/gnutls/check_SYS_getrandom.patch
@@ -0,0 +1,35 @@
+From f26c3979ab0325edb2e410d287bc501cf00e0ac0 Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos 
+Date: Mon, 22 Aug 2016 16:32:34 +0200
+Subject: [PATCH] rnd-linux: added check for SYS_getrandom being defined
+
+This allows to compile the getrandom() code in old Linux systems
+which do not have the system call defined.
+---
+
+Upstream-Status: Backport
+Signed-off-by: Khem Raj 
+
+ lib/nettle/rnd-linux.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/lib/nettle/rnd-linux.c b/lib/nettle/rnd-linux.c
+index d7f07a6..7a24d05 100644
+--- a/lib/nettle/rnd-linux.c
 b/lib/nettle/rnd-linux.c
+@@ -56,7 +56,11 @@ static dev_t _gnutls_urandom_fd_rdev = 0;
+ # else
+ #  include 
+ #  undef getrandom
+-#  define getrandom(dst,s,flags) syscall(SYS_getrandom, (void*)dst, 
(size_t)s, (unsigned int)flags)
++#  if defined(SYS_getrandom)
++#   define getrandom(dst,s,flags) syscall(SYS_getrandom, (void*)dst, 
(size_t)s, (unsigned int)flags)
++#  else
++#   define getrandom(dst,s,flags) -1
++#  endif
+ # endif
+ 
+ static unsigned have_getrandom(void)
+--
+libgit2 0.24.0
+
diff --git a/meta/recipes-support/gnutls/gnutls_3.5.3.bb 
b/meta/recipes-support/gnutls/gnutls_3.5.3.bb
index b2dbb07..0400588 100644
--- a/meta/recipes-support/gnutls/gnutls_3.5.3.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.5.3.bb
@@ -4,6 +4,7 @@ SRC_URI += "file://correct_rpl_gettimeofday_signature.patch \
 file://0001-configure.ac-fix-sed-command.patch \
 file://use-pkg-config-to-locate-zlib.patch \
 file://0001-Use-correct-include-dir-with-minitasn.patch \
+file://check_SYS_getrandom.patch \
 file://CVE-2016-7444.patch \
"
 SRC_URI[md5sum] = "6c2c7f40ddf52933ee3ca474cb8cb63c"
-- 
2.7.4

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


Re: [OE-core] [PATCH 4/5] musl: Update to 1.1.18

2017-12-01 Thread Andre McCurdy
On Wed, Nov 8, 2017 at 5:58 PM, Khem Raj  wrote:
> Rich Felker (9):
>   fix access by setjmp and longjmp to __hwcap on arm built as thumb2
>   for executing init array functions, use function type with prototype
>   fix read-after-free type error in pthread_detach
>   fix incorrect base name offset from nftw when pathname ends in slash(es)
>   in dns parsing callback, enforce MAXADDRS to preclude overflow
>   release 1.1.17
>   fix regression in glob with literal . or .. path component
>   fix build regression on ARM for ISA levels less than v5
>   release 1.1.18
>
> Szabolcs Nagy (1):
>   math: rewrite fma with mostly int arithmetics
>
> Will Dietz (1):
>   posix_spawn: use larger stack to cover worst-case in execvpe

With the version of musl currently included in rocko, various apps
(including bash) segfault at startup when compiled as Thumb2. The "fix
access by setjmp and longjmp to __hwcap on arm built as thumb2" commit
from musl 1.1.18 fixes that.

However the other changes in musl 1.1.18 look pretty useful too, so
unless there's strong objection, I'd like to suggest aligning rocko
with the musl 1.1.18 release. ie cherry-picking the following two
commits from oe-core master to rocko:

  c3f0a70 musl: Update to 1.1.18
  3953c54 musl: Update to latest


> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/musl/musl_git.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/musl/musl_git.bb 
> b/meta/recipes-core/musl/musl_git.bb
> index 671de326fb..932c9a27a0 100644
> --- a/meta/recipes-core/musl/musl_git.bb
> +++ b/meta/recipes-core/musl/musl_git.bb
> @@ -3,9 +3,9 @@
>
>  require musl.inc
>
> -SRCREV = "48be5b6313d7b827acf555769e93b389fa9f6307"
> +SRCREV = "eb03bde2f24582874cb72b56c7811bf51da0c817"
>
> -PV = "1.1.16+git${SRCPV}"
> +PV = "1.1.18+git${SRCPV}"
>
>  # mirror is at git://github.com/kraj/musl.git
>
> --
> 2.15.0
>
> --
> ___
> 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] ✗ patchtest: failure for initramfs-framework installation improvements (rev4)

2017-12-01 Thread Martin Jansa
Is it trying to apply whole series (including the 2 patches which were
already merged to master and actually introduced the issue I was trying to
fix)?

Does it mean that I cannot send a fix into the e-mail thread where the
issue was introduced and discussed?

Regards,

On Fri, Dec 1, 2017 at 11:02 PM, Patchwork <
patchw...@patchwork.openembedded.org> wrote:

> == Series Details ==
>
> Series: initramfs-framework installation improvements (rev4)
> Revision: 4
> URL   : https://patchwork.openembedded.org/series/9783/
> State : failure
>
> == Summary ==
>
>
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
>
>
>
> * Issue Series does not apply on top of target branch
> [test_series_merge_on_head]
>   Suggested fixRebase your series on top of targeted branch
>   Targeted branch  master (currently at addf309165)
>
>
>
> If you believe any of these test results are incorrect, please reply to the
> mailing list (openembedded-core@lists.openembedded.org) raising your
> concerns.
> Otherwise we would appreciate you correcting the issues and submitting a
> new
> version of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
>
> ---
> Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_
> Guidelines
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 3/3 V2] initramfs-framework: add install module

2017-12-01 Thread Cal Sullivan
My bad. I was using initramfs-module-install-efi as a template when I 
shouldn't have.


I see you already sent a patch addressing the issue. Looks good, and 
thanks for that.


---
Cal

On 12/01/2017 01:01 PM, Martin Jansa wrote:
Why does it inherit allarch when it depends on TUNE_PKGARCH grub and 
other packages?


Also it should repect the restrictions which are in grub recipe:

COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
COMPATIBLE_HOST_armv7a = 'null'
COMPATIBLE_HOST_armv7ve = 'null'

because without it it adds new ERROR to "bitbake world":
ERROR: Nothing RPROVIDES 'grub' (but 
oe-core/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb 
 RDEPENDS on or otherwise 
requires it)
grub was skipped: incompatible with host arm-oe-linux-gnueabi (not in 
COMPATIBLE_HOST)
grub was skipped: incompatible with host arm-oe-linux-gnueabi (not in 
COMPATIBLE_HOST)

NOTE: Runtime target 'grub' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['grub']
ERROR: Required build target 'meta-world-pkgdata' has no buildable 
providers.


On Tue, Nov 14, 2017 at 11:03 PM, California Sullivan 
> wrote:


The non-EFI counterpart for installation was previously missing for
initramfs-framework. This simply puts the normal install script in the
correct location for initramfs-framework to make use of it.

Signed-off-by: California Sullivan
mailto:california.l.sulli...@intel.com>>
---
V2 changes:
* Add the module's dependencies to
SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS, since
  its dependencies changing don't matter in regards building the
package.
* PR = "r1" since its a new recipe.

 meta/conf/layer.conf                                 |  4 
 .../initrdscripts/initramfs-module-install_1.0.bb
   | 20 
 2 files changed, 24 insertions(+)
 create mode 100644
meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb


diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 0342324..6782058 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -57,6 +57,10 @@ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
   initramfs-module-install-efi->e2fsprogs \
   initramfs-module-install-efi->parted \
   initramfs-module-install-efi->util-linux \
+  initramfs-module-install->e2fsprogs \
+  initramfs-module-install->grub \
+  initramfs-module-install->parted \
+  initramfs-module-install->util-linux \
   liberation-fonts->fontconfig \
   cantarell-fonts->fontconfig \
   gnome-icon-theme->librsvg \
diff --git
a/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb

b/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb

new file mode 100644
index 000..ce7f165
--- /dev/null
+++
b/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb

@@ -0,0 +1,20 @@
+SUMMARY = "initramfs-framework module for installation option"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+RDEPENDS_${PN} = "initramfs-framework-base grub parted
e2fsprogs-mke2fs util-linux-blkid"
+
+PR = "r1"
+
+inherit allarch
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+SRC_URI = "file://init-install.sh"
+
+S = "${WORKDIR}"
+
+do_install() {
+    install -d ${D}/init.d
+    install -m 0755 ${WORKDIR}/init-install.sh ${D}/init.d/install.sh
+}
+
+FILES_${PN} = "/init.d/install.sh"
--
2.9.5

--
___
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] ✗ patchtest: failure for initramfs-framework installation improvements (rev4)

2017-12-01 Thread Patchwork
== Series Details ==

Series: initramfs-framework installation improvements (rev4)
Revision: 4
URL   : https://patchwork.openembedded.org/series/9783/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at addf309165)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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


[OE-core] [PATCH] initramfs-module-install: Remove allarch and FILESEXTRAPATHS

2017-12-01 Thread Martin Jansa
* files is already included in default FILESPATH
* it cannot inherit allarch as it RDEPENDS on bunch of TUNE_PKGARCH packages
* use the same COMPATIBLE_HOST restrictions as grub has to prevent ERRORs in
  bitbake world
  ERROR: Nothing RPROVIDES 'grub' (but 
oe-core/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb 
RDEPENDS on or otherwise requires it)
  grub was skipped: incompatible with host arm-oe-linux-gnueabi (not in 
COMPATIBLE_HOST)
  grub was skipped: incompatible with host arm-oe-linux-gnueabi (not in 
COMPATIBLE_HOST)
  NOTE: Runtime target 'grub' is unbuildable, removing...
  Missing or unbuildable dependency chain was: ['grub']
  ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.

Signed-off-by: Martin Jansa 
---
 .../initrdscripts/initramfs-module-install-efi_1.0.bb | 3 ---
 meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb   | 8 +---
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git 
a/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb
index 24b53a8..1e7f76f 100644
--- a/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb
@@ -5,9 +5,6 @@ RDEPENDS_${PN} = "initramfs-framework-base parted 
e2fsprogs-mke2fs dosfstools ut
 
 PR = "r4"
 
-inherit allarch
-
-FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
 SRC_URI = "file://init-install-efi.sh"
 
 S = "${WORKDIR}"
diff --git a/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb
index ce7f165..02b69f3 100644
--- a/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb
@@ -3,11 +3,13 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 RDEPENDS_${PN} = "initramfs-framework-base grub parted e2fsprogs-mke2fs 
util-linux-blkid"
 
-PR = "r1"
+# The same restriction as grub
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
+COMPATIBLE_HOST_armv7a = 'null'
+COMPATIBLE_HOST_armv7ve = 'null'
 
-inherit allarch
+PR = "r1"
 
-FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
 SRC_URI = "file://init-install.sh"
 
 S = "${WORKDIR}"
-- 
2.7.4

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


Re: [OE-core] [PATCH] musl: prevent errors if do_install is run more than once

2017-12-01 Thread Khem Raj
On Fri, Dec 1, 2017 at 1:22 PM Matthew McClintock 
wrote:

> On Fri, Dec 1, 2017 at 2:13 PM, Khem Raj  wrote:
> > On Fri, Dec 1, 2017 at 11:30 AM, Andre McCurdy 
> wrote:
> >> On Fri, Dec 1, 2017 at 3:07 AM, Burton, Ross 
> wrote:
> >>> Extend lnr to have a --force option?
> >>
> >> Is there ever a case where we want lnr to fail if the target already
> exists?
> >>
> >> There are plenty of existing examples in oe-core where rm is run
> >> before lnr (and in the cases where it's not, it's perhaps just a bug
> >> or an oversight).
> >>
> >> So I think either leave the v1 patch as-is and run rm before lnr in
> >> musl do_install as we already do elsewhere, or update lnr so that it
> >> unconditionally removes any pre-existing target?
> >
> > I like Ross'es suggestion to modify lnr implementation as an
> > independent patch and
> > rebase your patch on top. Maybe a cleanup later to remove all rm cmds
> > that are used
> > before lnr
>
> Do we keep the lnr filename? Change to ln-python and add -r and -f?
>
> The above question wasn't answered. Should we just always force it and
> emit a WARNING if it's being replaced?


It’s should force replace it yes a note about replacing an existing file if
any is fine

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


Re: [OE-core] [PATCH] musl: prevent errors if do_install is run more than once

2017-12-01 Thread Matthew McClintock
On Fri, Dec 1, 2017 at 2:13 PM, Khem Raj  wrote:
> On Fri, Dec 1, 2017 at 11:30 AM, Andre McCurdy  wrote:
>> On Fri, Dec 1, 2017 at 3:07 AM, Burton, Ross  wrote:
>>> Extend lnr to have a --force option?
>>
>> Is there ever a case where we want lnr to fail if the target already exists?
>>
>> There are plenty of existing examples in oe-core where rm is run
>> before lnr (and in the cases where it's not, it's perhaps just a bug
>> or an oversight).
>>
>> So I think either leave the v1 patch as-is and run rm before lnr in
>> musl do_install as we already do elsewhere, or update lnr so that it
>> unconditionally removes any pre-existing target?
>
> I like Ross'es suggestion to modify lnr implementation as an
> independent patch and
> rebase your patch on top. Maybe a cleanup later to remove all rm cmds
> that are used
> before lnr

Do we keep the lnr filename? Change to ln-python and add -r and -f?

The above question wasn't answered. Should we just always force it and
emit a WARNING if it's being replaced?

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


Re: [OE-core] [PATCH 5/5] lib/oe/package.py: is_elf: Make it less prone to false positives

2017-12-01 Thread Olof Johansson
On 17-12-01 11:43 -0600, Mark Hatle wrote:
> The original implementation did not include the ',' options because different
> versions of file (as well as different architectures) would return different
> strings.
> 
> They all contains the same information, but order and inclusion of ',' changed
> regularly.
> 
> So I would caution that for this to check out a wide variety of host systems 
> and
> architectures would need to be verified.  (It's very possible that all modern
> systems now conform to a single standard...)
> 
> (The rest of the serious looks like a very good improvement, and I've got no
> further comments on that.)

I was a little bit worried about this, thanks, this is useful
feedback. Perhaps dropping the "," while still retaining the
whitespace delimitation could be enough, and still work with a
variety of file implementations?

And while we're talking portability, is the use of GNU file's
--brief option a problem (as introduced by another patch in this
series)? It isn't specified in posix, I don't know how widespread
it is.

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


Re: [OE-core] [PATCH 3/3 V2] initramfs-framework: add install module

2017-12-01 Thread Martin Jansa
Why does it inherit allarch when it depends on TUNE_PKGARCH grub and other
packages?

Also it should repect the restrictions which are in grub recipe:

COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
COMPATIBLE_HOST_armv7a = 'null'
COMPATIBLE_HOST_armv7ve = 'null'

because without it it adds new ERROR to "bitbake world":
ERROR: Nothing RPROVIDES 'grub' (but
oe-core/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb
RDEPENDS on or otherwise requires it)
grub was skipped: incompatible with host arm-oe-linux-gnueabi (not in
COMPATIBLE_HOST)
grub was skipped: incompatible with host arm-oe-linux-gnueabi (not in
COMPATIBLE_HOST)
NOTE: Runtime target 'grub' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['grub']
ERROR: Required build target 'meta-world-pkgdata' has no buildable
providers.

On Tue, Nov 14, 2017 at 11:03 PM, California Sullivan <
california.l.sulli...@intel.com> wrote:

> The non-EFI counterpart for installation was previously missing for
> initramfs-framework. This simply puts the normal install script in the
> correct location for initramfs-framework to make use of it.
>
> Signed-off-by: California Sullivan 
> ---
> V2 changes:
> * Add the module's dependencies to SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS, since
>   its dependencies changing don't matter in regards building the package.
> * PR = "r1" since its a new recipe.
>
>  meta/conf/layer.conf |  4 
>  .../initrdscripts/initramfs-module-install_1.0.bb| 20
> 
>  2 files changed, 24 insertions(+)
>  create mode 100644 meta/recipes-core/initrdscripts/initramfs-
> module-install_1.0.bb
>
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index 0342324..6782058 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -57,6 +57,10 @@ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
>initramfs-module-install-efi->e2fsprogs \
>initramfs-module-install-efi->parted \
>initramfs-module-install-efi->util-linux \
> +  initramfs-module-install->e2fsprogs \
> +  initramfs-module-install->grub \
> +  initramfs-module-install->parted \
> +  initramfs-module-install->util-linux \
>liberation-fonts->fontconfig \
>cantarell-fonts->fontconfig \
>gnome-icon-theme->librsvg \
> diff --git a/meta/recipes-core/initrdscripts/initramfs-
> module-install_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-
> module-install_1.0.bb
> new file mode 100644
> index 000..ce7f165
> --- /dev/null
> +++ b/meta/recipes-core/initrdscripts/initramfs-module-install_1.0.bb
> @@ -0,0 +1,20 @@
> +SUMMARY = "initramfs-framework module for installation option"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=
> 3da9cfbcb788c80a0384361b4de20420"
> +RDEPENDS_${PN} = "initramfs-framework-base grub parted e2fsprogs-mke2fs
> util-linux-blkid"
> +
> +PR = "r1"
> +
> +inherit allarch
> +
> +FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> +SRC_URI = "file://init-install.sh"
> +
> +S = "${WORKDIR}"
> +
> +do_install() {
> +install -d ${D}/init.d
> +install -m 0755 ${WORKDIR}/init-install.sh ${D}/init.d/install.sh
> +}
> +
> +FILES_${PN} = "/init.d/install.sh"
> --
> 2.9.5
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] musl: prevent errors if do_install is run more than once

2017-12-01 Thread Khem Raj
On Fri, Dec 1, 2017 at 11:30 AM, Andre McCurdy  wrote:
> On Fri, Dec 1, 2017 at 3:07 AM, Burton, Ross  wrote:
>> Extend lnr to have a --force option?
>
> Is there ever a case where we want lnr to fail if the target already exists?
>
> There are plenty of existing examples in oe-core where rm is run
> before lnr (and in the cases where it's not, it's perhaps just a bug
> or an oversight).
>
> So I think either leave the v1 patch as-is and run rm before lnr in
> musl do_install as we already do elsewhere, or update lnr so that it
> unconditionally removes any pre-existing target?

I like Ross'es suggestion to modify lnr implementation as an
independent patch and
rebase your patch on top. Maybe a cleanup later to remove all rm cmds
that are used
before lnr
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] bitbake.conf: set more conservative default for IMAGE_FSTYPES_DEBUGFS

2017-12-01 Thread Andre McCurdy
On Tue, Nov 7, 2017 at 2:35 PM, Andre McCurdy  wrote:
> On Fri, Oct 27, 2017 at 2:50 PM, Andre McCurdy  wrote:
>> Setting IMAGE_FSTYPES_DEBUGFS to the same value as IMAGE_FSTYPES can
>> lead to creating a large number of DEBUGFS filesystem images, many of
>> which may not make much sense (or may not even be buildable).
>
> Ping.

Ping again. Any issues with this change?

>> Signed-off-by: Andre McCurdy 
>> ---
>>  meta/conf/bitbake.conf | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index 9696273..15feb57 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -757,7 +757,7 @@ require conf/sanity.conf
>>  DL_DIR ?= "${TOPDIR}/downloads"
>>  SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
>>  IMAGE_FSTYPES ?= "tar.gz"
>> -IMAGE_FSTYPES_DEBUGFS ?= "${IMAGE_FSTYPES}"
>> +IMAGE_FSTYPES_DEBUGFS ?= "tar.gz"
>>
>>  INITRAMFS_FSTYPES ?= "cpio.gz"
>>  # The maximum size in Kbytes for the generated initramfs image size.
>> --
>> 1.9.1
>>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] musl: prevent errors if do_install is run more than once

2017-12-01 Thread Andre McCurdy
On Fri, Dec 1, 2017 at 3:07 AM, Burton, Ross  wrote:
> Extend lnr to have a --force option?

Is there ever a case where we want lnr to fail if the target already exists?

There are plenty of existing examples in oe-core where rm is run
before lnr (and in the cases where it's not, it's perhaps just a bug
or an oversight).

So I think either leave the v1 patch as-is and run rm before lnr in
musl do_install as we already do elsewhere, or update lnr so that it
unconditionally removes any pre-existing target?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 5/5] lib/oe/package.py: is_elf: Make it less prone to false positives

2017-12-01 Thread Mark Hatle
On 12/1/17 9:50 AM, Olof Johansson wrote:
> Avoid matching substrings that are picked up from paths, for instance.
> Do this by anchoring the tokens we look for (e.g "executable" or "not
> stripped") with whitespace and punctuation.
> 
> Submitted with this patch series is a change that adds the use of
> --brief to file. This removes the path prefix to the output, but the
> path can still be included in shebang lines (which file will report as
> something like "a /foo/bar/baz.py script").
> 
> Signed-off-by: Olof Johansson 
> ---
>  meta/lib/oe/package.py | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
> index 976d2ef36c..2bd771cfc5 100644
> --- a/meta/lib/oe/package.py
> +++ b/meta/lib/oe/package.py
> @@ -84,17 +84,17 @@ def is_elf(path, on_error=_is_elf_error):
>  error_cb('"file %s" failed')
>  return
>  
> -if not "ELF" in result:
> +if not result.startswith("ELF "):
>  return 0
>  
>  exec_type = 1
> -if "not stripped" not in result:
> +if ", not stripped" not in result:

The original implementation did not include the ',' options because different
versions of file (as well as different architectures) would return different
strings.

They all contains the same information, but order and inclusion of ',' changed
regularly.

So I would caution that for this to check out a wide variety of host systems and
architectures would need to be verified.  (It's very possible that all modern
systems now conform to a single standard...)

(The rest of the serious looks like a very good improvement, and I've got no
further comments on that.)

--Mark

>  exec_type |= 2
> -if "executable" in result:
> +if " executable, " in result:
>  exec_type |= 4
> -if "shared" in result:
> +if " shared object, " in result:
>  exec_type |= 8
> -if "relocatable" in result and is_kernel_module(path):
> +if "relocatable, " in result and is_kernel_module(path):
>  exec_type |= 16
>  return exec_type
>  
> 

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


[OE-core] [PATCH 3/3] utils: qemurunner.py: cleanup grammar and ensure consistency

2017-12-01 Thread Mark Asselstine
Minor grammar correction along with making the term 'login banner'
consistent throughout to make searching logs easier.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/utils/qemurunner.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index dfcd63e..c962602 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -317,7 +317,7 @@ class QemuRunner:
 
 if not reachedlogin:
 if time.time() >= endtime:
-self.logger.debug("Target didn't reached login boot in %d 
seconds (%s)" %
+self.logger.debug("Target didn't reach login banner in %d 
seconds (%s)" %
   (self.boottime, time.strftime("%D 
%H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
 # in case bootlog is empty, use tail qemu log store at self.msg
-- 
2.7.4

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


[OE-core] [PATCH 2/3] utils: qemurunner.py: Log both 'failed to reach login banner" reasons

2017-12-01 Thread Mark Asselstine
The current logging always assumes the boot timeout has expired yet
there is a second reason we might have ended up in a position where no
login banner was found, that being a socket disconnect. Add logging
for the disconnect case and make the timeout expiration conditional on
the timeout being exhausted.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/utils/qemurunner.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 8296e98..dfcd63e 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -307,14 +307,18 @@ class QemuRunner:
   (time.time() - (endtime - 
self.boottime),
   time.strftime("%D %H:%M:%S")))
 else:
+# no need to check if reachedlogin unless we support 
multiple connections
+self.logger.debug("QEMU socket disconnected before 
login banner reached. (%s)" %
+  time.strftime("%D %H:%M:%S"))
 socklist.remove(sock)
 sock.close()
 stopread = True
 
 
 if not reachedlogin:
-self.logger.debug("Target didn't reached login boot in %d seconds 
(%s)" %
-  (self.boottime, time.strftime("%D %H:%M:%S")))
+if time.time() >= endtime:
+self.logger.debug("Target didn't reached login boot in %d 
seconds (%s)" %
+  (self.boottime, time.strftime("%D 
%H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
 # in case bootlog is empty, use tail qemu log store at self.msg
 lines = tail(bootlog if bootlog else self.msg)
-- 
2.7.4

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


[OE-core] [PATCH 1/3] utils: qemurunner.py: Add wall clock to 'timeout' logging

2017-12-01 Thread Mark Asselstine
When debugging issues when timeouts are involved it is always best to
have wall clock times included. This helps give confidence that the
timeout is in fact run down at the right rate and that no unexpected
events were the true cause of a premature running down of the
timeout. Having these times in old logs also helps when debugging
issues as we have a historic record as to what is a 'typical' time to
complete an action.

In addition to adding the wall clock times the time to 'login' is now
printed making it consistent with the time to 'qemu pid'.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/utils/qemurunner.py | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 0631d43..8296e98 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -194,7 +194,8 @@ class QemuRunner:
 sys.exit(0)
 
 self.logger.debug("runqemu started, pid is %s" % self.runqemu.pid)
-self.logger.debug("waiting at most %s seconds for qemu pid" % 
self.runqemutime)
+self.logger.debug("waiting at most %s seconds for qemu pid (%s)" %
+  (self.runqemutime, time.strftime("%D %H:%M:%S")))
 endtime = time.time() + self.runqemutime
 while not self.is_alive() and time.time() < endtime:
 if self.runqemu.poll():
@@ -208,7 +209,8 @@ class QemuRunner:
 time.sleep(0.5)
 
 if not self.is_alive():
-self.logger.error("Qemu pid didn't appear in %s seconds" % 
self.runqemutime)
+self.logger.error("Qemu pid didn't appear in %s seconds (%s)" %
+  (self.runqemutime, time.strftime("%D %H:%M:%S")))
 # Dump all processes to help us to figure out what is going on...
 ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,command '], 
stdout=subprocess.PIPE).communicate()[0]
 processes = ps.decode("utf-8")
@@ -225,7 +227,9 @@ class QemuRunner:
 # We are alive: qemu is running
 out = self.getOutput(output)
 netconf = False # network configuration is not required by default
-self.logger.debug("qemu started in %s seconds - qemu procces pid is 
%s" % (time.time() - (endtime - self.runqemutime), self.qemupid))
+self.logger.debug("qemu started in %s seconds - qemu procces pid is %s 
(%s)" %
+  (time.time() - (endtime - self.runqemutime),
+   self.qemupid, time.strftime("%D %H:%M:%S")))
 if get_ip:
 cmdline = ''
 with open('/proc/%s/cmdline' % self.qemupid) as p:
@@ -269,7 +273,8 @@ class QemuRunner:
 return False
 
 self.logger.debug("Output from runqemu:\n%s", out)
-self.logger.debug("Waiting at most %d seconds for login banner" % 
self.boottime)
+self.logger.debug("Waiting at most %d seconds for login banner (%s)" %
+  (self.boottime, time.strftime("%D %H:%M:%S")))
 endtime = time.time() + self.boottime
 socklist = [self.server_socket]
 reachedlogin = False
@@ -298,7 +303,9 @@ class QemuRunner:
 self.server_socket = qemusock
 stopread = True
 reachedlogin = True
-self.logger.debug("Reached login banner")
+self.logger.debug("Reached login banner in %s 
seconds (%s)" %
+  (time.time() - (endtime - 
self.boottime),
+  time.strftime("%D %H:%M:%S")))
 else:
 socklist.remove(sock)
 sock.close()
@@ -306,7 +313,8 @@ class QemuRunner:
 
 
 if not reachedlogin:
-self.logger.debug("Target didn't reached login boot in %d seconds" 
% self.boottime)
+self.logger.debug("Target didn't reached login boot in %d seconds 
(%s)" %
+  (self.boottime, time.strftime("%D %H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
 # in case bootlog is empty, use tail qemu log store at self.msg
 lines = tail(bootlog if bootlog else self.msg)
-- 
2.7.4

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


Re: [OE-core] [PATCH 1/1] ltp: add runtime depends ltp-staticdev

2017-12-01 Thread Burton, Ross
On 1 December 2017 at 14:51, Khem Raj  wrote:

> On Thu, Nov 30, 2017 at 10:58 PM, Dengke Du 
> wrote:
> > The test case nm01 depends on /opt/ltp/testcases/data/nm01/lib.a in
> > ltp-staticdev package.
> >
>
> perhaps its better to create a packaging exception to include this static
> library to be packaged into ${PN}


Definitely.  For ltp I suspect the standard PN PN-dev PN-staticdev split is
entirely pointless, so just don't create those extra packages and silence
the QA checks.

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


Re: [OE-core] [PATCH 1/1] ltp: add runtime depends ltp-staticdev

2017-12-01 Thread Tim Orling
On Fri, Dec 1, 2017 at 6:52 AM Khem Raj  wrote:

> On Thu, Nov 30, 2017 at 10:58 PM, Dengke Du 
> wrote:
> > The test case nm01 depends on /opt/ltp/testcases/data/nm01/lib.a in
> > ltp-staticdev package.
> >
>
> perhaps its better to create a packaging exception to include this static
> library to be packaged into ${PN}
>
> > Signed-off-by: Dengke Du 
> > ---
> >  meta/recipes-extended/ltp/ltp_20170929.bb | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/recipes-extended/ltp/ltp_20170929.bb
> b/meta/recipes-extended/ltp/ltp_20170929.bb
> > index 93a59b3..6fd280c 100644
> > --- a/meta/recipes-extended/ltp/ltp_20170929.bb
> > +++ b/meta/recipes-extended/ltp/ltp_20170929.bb
> > @@ -108,6 +108,7 @@ RDEPENDS_${PN} = "\
> >  FILES_${PN}-staticdev += "/opt/ltp/lib/libmem.a
> /opt/ltp/testcases/data/nm01/lib.a"
> >
> >  FILES_${PN} += "/opt/ltp/* /opt/ltp/runtest/*
> /opt/ltp/scenario_groups/* /opt/ltp/testcases/bin/*
> /opt/ltp/testcases/bin/*/bin/* /opt/ltp/testscripts/*
> /opt/ltp/testcases/open_posix_testsuite/*
> /opt/ltp/testcases/open_posix_testsuite/conformance/*
> /opt/ltp/testcases/open_posix_testsuite/Documentation/*
> /opt/ltp/testcases/open_posix_testsuite/functional/*
> /opt/ltp/testcases/open_posix_testsuite/include/*
> /opt/ltp/testcases/open_posix_testsuite/scripts/*
> /opt/ltp/testcases/open_posix_testsuite/stress/*
> /opt/ltp/testcases/open_posix_testsuite/tools/*"
> > +RDEPENDES_${PN} += "${PN}-staticdev"
>

Typo in RDEPENDS
Please make sure you test patches before submitting. This could not have
worked as intended.

>
> >  # Avoid generated binaries stripping. Otherwise some of the ltp tests
> such as ldd01 & nm01 fails
> >  INHIBIT_PACKAGE_STRIP = "1"
> > --
> > 2.8.1
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/5] lib/oe/package.py: Expose is_elf

2017-12-01 Thread Olof Johansson
is_elf/isELF had copies in both staging.bbclass and package.bbclass.
After recent refactoring in staging.bbclass (involving breaking out the
isELF function to is_elf in lib/oe/package.py), the implementions
diverged. It would be beneficial to make everybody use this one
implementation, so let's expose it here for others to use.

Signed-off-by: Olof Johansson 
---
 meta/lib/oe/package.py | 88 +++---
 1 file changed, 54 insertions(+), 34 deletions(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 1e5c3aa8e1..f1f9333e0f 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -1,3 +1,6 @@
+import mmap
+import oe.utils
+
 def runstrip(arg):
 # Function to strip a single file, called from split_and_strip_files below
 # A working 'file' (one which works on the target architecture)
@@ -44,6 +47,56 @@ def runstrip(arg):
 
 return
 
+# Detect .ko module by searching for "vermagic=" string
+def is_kernel_module(path):
+with open(path) as f:
+return mmap.mmap(f.fileno(), 0, 
prot=mmap.PROT_READ).find(b"vermagic=") >= 0
+
+def _is_elf_error(msg):
+bb.error('is_elf: %s' % msg)
+
+def is_elf(path, on_error=_is_elf_error):
+"""
+Determine if a given file is an ELF archive (and other attributes),
+using the file utility.
+
+:param path: str, path of potential ELF file
+:param on_error: callable, gets called when an error occurs.
+ the callback takes a message parameter. A
+ default error handler is provided that prints
+ the message with 'bb.error'.
+
+is_elf returns a bitstring of flags, corresponding to various
+properties:
+
+*  1: ELF
+*  2: stripped
+*  4: executable
+*  8: shared library
+* 16: kernel module
+
+A return value of 0 means that the file is not an ELF file.
+"""
+ret, result = oe.utils.getstatusoutput(
+"file \"%s\"" % path.replace("\"", "\\\""))
+
+if ret:
+error_cb('"file %s" failed')
+return
+
+if not "ELF" in result:
+return 0
+
+exec_type = 1
+if "not stripped" not in result:
+exec_type |= 2
+if "executable" in result:
+exec_type |= 4
+if "shared" in result:
+exec_type |= 8
+if "relocatable" in result and is_kernel_module(path):
+exec_type |= 16
+return exec_type
 
 def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
qa_already_stripped=False):
 """
@@ -56,40 +109,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
qa_already_stripped=
 :param qa_already_stripped: Set to True if already-stripped' in 
${INSANE_SKIP}
 This is for proper logging and messages only.
 """
-import stat, errno, oe.path, oe.utils, mmap
-
-# Detect .ko module by searching for "vermagic=" string
-def is_kernel_module(path):
-with open(path) as f:
-return mmap.mmap(f.fileno(), 0, 
prot=mmap.PROT_READ).find(b"vermagic=") >= 0
-
-# Return type (bits):
-# 0 - not elf
-# 1 - ELF
-# 2 - stripped
-# 4 - executable
-# 8 - shared library
-# 16 - kernel module
-def is_elf(path):
-exec_type = 0
-ret, result = oe.utils.getstatusoutput(
-"file \"%s\"" % path.replace("\"", "\\\""))
-
-if ret:
-bb.error("split_and_strip_files: 'file %s' failed" % path)
-return exec_type
-
-if "ELF" in result:
-exec_type |= 1
-if "not stripped" not in result:
-exec_type |= 2
-if "executable" in result:
-exec_type |= 4
-if "shared" in result:
-exec_type |= 8
-if "relocatable" in result and is_kernel_module(path):
-exec_type |= 16
-return exec_type
+import stat, errno, oe.path, oe.utils
 
 elffiles = {}
 inodes = {}
-- 
2.11.0

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


[OE-core] [PATCH 2/5] package.bbclass: Make use of common is_elf function

2017-12-01 Thread Olof Johansson
The isELF and is_elf function share a common ancestry, but have
diverged. Let's use the implementation from oe.package.

Signed-off-by: Olof Johansson 
---
 meta/classes/package.bbclass | 40 +---
 1 file changed, 9 insertions(+), 31 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 2053d46395..f65596126d 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -857,6 +857,12 @@ python fixup_perms () {
 
 python split_and_strip_files () {
 import stat, errno
+import oe.package
+
+def is_elf(path):
+return oe.package.is_elf(
+path, lambda msg: package_qa_handle_error("split-strip", msg, d)
+)
 
 dvar = d.getVar('PKGD')
 pn = d.getVar('PN')
@@ -892,34 +898,6 @@ python split_and_strip_files () {
 sourcefile = d.expand("${WORKDIR}/debugsources.list")
 bb.utils.remove(sourcefile)
 
-# Return type (bits):
-# 0 - not elf
-# 1 - ELF
-# 2 - stripped
-# 4 - executable
-# 8 - shared library
-# 16 - kernel module
-def isELF(path):
-type = 0
-ret, result = oe.utils.getstatusoutput("file \"%s\"" % 
path.replace("\"", "\\\""))
-
-if ret:
-msg = "split_and_strip_files: 'file %s' failed" % path
-package_qa_handle_error("split-strip", msg, d)
-return type
-
-# Not stripped
-if "ELF" in result:
-type |= 1
-if "not stripped" not in result:
-type |= 2
-if "executable" in result:
-type |= 4
-if "shared" in result:
-type |= 8
-return type
-
-
 #
 # First lets figure out all of the files we may have to process ... do 
this only once!
 #
@@ -961,14 +939,14 @@ python split_and_strip_files () {
 # If it's a symlink, and points to an ELF file, we capture 
the readlink target
 if cpath.islink(file):
 target = os.readlink(file)
-if isELF(ltarget):
-#bb.note("Sym: %s (%d)" % (ltarget, 
isELF(ltarget)))
+if is_elf(ltarget):
+#bb.note("Sym: %s (%d)" % (ltarget, 
is_elf(ltarget)))
 symlinks[file] = target
 continue
 
 # It's a file (or hardlink), not a link
 # ...but is it ELF, and is it already stripped?
-elf_file = isELF(file)
+elf_file = is_elf(file)
 if elf_file & 1:
 if elf_file & 2:
 if 'already-stripped' in (d.getVar('INSANE_SKIP_' 
+ pn) or "").split():
-- 
2.11.0

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


[OE-core] [PATCH 4/5] lib/oe/package.py: is_elf: Disallow shell specials to be expanded

2017-12-01 Thread Olof Johansson
By using single quotes instead of double quotes, we don't have to worry
about escaping dangerous characters, other than ' itself.

Signed-off-by: Olof Johansson 
---
 meta/lib/oe/package.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index eab94feb91..976d2ef36c 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -78,7 +78,7 @@ def is_elf(path, on_error=_is_elf_error):
 A return value of 0 means that the file is not an ELF file.
 """
 ret, result = oe.utils.getstatusoutput(
-"file -b \"%s\"" % path.replace("\"", "\\\""))
+"file -b '%s'" % path.replace("'", "\\'"))
 
 if ret:
 error_cb('"file %s" failed')
-- 
2.11.0

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


[OE-core] [PATCH 0/5] Improve isELF, gets triggered by ELF anywhere in pathname

2017-12-01 Thread Olof Johansson
If the substring "ELF" is found anywhere in the pathname, the isELF function
would identify the file as an ELF file. The function could also be used to
execute arbitrary shell commands as the user running bitbake, since the file
execution allows processing of shell meta characters like variable expansion.

The isELF function has been copied and was until this patchset available from
two locations, one in lib/oe/package.py and one in package.bbclass. The two
functions had diverged. This is changed so that one common implementation is
used.

Olof Johansson (5):
  lib/oe/package.py: Expose is_elf
  package.bbclass: Make use of common is_elf function
  lib/oe/package.py: is_elf: Don't let filename influence filetype
  lib/oe/package.py: is_elf: Disallow shell specials to be expanded
  lib/oe/package.py: is_elf: Make it less prone to false positives

 meta/classes/package.bbclass | 40 +---
 meta/lib/oe/package.py   | 88 +++-
 2 files changed, 63 insertions(+), 65 deletions(-)

-- 
2.11.0

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


[OE-core] [PATCH 5/5] lib/oe/package.py: is_elf: Make it less prone to false positives

2017-12-01 Thread Olof Johansson
Avoid matching substrings that are picked up from paths, for instance.
Do this by anchoring the tokens we look for (e.g "executable" or "not
stripped") with whitespace and punctuation.

Submitted with this patch series is a change that adds the use of
--brief to file. This removes the path prefix to the output, but the
path can still be included in shebang lines (which file will report as
something like "a /foo/bar/baz.py script").

Signed-off-by: Olof Johansson 
---
 meta/lib/oe/package.py | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 976d2ef36c..2bd771cfc5 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -84,17 +84,17 @@ def is_elf(path, on_error=_is_elf_error):
 error_cb('"file %s" failed')
 return
 
-if not "ELF" in result:
+if not result.startswith("ELF "):
 return 0
 
 exec_type = 1
-if "not stripped" not in result:
+if ", not stripped" not in result:
 exec_type |= 2
-if "executable" in result:
+if " executable, " in result:
 exec_type |= 4
-if "shared" in result:
+if " shared object, " in result:
 exec_type |= 8
-if "relocatable" in result and is_kernel_module(path):
+if "relocatable, " in result and is_kernel_module(path):
 exec_type |= 16
 return exec_type
 
-- 
2.11.0

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


[OE-core] [PATCH 3/5] lib/oe/package.py: is_elf: Don't let filename influence filetype

2017-12-01 Thread Olof Johansson
The is_elf function is simply looking for the substring ELF in the
output from file. But file, by default, prefixes the outut with the
filename. If the filename containts the substring ELF anywhere, is_elf
would identify it as a ELF.

The --brief (or -b) flag of GNU's file utility makes file not prepend
filename to the output.

Signed-off-by: Olof Johansson 
---
 meta/lib/oe/package.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index f1f9333e0f..eab94feb91 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -78,7 +78,7 @@ def is_elf(path, on_error=_is_elf_error):
 A return value of 0 means that the file is not an ELF file.
 """
 ret, result = oe.utils.getstatusoutput(
-"file \"%s\"" % path.replace("\"", "\\\""))
+"file -b \"%s\"" % path.replace("\"", "\\\""))
 
 if ret:
 error_cb('"file %s" failed')
-- 
2.11.0

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


Re: [OE-core] [PATCH 1/1] ltp: add runtime depends ltp-staticdev

2017-12-01 Thread Khem Raj
On Thu, Nov 30, 2017 at 10:58 PM, Dengke Du  wrote:
> The test case nm01 depends on /opt/ltp/testcases/data/nm01/lib.a in
> ltp-staticdev package.
>

perhaps its better to create a packaging exception to include this static
library to be packaged into ${PN}

> Signed-off-by: Dengke Du 
> ---
>  meta/recipes-extended/ltp/ltp_20170929.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-extended/ltp/ltp_20170929.bb 
> b/meta/recipes-extended/ltp/ltp_20170929.bb
> index 93a59b3..6fd280c 100644
> --- a/meta/recipes-extended/ltp/ltp_20170929.bb
> +++ b/meta/recipes-extended/ltp/ltp_20170929.bb
> @@ -108,6 +108,7 @@ RDEPENDS_${PN} = "\
>  FILES_${PN}-staticdev += "/opt/ltp/lib/libmem.a 
> /opt/ltp/testcases/data/nm01/lib.a"
>
>  FILES_${PN} += "/opt/ltp/* /opt/ltp/runtest/* /opt/ltp/scenario_groups/* 
> /opt/ltp/testcases/bin/* /opt/ltp/testcases/bin/*/bin/* 
> /opt/ltp/testscripts/* /opt/ltp/testcases/open_posix_testsuite/* 
> /opt/ltp/testcases/open_posix_testsuite/conformance/* 
> /opt/ltp/testcases/open_posix_testsuite/Documentation/* 
> /opt/ltp/testcases/open_posix_testsuite/functional/* 
> /opt/ltp/testcases/open_posix_testsuite/include/* 
> /opt/ltp/testcases/open_posix_testsuite/scripts/* 
> /opt/ltp/testcases/open_posix_testsuite/stress/* 
> /opt/ltp/testcases/open_posix_testsuite/tools/*"
> +RDEPENDES_${PN} += "${PN}-staticdev"
>
>  # Avoid generated binaries stripping. Otherwise some of the ltp tests such 
> as ldd01 & nm01 fails
>  INHIBIT_PACKAGE_STRIP = "1"
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] xserver-xf86-config: remove last trace of 10-preload-modules.conf

2017-12-01 Thread Ross Burton
This file has been removed but the CONFFILES assignment for it wasn't.

Signed-off-by: Ross Burton 
---
 meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb 
b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
index 4c442bc7123..5420b7d23e5 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
@@ -10,7 +10,6 @@ SRC_URI = "file://xorg.conf"
 S = "${WORKDIR}"
 
 CONFFILES_${PN} = "${sysconfdir}/X11/xorg.conf"
-CONFFILES_${PN}_append_libc-musl = " 
${sysconfdir}/X11/xorg.conf.d/10-preload-modules.conf"
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 ALLOW_EMPTY_${PN} = "1"
-- 
2.11.0

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


[OE-core] [PATCH] initramfs-framework: Add exec module

2017-12-01 Thread Otavio Salvador
This new module allow for easy execution of external scripts or
applications. It runs anything found in /exec.d directory in order and
in case of no scripts to be available, it opens a shell.

Signed-off-by: Otavio Salvador 
---

 .../initrdscripts/initramfs-framework/exec | 29 ++
 .../initrdscripts/initramfs-framework_1.0.bb   |  9 +++
 2 files changed, 38 insertions(+)
 create mode 100644 meta/recipes-core/initrdscripts/initramfs-framework/exec

diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/exec 
b/meta/recipes-core/initrdscripts/initramfs-framework/exec
new file mode 100644
index 00..a8e2432bb6
--- /dev/null
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/exec
@@ -0,0 +1,29 @@
+#!/bin/sh
+# Copyright (C) 2017 O.S. Systems Software LTDA.
+# Licensed on MIT
+
+EXEC_DIR=/exec.d  # place to look for modules
+
+exec_enabled() {
+   return 0
+}
+
+exec_run() {
+   if [ ! -d $EXEC_DIR ]; then
+   msg "No contents to exec in $EXEC_DIR. Starting shell ..."
+   sh
+   fi
+
+   # Load and run modules
+   for m in $EXEC_DIR/*; do
+   # Skip backup files
+   if [ "`echo $m | sed -e 's/\~$//'`" != "$m" ]; then
+   continue
+   fi
+
+   debug "Starting $m"
+
+   # process module
+   ./$m
+   done
+}
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
index 2afc37ee75..75d965f069 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
@@ -8,6 +8,7 @@ PR = "r4"
 inherit allarch
 
 SRC_URI = "file://init \
+   file://exec \
file://rootfs \
file://finish \
file://mdev \
@@ -26,6 +27,9 @@ do_install() {
 install -m 0755 ${WORKDIR}/rootfs ${D}/init.d/90-rootfs
 install -m 0755 ${WORKDIR}/finish ${D}/init.d/99-finish
 
+   # exec
+install -m 0755 ${WORKDIR}/exec ${D}/init.d/89-exec
+
 # mdev
 install -m 0755 ${WORKDIR}/mdev ${D}/init.d/01-mdev
 
@@ -45,6 +49,7 @@ do_install() {
 }
 
 PACKAGES = "${PN}-base \
+initramfs-module-exec \
 initramfs-module-mdev \
 initramfs-module-udev \
 initramfs-module-e2fs \
@@ -62,6 +67,10 @@ FILES_${PN}-base = "/init /init.d/99-finish /dev"
 # and mounts the rootfs. Then 90-rootfs will proceed immediately.
 RRECOMMENDS_${PN}-base += "initramfs-module-rootfs"
 
+SUMMARY_initramfs-module-exec = "initramfs support for easy execution of 
applications"
+RDEPENDS_initramfs-module-exec = "${PN}-base"
+FILES_initramfs-module-exec = "/init.d/89-exec"
+
 SUMMARY_initramfs-module-mdev = "initramfs support for mdev"
 RDEPENDS_initramfs-module-mdev = "${PN}-base busybox-mdev"
 FILES_initramfs-module-mdev = "/init.d/01-mdev"
-- 
2.15.0

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


[OE-core] [PATCH 1/3] grub-efi: Rework GRUB_BUILTIN variable as it is too long

2017-12-01 Thread Otavio Salvador
As we will add new values here, it is better to split it in multiple
lines.

Signed-off-by: Otavio Salvador 
---

Changes in v2:
 - rebase on top of master

 meta/recipes-bsp/grub/grub-efi_2.02.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/grub/grub-efi_2.02.bb 
b/meta/recipes-bsp/grub/grub-efi_2.02.bb
index 44e32a88f1..a7be6cf30d 100644
--- a/meta/recipes-bsp/grub/grub-efi_2.02.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.02.bb
@@ -51,7 +51,8 @@ do_install_append_class-target() {
 {} +
 }
 
-GRUB_BUILDIN ?= "boot linux ext2 fat serial part_msdos part_gpt normal efi_gop 
iso9660 search"
+GRUB_BUILDIN ?= "boot linux ext2 fat serial part_msdos part_gpt normal \
+ efi_gop iso9660 search"
 
 do_deploy() {
# Search for the grub.cfg on the local boot media by using the
-- 
2.15.0

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


[OE-core] [PATCH 3/3] grub: Move grub-editenv packaging to grub2.inc

2017-12-01 Thread Otavio Salvador
The editenv utility must be available on grub and grub-efi so we
better have it inside the grub2.inc file to avoid the duplication of
metadata.

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 meta/recipes-bsp/grub/grub2.inc| 6 ++
 meta/recipes-bsp/grub/grub_2.02.bb | 6 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index a56fbe7bf8..28f96bb162 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -70,3 +70,9 @@ do_configure_prepend() {
 # grub and grub-efi's sysroot/${datadir}/grub/grub-mkconfig_lib are
 # conflicted, remove it since no one uses it.
 SYSROOT_DIRS_BLACKLIST += "${datadir}/grub/grub-mkconfig_lib"
+
+PACKAGES =+ "${PN}-editenv"
+
+FILES_${PN}-editenv = "${bindir}/grub-editenv"
+RDEPENDS_${PN} += "${PN}-editenv"
+RDEPENDS_${PN}_class-native = ""
diff --git a/meta/recipes-bsp/grub/grub_2.02.bb 
b/meta/recipes-bsp/grub/grub_2.02.bb
index b8055e7537..3e61f6a16d 100644
--- a/meta/recipes-bsp/grub/grub_2.02.bb
+++ b/meta/recipes-bsp/grub/grub_2.02.bb
@@ -1,10 +1,6 @@
 require grub2.inc
 
-RDEPENDS_${PN} = "diffutils freetype grub-editenv"
-
-PACKAGES =+ "grub-editenv"
-
-FILES_grub-editenv = "${bindir}/grub-editenv"
+RDEPENDS_${PN} += "diffutils freetype"
 
 do_install_append () {
 install -d ${D}${sysconfdir}/grub.d
-- 
2.15.0

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


[OE-core] [PATCH 2/3] grub-efi: Add loadenv and test as default built-in

2017-12-01 Thread Otavio Salvador
To allow scripting and environment changes, the loadenv and test must
be enabled. This adds those to the default set.

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 meta/recipes-bsp/grub/grub-efi_2.02.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/grub/grub-efi_2.02.bb 
b/meta/recipes-bsp/grub/grub-efi_2.02.bb
index a7be6cf30d..a38d05a2a0 100644
--- a/meta/recipes-bsp/grub/grub-efi_2.02.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.02.bb
@@ -52,7 +52,7 @@ do_install_append_class-target() {
 }
 
 GRUB_BUILDIN ?= "boot linux ext2 fat serial part_msdos part_gpt normal \
- efi_gop iso9660 search"
+ efi_gop iso9660 search loadenv test"
 
 do_deploy() {
# Search for the grub.cfg on the local boot media by using the
-- 
2.15.0

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


Re: [OE-core] [PATCH] musl: prevent errors if do_install is run more than once

2017-12-01 Thread Burton, Ross
Extend lnr to have a --force option?

Ross

On 30 November 2017 at 22:59, Andre McCurdy  wrote:

> On Thu, Nov 30, 2017 at 1:51 PM, Khem Raj  wrote:
> > On Thu, Nov 30, 2017 at 12:20 PM, Andre McCurdy 
> wrote:
> >> Signed-off-by: Andre McCurdy 
> >> ---
> >>  meta/recipes-core/musl/musl_git.bb | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-core/musl/musl_git.bb
> b/meta/recipes-core/musl/musl_git.bb
> >> index 932c9a2..db26b4f 100644
> >> --- a/meta/recipes-core/musl/musl_git.bb
> >> +++ b/meta/recipes-core/musl/musl_git.bb
> >> @@ -57,10 +57,11 @@ do_install() {
> >> oe_runmake install DESTDIR='${D}'
> >>
> >> install -d ${D}${bindir}
> >> +   rm -f ${D}${bindir}/ldd
> >
> > Doesn't lnr take care of removing old file ?
>
> Apparently not:
>
>   $ touch foo
>   $ lnr xxx foo
>   Traceback (most recent call last):
> File "/.../openembedded-core/scripts/lnr", line 21, in 
>   os.symlink(target, linkname)
>   FileExistsError: [Errno 17] File exists: 'xxx' -> 'foo'
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 4/5] webkitgtk: fix compile error when len(TMPDIR) == 410

2017-12-01 Thread Alexander Kanavin

On 12/01/2017 10:26 AM, Alexander Kanavin wrote:

On 12/01/2017 03:46 AM, Robert Yang wrote:
The flags.make is generated by cmake, and as I said in the commit 
message:


"The cmake doesn't support relative path, so we have to edit 
flags.make to fix

the problem"

I'm not familiar with cmake, please let me know if there is a way to make
it generate a relative path in flags.make.


I'll try to find out how it happens, and will get back to you.


Sadly, looks like you are right. Cmake will prepend a full path to every 
include directory, even if they're specified as relative in CmakeLists.txt.


As this is a common problem, should it go to cmake.bbclass perhaps?


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


Re: [OE-core] [PATCH 4/5] webkitgtk: fix compile error when len(TMPDIR) == 410

2017-12-01 Thread Alexander Kanavin

On 12/01/2017 03:46 AM, Robert Yang wrote:

The flags.make is generated by cmake, and as I said in the commit message:

"The cmake doesn't support relative path, so we have to edit flags.make 
to fix

the problem"

I'm not familiar with cmake, please let me know if there is a way to make
it generate a relative path in flags.make.


I'll try to find out how it happens, and will get back to you.

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


Re: [OE-core] [PATCH 1/5] go-native: fix PATH issue when len(TMPDIR) == 410

2017-12-01 Thread Alexander Kanavin

On 12/01/2017 03:40 AM, Robert Yang wrote:

So I don't think that it is worth to use malloc here, the similar to 2 3 5.
And we had used a few similar ways to fix this kinds of issues before.


Okay, that's fair. If there is an upper limit defined somewhere else 
(kernel, glibc) and upstream doesn't mind taking the fix, then I'm fine 
with it.



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