Re: [OE-core] [PATCH] gmp: depends on flex-native to fix parallel building issue

[Bai, Haiqing]

Yes, sir,  I did not reproduce this on master.  Even on morty, I only saw
twice.  Maybe we can hold on this and let me keep monitoring.  Thanks.


-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] 
Sent: 2017年12月12日 17:23
To: Bai, Haiqing; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] gmp: depends on flex-native to fix parallel 
building issue

Let me make this simpler. Which release of the project did you see this issue 
with?

I believe this issue would only occur with morty and early, pyro, rocko and 
master are not affected.

Cheers,

Richard

On Tue, 2017-12-12 at 07:13 +, Bai, Haiqing wrote:
> Comments below. thanks
> 
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: 2017年12月11日 6:48
> To: Bai, Haiqing; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] gmp: depends on flex-native to fix 
> parallel building issue
> 
> On Wed, 2017-11-29 at 14:54 +0800, Haiqing Bai wrote:
> > 
> > fix below parallel building issue:
> > configure:27365: result: flex
> > configure:27403: flex conftest.l
> > .../sysroots/x86_64-linux/usr/bin/flex.real: No such file or 
> > directory
> > configure:27407: $? = 127
> > configure:27409: checking lex output file root
> > configure:27420: error: cannot find output from flex; giving up
> > 
> > Signed-off-by: Haiqing Bai 
> > ---
> >  meta/recipes-support/gmp/gmp.inc | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes- 
> > support/gmp/gmp.inc index abac8cf..1b35eaa 100644
> > --- a/meta/recipes-support/gmp/gmp.inc
> > +++ b/meta/recipes-support/gmp/gmp.inc
> > @@ -10,3 +10,5 @@ PACKAGECONFIG[readline] = "--with-readline=yes, 
> > --with-readline=no,readline"
> >  
> >  ARM_INSTRUCTION_SET_armv4 = "arm"
> >  ARM_INSTRUCTION_SET_armv5 = "arm"
> > +
> > +DEPENDS = "flex-native"
> With recipe specific sysroots this should now be deterministic. The 
> log above suggests you were not using recipe specific sysroots? This 
> would therefore only be applicable to morty and earlier?
> [This issue is founded on x86-64 building,  but it does not mean it is 
> only related with x86.  Actually this is caused by the defect of the 
> traditional probe mechanism of 'configure',  the package configure 
> script try to probe whether has package 'flex' , then some optional 
> actions will be done by it.  In this issue,  when this probe happens,   
> /usr/bin/flex exists but '/usr/bin/flex.real' has not created for the 
> parallel building,  then configure reports the error and exits from 
> building.   Since there are no atomic guarantee for the package output 
> during parallel building, so here add this depends]
> 
> Cheers,
> 
> Richard
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] syslinux: always use the BFD linker

[Andre McCurdy]

On Tue, Dec 12, 2017 at 6:42 PM, Allen Wild  wrote:
> Oops, forgot mail the list when sending my first reply.
>
> I tried appending LDFLAGS, but it doesn't work for syslinux. It's
> during do_install, not do_compile, that $(LD) is called directly to
> link libutil.elf, libcom32.elf, libgpl.elf, and ldlinux.elf.
>
> A python-free but more intrusive appropach to fix this could be to add
> a new variable e.g. HOST_LDNAME in bitbake.conf and incorporate it
> into the definition of LD. It would default to "ld" but could be
> overridden by recipes like syslinux where appending LDFLAGS doesn't
> work.
>
> If we don't expect the bitbake.conf definition of LD to change,
> syslinux could also just simply redefine LD =
> "${HOST_PREFIX}ld.bfd${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"

If you don't need to modify the value of LD in the bitbake environment
(only the value seen by Make) perhaps try something like this:

  LD='${LD} -fuse-ld=bfd"

passed on the Make command line?

> Thoughts?
> --Allen
>
> On Tue, Dec 12, 2017 at 4:46 PM, Allen Wild  wrote:
>>> Hm, other recipes that have this need typically simply do:
>>>
>>> LDFLAGS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' 
>>> -fuse-ld=bfd ', '', d)}"
>>>
>>> Would a similar approach work here, too? Instead of this big change.
>>
>> I thought about that, but grepping the Makefiles appeared to show many
>> usages of $(LD) directly rather than using gcc as the linker, so I
>> assumed it wouldn't work.
>>
>> However, I just looked more closely at my log.do_compile and I don't
>> see anything appear to call LD directly, everything is getting run
>> through x86_64-oe-linux-gcc.
>> Clearly the LD variable passed to make affects this consistently, but
>> now I don't know why. I'll try appending LDFLAGS and see if that
>> works.
>>
>> Regards,
>> Allen
>>
>> On Tue, Dec 12, 2017 at 3:55 AM, André Draszik  wrote:
>>> On Mon, 2017-12-11 at 21:49 -0500, Allen Wild wrote:
 Syslinux compiles successfully with Gold, but at runtime Isolinux fails
 to boot, getting stuck at the version screen without loading the menu.
 Forcing the BFD linker fixes this.

 To future-proof, use an inline python replace rather than duplicating
 the definition of LD in bitbake.conf
>>>
>>> Hm, other recipes that have this need typically simply do:
>>>
>>> LDFLAGS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' 
>>> -fuse-ld=bfd ', '', d)}"
>>>
>>> Would a similar approach work here, too? Instead of this big change.
>>>
>>> Cheers,
>>> Andre'

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

[OE-core] [PATCH 1/1] image-live.bbclass: print warn when initramfs is invalid

[Robert Yang]

It's a problem when initramfs is invalid, so print warn rather than note.

Signed-off-by: Robert Yang 
---
 meta/classes/image-live.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index 9f8ff79..1623c15 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -92,7 +92,7 @@ build_iso() {
for fs in ${INITRD}
do
if [ ! -s "$fs" ]; then
-   bbnote "ISO image will not be created. $fs is invalid."
+   bbwarn "ISO image will not be created. $fs is invalid."
return
fi
done
-- 
2.7.4

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

[OE-core] [PATCH 0/1] image-live.bbclass: print warn when initramfs is invalid

[Robert Yang]

The following changes since commit ba274d3c3832b5add3e599a5f350aafeb81c3cfb:

  image-live.bbclass: add MLPREFIX to core-image-minimal-initramfs (2017-12-13 
10:44:31 +0800)

are available in the git repository at:

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

Robert Yang (1):
  image-live.bbclass: print warn when initramfs is invalid

 meta/classes/image-live.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.7.4

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

[OE-core] [PATCH 2/2] image-live.bbclass: remove MLPREFIX from syslinux

[Robert Yang]

Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
IMAGE_FSTYPES += "iso"

$ bitbake lib32-core-image-minimal
ERROR: lib32-core-image-minimal-1.0-r0 do_bootimg: The file 
/usr/include/printf.h is installed by both glibc and lib32-glibc, aborting

This was because:
lib32-syslinux -> lib32-glibc
virtual/kernel -> glibc

We can build 64bit syslinux (only build, not install) to fix the problem, the
do_bootimg only needs several data files of syslinux such as vesamenu.c32,
these files are not arch related.

Signed-off-by: Robert Yang 
---
 meta/classes/image-live.bbclass | 2 +-
 meta/classes/syslinux.bbclass   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index 9f8ff79..8872195 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -31,7 +31,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot 
\
 mtools-native:do_populate_sysroot \
 cdrtools-native:do_populate_sysroot \
 virtual/kernel:do_deploy \
-${MLPREFIX}syslinux:do_populate_sysroot \
+syslinux:do_populate_sysroot \
 syslinux-native:do_populate_sysroot \
 ${@oe.utils.ifelse(d.getVar('COMPRESSISO', 
False),'zisofs-tools-native:do_populate_sysroot','')} \
 
${PN}:do_image_${@d.getVar('LIVE_ROOTFS_TYPE').replace('-', '_')} \
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index d6f8824..98939ba 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -17,7 +17,7 @@
 # ${SYSLINUX_SERIAL_TTY} - Set alternate console=tty... kernel boot argument
 # ${SYSLINUX_KERNEL_ARGS} - Add additional kernel arguments
 
-do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \
+do_bootimg[depends] += "syslinux:do_populate_sysroot \
 syslinux-native:do_populate_sysroot"
 
 ISOLINUXDIR ?= "/isolinux"
-- 
2.7.4

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

[OE-core] [PATCH 0/2] fix multilib + iso

[Robert Yang]

The following changes since commit a24c10b7bdab8aa960fdd3a58d2009f24344e579:

  populate_sdk_ext: Use prebuilt uninative tarball (2017-12-11 21:46:33 +)

are available in the git repository at:

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

Robert Yang (2):
  image-live.bbclass: add MLPREFIX to core-image-minimal-initramfs
  image-live.bbclass: remove MLPREFIX from syslinux

 meta/classes/image-live.bbclass  | 4 ++--
 meta/classes/syslinux.bbclass| 2 +-
 meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.7.4

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

[OE-core] [PATCH 1/2] image-live.bbclass: add MLPREFIX to core-image-minimal-initramfs

[Robert Yang]

The 32bit core-image-minimal-initramfs should be built when build lib32-iso, 
e.g.:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
IMAGE_FSTYPES += "iso"

$ bitbake lib32-core-image-minimal
Exception: FileExistsError: [Errno 17] File exists: 
'/path/to/tmp/sysroots-components/core2-64/qemuwrapper-cross/usr/bin/crossscripts/qemuwrapper'
 -> 
'/path/to/tmp/work/qemux86_64-pokymllib32-linux/lib32-core-image-minimal/1.0-r0/lib32-recipe-sysroot/usr/bin/crossscripts/qemuwrapper'

This was because:
lib32-core-image-minimal -> core-image-minimal-initramfs
core-image-minimal-initramfs -> qemuwrapper-cross
lib32-core-image-minimal -> lib32-qemuwrapper-cross

So we got the error, build lib32-core-image-minimal-initramfs can fix the 
problem.

Signed-off-by: Robert Yang 
---
 meta/classes/image-live.bbclass  | 2 +-
 meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index 7a388d5..9f8ff79 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -40,7 +40,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot 
\
 
 LABELS_LIVE ?= "boot install"
 ROOT_LIVE ?= "root=/dev/ram0"
-INITRD_IMAGE_LIVE ?= "core-image-minimal-initramfs"
+INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
 INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
 
 LIVE_ROOTFS_TYPE ?= "ext4"
diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb 
b/meta/recipes-core/images/core-image-minimal-initramfs.bb
index 5794a25..c446e87 100644
--- a/meta/recipes-core/images/core-image-minimal-initramfs.bb
+++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb
@@ -8,7 +8,7 @@ PACKAGE_INSTALL = "initramfs-live-boot initramfs-live-install 
initramfs-live-ins
 # Do not pollute the initrd image with rootfs features
 IMAGE_FEATURES = ""
 
-export IMAGE_BASENAME = "core-image-minimal-initramfs"
+export IMAGE_BASENAME = "${MLPREFIX}core-image-minimal-initramfs"
 IMAGE_LINGUAS = ""
 
 LICENSE = "MIT"
-- 
2.7.4

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

Re: [OE-core] [PATCH] syslinux: always use the BFD linker

[Allen Wild]

Oops, forgot mail the list when sending my first reply.

I tried appending LDFLAGS, but it doesn't work for syslinux. It's
during do_install, not do_compile, that $(LD) is called directly to
link libutil.elf, libcom32.elf, libgpl.elf, and ldlinux.elf.

A python-free but more intrusive appropach to fix this could be to add
a new variable e.g. HOST_LDNAME in bitbake.conf and incorporate it
into the definition of LD. It would default to "ld" but could be
overridden by recipes like syslinux where appending LDFLAGS doesn't
work.

If we don't expect the bitbake.conf definition of LD to change,
syslinux could also just simply redefine LD =
"${HOST_PREFIX}ld.bfd${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"

Thoughts?
--Allen

On Tue, Dec 12, 2017 at 4:46 PM, Allen Wild  wrote:
>> Hm, other recipes that have this need typically simply do:
>>
>> LDFLAGS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' 
>> -fuse-ld=bfd ', '', d)}"
>>
>> Would a similar approach work here, too? Instead of this big change.
>
> I thought about that, but grepping the Makefiles appeared to show many
> usages of $(LD) directly rather than using gcc as the linker, so I
> assumed it wouldn't work.
>
> However, I just looked more closely at my log.do_compile and I don't
> see anything appear to call LD directly, everything is getting run
> through x86_64-oe-linux-gcc.
> Clearly the LD variable passed to make affects this consistently, but
> now I don't know why. I'll try appending LDFLAGS and see if that
> works.
>
> Regards,
> Allen
>
> On Tue, Dec 12, 2017 at 3:55 AM, André Draszik  wrote:
>> On Mon, 2017-12-11 at 21:49 -0500, Allen Wild wrote:
>>> Syslinux compiles successfully with Gold, but at runtime Isolinux fails
>>> to boot, getting stuck at the version screen without loading the menu.
>>> Forcing the BFD linker fixes this.
>>>
>>> To future-proof, use an inline python replace rather than duplicating
>>> the definition of LD in bitbake.conf
>>
>> Hm, other recipes that have this need typically simply do:
>>
>> LDFLAGS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' 
>> -fuse-ld=bfd ', '', d)}"
>>
>> Would a similar approach work here, too? Instead of this big change.
>>
>> Cheers,
>> Andre'
>>>
>> --
>> ___
>> 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 v9] kernel: Add support for multiple kernel packages

[Haris Okanovic]

Hi Ross,

On 12/04/2017 10:13 AM, Burton, Ross wrote:
I know I'm late and this has gone through so many revisions, but I'm 
seeing unexplained changes in buildhistory:


$ buildhistory-diff
packages/corei7-64-intel-common-poky-linux/linux-intel/kernel-image-bzimage: 
FILELIST: removed "/boot/bzImage"


Doing builds of virtual/kernel with and without this patch and comparing 
pkgdata directly confirms that the /boot/bzImage symlink doesn't exist 
with this patch but does without it.




I can see a reference to "/boot/bzImage" in both buildhistory and 
tmp-glibc/work/.../pkgdata [1] after running a clean rebuild of 
virtual/kernel [2].


[1] file paths:

"buildhistory/packages/qemux86-oe-linux/linux-yocto/kernel-image-bzimage/files-in-package.txt"

"tmp-glibc/work/qemux86-oe-linux/linux-yocto/4.12.12+gitAUTOINC+eda4d18ce4_16de014967-r0/pkgdata/runtime/kernel-image-bzimage"

[2] clean rebuild command:
 bitbake -c cleanall virtual/kernel
 bitbake virtual/kernel

Which file are you diffing? Could you share the full path?

-- Haris


Ross

On 10 November 2017 at 21:51, Haris Okanovic > wrote:


No problem! Thanks for all the good feedback. I think we shook out
most of the gremlins in the last few months.

Let me know if you need help with boot loader integration.

-- Haris



