[OE-core] Recovering GCC 4.8

I have a need for GCC 4.8 which was recently dropped from OE-core. commit d9aabf9639510fdb3e2ccc21ba5ae4aa9f6e4a57 Author: Richard Purdie Date: Wed Nov 11 08:50:02 2015 -0800 gcc: Drop 4.8 We have 5.2 and 4.9, we don't really need 4.8 now and it

[OE-core] [PATCH 6/6] git: fix installed-vs-shipped QA Issue

Since commit set default libexecdir to $prefix/libexec ... commit f35b2e29d9bfa817e64b83df11ebbbfe0f4e8e5c Author: Ross Burton Date: Tue Apr 30 20:35:54 2013 +0100 bitbake: set default libexecdir to $prefix/libexec ... It casued '${D}${libdir}' does not exist, and

[OE-core] [PATCH 4/6] openssl: substitute buildpath in source code

The openssl records $CC and $CFLAGS in source code which caused buildpaths QA issue: In crypto/cversion.c ... if (t == SSLEAY_CFLAGS) { return (CFLAGS); return ("compiler: information not available"); } ... We should do substitution in the above source code which use

[OE-core] [PATCH 5/6] btrfs-tools: fix symlink creation multiple times

The rule to create symlink in Makefile caused parallel issue: $ make -j 40 DESTDIR=/image install BUILD_VERBOSE=1 ... 1 [LN] libbtrfs.so.0 2 [LN] libbtrfs.so 3 ln -s -f libbtrfs.so.0.1 libbtrfs.so.0 4 ln -s -f libbtrfs.so.0.1 libbtrfs.so.0 5 ln -s -f libbtrfs.so.0.1

[OE-core] [PATCH 3/6] bison/gettext: add --with-bisonlocaledir to assign BISON_LOCALEDIR

This issue was triggered by buildpaths QA Warning. ... |gettext-0.19.6: File work/core2-64-poky-linux/gettext/0.19.6-r0/ packages-split/gettext/usr/bin/msgcmp in package contained reference to tmpdir ... Previously, variable BISON_LOCALEDIR was assigned only by the output of 'bison

[OE-core] [PATCH 0/6] fix buildpath QA Issue

Also fix btrfs-tools and git which were found by workd build Other buildpath fixes is still on the way. //Hongxu The following changes since commit ed20c6ca446a8788615e497bd4452195537deab5: epiphany: Add libxml2-native to DEPENDS (2016-02-19 01:01:26 +) are available in the git

[OE-core] [PATCH 1/6] depmodwrapper-cross: nopackages to avoid QA [buildpaths] issue

