date:20180719

This happened again when this commit was backported to sumo yesterday, so
now newer revision of oe-core sumo needs additional fix for
meta-raspberrypi:
https://github.com/agherzan/meta-raspberrypi/pull/291
this is quite unfortunate, so I'm going to send LIC_FILES_CHKSUM addition
to oe-core recipe before this spreads even more.

On Fri, Jun 22, 2018 at 5:24 PM Martin Jansa  wrote:

> BTW: this breaks raspberrypi builds in interesting way, I've sent PR with
> fix here:
> https://github.com/agherzan/meta-raspberrypi/pull/272
>
> but maybe we can improve this recipe a bit by including Firmware-cypress
> LIC_FILES_CHKSUM here and leaving only more version agnostic changes in
> meta-raspberrypi bbappend.
>
> On Mon, May 21, 2018 at 11:51 PM Otavio Salvador 
> wrote:
>
>> 8fc2d4e Merge git://git.marvell.com/mwifiex-firmware
>> e1abab6 linux-firmware: update Marvell USB8997 firmware image to add WPA2
>> vulnerability fix
>> c38c231 linux-firmware: update Marvell SD8897-B0 firmware image to add
>> WPA2 vulnerability fix
>> 0686ec7 Merge branch 'firmware-update' of
>> https://github.com/intel/opa-firmware
>> bb7f773  Update Intel OPA
>> hfi1 firmware
>> 397a604 qed: Add firmware 8.33.12.0
>> 40d4117 linux-firmware: Add firmware file for Intel Bluetooth,9560
>> bf3934f linux-firmware: Add firmware file for Intel Bluetooth,9260
>> f865934 linux-firmware: Update firmware file for Intel Bluetooth,8265
>> 7dab503 Merge branch 'for-upstream' of git://
>> git.chelsio.net/pub/git/linux-firmware
>> 0caed67  cxgb4:
>> update firmware to revision 1.19.1.0
>> 0783fb9 nfp: add symlink for mixed mode Agilio CX 2x25GbE cards
>> 380957e nfp: update Agilio SmartNIC flower firmware to rev 5701
>> b562d2f linux-firmware: update wil6210 firmware to 5.2.0.18
>> c1aa76a linux-firmware: rsi: update firmware images for Redpine 9113
>> chipset
>> 1621614 Merge tag 'iwlwifi-fw-2018-04-06' of git://
>> git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware
>> 50c1323
>> 
>> iwlwifi: update firmwares for 3160, 3168 and 7265
>> c711ea5 iwlwifi: add some new FW versions and update older ones
>> 8c1e439 amdgpu: update vce firmware for Polaris
>> 31accdf linux-firmware: Add firmware file for Intel Bluetooth,9560
>> 89139e8 linux-firmware: Add firmware file for Intel Bluetooth,9260
>> 58cdb52 linux-firmware: Update firmware file for Intel Bluetooth,8265
>> 9cb49be linux-firmware: Update firmware patch for Intel Bluetooth 8260
>> a3be6d4 Merge https://github.com/Netronome/linux-firmware into netro
>>
>> License-Update: new files and version update. Same terms.
>> Signed-off-by: Otavio Salvador 
>> ---
>>
>>  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> index c96588473b..8d6f2f2dbd 100644
>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> @@ -118,7 +118,7 @@ LIC_FILES_CHKSUM = "\
>>  file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 \
>>  file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
>>  file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \
>> -file://WHENCE;md5=ec6f70c8a1104ff87f6aa144d926f0dd \
>> +file://WHENCE;md5=6f46986f4e913ef16b765c2319cc5141 \
>>  "
>>
>>  # These are not common licenses, set NO_GENERIC_LICENSE for them
>> @@ -181,7 +181,7 @@ NO_GENERIC_LICENSE[Firmware-xc5000] = "LICENCE.xc5000"
>>  NO_GENERIC_LICENSE[Firmware-xc5000c] = "LICENCE.xc5000c"
>>  NO_GENERIC_LICENSE[WHENCE] = "WHENCE"
>>
>> -SRCREV = "4c0bf113a55975d702673e57c5542f150807ad66"
>> +SRCREV = "8fc2d4e55685bf73b6f7752383da9067404a74bb"
>>  PE = "1"
>>  PV = "0.0+git${SRCPV}"
>>
>> --
>> 2.17.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] [PATCH v2] lsb: fix usrmerge install path & QA warning

2018-07-19 Thread Ioan-Adrian Ratiu

${base_prefix} is set in bitbake.conf to empty. This makes lsb_release
always install under /bin which is a problem if usrmerge is in
DISTRO_FEATURES, because it needs to be installed under /usr/bin.

By using ${root_prefix} instead, we fix the usrmerge install path and
the following QA warning goes away while keeping the non-usrmerge path
identical.

WARNING: lsb-5.0-r0 do_package: QA Issue: lsb: Files/directories were
installed but not shipped in any package:
  /bin
  /bin/lsb_release
Please set FILES such that these items are packaged. Alternatively
if they are unneeded, avoid installing them or delete them within do_install.
lsb: 2 installed and not shipped files. [installed-vs-shipped]

Signed-off-by: Ioan-Adrian Ratiu 
---
 meta/recipes-extended/lsb/lsb_5.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/lsb/lsb_5.0.bb 