On 11/08/2017 04:20 PM, Wold, Saul wrote:


Haris,

Thanks for your patience on this process.  This version works
well, now
I have the extra work of getting these kernel known to systemd-boot!

Acked-by below!

Sau!

On Tue, 2017-11-07 at 12:40 -0600, Haris Okanovic wrote:

Some distros may want to provide alternate kernel "flavors"
via feeds
or
within bootable images. For example, readily available
builds which
provide certain diagnostic features can enable developers
and testers
to
more quickly resolve issues by avoiding lengthy kernel builds.

This change allows for building multiple flavors of the
kernel and
module packages by templatizing kernel package names via a new
KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults
to the
old
name of "kernel", but can be overridden by certain recipes
providing
alternate kernel flavors.

To maintain compatibility, recipes providing alternate
kernel flavors
cannot be the "preferred provider" for virtual/kernel. This is
because
OE puts the preferred provider's build and source at
"tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
"tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
"tmp-glibc/work/*/$PN/" like other recipes. Therefore,
recipes using
the
default KERNEL_PACKAGE_NAME="kernel" follows the old
semantics --
build
in the old location and may be preferred provider -- while
recipes
using
all other KERNEL_PACKAGE_NAME's build from the normal
WORKDIR and
don't
provide "virtual/kernel".

Testing:
   1. Add `KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny =
"tiny-linux"`
      to local.conf so that linux-yocto-tiny may build alongside
      the main kernel (linux-yocto).
   2. `bitbake linux-yocto linux-yocto-tiny` to build both
kernel
flavors.
   3. Verified image and modules IPKs exist for both:
      tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
      tmp-glibc/deploy/ipk/qemux86/tiny-linux* for
linux-yocto-tiny
   4. Verified linux-yocto is the "preferred provider", and
was built
in
      shared directory: tmp-glibc/work-shared/qemux86/kernel-*
   5. Add `CORE_IMAGE_BASE_INSTALL_append_pn-core-image-base
= "tiny-
linux"`
      to local.conf to install both kernel flavors in
core-image-base.
   6. `bitbake core-image-base` to build an image.
   7. Verified image contains two bzImage's under /boot/, with
      "yocto-standard" (linux-yocto recipe) selected to boot via
symlink.

Discussion threads:

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openembedded.org_pipermail_openembedded-2Dcore_2015-2DDecemb=DwIGaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=8Bziuw3IaCGjyrSAphuGwHmVdHcVwza-srUYwL9U_Ms=Po_g6d_nUSqHTshbn-ZaBXenlH_4CQklz7Csmi7u70A=cJkppECRP9FwMwrmn-tbJfRpffqbPbeRXS1uCu5JsB0=

Re: [OE-core] [PATCHv3] recipes-multimedia/gstreamer: Add gst-validate recipe

[Khem Raj]

On Tue, Dec 12, 2017 at 9:11 AM, Aníbal Limón  wrote:
> From: Aníbal Limón 
>
> The gst-validate is a tool to run integration tests of Gstreamer
> components [1].
>
> This tool can be used along with gst-integration-testsuites (scenarios
> and media) [2] to test Gstreamer components on the target device.
>
> An example of test using gst-integration-testsuites:
>
> $ gst-validate-launcher --sync # get [2] uses git and git-annex
> $ gst-validate-launcher
>
> or
>
> $ gst-validate-launcher -nd # needs xserver-xorg-xvfb to run wo DISPLAY
>

perhaps it should following the same recipe naming convention as gstreamer 1.0

> [1]
> https://blogs.gnome.org/tsaunier/2014/04/21/gst-validate-a-suite-of-tools-to-run-integration-tests-for-gstreamer-2/
> [2] https://cgit.freedesktop.org/gstreamer/gst-integration-testsuites
>
> Signed-off-by: Aníbal Limón 
> ---
>  .../gstreamer/gst-validate_1.12.3.bb   | 18 
> ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb
>
> diff --git a/meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb 
> b/meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb
> new file mode 100644
> index 00..8f5437641f
> --- /dev/null
> +++ b/meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb
> @@ -0,0 +1,18 @@
> +SUMMARY = "Gstreamer validation tool"
> +DESCRIPTION = "A Tool to test GStreamer components"
> +HOMEPAGE = 
> "https://gstreamer.freedesktop.org/releases/gst-validate/1.12.3.html;
> +SECTION = "multimedia"
> +
> +LICENSE = "LGPLv2.1"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"
> +
> +SRC_URI = "https://gstreamer.freedesktop.org/src/${BPN}/${BP}.tar.xz;
> +SRC_URI[md5sum] = "623edc479a1e5c1e76bd7e1cf8393253"
> +SRC_URI[sha256sum] = 
> "5139949d20274fdd702492438eeab2c9e55aa82f60aca17db27ebd3faf08489e"
> +
> +DEPENDS = "json-glib glib-2.0 gstreamer1.0 gstreamer1.0-plugins-base"
> +RRECOMMENDS_${PN} = "git"
> +
> +FILES_${PN} += "${datadir}/gstreamer-1.0/* ${libdir}/gst-validate-launcher/* 
> ${libdir}/gstreamer-1.0/*"
> +
> +inherit pkgconfig gettext autotools gobject-introspection gtk-doc
> --
> 2.11.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [pyro][PATCH] glibc: Fix CVE-2017-1000366

[George McCollister]

On Thu, Nov 30, 2017 at 9:16 AM, akuster808  wrote:
>
>
> On 11/21/2017 12:03 PM, George McCollister wrote:
>> Add backported patches from the upstream release/2.25/master branch to
>> fix CVE-2017-1000366. Also add a backported patch that resolves SSE
>> related build problems introduced by these patches.
>
> Thanks for the patch. This series causes an error when: bitbake
> core-image-sato -c populate_sdk, so its on hold.
>

Sorry for the delay, this got buried in my inbox and I didn't see it
until today (updated email filters so it shouldn't happen again).

The problem here is that
0003-nativesdk-glibc-Raise-the-size-of-arrays-containing-.patch is
applied first and also touches elf/rtld.c. This causes the patches in
this series to be applied incorrectly against nativesdk-glibc. The
fact that the nativesdk patches are applied before the base patches is
a bit concerning as it could cause other problems as well. It seems
like it would be much safer to apply the base patches then apply the
nativesdk patches to avoid conflicts. Your thoughts?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] wic: argparse now used for help functionality.

[anelliot]

The wic help output formally consisted of manually created strings mixed with 
argparse,
which was unformatted and unusable. This fix cleans up the help messages, 
rewrites help
functionality to use argparse, and adds functionality to show information for
plugins (similar to canned images).

The following changes since commit 58e05020e09971f05effb79f8f1eb2012df4f0db:

  bitbake: providers: Fix determinism issue (2017-12-10 22:45:21 +)

are available in the git repository at:

  git://push.yoctoproject.org/poky-contrib anelliot/bug12205

anelliot (1):
  wic: argparse now used for help functionality.

 scripts/lib/wic/engine.py |   87 +++-
 scripts/lib/wic/help.py   | 1072 +
 scripts/wic   |  169 +++
 3 files changed, 243 insertions(+), 1085 deletions(-)

-- 
2.7.4

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

[OE-core] [PATCH 1/1] wic: argparse now used for help functionality.

[anelliot]

The wic help output formally consisted of manually created strings mixed with 
argparse,
which wasunformatted and unusable. This fix cleans up the help messages, 
rewrites help
functionality to use argparse, and adds functionality to show information for
plugins (similar to canned images).

Fixes [YOCTO #12205]

Signed-off-by: anelliot 
---
 scripts/lib/wic/engine.py |   87 +++-
 scripts/lib/wic/help.py   | 1072 +
 scripts/wic   |  169 +++
 3 files changed, 243 insertions(+), 1085 deletions(-)

diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
index edcfab3..5d1e1d8 100644
--- a/scripts/lib/wic/engine.py
+++ b/scripts/lib/wic/engine.py
@@ -58,6 +58,8 @@ def verify_build_env():
 
 CANNED_IMAGE_DIR = "lib/wic/canned-wks" # relative to scripts
 SCRIPTS_CANNED_IMAGE_DIR = "scripts/" + CANNED_IMAGE_DIR
+SOURCE_PLUGIN_DIR = "lib/wic/plugins/source"
+SCRIPTS_SOURCE_PLUGIN_DIR = "scripts/" + SOURCE_PLUGIN_DIR
 WIC_DIR = "wic"
 
 def build_canned_image_list(path):
@@ -76,6 +78,23 @@ def build_canned_image_list(path):
 
 return canned_wks_layer_dirs
 
+def build_source_plugin_list(path):
+layers_path = get_bitbake_var("BBLAYERS")
+canned_wks_layer_dirs = []
+
+if layers_path is not None:
+for layer_path in layers_path.split():
+for wks_path in (WIC_DIR, SCRIPTS_SOURCE_PLUGIN_DIR):
+cpath = os.path.join(layer_path, wks_path)
+if os.path.isdir(cpath):
+canned_wks_layer_dirs.append(cpath)
+
+cpath = os.path.join(path, SOURCE_PLUGIN_DIR)
+canned_wks_layer_dirs.append(cpath)
+
+return canned_wks_layer_dirs
+
+
 def find_canned_image(scripts_path, wks_file):
 """
 Find a .wks file with the given name in the canned files dir.
@@ -95,6 +114,24 @@ def find_canned_image(scripts_path, wks_file):
 return None
 
 
+def find_source_plugin(scripts_path, plugin_file):
+"""
+Find a .py file with the given name in the source plugin dir.
+
+Return False if not found
+"""
+layers_source_plugin_dir = build_source_plugin_list(scripts_path)
+
+for source_plugin_dir in layers_source_plugin_dir:
+for root, dirs, files in os.walk(source_plugin_dir):
+for fname in files:
+if fname.endswith("~") or fname.endswith("#"):
+continue
+if fname.endswith(".py") and plugin_file + ".py" == fname:
+fullpath = os.path.join(source_plugin_dir, fname)
+return fullpath
+return None
+
 def list_canned_images(scripts_path):
 """
 List the .wks files in the canned image dir, minus the extension.
@@ -119,7 +156,7 @@ def list_canned_images(scripts_path):
 print("  %s\t\t%s" % (basename.ljust(30), desc))
 
 
-def list_canned_image_help(scripts_path, fullpath):
+def list_canned_image_help(fullpath):
 """
 List the help and params in the specified canned image.
 """
@@ -139,6 +176,7 @@ def list_canned_image_help(scripts_path, fullpath):
 if idx != -1:
 print(line[idx + len("#:"):].rstrip())
 else:
+print()
 break
 
 
@@ -152,6 +190,29 @@ def list_source_plugins():
 print("  %s" % plugin)
 
 
+def list_source_plugins_help(fullpath):
+"""
+List the help and params in the specified canned image.
+"""
+found = False
+with open(fullpath) as plugin:
+for line in plugin:
+if not found:
+idx = line.find("DESCRIPTION")
+if idx != -1:
+print(line[idx + len("DESCRIPTION"):].strip())
+found = True
+continue
+if not line.strip():
+break
+idx = line.find("#")
+auth = line.find("AUTHORS")
+if idx != -1 and auth == -1:
+print(line[idx + len("#:"):].rstrip())
+else:
+break
+
+
 def wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
native_sysroot, options):
 """
@@ -204,7 +265,7 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir, 
kernel_dir,
 logger.info("The image(s) were created using OE kickstart file:\n  %s", 
wks_file)
 
 
-def wic_list(args, scripts_path):
+def wic_list(scripts_path, args):
 """
 Print the list of images or source plugins.
 """
@@ -218,16 +279,20 @@ def wic_list(args, scripts_path):
 elif args.list_type == "source-plugins":
 list_source_plugins()
 return True
-elif len(args.help_for) == 1 and args.help_for[0] == 'help':
-wks_file = args.list_type
-fullpath = find_canned_image(scripts_path, wks_file)
+elif len(args.info_for) == 1 and args.info_for[0] == 'info':
+input_file = args.list_type
+fullpath = find_canned_image(scripts_path, input_file)
 if not 

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Otavio Salvador]

On Tue, Dec 12, 2017 at 3:54 PM, Joshua Watt  wrote:
...
> Using a "packaged waf" is against one of the philosophies of waf.
> Consequently, this is one of the reasons software built with waf has
> trouble getting into things like Debian packages.

The more I learn about waf, the more I enjoy not being a waf user ...

You raised quite good points. I believe Stefan latest patch does take
care the most common cases.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Joshua Watt]

On Tue, 2017-12-12 at 16:56 +0100, Stefan Agner wrote:
> On 2017-12-12 16:47, Otavio Salvador wrote:
> > On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner 
> > wrote:
> > > On 2017-12-12 15:13, Burton, Ross wrote:
> > > 
> > > > On 12 December 2017 at 14:03, Stefan Agner 
> > > > wrote:
> > > > 
> > > > > On 2017-12-12 15:00, Burton, Ross wrote:
> > > > > 
> > > > > > On 12 December 2017 at 13:27, Stefan Agner  > > > > > > wrote:
> > > > > > 
> > > > > > > On some build hosts distros (e.g. Fedora 26) waf tries to
> > > > > > > be
> > > > > > > smart about libdir detection and defaults to
> > > > > > > [EXEC_PREFIX/lib64].
> > > > > > > This obviously is not what we want for 32-bit targets and
> > > > > > > usually
> > > > > > > fails in the do_package phase:
> > > > > > > WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package:
> > > > > > > QA Issue: gstreamer1.0-plugins-imx: Files/directories
> > > > > > > were installed but not shipped in any package:
> > > > > > > /usr/lib64/libgstimxcommon.so.0
> > > > > > > 
> > > > > > > Waf knows prefix, bindir and libdir as default options.
> > > > > > > Explicitly
> > > > > > > pass those three.
> > > > > > 
> > > > > > Obviously not.
> > > > > > 
> > > > > > ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed:
> > > > > > do_configure (log file is located at /data/poky-
> > > > > > tmp/master/build/work/corei7-64-poky-linux/eglinfo-
> > > > > > x11/1.0.0-r0/temp/log.do_configure.17278)
> > > > > > ERROR: Logfile of failure stored in: /data/poky-
> > > > > > tmp/master/build/work/corei7-64-poky-linux/eglinfo-
> > > > > > x11/1.0.0-r0/temp/log.do_configure.17278
> > > > > > Log data follows:
> > > > > > > DEBUG: Executing shell function do_configure
> > > > > > > waf [commands] [options]
> > > > > > > 
> > > > > > > Main commands (example: ./waf build -j4)
> > > > > > >   build: executes the build
> > > > > > >   clean: cleans the project
> > > > > > >   configure: configures the project
> > > > > > >   dist : makes a tarball for redistributing the
> > > > > > > sources
> > > > > > >   distcheck: checks if the project compiles (tarball from
> > > > > > > 'dist')
> > > > > > >   distclean: removes the build directory
> > > > > > >   install  : installs the targets on the system
> > > > > > >   list : lists the targets to execute
> > > > > > >   step : executes tasks in a step-by-step fashion,
> > > > > > > for debugging
> > > > > > >   uninstall: removes the targets installed
> > > > > > >   update   : updates the plugins from the *waflib/extras*
> > > > > > > directory
> > > > > > > 
> > > > > > > waf: error: no such option: --bindir
> > > > > 
> > > > > Hm, eglinfo seems to come with a old waf version, 1.7.8 to be
> > > > > specific.
> > > > > 
> > > > > It seems bindir/libdir got added in 1.8 series:
> > > > > https://github.com/waf-project/waf/blob/waf-1.8/waflib/Option
> > > > > s.py
> > > > > 
> > > > > Make version specific variables?
> > > > 
> > > > That neatly shows where the "clever code" that was breaking
> > > > libdir earlier is:
> > > > 
> > > > https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0a
> > > > b003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237
> > > > 
> > > 
> > > Yeah that seems to be it.
> > > 
> > > That go added in the 1.8.6 dev cycle afaik.
> > > 
> > > I am thinking about adding some kind of version autodetection
> > > 
> > > WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-
> > > 9]*
> > > (.*//};q')
> > > 
> > > if [ $WAFMINOR -gt "7" ] ...
> > > 
> > > Maybe there is a nicer way of doing this?
> > 
> > What about we provide a package waf version and replace the
> > binaries
> > prior building? So we know what version we'd be using. Kinda
> > autoreconf run in autotools class.
> 
> Waf seems to be extensible using wscript. I don't know how exactly
> wscript depends on waf (version) and whether the API is considered
> stable...
> 
> I'd rather prefer not taking chances...