This depmodwrapper is a wrapper script to support install-corss, which is invoked at do_rootfs time. So the depmodwrapper-cross should not generate packages. The fix could avoids QA buildpaths issue. [YOCTO #7058] Signed-off-by: Hongxu Jia ---

[OE-core] [PATCH 2/6] gcc: use relative path for configure script

The absolute path (/path/to/configure) caused __FILE__ to be an absolute path. If 'assert' invoked, it uses __FILE__, and build path would be in elf files. In assert.h ... .# define assert(expr) \ ((expr)

[OE-core] [PATCH v2 3/3] populate_sdk_ext.bbclass: Add SDK_RECRDEP_TASKS variable

Currently there isn't a way for the extensible sdk to know all the tasks that will need sstate for an image. This is because a layer can add it's on custom tasks that are required for an image to be generated. The extensible sdk solved this for poky by using recrdeptask and specifying the tasks

Re: [OE-core] [PATCH 3/3] populate_sdk_ext.bbclass: Add SDK_RECRDEP_TASKS variable

On 02/18/2016 02:57 PM, Richard Purdie wrote: On Thu, 2016-02-18 at 09:17 -0800, Randy Witt wrote: Currently there isn't a way for the extensible sdk to know all the tasks that will need sstate for an image. This is because a layer can add it's on custom tasks that are required for an image to

[OE-core] [PATCH 0/1] insane.bbclass: make the checking stricter for unsafe references in scripts

The following changes since commit 31af4a37c429bb1db8bfc64242b2963220f9a0e1: oeqa/parselogs: Whitelist dmi firmware failure message in 4.4 kernels (2016-02-16 23:53:43 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib ChenQi/qa-unsafe

[OE-core] [PATCH 1/1] insane.bbclass: make the checking stricter for unsafe references in scripts

From: Chen Qi Previously, the checking for unsafe references is not strict enough. It only checks whether '/usr/' is in the script. As a result, any script containing statements like below will match this check. PATH="/bin:/sbin:/usr/bin:/usr/sbin" However, as

[OE-core] [PATCH v2 2/3] libsoup-2.4: prevent PACKAGECONFIG dependant package renaming

When built without gnome support, libsoup-2.4 will contain only one shared lib and will therefore become subject to renaming by debian.bbclass. Prevent renaming in order to keep the package name consistent regardless of whether gnome support is enabled or disabled. Signed-off-by: Andre McCurdy

[OE-core] [PATCH v2 3/3] libsoup-2.4: disable libsoup-gnome by default

libsoup-gnome is entirely deprecated and has just been stubs since 2.42. Signed-off-by: Andre McCurdy --- meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[OE-core] [PATCH v2 1/3] libsoup-2.4: minor formatting improvements

Also update HOMEPAGE from generic Gnome to something libsoup specific. Signed-off-by: Andre McCurdy --- meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git

[OE-core] [PATCH v2 0/3] libsoup-2.4: cleanup + disable libsoup-gnome by default

v2: Prevent PACKAGECONFIG dependant package renaming Andre McCurdy (3): libsoup-2.4: minor formatting improvements libsoup-2.4: prevent PACKAGECONFIG dependant package renaming libsoup-2.4: disable libsoup-gnome by default meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 26

Re: [OE-core] [PATCH 2/2] libsoup-2.4: disable libsoup-gnome by default

On Thu, 2016-02-18 at 13:33 -0800, Andre McCurdy wrote: > Aside from automated detection of such problems, what's the best fix > in this particular case? > > 1) Use LEAD_SONAME to force renaming, even in the case when the > libsoup-2.4 package contains both shared libs. > > 2) Split

Re: [OE-core] [PATCH] cml1.bbclass: fix do_menuconfig

On Thu, Feb 18, 2016 at 7:46 AM, Markus Lehtonen wrote: > The functionality got broken after bitbake commit > 8bf33a8e92c0e188fa392030025756196c96fcbb > which disabled the (bitbake) variable expansion inside python functions. > > Signed-off-by: Markus Lehtonen

Re: [OE-core] [PATCH 3/3] populate_sdk_ext.bbclass: Add SDK_RECRDEP_TASKS variable

On Thu, 2016-02-18 at 09:17 -0800, Randy Witt wrote: > Currently there isn't a way for the extensible sdk to know all the > tasks > that will need sstate for an image. This is because a layer can add > it's > on custom tasks that are required for an image to be generated. > > The extensible sdk

Re: [OE-core] [PATCH 2/2] libsoup-2.4: disable libsoup-gnome by default

On Thu, 2016-02-18 at 13:33 -0800, Andre McCurdy wrote: > Aside from automated detection of such problems, what's the best fix > in this particular case? > > 1) Use LEAD_SONAME to force renaming, even in the case when the > libsoup-2.4 package contains both shared libs. > > 2) Split

[OE-core] [PATCH 1/1] linux-yocto/4.1: capabilities backports

Backporting the following upstream commits to the 4.1 yocto tree: bdf4565e5dcc capabilities: add a securebit to disable PR_CAP_AMBIENT_RAISE 2483c95caedc selftests/capabilities: Add tests for capability evolution 4c274aa74e5d capabilities: ambient capabilities Signed-off-by: Saul Wold

Re: [OE-core] [PATCH 2/2] libsoup-2.4: disable libsoup-gnome by default

On Thu, Feb 18, 2016 at 12:24 PM, Paul Eggleton wrote: > Hi Martin, > > On Thu, 18 Feb 2016 20:39:08 Martin Jansa wrote: >> IIRC this will rename the resulting package (because there will be only one >> shared library now). >> >> that will probably break on device

Re: [OE-core] [PATCH 2/2] libsoup-2.4: disable libsoup-gnome by default

Hi Martin, On Thu, 18 Feb 2016 20:39:08 Martin Jansa wrote: > IIRC this will rename the resulting package (because there will be only one > shared library now). > > that will probably break on device upgrade-path > > I'm not sure if someone still cares about upgrade-paths.. there are too > many

Re: [OE-core] [PATCH 2/2] libsoup-2.4: disable libsoup-gnome by default

On Thu, Feb 18, 2016 at 11:39 AM, Martin Jansa wrote: > IIRC this will rename the resulting package (because there will be only one > shared library now). Yes, you're right. Previously "libsoup-2.4" and becomes "libsoup-2.4-1" when the "gnome" PACKAGECONFIG is removed. >

Re: [OE-core] [PATCH 2/2] libsoup-2.4: disable libsoup-gnome by default

IIRC this will rename the resulting package (because there will be only one shared library now). that will probably break on device upgrade-path I'm not sure if someone still cares about upgrade-paths.. there are too many issues going in unnoticed. On Thu, Feb 18, 2016 at 8:21 PM, Andre McCurdy

[OE-core] [PATCH 2/2] libsoup-2.4: disable libsoup-gnome by default

libsoup-gnome is entirely deprecated and has just been stubs since 2.42. Signed-off-by: Andre McCurdy --- meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[OE-core] [PATCH 0/2] libsoup-2.4: cleanup + disable libsoup-gnome by default

Andre McCurdy (2): libsoup-2.4: minor formatting improvements libsoup-2.4: disable libsoup-gnome by default meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 20 +--- 1 file changed, 9 insertions(+), 11 deletions(-) -- 1.9.1 --

[OE-core] [PATCH 1/2] libsoup-2.4: minor formatting improvements

Also update HOMEPAGE from generic Gnome to something libsoup specific. Signed-off-by: Andre McCurdy --- meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git

Re: [OE-core] [PATCH 0/2] testimage: add/modify DEFAULT_TEST_SUITES

So I'm currently running a couple lsb builds, but even though they aren't finished, I think this patch may be the culprit, since I am defining DEFAULT_TEST_SUITES_pn-core-image-lsb with exactly the tests that are failing, so I'll most likely be sending an update soon. Alex Franco On 02/18/2016

[OE-core] [PATCH 2/3] devtool: Don't recursively look for .devtoolbase in --basepath

If the user specifies --basepath on the commandline, only the directory specified should be searched for .devtoolbase. Otherwise when --basepath is a child of the sdk directory, .devtoolbase will always be found and devtool will only show options meant to be used within an sdk. Signed-off-by:

[OE-core] [PATCH 1/3] populate_sdk_ext: Don't ignore SDK_TARGETS value

This fixes a problem where SDK_INSTALL_TARGETS wouldn't pick up the value in SDK_TARGETS. It also removes the inline python to make the code more readable. Signed-off-by: Randy Witt --- meta/classes/populate_sdk_ext.bbclass | 13 - 1 file changed, 12

[OE-core] [PATCH 3/3] populate_sdk_ext.bbclass: Add SDK_RECRDEP_TASKS variable

Currently there isn't a way for the extensible sdk to know all the tasks that will need sstate for an image. This is because a layer can add it's on custom tasks that are required for an image to be generated. The extensible sdk solved this for poky by using recrdeptask and specifying the tasks

[OE-core] [PATCH 0/3] extsdk bug fixes

These are bug fixes for bugs found during installation of the ext sdk. The following changes since commit bc72f64eb4041ef44198e3e0caeb2be9f43eb44e: linux-yocto: Update SRCREV for genericx86* for 4.4 (2016-02-11 22:58:38 +) are available in the git repository at:

[OE-core] [PATCH] waf.bbclass: Remove --disable-static from EXTRA_OECONF

As of commit OE-Core:773c9e18071d71454473dd81aff911104a2e9bc6 EXTRA_OECONF is appended with the option --disable-static on DISABLE_STATIC variable and this cause the error: waf: error: no such option: --disable-static So, we need to disable this option. Signed-off-by: Fabio Berton

[OE-core] [PATCH] signing-keys: Make signing keys the only publisher of keys

Previously the keys were put into the os-release package. The package indexing code was also deploying the keys rather than only using the keys. This change makes signing-keys.bb the only publisher of the keys and also uses standard tasks that already have sstate. Signed-off-by: Randy Witt

Re: [OE-core] [PATCH v5 1/3] gpg_sign: add local ipk package signing functionality

On 18/02/16 11:28, "Ioan-Adrian Ratiu" wrote: >Hello > >On Thu, 18 Feb 2016 11:04:22 +0200 >Markus Lehtonen wrote: > >> Hi, >> >> >> >> On 17/02/16 17:41, "Ioan-Adrian Ratiu" >>

Re: [OE-core] [PATCH v2 2/2] devtool: update-recipe: create config fragment

On Thu, Feb 18, 2016 at 7:19 AM Markus Lehtonen < markus.lehto...@linux.intel.com> wrote: > Create config fragment if the user makes modifications to kernel config. > User may change .config e.g. by directly editing it or by running the > 'do_menuconfig' bitbake task. Devtool generates one

Re: [OE-core] [PATCH 0/2] testimage: add/modify DEFAULT_TEST_SUITES

On Wed, 2016-02-17 at 09:55 +, Alex Franco wrote: > - Add generic variables to reuse values in default test suites > - Add more default test suites variables > - Modify existing test suites to use generic vars when possible > > [YOCTO #8410] > > Alex Franco (2): > testimage: add

[OE-core] [PATCH v2 2/2] devtool: update-recipe: create config fragment

Create config fragment if the user makes modifications to kernel config. User may change .config e.g. by directly editing it or by running the 'do_menuconfig' bitbake task. Devtool generates one monolithic fragment by simply doing a diff between .config and .config.baseline files in the source

[OE-core] [PATCH v2 1/2] devtool: sync: update kernel config

Copy kernel config is copied to the source directory at a later phase in _extract_source() so that it gets copied when devtool sync is done, too. Signed-off-by: Markus Lehtonen --- scripts/lib/devtool/standard.py | 6 +- 1 file changed, 5 insertions(+), 1

[OE-core] [PATCH v2 0/2] devtool: create kernel config fragment

Second iteration of rudimentary support for creating kernel config fragments with devtool. When doing 'update-recipe' devtool diffs .config.baseline and .config (under ${S}) and creates/upates a config fragment which is added to SRC_URI of the recipe. Unlike the in the first version of this

Re: [OE-core] [PATCH] add tunings for 32-bit ARMv8-a

On 02/16/2016 06:20 PM, Martin Jansa wrote: On Tue, Feb 16, 2016 at 06:08:45PM +0200, Dragomir Daniel wrote: On 02/16/2016 04:54 PM, Martin Jansa wrote: On Tue, Feb 16, 2016 at 04:28:38PM +0200, Daniel Dragomir wrote: From: Cristian Bercaru This patch adds

Re: [OE-core] Error building core-image-sato

On 02/18/2016 07:02 AM, winis...@futuraautomation.com wrote: NOTE: Runtime target 'xf86-input-tslib' is unbuildable, removing... The recipe is in meta-openembedded/meta-oe layer, not in oe-core. You should probably try to build it in isolation and figure out why it doesn't build. Alex

Re: [OE-core] [PATCH] conf/distro/include: Add no-static-libs.inc

On Thu, Feb 18, 2016 at 8:05 AM, Andreas Müller wrote: > On Mon, Feb 15, 2016 at 2:44 PM, Otavio Salvador > wrote: >> On Sun, Feb 14, 2016 at 12:28 PM, Richard Purdie >> wrote: >>> Maintaining

Re: [OE-core] [PATCH 0/4] Fido pull request

On Tue, 2016-02-16 at 14:30 +, Joshua Lock wrote: > Please consider the following fixes for inclusion in the Fido branch. > > - libpcre security fix not required in jethro or master because the > newer >   version they carry isn't affected > - backport a fix for some memory leaks in

[OE-core] [PATCH] epiphany: Add libxml2-native to DEPENDS

configure needs xmllint and there was no direct dependency. Signed-off-by: Richard Purdie diff --git a/meta/recipes-gnome/epiphany/epiphany_3.18.3.bb b/meta/recipes-gnome/epiphany/epiphany_3.18.3.bb index e822d3b..73fcd93 100644 ---

Re: [OE-core] [PATCH 1/1] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

On 02/18/2016 04:15 PM, Andrea Adami wrote: > On Thu, Feb 18, 2016 at 4:37 AM, Andre McCurdy wrote: >> On Wed, Feb 17, 2016 at 2:01 AM, wrote: >>> From: He Zhe >>> >>> Add KERNEL_IMAGETYPES to support building packaging and

Re: [OE-core] [PATCH] conf/distro/include: Add no-static-libs.inc

On Mon, Feb 15, 2016 at 2:44 PM, Otavio Salvador wrote: > On Sun, Feb 14, 2016 at 12:28 PM, Richard Purdie > wrote: >> Maintaining this list in a common location is more desireable than >> everyone doing it themselves. Poky

[OE-core] [PATCH] oeqa/utils/commands.py: eliminate import bb error [YP#9136] added bitbake/lib to sys.path

Signed-off-by: Costin Constantin --- meta/lib/oeqa/utils/commands.py | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py index 32e001c..8220169 100644 --- a/meta/lib/oeqa/utils/commands.py +++

Re: [OE-core] [PATCH 1/1] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

On 02/18/2016 11:37 AM, Andre McCurdy wrote: > On Wed, Feb 17, 2016 at 2:01 AM, wrote: >> From: He Zhe >> >> Add KERNEL_IMAGETYPES to support building packaging and installing >> multi types of kernel images, such as zImage uImage, at one time. >>

[OE-core] [PATCH][RESEND] gcc-5.3: backport fix for PR-target-65358

Signed-off-by: Martin Jansa --- meta/recipes-devtools/gcc/gcc-5.3.inc | 3 +- ...arget-65358-Avoid-clobbering-partial-argu.patch | 307 + 2 files changed, 309 insertions(+), 1 deletion(-) create mode 100644

Re: [OE-core] [PATCH v5 1/3] gpg_sign: add local ipk package signing functionality

Hello On Thu, 18 Feb 2016 11:04:22 +0200 Markus Lehtonen wrote: > Hi, > > > > On 17/02/16 17:41, "Ioan-Adrian Ratiu" > adrian.ra...@ni.com> wrote: > > >Implement local ipk signing logic

Re: [OE-core] [jethro][PATCH] glibc CVE-2015-7547

On Wed, 2016-02-17 at 10:48 -0800, Armin Kuster wrote: > This is being submitted to comply to Yocto compatability. > > Master is affected but waiting for 2.23 to be merged before sending > patches. I plan to backport this to fido as soon as it's on a branch I can cherry-pick from. Regards,

Re: [OE-core] [PATCH v5 3/3] package_manager: sign IPK package feeds

On 17/02/16 17:41, "Ioan-Adrian Ratiu" wrote: >Create gpg signed ipk package feeds using the gpg backend if configured. > >Signed-off-by: Ioan-Adrian Ratiu >--- >

Re: [OE-core] [PATCH v5 2/3] gpg_sign: detached_sign: add signature type support

On 17/02/16 17:41, "Ioan-Adrian Ratiu" wrote: >Add support for multiple types of signatures (binary or ascii) >in export_pubkey(). There is no change in behaviour for the function, >the previous implicit

Re: [OE-core] [PATCH v5 1/3] gpg_sign: add local ipk package signing functionality

Hi, On 17/02/16 17:41, "Ioan-Adrian Ratiu" wrote: >Implement local ipk signing logic inside the gpg backend and add a new >bbclass which configures signing similar to how rpm does it. > >The ipk signing

Re: [OE-core] [PATCH] oe-core: Fix base-files wrong softlink of /var/run and /var/lock

On 02/18/2016 04:19 PM, Richard Purdie wrote: On Wed, 2016-02-17 at 18:10 -0800, fupan...@windriver.com wrote: From: fli OE-CORE's fs-perms.txt force /var/run to link /run and /var/lock to /run/lock, so in order to match with it, make base-files /var/run and /var/lock

Re: [OE-core] [PATCH] oe-core: Fix base-files wrong softlink of /var/run and /var/lock

On Wed, 2016-02-17 at 18:10 -0800, fupan...@windriver.com wrote: > From: fli > > OE-CORE's fs-perms.txt force /var/run to link /run and > /var/lock to /run/lock, so in order to match with it, > make base-files /var/run and /var/lock link the absolute > path too. You

[OE-core] [PATCH] libtool: Don't hardcode grep paths

If sharing sstate between different distros, some of which have /bin/grep and some /usr/bin/grep, this can break. Simply don't hardcode the path. Signed-off-by: Richard Purdie diff --git a/meta/recipes-devtools/libtool/libtool-2.4.6.inc

Re: [OE-core] [PATCH 1/1] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

On Thu, Feb 18, 2016 at 4:37 AM, Andre McCurdy wrote: > On Wed, Feb 17, 2016 at 2:01 AM, wrote: >> From: He Zhe >> >> Add KERNEL_IMAGETYPES to support building packaging and installing >> multi types of kernel images, such as