b/meta/recipes-extended/lsb/lsb_5.0.bb
index df4812e4bc..0a00086d88 100644
--- a/meta/recipes-extended/lsb/lsb_5.0.bb
+++ b/meta/recipes-extended/lsb/lsb_5.0.bb
@@ -34,7 +34,7 @@ S = "${WORKDIR}/lsb-release-1.4"
 CLEANBROKEN = "1"
 
 do_install() {
-   oe_runmake install prefix=${D}${base_prefix} mandir=${D}${datadir}/man/ 
DESTDIR=${D}
+   oe_runmake install prefix=${D}${root_prefix} mandir=${D}${datadir}/man/ 
DESTDIR=${D}
 
# these two dirs are needed by package lsb-dist-checker
mkdir -p ${D}${sysconfdir}/opt
-- 
2.18.0

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

Re: [OE-core] [PATCH] lsb: fix usrmerge install path & QA warning

2018-07-19 Thread Ioan-Adrian Ratiu

On Fri, 20 Jul 2018, "Burton, Ross"  wrote:
> Remember to check what happens without usrmerge:
>
> packages/corei7-64-poky-linux/lsb/lsb: FILELIST: directory renamed
> /bin -> /bin/bin, changed order
>
> lsb:
> /bin/bin/lsb_release

Sorry about that and thanks! I'll send v2 where I'll use ${root_prefix}
which takes into account the presence of usrmerge.

>
> Ross
>
> On 19 July 2018 at 14:41, Ioan-Adrian Ratiu  wrote:
>> ${base_prefix} is set in bitbake.conf to empty. This makes lsb_release
>> always install under /bin which is a problem if usrmerge is in
>> DISTRO_FEATURES, because it needs to be installed under /usr/bin.
>>
>> By using ${base_bindir} instead, we fix the usrmerge install path and
>> the following QA warning goes away.
>>
>> WARNING: lsb-5.0-r0 do_package: QA Issue: lsb: Files/directories were
>> installed but not shipped in any package:
>>   /bin
>>   /bin/lsb_release
>> Please set FILES such that these items are packaged. Alternatively
>> if they are unneeded, avoid installing them or delete them within do_install.
>> lsb: 2 installed and not shipped files. [installed-vs-shipped]
>>
>> Signed-off-by: Ioan-Adrian Ratiu 
>> ---
>>  meta/recipes-extended/lsb/lsb_5.0.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-extended/lsb/lsb_5.0.bb 
>> b/meta/recipes-extended/lsb/lsb_5.0.bb
>> index 746204b6ec..1657ba6f78 100644
>> --- a/meta/recipes-extended/lsb/lsb_5.0.bb
>> +++ b/meta/recipes-extended/lsb/lsb_5.0.bb
>> @@ -33,7 +33,7 @@ S = "${WORKDIR}/lsb-release-1.4"
>>  CLEANBROKEN = "1"
>>
>>  do_install() {
>> -   oe_runmake install prefix=${D}${base_prefix} 
>> mandir=${D}${datadir}/man/ DESTDIR=${D}
>> +   oe_runmake install prefix=${D}${base_bindir} 
>> mandir=${D}${datadir}/man/ DESTDIR=${D}
>>
>> # these two dirs are needed by package lsb-dist-checker
>> mkdir -p ${D}${sysconfdir}/opt
>> --
>> 2.18.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] [OE-Core][PATCH v2] image: Use ${COREBASE}/meta for timestamp, fallback to bitbake.conf

To handle the case where ${COREBASE} isn't the git directory, avoid
erroring out when the git command fails. If we don't have a timestamp
after this, fall back to the timestamp from conf/bitbake.conf.

Signed-off-by: Alex Kiernan 
---

Changes in v2:
- Revert to original behaviour and use ${COREBASE} as per Richard Purdie's
  advice

 meta/classes/image.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index adc50c9..48961b6 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -651,7 +651,10 @@ POPULATE_SDK_PRE_TARGET_COMMAND += 
"${@bb.utils.contains('DISTRO_FEATURES', 'usr
 reproducible_final_image_task () {
 if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
 if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
-REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log -1 
--pretty=%ct`
+REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log -1 
--pretty=%ct 2>/dev/null` || true
+if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" = "" ]; then
+REPRODUCIBLE_TIMESTAMP_ROOTFS=`stat -c%Y 
${@bb.utils.which(d.getVar("BBPATH"), "conf/bitbake.conf")}`
+fi
 fi
 # Set mtime of all files to a reproducible value
 bbnote "reproducible_final_image_task: mtime set to 
$REPRODUCIBLE_TIMESTAMP_ROOTFS"
-- 
2.7.4

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

[OE-core] [rocko][PATCH] wic: if we can't get from ioctl, try from os.stat()

2018-07-19 Thread Anuj Mittal

From: Dogukan Ergun 

Under some conditions, ioctl FIGETBSZ can't return real value.
We can try to use fallback via os.stat() to get block size.

Source of patch:
https://github.com/intel/bmap-tools/commit/17365f4fe9089df7ee9800a2a0ced177ec4798a4

Fixes [YOCTO #12319]

Signed-off-by: Dogukan Ergun 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Anuj Mittal 
---
 scripts/lib/wic/filemap.py | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
index 77e32b9add..a72fa09ef5 100644
--- a/scripts/lib/wic/filemap.py
+++ b/scripts/lib/wic/filemap.py
@@ -37,7 +37,15 @@ def get_block_size(file_obj):
 # Get the block size of the host file-system for the image file by calling
 # the FIGETBSZ ioctl (number 2).
 binary_data = fcntl.ioctl(file_obj, 2, struct.pack('I', 0))
-return struct.unpack('I', binary_data)[0]
+bsize = struct.unpack('I', binary_data)[0]
+if not bsize:
+import os
+stat = os.fstat(file_obj.fileno())
+if hasattr(stat, 'st_blksize'):
+bsize = stat.st_blksize
+else:
+raise IOError("Unable to determine block size")
+return bsize
 
 class ErrorNotSupp(Exception):
 """
-- 
2.17.1

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

Re: [OE-core] [OE-Core][PATCH] image: Use ${COREBASE}/meta for timestamp, fallback to bitbake.conf

On Thu, Jul 19, 2018 at 7:20 PM Khem Raj  wrote:
>
>
> On Thu, Jul 19, 2018 at 10:26 AM Alex Kiernan  wrote:
> >
> > On Thu, Jul 19, 2018 at 6:21 PM Khem Raj  wrote:
> > >
> > >
> > >
> > > On 7/19/18 10:12 AM, Alex Kiernan wrote:
> > > > To handle the case where ${COREBASE} isn't the git directory, but
> > > > ${COREBASE}/meta might be (since that's the layer that sets up the 
> > > > COREBASE
> > > > variable), use the timestamp from there. If that fails use the timestamp
> > > > from conf/bitbake.conf.
> > >
> > > whats the chance that ${COREBASE}/meta might also not be a directory
> > > under git when compared to ${COREBASE} ?
> > >
> >
> > About the same I expect, but if it's not then git will climb up to
> > ${COREBASE} so I think we're better off.
> >
> > And if it doesn't find one then it falls back to the timestamp on
> > bitbake.conf - I've just been testing a snapshot of the layers as a
> > tarball and building successfully inside that when there's no git
> > directories for it to find at all.
> >
>
> OK lets stay with adding bitbake.conf as fallback.
>

I've just re-read Richard's advice from before:

  I'd suggest the code checks for ${COREBASE}/.git and if that doesn't
  exist, fall back to the timestamp of the
  ${COREBASE}/meta/conf/bitbake.conf file.

Which it'd been my intention to follow; I'll swap it back to
${COREBASE}/.git and post V2.



> > > >
> > > > Signed-off-by: Alex Kiernan 
> > > > ---
> > > >
> > > >   meta/classes/image.bbclass | 5 -
> > > >   1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> > > > index adc50c9..0afebff 100644
> > > > --- a/meta/classes/image.bbclass
> > > > +++ b/meta/classes/image.bbclass
> > > > @@ -651,7 +651,10 @@ POPULATE_SDK_PRE_TARGET_COMMAND += 
> > > > "${@bb.utils.contains('DISTRO_FEATURES', 'usr
> > > >   reproducible_final_image_task () {
> > > >   if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
> > > >   if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
> > > > -REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log -1 
> > > > --pretty=%ct`
> > > > +REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}/meta" 
> > > > log -1 --pretty=%ct 2>/dev/null` || true
> > > > +if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" = "" ]; then
> > > > +REPRODUCIBLE_TIMESTAMP_ROOTFS=`stat -c%Y 
> > > > ${@bb.utils.which(d.getVar("BBPATH"), "conf/bitbake.conf")}`
> > > > +fi
> > > >   fi
> > > >   # Set mtime of all files to a reproducible value
> > > >   bbnote "reproducible_final_image_task: mtime set to 
> > > > $REPRODUCIBLE_TIMESTAMP_ROOTFS"
> > > >
> >
> >
> >
> > --
> > Alex Kiernan



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

[OE-core] [PATCH v2] cross-canadian/libgcc: fix aarch64's multilib SDK

2018-07-19 Thread Lei Maohui

The arm toolchain has a "-gnueabi" suffix, but aarch64 doesn't,
this makes multilib sdk doesn't work, there will be error as following:

.../usr/libexec/armeb-poky-linux-gux-linux-gnueabi/7.3.0/real-ld: cannot find 
crtbeginS.o: No such file or directo
.../usr/libexec/armeb-poky-linux-gux-linux-gnueabi/7.3.0/real-ld: cannot find 
-lgcc
.../usr/libexec/armeb-poky-linux-gux-linux-gnueabi/7.3.0/real-ld: cannot find 
-lgcc
collect2: error: ld returned 1 exit status

Signed-off-by: Robert Yang 
Signed-off-by: Lei Maohui 
---
 meta/recipes-devtools/gcc/libgcc-common.inc | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-devtools/gcc/libgcc-common.inc 
b/meta/recipes-devtools/gcc/libgcc-common.inc
index 848a476..a49fc98 100644
--- a/meta/recipes-devtools/gcc/libgcc-common.inc
+++ b/meta/recipes-devtools/gcc/libgcc-common.inc
@@ -145,11 +145,22 @@ fakeroot python do_extra_symlinks() {
 if bb.data.inherits_class('nativesdk', d):
 return
 
-targetsys = d.getVar('BASETARGET_SYS')
+base_targetsys = d.getVar('BASETARGET_SYS')
+targetsys = d.getVar('TARGET_SYS')
+
+if base_targetsys != targetsys:
+dest = d.getVar('D') + d.getVar('libdir') + '/' + base_targetsys
+dest_list = [dest]
+# For multilib like aarch64 + arm, need 2 symlinks:
+# 1) BASETARGET_SYS as usual
+# 2) BASETARGET_SYS + "-gnueabi" for multilib
+libce = d.getVar('LIBCEXTENSION')
+abie = d.getVar('ABIEXTENSION')
+if abie and libce and targetsys.endswith(libce + abie):
+dest_list.append(dest + libce + abie)
+src = targetsys
+for dir in dest_list:
+if not os.path.lexists(dir) and os.path.lexists(d.getVar('D', 
True) + d.getVar('libdir', True)):
+os.symlink(src, dir)
 
-if targetsys != d.getVar('TARGET_SYS'):
-dest = d.getVar('D') + d.getVar('libdir') + '/' + targetsys
-src = d.getVar('TARGET_SYS')
-if not os.path.lexists(dest) and os.path.lexists(d.getVar('D') + 
d.getVar('libdir')):
-os.symlink(src, dest)
 }
-- 
2.7.4



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

[OE-core] [PATCH v2] sshd: add sshd.service

2018-07-19 Thread Zheng Ruoqin

Add sshd.service for user to start the sshd daemon.

Signed-off-by: Zheng Ruoqin 
---
 meta/recipes-connectivity/openssh/openssh/sshd.service | 16 
 meta/recipes-connectivity/openssh/openssh_7.7p1.bb |  6 ++
 2 files changed, 22 insertions(+)
 create mode 100644 meta/recipes-connectivity/openssh/openssh/sshd.service

diff --git a/meta/recipes-connectivity/openssh/openssh/sshd.service 
b/meta/recipes-connectivity/openssh/openssh/sshd.service
new file mode 100644
index 000..eb87d32
--- /dev/null
+++ b/meta/recipes-connectivity/openssh/openssh/sshd.service
@@ -0,0 +1,16 @@
+[Unit]
+Description=OpenSSH server daemon
+Documentation=man:sshd(8) man:sshd_config(5)
+After=network.target sshd-keygen.service
+Wants=sshd-keygen.service
+
+[Service]
+EnvironmentFile=/etc/sysconfig/sshd
+ExecStart=/usr/sbin/sshd -D $OPTIONS
+ExecReload=/bin/kill -HUP $MAINPID
+KillMode=process
+Restart=on-failure
+RestartSec=42s
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/recipes-connectivity/openssh/openssh_7.7p1.bb 
b/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
index b3da5f6..b4f4c6d 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
@@ -17,6 +17,7 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
file://ssh_config \
file://init \
${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', 
'', d)} \
+   ${@bb.utils.contains('SSHD_DAEMON', 'service', 
'${SSHD_DAEMON_SRC_URI}', '', d)} \
file://sshd.socket \
file://sshd@.service \
file://sshdgenkeys.service \
@@ -30,6 +31,8 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
 
 PAM_SRC_URI = "file://sshd"
 
+SSHD_DAEMON_SRC_URI = "file://sshd.service"
+
 SRC_URI[md5sum] = "68ba883aff6958297432e5877e9a0fe2"
 SRC_URI[sha256sum] = 
"d73be7e684e99efcd024be15a30bffcbe41b012b2f7b3c9084aed621775e6b8f"
 
@@ -111,6 +114,9 @@ do_install_append () {
echo "HostKey /var/run/ssh/ssh_host_ed25519_key" >> 
${D}${sysconfdir}/ssh/sshd_config_readonly
 
install -d ${D}${systemd_unitdir}/system
+   if [ "${@bb.utils.filter('SSHD_DAEMON', 'service', d)}" ]; then
+   install -c -m 0644 ${WORKDIR}/sshd.service 
${D}${systemd_unitdir}/system
+fi
install -c -m 0644 ${WORKDIR}/sshd.socket ${D}${systemd_unitdir}/system
install -c -m 0644 ${WORKDIR}/sshd@.service 
${D}${systemd_unitdir}/system
install -c -m 0644 ${WORKDIR}/sshdgenkeys.service 
${D}${systemd_unitdir}/system
-- 
2.7.4



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

[OE-core] [PATCH] oeqa: rationalise Perl tests

2018-07-19 Thread Ross Burton

As with the Python test, this can be both better and faster.  No need to copy a
file, just run a one-liner.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/files/test.pl |  2 --
 meta/lib/oeqa/runtime/cases/perl.py | 32 
 meta/lib/oeqa/sdk/cases/perl.py | 25 +++--
 3 files changed, 11 insertions(+), 48 deletions(-)
 delete mode 100644 meta/lib/oeqa/files/test.pl

diff --git a/meta/lib/oeqa/files/test.pl b/meta/lib/oeqa/files/test.pl
deleted file mode 100644
index 689c8f16355..000
--- a/meta/lib/oeqa/files/test.pl
+++ /dev/null
@@ -1,2 +0,0 @@
-$a = 9.01e+21 - 9.01e+21 + 0.01;
-print ("the value of a is ", $a, "\n");
diff --git a/meta/lib/oeqa/runtime/cases/perl.py 
b/meta/lib/oeqa/runtime/cases/perl.py
index d0b7e8ed925..afeeb180e24 100644
--- a/meta/lib/oeqa/runtime/cases/perl.py
+++ b/meta/lib/oeqa/runtime/cases/perl.py
@@ -1,37 +1,13 @@
 import os
 
 from oeqa.runtime.case import OERuntimeTestCase
-from oeqa.core.decorator.depends import OETestDepends
 from oeqa.core.decorator.oeid import OETestID
 from oeqa.runtime.decorator.package import OEHasPackage
 
 class PerlTest(OERuntimeTestCase):
-
-@classmethod
-def setUpClass(cls):
-src = os.path.join(cls.tc.files_dir, 'test.pl')
-dst = '/tmp/test.pl'
-cls.tc.target.copyTo(src, dst)
-
-@classmethod
-def tearDownClass(cls):
-dst = '/tmp/test.pl'
-cls.tc.target.run('rm %s' % dst)
-
-@OETestID(1141)
-@OETestDepends(['ssh.SSHTest.test_ssh'])
-@OEHasPackage(['perl'])
-def test_perl_exists(self):
-status, output = self.target.run('which perl')
-msg = 'Perl binary not in PATH or not on target.'
-self.assertEqual(status, 0, msg=msg)
-
 @OETestID(208)
-@OETestDepends(['perl.PerlTest.test_perl_exists'])
+@OEHasPackage(['perl'])
 def test_perl_works(self):
-status, output = self.target.run('perl /tmp/test.pl')
-msg = 'Exit status was not 0. Output: %s' % output
-self.assertEqual(status, 0, msg=msg)
-
-msg = 'Incorrect output: %s' % output
-self.assertEqual(output, "the value of a is 0.01", msg=msg)
+status, output = self.target.run("perl -e '$_=\"Uryyb, jbeyq\"; 
tr/a-zA-Z/n-za-mN-ZA-M/;print'")
+self.assertEqual(status, 0)
+self.assertEqual(output, "Hello, world")
diff --git a/meta/lib/oeqa/sdk/cases/perl.py b/meta/lib/oeqa/sdk/cases/perl.py
index 8085678116c..ff50b468006 100644
--- a/meta/lib/oeqa/sdk/cases/perl.py
+++ b/meta/lib/oeqa/sdk/cases/perl.py
@@ -1,8 +1,4 @@
-import os
-import shutil
 import unittest
-
-from oeqa.core.utils.path import remove_safe
 from oeqa.sdk.case import OESDKTestCase
 
 class PerlTest(OESDKTestCase):
@@ -12,17 +8,10 @@ class PerlTest(OESDKTestCase):
 self.tc.hasHostPackage("perl-native")):
 raise unittest.SkipTest("No perl package in the SDK")
 
-for f in ['test.pl']:
-shutil.copyfile(os.path.join(self.tc.files_dir, f),
-os.path.join(self.tc.sdk_dir, f))
-self.testfile = os.path.join(self.tc.sdk_dir, "test.pl")
-
-def test_perl_exists(self):
-self._run('which perl')
-
-def test_perl_works(self):
-self._run('perl %s' % self.testfile)
-
-@classmethod
-def tearDownClass(self):
-remove_safe(self.testfile)
+def test_perl(self):
+try:
+cmd = "perl -e '$_=\"Uryyb, jbeyq\"; 
tr/a-zA-Z/n-za-mN-ZA-M/;print'"
+output = self._run(cmd)
+self.assertEqual(output, "Hello, world")
+except subprocess.CalledProcessError as e:
+self.fail("Unexpected exit %d (output %s)" % (e.returncode, 
e.output))
-- 
2.11.0

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

Re: [OE-core] [PATCH] lsb: fix usrmerge install path & QA warning

2018-07-19 Thread Burton, Ross

Remember to check what happens without usrmerge:

packages/corei7-64-poky-linux/lsb/lsb: FILELIST: directory renamed
/bin -> /bin/bin, changed order

lsb:
/bin/bin/lsb_release

Ross

On 19 July 2018 at 14:41, Ioan-Adrian Ratiu  wrote:
> ${base_prefix} is set in bitbake.conf to empty. This makes lsb_release
> always install under /bin which is a problem if usrmerge is in
> DISTRO_FEATURES, because it needs to be installed under /usr/bin.
>
> By using ${base_bindir} instead, we fix the usrmerge install path and
> the following QA warning goes away.
>
> WARNING: lsb-5.0-r0 do_package: QA Issue: lsb: Files/directories were
> installed but not shipped in any package:
>   /bin
>   /bin/lsb_release
> Please set FILES such that these items are packaged. Alternatively
> if they are unneeded, avoid installing them or delete them within do_install.
> lsb: 2 installed and not shipped files. [installed-vs-shipped]
>
> Signed-off-by: Ioan-Adrian Ratiu 
> ---
>  meta/recipes-extended/lsb/lsb_5.0.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-extended/lsb/lsb_5.0.bb 
> b/meta/recipes-extended/lsb/lsb_5.0.bb
> index 746204b6ec..1657ba6f78 100644
> --- a/meta/recipes-extended/lsb/lsb_5.0.bb
> +++ b/meta/recipes-extended/lsb/lsb_5.0.bb
> @@ -33,7 +33,7 @@ S = "${WORKDIR}/lsb-release-1.4"
>  CLEANBROKEN = "1"
>
>  do_install() {
> -   oe_runmake install prefix=${D}${base_prefix} 
> mandir=${D}${datadir}/man/ DESTDIR=${D}
> +   oe_runmake install prefix=${D}${base_bindir} 
> mandir=${D}${datadir}/man/ DESTDIR=${D}
>
> # these two dirs are needed by package lsb-dist-checker
> mkdir -p ${D}${sysconfdir}/opt
> --
> 2.18.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] [PATCH] libx11: remove redundant siteinfo inherit

2018-07-19 Thread Ross Burton

The recipe doesn't use the variables, and autotools inherits this already.

Signed-off-by: Ross Burton 
---
 meta/recipes-graphics/xorg-lib/libx11.inc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc 
b/meta/recipes-graphics/xorg-lib/libx11.inc
index d9a2b52ad69..36c950ad343 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -6,8 +6,6 @@ basic functions of the window system."
 
 require xorg-lib-common.inc
 
-inherit siteinfo
-
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/libx11:"
 
 PE = "1"
-- 
2.11.0

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

Re: [OE-core] [PATCH] musl: Fix dirent struct alignment issue seen on armv5te

2018-07-19 Thread Andrea Adami

On Thu, Jul 19, 2018 at 3:57 PM, Khem Raj  wrote:
> Full logs
> https://git.musl-libc.org/cgit/musl/log/?qt=range&q=9cad27a3dc1a4eb349b6591e4dc8cc89dce32277..18fbc7e4fa254696eb024f56ee74704805925fad
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/musl/musl_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/musl/musl_git.bb 
> b/meta/recipes-core/musl/musl_git.bb
> index b56870cb3f..9a3bbef68e 100644
> --- a/meta/recipes-core/musl/musl_git.bb
> +++ b/meta/recipes-core/musl/musl_git.bb
> @@ -3,7 +3,7 @@
>
>  require musl.inc
>
> -SRCREV = "9cad27a3dc1a4eb349b6591e4dc8cc89dce32277"
> +SRCREV = "18fbc7e4fa254696eb024f56ee74704805925fad"
>
>  PV = "1.1.19+git${SRCPV}"
>
> --
> 2.18.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Thanks. Patch fixes the issue: no more alignment traps on armv5te.
Tested on pxa255/corgi.

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

Re: [OE-core] [oe-core][PATCH] u-boot: Fix pylibfdt generation

2018-07-19 Thread Joshua Watt

On Thu, 2018-07-19 at 21:10 +0100, Burton, Ross wrote:
> On 19 July 2018 at 17:31, Joshua Watt  wrote:
> > +EXTRA_OEMAKE += 'PYTHON=nativepython
> > STAGING_INCDIR=${STAGING_INCDIR_NATIVE}
> > STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}'
> > +DEPENDS += "bc-native dtc-native swig-native python-native"
> 
> Instead of setting PYTHON and DEPENDS, you can just inherit
> pythonnative.

I tried that, but pythonnative.bbclass appears to export the wrong
variables for this case:
 export STAGING_INCDIR
 export STAGING_LIBDIR

u-boot actually needs:

 STAGING_INCDIR=${STAGING_INCDIR_NATIVE}
 STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}

I'm not sure where the disconnect is there?

> 
> Or ideally, if it can use Python 3, inherit python3native.
> 
> Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH] u-boot: Fix pylibfdt generation

2018-07-19 Thread Burton, Ross

On 19 July 2018 at 17:31, Joshua Watt  wrote:
> +EXTRA_OEMAKE += 'PYTHON=nativepython STAGING_INCDIR=${STAGING_INCDIR_NATIVE} 
> STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}'
> +DEPENDS += "bc-native dtc-native swig-native python-native"

Instead of setting PYTHON and DEPENDS, you can just inherit pythonnative.

Or ideally, if it can use Python 3, inherit python3native.

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

[OE-core] [oe-core] INCOMPATIBLE_LICENSE mechanism

2018-07-19 Thread Jonathan Haigh

 Hi,


I have some questions, comments and suggestions about the INCOMPATIBLE_LICENSE 
mechanism:


1. If I specify licenseX in INCOMPATIBLE_LICENSE then I get an error when 
building a recipe with a package (packageA) that just RRECOMMENDS a package 
(packageB) with licenceX, even if I add packageB to 
BAD_RECOMMENDATIONS_pn-packageA. Am I correct in thinking that this behaviour 
is unintentional?


2. When checking whether a license expression is compatible with 
INCOMPATIBLE_LICENSE, the code takes into account "or" operands in the license 
expression, such that if licenseX is in INCOMPATIBLE_LICENSE but licenseY 
isn't, and a package's license expression is "licenseX | licenseY" then the 
license will be deemed okay even though licenseX is incompatible. I don't think 
this consideration of "or" operands is valid. Consider the case where:

  *   packageA has license expression "LGPLv3 | GPLv2;
  *   packageB has license expression "MIT";
  *   packageB dynamically links with packageA;
  *   INCOMPATIBLE_LICENSE = "LGPL-3.0".

PackageB mustn't be using packageA under the terms of the GPLv2 because the 
resulting combination would have to be GPLv2, not MIT, to comply with the terms 
of the GPLv2. PackageB must therefore be using packageA under the terms of the 
LGPLv3, but LGPL-3.0 is in INCOMPATIBLE_LICENSE, so the combination should be 
rejected.


Actually keeping track of how licenses of packages and their dependents 
interact might be too much work, too messy, or require too much legal 
knowledge, so I suggest this special treatment of "or" operands in license 
expressions is removed. Another approach might be to allow packages explicitly 
declare the licenses under which they are using their rdependencies. That 
wouldn't work nicely with the implicit RDEPENDS addition mechanism though.


3. If I understand correctly, INCOMPATIBLE_LICENSE doesn't let me have 
different license policies for packages that go into different images. It would 
be useful to be able to specify INCOMPATIBLE_LICENSE in an image recipe to 
prevent just that image containing packages/recipes with incompatible licenses. 
This would be useful e.g. to have a GPLv3-free production image but allow GPLv3 
packages in a debug image.


4. From the code in license.bbclass, it looks like when writing the rootfs and 
image manifest files, the intended behaviour is to modify the license 
expressions of packages/recipes by removing incompatible "or" branches (which 
seems a little odd, especially given #2). However, this is not the actual 
behaviour of the code when run with Python3. From write_license_files() in 
license.bbclass:

bad_licenses = (d.getVar("INCOMPATIBLE_LICENSE") or "").split()
bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses)
bad_licenses = expand_wildcard_licenses(d, bad_licenses)

expand_wildcard_licenses() expects a list, but in Python3 map() returns some 
sort of iterator, which causes expand_wildcard_licenses() to return an empty 
list. This can be fixed by wrapping the call to map() in a call to list(). I'll 
send a patch for this.


I have a bbclass that adds license checking at the rootfs/image stage and 
doesn't take into account the "or" operands in license expressions, but I think 
it would be better to change/extend the functionality of the 
INCOMPATIBLE_LICENSE mechanism. Do the oe-core maintainers here agree with the 
following approach?

  *   Don't fail a build if a package just RRECOMMENDs another package with an 
incompatible license, only fail if the package is actually built.
  *   Don't take "or" operands into account when checking for incompatible 
licenses.
  *   Add functionality to allow INCOMPATIBLE_LICENSE to just apply to 
packages/recipes that go into a particular image.
  *   Don't modify package/recipe license expressions in the manifest files.

If so, I'd like to contribute patches to do this. I'm not at all familiar with 
how the RRECOMMENDS mechanism works though, so some guidance on that part would 
be useful.

Thanks for all the work being done on OE, it is much appreciated.

Jonathan
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] logrotate: Improve configurability of the installed systemd service files

This makes it possible to add extra options to the logrotate
application (via ${LOGROTATE_OPTIONS}), and it allows the Persistent
option in logrotate.timer to be configured via
${LOGROTATE_SYSTEMD_TIMER_PERSISTENT}.

It also changes the sed expressions to allow for
${LOGROTATE_SYSTEMD_TIMER_BASIS} to contain commas without having to
prefix them with backslahes, e.g.:
LOGROTATE_SYSTEMD_TIMER_BASIS = "*-*-* *:00,30:00"

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-extended/logrotate/logrotate_3.14.0.bb | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-extended/logrotate/logrotate_3.14.0.bb 
b/meta/recipes-extended/logrotate/logrotate_3.14.0.bb
index d48539f84f..ccc68ad3ac 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.14.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.14.0.bb
@@ -34,9 +34,9 @@ PACKAGECONFIG[acl] = ",,acl"
 PACKAGECONFIG[selinux] = ",,libselinux"
 
 CONFFILES_${PN} += "${localstatedir}/lib/logrotate.status \
-   ${sysconfdir}/logrotate.conf \
-   ${sysconfdir}/logrotate.d/btmp \
-   ${sysconfdir}/logrotate.d/wtmp"
+${sysconfdir}/logrotate.conf \
+${sysconfdir}/logrotate.d/btmp \
+${sysconfdir}/logrotate.d/wtmp"
 
 # If RPM_OPT_FLAGS is unset, it adds -g itself rather than obeying our
 # optimization variables, so use it rather than EXTRA_CFLAGS.
@@ -62,8 +62,11 @@ SYSTEMD_SERVICE_${PN} = "\
 ${BPN}.timer \
 "
 
+LOGROTATE_OPTIONS ?= ""
+
 LOGROTATE_SYSTEMD_TIMER_BASIS ?= "daily"
 LOGROTATE_SYSTEMD_TIMER_ACCURACY ?= "12h"
+LOGROTATE_SYSTEMD_TIMER_PERSISTENT ?= "true"
 
 do_install(){
 oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
@@ -78,8 +81,15 @@ do_install(){
 install -d ${D}${systemd_system_unitdir}
 install -m 0644 ${S}/examples/logrotate.service 
${D}${systemd_system_unitdir}/logrotate.service
 install -m 0644 ${S}/examples/logrotate.timer 
${D}${systemd_system_unitdir}/logrotate.timer
-sed -i -e 
's,OnCalendar=.*$,OnCalendar=${LOGROTATE_SYSTEMD_TIMER_BASIS},g' 
${D}${systemd_system_unitdir}/logrotate.timer
-sed -i -e 
's,AccuracySec=.*$,AccuracySec=${LOGROTATE_SYSTEMD_TIMER_ACCURACY},g' 
${D}${systemd_system_unitdir}/logrotate.timer
+[ -z "${LOGROTATE_OPTIONS}" ] ||
+sed -ri \
+-e 's|(ExecStart=.*/logrotate.*)$|\1 ${LOGROTATE_OPTIONS}|g' \
+${D}${systemd_system_unitdir}/logrotate.service
+sed -ri \
+-e 's|(OnCalendar=).*$|\1${LOGROTATE_SYSTEMD_TIMER_BASIS}|g' \
+-e 's|(AccuracySec=).*$|\1${LOGROTATE_SYSTEMD_TIMER_ACCURACY}|g' \
+-e 's|(Persistent=).*$|\1${LOGROTATE_SYSTEMD_TIMER_PERSISTENT}|g' \
+${D}${systemd_system_unitdir}/logrotate.timer
 fi
 
 if ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'true', 'false', 
d)}; then
-- 
2.12.0

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

[OE-core] [PATCH 3/3] base-files: profile: Avoid using "command" to determine if programs exist

Since the existence of "command" in itself is not guaranteed, using it
to determine if other executables exist is moot. Instead just run the
executables and let the shell determine if they exist. By piping stderr
to /dev/null we avoid unnecessary warnings in case they do not exist.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-core/base-files/base-files/profile | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-core/base-files/base-files/profile 
b/meta/recipes-core/base-files/base-files/profile
index a062028226..e14cb2d878 100644
--- a/meta/recipes-core/base-files/base-files/profile
+++ b/meta/recipes-core/base-files/base-files/profile
@@ -20,14 +20,16 @@ if [ -d /etc/profile.d ]; then
unset i
 fi
 
-if command -v resize >/dev/null && command -v tty >/dev/null; then
-   # Make sure we are on a serial console (i.e. the device used starts with
-   # /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which
-   # tries do use ssh
-   case $(tty) in
-   /dev/tty[A-z]*) resize >/dev/null;;
-   esac
-fi
+# Make sure we are on a serial console (i.e. the device used starts with
+# /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which tries do
+# use ssh
+case $(tty 2>/dev/null) in
+   # The first invocation of resize verifies that it exists, the second
+   # does the actual resizing. This is due to that resize uses stderr to
+   # determine the size of the tty, which does not work if it is redirected
+   # to /dev/null.
+   /dev/tty[A-z]*) resize >/dev/null 2>&1 && resize >/dev/null;;
+esac
 
 export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM
 
-- 
2.12.0

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

Re: [OE-core] [OE-Core][PATCH] image: Use ${COREBASE}/meta for timestamp, fallback to bitbake.conf

On Thu, Jul 19, 2018 at 10:26 AM Alex Kiernan 
wrote:
>
> On Thu, Jul 19, 2018 at 6:21 PM Khem Raj  wrote:
> >
> >
> >
> > On 7/19/18 10:12 AM, Alex Kiernan wrote:
> > > To handle the case where ${COREBASE} isn't the git directory, but
> > > ${COREBASE}/meta might be (since that's the layer that sets up the
COREBASE
> > > variable), use the timestamp from there. If that fails use the
timestamp
> > > from conf/bitbake.conf.
> >
> > whats the chance that ${COREBASE}/meta might also not be a directory
> > under git when compared to ${COREBASE} ?
> >
>
> About the same I expect, but if it's not then git will climb up to
> ${COREBASE} so I think we're better off.
>
> And if it doesn't find one then it falls back to the timestamp on
> bitbake.conf - I've just been testing a snapshot of the layers as a
> tarball and building successfully inside that when there's no git
> directories for it to find at all.
>

OK lets stay with adding bitbake.conf as fallback.

> > >
> > > Signed-off-by: Alex Kiernan 
> > > ---
> > >
> > >   meta/classes/image.bbclass | 5 -
> > >   1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> > > index adc50c9..0afebff 100644
> > > --- a/meta/classes/image.bbclass
> > > +++ b/meta/classes/image.bbclass
> > > @@ -651,7 +651,10 @@ POPULATE_SDK_PRE_TARGET_COMMAND +=
"${@bb.utils.contains('DISTRO_FEATURES', 'usr
> > >   reproducible_final_image_task () {
> > >   if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
> > >   if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
> > > -REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log
-1 --pretty=%ct`
> > > +REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}/meta"
log -1 --pretty=%ct 2>/dev/null` || true
> > > +if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" = "" ]; then
> > > +REPRODUCIBLE_TIMESTAMP_ROOTFS=`stat -c%Y
${@bb.utils.which(d.getVar("BBPATH"), "conf/bitbake.conf")}`
> > > +fi
> > >   fi
> > >   # Set mtime of all files to a reproducible value
> > >   bbnote "reproducible_final_image_task: mtime set to
$REPRODUCIBLE_TIMESTAMP_ROOTFS"
> > >
>
>
>
> --
> Alex Kiernan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3] Three miscellaneous patches

These are three miscellaneous patches that I have sent earlier, 
but which somehow seems to have fallen between the cracks. The
original patches should still apply, but I thought it easier
to just resend them.

//Peter

The following changes since commit b0f2f690a3513e4c9fa30fee1b8d7ac2d7140657:

  systemd-boot: upgrade to 239 (2018-07-18 10:18:42 +0100)

are available in the git repository at:

  git://push.yoctoproject.org/poky-contrib pkj/misc-patches

Peter Kjellerstedt (3):
  iptables: Split the iptables modules into separate packages
  logrotate: Improve configurability of the installed systemd service
files
  base-files: profile: Avoid using "command" to determine if programs
exist

 meta/recipes-core/base-files/base-files/profile| 18 +
 meta/recipes-extended/iptables/iptables_1.6.2.bb   | 43 +++---
 .../recipes-extended/logrotate/logrotate_3.14.0.bb | 20 +++---
 3 files changed, 55 insertions(+), 26 deletions(-)

-- 
2.12.0

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

[OE-core] [PATCH 1/3] iptables: Split the iptables modules into separate packages

By splitting the iptables modules into separate packages it is
possible to pick and choose the modules to install and thereby reduce
the total size of the installed modules.

Backwards compatibility is maintained by adding a recommendation of
iptables-modules, which is a meta package that depends on all the
generated packages.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-extended/iptables/iptables_1.6.2.bb | 43 +---
 1 file changed, 30 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-extended/iptables/iptables_1.6.2.bb 
b/meta/recipes-extended/iptables/iptables_1.6.2.bb
index 38a83d2b32..e00824f763 100644
--- a/meta/recipes-extended/iptables/iptables_1.6.2.bb
+++ b/meta/recipes-extended/iptables/iptables_1.6.2.bb
@@ -7,17 +7,6 @@ LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263\
 
file://iptables/iptables.c;beginline=13;endline=25;md5=c5cffd09974558cf27d0f763df2a12dc"
 
-RRECOMMENDS_${PN} = "kernel-module-x-tables \
- kernel-module-ip-tables \
- kernel-module-iptable-filter \
- kernel-module-iptable-nat \
- kernel-module-nf-defrag-ipv4 \
- kernel-module-nf-conntrack \
- kernel-module-nf-conntrack-ipv4 \
- kernel-module-nf-nat \
- kernel-module-ipt-masquerade"
-FILES_${PN} =+ "${libdir}/xtables/ ${datadir}/xtables"
-
 SRC_URI = "http://netfilter.org/projects/iptables/files/iptables-${PV}.tar.bz2 
\

file://0001-configure-Add-option-to-enable-disable-libnfnetlink.patch \

file://0002-configure.ac-only-check-conntrack-when-libnfnetlink-enabled.patch \
@@ -28,8 +17,8 @@ SRC_URI[sha256sum] = 
"55d02dfa46263343a401f297d44190f2a3e5113c8933946f094ed40237
 
 inherit autotools pkgconfig
 
-EXTRA_OECONF = "--with-kernel=${STAGING_INCDIR} \
-   "
+EXTRA_OECONF = "--with-kernel=${STAGING_INCDIR}"
+
 PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
 
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
@@ -45,3 +34,31 @@ do_configure_prepend() {
# Keep ax_check_linker_flags.m4 which belongs to autoconf-archive.
rm -f libtool.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4
 }
+
+PACKAGES += "${PN}-modules"
+PACKAGES_DYNAMIC += "^${PN}-module-.*"
+
+python populate_packages_prepend() {
+modules = do_split_packages(d, '${libdir}/xtables', 'lib(.*)\.so$', 
'${PN}-module-%s', '${PN} module %s', extra_depends='')
+if modules:
+metapkg = d.getVar('PN') + '-modules'
+d.appendVar('RDEPENDS_' + metapkg, ' ' + ' '.join(modules))
+}
+
+FILES_${PN} += "${datadir}/xtables"
+
+ALLOW_EMPTY_${PN}-modules = "1"
+
+RDEPENDS_${PN} = "${PN}-module-xt-standard"
+RRECOMMENDS_${PN} = " \
+${PN}-modules \
+kernel-module-x-tables \
+kernel-module-ip-tables \
+kernel-module-iptable-filter \
+kernel-module-iptable-nat \
+kernel-module-nf-defrag-ipv4 \
+kernel-module-nf-conntrack \
+kernel-module-nf-conntrack-ipv4 \
+kernel-module-nf-nat \
+kernel-module-ipt-masquerade \
+"
-- 
2.12.0

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

Re: [OE-core] [PATCH 1/4] u-boot: Add missing dependency on swig

FWIW: my do_compile_prepend hack to stop autodetecting swig from sysroot
(in pre-RSS - recipe specific sysroots in Yocto 2.2) stopped working in
2017.07 version where it was moved from tools/Makefile:
https://github.com/u-boot/u-boot/commit/727f153629719c93f9c5df6e391fdfee32377ca7#diff-c9b3e9a4c86396781af56d6bdfc8c9f3

It was still building without swig I belive until 2018.07 version which
doesn't use "$(if $(shell which swig 2> /dev/null)" to check for native
swig anymore since:
https://github.com/u-boot/u-boot/commit/15b97f5c5e6d88e0560c6928f3acd01c999a494d#diff-c9b3e9a4c86396781af56d6bdfc8c9f3

Thanks Joshua for the fix.

On Thu, Jul 19, 2018 at 7:00 PM Joshua Watt  wrote:

> On Wed, 2018-07-11 at 20:56 +0200, Marek Vasut wrote:
> > On 07/11/2018 06:10 PM, Burton, Ross wrote:
> > > On 11 July 2018 at 16:03, Marek Vasut  wrote:
> > > > The U-Boot build, in particular the pylibfdt, depends on swig-
> > > > native.
> > > > Add the missing dependency.
> > >
> > > If pylibfdt isn't usually needed (which it cant be, if swig is an
> > > optional build dependency which isn't on my machines, or the
> > > autobuilders, right?) can we just disable the building of pylibfdt
> > > instead?
> >
> > Why do you think libpyfdt isn't usually needed ?
> >
> > Why do you think swig is optional dependency ?
>
> I encountered this same issue and was able to track it down. The
> problem is that u-boot is building pylibfdt using the host Python
> instead of using python-native provided by bitbake. pylibfdt is a non-
> optional dependency for several u-boot configurations, in my case qemu-
> x86 and qemu-x84_64.
>
> I pushed a patch to the mailing list that I think fixes this: http://li
> sts.openembedded.org/pipermail/openembedded-core/2018-July/153115.html
>
> >
> > > Ross
> > >
> >
> >
> > --
> > Best regards,
> > Marek Vasut
> --
> ___
> 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] [OE-Core][PATCH] image: Use ${COREBASE}/meta for timestamp, fallback to bitbake.conf

On Thu, Jul 19, 2018 at 6:21 PM Khem Raj  wrote:
>
>
>
> On 7/19/18 10:12 AM, Alex Kiernan wrote:
> > To handle the case where ${COREBASE} isn't the git directory, but
> > ${COREBASE}/meta might be (since that's the layer that sets up the COREBASE
> > variable), use the timestamp from there. If that fails use the timestamp
> > from conf/bitbake.conf.
>
> whats the chance that ${COREBASE}/meta might also not be a directory
> under git when compared to ${COREBASE} ?
>

About the same I expect, but if it's not then git will climb up to
${COREBASE} so I think we're better off.

And if it doesn't find one then it falls back to the timestamp on
bitbake.conf - I've just been testing a snapshot of the layers as a
tarball and building successfully inside that when there's no git
directories for it to find at all.

> >
> > Signed-off-by: Alex Kiernan 
> > ---
> >
> >   meta/classes/image.bbclass | 5 -
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> > index adc50c9..0afebff 100644
> > --- a/meta/classes/image.bbclass
> > +++ b/meta/classes/image.bbclass
> > @@ -651,7 +651,10 @@ POPULATE_SDK_PRE_TARGET_COMMAND += 
> > "${@bb.utils.contains('DISTRO_FEATURES', 'usr
> >   reproducible_final_image_task () {
> >   if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
> >   if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
> > -REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log -1 
> > --pretty=%ct`
> > +REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}/meta" log 
> > -1 --pretty=%ct 2>/dev/null` || true
> > +if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" = "" ]; then
> > +REPRODUCIBLE_TIMESTAMP_ROOTFS=`stat -c%Y 
> > ${@bb.utils.which(d.getVar("BBPATH"), "conf/bitbake.conf")}`
> > +fi
> >   fi
> >   # Set mtime of all files to a reproducible value
> >   bbnote "reproducible_final_image_task: mtime set to 
> > $REPRODUCIBLE_TIMESTAMP_ROOTFS"
> >



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

Re: [OE-core] [OE-Core][PATCH] image: Use ${COREBASE}/meta for timestamp, fallback to bitbake.conf





On 7/19/18 10:12 AM, Alex Kiernan wrote:

To handle the case where ${COREBASE} isn't the git directory, but
${COREBASE}/meta might be (since that's the layer that sets up the COREBASE
variable), use the timestamp from there. If that fails use the timestamp
from conf/bitbake.conf.


whats the chance that ${COREBASE}/meta might also not be a directory 
under git when compared to ${COREBASE} ?




Signed-off-by: Alex Kiernan 
---

  meta/classes/image.bbclass | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index adc50c9..0afebff 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -651,7 +651,10 @@ POPULATE_SDK_PRE_TARGET_COMMAND += 
"${@bb.utils.contains('DISTRO_FEATURES', 'usr
  reproducible_final_image_task () {
  if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
  if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
-REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log -1 
--pretty=%ct`
+REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}/meta" log -1 
--pretty=%ct 2>/dev/null` || true
+if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" = "" ]; then
+REPRODUCIBLE_TIMESTAMP_ROOTFS=`stat -c%Y 
${@bb.utils.which(d.getVar("BBPATH"), "conf/bitbake.conf")}`
+fi
  fi
  # Set mtime of all files to a reproducible value
  bbnote "reproducible_final_image_task: mtime set to 
$REPRODUCIBLE_TIMESTAMP_ROOTFS"


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

[OE-core] [OE-Core][PATCH] image: Use ${COREBASE}/meta for timestamp, fallback to bitbake.conf

To handle the case where ${COREBASE} isn't the git directory, but
${COREBASE}/meta might be (since that's the layer that sets up the COREBASE
variable), use the timestamp from there. If that fails use the timestamp
from conf/bitbake.conf.

Signed-off-by: Alex Kiernan 
---

 meta/classes/image.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index adc50c9..0afebff 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -651,7 +651,10 @@ POPULATE_SDK_PRE_TARGET_COMMAND += 
"${@bb.utils.contains('DISTRO_FEATURES', 'usr
 reproducible_final_image_task () {
 if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
 if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
-REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log -1 
--pretty=%ct`
+REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}/meta" log -1 
--pretty=%ct 2>/dev/null` || true
+if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" = "" ]; then
+REPRODUCIBLE_TIMESTAMP_ROOTFS=`stat -c%Y 
${@bb.utils.which(d.getVar("BBPATH"), "conf/bitbake.conf")}`
+fi
 fi
 # Set mtime of all files to a reproducible value
 bbnote "reproducible_final_image_task: mtime set to 
$REPRODUCIBLE_TIMESTAMP_ROOTFS"
-- 
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/4] u-boot: Add missing dependency on swig

2018-07-19 Thread Joshua Watt

On Wed, 2018-07-11 at 20:56 +0200, Marek Vasut wrote:
> On 07/11/2018 06:10 PM, Burton, Ross wrote:
> > On 11 July 2018 at 16:03, Marek Vasut  wrote:
> > > The U-Boot build, in particular the pylibfdt, depends on swig-
> > > native.
> > > Add the missing dependency.
> > 
> > If pylibfdt isn't usually needed (which it cant be, if swig is an
> > optional build dependency which isn't on my machines, or the
> > autobuilders, right?) can we just disable the building of pylibfdt
> > instead?
> 
> Why do you think libpyfdt isn't usually needed ?
> 
> Why do you think swig is optional dependency ?

I encountered this same issue and was able to track it down. The
problem is that u-boot is building pylibfdt using the host Python
instead of using python-native provided by bitbake. pylibfdt is a non-
optional dependency for several u-boot configurations, in my case qemu-
x86 and qemu-x84_64.

I pushed a patch to the mailing list that I think fixes this: http://li
sts.openembedded.org/pipermail/openembedded-core/2018-July/153115.html

> 
> > Ross
> > 
> 
> 
> -- 
> Best regards,
> Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH] u-boot: Fix pylibfdt generation

2018-07-19 Thread Joshua Watt

u-boot attempts to build a Python library called pylibfdt. By default,
u-boot would attempt to use the build host's Python interpreter, which
causes numerous problems, not least of which is that it fails if the
host doesn't have the Python development package installed (complaining
about not being able to find Python.h)

Rectify this situation by including the proper build time dependencies
for pylibfdt and passing the proper arguments to make.

Signed-off-by: Joshua Watt 
---
 meta/recipes-bsp/u-boot/u-boot.inc| 1 +
 meta/recipes-bsp/u-boot/u-boot_2018.07.bb | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index c2bcf998402..6b8604ddbec 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -9,6 +9,7 @@ inherit uboot-config uboot-extlinux-config uboot-sign deploy
 
 EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc 
${TOOLCHAIN_OPTIONS}" V=1'
 EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"'
+EXTRA_OEMAKE += 'PYTHON=nativepython STAGING_INCDIR=${STAGING_INCDIR_NATIVE} 
STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}'
 
 PACKAGECONFIG ??= "openssl"
 # u-boot will compile its own tools during the build, with specific
diff --git a/meta/recipes-bsp/u-boot/u-boot_2018.07.bb 
b/meta/recipes-bsp/u-boot/u-boot_2018.07.bb
index 37c21dcaa38..11588a75ed5 100644
--- a/meta/recipes-bsp/u-boot/u-boot_2018.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot_2018.07.bb
@@ -1,4 +1,4 @@
 require u-boot-common_${PV}.inc
 require u-boot.inc
 
-DEPENDS += "bc-native dtc-native"
+DEPENDS += "bc-native dtc-native swig-native python-native"
-- 
2.17.1

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

Re: [OE-core] [PATCH] libnss-mdns: Fix search path for avahi socket file

On Thu, Jul 19, 2018 at 9:25 AM  wrote:
>
> There are several ways to fix it.
>
> 1. Patching Makefiles (see patch in the ticket: 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12843)
>
> 2. Add localstatedir = "/"
>
> 3. Adding --localstatedir=${root_prefix} to EXTRA_OECONF
>
> 4. Don't fix it as /var/run should be a link to /run.
>
>
> So what is the preferred solution?
>
>

I think using root_prefix to point to localestatedir might be ok.


> Khem Raj  hat am 5. Juli 2018 um 19:48 geschrieben:
>
>
> On 7/5/18 10:26 AM, Betacentauri wrote:
>
> Since v0.7 avahi uses /run/avahi-daemon/socket.
> libnss searches in $(localstatedir)/run/avahi-daemon/.
> Set localstatedir to / to fix mdns resolving.
> ---
> meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb 
> b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
> index 5be5e4f..d0eb276 100644
> --- a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
> +++ b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
> @@ -17,6 +17,8 @@ SRC_URI[sha256sum] = 
> "1e683c2e7c3921814706d62fbbd3e9cbf493a75fa00255e0e715508d81
>
> S = "${WORKDIR}/nss-mdns-${PV}"
>
> +localstatedir = "/"
> +
>
>
> Adding --localstatedir=${root_prefix} to EXTRA_OECONF perhaps is better
> for description.
>
> inherit autotools
>
> EXTRA_OECONF = "--libdir=${base_libdir} --disable-lynx --enable-avahi"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libnss-mdns: Fix search path for avahi socket file

2018-07-19 Thread betacentauri

There are several ways to fix it.

1. Patching Makefiles (see patch in the ticket: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12843)

2. Add localstatedir = "/"

3. Adding --localstatedir=${root_prefix} to EXTRA_OECONF

4. Don't fix it as /var/run should be a link to /run.


So what is the preferred solution?


> Khem Raj mailto:raj.k...@gmail.com > hat am 5. Juli 2018 
> um 19:48 geschrieben:
> 
> 
> On 7/5/18 10:26 AM, Betacentauri wrote:
> 
> > > Since v0.7 avahi uses /run/avahi-daemon/socket.
> > libnss searches in $(localstatedir)/run/avahi-daemon/.
> > Set localstatedir to / to fix mdns resolving.
> > ---
> > meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb | 2 ++
> > 1 file changed, 2 insertions(+)
> > 
> > diff --git 
> > a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb 
> > b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
> > index 5be5e4f..d0eb276 100644
> > --- a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
> > +++ b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
> > @@ -17,6 +17,8 @@ SRC_URI[sha256sum] = 
> > "1e683c2e7c3921814706d62fbbd3e9cbf493a75fa00255e0e715508d81
> > 
> > S = "${WORKDIR}/nss-mdns-${PV}"
> > 
> > +localstatedir = "/"
> > +
> > 
> > > Adding --localstatedir=${root_prefix} to EXTRA_OECONF perhaps is 
> > better
> for description.
> 
> > > inherit autotools
> > 
> > EXTRA_OECONF = "--libdir=${base_libdir} --disable-lynx 
> > --enable-avahi"
> > 
> > > 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] systemtap: improve reproducibility

- Fix build path issue of .pyc files;

- Fix build path issue of c++ object files;

[YOCTO #12528]

Signed-off-by: Hongxu Jia 
---
 ...all-python-modules-to-correct-library-dir.patch | 11 ++--
 ...1-improve-reproducibility-for-c-compiling.patch | 31 ++
 meta/recipes-kernel/systemtap/systemtap_git.bb |  8 ++
 3 files changed, 48 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-kernel/systemtap/systemtap/0001-improve-reproducibility-for-c-compiling.patch

diff --git 
a/meta/recipes-kernel/systemtap/systemtap/0001-Install-python-modules-to-correct-library-dir.patch
 
b/meta/recipes-kernel/systemtap/systemtap/0001-Install-python-modules-to-correct-library-dir.patch
index 528864c..c7ba338 100644
--- 
a/meta/recipes-kernel/systemtap/systemtap/0001-Install-python-modules-to-correct-library-dir.patch
+++ 
b/meta/recipes-kernel/systemtap/systemtap/0001-Install-python-modules-to-correct-library-dir.patch
@@ -5,6 +5,13 @@ Subject: [PATCH] Install python modules to correct library dir.
 
 Upstream-Status: Inappropriate [oe-core specific]
 Signed-off-by: Alexander Kanavin 
+
+Supply "--root" directory to the "install" command, and use
+it as a prefix to strip off the purported filename encoded
+in bytecode files. (It strips build path prefix from .pyc files)
+
+Signed-off-by: Hongxu Jia 
+
 ---
  python/Makefile.am | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
@@ -18,7 +25,7 @@ index a254480f9..efe9f3c01 100644
(cd $(srcdir); CFLAGS="$(AM_CPPFLAGS)" $(PYTHON) setup.py build \
   --build-base $(shell readlink -f $(builddir))/py2build \
 -   install --prefix $(DESTDIR)$(prefix) \
-+   install --prefix $(DESTDIR)$(prefix) 
--install-lib=$(DESTDIR)${pythondir} \
++   install --root $(DESTDIR) --prefix $(prefix) --prefix $(prefix) 
--install-lib=${pythondir} \
 --single-version-externally-managed \
 --record $(shell readlink -f $(builddir))/py2build/install_files.txt \
   --verbose)
@@ -27,7 +34,7 @@ index a254480f9..efe9f3c01 100644
(cd $(srcdir); CFLAGS="$(AM_CPPFLAGS)" $(PYTHON3) setup.py build \
   --build-base $(shell readlink -f $(builddir))/py3build \
 -   install --prefix $(DESTDIR)$(prefix) \
-+   install --prefix $(DESTDIR)$(prefix) 
--install-lib=$(DESTDIR)${python3dir} \
++   install --root $(DESTDIR) --prefix $(prefix) 
--install-lib=${python3dir} \
 --single-version-externally-managed \
 --record $(shell readlink -f $(builddir))/py3build/install_files.txt \
   --verbose)
diff --git 
a/meta/recipes-kernel/systemtap/systemtap/0001-improve-reproducibility-for-c-compiling.patch
 
b/meta/recipes-kernel/systemtap/systemtap/0001-improve-reproducibility-for-c-compiling.patch
new file mode 100644
index 000..15a6f2a
--- /dev/null
+++ 
b/meta/recipes-kernel/systemtap/systemtap/0001-improve-reproducibility-for-c-compiling.patch
@@ -0,0 +1,31 @@
+From 6288ba5df0a8c73ef842b609081449ac4de86123 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia 
+Date: Wed, 18 Jul 2018 16:58:33 +0800
+Subject: [PATCH] improve reproducibility for c++ compiling
+
+Use relative dir to include header string_ref to
+strip build path prefix in c++ object file
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia 
+---
+ stringtable.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/stringtable.h b/stringtable.h
+index 5fc42e7..6fd8a1e 100644
+--- a/stringtable.h
 b/stringtable.h
+@@ -19,7 +19,7 @@
+ 
+ #if defined(HAVE_BOOST_UTILITY_STRING_REF_HPP)
+ #include 
+-#include  //header with string_ref
++#include "@RELATIVE_STAGING_INCDIR@/boost/utility/string_ref.hpp" //header 
with string_ref
+ 
+ // XXX: experimental tunables
+ #define INTERNED_STRING_FIND_MEMMEM 1 /* perf stat indicates a very slight 
benefit */
+-- 
+2.7.4
+
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb 
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index b280f58..0b7833e 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -3,6 +3,8 @@ HOMEPAGE = "https://sourceware.org/systemtap/";
 
 require systemtap_git.inc
 
+SRC_URI += "file://0001-improve-reproducibility-for-c-compiling.patch"
+
 DEPENDS = "elfutils"
 
 EXTRA_OECONF += "--with-libelf=${STAGING_DIR_TARGET} --without-rpm \
@@ -25,6 +27,12 @@ PACKAGECONFIG[python3-probes] = 
"--with-python3-probes,--without-python3-probes,
 
 inherit autotools gettext pkgconfig distutils3-base
 
+do_configure_prepend () {
+# Improve reproducibility for c++ object files
+reltivepath="${@os.path.relpath(d.getVar('STAGING_INCDIR'), 
d.getVar('S'))}"
+sed -i "s:@RELATIVE_STAGING_INCDIR@:$reltivepath:g" ${S}/stringtable.h
+}
+
 do_install_append () {
if [ ! -f ${D}${bindir}/stap ]; then
   # translator disabled case, need to leave only minimal runtime
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Op

[OE-core] [PATCH 1/3] distutils/setuptools, distutils3/setuptools3: improve reproducibility

- Unify var-DISTUTILS_INSTALL_ARGS in distutils and setuptools

- Supply "--root" directory to the "install" command, and use
  it as a prefix to strip off the purported filename encoded
  in bytecode files. (It strips build path prefix from .pyc files)

[YOCTO #8446]
[YOCTO #12084]

Signed-off-by: Hongxu Jia 
---
 meta/classes/distutils.bbclass   | 8 +---
 meta/classes/distutils3.bbclass  | 8 +---
 meta/classes/setuptools.bbclass  | 5 -
 meta/classes/setuptools3.bbclass | 4 
 4 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 1930c35..db28767 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -4,8 +4,10 @@ DISTUTILS_BUILD_ARGS ?= ""
 DISTUTILS_STAGE_HEADERS_ARGS ?= "--install-dir=${STAGING_INCDIR}/${PYTHON_DIR}"
 DISTUTILS_STAGE_ALL_ARGS ?= "--prefix=${STAGING_DIR_HOST}${prefix} \
 --install-data=${STAGING_DATADIR}"
-DISTUTILS_INSTALL_ARGS ?= "--prefix=${D}/${prefix} \
---install-data=${D}/${datadir}"
+DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
+--prefix=${prefix} \
+--install-lib=${PYTHON_SITEPACKAGES_DIR} \
+--install-data=${datadir}"
 
 distutils_do_compile() {
  STAGING_INCDIR=${STAGING_INCDIR} \
@@ -34,7 +36,7 @@ distutils_do_install() {
 STAGING_INCDIR=${STAGING_INCDIR} \
 STAGING_LIBDIR=${STAGING_LIBDIR} \
 PYTHONPATH=${D}${PYTHON_SITEPACKAGES_DIR} \
-${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
install --install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} ${DISTUTILS_INSTALL_ARGS} 
|| \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
install ${DISTUTILS_INSTALL_ARGS} || \
 bbfatal_log "${PYTHON_PN} setup.py install execution failed."
 
 # support filenames with *spaces*
diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index d4b92a3..9637486 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -5,8 +5,10 @@ DISTUTILS_BUILD_EXT_ARGS ?= ""
 DISTUTILS_STAGE_HEADERS_ARGS ?= "--install-dir=${STAGING_INCDIR}/${PYTHON_DIR}"
 DISTUTILS_STAGE_ALL_ARGS ?= "--prefix=${STAGING_DIR_HOST}${prefix} \
 --install-data=${STAGING_DATADIR}"
-DISTUTILS_INSTALL_ARGS ?= "--prefix=${D}/${prefix} \
---install-data=${D}/${datadir}"
+DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
+--prefix=${prefix} \
+--install-lib=${PYTHON_SITEPACKAGES_DIR} \
+--install-data=${datadir}"
 
 distutils3_do_configure() {
if [ "${CLEANBROKEN}" != "1" ] ; then
@@ -45,7 +47,7 @@ distutils3_do_install() {
 STAGING_INCDIR=${STAGING_INCDIR} \
 STAGING_LIBDIR=${STAGING_LIBDIR} \
 PYTHONPATH=${D}${PYTHON_SITEPACKAGES_DIR} \
-${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
install --install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} ${DISTUTILS_INSTALL_ARGS} 
|| \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
install ${DISTUTILS_INSTALL_ARGS} || \
 bbfatal_log "${PYTHON_PN} setup.py install execution failed."
 
 # support filenames with *spaces*
diff --git a/meta/classes/setuptools.bbclass b/meta/classes/setuptools.bbclass
index 157ef63..a923ea3 100644
--- a/meta/classes/setuptools.bbclass
+++ b/meta/classes/setuptools.bbclass
@@ -1,8 +1,3 @@
 inherit distutils
 
 DEPENDS += "python-setuptools-native"
-
-DISTUTILS_INSTALL_ARGS = "--root=${D} \
---prefix=${prefix} \
---install-lib=${PYTHON_SITEPACKAGES_DIR} \
---install-data=${datadir}"
diff --git a/meta/classes/setuptools3.bbclass b/meta/classes/setuptools3.bbclass
index de6dd94..8ca66ee 100644
--- a/meta/classes/setuptools3.bbclass
+++ b/meta/classes/setuptools3.bbclass
@@ -2,7 +2,3 @@ inherit distutils3
 
 DEPENDS += "python3-setuptools-native"
 
-DISTUTILS_INSTALL_ARGS = "--root=${D} \
---prefix=${prefix} \
---install-lib=${PYTHON_SITEPACKAGES_DIR} \
---install-data=${datadir}"
-- 
2.7.4

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

[OE-core] [PATCH 3/3] python3-pip: clean up obsolete

Since unify var-DISTUTILS_INSTALL_ARGS in distutils and setuptools,
- The local DISTUTILS_INSTALL_ARGS assignment is obsolete;
- The site.py is not be generated any more;
- The layout is in a standard pip dir (such as /usr/lib/python3.5/site-
  packages/pip rather than /lib/python3.5/site-packages/pip-10.0.1-
  py3.5.egg/pip), the pth file is not required;

`#!/usr/bin/env python3' is already used, do not manually sed.

[YOCTO #8446]

Signed-off-by: Hongxu Jia 
---
 meta/recipes-devtools/python/python3-pip_10.0.1.bb | 18 --
 1 file changed, 18 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-pip_10.0.1.bb 
b/meta/recipes-devtools/python/python3-pip_10.0.1.bb
index 100d4d0..8deec2b 100644
--- a/meta/recipes-devtools/python/python3-pip_10.0.1.bb
+++ b/meta/recipes-devtools/python/python3-pip_10.0.1.bb
@@ -11,27 +11,9 @@ SRC_URI[sha256sum] = 
"f2bd08e0cd1b06e10218feaf6fef299f473ba706582eb3bd9d52203fdb
 
 inherit pypi distutils3
 
-DISTUTILS_INSTALL_ARGS += "--install-lib=${D}${PYTHON_SITEPACKAGES_DIR}"
-
-do_install_prepend() {
-install -d ${D}${PYTHON_SITEPACKAGES_DIR}
-}
-
-# Use setuptools site.py instead, avoid shared state issue
 do_install_append() {
-rm ${D}${PYTHON_SITEPACKAGES_DIR}/site.py
-rm ${D}${PYTHON_SITEPACKAGES_DIR}/__pycache__/site.cpython-*.pyc
-
 # Install as pip3 and leave pip2 as default
 rm ${D}/${bindir}/pip
-
-# Installed eggs need to be passed directly to the interpreter via a pth 
file
-echo "./${PYPI_PACKAGE}-${PV}-py${PYTHON_BASEVERSION}.egg" > 
${D}${PYTHON_SITEPACKAGES_DIR}/${PYPI_PACKAGE}-${PV}.pth
-
-# Make sure we use /usr/bin/env python3
-for PYTHSCRIPT in `grep -rIl ${bindir} ${D}${bindir}/pip3*`; do
-sed -i -e '1s|^#!.*|#!/usr/bin/env python3|' $PYTHSCRIPT
-done
 }
 
 RDEPENDS_${PN} = "\
-- 
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] python-setuptools.inc: clean up useless local var-DISTUTILS_INSTALL_ARGS

Since unify var-DISTUTILS_INSTALL_ARGS in distutils and setuptools,
The local var-DISTUTILS_INSTALL_ARGS broke do_install
...
error: option --script-dir not recognized
ERROR: python3 setup.py install execution failed.
...

[YOCTO #8446]

Signed-off-by: Hongxu Jia 
---
 meta/recipes-devtools/python/python-setuptools.inc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python-setuptools.inc 
b/meta/recipes-devtools/python/python-setuptools.inc
index ab1c013..6dd772d 100644
--- a/meta/recipes-devtools/python/python-setuptools.inc
+++ b/meta/recipes-devtools/python/python-setuptools.inc
@@ -13,9 +13,6 @@ SRC_URI[sha256sum] = 
"012adb8e25fbfd64c652e99e7bab58799a3aaf05d39ab38561f69190a9
 
 DEPENDS += "${PYTHON_PN}"
 
-DISTUTILS_INSTALL_ARGS += "--install-lib=${D}${PYTHON_SITEPACKAGES_DIR} \
-   --script-dir=${bindir}"
-
 RDEPENDS_${PN} = "\
   ${PYTHON_PN}-compile \
   ${PYTHON_PN}-compression \
-- 
2.7.4

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

[OE-core] [PATCH V2 0/3] fix .pyc/.pyo buildpaths issue

Changed in V2: Rebase to latest oe-core

The following changes since commit ff0b682b807959521c85716296de7a1d26d7d18f:

  systemd-boot: upgrade to 239 (2018-07-18 10:13:30 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib hongxu/pyc-buildpath
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=hongxu/pyc-buildpath

Hongxu Jia (3):
  distutils/setuptools, distutils3/setuptools3: improve reproducibility
  python-setuptools.inc: clean up useless local
var-DISTUTILS_INSTALL_ARGS
  python3-pip: clean up obsolete

 meta/classes/distutils.bbclass |  8 +---
 meta/classes/distutils3.bbclass|  8 +---
 meta/classes/setuptools.bbclass|  5 -
 meta/classes/setuptools3.bbclass   |  4 
 meta/recipes-devtools/python/python-setuptools.inc |  3 ---
 meta/recipes-devtools/python/python3-pip_10.0.1.bb | 18 --
 6 files changed, 10 insertions(+), 36 deletions(-)

-- 
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/3] distutils/setuptools, distutils3/setuptools3: improve reproducibility


On 2018年07月19日 21:05, Burton, Ross wrote:

Hi Hongxu,

Can you rebase this to current master?


No problem, V2 incoming

//Hongxu


Cheers,
Ross

On 18 July 2018 at 01:57, Hongxu Jia  wrote:

- Unify var-DISTUTILS_INSTALL_ARGS in distutils and setuptools

- Supply "--root" directory to the "install" command, and use
   it as a prefix to strip off the purported filename encoded
   in bytecode files. (It strips build path prefix from .pyc files)

[YOCTO #8446]
[YOCTO #12084]

Signed-off-by: Hongxu Jia 
---
  meta/classes/distutils.bbclass   | 8 +---
  meta/classes/distutils3.bbclass  | 8 +---
  meta/classes/setuptools.bbclass  | 5 -
  meta/classes/setuptools3.bbclass | 4 
  4 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 1930c35..db28767 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -4,8 +4,10 @@ DISTUTILS_BUILD_ARGS ?= ""
  DISTUTILS_STAGE_HEADERS_ARGS ?= 
"--install-dir=${STAGING_INCDIR}/${PYTHON_DIR}"
  DISTUTILS_STAGE_ALL_ARGS ?= "--prefix=${STAGING_DIR_HOST}${prefix} \
  --install-data=${STAGING_DATADIR}"
-DISTUTILS_INSTALL_ARGS ?= "--prefix=${D}/${prefix} \
---install-data=${D}/${datadir}"
+DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
+--prefix=${prefix} \
+--install-lib=${PYTHON_SITEPACKAGES_DIR} \
+--install-data=${datadir}"

  distutils_do_compile() {
   STAGING_INCDIR=${STAGING_INCDIR} \
@@ -34,7 +36,7 @@ distutils_do_install() {
  STAGING_INCDIR=${STAGING_INCDIR} \
  STAGING_LIBDIR=${STAGING_LIBDIR} \
  PYTHONPATH=${D}${PYTHON_SITEPACKAGES_DIR} \
-${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
install --install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} ${DISTUTILS_INSTALL_ARGS} 
|| \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
install ${DISTUTILS_INSTALL_ARGS} || \
  bbfatal_log "${PYTHON_PN} setup.py install execution failed."

  # support filenames with *spaces*
diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index d4b92a3..9637486 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -5,8 +5,10 @@ DISTUTILS_BUILD_EXT_ARGS ?= ""
  DISTUTILS_STAGE_HEADERS_ARGS ?= 
"--install-dir=${STAGING_INCDIR}/${PYTHON_DIR}"
  DISTUTILS_STAGE_ALL_ARGS ?= "--prefix=${STAGING_DIR_HOST}${prefix} \
  --install-data=${STAGING_DATADIR}"
-DISTUTILS_INSTALL_ARGS ?= "--prefix=${D}/${prefix} \
---install-data=${D}/${datadir}"
+DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
+--prefix=${prefix} \
+--install-lib=${PYTHON_SITEPACKAGES_DIR} \
+--install-data=${datadir}"

  distutils3_do_configure() {
 if [ "${CLEANBROKEN}" != "1" ] ; then
@@ -45,7 +47,7 @@ distutils3_do_install() {
  STAGING_INCDIR=${STAGING_INCDIR} \
  STAGING_LIBDIR=${STAGING_LIBDIR} \
  PYTHONPATH=${D}${PYTHON_SITEPACKAGES_DIR} \
-${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
install --install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} ${DISTUTILS_INSTALL_ARGS} 
|| \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
install ${DISTUTILS_INSTALL_ARGS} || \
  bbfatal_log "${PYTHON_PN} setup.py install execution failed."

  # support filenames with *spaces*
diff --git a/meta/classes/setuptools.bbclass b/meta/classes/setuptools.bbclass
index 157ef63..a923ea3 100644
--- a/meta/classes/setuptools.bbclass
+++ b/meta/classes/setuptools.bbclass
@@ -1,8 +1,3 @@
  inherit distutils

  DEPENDS += "python-setuptools-native"
-
-DISTUTILS_INSTALL_ARGS = "--root=${D} \
---prefix=${prefix} \
---install-lib=${PYTHON_SITEPACKAGES_DIR} \
---install-data=${datadir}"
diff --git a/meta/classes/setuptools3.bbclass b/meta/classes/setuptools3.bbclass
index de6dd94..8ca66ee 100644
--- a/meta/classes/setuptools3.bbclass
+++ b/meta/classes/setuptools3.bbclass
@@ -2,7 +2,3 @@ inherit distutils3

  DEPENDS += "python3-setuptools-native"

-DISTUTILS_INSTALL_ARGS = "--root=${D} \
---prefix=${prefix} \
---install-lib=${PYTHON_SITEPACKAGES_DIR} \
---install-data=${datadir}"
--
2.7.4



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

Re: [OE-core] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs





On 2018-07-19 16:02, Martin Jansa wrote:

I don't want to continue in this discussion, hopefully someone else will
add an opinion as well.

Cheers,


I agree. For a v3 of the patches, I'm OK with reintroducing the 
libvisual packageconfig. As for the rest (--disable-twolame etc.), these 
are a separate discussion, one that goes beyond the scope of these 
patches. I propose we worry about that as part of a separate set of patches.

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

Re: [OE-core] [PATCH][RFC] glibc: Avoid multilibbing on wordsize.h

2018-07-19 Thread Anibal Limon

On Wed, 18 Jul 2018 at 20:27, Daniel Díaz  wrote:

> Once another header #includes , there is a
> potential recursion going on because the
> multilib_header_wrapper.h #includes  again!
>
> This should not happen because an __arm__ (32-bits) or an
> __aarch64__ (64-bits) environment guarantees that we will
> be getting the correct definition, but when building against
> a different target (like BPF), recursion is what happens.
>
> This can be seen, for instance, when building eBPF programs
> from the kernel with `clang -target bpf', such as the ones
> located in linux/tools/testing/selftests/bpf/.
>
> Signed-off-by: Daniel Díaz 
>
Signed-off-by: Aníbal Limón 

> ---
>  meta/recipes-core/glibc/glibc-package.inc | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/glibc/glibc-package.inc
> b/meta/recipes-core/glibc/glibc-package.inc
> index ae3f2f6..a4f61f8 100644
> --- a/meta/recipes-core/glibc/glibc-package.inc
> +++ b/meta/recipes-core/glibc/glibc-package.inc
> @@ -136,8 +136,7 @@ do_install_append_armeb () {
>  }
>
>  do_install_armmultilib () {
> -
> -   oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h
> bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h
> +   oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h
> bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h
> oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h
> bits/pthreadtypes.h bits/pthreadtypes-arch.h  bits/sem.h  bits/semaphore.h
> bits/setjmp.h
> oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h
> bits/statfs.h bits/typesizes.h
>
> --
> 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] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs

On Thu, Jul 19, 2018 at 03:38:16PM +0200, Carlos Rafael Giani wrote:
> The main problem I see with all of this - aside from filling the recipes 
> with packageconfigs that may or may not become actually usable in the 
> future - is that when the packageconfig recipes don't yet exist, you are 
> essentially speculating. Even the *names* of the dependencies may turn 
> out to be different in the future (foo vs. libfoo for example). Or 
> perhaps you need to include more dependencies, like what can happen with 
> OpenGL ES (it also needs libEGL).
> 
> 
> On 2018-07-19 15:20, Martin Jansa wrote:
> > On Thu, Jul 19, 2018 at 02:47:58PM +0200, Carlos Rafael Giani wrote:
> >>
> >> On 2018-07-19 14:12, Martin Jansa wrote:
> >>> On Thu, Jul 19, 2018 at 01:16:51PM +0200, Carlos Rafael Giani wrote:
>  As a general rule, I think adding packageconfigs to an oe-core recipe
>  that has dependencies outside of oe-core and meta-openembedded is
>  questionable. Take the qt5 packageconfig for example. It is *not* part
>  of gstreamer1.0-plugins-good in oe-core, and for good reason - it needs
>  extra switches for passing paths to moc, uic etc.
> >>> I don't see what's questionable with that. PACKAGECONFIG is just a way
> >>> to pass configure options like EXTRA_OECONF just with benefit that it's
> >>> easily switched from outside and that it encapsulates build time and
> >>> runtime dependencies together with the options.
> >>>
>  Now, what if a recipe outside of oe-core and meta-openembedded is just
>  like that? It needs its own customizations, its own switches. It would
>  be better off setting up its own packageconfig, just like what that
>  bbappend in meta-qt5 does.
> >>> If someone submits PACKAGECONFIG addition for something which only
> >>> exists in his own layer, I'm fine with that, why should we make it
> >>> harder for people to use oe-core or meta-oe recipes?
> >> Adding a .bbappend that adds the packageconfig does not sound hard to
> >> me. However, having packageconfigs whose dependencies may or may not be
> >> dead (because of the layer being dead) sounds more like a maintenance
> >> problem.
> > It's not too hard, but completely unnecessary when the PACKAGECONFIG was
> > already there in oe-core and you're removing it for no good reason.
> > Especially if such PACKAGECONFIG needs to be added by multiple people in
> > multiple projects instead of just once in the recipe where it belongs.
> 
> libvisual is not in oe-core or meta-openembedded, otherwise I would have 
> added it. As for zlib etc. I already added them back in in v2 of the 
> patches.

But you're still _removing_ the PACKAGECONFIG for libvisual.

> > And it brings annoying issues like the gstreamer bbappend in meta-qt5
> > without any good reason.
> >
> > Carrying libdrm PACKAGECONFIGs in my bbappend was simple enough, but
> > then Ross migrated libdrm from autotools to meson and instead of simply
> > updating the PACKAGECONFIGs to the format used by meson atomically with
> > the meson migration in the same commit I had to update the .bbappend,
> > which caused my layer to require new oe-core again (to have the meson
> > migration, because the PACKAGECONFIG isn't backwards compatible) and at
> > that time I've rather submitted all my PACKAGECONFIGs to oe-core instead
> > of maintenance burden to keep them locally.
> 
> As said, I can then agree to add packageconfigs for recipes that already 
> exist somewhere. But adding them speculatively with not-yet-existing 

Except you can never know what exists elsewhere, because not all layers
are public or on layerindex.

> dependencies is an entirely different matter. I wouldn't do that. 
> Instead, I'd keep the --disable-twolame etc. switches around.
> 
> > Congrats! but it still doesn't mean we should add more of them without
> > good reasons, right?
> 
> Sure, but avoiding them is not a high priority for me. They are more of 
> an annoyance than an outright problem.
> 
> 
> > And what about people who have libvisual in their layer (from
> > meta-debian or meta-qt5-extra or written from scratch) are they also now
> > responsible for maintaining bbappend PACKAGECONFIG for gstreamer?
> 
> Yeah, at least initially. If some layer introduces a recipe that happens 
> to have a corresponding plugin in base/good/bad/ugly, it makes sense to 
> add a .bbappend at first. Later on, you can patch oe-core if it sounds 
> like having this packageconfig in a central place makes sense. To me, 
> this sounds like a more modular approach.
> 
> 
> >> Eh, I don't think I can agree with that approach. Having an openexr
> >> packageconfig for example implies that this packageconfig is actually
> >> usable and gstreamer1.0-plugins-bad can be built with it enabled. But
> >> adding it without an openexr dependency? Sounds broken to me. This is
> >> why I prefer to keep such features disabled until there is a recipe for
> >> them in meta-openembedded.
> > It's not broken, it just isn't well tes

[OE-core] [PATCH] musl: Fix dirent struct alignment issue seen on armv5te

Full logs
https://git.musl-libc.org/cgit/musl/log/?qt=range&q=9cad27a3dc1a4eb349b6591e4dc8cc89dce32277..18fbc7e4fa254696eb024f56ee74704805925fad

Signed-off-by: Khem Raj 
---
 meta/recipes-core/musl/musl_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/musl/musl_git.bb 
b/meta/recipes-core/musl/musl_git.bb
index b56870cb3f..9a3bbef68e 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -3,7 +3,7 @@
 
 require musl.inc
 
-SRCREV = "9cad27a3dc1a4eb349b6591e4dc8cc89dce32277"
+SRCREV = "18fbc7e4fa254696eb024f56ee74704805925fad"
 
 PV = "1.1.19+git${SRCPV}"
 
-- 
2.18.0

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

Re: [OE-core] [PATCH resend] wic: allow bitbake variables in kickstarter files

2018-07-19 Thread Sean Nyekjær





On 2018-07-17 10:14, Rasmus Villemoes wrote:

On 2018-07-03 14:54, Rasmus Villemoes wrote:

image_types_wic.bbclass has a mechanism for doing variable substitution
on .wks files by simply letting the input file be called
.wks.in. However, that doesn't allow using variables in files included
via the include directive. This is unfortunate, because lacking either
the ability to include other files or variable substitution leads to
fragile and error-prone duplication between kickstarter files and
recipes/configuration files used for various boards.

This adds (somewhat naive) support for variable substitution in all
files parsed by wic. The user should add all required variables to
WICVARS to get them exported appropriately.


ping^n


ping^5

Hi can you please take a look at this :-) Please...

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

[OE-core] [PATCH] lsb: fix usrmerge install path & QA warning

2018-07-19 Thread Ioan-Adrian Ratiu

${base_prefix} is set in bitbake.conf to empty. This makes lsb_release
always install under /bin which is a problem if usrmerge is in
DISTRO_FEATURES, because it needs to be installed under /usr/bin.

By using ${base_bindir} instead, we fix the usrmerge install path and
the following QA warning goes away.

WARNING: lsb-5.0-r0 do_package: QA Issue: lsb: Files/directories were
installed but not shipped in any package:
  /bin
  /bin/lsb_release
Please set FILES such that these items are packaged. Alternatively
if they are unneeded, avoid installing them or delete them within do_install.
lsb: 2 installed and not shipped files. [installed-vs-shipped]

Signed-off-by: Ioan-Adrian Ratiu 
---
 meta/recipes-extended/lsb/lsb_5.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/lsb/lsb_5.0.bb 
b/meta/recipes-extended/lsb/lsb_5.0.bb
index 746204b6ec..1657ba6f78 100644
--- a/meta/recipes-extended/lsb/lsb_5.0.bb
+++ b/meta/recipes-extended/lsb/lsb_5.0.bb
@@ -33,7 +33,7 @@ S = "${WORKDIR}/lsb-release-1.4"
 CLEANBROKEN = "1"
 
 do_install() {
-   oe_runmake install prefix=${D}${base_prefix} mandir=${D}${datadir}/man/ 
DESTDIR=${D}
+   oe_runmake install prefix=${D}${base_bindir} mandir=${D}${datadir}/man/ 
DESTDIR=${D}
 
# these two dirs are needed by package lsb-dist-checker
mkdir -p ${D}${sysconfdir}/opt
-- 
2.18.0

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

Re: [OE-core] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs

The main problem I see with all of this - aside from filling the recipes 
with packageconfigs that may or may not become actually usable in the 
future - is that when the packageconfig recipes don't yet exist, you are 
essentially speculating. Even the *names* of the dependencies may turn 
out to be different in the future (foo vs. libfoo for example). Or 
perhaps you need to include more dependencies, like what can happen with 
OpenGL ES (it also needs libEGL).



On 2018-07-19 15:20, Martin Jansa wrote:

On Thu, Jul 19, 2018 at 02:47:58PM +0200, Carlos Rafael Giani wrote:


On 2018-07-19 14:12, Martin Jansa wrote:

On Thu, Jul 19, 2018 at 01:16:51PM +0200, Carlos Rafael Giani wrote:

As a general rule, I think adding packageconfigs to an oe-core recipe
that has dependencies outside of oe-core and meta-openembedded is
questionable. Take the qt5 packageconfig for example. It is *not* part
of gstreamer1.0-plugins-good in oe-core, and for good reason - it needs
extra switches for passing paths to moc, uic etc.

I don't see what's questionable with that. PACKAGECONFIG is just a way
to pass configure options like EXTRA_OECONF just with benefit that it's
easily switched from outside and that it encapsulates build time and
runtime dependencies together with the options.


Now, what if a recipe outside of oe-core and meta-openembedded is just
like that? It needs its own customizations, its own switches. It would
be better off setting up its own packageconfig, just like what that
bbappend in meta-qt5 does.

If someone submits PACKAGECONFIG addition for something which only
exists in his own layer, I'm fine with that, why should we make it
harder for people to use oe-core or meta-oe recipes?

Adding a .bbappend that adds the packageconfig does not sound hard to
me. However, having packageconfigs whose dependencies may or may not be
dead (because of the layer being dead) sounds more like a maintenance
problem.

It's not too hard, but completely unnecessary when the PACKAGECONFIG was
already there in oe-core and you're removing it for no good reason.
Especially if such PACKAGECONFIG needs to be added by multiple people in
multiple projects instead of just once in the recipe where it belongs.


libvisual is not in oe-core or meta-openembedded, otherwise I would have 
added it. As for zlib etc. I already added them back in in v2 of the 
patches.



And it brings annoying issues like the gstreamer bbappend in meta-qt5
without any good reason.

Carrying libdrm PACKAGECONFIGs in my bbappend was simple enough, but
then Ross migrated libdrm from autotools to meson and instead of simply
updating the PACKAGECONFIGs to the format used by meson atomically with
the meson migration in the same commit I had to update the .bbappend,
which caused my layer to require new oe-core again (to have the meson
migration, because the PACKAGECONFIG isn't backwards compatible) and at
that time I've rather submitted all my PACKAGECONFIGs to oe-core instead
of maintenance burden to keep them locally.


As said, I can then agree to add packageconfigs for recipes that already 
exist somewhere. But adding them speculatively with not-yet-existing 
dependencies is an entirely different matter. I wouldn't do that. 
Instead, I'd keep the --disable-twolame etc. switches around.



Congrats! but it still doesn't mean we should add more of them without
good reasons, right?


Sure, but avoiding them is not a high priority for me. They are more of 
an annoyance than an outright problem.




And what about people who have libvisual in their layer (from
meta-debian or meta-qt5-extra or written from scratch) are they also now
responsible for maintaining bbappend PACKAGECONFIG for gstreamer?


Yeah, at least initially. If some layer introduces a recipe that happens 
to have a corresponding plugin in base/good/bad/ugly, it makes sense to 
add a .bbappend at first. Later on, you can patch oe-core if it sounds 
like having this packageconfig in a central place makes sense. To me, 
this sounds like a more modular approach.




Eh, I don't think I can agree with that approach. Having an openexr
packageconfig for example implies that this packageconfig is actually
usable and gstreamer1.0-plugins-bad can be built with it enabled. But
adding it without an openexr dependency? Sounds broken to me. This is
why I prefer to keep such features disabled until there is a recipe for
them in meta-openembedded.

It's not broken, it just isn't well tested. Everybody tests only the
explicitly disabled path until someone actually tries to enable it,
which is exactly the same for disabled PACKAGECONFIG and --disable-foo
in EXTRA_OECONF.

I'm not saying that these features should be enabled! Of course not,
they cannot be for features which require extra dependencies from other
layers. I'm just saying that --disable-twolame from
PACKAGECONFIG[twolame] is much better than --disable-twolame from
EXTRA_OECONF, because is easy to enable without the .bbappend and in
most cases it will work

Re: [OE-core] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs

On Thu, Jul 19, 2018 at 02:47:58PM +0200, Carlos Rafael Giani wrote:
> 
> 
> On 2018-07-19 14:12, Martin Jansa wrote:
> > On Thu, Jul 19, 2018 at 01:16:51PM +0200, Carlos Rafael Giani wrote:
> >> As a general rule, I think adding packageconfigs to an oe-core recipe
> >> that has dependencies outside of oe-core and meta-openembedded is
> >> questionable. Take the qt5 packageconfig for example. It is *not* part
> >> of gstreamer1.0-plugins-good in oe-core, and for good reason - it needs
> >> extra switches for passing paths to moc, uic etc.
> > I don't see what's questionable with that. PACKAGECONFIG is just a way
> > to pass configure options like EXTRA_OECONF just with benefit that it's
> > easily switched from outside and that it encapsulates build time and
> > runtime dependencies together with the options.
> >
> >> Now, what if a recipe outside of oe-core and meta-openembedded is just
> >> like that? It needs its own customizations, its own switches. It would
> >> be better off setting up its own packageconfig, just like what that
> >> bbappend in meta-qt5 does.
> > If someone submits PACKAGECONFIG addition for something which only
> > exists in his own layer, I'm fine with that, why should we make it
> > harder for people to use oe-core or meta-oe recipes?
> 
> Adding a .bbappend that adds the packageconfig does not sound hard to 
> me. However, having packageconfigs whose dependencies may or may not be 
> dead (because of the layer being dead) sounds more like a maintenance 
> problem.

It's not too hard, but completely unnecessary when the PACKAGECONFIG was
already there in oe-core and you're removing it for no good reason.
Especially if such PACKAGECONFIG needs to be added by multiple people in
multiple projects instead of just once in the recipe where it belongs.

And it brings annoying issues like the gstreamer bbappend in meta-qt5
without any good reason.

Carrying libdrm PACKAGECONFIGs in my bbappend was simple enough, but
then Ross migrated libdrm from autotools to meson and instead of simply
updating the PACKAGECONFIGs to the format used by meson atomically with
the meson migration in the same commit I had to update the .bbappend,
which caused my layer to require new oe-core again (to have the meson
migration, because the PACKAGECONFIG isn't backwards compatible) and at
that time I've rather submitted all my PACKAGECONFIGs to oe-core instead
of maintenance burden to keep them locally.

> > No I don't like that meta-qt5 has to use own bbappend for gstreamer,
> > it's necessary in this case because of the paths as you sad, but also
> > causes:
> > https://github.com/meta-qt5/meta-qt5/commit/73f99f2370a3dc5b81f42d0af7fe530431599454
> > which is quite annoying for meta-qt5 users, because this is one of very
> > few reasons why different meta-qt5 version isn't compatible with
> > different oe-core. So in order to use Qt 5.11 with oe-core from morty, I
> > need to BBMASK this bbappend and create the old one for
> > gstreamer1.0-plugins-bad in our project layer, it would be much nicer
> > and less error prone with PACKAGECONFIG directly in oe-core.
> 
> Agreed. This is a drawback. Unavoidable in this case, unfortunately.
> 
> > Also if you look at EXTRA_OECONF you'll see either --disable-qt twice or
> > --disable-qt followed by --enable-qt (when we depend on configure to let
> > the last option on command line win) which isn't ideal as well and might
> > confuse people looking at the log.do_configure.
> 
> Hmm perhaps a bit, but the order matters, so I know that the last one 
> "wins". Multiple switches like that are not uncommon in automated build 
> environments, so I am used to seeing these.

Congrats! but it still doesn't mean we should add more of them without
good reasons, right?
 
> >> I suppose with libvisual such a central packageconfig would work, but
> >> isn't the whole idea of oe-core to be lean? And yet, now we start adding
> >> more and more packageconfigs even though the recipes are in some other
> >> layers that are not part of the central ones (oe-core and
> >> meta-openembedded)?
> > Yes it's supposed to be lean as in number of recipes it needs to carry,
> > not lean by number of lines (PACKAGECONFIG is 1 line exactly as the
> > --diable flag in EXTRA_OECONF) or lean in number of ways how people are
> > able to use it.
> >
> > Why should meta-openembedded have special status for PACKAGECONFIGs
> > anyway, if you want to make it harder to customize the build, why stop
> > there?
> 
> meta-openembedded isn't tied to any particular platform, BSP, distro, 
> environment. It does have a special place, since it is a central layer 
> for many setups. How many BSP layers, distro layers etc. list both 
> oe-core and meta-openembedded as dependency, for example? meta-debian 
> and meta-qt5-extra however do not have nearly the same status (and these 
> are the places where libvisual is).

And what about people who have libvisual in their layer (from
meta-debian or meta-qt5-extra or written fr

Re: [OE-core] [PATCH 1/3] distutils/setuptools, distutils3/setuptools3: improve reproducibility

2018-07-19 Thread Burton, Ross

Hi Hongxu,

Can you rebase this to current master?

Cheers,
Ross

On 18 July 2018 at 01:57, Hongxu Jia  wrote:
> - Unify var-DISTUTILS_INSTALL_ARGS in distutils and setuptools
>
> - Supply "--root" directory to the "install" command, and use
>   it as a prefix to strip off the purported filename encoded
>   in bytecode files. (It strips build path prefix from .pyc files)
>
> [YOCTO #8446]
> [YOCTO #12084]
>
> Signed-off-by: Hongxu Jia 
> ---
>  meta/classes/distutils.bbclass   | 8 +---
>  meta/classes/distutils3.bbclass  | 8 +---
>  meta/classes/setuptools.bbclass  | 5 -
>  meta/classes/setuptools3.bbclass | 4 
>  4 files changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
> index 1930c35..db28767 100644
> --- a/meta/classes/distutils.bbclass
> +++ b/meta/classes/distutils.bbclass
> @@ -4,8 +4,10 @@ DISTUTILS_BUILD_ARGS ?= ""
>  DISTUTILS_STAGE_HEADERS_ARGS ?= 
> "--install-dir=${STAGING_INCDIR}/${PYTHON_DIR}"
>  DISTUTILS_STAGE_ALL_ARGS ?= "--prefix=${STAGING_DIR_HOST}${prefix} \
>  --install-data=${STAGING_DATADIR}"
> -DISTUTILS_INSTALL_ARGS ?= "--prefix=${D}/${prefix} \
> ---install-data=${D}/${datadir}"
> +DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
> +--prefix=${prefix} \
> +--install-lib=${PYTHON_SITEPACKAGES_DIR} \
> +--install-data=${datadir}"
>
>  distutils_do_compile() {
>   STAGING_INCDIR=${STAGING_INCDIR} \
> @@ -34,7 +36,7 @@ distutils_do_install() {
>  STAGING_INCDIR=${STAGING_INCDIR} \
>  STAGING_LIBDIR=${STAGING_LIBDIR} \
>  PYTHONPATH=${D}${PYTHON_SITEPACKAGES_DIR} \
> -${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
> install --install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} 
> ${DISTUTILS_INSTALL_ARGS} || \
> +${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
> install ${DISTUTILS_INSTALL_ARGS} || \
>  bbfatal_log "${PYTHON_PN} setup.py install execution failed."
>
>  # support filenames with *spaces*
> diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
> index d4b92a3..9637486 100644
> --- a/meta/classes/distutils3.bbclass
> +++ b/meta/classes/distutils3.bbclass
> @@ -5,8 +5,10 @@ DISTUTILS_BUILD_EXT_ARGS ?= ""
>  DISTUTILS_STAGE_HEADERS_ARGS ?= 
> "--install-dir=${STAGING_INCDIR}/${PYTHON_DIR}"
>  DISTUTILS_STAGE_ALL_ARGS ?= "--prefix=${STAGING_DIR_HOST}${prefix} \
>  --install-data=${STAGING_DATADIR}"
> -DISTUTILS_INSTALL_ARGS ?= "--prefix=${D}/${prefix} \
> ---install-data=${D}/${datadir}"
> +DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
> +--prefix=${prefix} \
> +--install-lib=${PYTHON_SITEPACKAGES_DIR} \
> +--install-data=${datadir}"
>
>  distutils3_do_configure() {
> if [ "${CLEANBROKEN}" != "1" ] ; then
> @@ -45,7 +47,7 @@ distutils3_do_install() {
>  STAGING_INCDIR=${STAGING_INCDIR} \
>  STAGING_LIBDIR=${STAGING_LIBDIR} \
>  PYTHONPATH=${D}${PYTHON_SITEPACKAGES_DIR} \
> -${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
> install --install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} 
> ${DISTUTILS_INSTALL_ARGS} || \
> +${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py 
> install ${DISTUTILS_INSTALL_ARGS} || \
>  bbfatal_log "${PYTHON_PN} setup.py install execution failed."
>
>  # support filenames with *spaces*
> diff --git a/meta/classes/setuptools.bbclass b/meta/classes/setuptools.bbclass
> index 157ef63..a923ea3 100644
> --- a/meta/classes/setuptools.bbclass
> +++ b/meta/classes/setuptools.bbclass
> @@ -1,8 +1,3 @@
>  inherit distutils
>
>  DEPENDS += "python-setuptools-native"
> -
> -DISTUTILS_INSTALL_ARGS = "--root=${D} \
> ---prefix=${prefix} \
> ---install-lib=${PYTHON_SITEPACKAGES_DIR} \
> ---install-data=${datadir}"
> diff --git a/meta/classes/setuptools3.bbclass 
> b/meta/classes/setuptools3.bbclass
> index de6dd94..8ca66ee 100644
> --- a/meta/classes/setuptools3.bbclass
> +++ b/meta/classes/setuptools3.bbclass
> @@ -2,7 +2,3 @@ inherit distutils3
>
>  DEPENDS += "python3-setuptools-native"
>
> -DISTUTILS_INSTALL_ARGS = "--root=${D} \
> ---prefix=${prefix} \
> ---install-lib=${PYTHON_SITEPACKAGES_DIR} \
> ---install-data=${datadir}"
> --
> 2.7.4
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wic: allow bitbake variables in kickstarter files

2018-07-19 Thread Tom Rini

On Thu, Mar 22, 2018 at 02:44:13PM +0100, Rasmus Villemoes wrote:

> image_types_wic.bbclass has a mechanism for doing variable substitution
> on .wks files by simply letting the input file be called
> .wks.in. However, that doesn't allow using variables in files included
> via the include directive.
> 
> This adds (somewhat naive) support for variable substitution in all
> files parsed by wic. The user should add all required variables to
> WICVARS to get them exported appropriately.
> 
> Signed-off-by: Rasmus Villemoes 

This seems quite useful and I like the idea.  I don't know the wic
internals well enough to "Reviewed-by" this myself, sorry.

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

Re: [OE-core] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs

On 2018-07-19 14:12, Martin Jansa wrote:

On Thu, Jul 19, 2018 at 01:16:51PM +0200, Carlos Rafael Giani wrote:

As a general rule, I think adding packageconfigs to an oe-core recipe
that has dependencies outside of oe-core and meta-openembedded is
questionable. Take the qt5 packageconfig for example. It is *not* part
of gstreamer1.0-plugins-good in oe-core, and for good reason - it needs
extra switches for passing paths to moc, uic etc.

I don't see what's questionable with that. PACKAGECONFIG is just a way
to pass configure options like EXTRA_OECONF just with benefit that it's
easily switched from outside and that it encapsulates build time and
runtime dependencies together with the options.

Now, what if a recipe outside of oe-core and meta-openembedded is just
like that? It needs its own customizations, its own switches. It would
be better off setting up its own packageconfig, just like what that
bbappend in meta-qt5 does.

If someone submits PACKAGECONFIG addition for something which only
exists in his own layer, I'm fine with that, why should we make it
harder for people to use oe-core or meta-oe recipes?

Adding a .bbappend that adds the packageconfig does not sound hard to
me. However, having packageconfigs whose dependencies may or may not be
dead (because of the layer being dead) sounds more like a maintenance
problem.

No I don't like that meta-qt5 has to use own bbappend for gstreamer,
it's necessary in this case because of the paths as you sad, but also
causes:
https://github.com/meta-qt5/meta-qt5/commit/73f99f2370a3dc5b81f42d0af7fe530431599454
which is quite annoying for meta-qt5 users, because this is one of very
few reasons why different meta-qt5 version isn't compatible with
different oe-core. So in order to use Qt 5.11 with oe-core from morty, I
need to BBMASK this bbappend and create the old one for
gstreamer1.0-plugins-bad in our project layer, it would be much nicer
and less error prone with PACKAGECONFIG directly in oe-core.

Agreed. This is a drawback. Unavoidable in this case, unfortunately.

Also if you look at EXTRA_OECONF you'll see either --disable-qt twice or
--disable-qt followed by --enable-qt (when we depend on configure to let
the last option on command line win) which isn't ideal as well and might
confuse people looking at the log.do_configure.

Hmm perhaps a bit, but the order matters, so I know that the last one
"wins". Multiple switches like that are not uncommon in automated build
environments, so I am used to seeing these.

I suppose with libvisual such a central packageconfig would work, but
isn't the whole idea of oe-core to be lean? And yet, now we start adding
more and more packageconfigs even though the recipes are in some other
layers that are not part of the central ones (oe-core and
meta-openembedded)?

Yes it's supposed to be lean as in number of recipes it needs to carry,
not lean by number of lines (PACKAGECONFIG is 1 line exactly as the
--diable flag in EXTRA_OECONF) or lean in number of ways how people are
able to use it.

Why should meta-openembedded have special status for PACKAGECONFIGs
anyway, if you want to make it harder to customize the build, why stop
there?

meta-openembedded isn't tied to any particular platform, BSP, distro,
environment. It does have a special place, since it is a central layer
for many setups. How many BSP layers, distro layers etc. list both
oe-core and meta-openembedded as dependency, for example? meta-debian
and meta-qt5-extra however do not have nearly the same status (and these
are the places where libvisual is).

You might as well add dozens of packageconfigs to
gstreamer1.0-plugins-bad, just in case some obscure layer adds a recipe
for OpenEXR or spandsp for example.

Yes, that's exactly what I often do, last time e.g. with libdrm
http://git.openembedded.org/openembedded-core/commit/?id=dc7d3b2ff79ae324b96a51ec1be557a432ed351d
and e.g. qemu before that, adding PACKAGECONFIG for dependencies which
I haven't submitted to meta-networking yet at that time:
http://git.openembedded.org/openembedded-core/commit/?id=ebb6ef1dbc7e03a4b7030b3056bd0fa59fdd047b
and I haven't submitted the recipe for virglrenderer yet as well and
I don't see any issue with having the PACKAGECONFIG for it already.

Eh, I don't think I can agree with that approach. Having an openexr
packageconfig for example implies that this packageconfig is actually
usable and gstreamer1.0-plugins-bad can be built with it enabled. But
adding it without an openexr dependency? Sounds broken to me. This is
why I prefer to keep such features disabled until there is a recipe for
them in meta-openembedded.

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

Re: [OE-core] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs

On Thu, Jul 19, 2018 at 01:16:51PM +0200, Carlos Rafael Giani wrote:
> As a general rule, I think adding packageconfigs to an oe-core recipe 
> that has dependencies outside of oe-core and meta-openembedded is 
> questionable. Take the qt5 packageconfig for example. It is *not* part 
> of gstreamer1.0-plugins-good in oe-core, and for good reason - it needs 
> extra switches for passing paths to moc, uic etc.

I don't see what's questionable with that. PACKAGECONFIG is just a way
to pass configure options like EXTRA_OECONF just with benefit that it's
easily switched from outside and that it encapsulates build time and
runtime dependencies together with the options.

> Now, what if a recipe outside of oe-core and meta-openembedded is just 
> like that? It needs its own customizations, its own switches. It would 
> be better off setting up its own packageconfig, just like what that 
> bbappend in meta-qt5 does.

If someone submits PACKAGECONFIG addition for something which only
exists in his own layer, I'm fine with that, why should we make it
harder for people to use oe-core or meta-oe recipes?

No I don't like that meta-qt5 has to use own bbappend for gstreamer,
it's necessary in this case because of the paths as you sad, but also
causes:
https://github.com/meta-qt5/meta-qt5/commit/73f99f2370a3dc5b81f42d0af7fe530431599454
which is quite annoying for meta-qt5 users, because this is one of very
few reasons why different meta-qt5 version isn't compatible with
different oe-core. So in order to use Qt 5.11 with oe-core from morty, I
need to BBMASK this bbappend and create the old one for
gstreamer1.0-plugins-bad in our project layer, it would be much nicer
and less error prone with PACKAGECONFIG directly in oe-core.

Also if you look at EXTRA_OECONF you'll see either --disable-qt twice or
--disable-qt followed by --enable-qt (when we depend on configure to let
the last option on command line win) which isn't ideal as well and might
confuse people looking at the log.do_configure.

> I suppose with libvisual such a central packageconfig would work, but 
> isn't the whole idea of oe-core to be lean? And yet, now we start adding 
> more and more packageconfigs even though the recipes are in some other 
> layers that are not part of the central ones (oe-core and 
> meta-openembedded)?

Yes it's supposed to be lean as in number of recipes it needs to carry,
not lean by number of lines (PACKAGECONFIG is 1 line exactly as the
--diable flag in EXTRA_OECONF) or lean in number of ways how people are
able to use it.

Why should meta-openembedded have special status for PACKAGECONFIGs
anyway, if you want to make it harder to customize the build, why stop
there?

> You might as well add dozens of packageconfigs to 
> gstreamer1.0-plugins-bad, just in case some obscure layer adds a recipe 
> for OpenEXR or spandsp for example.

Yes, that's exactly what I often do, last time e.g. with libdrm
http://git.openembedded.org/openembedded-core/commit/?id=dc7d3b2ff79ae324b96a51ec1be557a432ed351d
and e.g. qemu before that, adding PACKAGECONFIG for dependencies which
I haven't submitted to meta-networking yet at that time:
http://git.openembedded.org/openembedded-core/commit/?id=ebb6ef1dbc7e03a4b7030b3056bd0fa59fdd047b
and I haven't submitted the recipe for virglrenderer yet as well and
I don't see any issue with having the PACKAGECONFIG for it already.

Cheers,

> On 2018-07-19 13:07, Martin Jansa wrote:
> > On Thu, Jul 19, 2018 at 12:07:09PM +0200, Carlos Rafael Giani wrote:
> >> * Add patches for gbm, libpng, libjpeg to conditionally enable/disable
> >>them in the configure script
> >> * There is no libvisual recipe in oe-core or in meta-openembedded, so
> >>the visual packageconfig needs to go
> > No, it doesn't need to go and shouldn't.
> >
> > Why are you trying to force people who already have libvisual recipe
> > (maybe from one of these 2
> > layers: 
> > http://layers.openembedded.org/layerindex/branch/master/recipes/?q=libvisual
> >  )
> > to create gstreamer1.0-plugins-base bbappend just to return the
> > PACKAGECONFIG and remove the --disable-libvisual from EXTRA_OECONF?
> > It doesn't make any sense. Extra PACKAGECONFIGs for stuff you might not
> > use doesn't cause any extra overhead, yes they are less tested than the
> > stuff which people usually have enabled/disabled, but still having the
> > PACKAGECONFIG available makes it much easier for project layers to
> > correctly configure recipes in upstream layers.
> >
> >> * Reorder the packageconfigs alphabetically
> >>
> >> Signed-off-by: Carlos Rafael Giani 
> >> ---
> >>   ...r-explicitely-enabling-disabling-GBM.patch |  70 
> >>   ...for-explicitely-enabling-disabling-P.patch | 107 ++
> >>   .../gstreamer1.0-plugins-base_1.14.1.bb   |  29 +++--
> >>   3 files changed, 196 insertions(+), 10 deletions(-)
> >>   create mode 100644 
> >> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-ena

[OE-core] [PATCH v2] busybox: update to 1.29.1

2018-07-19 Thread Andrej Valek

  - refresh busybox-udhcpc-no_deconfig.patch
  - remove obsolete patches which are included in this update
  - update defconfig

Signed-off-by: Andrej Valek 
---
 ...inittab_1.27.2.bb => busybox-inittab_1.29.1.bb} |   0
 .../busybox/busybox/CVE-2011-5325.patch| 481 -
 .../busybox/busybox/CVE-2017-15873.patch   |  95 
 .../busybox/busybox/busybox-CVE-2017-16544.patch   |  43 --
 .../busybox/busybox-fix-lzma-segfaults.patch   | 106 -
 .../busybox/busybox-udhcpc-no_deconfig.patch   |  48 +-
 meta/recipes-core/busybox/busybox/defconfig|  46 +-
 .../busybox/busybox/umount-ignore-c.patch  |  40 --
 .../{busybox_1.27.2.bb => busybox_1.29.1.bb}   |   9 +-
 9 files changed, 66 insertions(+), 802 deletions(-)
 rename meta/recipes-core/busybox/{busybox-inittab_1.27.2.bb => 
busybox-inittab_1.29.1.bb} (100%)
 delete mode 100755 meta/recipes-core/busybox/busybox/CVE-2011-5325.patch
 delete mode 100644 meta/recipes-core/busybox/busybox/CVE-2017-15873.patch
 delete mode 100644 
meta/recipes-core/busybox/busybox/busybox-CVE-2017-16544.patch
 delete mode 100644 
meta/recipes-core/busybox/busybox/busybox-fix-lzma-segfaults.patch
 delete mode 100644 meta/recipes-core/busybox/busybox/umount-ignore-c.patch
 rename meta/recipes-core/busybox/{busybox_1.27.2.bb => busybox_1.29.1.bb} (82%)

diff --git a/meta/recipes-core/busybox/busybox-inittab_1.27.2.bb 
b/meta/recipes-core/busybox/busybox-inittab_1.29.1.bb
similarity index 100%
rename from meta/recipes-core/busybox/busybox-inittab_1.27.2.bb
rename to meta/recipes-core/busybox/busybox-inittab_1.29.1.bb
diff --git a/meta/recipes-core/busybox/busybox/CVE-2011-5325.patch 
b/meta/recipes-core/busybox/busybox/CVE-2011-5325.patch
deleted file mode 100755
index 0926107bea..00
--- a/meta/recipes-core/busybox/busybox/CVE-2011-5325.patch
+++ /dev/null
@@ -1,481 +0,0 @@
-busybox-1.27.2: Fix CVE-2011-5325
-
-[No upstream tracking] -- https://bugs.busybox.net/show_bug.cgi?id=8411
-
-libarchive: do not extract unsafe symlinks
-
-Prevent unsafe links extracting unless env variable $EXTRACT_UNSAFE_SYMLINKS=1
-is not set. Untarring file with -C DESTDIR parameter could be extracted with
-unwanted symlinks. This doesn't feel right, and IIRC GNU tar doesn't do that.
-Include necessary changes from previous commits.
-
-Upstream-Status: Backport 
[https://git.busybox.net/busybox/commit/?id=bc9bbeb2b81001e8731cd2ae501c8fccc8d87cc7]
-CVE: CVE-2011-5325
-bug: 8411
-Signed-off-by: Radovan Scasny 
-Signed-off-by: Andrej Valek 
-
-diff --git a/archival/libarchive/Kbuild.src b/archival/libarchive/Kbuild.src
-index 942e755..e1a8a75 100644
 a/archival/libarchive/Kbuild.src
-+++ b/archival/libarchive/Kbuild.src
-@@ -12,6 +12,8 @@ COMMON_FILES:= \
-   data_extract_all.o \
-   data_extract_to_stdout.o \
- \
-+  unsafe_symlink_target.o \
-+\
-   filter_accept_all.o \
-   filter_accept_list.o \
-   filter_accept_reject_list.o \
-diff --git a/archival/libarchive/data_extract_all.c 
b/archival/libarchive/data_extract_all.c
-index 1830ffb..b828b65 100644
 a/archival/libarchive/data_extract_all.c
-+++ b/archival/libarchive/data_extract_all.c
-@@ -128,10 +128,9 @@ void FAST_FUNC data_extract_all(archive_handle_t 
*archive_handle)
-   res = link(hard_link, dst_name);
-   if (res != 0 && !(archive_handle->ah_flags & 
ARCHIVE_EXTRACT_QUIET)) {
-   /* shared message */
--  bb_perror_msg("can't create %slink "
--  "%s to %s", "hard",
--  dst_name,
--  hard_link);
-+  bb_perror_msg("can't create %slink '%s' to '%s'",
-+   "hard", dst_name, hard_link
-+  );
-   }
-   /* Hardlinks have no separate mode/ownership, skip chown/chmod 
*/
-   goto ret;
-@@ -178,15 +177,17 @@ void FAST_FUNC data_extract_all(archive_handle_t 
*archive_handle)
-   case S_IFLNK:
-   /* Symlink */
- //TODO: what if file_header->link_target == NULL (say, corrupted tarball?)
--  res = symlink(file_header->link_target, dst_name);
--  if (res != 0
--   && !(archive_handle->ah_flags & ARCHIVE_EXTRACT_QUIET)
--  ) {
--  /* shared message */
--  bb_perror_msg("can't create %slink "
--  "%s to %s", "sym",
--  dst_name,
--  file_header->link_target);
-+  if (!unsafe_symlink_target(file_header->link_target)) {
-+  res = symlink(file_header->link_target, dst_name);
-+  if (res != 0
-+  && !(archive_handle->ah_flags & 
ARCHIVE_EXTRACT_QUIET)
-+  ) {
-+

Re: [OE-core] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs

As a general rule, I think adding packageconfigs to an oe-core recipe 
that has dependencies outside of oe-core and meta-openembedded is 
questionable. Take the qt5 packageconfig for example. It is *not* part 
of gstreamer1.0-plugins-good in oe-core, and for good reason - it needs 
extra switches for passing paths to moc, uic etc.


Now, what if a recipe outside of oe-core and meta-openembedded is just 
like that? It needs its own customizations, its own switches. It would 
be better off setting up its own packageconfig, just like what that 
bbappend in meta-qt5 does.


I suppose with libvisual such a central packageconfig would work, but 
isn't the whole idea of oe-core to be lean? And yet, now we start adding 
more and more packageconfigs even though the recipes are in some other 
layers that are not part of the central ones (oe-core and 
meta-openembedded)?


You might as well add dozens of packageconfigs to 
gstreamer1.0-plugins-bad, just in case some obscure layer adds a recipe 
for OpenEXR or spandsp for example.



On 2018-07-19 13:07, Martin Jansa wrote:

On Thu, Jul 19, 2018 at 12:07:09PM +0200, Carlos Rafael Giani wrote:

* Add patches for gbm, libpng, libjpeg to conditionally enable/disable
   them in the configure script
* There is no libvisual recipe in oe-core or in meta-openembedded, so
   the visual packageconfig needs to go

No, it doesn't need to go and shouldn't.

Why are you trying to force people who already have libvisual recipe
(maybe from one of these 2
layers: 
http://layers.openembedded.org/layerindex/branch/master/recipes/?q=libvisual )
to create gstreamer1.0-plugins-base bbappend just to return the
PACKAGECONFIG and remove the --disable-libvisual from EXTRA_OECONF?
It doesn't make any sense. Extra PACKAGECONFIGs for stuff you might not
use doesn't cause any extra overhead, yes they are less tested than the
stuff which people usually have enabled/disabled, but still having the
PACKAGECONFIG available makes it much easier for project layers to
correctly configure recipes in upstream layers.


* Reorder the packageconfigs alphabetically

Signed-off-by: Carlos Rafael Giani 
---
  ...r-explicitely-enabling-disabling-GBM.patch |  70 
  ...for-explicitely-enabling-disabling-P.patch | 107 ++
  .../gstreamer1.0-plugins-base_1.14.1.bb   |  29 +++--
  3 files changed, 196 insertions(+), 10 deletions(-)
  create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
  create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
new file mode 100644
index 00..79e0b78aaf
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
@@ -0,0 +1,70 @@
+From 7f93afc497010384da9f9d15163c31a862bd1dfa Mon Sep 17 00:00:00 2001
+From: Carlos Rafael Giani 
+Date: Thu, 19 Jul 2018 10:30:54 +0200
+Subject: [PATCH 10/11] gl: Add switch for explicitely enabling/disabling GBM
+ support
+
+https://bugzilla.gnome.org/show_bug.cgi?id=796833
+---
+ m4/gst-gl.m4 | 38 +-
+ 1 file changed, 29 insertions(+), 9 deletions(-)
+
+diff --git a/m4/gst-gl.m4 b/m4/gst-gl.m4
+index 1e9724094..20b2233de 100644
+--- a/m4/gst-gl.m4
 b/m4/gst-gl.m4
+@@ -117,6 +117,15 @@ AC_ARG_ENABLE([dispmanx],
+*) AC_MSG_ERROR([bad value ${enableval} for --enable-dispmanx]) ;;
+  esac],[NEED_DISPMANX=auto])
+
++AC_ARG_ENABLE([gbm],
++ [  --enable-gbmEnable Mesa3D GBM support (requires EGL) 
@<:@default=auto@:>@],
++ [case "${enableval}" in
++   yes)  NEED_GBM=yes ;;
++   no)   NEED_GBM=no ;;
++   auto) NEED_GBM=auto ;;
++   *) AC_MSG_ERROR([bad value ${enableval} for --enable-gbm]) ;;
++ esac],[NEED_GBM=auto])
++
+ AG_GST_PKG_CHECK_MODULES(X11_XCB, x11-xcb)
+ save_CPPFLAGS="$CPPFLAGS"
+ save_LIBS="$LIBS"
+@@ -172,15 +181,26 @@ case $host in
+ AC_CHECK_LIB([EGL], [fbGetDisplay], [HAVE_VIV_FB_EGL=yes])
+ fi
+
+-if test "x$HAVE_EGL" = "xyes"; then
+-PKG_CHECK_MODULES(DRM, libdrm >= 2.4.55, HAVE_DRM=yes, HAVE_DRM=no)
+-AC_SUBST(DRM_CFLAGS)
+-AC_SUBST(DRM_LIBS)
+-if test "x$HAVE_DRM" = "xyes" -a "x$HAVE_GUDEV" = "xyes"; then
+-  PKG_CHECK_MODULES(GBM, gbm, HAVE_GBM_EGL=yes, HAVE_GBM_EGL=no)
+-  AC_SUBST(GBM_CFLAGS)
+-  AC_SUBST(GBM_LIBS)
+-   fi
++if test "x$HAVE_EGL" = "xyes" -a "x$NEED_GBM" != "xno"; then
++  PKG_CHECK_MODULES(DRM, libdrm >= 2.4.55, HAVE_DRM=yes, HAVE_DRM=no)
++  AC_SUBST(DRM_CFLAGS)
++  AC_SUBST(DRM_LIBS)
+

Re: [OE-core] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs

On Thu, Jul 19, 2018 at 12:07:09PM +0200, Carlos Rafael Giani wrote:
> * Add patches for gbm, libpng, libjpeg to conditionally enable/disable
>   them in the configure script
> * There is no libvisual recipe in oe-core or in meta-openembedded, so
>   the visual packageconfig needs to go

No, it doesn't need to go and shouldn't.

Why are you trying to force people who already have libvisual recipe
(maybe from one of these 2
layers: 
http://layers.openembedded.org/layerindex/branch/master/recipes/?q=libvisual )
to create gstreamer1.0-plugins-base bbappend just to return the
PACKAGECONFIG and remove the --disable-libvisual from EXTRA_OECONF?
It doesn't make any sense. Extra PACKAGECONFIGs for stuff you might not
use doesn't cause any extra overhead, yes they are less tested than the
stuff which people usually have enabled/disabled, but still having the
PACKAGECONFIG available makes it much easier for project layers to
correctly configure recipes in upstream layers.

> * Reorder the packageconfigs alphabetically
> 
> Signed-off-by: Carlos Rafael Giani 
> ---
>  ...r-explicitely-enabling-disabling-GBM.patch |  70 
>  ...for-explicitely-enabling-disabling-P.patch | 107 ++
>  .../gstreamer1.0-plugins-base_1.14.1.bb   |  29 +++--
>  3 files changed, 196 insertions(+), 10 deletions(-)
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch
> 
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
>  
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
> new file mode 100644
> index 00..79e0b78aaf
> --- /dev/null
> +++ 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
> @@ -0,0 +1,70 @@
> +From 7f93afc497010384da9f9d15163c31a862bd1dfa Mon Sep 17 00:00:00 2001
> +From: Carlos Rafael Giani 
> +Date: Thu, 19 Jul 2018 10:30:54 +0200
> +Subject: [PATCH 10/11] gl: Add switch for explicitely enabling/disabling GBM
> + support
> +
> +https://bugzilla.gnome.org/show_bug.cgi?id=796833
> +---
> + m4/gst-gl.m4 | 38 +-
> + 1 file changed, 29 insertions(+), 9 deletions(-)
> +
> +diff --git a/m4/gst-gl.m4 b/m4/gst-gl.m4
> +index 1e9724094..20b2233de 100644
> +--- a/m4/gst-gl.m4
>  b/m4/gst-gl.m4
> +@@ -117,6 +117,15 @@ AC_ARG_ENABLE([dispmanx],
> +*) AC_MSG_ERROR([bad value ${enableval} for --enable-dispmanx]) ;;
> +  esac],[NEED_DISPMANX=auto])
> + 
> ++AC_ARG_ENABLE([gbm],
> ++ [  --enable-gbmEnable Mesa3D GBM support (requires EGL) 
> @<:@default=auto@:>@],
> ++ [case "${enableval}" in
> ++   yes)  NEED_GBM=yes ;;
> ++   no)   NEED_GBM=no ;;
> ++   auto) NEED_GBM=auto ;;
> ++   *) AC_MSG_ERROR([bad value ${enableval} for --enable-gbm]) ;;
> ++ esac],[NEED_GBM=auto])
> ++
> + AG_GST_PKG_CHECK_MODULES(X11_XCB, x11-xcb)
> + save_CPPFLAGS="$CPPFLAGS"
> + save_LIBS="$LIBS"
> +@@ -172,15 +181,26 @@ case $host in
> + AC_CHECK_LIB([EGL], [fbGetDisplay], [HAVE_VIV_FB_EGL=yes])
> + fi
> + 
> +-if test "x$HAVE_EGL" = "xyes"; then
> +-PKG_CHECK_MODULES(DRM, libdrm >= 2.4.55, HAVE_DRM=yes, HAVE_DRM=no)
> +-AC_SUBST(DRM_CFLAGS)
> +-AC_SUBST(DRM_LIBS)
> +-if test "x$HAVE_DRM" = "xyes" -a "x$HAVE_GUDEV" = "xyes"; then
> +-  PKG_CHECK_MODULES(GBM, gbm, HAVE_GBM_EGL=yes, HAVE_GBM_EGL=no)
> +-  AC_SUBST(GBM_CFLAGS)
> +-  AC_SUBST(GBM_LIBS)
> +-   fi
> ++if test "x$HAVE_EGL" = "xyes" -a "x$NEED_GBM" != "xno"; then
> ++  PKG_CHECK_MODULES(DRM, libdrm >= 2.4.55, HAVE_DRM=yes, HAVE_DRM=no)
> ++  AC_SUBST(DRM_CFLAGS)
> ++  AC_SUBST(DRM_LIBS)
> ++  if test "x$NEED_GBM" = "xyes"; then
> ++if test "x$HAVE_DRM" = "xno"; then
> ++  AC_MSG_ERROR([GBM support requested but libdrm is not available])
> ++fi
> ++if test "x$HAVE_GUDEV" = "xno"; then
> ++  AC_MSG_ERROR([GBM support requested but gudev is not available])
> ++fi
> ++  fi
> ++  if test "x$HAVE_DRM" = "xyes" -a "x$HAVE_GUDEV" = "xyes"; then
> ++PKG_CHECK_MODULES(GBM, gbm, HAVE_GBM_EGL=yes, HAVE_GBM_EGL=no)
> ++if test "x$HAVE_GBM_EGL" = "xno" -a "x$NEED_GBM" = "xyes"; then
> ++  AC_MSG_ERROR([GBM support requested but gbm library is not 
> available])
> ++fi
> ++AC_SUBST(GBM_CFLAGS)
> ++AC_SUBST(GBM_LIBS)
> ++  fi
> + fi
> + 
> + dnl FIXME: Mali EGL depends on GLESv1 or GLESv2
> +-- 
> +2.17.1
> +
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switch

[OE-core] ✗ patchtest: failure for "[v2] gstreamer1.0-plugin-base:..." and 5 more

2018-07-19 Thread Patchwork

== Series Details ==

Series: "[v2] gstreamer1.0-plugin-base:..." and 5 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/13098/
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 ff0b682b80)

* Patch[v2,3/6] gstreamer1.0-plugin-bad: Update packageconfigs
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")

* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch)

* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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 v2 6/6] gstreamer1.0-libav: Replace German umlaut to avoid parsing problems

The umlaut can cause issues related to encoding; avoid by replacing it

Signed-off-by: Carlos Rafael Giani 
---
 .../workaround-to-build-gst-libav-for-i586-with-gcc.patch   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
index 36abf8607e..5355480aa4 100644
--- 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
@@ -1,5 +1,5 @@
 Description: Workaround to build libav for i586 with gcc 4.9.2 by avoiding 
memset
-Author: Bernhard Übelacker 
+Author: Bernhard Uebelacker 
 
 ---
 Bug-Debian: https://bugs.debian.org/783082
-- 
2.17.1

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

[OE-core] [PATCH v2 5/6] gstreamer1.0-vaapi: Add patch for EGL CFLAGS for proper EGL support

Signed-off-by: Carlos Rafael Giani 
---
 ...le.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch | 33 +++
 .../gstreamer/gstreamer1.0-vaapi_1.14.1.bb|  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch
new file mode 100644
index 00..d7b8984953
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch
@@ -0,0 +1,33 @@
+From 5403a89e6a7ac72a23e0221075c0c19b5f85a021 Mon Sep 17 00:00:00 2001
+From: Fabio Berton 
+Date: Wed, 13 Jun 2018 09:09:25 -0300
+Subject: [PATCH] gst/vaapi/Makefile.am: Add EGL_CFLAGS to libgstvaapi CFLAGS
+Organization: O.S. Systems Software LTDA.
+
+We need this to pass correctly EGL CFLAGS when building with EGL support.
+
+Upstream-Status: Pending
+
+Signed-off-by: Fabio Berton 
+---
+ gst/vaapi/Makefile.am | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/gst/vaapi/Makefile.am b/gst/vaapi/Makefile.am
+index b299ac98..d6cab71f 100644
+--- a/gst/vaapi/Makefile.am
 b/gst/vaapi/Makefile.am
+@@ -24,6 +24,10 @@ libgstvaapi_LIBS += 
$(top_builddir)/gst-libs/gst/vaapi/libgstvaapi-glx.la
+ endif
+ 
+ if USE_EGL
++libgstvaapi_CFLAGS += \
++  $(EGL_CFLAGS)   \
++  $(NULL)
++
+ libgstvaapi_LIBS += $(top_builddir)/gst-libs/gst/vaapi/libgstvaapi-egl.la
+ endif
+ 
+-- 
+2.17.1
+
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
index e647458fab..63290326a5 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
@@ -9,6 +9,7 @@ LICENSE = "LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"
 
 SRC_URI = 
"https://gstreamer.freedesktop.org/src/${REALPN}/${REALPN}-${PV}.tar.xz \
+   
file://0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch \
   "
 
 SRC_URI[md5sum] = "38c5b2390797b7a0a269a5ab6c8cbe8f"
-- 
2.17.1

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

[OE-core] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs

* Add patches for gbm, libpng, libjpeg to conditionally enable/disable
  them in the configure script
* There is no libvisual recipe in oe-core or in meta-openembedded, so
  the visual packageconfig needs to go
* Reorder the packageconfigs alphabetically

Signed-off-by: Carlos Rafael Giani 
---
 ...r-explicitely-enabling-disabling-GBM.patch |  70 
 ...for-explicitely-enabling-disabling-P.patch | 107 ++
 .../gstreamer1.0-plugins-base_1.14.1.bb   |  29 +++--
 3 files changed, 196 insertions(+), 10 deletions(-)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
new file mode 100644
index 00..79e0b78aaf
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
@@ -0,0 +1,70 @@
+From 7f93afc497010384da9f9d15163c31a862bd1dfa Mon Sep 17 00:00:00 2001
+From: Carlos Rafael Giani 
+Date: Thu, 19 Jul 2018 10:30:54 +0200
+Subject: [PATCH 10/11] gl: Add switch for explicitely enabling/disabling GBM
+ support
+
+https://bugzilla.gnome.org/show_bug.cgi?id=796833
+---
+ m4/gst-gl.m4 | 38 +-
+ 1 file changed, 29 insertions(+), 9 deletions(-)
+
+diff --git a/m4/gst-gl.m4 b/m4/gst-gl.m4
+index 1e9724094..20b2233de 100644
+--- a/m4/gst-gl.m4
 b/m4/gst-gl.m4
+@@ -117,6 +117,15 @@ AC_ARG_ENABLE([dispmanx],
+*) AC_MSG_ERROR([bad value ${enableval} for --enable-dispmanx]) ;;
+  esac],[NEED_DISPMANX=auto])
+ 
++AC_ARG_ENABLE([gbm],
++ [  --enable-gbmEnable Mesa3D GBM support (requires EGL) 
@<:@default=auto@:>@],
++ [case "${enableval}" in
++   yes)  NEED_GBM=yes ;;
++   no)   NEED_GBM=no ;;
++   auto) NEED_GBM=auto ;;
++   *) AC_MSG_ERROR([bad value ${enableval} for --enable-gbm]) ;;
++ esac],[NEED_GBM=auto])
++
+ AG_GST_PKG_CHECK_MODULES(X11_XCB, x11-xcb)
+ save_CPPFLAGS="$CPPFLAGS"
+ save_LIBS="$LIBS"
+@@ -172,15 +181,26 @@ case $host in
+ AC_CHECK_LIB([EGL], [fbGetDisplay], [HAVE_VIV_FB_EGL=yes])
+ fi
+ 
+-if test "x$HAVE_EGL" = "xyes"; then
+-PKG_CHECK_MODULES(DRM, libdrm >= 2.4.55, HAVE_DRM=yes, HAVE_DRM=no)
+-AC_SUBST(DRM_CFLAGS)
+-AC_SUBST(DRM_LIBS)
+-if test "x$HAVE_DRM" = "xyes" -a "x$HAVE_GUDEV" = "xyes"; then
+-  PKG_CHECK_MODULES(GBM, gbm, HAVE_GBM_EGL=yes, HAVE_GBM_EGL=no)
+-  AC_SUBST(GBM_CFLAGS)
+-  AC_SUBST(GBM_LIBS)
+-   fi
++if test "x$HAVE_EGL" = "xyes" -a "x$NEED_GBM" != "xno"; then
++  PKG_CHECK_MODULES(DRM, libdrm >= 2.4.55, HAVE_DRM=yes, HAVE_DRM=no)
++  AC_SUBST(DRM_CFLAGS)
++  AC_SUBST(DRM_LIBS)
++  if test "x$NEED_GBM" = "xyes"; then
++if test "x$HAVE_DRM" = "xno"; then
++  AC_MSG_ERROR([GBM support requested but libdrm is not available])
++fi
++if test "x$HAVE_GUDEV" = "xno"; then
++  AC_MSG_ERROR([GBM support requested but gudev is not available])
++fi
++  fi
++  if test "x$HAVE_DRM" = "xyes" -a "x$HAVE_GUDEV" = "xyes"; then
++PKG_CHECK_MODULES(GBM, gbm, HAVE_GBM_EGL=yes, HAVE_GBM_EGL=no)
++if test "x$HAVE_GBM_EGL" = "xno" -a "x$NEED_GBM" = "xyes"; then
++  AC_MSG_ERROR([GBM support requested but gbm library is not 
available])
++fi
++AC_SUBST(GBM_CFLAGS)
++AC_SUBST(GBM_LIBS)
++  fi
+ fi
+ 
+ dnl FIXME: Mali EGL depends on GLESv1 or GLESv2
+-- 
+2.17.1
+
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch
new file mode 100644
index 00..3e22332dab
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch
@@ -0,0 +1,107 @@
+From 092aadfc1df69c46d920b0cd39f98d363d6988b3 Mon Sep 17 00:00:00 2001
+From: Carlos Rafael Giani 
+Date: Thu, 19 Jul 2018 11:16:05 +0200
+Subject: [PATCH 11/11] gl: Add switches for explicitely enabling/disabling PNG
+ and JPEG support
+
+https://bugzilla.gnome.org/show_bug.cgi?id=796833
+---
+ m4/gst-gl.m4 | 66 
+ 1 file changed, 46 insertions(+), 20 deletions(-)
+
+diff --git a/m4/gst-gl.m4 b/m4/gst-gl.m4
+index 20b2233de..f8809981c 100644
+--- a/m4/gst-gl.m4
 b/m4/gst-gl.m4
+@@ -126,6 +126,24 @@ AC_ARG_ENABL

Re: [OE-core] [sumo][PATCH] glibc: fix CVE-2018-11237

2018-07-19 Thread Zheng, Ruoqin

Ping

--
Zheng Ruoqin
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
   Nanjing, 210012, China
MAIL : zhengrq.f...@cn.fujistu.com


-Original Message-
From: Zheng, Ruoqin/郑 若钦 
Sent: Tuesday, June 26, 2018 2:05 PM
To: openembedded-core@lists.openembedded.org
Cc: Zheng, Ruoqin/郑 若钦 
Subject: [OE-core][sumo][PATCH] glibc: fix CVE-2018-11237

glibc: fix CVE-2018-11237

Signed-off-by: Zheng Ruoqin 
---
 meta/recipes-core/glibc/glibc/CVE-2018-11237.patch | 83 ++
 meta/recipes-core/glibc/glibc_2.27.bb  |  1 +
 2 files changed, 84 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2018-11237.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2018-11237.patch 
b/meta/recipes-core/glibc/glibc/CVE-2018-11237.patch
new file mode 100644
index 000..33168be
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2018-11237.patch
@@ -0,0 +1,83 @@
+From 9b7c6e4176e61c59b0a63c6ba906d875dc0e Mon Sep 17 00:00:00 2001
+From: Andreas Schwab 
+Date: Tue, 22 May 2018 10:37:59 +0200
+Subject: [PATCH] Don't write beyond destination in  
+__mempcpy_avx512_no_vzeroupper (bug 23196)
+
+When compiled as mempcpy, the return value is the end of the estination 
+buffer, thus it cannot be used to refer to the start of it.
+
+2018-05-23  Andreas Schwab  
+
+   [BZ #23196]
+   CVE-2018-11237
+   * sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S
+   (L(preloop_large)): Save initial destination pointer in %r11 and
+   use it instead of %rax after the loop.
+   * string/test-mempcpy.c (MIN_PAGE_SIZE): Define.
+
+CVE: CVE-2018-11237
+Upstream-Status: Backport
+Signed-off-by: Zheng Ruoqin 
+---
+ ChangeLog   | 9 +
+ string/test-mempcpy.c   | 1 +
+ sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S | 5 +++--
+ 3 files changed, 13 insertions(+), 2 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 23ff0ea..85f6d25 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,12 @@
++2018-05-23  Andreas Schwab  
++
++  [BZ #23196]
++  CVE-2018-11237
++  * sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S
++  (L(preloop_large)): Save initial destination pointer in %r11 and
++  use it instead of %rax after the loop.
++  * string/test-mempcpy.c (MIN_PAGE_SIZE): Define.
++
+ 2018-02-22  Andrew Waterman 
+ 
+   [BZ # 22884]
+diff --git a/string/test-mempcpy.c b/string/test-mempcpy.c index 
+c08fba8..d98ecdd 100644
+--- a/string/test-mempcpy.c
 b/string/test-mempcpy.c
+@@ -18,6 +18,7 @@
+.  */
+ 
+ #define MEMCPY_RESULT(dst, len) (dst) + (len)
++#define MIN_PAGE_SIZE 131072
+ #define TEST_MAIN
+ #define TEST_NAME "mempcpy"
+ #include "test-string.h"
+diff --git a/sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S 
+b/sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S
+index 23c0f7a..a55cf6f 100644
+--- a/sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S
 b/sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S
+@@ -335,6 +335,7 @@ L(preloop_large):
+   ja  L(preloop_large_bkw)
+   vmovups (%rsi), %zmm4
+   vmovups 0x40(%rsi), %zmm5
++  mov %rdi, %r11
+ 
+ /* Align destination for access with non-temporal stores in the loop.  */
+   mov %rdi, %r8
+@@ -366,8 +367,8 @@ L(gobble_256bytes_nt_loop):
+   cmp $256, %rdx
+   ja  L(gobble_256bytes_nt_loop)
+   sfence
+-  vmovups %zmm4, (%rax)
+-  vmovups %zmm5, 0x40(%rax)
++  vmovups %zmm4, (%r11)
++  vmovups %zmm5, 0x40(%r11)
+   jmp L(check)
+ 
+ L(preloop_large_bkw):
+--
+1.8.3.1
+
diff --git a/meta/recipes-core/glibc/glibc_2.27.bb 
b/meta/recipes-core/glibc/glibc_2.27.bb
index c814798..59c9d07 100644
--- a/meta/recipes-core/glibc/glibc_2.27.bb
+++ b/meta/recipes-core/glibc/glibc_2.27.bb
@@ -45,6 +45,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \

file://0028-bits-siginfo-consts.h-enum-definition-for-TRAP_HWBKP.patch \

file://0029-Replace-strncpy-with-memccpy-to-fix-Wstringop-trunca.patch \
file://0030-plural_c_no_preprocessor_lines.patch \
+   file://CVE-2018-11237.patch \
 "
 
 NATIVESDKFIXES ?= ""
--
1.8.3.1



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

[OE-core] [PATCH v2 3/6] gstreamer1.0-plugin-bad: Update packageconfigs

* Add packageconfigs for gl, libde265, lcms2, openh264, tinyalsa, ttml,
  webrtc, webrtcdsp
* Add note about neon being dead (and --disable-neon config switch)
* Remove unnecessary gstglconfig.h line, since that file is no longer
  part of -bad (it is in -base now)
* Update EXTRA_OECONF flags, since new plugins got added to -bad
* Add ttml to the default packageconfigs since its dependencies are
  all in oe-core
---
 .../gstreamer1.0-plugins-bad_1.14.1.bb| 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb
index 0e477e5a9c..721df60b8d 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb
@@ -27,9 +27,14 @@ PACKAGECONFIG ??= " \
 ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
 ${@bb.utils.filter('DISTRO_FEATURES', 'directfb vulkan', d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland', '', d)} \
-bz2 curl dash dtls hls rsvg sbc smoothstreaming sndfile uvch264 webp \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)} \
+bz2 curl dash dtls hls rsvg sbc smoothstreaming sndfile ttml uvch264 webp \
 "
 
+# the gl packageconfig enables OpenGL elements that haven't been ported
+# to -base yet. They depend on the gstgl library in -base, so we do
+# not add GL dependencies here, since these are taken care of in -base.
+
 PACKAGECONFIG[assrender]   = 
"--enable-assrender,--disable-assrender,libass"
 PACKAGECONFIG[bluez]   = "--enable-bluez,--disable-bluez,${BLUEZ}"
 PACKAGECONFIG[bz2] = "--enable-bz2,--disable-bz2,bzip2"
@@ -43,13 +48,17 @@ PACKAGECONFIG[faad]= 
"--enable-faad,--disable-faad,faad2"
 PACKAGECONFIG[flite]   = "--enable-flite,--disable-flite,flite-alsa"
 PACKAGECONFIG[fluidsynth]  = 
"--enable-fluidsynth,--disable-fluidsynth,fluidsynth"
 PACKAGECONFIG[hls] = "--enable-hls 
--with-hls-crypto=nettle,--disable-hls,nettle"
+PACKAGECONFIG[gl]  = "--enable-gl,--disable-gl,"
 PACKAGECONFIG[kms] = "--enable-kms,--disable-kms,libdrm"
+PACKAGECONFIG[libde265]= 
"--enable-libde265,--disable-libde265,libde265"
 PACKAGECONFIG[libmms]  = "--enable-libmms,--disable-libmms,libmms"
 PACKAGECONFIG[libssh2] = "--enable-libssh2,--disable-libssh2,libssh2"
+PACKAGECONFIG[lcms2]   = "--enable-lcms2,--disable-lcms2,lcms"
 PACKAGECONFIG[modplug] = 
"--enable-modplug,--disable-modplug,libmodplug"
 PACKAGECONFIG[neon]= "--enable-neon,--disable-neon,neon"
 PACKAGECONFIG[openal]  = "--enable-openal,--disable-openal,openal-soft"
 PACKAGECONFIG[opencv]  = "--enable-opencv,--disable-opencv,opencv"
+PACKAGECONFIG[openh264]= 
"--enable-openh264,--disable-openh264,openh264"
 PACKAGECONFIG[openjpeg]= 
"--enable-openjpeg,--disable-openjpeg,openjpeg"
 # the opus encoder/decoder elements are now in the -base package,
 # but the opus parser remains in -bad
@@ -61,28 +70,38 @@ PACKAGECONFIG[sbc] = 
"--enable-sbc,--disable-sbc,sbc"
 PACKAGECONFIG[smoothstreaming] = 
"--enable-smoothstreaming,--disable-smoothstreaming,libxml2"
 PACKAGECONFIG[sndfile] = 
"--enable-sndfile,--disable-sndfile,libsndfile1"
 PACKAGECONFIG[srtp]= "--enable-srtp,--disable-srtp,libsrtp"
+PACKAGECONFIG[tinyalsa]= 
"--enable-tinyalsa,--disable-tinyalsa,tinyalsa"
+PACKAGECONFIG[ttml]= "--enable-ttml,--disable-ttml,libxml2 pango 
cairo"
 PACKAGECONFIG[uvch264] = "--enable-uvch264,--disable-uvch264,libusb1 
libgudev"
 PACKAGECONFIG[voaacenc]= 
"--enable-voaacenc,--disable-voaacenc,vo-aacenc"
 PACKAGECONFIG[voamrwbenc]  = 
"--enable-voamrwbenc,--disable-voamrwbenc,vo-amrwbenc"
 PACKAGECONFIG[vulkan]  = "--enable-vulkan,--disable-vulkan,vulkan"
 PACKAGECONFIG[wayland] = 
"--enable-wayland,--disable-wayland,wayland-native wayland wayland-protocols 
libdrm"
 PACKAGECONFIG[webp]= "--enable-webp,--disable-webp,libwebp"
+PACKAGECONFIG[webrtc]  = "--enable-webrtc,--disable-webrtc,libnice"
+PACKAGECONFIG[webrtcdsp]   = 
"--enable-webrtcdsp,--disable-webrtcdsp,webrtc-audio-processing"
 
 # these plugins have no corresponding library in OE-core or meta-openembedded:
 #   openni2 winks direct3d directsound winscreencap acm apple_media iqa
-#   android_media avc bs2b chromaprint daala dts fdkaac gme gsm kate ladspa 
libde265
-#   lv2 mpeg2enc mplex msdk musepack nvenc ofa openh264 opensles soundtouch 
spandsp
-#   spc teletextdec tinyalsa vdpau wasapi x265 zbar webrtcdsp
+#   android_media avc bs2b chromaprint daala dts fdkaac gme gsm kate ladspa
+#   lv2 mpeg2enc mplex msdk musepack nvenc ofa openmpt opensles soundtouch
+#   spandsp spc teletextdec vdpa

[OE-core] [PATCH v2 4/6] gstreamer1.0-vaapi: Remove unnecessary FILESPATH modification

Signed-off-by: Carlos Rafael Giani 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
index 906dc6e6c4..e647458fab 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
@@ -4,7 +4,6 @@ based plugins for GStreamer and helper libraries: 
`vaapidecode', \
 `vaapiconvert', and `vaapisink'."
 
 REALPN = "gstreamer-vaapi"
-FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${REALPN}", 
"${FILE_DIRNAME}/${REALPN}"], d)}"
 
 LICENSE = "LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"
-- 
2.17.1

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

[OE-core] [PATCH v2 2/6] gstreamer1.0-plugin-good: Update packageconfigs

* There is no twolame recipe in oe-core or in meta-openembedded, so
  disable it
* Reorder the packageconfigs alphabetically

Signed-off-by: Carlos Rafael Giani 
---
 .../gstreamer/gstreamer1.0-plugins-good_1.14.1.bb   | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb
index 36eb3107ae..beae43f915 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb
@@ -28,20 +28,24 @@ PACKAGECONFIG ??= " \
 ${GSTREAMER_ORC} \
 ${@bb.utils.filter('DISTRO_FEATURES', 'pulseaudio x11', d)} \
 ${@bb.utils.contains_any('DISTRO_FEATURES', 
d.getVar('GTK3DISTROFEATURES'), 'gtk', '', d)} \
-cairo flac gdk-pixbuf gudev jpeg libpng soup speex taglib v4l2 bz2 zlib 
mpg123 lame \
+bz2 cairo flac gdk-pixbuf gudev jpeg lame libpng mpg123 soup speex taglib 
v4l2 zlib \
 "
 
 X11DEPENDS = "virtual/libx11 libsm libxrender libxfixes libxdamage"
 
+PACKAGECONFIG[bz2]= "--enable-bz2,--disable-bz2,bzip2"
 PACKAGECONFIG[cairo]  = "--enable-cairo,--disable-cairo,cairo"
 PACKAGECONFIG[dv1394] = "--enable-dv1394,--disable-dv1394,libiec61883 
libavc1394 libraw1394"
 PACKAGECONFIG[flac]   = "--enable-flac,--disable-flac,flac"
 PACKAGECONFIG[gdk-pixbuf] = 
"--enable-gdk_pixbuf,--disable-gdk_pixbuf,gdk-pixbuf"
+PACKAGECONFIG[gtk]= "--enable-gtk3,--disable-gtk3,gtk+3"
 PACKAGECONFIG[gudev]  = "--with-gudev,--without-gudev,libgudev"
 PACKAGECONFIG[jack]   = "--enable-jack,--disable-jack,jack"
 PACKAGECONFIG[jpeg]   = "--enable-jpeg,--disable-jpeg,jpeg"
+PACKAGECONFIG[lame]   = "--enable-lame,--disable-lame,lame"
 PACKAGECONFIG[libpng] = "--enable-libpng,--disable-libpng,libpng"
 PACKAGECONFIG[libv4l2]= "--with-libv4l2,--without-libv4l2,v4l-utils"
+PACKAGECONFIG[mpg123] = "--enable-mpg123,--disable-mpg123,mpg123"
 PACKAGECONFIG[pulseaudio] = "--enable-pulse,--disable-pulse,pulseaudio"
 PACKAGECONFIG[soup]   = "--enable-soup,--disable-soup,libsoup-2.4"
 PACKAGECONFIG[speex]  = "--enable-speex,--disable-speex,speex"
@@ -50,11 +54,7 @@ PACKAGECONFIG[v4l2]   = "--enable-gst_v4l2 
--enable-v4l2-probe,--disable-gst
 PACKAGECONFIG[vpx]= "--enable-vpx,--disable-vpx,libvpx"
 PACKAGECONFIG[wavpack]= "--enable-wavpack,--disable-wavpack,wavpack"
 PACKAGECONFIG[x11]= "--enable-x,--disable-x,${X11DEPENDS}"
-PACKAGECONFIG[bz2]= "--enable-bz2,--disable-bz2,bzip2"
 PACKAGECONFIG[zlib]   = "--enable-zlib,--disable-zlib,zlib"
-PACKAGECONFIG[lame]   = "--enable-lame,--disable-lame,lame"
-PACKAGECONFIG[mpg123] = "--enable-mpg123,--disable-mpg123,mpg123"
-PACKAGECONFIG[gtk]= "--enable-gtk3,--disable-gtk3,gtk+3"
 
 # qt5 support is disabled, because it is not present in OE core, and requires 
more work than
 # just adding a packageconfig (it requires access to moc, uic, rcc, and qmake 
paths).
@@ -71,9 +71,10 @@ EXTRA_OECONF += " \
 --disable-oss4 \
 --disable-osx_audio \
 --disable-osx_video \
+--disable-qt \
 --disable-shout2 \
+--disable-twolame \
 --disable-waveform \
---disable-qt \
 "
 
 FILES_${PN}-equalizer += "${datadir}/gstreamer-1.0/presets/*.prs"
-- 
2.17.1

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

openembedded-core@lists.openembedded.org

2018-07-19 Thread hongl


ping



Fix CVE-2018-1122 & CVE-2018-1122

Signed-off-by: Hong Liu 
---
  .../procps/procps/CVE-2018-1122.patch  | 70 ++
  .../procps/procps/CVE-2018-1123.patch  | 84 ++
  meta/recipes-extended/procps/procps_3.3.12.bb  |  2 +
  3 files changed, 156 insertions(+)
  create mode 100644 meta/recipes-extended/procps/procps/CVE-2018-1122.patch
  create mode 100644 meta/recipes-extended/procps/procps/CVE-2018-1123.patch

diff --git a/meta/recipes-extended/procps/procps/CVE-2018-1122.patch 
b/meta/recipes-extended/procps/procps/CVE-2018-1122.patch
new file mode 100644
index 000..f840873
--- /dev/null
+++ b/meta/recipes-extended/procps/procps/CVE-2018-1122.patch
@@ -0,0 +1,70 @@
+From 3cf9b0f403f758a2cfdc6f52f76c261b0f6ce924 Mon Sep 17 00:00:00 2001
+From: Qualys Security Advisory 
+Date: Thu, 1 Jan 1970 00:00:00 +
+Subject: [PATCH 097/126] top: Do not default to the cwd in configs_read().
+
+If the HOME environment variable is not set, or not absolute, use the
+home directory returned by getpwuid(getuid()), if set and absolute
+(instead of the cwd "."); otherwise, set p_home to NULL.
+
+To keep the changes to a minimum, we rely on POSIX, which requires that
+fopen() fails with ENOENT if the pathname (Rc_name) is an empty string.
+This integrates well into the existing code, and makes write_rcfile()
+work without a change.
+
+Also, it makes the code in configs_read() easier to follow: only set and
+use p_home if safe, and only set Rc_name if safe (in all the other cases
+it is the empty string, and the fopen() calls fail). Plus, check for
+snprintf() truncation (and if it happens, reset Rc_name to the empty
+string).
+
+Important note: top.1 should probably be updated, since it mentions the
+fallback to the current working directory.
+[carnil: Backport to 3.3.12: p_home -> p, context]
+
+Signed-off-by: Qualys Security Advisory 
+---
+ top/top.c | 33 -
+ 1 file changed, 28 insertions(+), 5 deletions(-)
+
+--- a/top/top.c
 b/top/top.c
+@@ -3423,6 +3423,19 @@ static int config_cvt (WIN_t *q) {
+return 0;
+ } // end: config_cvt
+
++static int snprintf_Rc_name (const char *const format, ...) 
__attribute__((format(printf,1,2)));
++static int snprintf_Rc_name (const char *const format, ...) {
++   int len;
++   va_list ap;
++   va_start(ap, format);
++   len = vsnprintf(Rc_name, sizeof(Rc_name), format, ap);
++   va_end(ap);
++   if (len <= 0 || (size_t)len >= sizeof(Rc_name)) {
++  Rc_name[0] = '\0';
++  return 0;
++   }
++   return len;
++}
+
+ /*
+  * Build the local RC file name then try to read both of 'em.
+@@ -3445,8 +3458,17 @@ static void configs_read (void) {
+FILE *fp;
+int i;
+
++   Rc_name[0] = '\0'; // "fopen() shall fail if pathname is an empty string."
+p = getenv("HOME");
+-   snprintf(Rc_name, sizeof(Rc_name), "%s/.%src", (p && *p) ? p : ".", 
Myname);
++   if (!p || p[0] != '/') {
++  const struct passwd *const pwd = getpwuid(getuid());
++  if (!pwd || !(p = pwd->pw_dir) || p[0] != '/') {
++ p = NULL;
++  }
++   }
++   if (p) {
++  snprintf_Rc_name("%s/.%src", p, Myname);
++   }
+
+fp = fopen(SYS_RCFILESPEC, "r");
+if (fp) {
diff --git a/meta/recipes-extended/procps/procps/CVE-2018-1123.patch 
b/meta/recipes-extended/procps/procps/CVE-2018-1123.patch
new file mode 100644
index 000..a2060e8
--- /dev/null
+++ b/meta/recipes-extended/procps/procps/CVE-2018-1123.patch
@@ -0,0 +1,84 @@
+From 136e3724952827bbae8887a42d9d2b6f658a48ab Mon Sep 17 00:00:00 2001
+From: Qualys Security Advisory 
+Date: Thu, 1 Jan 1970 00:00:00 +
+Subject: [PATCH] ps/output.c: Fix outbuf overflows in pr_args() etc.
+
+Because there is usually less than OUTBUF_SIZE available at endp.
+
+Signed-off-by: Qualys Security Advisory 
+---
+ ps/output.c | 23 ++-
+ 1 file changed, 14 insertions(+), 9 deletions(-)
+
+diff --git a/ps/output.c b/ps/output.c
+index 0c63bb6..4456f28 100644
+--- a/ps/output.c
 b/ps/output.c
+@@ -389,6 +389,9 @@ Modifications to the arguments are not shown.
+
+ // FIXME: some of these may hit the guard page in forest mode
+
++#define OUTBUF_SIZE_AT(endp) \
++  (((endp) >= outbuf && (endp) < outbuf + OUTBUF_SIZE) ? (outbuf + 
OUTBUF_SIZE) - (endp) : 0)
++
+ /*
+  * "args", "cmd", "command" are all the same:  long  unless  c
+  * "comm", "ucmd", "ucomm"  are all the same:  short unless -f
+@@ -402,15 +405,15 @@ static int pr_args(char *restrict const outbuf, const 
proc_t *restrict const pp)
+   rightward -= fh;
+
+   if(pp->cmdline && !bsd_c_option)
+-endp += escaped_copy(endp, *pp->cmdline, OUTBUF_SIZE, &rightward);
++endp += escaped_copy(endp, *pp->cmdline, OUTBUF_SIZE_AT(endp), 
&rightward);
+   else
+-endp += escape_command(endp, pp, OUTBUF_SIZE, &rightward, ESC_DEFUNCT);
++endp += escape_command(endp, pp, OUTBUF_SIZE_AT(endp), &rightward, 
ESC_DEFUNCT);
+
+-  if(bsd_e_option && rightwar

Re: [OE-core] [PATCH] Fix build error when enable archiver.

2018-07-19 Thread Richard Purdie

This patch does not look correct. "nopackages" has a very specific
meaning and the archive policy may or may not be different from that
but they need to remain separate.

So no, this patch is not going to be merged, sorry.

Cheers,

Richard

On Thu, 2018-07-19 at 09:37 +, Lei, Maohui wrote:
> ping
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-
> > core-boun...@lists.openembedded.org] On Behalf Of Lei, Maohui
> > Sent: Tuesday, June 19, 2018 9:22 AM
> > To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH] Fix build error when enable
> > archiver.
> > 
> > Hi Peter
> > 
> > > This cannot be correct. If I am not mistaken, then this would
> > > effectively disable the archiver class from outputting anything
> > > for
> > > native packages.
> > 
> > I don't think there is any necessary to create archiver for xx-
> > native as same
> > as no need to create packages for xx-native.
> > xx-native is only useful on build system, it is not outcome of
> > build system.
> > 
> > Best regards
> > Lei
> > 
> > 
> > > -Original Message-
> > > From: Peter Kjellerstedt [mailto:peter.kjellerst...@axis.com]
> > > Sent: Thursday, June 14, 2018 6:55 PM
> > > To: Lei, Maohui; openembedded-core@lists.openembedded.org
> > > Subject: RE: [OE-core] [PATCH] Fix build error when enable
> > > archiver.
> > > 
> > > > -Original Message-
> > > > From: openembedded-core-boun...@lists.openembedded.org
> > > > [mailto:openembedded-core-boun...@lists.openembedded.org] On
> > > > Behalf Of
> > > > Lei Maohui
> > > > Sent: den 2 juni 2018 23:04
> > > > To: openembedded-core@lists.openembedded.org
> > > > Subject: [OE-core] [PATCH] Fix build error when enable
> > > > archiver.
> > > > 
> > > > The error is as fllowing:
> > > > ERROR: Task do_deploy_archives in
> > > > virtual:native:/yocto/poky/meta/recipes-
> > > > extended/newt/libnewt_0.52.20.bb
> > > 
> > > depends upon non-existent task
> > > > do_package_write_rpm in
> > > > virtual:native:/yocto/poky/meta/recipes-
> > > 
> > > extended/newt/libnewt_0.52.20.bb
> > > > ERROR: Command execution failed: 1
> > > > 
> > > > Signed-off-by: Lei Maohui 
> > > > ---
> > > >  meta/classes/nopackages.bbclass | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/meta/classes/nopackages.bbclass
> > > 
> > > b/meta/classes/nopackages.bbclass
> > > > index 559f507..d9ddfac 100644
> > > > --- a/meta/classes/nopackages.bbclass
> > > > +++ b/meta/classes/nopackages.bbclass
> > > > @@ -10,3 +10,4 @@ deltask do_package_write_ipk_setscene
> > > >  deltask do_package_write_deb_setscene
> > > >  deltask do_package_qa_setscene
> > > >  deltask do_packagedata_setscene
> > > > +deltask do_deploy_archives
> > > > --
> > > > 1.9.1
> > > 
> > > This cannot be correct. If I am not mistaken, then this would
> > > effectively disable the archiver class from outputting anything
> > > for
> > > native packages.
> > > 
> > > //Peter
> > > 
> > > 
> > 
> > 
> > 
> > --
> > ___
> > 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] Fix build error when enable archiver.

2018-07-19 Thread Lei, Maohui

ping

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-
> core-boun...@lists.openembedded.org] On Behalf Of Lei, Maohui
> Sent: Tuesday, June 19, 2018 9:22 AM
> To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] Fix build error when enable archiver.
> 
> Hi Peter
> 
> > This cannot be correct. If I am not mistaken, then this would
> > effectively disable the archiver class from outputting anything for
> > native packages.
> 
> I don't think there is any necessary to create archiver for xx-native as same
> as no need to create packages for xx-native.
> xx-native is only useful on build system, it is not outcome of build system.
> 
> Best regards
> Lei
> 
> 
> > -Original Message-
> > From: Peter Kjellerstedt [mailto:peter.kjellerst...@axis.com]
> > Sent: Thursday, June 14, 2018 6:55 PM
> > To: Lei, Maohui; openembedded-core@lists.openembedded.org
> > Subject: RE: [OE-core] [PATCH] Fix build error when enable archiver.
> >
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> > > Lei Maohui
> > > Sent: den 2 juni 2018 23:04
> > > To: openembedded-core@lists.openembedded.org
> > > Subject: [OE-core] [PATCH] Fix build error when enable archiver.
> > >
> > > The error is as fllowing:
> > > ERROR: Task do_deploy_archives in
> > > virtual:native:/yocto/poky/meta/recipes-extended/newt/libnewt_0.52.20.bb
> > depends upon non-existent task
> > > do_package_write_rpm in virtual:native:/yocto/poky/meta/recipes-
> > extended/newt/libnewt_0.52.20.bb
> > > ERROR: Command execution failed: 1
> > >
> > > Signed-off-by: Lei Maohui 
> > > ---
> > >  meta/classes/nopackages.bbclass | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/meta/classes/nopackages.bbclass
> > b/meta/classes/nopackages.bbclass
> > > index 559f507..d9ddfac 100644
> > > --- a/meta/classes/nopackages.bbclass
> > > +++ b/meta/classes/nopackages.bbclass
> > > @@ -10,3 +10,4 @@ deltask do_package_write_ipk_setscene
> > >  deltask do_package_write_deb_setscene
> > >  deltask do_package_qa_setscene
> > >  deltask do_packagedata_setscene
> > > +deltask do_deploy_archives
> > > --
> > > 1.9.1
> >
> > This cannot be correct. If I am not mistaken, then this would
> > effectively disable the archiver class from outputting anything for
> > native packages.
> >
> > //Peter
> >
> >
> 
> 
> 
> --
> ___
> 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 1/6] gstreamer1.0-plugin-base: Update packageconfigs