I agree.

Using a "packaged waf" is against one of the philosophies of waf.
Consequently, this is one of the reasons software built with waf has
trouble getting into things like Debian packages. 

Also, from expirence this is probably not a good idea for 2 reasons:
 1) Different versions of waf behave differently and it can cause
strange build issues if you replace the version a package is normally
built and tested with
 2) A project can "prebuild" waf with all the extra tools it wants. If
there was a packaged version of waf it would have to include every tool
possible, which can be imposible if there are custom project tools
which have been prebuilt. I don't know how common it is to include
custom project tools into the prebuilt waf, but it is certainly
possible.

> 
> --
> Stefan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

[OE-core] [PATCH 9/9] gcc-6.4: Fix libgfortran build

[Khem Raj]

From: Ricardo Ribalda Delgado 

Without this patch libbacktrace cannot be included/link during
libgfortran build.

libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
or unhandled argument `../libbacktrace/libbacktrace.la'

Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-6.4.inc  |  1 +
 .../gcc/gcc-6.4/0057-Fix-gfortran-build.patch  | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.4/0057-Fix-gfortran-build.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.4.inc 
b/meta/recipes-devtools/gcc/gcc-6.4.inc
index 03f2bf045d..a191fd70a3 100644
--- a/meta/recipes-devtools/gcc/gcc-6.4.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.4.inc
@@ -76,6 +76,7 @@ SRC_URI = "\
file://0054_all_nopie-all-flags.patch \
file://0055-unwind_h-glibc26.patch \

file://0056-LRA-PR70904-relax-the-restriction-on-subreg-reload-f.patch \
+   file://0057-Fix-gfortran-build.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git a/meta/recipes-devtools/gcc/gcc-6.4/0057-Fix-gfortran-build.patch 
b/meta/recipes-devtools/gcc/gcc-6.4/0057-Fix-gfortran-build.patch
new file mode 100644
index 00..30b135b978
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-6.4/0057-Fix-gfortran-build.patch
@@ -0,0 +1,53 @@
+Without this patch libbacktrace cannot be included/link during
+libgfortran build.
+
+libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
+or unhandled argument `../libbacktrace/libbacktrace.la'
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado 
+
+diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
+index 39d3e11d223c..b5efe6dfe195 100644
+--- a/libgfortran/Makefile.am
 b/libgfortran/Makefile.am
+@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+ libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec 
$(LIBQUADLIB_DEP)
+@@ -63,7 +63,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ # Fortran rules for complex multiplication and division
+ AM_CFLAGS += -fcx-fortran-rules
+diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
+index 7ed080cf7b0d..d197fbd6b683 100644
+--- a/libgfortran/Makefile.in
 b/libgfortran/Makefile.in
+@@ -598,7 +598,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+ 
+@@ -618,7 +618,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ gfor_io_src = io/size_from_kind.c $(am__append_2)
+ gfor_io_headers = \
-- 
2.15.1

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

[OE-core] [PATCH 8/9] gcc-7.2: Fix libgfortran build

[Khem Raj]

From: Ricardo Ribalda Delgado 

Without this patch libbacktrace cannot be included/link during
libgfortran build.

libbtool: link: cannot find the library
`../libbacktrace/libbacktrace.la'
or unhandled argument `../libbacktrace/libbacktrace.la

Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-7.2.inc  |  1 +
 .../gcc/gcc-7.2/0051-Fix-gfortran-build.patch  | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch

diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
b/meta/recipes-devtools/gcc/gcc-7.2.inc
index 1d40cba731..baf98aeba8 100644
--- a/meta/recipes-devtools/gcc/gcc-7.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
@@ -75,6 +75,7 @@ SRC_URI = "\
file://0048-gcc-Enable-static-PIE.patch \
file://fix-segmentation-fault-precompiled-hdr.patch \

file://0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch \
+   file://0051-Fix-gfortran-build.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git a/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch 
b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
new file mode 100644
index 00..a71b6b0bee
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
@@ -0,0 +1,53 @@
+Without this patch libbacktrace cannot be included/link during
+libgfortran build.
+
+libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
+or unhandled argument `../libbacktrace/libbacktrace.la'
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado 
+
+diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
+index 2857af5943f9..e07760069a3c 100644
+--- a/libgfortran/Makefile.am
 b/libgfortran/Makefile.am
+@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   $(HWCAP_LDFLAGS) \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+@@ -64,7 +64,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ # Fortran rules for complex multiplication and division
+ AM_CFLAGS += -fcx-fortran-rules
+diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
+index 05b183dcadb0..c9e0280e412c 100644
+--- a/libgfortran/Makefile.in
 b/libgfortran/Makefile.in
+@@ -581,7 +581,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   $(HWCAP_LDFLAGS) \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+@@ -602,7 +602,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ gfor_io_src = io/size_from_kind.c $(am__append_2)
+ gfor_io_headers = \
-- 
2.15.1

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

[OE-core] [PATCH 7/9] glibc: Upgrade to latest on 2.26 release

[Khem Raj]

For detailed view of changes see
https://github.com/kraj/glibc/compare/glibc-2.26...77f921dac17c5fa99bd9e926d926c327982895f7

drop upstreamed 1 patch

Signed-off-by: Khem Raj 
---
 ...ress-pedantic-warning-caused-by-statement.patch | 90 --
 meta/recipes-core/glibc/glibc_2.26.bb  |  3 +-
 2 files changed, 1 insertion(+), 92 deletions(-)
 delete mode 100644 
meta/recipes-core/glibc/glibc/0026-assert-Suppress-pedantic-warning-caused-by-statement.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0026-assert-Suppress-pedantic-warning-caused-by-statement.patch
 
b/meta/recipes-core/glibc/glibc/0026-assert-Suppress-pedantic-warning-caused-by-statement.patch
deleted file mode 100644
index b2bb96b818..00
--- 
a/meta/recipes-core/glibc/glibc/0026-assert-Suppress-pedantic-warning-caused-by-statement.patch
+++ /dev/null
@@ -1,90 +0,0 @@
-From 037283cbc74739b72f36dfec827d120faa243406 Mon Sep 17 00:00:00 2001
-From: Florian Weimer 
-Date: Thu, 6 Jul 2017 11:50:55 +0200
-Subject: [PATCH 26/26] assert: Suppress pedantic warning caused by statement
- expression [BZ# 21242]
-
-On 07/05/2017 10:15 PM, Zack Weinberg wrote:
-> On Wed, Jul 5, 2017 at 11:51 AM, Florian Weimer  wrote:
->> On 07/05/2017 05:46 PM, Zack Weinberg wrote:
->>> A problem occurs to me: expressions involving VLAs _are_ evaluated
->>> inside sizeof.
->>
->> The type of the sizeof argument would still be int (due to the
->> comparison against 0), so this doesn't actually occur.
->
-> I rechecked what C99 says about sizeof and VLAs, and you're right -
-> the operand of sizeof is only evaluated when sizeof is _directly_
-> applied to a VLA.  So this is indeed safe, but I think this wrinkle
-> should be mentioned in the comment.  Perhaps
->
-> /* The first occurrence of EXPR is not evaluated due to the sizeof,
->but will trigger any pedantic warnings masked by the __extension__
->for the second occurrence.  The explicit comparison against zero
->ensures that sizeof is not directly applied to a function pointer or
->bit-field (which would be ill-formed) or VLA (which would be evaluated).  
*/
->
-> zw
-
-What about the attached patch?
-
-Siddhesh, is this okay during the freeze?  I'd like to backport it to
-2.25 as well.
-
-Thanks,
-Florian
-
-assert: Suppress pedantic warning caused by statement expression
-
-2017-07-06  Florian Weimer  
-
-   [BZ #21242]
-   * assert/assert.h [__GNUC__ && !__STRICT_ANSI__] (assert):
-   Suppress pedantic warning resulting from statement expression.
-   (__ASSERT_FUNCTION): Add missing __extendsion__.

-
-Upstream-Status: Submitted
-Signed-off-by: Khem Raj 
-
- assert/assert.h | 12 +---
- 1 file changed, 9 insertions(+), 3 deletions(-)
-
-diff --git a/assert/assert.h b/assert/assert.h
-index 22f019537c..6801cfeb10 100644
 a/assert/assert.h
-+++ b/assert/assert.h
-@@ -91,13 +91,19 @@ __END_DECLS
-  ? __ASSERT_VOID_CAST (0) \
-  : __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION))
- # else
-+/* The first occurrence of EXPR is not evaluated due to the sizeof,
-+   but will trigger any pedantic warnings masked by the __extension__
-+   for the second occurrence.  The explicit comparison against zero is
-+   required to support function pointers and bit fields in this
-+   context, and to suppress the evaluation of variable length
-+   arrays.  */
- #  define assert(expr)
\
--({
\
-+  ((void) sizeof ((expr) == 0), __extension__ ({  \
-   if (expr)   
\
- ; /* empty */ \
-   else\
- __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION); \
--})
-+}))
- # endif
- 
- # ifdef   __USE_GNU
-@@ -113,7 +119,7 @@ __END_DECLS
-C9x has a similar variable called __func__, but prefer the GCC one since
-it demangles C++ function names.  */
- # if defined __cplusplus ? __GNUC_PREREQ (2, 6) : __GNUC_PREREQ (2, 4)
--#   define __ASSERT_FUNCTION  __PRETTY_FUNCTION__
-+#   define __ASSERT_FUNCTION  __extension__ __PRETTY_FUNCTION__
- # else
- #  if defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
- #   define __ASSERT_FUNCTION  __func__
--- 
-2.13.3
-
diff --git a/meta/recipes-core/glibc/glibc_2.26.bb 
b/meta/recipes-core/glibc/glibc_2.26.bb
index 135ec4fb16..5213a6a942 100644
--- a/meta/recipes-core/glibc/glibc_2.26.bb
+++ b/meta/recipes-core/glibc/glibc_2.26.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \
 
 DEPENDS += "gperf-native"
 
-SRCREV ?= "1c9a5c270d8b66f30dcfaf1cb2d6cf39d3e18369"
+SRCREV ?= 

[OE-core] [PATCH 1/9] binutils: update to 2.29.1

[Khem Raj]

From: Armin Kuster 

update to 2.29.1 to fix the following missing CVEs:

CVE-2017-15939, CVE-2017-15938, CVE-2017-15225, CVE-2017-15025,
CVE-2017-15024, CVE-2017-15023, CVE-2017-15022, CVE-2017-15021,
CVE-2017-15020, CVE-2017-14974, CVE-2017-14940, CVE-2017-14939,
CVE-2017-14938, CVE-2017-14934, CVE-2017-14933, CVE-2017-14932,
CVE-2017-14930, CVE-2017-14745, CVE-2017-14729, CVE-2017-14529,
CVE-2017-14333, CVE-2017-14130, CVE-2017-14129, CVE-2017-14128,
CVE-2017-13757, CVE-2017-13716, CVE-2017-13710, CVE-2017-12967,
CVE-2017-12799, CVE-2017-12459, CVE-2017-12458, CVE-2017-12457,
CVE-2017-12456, CVE-2017-12455, CVE-2017-12454, CVE-2017-12453,
CVE-2017-12452, CVE-2017-12451, CVE-2017-12450, CVE-2017-12449,
CVE-2017-12448

see Changelogs for additional information

Signed-off-by: Armin Kuster 
---
 .../binutils/{binutils-2.29.inc => binutils-2.29.1.inc} | 2 +-
 ...inutils-cross-canadian_2.29.bb => binutils-cross-canadian_2.29.1.bb} | 0
 .../binutils/{binutils-cross_2.29.bb => binutils-cross_2.29.1.bb}   | 0
 .../binutils/{binutils-crosssdk_2.29.bb => binutils-crosssdk_2.29.1.bb} | 0
 meta/recipes-devtools/binutils/{binutils_2.29.bb => binutils_2.29.1.bb} | 0
 5 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/binutils/{binutils-2.29.inc => 
binutils-2.29.1.inc} (97%)
 rename meta/recipes-devtools/binutils/{binutils-cross-canadian_2.29.bb => 
binutils-cross-canadian_2.29.1.bb} (100%)
 rename meta/recipes-devtools/binutils/{binutils-cross_2.29.bb => 
binutils-cross_2.29.1.bb} (100%)
 rename meta/recipes-devtools/binutils/{binutils-crosssdk_2.29.bb => 
binutils-crosssdk_2.29.1.bb} (100%)
 rename meta/recipes-devtools/binutils/{binutils_2.29.bb => binutils_2.29.1.bb} 
(100%)

diff --git a/meta/recipes-devtools/binutils/binutils-2.29.inc 
b/meta/recipes-devtools/binutils/binutils-2.29.1.inc
similarity index 97%
rename from meta/recipes-devtools/binutils/binutils-2.29.inc
rename to meta/recipes-devtools/binutils/binutils-2.29.1.inc
index 27d46eb088..d92bbbce5d 100644
--- a/meta/recipes-devtools/binutils/binutils-2.29.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.29.1.inc
@@ -18,7 +18,7 @@ BINUPV = "${@binutils_branch_version(d)}"
 
 UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
 
-SRCREV = "37e991bb143ca2106330bcdc625590d53838b7a1"
+SRCREV = "90276f15379d380761fc499da2ba24cfb3c12a94"
 SRC_URI = "\
  
git://sourceware.org/git/binutils-gdb.git;branch=binutils-${BINUPV}-branch;protocol=git
 \
  file://0003-configure-widen-the-regexp-for-SH-architectures.patch \
diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian_2.29.bb 
b/meta/recipes-devtools/binutils/binutils-cross-canadian_2.29.1.bb
similarity index 100%
rename from meta/recipes-devtools/binutils/binutils-cross-canadian_2.29.bb
rename to meta/recipes-devtools/binutils/binutils-cross-canadian_2.29.1.bb
diff --git a/meta/recipes-devtools/binutils/binutils-cross_2.29.bb 
b/meta/recipes-devtools/binutils/binutils-cross_2.29.1.bb
similarity index 100%
rename from meta/recipes-devtools/binutils/binutils-cross_2.29.bb
rename to meta/recipes-devtools/binutils/binutils-cross_2.29.1.bb
diff --git a/meta/recipes-devtools/binutils/binutils-crosssdk_2.29.bb 
b/meta/recipes-devtools/binutils/binutils-crosssdk_2.29.1.bb
similarity index 100%
rename from meta/recipes-devtools/binutils/binutils-crosssdk_2.29.bb
rename to meta/recipes-devtools/binutils/binutils-crosssdk_2.29.1.bb
diff --git a/meta/recipes-devtools/binutils/binutils_2.29.bb 
b/meta/recipes-devtools/binutils/binutils_2.29.1.bb
similarity index 100%
rename from meta/recipes-devtools/binutils/binutils_2.29.bb
rename to meta/recipes-devtools/binutils/binutils_2.29.1.bb
-- 
2.15.1

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

[OE-core] [PATCH 6/9] musl: Update to latest

[Khem Raj]

These commits are added
https://git.musl-libc.org/cgit/musl/log/?qt=range=eb03bde2f24582874cb72b56c7811bf51da0c817..4000b0107ddd7fe733fa31d4f078c6fcd35851d6

Key fix for malloc
https://git.musl-libc.org/cgit/musl/commit/?id=a71b46cfd289aa0ff829fc9a436c59c398f8326d

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 932c9a27a0..edfaa07eee 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 = "eb03bde2f24582874cb72b56c7811bf51da0c817"
+SRCREV = "4000b0107ddd7fe733fa31d4f078c6fcd35851d6"
 
 PV = "1.1.18+git${SRCPV}"
 
-- 
2.15.1

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

[OE-core] [PATCH 2/9] binutils: Convert SRC_URI and SRCREV to weak defines

[Khem Raj]

This makes it easy to override them in bbappends

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/binutils/binutils-2.29.1.inc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils-2.29.1.inc 
b/meta/recipes-devtools/binutils/binutils-2.29.1.inc
index d92bbbce5d..07a72e2b5a 100644
--- a/meta/recipes-devtools/binutils/binutils-2.29.1.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.29.1.inc
@@ -18,9 +18,10 @@ BINUPV = "${@binutils_branch_version(d)}"
 
 UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
 
-SRCREV = "90276f15379d380761fc499da2ba24cfb3c12a94"
+SRCREV ?= "90276f15379d380761fc499da2ba24cfb3c12a94"
+BINUTILS_GIT_URI ?= 
"git://sourceware.org/git/binutils-gdb.git;branch=binutils-${BINUPV}-branch;protocol=git"
 SRC_URI = "\
- 
git://sourceware.org/git/binutils-gdb.git;branch=binutils-${BINUPV}-branch;protocol=git
 \
+ ${BINUTILS_GIT_URI} \
  file://0003-configure-widen-the-regexp-for-SH-architectures.patch \
  file://0004-Point-scripts-location-to-libdir.patch \
  file://0005-Only-generate-an-RPATH-entry-if-LD_RUN_PATH-is-not-e.patch \
-- 
2.15.1

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

[OE-core] [PATCH 5/9] musl: Disable thumb1 ISA

[Khem Raj]

From: Andrea Adami 

thumb1 is unsupported see http://www.openwall.com/lists/musl/2017/10/20/10

Fix
[YOCTO #12336]

Signed-off-by: Andrea Adami 
Signed-off-by: Khem Raj 
---
 meta/recipes-core/musl/musl.inc | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-core/musl/musl.inc b/meta/recipes-core/musl/musl.inc
index 56c9d7fe17..9af1172ae0 100644
--- a/meta/recipes-core/musl/musl.inc
+++ b/meta/recipes-core/musl/musl.inc
@@ -26,3 +26,8 @@ INSANE_SKIP_${PN} = "dev-so"
 # Doesn't compile in MIPS16e mode due to use of hand-written
 # assembly
 MIPS_INSTRUCTION_SET = "mips"
+
+# thumb1 is unsupported
+ARM_INSTRUCTION_SET_armv5 = "arm"
+ARM_INSTRUCTION_SET_armv4 = "arm"
+
-- 
2.15.1

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

[OE-core] [PATCH 3/9] gdb: Upgrade to 8.0.1

[Khem Raj]

Minor bugfix release, details are here
https://sourceware.org/ml/gdb-announce/2017/msg4.html

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gdb/{gdb-8.0.inc => gdb-8.0.1.inc}  | 4 ++--
 .../gdb/{gdb-cross-canadian_8.0.bb => gdb-cross-canadian_8.0.1.bb}| 0
 meta/recipes-devtools/gdb/{gdb-cross_8.0.bb => gdb-cross_8.0.1.bb}| 0
 meta/recipes-devtools/gdb/{gdb_8.0.bb => gdb_8.0.1.bb}| 0
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/gdb/{gdb-8.0.inc => gdb-8.0.1.inc} (88%)
 rename meta/recipes-devtools/gdb/{gdb-cross-canadian_8.0.bb => 
gdb-cross-canadian_8.0.1.bb} (100%)
 rename meta/recipes-devtools/gdb/{gdb-cross_8.0.bb => gdb-cross_8.0.1.bb} 
(100%)
 rename meta/recipes-devtools/gdb/{gdb_8.0.bb => gdb_8.0.1.bb} (100%)

diff --git a/meta/recipes-devtools/gdb/gdb-8.0.inc 
b/meta/recipes-devtools/gdb/gdb-8.0.1.inc
similarity index 88%
rename from meta/recipes-devtools/gdb/gdb-8.0.inc
rename to meta/recipes-devtools/gdb/gdb-8.0.1.inc
index fba32ce12c..04a1c809db 100644
--- a/meta/recipes-devtools/gdb/gdb-8.0.inc
+++ b/meta/recipes-devtools/gdb/gdb-8.0.1.inc
@@ -17,6 +17,6 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://0010-resolve-restrict-keyword-conflict.patch \
file://package_devel_gdb_patches_120-sigprocmask-invalid-call.patch 
\
 "
-SRC_URI[md5sum] = "c3d35cd949084be53b92cc1e03485f88"
-SRC_URI[sha256sum] = 
"f6a24ffe4917e67014ef9273eb8b547cb96a13e5ca74895b06d683b391f3f4ee"
+SRC_URI[md5sum] = "48cac527e6f3018b865ece021e9723ac"
+SRC_URI[sha256sum] = 
"3dbd5f93e36ba2815ad0efab030dcd0c7b211d7b353a40a53f4c02d7d56295e3"
 
diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian_8.0.bb 
b/meta/recipes-devtools/gdb/gdb-cross-canadian_8.0.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross-canadian_8.0.bb
rename to meta/recipes-devtools/gdb/gdb-cross-canadian_8.0.1.bb
diff --git a/meta/recipes-devtools/gdb/gdb-cross_8.0.bb 
b/meta/recipes-devtools/gdb/gdb-cross_8.0.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross_8.0.bb
rename to meta/recipes-devtools/gdb/gdb-cross_8.0.1.bb
diff --git a/meta/recipes-devtools/gdb/gdb_8.0.bb 
b/meta/recipes-devtools/gdb/gdb_8.0.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb_8.0.bb
rename to meta/recipes-devtools/gdb/gdb_8.0.1.bb
-- 
2.15.1

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

[OE-core] [PATCH 4/9] gcc6: enable FL_LPAE flag for armv7ve cores

[Khem Raj]

From: Andre McCurdy 

The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
neglected to also add it to the armv7ve compatible cores defined in
arm-cores.def.

  
https://github.com/gcc-mirror/gcc/commit/af2d9b9e58e8be576c53d94f30c48c68146b0c98

The result is that gcc 6.4 now refuses to allow -march=armv7ve and
-mcpu=XXX to be used together, even when -mcpu is set to an armv7ve
compatible core:

  arm-linux-gnueabi-gcc -march=armv7ve -mcpu=cortex-a7 -Werror ...
  error: switch -mcpu=cortex-a7 conflicts with -march=armv7ve switch [-Werror]

Fix by defining flags for armv7ve compatible cores directly from
FL_FOR_ARCH7VE, rather than re-creating the armv7ve flags
independently by combining FL_FOR_ARCH7A with the armv7ve specific
FL_THUMB_DIV and FL_ARM_DIV flags.

Signed-off-by: Andre McCurdy 
Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-6.4.inc  |  1 +
 ...001-enable-FL_LPAE-flag-for-armv7ve-cores.patch | 67 ++
 2 files changed, 68 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.4.inc 
b/meta/recipes-devtools/gcc/gcc-6.4.inc
index 37e996afb7..03f2bf045d 100644
--- a/meta/recipes-devtools/gcc/gcc-6.4.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.4.inc
@@ -81,6 +81,7 @@ SRC_URI = "\
 BACKPORTS = "\
file://CVE-2016-6131.patch \

file://0057-ARM-PR-82445-suppress-32-bit-aligned-ldrd-strd-peeph.patch \
+   file://0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch \
 "
 SRC_URI[md5sum] = "11ba51a0cfb8471927f387c8895fe232"
 SRC_URI[sha256sum] = 
"850bf21eafdfe5cd5f6827148184c08c4a0852a37ccf36ce69855334d2c914d4"
diff --git 
a/meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
 
b/meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
new file mode 100644
index 00..3f664c5885
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
@@ -0,0 +1,67 @@
+From 22fcc126fad61a8e9ddaaabbc8036644273642dc Mon Sep 17 00:00:00 2001
+From: ktkachov 
+Date: Thu, 9 Nov 2017 14:34:28 +
+Subject: [PATCH] enable FL_LPAE flag for armv7ve cores
+
+The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
+neglected to also add it to the armv7ve compatible cores defined in
+arm-cores.def.
+
+  
https://github.com/gcc-mirror/gcc/commit/af2d9b9e58e8be576c53d94f30c48c68146b0c98
+
+The result is that gcc 6.4 now refuses to allow -march=armv7ve and
+-mcpu=XXX to be used together, even when -mcpu is set to an armv7ve
+compatible core:
+
+  arm-linux-gnueabi-gcc -march=armv7ve -mcpu=cortex-a7 -Werror ...
+  error: switch -mcpu=cortex-a7 conflicts with -march=armv7ve switch [-Werror]
+
+Fix by defining flags for armv7ve compatible cores directly from
+FL_FOR_ARCH7VE, rather than re-creating the armv7ve flags
+independently by combining FL_FOR_ARCH7A with the armv7ve specific
+FL_THUMB_DIV and FL_ARM_DIV flags.
+
+Upstream-Status: Backport
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch@254584 
138bc75d-0d04-0410-961f-82ee72b054a4
+
+Signed-off-by: Andre McCurdy 
+---
+ gcc/config/arm/arm-cores.def | 12 ++--
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
+index 829b839..ca37e6f 100644
+--- a/gcc/config/arm/arm-cores.def
 b/gcc/config/arm/arm-cores.def
+@@ -145,12 +145,12 @@ 
ARM_CORE("cortex-m0plus.small-multiply",cortexm0plussmallmultiply, cortexm0plus,
+ /* V7 Architecture Processors */
+ ARM_CORE("generic-armv7-a",   genericv7a, genericv7a, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex)
+ ARM_CORE("cortex-a5", cortexa5, cortexa5, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex_a5)
+-ARM_CORE("cortex-a7", cortexa7, cortexa7, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a7)
++ARM_CORE("cortex-a7", cortexa7, cortexa7, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7VE), cortex_a7)
+ ARM_CORE("cortex-a8", cortexa8, cortexa8, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex_a8)
+ ARM_CORE("cortex-a9", cortexa9, cortexa9, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex_a9)
+-ARM_CORE("cortex-a12",cortexa12, cortexa17,   7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a12)
+-ARM_CORE("cortex-a15",cortexa15, cortexa15,   7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a15)

Re: [OE-core] [PATCH] musl: use arm instruction set for armv4 and armv5

[Khem Raj]

On Tue, Dec 12, 2017 at 9:15 AM, Burton, Ross  wrote:
> Just to make it clear I'm waiting on Andrea or Khem to ping the right patch.
>

I will resend them today

> Ross
>
> On 12 December 2017 at 15:23, Andrea Adami  wrote:
>>
>> Hello,
>>
>> musl 1.18 recipe is still failing.
>> Please apply one of the a.m. patches, thanks
>>
>> Andrea
>>
>> On Wed, Nov 15, 2017 at 4:37 AM, Khem Raj  wrote:
>> > On Tue, Nov 14, 2017 at 1:44 PM, Andrea Adami 
>> > wrote:
>> >> thumb1 is not supported with musl.
>> >>
>> >> Fixes: [YOCTO #12336]
>> >>
>> >> Signed-off-by: Andrea Adami 
>> >> ---
>> >>  meta/recipes-core/musl/musl.inc | 4 
>> >>  1 file changed, 4 insertions(+)
>> >>
>> >> diff --git a/meta/recipes-core/musl/musl.inc
>> >> b/meta/recipes-core/musl/musl.inc
>> >> index 56c9d7f..b4b0de9 100644
>> >> --- a/meta/recipes-core/musl/musl.inc
>> >> +++ b/meta/recipes-core/musl/musl.inc
>> >> @@ -26,3 +26,7 @@ INSANE_SKIP_${PN} = "dev-so"
>> >>  # Doesn't compile in MIPS16e mode due to use of hand-written
>> >>  # assembly
>> >>  MIPS_INSTRUCTION_SET = "mips"
>> >> +
>> >> +# Doesn't support thumb1
>> >> +ARM_INSTRUCTION_SET_armv4 = "arm"
>> >> +ARM_INSTRUCTION_SET_armv5 = "arm"
>> >
>> > Ah I submitted a parallel fix that was sitting on my branch.
>> > is that fine ?
>> >
>> >> --
>> >> 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
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] musl: use arm instruction set for armv4 and armv5

[Khem Raj]

They have been proposed some time back. I dont know if they fell through cracks.

On Tue, Dec 12, 2017 at 7:23 AM, Andrea Adami  wrote:
> Hello,
>
> musl 1.18 recipe is still failing.
> Please apply one of the a.m. patches, thanks
>
> Andrea
>
> On Wed, Nov 15, 2017 at 4:37 AM, Khem Raj  wrote:
>> On Tue, Nov 14, 2017 at 1:44 PM, Andrea Adami  wrote:
>>> thumb1 is not supported with musl.
>>>
>>> Fixes: [YOCTO #12336]
>>>
>>> Signed-off-by: Andrea Adami 
>>> ---
>>>  meta/recipes-core/musl/musl.inc | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/meta/recipes-core/musl/musl.inc 
>>> b/meta/recipes-core/musl/musl.inc
>>> index 56c9d7f..b4b0de9 100644
>>> --- a/meta/recipes-core/musl/musl.inc
>>> +++ b/meta/recipes-core/musl/musl.inc
>>> @@ -26,3 +26,7 @@ INSANE_SKIP_${PN} = "dev-so"
>>>  # Doesn't compile in MIPS16e mode due to use of hand-written
>>>  # assembly
>>>  MIPS_INSTRUCTION_SET = "mips"
>>> +
>>> +# Doesn't support thumb1
>>> +ARM_INSTRUCTION_SET_armv4 = "arm"
>>> +ARM_INSTRUCTION_SET_armv5 = "arm"
>>
>> Ah I submitted a parallel fix that was sitting on my branch.
>> is that fine ?
>>
>>> --
>>> 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] musl: use arm instruction set for armv4 and armv5

[Burton, Ross]

Just to make it clear I'm waiting on Andrea or Khem to ping the right patch.

Ross

On 12 December 2017 at 15:23, Andrea Adami  wrote:

> Hello,
>
> musl 1.18 recipe is still failing.
> Please apply one of the a.m. patches, thanks
>
> Andrea
>
> On Wed, Nov 15, 2017 at 4:37 AM, Khem Raj  wrote:
> > On Tue, Nov 14, 2017 at 1:44 PM, Andrea Adami 
> wrote:
> >> thumb1 is not supported with musl.
> >>
> >> Fixes: [YOCTO #12336]
> >>
> >> Signed-off-by: Andrea Adami 
> >> ---
> >>  meta/recipes-core/musl/musl.inc | 4 
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/meta/recipes-core/musl/musl.inc
> b/meta/recipes-core/musl/musl.inc
> >> index 56c9d7f..b4b0de9 100644
> >> --- a/meta/recipes-core/musl/musl.inc
> >> +++ b/meta/recipes-core/musl/musl.inc
> >> @@ -26,3 +26,7 @@ INSANE_SKIP_${PN} = "dev-so"
> >>  # Doesn't compile in MIPS16e mode due to use of hand-written
> >>  # assembly
> >>  MIPS_INSTRUCTION_SET = "mips"
> >> +
> >> +# Doesn't support thumb1
> >> +ARM_INSTRUCTION_SET_armv4 = "arm"
> >> +ARM_INSTRUCTION_SET_armv5 = "arm"
> >
> > Ah I submitted a parallel fix that was sitting on my branch.
> > is that fine ?
> >
> >> --
> >> 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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv3] recipes-multimedia/gstreamer: Add gst-validate recipe

[Aníbal Limón]

From: Aníbal Limón 

The gst-validate is a tool to run integration tests of Gstreamer
components [1].

This tool can be used along with gst-integration-testsuites (scenarios
and media) [2] to test Gstreamer components on the target device.

An example of test using gst-integration-testsuites:

$ gst-validate-launcher --sync # get [2] uses git and git-annex
$ gst-validate-launcher

or

$ gst-validate-launcher -nd # needs xserver-xorg-xvfb to run wo DISPLAY

[1]
https://blogs.gnome.org/tsaunier/2014/04/21/gst-validate-a-suite-of-tools-to-run-integration-tests-for-gstreamer-2/
[2] https://cgit.freedesktop.org/gstreamer/gst-integration-testsuites

Signed-off-by: Aníbal Limón 
---
 .../gstreamer/gst-validate_1.12.3.bb   | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb

diff --git a/meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb 
b/meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb
new file mode 100644
index 00..8f5437641f
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb
@@ -0,0 +1,18 @@
+SUMMARY = "Gstreamer validation tool"
+DESCRIPTION = "A Tool to test GStreamer components"
+HOMEPAGE = 
"https://gstreamer.freedesktop.org/releases/gst-validate/1.12.3.html;
+SECTION = "multimedia"
+
+LICENSE = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"
+
+SRC_URI = "https://gstreamer.freedesktop.org/src/${BPN}/${BP}.tar.xz;
+SRC_URI[md5sum] = "623edc479a1e5c1e76bd7e1cf8393253"
+SRC_URI[sha256sum] = 
"5139949d20274fdd702492438eeab2c9e55aa82f60aca17db27ebd3faf08489e"
+
+DEPENDS = "json-glib glib-2.0 gstreamer1.0 gstreamer1.0-plugins-base"
+RRECOMMENDS_${PN} = "git"
+
+FILES_${PN} += "${datadir}/gstreamer-1.0/* ${libdir}/gst-validate-launcher/* 
${libdir}/gstreamer-1.0/*"
+
+inherit pkgconfig gettext autotools gobject-introspection gtk-doc
-- 
2.11.0

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

[OE-core] [PATCHv3] recipes-multimedia/gstreamer: Add gst-validate recipe

[Aníbal Limón]

From: Aníbal Limón 

The gst-validate is a tool to run integration tests of Gstreamer
components [1].

This tool can be used along with gst-integration-testsuites (scenarios
and media) [2] to test Gstreamer components on the target device.

An example of test using gst-integration-testsuites:

$ gst-validate-launcher --sync # get [2] uses git and git-annex
$ gst-validate-launcher

or

$ gst-validate-launcher -nd # needs xserver-xorg-xvfb to run wo DISPLAY

[1]
https://blogs.gnome.org/tsaunier/2014/04/21/gst-validate-a-suite-of-tools-to-run-integration-tests-for-gstreamer-2/
[2] https://cgit.freedesktop.org/gstreamer/gst-integration-testsuites

Signed-off-by: Aníbal Limón 
---
 .../gstreamer/gst-validate_1.12.3.bb   | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb

diff --git a/meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb 
b/meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb
new file mode 100644
index 00..8f5437641f
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gst-validate_1.12.3.bb
@@ -0,0 +1,18 @@
+SUMMARY = "Gstreamer validation tool"
+DESCRIPTION = "A Tool to test GStreamer components"
+HOMEPAGE = 
"https://gstreamer.freedesktop.org/releases/gst-validate/1.12.3.html;
+SECTION = "multimedia"
+
+LICENSE = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"
+
+SRC_URI = "https://gstreamer.freedesktop.org/src/${BPN}/${BP}.tar.xz;
+SRC_URI[md5sum] = "623edc479a1e5c1e76bd7e1cf8393253"
+SRC_URI[sha256sum] = 
"5139949d20274fdd702492438eeab2c9e55aa82f60aca17db27ebd3faf08489e"
+
+DEPENDS = "json-glib glib-2.0 gstreamer1.0 gstreamer1.0-plugins-base"
+RRECOMMENDS_${PN} = "git"
+
+FILES_${PN} += "${datadir}/gstreamer-1.0/* ${libdir}/gst-validate-launcher/* 
${libdir}/gstreamer-1.0/*"
+
+inherit pkgconfig gettext autotools gobject-introspection gtk-doc
-- 
2.11.0

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

Re: [OE-core] [PATCHv2] recipes-multimedia/gstreamer: Add gst-validate recipe

[Otavio Salvador]

On Tue, Dec 12, 2017 at 1:51 PM, Anibal Limon  wrote:
>
>
> On 12 December 2017 at 06:50, Otavio Salvador
>  wrote:
>>
>> On Tue, Dec 12, 2017 at 10:23 AM, Burton, Ross 
>> wrote:
>> > On 6 December 2017 at 22:00, Aníbal Limón 
>> > wrote:
>> >>
>> >> +SRC_URI =
>> >> "https://gstreamer.freedesktop.org/src/${PN}/${PN}-${PV}.tar.xz;
>> >
>> >
>> > ERROR: lib32-gst-validate-1.12.3-r0 do_fetch: Fetcher failure for URL:
>> >
>> > 'https://gstreamer.freedesktop.org/src/lib32-gst-validate/lib32-gst-validate-1.12.3.tar.xz'.
>> > Unable to fetch URL from any source.
>> >
>> > You need to use BPN not PN, but use ${BP} instead of of BPN-PV.
>>
>> Also, it should rdepends on git and git-annex no?
>
>
>
> Yes, i can add the git dependency but git-annex depends on haskell that we
> don't have a recipe to build.
>
> You can copy/populate the gst-integration-testsuites from other source or
> create/use other test suites.

Would be possible to populate a package? so we'd depend on git-annex
on host for it?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] waf.bbclass: explicitly pass bindir and libdir if supported

[Otavio Salvador]

On Tue, Dec 12, 2017 at 2:13 PM, Stefan Agner  wrote:
> From: Stefan Agner 
>
> On some build hosts distros (e.g. Fedora 26) waf tries to be
> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
> This obviously is not what we want for 32-bit targets and usually
> fails in the do_package phase:
>   WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in 
> any package:
> /usr/lib64/libgstimxcommon.so.0
> ...
>
> Depending on version, waf knows prefix or prefix, bindir and
> libdir as default options. Explicitly pass the right set of
> arguments.
>
> Signed-off-by: Stefan Agner 

I think it is the best we can do for now. Anything fancier than this
is risky and would not be possible to be backported.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3] waf.bbclass: explicitly pass bindir and libdir if supported

[Stefan Agner]

From: Stefan Agner 

On some build hosts distros (e.g. Fedora 26) waf tries to be
smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
This obviously is not what we want for 32-bit targets and usually
fails in the do_package phase:
  WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in 
any package:
/usr/lib64/libgstimxcommon.so.0
...

Depending on version, waf knows prefix or prefix, bindir and
libdir as default options. Explicitly pass the right set of
arguments.

Signed-off-by: Stefan Agner 
---
 meta/classes/waf.bbclass | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/meta/classes/waf.bbclass b/meta/classes/waf.bbclass
index c4698e910a..acbda278a2 100644
--- a/meta/classes/waf.bbclass
+++ b/meta/classes/waf.bbclass
@@ -25,8 +25,23 @@ def get_waf_parallel_make(d):
 
 return ""
 
+python waf_preconfigure() {
+from distutils.version import StrictVersion
+srcsubdir = d.getVar('S')
+wafbin = os.path.join(srcsubdir, 'waf')
+status, result = oe.utils.getstatusoutput(wafbin + " --version")
+if status != 0:
+bb.warn("Unable to execute waf --version, exit code %d. Assuming waf 
version without bindir/libdir support." % status)
+return
+version = result.split()[1]
+if StrictVersion(version) >= StrictVersion("1.8.7"):
+d.setVar("WAF_EXTRA_CONF", "--bindir=${bindir} --libdir=${libdir}")
+}
+
+do_configure[prefuncs] += "waf_preconfigure"
+
 waf_do_configure() {
-   ${S}/waf configure --prefix=${prefix} ${EXTRA_OECONF}
+   ${S}/waf configure --prefix=${prefix} ${WAF_EXTRA_CONF} ${EXTRA_OECONF}
 }
 
 waf_do_compile()  {
-- 
2.13.6

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

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Stefan Agner]

On 2017-12-12 17:04, Vincent Prince wrote:

> As waf_do_configure takes care of EXTRA_OECONF, maybe we can only fix 
> gstreamer1.0-plugins-imx_0.13.0.bb by adding libdir ?  
> It is much a bug fix than a longterm solution, but if any waf version breaks 
> options, it can be a nightmare to handle... 

For me, that definitly would work too.

But then, since all version of waf > 1.8.6 seem to use this
autodetection it is quite likely that other packages fail/will fail.

I am about to send a v3 with version detection, lets see if we can agree
on such a solution (and backport it to rocko).

--
Stefan


> 
> 2017-12-12 16:56 GMT+01:00 Stefan Agner :
> 
>> On 2017-12-12 16:47, Otavio Salvador wrote:
>>> On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner  wrote:
 On 2017-12-12 15:13, Burton, Ross wrote:
 
> On 12 December 2017 at 14:03, Stefan Agner  wrote:
> 
>> On 2017-12-12 15:00, Burton, Ross wrote:
>> 
>>> On 12 December 2017 at 13:27, Stefan Agner  wrote:
>>> 
 On some build hosts distros (e.g. Fedora 26) waf tries to be
 smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
 This obviously is not what we want for 32-bit targets and usually
 fails in the do_package phase:
 WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
 gstreamer1.0-plugins-imx: Files/directories were installed but not 
 shipped in any package:
 /usr/lib64/libgstimxcommon.so.0
 
 Waf knows prefix, bindir and libdir as default options. Explicitly
 pass those three.
>>> 
>>> Obviously not.
>>> 
>>> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure 
>>> (log file is located at 
>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
>>> ERROR: Logfile of failure stored in: 
>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
>>> Log data follows:
>>> | DEBUG: Executing shell function do_configure
>>> | waf [commands] [options]
>>> |
>>> | Main commands (example: ./waf build -j4)
>>> |   build: executes the build
>>> |   clean: cleans the project
>>> |   configure: configures the project
>>> |   dist : makes a tarball for redistributing the sources
>>> |   distcheck: checks if the project compiles (tarball from 'dist')
>>> |   distclean: removes the build directory
>>> |   install  : installs the targets on the system
>>> |   list : lists the targets to execute
>>> |   step : executes tasks in a step-by-step fashion, for debugging
>>> |   uninstall: removes the targets installed
>>> |   update   : updates the plugins from the *waflib/extras* directory
>>> |
>>> | waf: error: no such option: --bindir
>>> 
>> Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific.
>> 
>> It seems bindir/libdir got added in 1.8 series:
>> https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py
>> 
>> Make version specific variables?
> 
> That neatly shows where the "clever code" that was breaking libdir 
> earlier is:
> 
> https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0ab003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237
> 
 
 Yeah that seems to be it.
 
 That go added in the 1.8.6 dev cycle afaik.
 
 I am thinking about adding some kind of version autodetection
 
 WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-9]*
 (.*//};q')
 
 if [ $WAFMINOR -gt "7" ] ...
 
 Maybe there is a nicer way of doing this?
>>> 
>>> What about we provide a package waf version and replace the binaries
>>> prior building? So we know what version we'd be using. Kinda
>>> autoreconf run in autotools class.
>> Waf seems to be extensible using wscript. I don't know how exactly
>> wscript depends on waf (version) and whether the API is considered
>> stable...
>> 
>> I'd rather prefer not taking chances...
>> 
>> --
>> Stefan
>> 
>> --
>> ___
>> 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] waf.bbclass: explicitly pass bindir and libdir

[Vincent Prince]

As waf_do_configure takes care of EXTRA_OECONF, maybe we can only fix
gstreamer1.0-plugins-imx_0.13.0.bb by adding libdir ?
It is much a bug fix than a longterm solution, but if any waf version
breaks options, it can be a nightmare to handle...

2017-12-12 16:56 GMT+01:00 Stefan Agner :

> On 2017-12-12 16:47, Otavio Salvador wrote:
> > On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner  wrote:
> >> On 2017-12-12 15:13, Burton, Ross wrote:
> >>
> >>> On 12 December 2017 at 14:03, Stefan Agner  wrote:
> >>>
>  On 2017-12-12 15:00, Burton, Ross wrote:
> 
> > On 12 December 2017 at 13:27, Stefan Agner  wrote:
> >
> >> On some build hosts distros (e.g. Fedora 26) waf tries to be
> >> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
> >> This obviously is not what we want for 32-bit targets and usually
> >> fails in the do_package phase:
> >> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped
> in any package:
> >> /usr/lib64/libgstimxcommon.so.0
> >>
> >> Waf knows prefix, bindir and libdir as default options. Explicitly
> >> pass those three.
> >
> > Obviously not.
> >
> > ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed:
> do_configure (log file is located at /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.
> do_configure.17278)
> > ERROR: Logfile of failure stored in: /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
> > Log data follows:
> > | DEBUG: Executing shell function do_configure
> > | waf [commands] [options]
> > |
> > | Main commands (example: ./waf build -j4)
> > |   build: executes the build
> > |   clean: cleans the project
> > |   configure: configures the project
> > |   dist : makes a tarball for redistributing the sources
> > |   distcheck: checks if the project compiles (tarball from 'dist')
> > |   distclean: removes the build directory
> > |   install  : installs the targets on the system
> > |   list : lists the targets to execute
> > |   step : executes tasks in a step-by-step fashion, for
> debugging
> > |   uninstall: removes the targets installed
> > |   update   : updates the plugins from the *waflib/extras* directory
> > |
> > | waf: error: no such option: --bindir
> >
>  Hm, eglinfo seems to come with a old waf version, 1.7.8 to be
> specific.
> 
>  It seems bindir/libdir got added in 1.8 series:
>  https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py
> 
>  Make version specific variables?
> >>>
> >>> That neatly shows where the "clever code" that was breaking libdir
> earlier is:
> >>>
> >>> https://github.com/waf-project/waf/commit/
> 823b4cd2dc03d06a81e0ab003606067da03d8745#diff-
> b44b0c8f383b2fd1b19f2ba039d30237
> >>>
> >>
> >> Yeah that seems to be it.
> >>
> >> That go added in the 1.8.6 dev cycle afaik.
> >>
> >> I am thinking about adding some kind of version autodetection
> >>
> >> WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-9]*
> >> (.*//};q')
> >>
> >> if [ $WAFMINOR -gt "7" ] ...
> >>
> >> Maybe there is a nicer way of doing this?
> >
> > What about we provide a package waf version and replace the binaries
> > prior building? So we know what version we'd be using. Kinda
> > autoreconf run in autotools class.
>
> Waf seems to be extensible using wscript. I don't know how exactly
> wscript depends on waf (version) and whether the API is considered
> stable...
>
> I'd rather prefer not taking chances...
>
> --
> Stefan
> --
> ___
> 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] waf.bbclass: explicitly pass bindir and libdir

[Stefan Agner]

On 2017-12-12 16:47, Otavio Salvador wrote:
> On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner  wrote:
>> On 2017-12-12 15:13, Burton, Ross wrote:
>>
>>> On 12 December 2017 at 14:03, Stefan Agner  wrote:
>>>
 On 2017-12-12 15:00, Burton, Ross wrote:

> On 12 December 2017 at 13:27, Stefan Agner  wrote:
>
>> On some build hosts distros (e.g. Fedora 26) waf tries to be
>> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
>> This obviously is not what we want for 32-bit targets and usually
>> fails in the do_package phase:
>> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
>> gstreamer1.0-plugins-imx: Files/directories were installed but not 
>> shipped in any package:
>> /usr/lib64/libgstimxcommon.so.0
>>
>> Waf knows prefix, bindir and libdir as default options. Explicitly
>> pass those three.
>
> Obviously not.
>
> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure 
> (log file is located at 
> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
> ERROR: Logfile of failure stored in: 
> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
> Log data follows:
> | DEBUG: Executing shell function do_configure
> | waf [commands] [options]
> |
> | Main commands (example: ./waf build -j4)
> |   build: executes the build
> |   clean: cleans the project
> |   configure: configures the project
> |   dist : makes a tarball for redistributing the sources
> |   distcheck: checks if the project compiles (tarball from 'dist')
> |   distclean: removes the build directory
> |   install  : installs the targets on the system
> |   list : lists the targets to execute
> |   step : executes tasks in a step-by-step fashion, for debugging
> |   uninstall: removes the targets installed
> |   update   : updates the plugins from the *waflib/extras* directory
> |
> | waf: error: no such option: --bindir
>
 Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific.

 It seems bindir/libdir got added in 1.8 series:
 https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py

 Make version specific variables?
>>>
>>> That neatly shows where the "clever code" that was breaking libdir earlier 
>>> is:
>>>
>>> https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0ab003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237
>>>
>>
>> Yeah that seems to be it.
>>
>> That go added in the 1.8.6 dev cycle afaik.
>>
>> I am thinking about adding some kind of version autodetection
>>
>> WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-9]*
>> (.*//};q')
>>
>> if [ $WAFMINOR -gt "7" ] ...
>>
>> Maybe there is a nicer way of doing this?
> 
> What about we provide a package waf version and replace the binaries
> prior building? So we know what version we'd be using. Kinda
> autoreconf run in autotools class.

Waf seems to be extensible using wscript. I don't know how exactly
wscript depends on waf (version) and whether the API is considered
stable...

I'd rather prefer not taking chances...

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

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Otavio Salvador]

On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner  wrote:
> On 2017-12-12 15:13, Burton, Ross wrote:
>
>> On 12 December 2017 at 14:03, Stefan Agner  wrote:
>>
>>> On 2017-12-12 15:00, Burton, Ross wrote:
>>>
 On 12 December 2017 at 13:27, Stefan Agner  wrote:

> On some build hosts distros (e.g. Fedora 26) waf tries to be
> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
> This obviously is not what we want for 32-bit targets and usually
> fails in the do_package phase:
> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
> gstreamer1.0-plugins-imx: Files/directories were installed but not 
> shipped in any package:
> /usr/lib64/libgstimxcommon.so.0
>
> Waf knows prefix, bindir and libdir as default options. Explicitly
> pass those three.

 Obviously not.

 ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure 
 (log file is located at 
 /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
 ERROR: Logfile of failure stored in: 
 /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
 Log data follows:
 | DEBUG: Executing shell function do_configure
 | waf [commands] [options]
 |
 | Main commands (example: ./waf build -j4)
 |   build: executes the build
 |   clean: cleans the project
 |   configure: configures the project
 |   dist : makes a tarball for redistributing the sources
 |   distcheck: checks if the project compiles (tarball from 'dist')
 |   distclean: removes the build directory
 |   install  : installs the targets on the system
 |   list : lists the targets to execute
 |   step : executes tasks in a step-by-step fashion, for debugging
 |   uninstall: removes the targets installed
 |   update   : updates the plugins from the *waflib/extras* directory
 |
 | waf: error: no such option: --bindir

>>> Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific.
>>>
>>> It seems bindir/libdir got added in 1.8 series:
>>> https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py
>>>
>>> Make version specific variables?
>>
>> That neatly shows where the "clever code" that was breaking libdir earlier 
>> is:
>>
>> https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0ab003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237
>>
>
> Yeah that seems to be it.
>
> That go added in the 1.8.6 dev cycle afaik.
>
> I am thinking about adding some kind of version autodetection
>
> WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-9]*
> (.*//};q')
>
> if [ $WAFMINOR -gt "7" ] ...
>
> Maybe there is a nicer way of doing this?

What about we provide a package waf version and replace the binaries
prior building? So we know what version we'd be using. Kinda
autoreconf run in autotools class.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ptest-runner: Upgrade to 2.1.1

[Aníbal Limón]

From: Aníbal Limón 

Contains fixes,

- timeout option missing the argument option ":" to getopt
- utils.c: Prefer monotonic clock to calculate elapsed time
- Add support to avoid load/run twice a run_ptest script

Signed-off-by: Aníbal Limón 
---
 .../ptest-runner/{ptest-runner_2.1.bb => ptest-runner_2.1.1.bb}   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/ptest-runner/{ptest-runner_2.1.bb => 
ptest-runner_2.1.1.bb} (89%)

diff --git a/meta/recipes-support/ptest-runner/ptest-runner_2.1.bb 
b/meta/recipes-support/ptest-runner/ptest-runner_2.1.1.bb
similarity index 89%
rename from meta/recipes-support/ptest-runner/ptest-runner_2.1.bb
rename to meta/recipes-support/ptest-runner/ptest-runner_2.1.1.bb
index 71c1dabee4..e5b71c0f01 100644
--- a/meta/recipes-support/ptest-runner/ptest-runner_2.1.bb
+++ b/meta/recipes-support/ptest-runner/ptest-runner_2.1.1.bb
@@ -7,8 +7,8 @@ HOMEPAGE = 
"http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/about/;
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"
 
-SRCREV = "8a93832dad621535e90aa8e1fb74ae5ba743fc3e"
-PV = "2.1+git${SRCPV}"
+SRCREV = "16413d71cc06b02a6d859c35a017cc49b88283f7"
+PV = "2.1.1+git${SRCPV}"
 
 SRC_URI = "git://git.yoctoproject.org/ptest-runner2"
 S = "${WORKDIR}/git"
-- 
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: use arm instruction set for armv4 and armv5

[Andrea Adami]

Hello,

musl 1.18 recipe is still failing.
Please apply one of the a.m. patches, thanks

Andrea

On Wed, Nov 15, 2017 at 4:37 AM, Khem Raj  wrote:
> On Tue, Nov 14, 2017 at 1:44 PM, Andrea Adami  wrote:
>> thumb1 is not supported with musl.
>>
>> Fixes: [YOCTO #12336]
>>
>> Signed-off-by: Andrea Adami 
>> ---
>>  meta/recipes-core/musl/musl.inc | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/meta/recipes-core/musl/musl.inc 
>> b/meta/recipes-core/musl/musl.inc
>> index 56c9d7f..b4b0de9 100644
>> --- a/meta/recipes-core/musl/musl.inc
>> +++ b/meta/recipes-core/musl/musl.inc
>> @@ -26,3 +26,7 @@ INSANE_SKIP_${PN} = "dev-so"
>>  # Doesn't compile in MIPS16e mode due to use of hand-written
>>  # assembly
>>  MIPS_INSTRUCTION_SET = "mips"
>> +
>> +# Doesn't support thumb1
>> +ARM_INSTRUCTION_SET_armv4 = "arm"
>> +ARM_INSTRUCTION_SET_armv5 = "arm"
>
> Ah I submitted a parallel fix that was sitting on my branch.
> is that fine ?
>
>> --
>> 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] kernel-devsrc: Use full mrproper to clean

[Saul Wold]

On Tue, 2017-12-12 at 11:57 +, Burton, Ross wrote:
> This breaks some of the sanity tests, which build a kernel module:
> 
> https://autobuilder.yocto.io/builders/nightly-x86-64/builds/664
> 
Interesting, I did a local build of a kernel module as well as a full
build of the kernel with out failure, I will investigate the oe-
selftest failure.

Sau!

> Ross
> 
> On 5 December 2017 at 23:00, Saul Wold  wrote:
> > By using the full mrproper clean target it also removes some
> > generated files
> > that are not required on the target to build. It also helps to fix
> > reprodudible
> > builds as the generated files could have different permissions
> > causing the
> > check to fail.
> > 
> > Tested with building and booting kernel from source on the target
> > 
> > [YOCTO #12137]
> > 
> > Signed-off-by: Saul Wold 
> > ---
> >  meta/recipes-kernel/linux/kernel-devsrc.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > b/meta/recipes-kernel/linux/kernel-devsrc.bb
> > index c1b5b7786d7..d925a33aeb1 100644
> > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> > @@ -52,7 +52,7 @@ do_install() {
> >  # The main build artifacts. We clean the directory to
> > avoid QA errors on mismatched
> >  # architecture (since scripts and helpers are native
> > format).
> >  KBUILD_OUTPUT="$kerneldir"
> > -oe_runmake -C $kerneldir CC="${KERNEL_CC}"
> > LD="${KERNEL_LD}" clean _mrproper_scripts
> > +oe_runmake -C $kerneldir CC="${KERNEL_CC}"
> > LD="${KERNEL_LD}" clean mrproper
> >  # make clean generates an absolute path symlink called
> > "source"
> >  # in $kerneldir points to $kerneldir, which doesn't make
> > any
> >  # sense, so remove it.
> > --
> > 2.13.6
> > 
> > --
> > ___
> > 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] waf.bbclass: explicitly pass bindir and libdir

[Stefan Agner]

On 2017-12-12 15:13, Burton, Ross wrote:

> On 12 December 2017 at 14:03, Stefan Agner  wrote:
> 
>> On 2017-12-12 15:00, Burton, Ross wrote:
>> 
>>> On 12 December 2017 at 13:27, Stefan Agner  wrote:
>>> 
 On some build hosts distros (e.g. Fedora 26) waf tries to be
 smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
 This obviously is not what we want for 32-bit targets and usually
 fails in the do_package phase:
 WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
 gstreamer1.0-plugins-imx: Files/directories were installed but not shipped 
 in any package:
 /usr/lib64/libgstimxcommon.so.0
 
 Waf knows prefix, bindir and libdir as default options. Explicitly
 pass those three.
>>> 
>>> Obviously not.
>>> 
>>> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure 
>>> (log file is located at 
>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
>>> ERROR: Logfile of failure stored in: 
>>> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
>>> Log data follows:
>>> | DEBUG: Executing shell function do_configure
>>> | waf [commands] [options]
>>> |
>>> | Main commands (example: ./waf build -j4)
>>> |   build: executes the build
>>> |   clean: cleans the project
>>> |   configure: configures the project
>>> |   dist : makes a tarball for redistributing the sources
>>> |   distcheck: checks if the project compiles (tarball from 'dist')
>>> |   distclean: removes the build directory
>>> |   install  : installs the targets on the system
>>> |   list : lists the targets to execute
>>> |   step : executes tasks in a step-by-step fashion, for debugging
>>> |   uninstall: removes the targets installed
>>> |   update   : updates the plugins from the *waflib/extras* directory
>>> |
>>> | waf: error: no such option: --bindir
>>> 
>> Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific.
>> 
>> It seems bindir/libdir got added in 1.8 series:
>> https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py
>> 
>> Make version specific variables?
> 
> That neatly shows where the "clever code" that was breaking libdir earlier 
> is: 
> 
> https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0ab003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237
>  
> 

Yeah that seems to be it.

That go added in the 1.8.6 dev cycle afaik.

I am thinking about adding some kind of version autodetection

WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-9]*
(.*//};q')

if [ $WAFMINOR -gt "7" ] ...

Maybe there is a nicer way of doing this?

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

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Burton, Ross]

On 12 December 2017 at 14:03, Stefan Agner  wrote:

> On 2017-12-12 15:00, Burton, Ross wrote:
>
> > On 12 December 2017 at 13:27, Stefan Agner  wrote:
> >
> >> On some build hosts distros (e.g. Fedora 26) waf tries to be
> >> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
> >> This obviously is not what we want for 32-bit targets and usually
> >> fails in the do_package phase:
> >> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped
> in any package:
> >> /usr/lib64/libgstimxcommon.so.0
> >>
> >> Waf knows prefix, bindir and libdir as default options. Explicitly
> >> pass those three.
> >
> > Obviously not.
> >
> > ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure
> (log file is located at /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.
> do_configure.17278)
> > ERROR: Logfile of failure stored in: /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
> > Log data follows:
> > | DEBUG: Executing shell function do_configure
> > | waf [commands] [options]
> > |
> > | Main commands (example: ./waf build -j4)
> > |   build: executes the build
> > |   clean: cleans the project
> > |   configure: configures the project
> > |   dist : makes a tarball for redistributing the sources
> > |   distcheck: checks if the project compiles (tarball from 'dist')
> > |   distclean: removes the build directory
> > |   install  : installs the targets on the system
> > |   list : lists the targets to execute
> > |   step : executes tasks in a step-by-step fashion, for debugging
> > |   uninstall: removes the targets installed
> > |   update   : updates the plugins from the *waflib/extras* directory
> > |
> > | waf: error: no such option: --bindir
> >
>
> Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific.
>
> It seems bindir/libdir got added in 1.8 series:
> https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py
>
> Make version specific variables?
>

That neatly shows where the "clever code" that was breaking libdir earlier
is:

https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0ab003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237

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

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Stefan Agner]

On 2017-12-12 15:06, Vincent Prince wrote:

> Hi Ross, 
> 
> Does it fail with V1?

The waf version which comes with eglinfo says it will fail: 

  configure options: 
-o OUT, --out=OUT   build dir for the project 
-t TOP, --top=TOP   src dir for the project 
--prefix=PREFIX installation prefix [default: '/usr/local/'] 
--download  try to download the tools if missing 
..

No libdir to be seen.

--
Stefan

> Best regards, 
> Vincent 
> 
> 2017-12-12 15:00 GMT+01:00 Burton, Ross :
> 
> On 12 December 2017 at 13:27, Stefan Agner  wrote:
> 
> On some build hosts distros (e.g. Fedora 26) waf tries to be
> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
> This obviously is not what we want for 32-bit targets and usually
> fails in the do_package phase:
> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in 
> any package:
> /usr/lib64/libgstimxcommon.so.0
> 
> Waf knows prefix, bindir and libdir as default options. Explicitly
> pass those three. 
> 
> Obviously not. 
> 
> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure (log 
> file is located at 
> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
>  
> ERROR: Logfile of failure stored in: 
> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
>  
> Log data follows: 
> | DEBUG: Executing shell function do_configure 
> | waf [commands] [options] 
> | 
> | Main commands (example: ./waf build -j4) 
> |   build: executes the build 
> |   clean: cleans the project 
> |   configure: configures the project 
> |   dist : makes a tarball for redistributing the sources 
> |   distcheck: checks if the project compiles (tarball from 'dist') 
> |   distclean: removes the build directory 
> |   install  : installs the targets on the system 
> |   list : lists the targets to execute 
> |   step : executes tasks in a step-by-step fashion, for debugging 
> |   uninstall: removes the targets installed 
> |   update   : updates the plugins from the *waflib/extras* directory 
> | 
> | waf: error: no such option: --bindir 
> 
> Ross  
> --
> ___
> 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] waf.bbclass: explicitly pass bindir and libdir

[Stefan Agner]

On 2017-12-12 15:00, Burton, Ross wrote:

> On 12 December 2017 at 13:27, Stefan Agner  wrote:
> 
>> On some build hosts distros (e.g. Fedora 26) waf tries to be
>> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
>> This obviously is not what we want for 32-bit targets and usually
>> fails in the do_package phase:
>> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
>> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped 
>> in any package:
>> /usr/lib64/libgstimxcommon.so.0
>> 
>> Waf knows prefix, bindir and libdir as default options. Explicitly
>> pass those three.
> 
> Obviously not. 
> 
> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure (log 
> file is located at 
> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
>  
> ERROR: Logfile of failure stored in: 
> /data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
>  
> Log data follows: 
> | DEBUG: Executing shell function do_configure 
> | waf [commands] [options] 
> | 
> | Main commands (example: ./waf build -j4) 
> |   build: executes the build 
> |   clean: cleans the project 
> |   configure: configures the project 
> |   dist : makes a tarball for redistributing the sources 
> |   distcheck: checks if the project compiles (tarball from 'dist') 
> |   distclean: removes the build directory 
> |   install  : installs the targets on the system 
> |   list : lists the targets to execute 
> |   step : executes tasks in a step-by-step fashion, for debugging 
> |   uninstall: removes the targets installed 
> |   update   : updates the plugins from the *waflib/extras* directory 
> | 
> | waf: error: no such option: --bindir 
> 

Hm, eglinfo seems to come with a old waf version, 1.7.8 to be specific.

It seems bindir/libdir got added in 1.8 series:
https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py

Make version specific variables?

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

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Vincent Prince]

Hi Ross,

Does it fail with V1?

Best regards,
Vincent

2017-12-12 15:00 GMT+01:00 Burton, Ross :

> On 12 December 2017 at 13:27, Stefan Agner  wrote:
>
>> On some build hosts distros (e.g. Fedora 26) waf tries to be
>> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
>> This obviously is not what we want for 32-bit targets and usually
>> fails in the do_package phase:
>>   WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
>> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped
>> in any package:
>> /usr/lib64/libgstimxcommon.so.0
>>
>> Waf knows prefix, bindir and libdir as default options. Explicitly
>> pass those three.
>>
>
> Obviously not.
>
> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure
> (log file is located at /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.
> do_configure.17278)
> ERROR: Logfile of failure stored in: /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
> Log data follows:
> | DEBUG: Executing shell function do_configure
> | waf [commands] [options]
> |
> | Main commands (example: ./waf build -j4)
> |   build: executes the build
> |   clean: cleans the project
> |   configure: configures the project
> |   dist : makes a tarball for redistributing the sources
> |   distcheck: checks if the project compiles (tarball from 'dist')
> |   distclean: removes the build directory
> |   install  : installs the targets on the system
> |   list : lists the targets to execute
> |   step : executes tasks in a step-by-step fashion, for debugging
> |   uninstall: removes the targets installed
> |   update   : updates the plugins from the *waflib/extras* directory
> |
> | waf: error: no such option: --bindir
>
> Ross
>
> --
> ___
> 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] waf.bbclass: explicitly pass bindir and libdir

[Burton, Ross]

On 12 December 2017 at 13:27, Stefan Agner  wrote:

> On some build hosts distros (e.g. Fedora 26) waf tries to be
> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
> This obviously is not what we want for 32-bit targets and usually
> fails in the do_package phase:
>   WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped
> in any package:
> /usr/lib64/libgstimxcommon.so.0
>
> Waf knows prefix, bindir and libdir as default options. Explicitly
> pass those three.
>

Obviously not.

ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure
(log file is located at
/data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278)
ERROR: Logfile of failure stored in:
/data/poky-tmp/master/build/work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
Log data follows:
| DEBUG: Executing shell function do_configure
| waf [commands] [options]
|
| Main commands (example: ./waf build -j4)
|   build: executes the build
|   clean: cleans the project
|   configure: configures the project
|   dist : makes a tarball for redistributing the sources
|   distcheck: checks if the project compiles (tarball from 'dist')
|   distclean: removes the build directory
|   install  : installs the targets on the system
|   list : lists the targets to execute
|   step : executes tasks in a step-by-step fashion, for debugging
|   uninstall: removes the targets installed
|   update   : updates the plugins from the *waflib/extras* directory
|
| waf: error: no such option: --bindir

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

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Otavio Salvador]

On Tue, Dec 12, 2017 at 11:27 AM, Stefan Agner  wrote:
> From: Stefan Agner 
>
> On some build hosts distros (e.g. Fedora 26) waf tries to be
> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
> This obviously is not what we want for 32-bit targets and usually
> fails in the do_package phase:
>   WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in 
> any package:
> /usr/lib64/libgstimxcommon.so.0
>
> Waf knows prefix, bindir and libdir as default options. Explicitly
> pass those three.
>
> Signed-off-by: Stefan Agner 

Acked-by: Otavio Salvador 

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Stefan Agner]

From: Stefan Agner 

On some build hosts distros (e.g. Fedora 26) waf tries to be
smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
This obviously is not what we want for 32-bit targets and usually
fails in the do_package phase:
  WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: 
gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in 
any package:
/usr/lib64/libgstimxcommon.so.0

Waf knows prefix, bindir and libdir as default options. Explicitly
pass those three.

Signed-off-by: Stefan Agner 
---
 meta/classes/waf.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/waf.bbclass b/meta/classes/waf.bbclass
index c4698e910a..d0de6fe729 100644
--- a/meta/classes/waf.bbclass
+++ b/meta/classes/waf.bbclass
@@ -26,7 +26,7 @@ def get_waf_parallel_make(d):
 return ""
 
 waf_do_configure() {
-   ${S}/waf configure --prefix=${prefix} ${EXTRA_OECONF}
+   ${S}/waf configure --prefix=${prefix} --bindir=${bindir} 
--libdir=${libdir} ${EXTRA_OECONF}
 }
 
 waf_do_compile()  {
-- 
2.13.6

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

[OE-core] [PATCH 1/2] maintainers.inc: add an entry for dwarfsrcfiles

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/maintainers.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 856a6b763bf..9e5dbe17269 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -151,6 +151,7 @@ RECIPE_MAINTAINER_pn-dri2proto = "Armin Kuster 
"
 RECIPE_MAINTAINER_pn-dri3proto = "Armin Kuster "
 RECIPE_MAINTAINER_pn-dropbear = "Yi Zhao "
 RECIPE_MAINTAINER_pn-dtc = "Alexander Kanavin "
+RECIPE_MAINTAINER_pn-dwarfsrcfiles = "Alexander Kanavin 
"
 RECIPE_MAINTAINER_pn-e2fsprogs = "Robert Yang "
 RECIPE_MAINTAINER_pn-ed = "Alexander Kanavin "
 RECIPE_MAINTAINER_pn-eee-acpi-scripts = "Alexander Kanavin 
"
-- 
2.15.0

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

[OE-core] [PATCH 2/2] oe-selftest: add a test for recipes without maintainers

[Alexander Kanavin]

'bitbake -c checkpkg world' is moved to class initializer to avoid
it being run twice in a row.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oeqa/selftest/cases/distrodata.py | 32 +-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/distrodata.py 
b/meta/lib/oeqa/selftest/cases/distrodata.py
index 12540adc7d8..cf8b4a21763 100644
--- a/meta/lib/oeqa/selftest/cases/distrodata.py
+++ b/meta/lib/oeqa/selftest/cases/distrodata.py
@@ -9,6 +9,12 @@ class Distrodata(OESelftestTestCase):
 @classmethod
 def setUpClass(cls):
 super(Distrodata, cls).setUpClass()
+feature = 'INHERIT += "distrodata"\n'
+feature += 'LICENSE_FLAGS_WHITELIST += " commercial"\n'
+
+cls.write_config(cls, feature)
+bitbake('-c checkpkg world')
+
 
 @OETestID(1902)
 def test_checkpkg(self):
@@ -18,11 +24,6 @@ class Distrodata(OESelftestTestCase):
 Product: oe-core
 Author:  Alexander Kanavin 
 """
-feature = 'INHERIT += "distrodata"\n'
-feature += 'LICENSE_FLAGS_WHITELIST += " commercial"\n'
-
-self.write_config(feature)
-bitbake('-c checkpkg world')
 checkpkg_result = open(os.path.join(get_bb_var("LOG_DIR"), 
"checkpkg.csv")).readlines()[1:]
 regressed_failures = [pkg_data[0] for pkg_data in 
[pkg_line.split('\t') for pkg_line in checkpkg_result] if pkg_data[11] == 
'UNKNOWN_BROKEN']
 regressed_successes = [pkg_data[0] for pkg_data in 
[pkg_line.split('\t') for pkg_line in checkpkg_result] if pkg_data[11] == 
'KNOWN_BROKEN']
@@ -40,3 +41,24 @@ The following packages have been checked successfully for 
upstream versions,
 but their recipes claim otherwise by setting UPSTREAM_VERSION_UNKNOWN. Please 
remove that line from the recipes.
 """ + "\n".join(regressed_successes)
 self.assertTrue(len(regressed_failures) == 0 and 
len(regressed_successes) == 0, msg)
+
+def test_maintainers(self):
+"""
+Summary: Test that recipes have a maintainer
+Expected:All recipes (except a few special static/testing ones) 
should have a maintainer listed in maintainers.inc file.
+Product: oe-core
+Author:  Alexander Kanavin 
+"""
+def is_exception(pkg):
+exceptions = ["packagegroup-", "initramfs-", 
"systemd-machine-units", "container-image-testpkg", "postinst", 
"devtool-test-", "selftest-ed"]
+for i in exceptions:
+ if i in pkg:
+ return True
+return False
+
+checkpkg_result = open(os.path.join(get_bb_var("LOG_DIR"), 
"checkpkg.csv")).readlines()[1:]
+no_maintainer_list = [pkg_data[0] for pkg_data in 
[pkg_line.split('\t') for pkg_line in checkpkg_result] if pkg_data[14] == '' 
and not is_exception(pkg_data[0])]
+msg = """
+The following packages do not have a maintainer assigned to them. Please add 
an entry to meta/conf/distro/include/maintainers.inc file.
+""" + "\n".join(no_maintainer_list)
+self.assertTrue(len(no_maintainer_list) == 0, msg)
-- 
2.15.0

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

Re: [OE-core] [PATCH] i2c-tools: upgrade to 4.0

[Alexander Kanavin]

On 12/09/2017 06:57 PM, Richard Purdie wrote:


Fails on musl sadly:

https://autobuilder.yocto.io/builders/nightly-musl/builds/643/steps/BuildImages/logs/stdio


musl is a notorious source of failures discovered late (e.g. on AB) and 
resulting patch friction. I'll add a musl build test to AUH, and once 
AUH is ready for consumption we should steer people towards using it - 
particularly when they send patches that break on musl :)


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

Re: [OE-core] [PATCHv2] recipes-multimedia/gstreamer: Add gst-validate recipe

[Otavio Salvador]

On Tue, Dec 12, 2017 at 10:23 AM, Burton, Ross  wrote:
> On 6 December 2017 at 22:00, Aníbal Limón  wrote:
>>
>> +SRC_URI =
>> "https://gstreamer.freedesktop.org/src/${PN}/${PN}-${PV}.tar.xz;
>
>
> ERROR: lib32-gst-validate-1.12.3-r0 do_fetch: Fetcher failure for URL:
> 'https://gstreamer.freedesktop.org/src/lib32-gst-validate/lib32-gst-validate-1.12.3.tar.xz'.
> Unable to fetch URL from any source.
>
> You need to use BPN not PN, but use ${BP} instead of of BPN-PV.

Also, it should rdepends on git and git-annex no?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv2] recipes-multimedia/gstreamer: Add gst-validate recipe

[Burton, Ross]

On 6 December 2017 at 22:00, Aníbal Limón  wrote:

> +SRC_URI = "https://gstreamer.freedesktop.org/src/${PN}/${PN}-${PV}.tar.xz
> "
>

ERROR: lib32-gst-validate-1.12.3-r0 do_fetch: Fetcher failure for URL: '
https://gstreamer.freedesktop.org/src/lib32-gst-validate/lib32-gst-validate-1.12.3.tar.xz'.
Unable to fetch URL from any source.

You need to use BPN not PN, but use ${BP} instead of of BPN-PV.

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

Re: [OE-core] [PATCHv2] recipes-multimedia/gstreamer: Add gst-validate recipe

[Burton, Ross]

On 6 December 2017 at 22:00, Aníbal Limón  wrote:

> +# to use non display mode in gst-validate-launcher
> +RDEPENDS_${PN} = "xserver-xorg-xvfb"
>

Don't enforce behaviour.  This forces the xvfb server into images which
have a proper server, and gst-validate refuses to build if the X11 distro
feature is disabled.

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

Re: [OE-core] [PATCH] kernel-devsrc: Use full mrproper to clean

[Burton, Ross]

This breaks some of the sanity tests, which build a kernel module:

https://autobuilder.yocto.io/builders/nightly-x86-64/builds/664

Ross

On 5 December 2017 at 23:00, Saul Wold  wrote:

> By using the full mrproper clean target it also removes some generated
> files
> that are not required on the target to build. It also helps to fix
> reprodudible
> builds as the generated files could have different permissions causing the
> check to fail.
>
> Tested with building and booting kernel from source on the target
>
> [YOCTO #12137]
>
> Signed-off-by: Saul Wold 
> ---
>  meta/recipes-kernel/linux/kernel-devsrc.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> b/meta/recipes-kernel/linux/kernel-devsrc.bb
> index c1b5b7786d7..d925a33aeb1 100644
> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> @@ -52,7 +52,7 @@ do_install() {
>  # The main build artifacts. We clean the directory to avoid QA
> errors on mismatched
>  # architecture (since scripts and helpers are native format).
>  KBUILD_OUTPUT="$kerneldir"
> -oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> clean _mrproper_scripts
> +oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> clean mrproper
>  # make clean generates an absolute path symlink called "source"
>  # in $kerneldir points to $kerneldir, which doesn't make any
>  # sense, so remove it.
> --
> 2.13.6
>
> --
> ___
> 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] recipetool: create: fix conflict between SRCREV and tag

[Chang, Rebecca Swee Fun]

Thank you, please let me know if the patch need a v2.

Rebecca

From: Ross Burton 
Date: Monday, 11 December 2017 at 9:34 PM
To: "Chang, Rebecca Swee Fun" 
Cc: OpenEmbedded Core Mailing List 
Subject: Re: [OE-core] [PATCH] recipetool: create: fix conflict between SRCREV 
and tag

I think there were selftest failures and I removed it to see what happened, 
added back again now.

Ross

On 11 December 2017 at 01:10, Chang, Rebecca Swee Fun 
> 
wrote:
Ping again.
I noticed that it was on mut2 2 weeks ago. I think this was dropped somehow at 
that point. May I know what I can do in order to make it into M1 cycle?

Thanks,
Rebecca


On 15/11/2017, 10:00 AM, 
"openembedded-core-boun...@lists.openembedded.org
 on behalf of Chang Rebecca Swee Fun" 

 on behalf of 
rebecca.swee.fun.ch...@intel.com> 
wrote:

If you specify 'tag=' for a git URL and passed to recipetool create, you
will get into Bitbake expansion error shown below:

- snip -
$ devtool add --version 2.4.2 mbedtls 
"git://github.com/ARMmbed/mbedtls;tag=mbedtls-2.4.2"
...
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression 
was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
failure: Conflicting revisions (abeccb9dbd7e19ae91ac50e1edd3803111c5f9b6 from 
SRCREV and mbedtls-2.4.2 from the url) found, please specify one valid value
- snip -

Assuming the tag is valid, we should get the tag commit hash and
drop the usage of 'tag=' from SRC_URI. By using a commit hash
corresponding to the tag will prevent bitbake from accessing
remote repository in order to expand SRCPV.

Signed-off-by: Chang Rebecca Swee Fun 
>
---
 scripts/lib/recipetool/create.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/lib/recipetool/create.py 
b/scripts/lib/recipetool/create.py
index 54e7e85..2fc9e0a 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -480,7 +480,6 @@ def create_recipe(args):
 if tag:
 # Keep a copy of tag and append nobranch=1 then remove tag 
from URL.
 # Bitbake fetcher unable to fetch when {AUTOREV} and tag is 
set at the same time.
-# We will re-introduce tag argument after bitbake fetcher 
process is complete.
 storeTagName = params['tag']
 params['nobranch'] = '1'
 del params['tag']
@@ -552,13 +551,11 @@ def create_recipe(args):

 # Since we might have a value in srcbranch, we need to
 # recontruct the srcuri to include 'branch' in params.
+scheme, network, path, user, passwd, params = 
bb.fetch2.decodeurl(srcuri)
 if srcbranch:
-scheme, network, path, user, passwd, params = 
bb.fetch2.decodeurl(srcuri)
 params['branch'] = srcbranch
-srcuri = bb.fetch2.encodeurl((scheme, network, path, user, 
passwd, params))

 if storeTagName and scheme in ['git', 'gitsm']:
-# Re-introduced tag variable from storeTagName
 # Check srcrev using tag and check validity of the tag
 cmd = ('git rev-parse --verify %s' % (storeTagName))
 try:
@@ -568,6 +565,9 @@ def create_recipe(args):
 logger.error(str(err))
 logger.error("Possibly wrong tag name is provided")
 sys.exit(1)
+# Drop tag from srcuri as it will have conflicts with SRCREV 
during recipe parse.
+del params['tag']
+srcuri = bb.fetch2.encodeurl((scheme, network, path, user, passwd, 
params))

 if os.path.exists(os.path.join(srctree, '.gitmodules')) and 
srcuri.startswith('git://'):
 srcuri = 'gitsm://' + srcuri[6:]
--
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

-- 
___
Openembedded-core mailing 

Re: [OE-core] [PATCH] waf.bbclass: explicitly pass libdir

[Stefan Agner]

On 2017-12-12 11:58, Burton, Ross wrote:

> On 12 December 2017 at 07:48, Stefan Agner  wrote:
> 
>> On 2017-12-11 18:15, Otavio Salvador wrote:
>>> On Mon, Dec 11, 2017 at 3:09 PM, Burton, Ross  wrote:
 On 11 December 2017 at 15:37, Joshua Watt  wrote:
> 
> Vanilla waf only supports --prefix, --libdir, and --bindir. Anything else
> is a result of loading the gnu_dirs tool, which not all projects are
> required to do.
> 
> 
> Sorry, hit send too soo: waf (at least version 2.0) also errors out on
> unknown options. I think the three I listed are the only ones we can do
> generically. There might be some way to easily adding the rest if you know
> waf is loading gnu_dirs
 
 
 One option would be for waf.bbclass to check if WAF_USES_GNU_DIRS is set
 (defaulting to 0) and pass the full set of path options automatically.
>>> 
>>> Possible. But passing the standard ones solve 99% of the issues.
>>> 
>> 
>> I am with Otavio here. Also, adding the standard ones and adding the
>> additional GNU_DIRS would best be done in two independent patches
>> anyway. For now I'd rather prefer to only add the standard ones.
> 
> Fine by me.  Will there be a v2 adding --bindir? 
> 

Yes, will send soon. 

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

Re: [OE-core] [PATCH] waf.bbclass: explicitly pass libdir

[Burton, Ross]

On 12 December 2017 at 07:48, Stefan Agner  wrote:

> On 2017-12-11 18:15, Otavio Salvador wrote:
> > On Mon, Dec 11, 2017 at 3:09 PM, Burton, Ross 
> wrote:
> >> On 11 December 2017 at 15:37, Joshua Watt  wrote:
> >>>
> >>> Vanilla waf only supports --prefix, --libdir, and --bindir. Anything
> else
> >>> is a result of loading the gnu_dirs tool, which not all projects are
> >>> required to do.
> >>>
> >>>
> >>> Sorry, hit send too soo: waf (at least version 2.0) also errors out on
> >>> unknown options. I think the three I listed are the only ones we can do
> >>> generically. There might be some way to easily adding the rest if you
> know
> >>> waf is loading gnu_dirs
> >>
> >>
> >> One option would be for waf.bbclass to check if WAF_USES_GNU_DIRS is set
> >> (defaulting to 0) and pass the full set of path options automatically.
> >
> > Possible. But passing the standard ones solve 99% of the issues.
> >
>
> I am with Otavio here. Also, adding the standard ones and adding the
> additional GNU_DIRS would best be done in two independent patches
> anyway. For now I'd rather prefer to only add the standard ones.
>

Fine by me.  Will there be a v2 adding --bindir?

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

Re: [OE-core] [PATCH] gmp: depends on flex-native to fix parallel building issue

[Richard Purdie]

Let me make this simpler. Which release of the project did you see this
issue with?

I believe this issue would only occur with morty and early, pyro, rocko
and master are not affected.

Cheers,

Richard

On Tue, 2017-12-12 at 07:13 +, Bai, Haiqing wrote:
> Comments below. thanks
> 
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] 
> Sent: 2017年12月11日 6:48
> To: Bai, Haiqing; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] gmp: depends on flex-native to fix
> parallel building issue
> 
> On Wed, 2017-11-29 at 14:54 +0800, Haiqing Bai wrote:
> > 
> > fix below parallel building issue:
> > configure:27365: result: flex
> > configure:27403: flex conftest.l
> > .../sysroots/x86_64-linux/usr/bin/flex.real: No such file or
> > directory
> > configure:27407: $? = 127
> > configure:27409: checking lex output file root
> > configure:27420: error: cannot find output from flex; giving up
> > 
> > Signed-off-by: Haiqing Bai 
> > ---
> >  meta/recipes-support/gmp/gmp.inc | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes- 
> > support/gmp/gmp.inc index abac8cf..1b35eaa 100644
> > --- a/meta/recipes-support/gmp/gmp.inc
> > +++ b/meta/recipes-support/gmp/gmp.inc
> > @@ -10,3 +10,5 @@ PACKAGECONFIG[readline] = "--with-readline=yes, 
> > --with-readline=no,readline"
> >  
> >  ARM_INSTRUCTION_SET_armv4 = "arm"
> >  ARM_INSTRUCTION_SET_armv5 = "arm"
> > +
> > +DEPENDS = "flex-native"
> With recipe specific sysroots this should now be deterministic. The
> log above suggests you were not using recipe specific sysroots? This
> would therefore only be applicable to morty and earlier?
> [This issue is founded on x86-64 building,  but it does not mean it
> is only related with x86.  Actually this is caused by the defect of
> the traditional probe mechanism of 'configure',  the package
> configure
> script try to probe whether has package 'flex' , then some optional
> actions will be done by it.  In this issue,  when this probe
> happens,   /usr/bin/flex exists but '/usr/bin/flex.real' has not
> created for the
> parallel building,  then configure reports the error and exits from
> building.   Since there are no atomic guarantee for the package
> output during parallel building, so here add this depends]
> 
> Cheers,
> 
> Richard
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] syslinux: always use the BFD linker

[André Draszik]

On Mon, 2017-12-11 at 21:49 -0500, Allen Wild wrote:
> Syslinux compiles successfully with Gold, but at runtime Isolinux fails
> to boot, getting stuck at the version screen without loading the menu.
> Forcing the BFD linker fixes this.
> 
> To future-proof, use an inline python replace rather than duplicating
> the definition of LD in bitbake.conf

Hm, other recipes that have this need typically simply do:

LDFLAGS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' 
-fuse-ld=bfd ', '', d)}"

Would a similar approach work here, too? Instead of this big change.

Cheers,
Andre'
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] perl: native modules will not trigger build perl for target.

[Krzysztof Taborski]

kindly reminder

2017-12-08 18:46 GMT+01:00 Krzysztof Taborski :

> Hello,
> I would like to request feedback about my patch.
>
> Br,
> Krzysztof Taborski
>
> -Original Message-
> From: Krzysztof Taborski [mailto:taborskikrzysz...@gmail.com]
> Sent: Monday, December 04, 2017 7:17 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Krzysztof Taborski
> Subject: [OE-core][PATCH v2] perl: native modules will not trigger build
> perl for target.
>
> Currently building perl-native modules triggers build perl for target due
> to PACKAGES_DYNAMIC regex.
>
> This commit will cause, that perl native modules will trigger perl-native
> build.
>
> Signed-off-by: Krzysztof Taborski 
> ---
>  meta/recipes-devtools/perl/perl-native_5.24.1.bb | 2 ++
>  meta/recipes-devtools/perl/perl_5.24.1.bb| 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/perl/perl-native_5.24.1.bb
> b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
> index 48113f05a9..a81dc4d703 100644
> --- a/meta/recipes-devtools/perl/perl-native_5.24.1.bb
> +++ b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
> @@ -134,3 +134,5 @@ EOF
>
>  # Fix the path in sstate
>  SSTATE_SCAN_FILES += "*.pm *.pod *.h *.pl *.sh"
> +PACKAGES_DYNAMIC_class-native += "^perl-module-.*native$"
> +
> diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb
> b/meta/recipes-devtools/perl/perl_5.24.1.bb
> index 6b27b22d22..3dc7805da9 100644
> --- a/meta/recipes-devtools/perl/perl_5.24.1.bb
> +++ b/meta/recipes-devtools/perl/perl_5.24.1.bb
> @@ -323,7 +323,7 @@ python split_perl_packages () {
>  d.setVar(d.expand("RRECOMMENDS_${PN}-modules"), ' '.join(packages))
> }
>
> -PACKAGES_DYNAMIC += "^perl-module-.*"
> +PACKAGES_DYNAMIC += "^perl-module-.*(?  PACKAGES_DYNAMIC_class-nativesdk += "^nativesdk-perl-module-.*"
>
>  RPROVIDES_perl-lib = "perl-lib"
> --
> 2.13.6
>
>


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