[OE-core] [PATCH] glibc: add missing TRAP_BRANCH/TRAP_HWBKPT definitions

Patch submitted upstream, pending to be merged: https://sourceware.org/bugzilla/show_bug.cgi?id=21286 Signed-off-by: Fathi Boudra --- ...o.h-enum-definition-for-TRAP_HWBKPT-is-mi.patch | 69 ++ meta/recipes-core/glibc/glibc_2.25.bb | 1

[OE-core] [PATCH 2/2] libvorbis: Contain gcc specific compiler flags using configure option

Signed-off-by: Khem Raj --- .../libvorbis/0001-configure-Check-for-clang.patch | 56 ++ .../libvorbis/libvorbis_1.3.5.bb | 4 +- 2 files changed, 59 insertions(+), 1 deletion(-) create mode 100644

[OE-core] [PATCH 1/2] db: Fix atomic function namespace clash with clang builtins

Rename local function to avoid conflicts with compiler intrinsics Signed-off-by: Khem Raj --- ...me-local-__atomic_compare_exchange-to-avo.patch | 45 ++ meta/recipes-support/db/db_5.3.28.bb | 1 + 2 files changed, 46 insertions(+) create

[OE-core] [PATCH 0/2] Misc fixes

clang finds couple of more issues to weed out The following changes since commit d1d55041e38b12d40f896834b56475ea19a6047f: sstate: Ensure installation directory is empty before execution (2017-03-22 10:12:10 +) are available in the git repository at:

[OE-core] [PATCH V2 1/1] runqemu-gen-tapdevs: fix file path in example

Fix the path in example so that '/usr/bin/tunctl' could be found under this path. Signed-off-by: Chen Qi --- scripts/runqemu-gen-tapdevs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/runqemu-gen-tapdevs b/scripts/runqemu-gen-tapdevs index

[OE-core] [PATCH V2 0/1] runqemu-gen-tapdevs: fix file path in example

The following changes since commit 49c2df5652d25e6e9b2a4976658ab9bb17fe6694: meta-yocto-bsp: Remove superfluous OVERRIDES in machine conf files (2017-03-22 11:35:23 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/example-path

Re: [OE-core] [PATCH 1/1] runqemu-gen-tapdevs: fix file path in example

On 03/22/2017 06:27 PM, Richard Purdie wrote: On Wed, 2017-03-22 at 17:23 +0800, Chen Qi wrote: Fix the path in example so that '/usr/bin/tunctl' could be found under this path. Signed-off-by: Chen Qi --- scripts/runqemu-gen-tapdevs | 2 +- 1 file changed, 1

Re: [OE-core] ✗ patchtest: failure for #10618: Increase oe-selftest coverage of wic codebase (first part)

Hi Leo, On Thursday, 23 March 2017 9:53:31 AM NZDT Patchwork wrote: > == Series Details == > > Series: #10618: Increase oe-selftest coverage of wic codebase (first part) > Revision: 1 > URL : https://patchwork.openembedded.org/series/5923/ > State : failure > > == Summary == > > > Thank you

Re: [OE-core] possible content for site.conf?

On 3/22/17 7:02 PM, Robert P. J. Day wrote: > On Wed, 22 Mar 2017, Burton, Ross wrote: > >> >> On 22 March 2017 at 10:51, Robert P. J. Day wrote: >> from site.conf.sample, the obvious content is things like: >> >> * download dir >> * reference to local

[OE-core] [PATCH v2] libxslt: Add PACKAGECONFIG support for python

Add support to enable python bindings for libxslt using PACKAGECONFIG. This will include --with-python argument while compiling the package. The support is disabled by default. Signed-off-by: Vedang Patel --- meta/recipes-support/libxslt/libxslt_1.1.29.bb | 6 -- 1

Re: [OE-core] Using MACHINE_FEATURES in a native recipe

On Wed, Mar 22, 2017 at 4:00 PM, Andre McCurdy wrote: > On Wed, Mar 22, 2017 at 2:46 PM, Khem Raj wrote: >> On Wed, Mar 22, 2017 at 2:42 PM, Andre McCurdy wrote: >>> Currently native.bbclass clears MACHINEOVERRIDES but leaves >>>

Re: [OE-core] [PATCH] libxslt: Add PACKAGECONFIG support

On Wed, 2017-03-22 at 22:18 +, Burton, Ross wrote: > > On 22 March 2017 at 22:16, Patel, Vedang > wrote: > > I got my mistake. Setting PACKAGECONFIG enabled all the features by > > default. Also, should I be including python as runtime dependency > > when > >

Re: [OE-core] Using MACHINE_FEATURES in a native recipe

On Wed, Mar 22, 2017 at 2:46 PM, Khem Raj wrote: > On Wed, Mar 22, 2017 at 2:42 PM, Andre McCurdy wrote: >> Currently native.bbclass clears MACHINEOVERRIDES but leaves >> MACHINE_FEATURES alone. Is that an oversight? Or is there ever a >> legitimate

[OE-core] [PATCH] native.bbclass: clear MACHINE_FEATURES

Try to avoid native recipes accidentally being dependent on MACHINE_FEATURES. This simple change doesn't prevent MACHINE_FEATURES set via MACHINE_FEATURES_BACKFILL sneaking through, but it's better than nothing. Signed-off-by: Andre McCurdy --- meta/classes/native.bbclass |

Re: [OE-core] possible content for site.conf?

We use it as a form of default local.conf, making it a consistent configuration for building our layer. By combining this with a "bb" wrapper script, nothing needs to be sourced, and there is no build preparation at all - our workflow is simply 1. Check out our layer 2. Type `bb thing` The

Re: [OE-core] [PATCH] libxslt: Add PACKAGECONFIG support

On 22 March 2017 at 22:16, Patel, Vedang wrote: > I got my mistake. Setting PACKAGECONFIG enabled all the features by > default. Also, should I be including python as runtime dependency when > --with-python is used? > No, the rdepends will happen magically. You might

Re: [OE-core] [PATCH] libxslt: Add PACKAGECONFIG support

Hi Ross, On Wed, 2017-03-22 at 20:19 +, Burton, Ross wrote: > > On 22 March 2017 at 20:17, Patel, Vedang > wrote: > > Can you elabore on your concern? I am not exactly following it. > > > > the configs won't be enabled unless the corresponding features are > >

Re: [OE-core] Using MACHINE_FEATURES in a native recipe

On Wed, Mar 22, 2017 at 2:42 PM, Andre McCurdy wrote: > Currently native.bbclass clears MACHINEOVERRIDES but leaves > MACHINE_FEATURES alone. Is that an oversight? Or is there ever a > legitimate reason for a native recipe to have a dependency on > MACHINE_FEATURES?

[OE-core] Using MACHINE_FEATURES in a native recipe

Currently native.bbclass clears MACHINEOVERRIDES but leaves MACHINE_FEATURES alone. Is that an oversight? Or is there ever a legitimate reason for a native recipe to have a dependency on MACHINE_FEATURES? -- ___ Openembedded-core mailing list

[OE-core] ✗ patchtest: failure for #10618: Increase oe-selftest coverage of wic codebase (first part)

== Series Details == Series: #10618: Increase oe-selftest coverage of wic codebase (first part) Revision: 1 URL : https://patchwork.openembedded.org/series/5923/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response.

Re: [OE-core] [PATCH] libxslt: Add PACKAGECONFIG support

On 22 March 2017 at 20:17, Patel, Vedang wrote: > Can you elabore on your concern? I am not exactly following it. > > the configs won't be enabled unless the corresponding features are > explicitly enabled in the image. I am using libxslt- prefix to make sure > someone

Re: [OE-core] [PATCH] libxslt: Add PACKAGECONFIG support

Hi Jussi, On Tue, 2017-03-21 at 08:36 +, Kukkonen, Jussi wrote: On 21 March 2017 at 02:31, Vedang Patel > wrote: Some options like python bindings, debug support, crypto are hardcoded inside the recipe. Change that to make those option

[OE-core] Fedorahosted.org in SRC_URI

Hi FYI I see this notice https://fedoraproject.org/wiki/Infrastructure/Fedorahosted-retirement and I then grep'ed for fedorahosted in SRC_URI, they need to be fixed oe-core meta/lib/oeqa/selftest/recipetool.py:checkvars['SRC_URI'] =

Re: [OE-core] [PATCH 1/1] meta/classes/kernel.bbclass: revert 56fe5300ab5

On 22 March 2017 at 17:00, Trevor Woerner wrote: > Please don't add this patch, I've found a test case where I see the > "+" being added. > (Is there a stronger way of doing this via patchwork?) > As the submitter you should be able to retract a patch in patchwork, but this

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On Wed, Mar 22, 2017 at 11:44 AM, Burton, Ross wrote: > > On 22 March 2017 at 14:59, Richard Purdie linuxfoundation.org> wrote: > >> What should happen is that the openstack recipe should complain loudly >> (error) if anyone tried to build it (or parse

Re: [OE-core] [PATCH 1/1] meta/classes/kernel.bbclass: revert 56fe5300ab5

Please don't add this patch, I've found a test case where I see the "+" being added. (Is there a stronger way of doing this via patchwork?) On Tue, Mar 21, 2017 at 3:05 PM, Trevor Woerner wrote: > This commit effectively reverts 56fe5300ab5 (except doing a revert at this >

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On Wed, 2017-03-22 at 15:44 +, Burton, Ross wrote: > > On 22 March 2017 at 14:59, Richard Purdie tion.org> wrote: > > What should happen is that the openstack recipe should complain > > loudly > > (error) if anyone tried to build it (or parse it?) with anything >

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On 22 March 2017 at 14:59, Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > What should happen is that the openstack recipe should complain loudly > (error) if anyone tried to build it (or parse it?) with anything except > the versions its known to work with. > Is this a good time

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On Wed, 22 Mar 2017 08:33:17 -0400 Bruce Ashfield wrote: > On Wed, Mar 22, 2017 at 8:24 AM, Robert P. J. Day > wrote: > > > > > proper attributions seem to have been totally lost here ... > > > > On Wed, 22 Mar 2017, Bruce Ashfield wrote: > >

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On Wed, 2017-03-22 at 08:33 -0400, Bruce Ashfield wrote: > > > On Wed, Mar 22, 2017 at 8:24 AM, Robert P. J. Day .ca> wrote: > > > >   proper attributions seem to have been totally lost here ... > > > > On Wed, 22 Mar 2017, Bruce Ashfield wrote: > > > > > On Wed, Mar 22,

[OE-core] [PATCH 09/10] selftest: pylinted wic test suite.

Fixed long lines, indentation and one unused variable. Signed-off-by: Ed Bartosh --- meta/lib/oeqa/selftest/wic.py | 52 +++ 1 file changed, 28 insertions(+), 24 deletions(-) diff --git a/meta/lib/oeqa/selftest/wic.py

[OE-core] [PATCH 04/10] wic: fix bug in sparse_copy

sparse_copy creates output file that is smaller than input file when input file ends with unmapped blocks. Used truncate() when output file is created to ensure the size of output file will always be equal to the size of input file. Signed-off-by: Ed Bartosh ---

[OE-core] [PATCH 07/10] wic: improve getting syslinux path

Used wic-tools STAGING_DATADIR if syslinux can't be found in default bootimg_dir. Signed-off-by: Ed Bartosh --- scripts/lib/wic/plugins/source/bootimg-pcbios.py | 51 +--- 1 file changed, 27 insertions(+), 24 deletions(-) diff --git

[OE-core] [PATCH 02/10] wic: don't set creator.bootimg_dir in plugins

Changing bootimg_dir in plugins is a dangerous hack as this value comes from wic command line and can be used by multiple plugins. Signed-off-by: Ed Bartosh --- scripts/lib/wic/plugins/source/bootimg-efi.py| 2 -- scripts/lib/wic/plugins/source/bootimg-pcbios.py

[OE-core] [PATCH 06/10] wic: remove empty plugin methods

Removed do_install_disk and do_configure_partition methods from bootimage-partition, fsimage and rawcopy plugins as they're empy and not used. [YOCTO #10618] Signed-off-by: Ed Bartosh --- scripts/lib/wic/plugins/source/bootimg-partition.py | 20

[OE-core] [PATCH 08/10] oe-selftest: test wic rawcopy plugin

Added test_rawcopy_plugin_qemu test case and wks template. This test builds ext4 rootfs image, copies it to the root partition of the wic image using rawcopy plugin and boots wic image in qemu. [YOCTO #10618] Signed-off-by: Ed Bartosh ---

[OE-core] [PATCH 01/10] wic: remove rootfs_pcbios_ext plugin

Removed broken unused plugin. Signed-off-by: Ed Bartosh --- .../lib/wic/plugins/source/rootfs_pcbios_ext.py| 213 - 1 file changed, 213 deletions(-) delete mode 100644 scripts/lib/wic/plugins/source/rootfs_pcbios_ext.py diff --git

[OE-core] [PATCH 10/10] oe-selftest: add test_rawcopy_plugin test case

This test case builds wic image using rawcopy plugin running wic directly. [YOCTO #10618] Signed-off-by: Ed Bartosh --- meta/lib/oeqa/selftest/wic.py | 16 1 file changed, 16 insertions(+) diff --git a/meta/lib/oeqa/selftest/wic.py

[OE-core] [PATCH 05/10] wic: use STAGING_DATADIR as a default for bootimg_dir

Default value for bootimg_dir was not set in main wic script unlike the rest of artifacts: kernel_dir, roofts_dir and native_sysroot. Set it to the value of STAGING_DATADIR for consistency and to avoid confusion of wic plugin developers. Signed-off-by: Ed Bartosh ---

[OE-core] [PATCH 03/10] wic: use kernel_dir instead of bootimg_dir

bootimg_dir is usually set to the value of STAGING_DATADIR and kernel_dir - to the value of DEPLOY_DIR_IMAGE, so usage of kernel_dir is more logical in bootimg-efi, bootimg-partition and rawcopy plugins. Replaced usage of bootimg_dir to kernel_dir in 3 above mentioned plugins that use

[OE-core] [PATCH 00/10] #10618: Increase oe-selftest coverage of wic codebase (first part)

Hi, The main goal of these changes was to increase test coverage by testing rawcopy plugin, which was not covered by the wic test suite. While working on it I found and fixed quite nasty bug in sparse_copy API and made set of other important changes to make the test case working. I've also

Re: [OE-core] another design question -- proper (meaningful) content of recipe patches?

On 03/22/2017 03:22 PM, Robert P. J. Day wrote: in any event, i can appreciate the value of sometimes adding numbering to patches to enforce a processing order, but when one has a numbered series of patches getting up to 20 or 25, that strikes me as time to collapse all that into larger and

Re: [OE-core] another design question -- proper (meaningful) content of recipe patches?

On Wed, Mar 22, 2017 at 9:22 AM, Robert P. J. Day wrote: > > got into an animated discussion the other day regarding proper > design of patch files associated with a recipe. as a demo, i can > actually use part of a recipe file ripped from the meta-digi-arm > layer, for

Re: [OE-core] another design question -- proper (meaningful) content of recipe patches?

On 22 March 2017 at 13:22, Robert P. J. Day wrote: > in any event, i can appreciate the value of sometimes adding > numbering to patches to enforce a processing order, but when one has a > numbered series of patches getting up to 20 or 25, that strikes me as > time to

[OE-core] another design question -- proper (meaningful) content of recipe patches?

got into an animated discussion the other day regarding proper design of patch files associated with a recipe. as a demo, i can actually use part of a recipe file ripped from the meta-digi-arm layer, for "kernel-module-qualcomm", whose recipe file contains (in part): SRC_URI = " \

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On Wed, 22 Mar 2017, Bruce Ashfield wrote: > > > On Wed, Mar 22, 2017 at 8:24 AM, Robert P. J. Day > wrote: > >   proper attributions seem to have been totally lost here ... > > On Wed, 22 Mar 2017, Bruce Ashfield wrote: > > > On Wed, Mar 22, 2017 at

[OE-core] State of bitbake world, Failed tasks 2017-03-21

This time executed without sstate-cache and downloads directory from previous builds, so there is complete list of QA issues and couple do_fetch failures. == Number of issues - stats == {| class='wikitable' !|Date !!colspan='3'|Failed tasks !!colspan='6'|Failed

[OE-core] [PATCH 3/3] rpm: add a "rpm-build" PROVIDES

rpm 5.x was packaging build tools separately, so we need to unbreak things that relied on that. [YOCTO #11167] Signed-off-by: Alexander Kanavin --- meta/recipes-devtools/rpm/rpm_git.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git

[OE-core] [PATCH 1/3] oeqa: use WORKDIR/oe-testimage-repo to look for RPM packages

Using RPM deploy dir was causing errors when pre-built images were used with these steps: https://wiki.yoctoproject.org/wiki/Quality_Assurance_yocto_project [YOCTO #11173] Signed-off-by: Alexander Kanavin --- meta/lib/oeqa/runtime/cases/dnf.py | 2 +- 1 file

[OE-core] [PATCH 2/3] sign_rpm.bbclass: do not set/use RPM_GPG_PUBKEY

This is entirely unnecessary (we can ask the signer backend to export the key to a file when needed), and was causing confusing selftest failures due to the variable being set from two different places. [YOCTO #11191] Signed-off-by: Alexander Kanavin ---

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On Wed, Mar 22, 2017 at 8:24 AM, Robert P. J. Day wrote: > > proper attributions seem to have been totally lost here ... > > On Wed, 22 Mar 2017, Bruce Ashfield wrote: > > > On Wed, Mar 22, 2017 at 8:02 AM, Burton, Ross > wrote: > > > > On

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

proper attributions seem to have been totally lost here ... On Wed, 22 Mar 2017, Bruce Ashfield wrote: > On Wed, Mar 22, 2017 at 8:02 AM, Burton, Ross wrote: > > On 22 March 2017 at 11:57, Bruce Ashfield > wrote: > So where

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On Wed, Mar 22, 2017 at 8:02 AM, Burton, Ross wrote: > > On 22 March 2017 at 11:57, Bruce Ashfield > wrote: > >> So where are they supposed to be specified ? Surely not a separate distro >> .conf ? and most >> certainly not in local.conf ... I've

Re: [OE-core] [PATCH v4 0/5] wic: selftest: enhancements for non-x86 MACHINE support & fixed-size tests

Hi Maciej, The patchset looks great! Thank you! On Tue, Mar 21, 2017 at 12:35:00PM +0100, Maciej Borzecki wrote: > v4 of a series with enhancements and new test cases for wic selftest. > The enhancements allow for running wic selftest for non-x86 MACHINE, > such as qemuarm (the whole series was

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On 22 March 2017 at 11:57, Bruce Ashfield wrote: > So where are they supposed to be specified ? Surely not a separate distro > .conf ? and most > certainly not in local.conf ... I've always been unsure of where the right > place to specify > versions like that. > If it

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On Wed, Mar 22, 2017 at 7:19 AM, Burton, Ross wrote: > > On 22 March 2017 at 11:14, Robert P. J. Day wrote: > >> so, just to be clear, the simple act of adding that layer to a >> project's bblayers.conf file will cause those preferred versions to >>

Re: [OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

On 22 March 2017 at 11:14, Robert P. J. Day wrote: > so, just to be clear, the simple act of adding that layer to a > project's bblayers.conf file will cause those preferred versions to > be selected, correct? > > is that considered good design? in a perfect world, i've

[OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

i'm just adding some content to intro OE/YP wiki pages about what various OE files should contain, and what they shouldn't contain, and this is the layer.conf file for the meta-openstack layer: # We have a conf and classes directory, append to BBPATH BBPATH .= ":${LAYERDIR}" # We have a

Re: [OE-core] [PATCH 0/4] [V3] Fix some issues of kernel/image recipes

On 21 March 2017 at 14:34, wrote: > > The changes in V3: > 1 Drop one patch which is problematic. > 2 Change a conditional checking line in kernel-initramfs.bb: > From: "if type != 'vmlinux' or d.getVar('KERNEL_IMAGETYPE') == 'vmlinux':" > To: "if type != 'vmlinux' or

Re: [OE-core] possible content for site.conf?

On Wed, 22 Mar 2017, Burton, Ross wrote: > > On 22 March 2017 at 10:51, Robert P. J. Day wrote: >   from site.conf.sample, the obvious content is things like: > > * download dir > * reference to local (in-house) source mirror > * http

Re: [OE-core] possible content for site.conf?

On 22 March 2017 at 10:51, Robert P. J. Day wrote: > from site.conf.sample, the obvious content is things like: > > * download dir > * reference to local (in-house) source mirror > * http proxies/fetching configuration > > and so on. any other things people throw into

[OE-core] possible content for site.conf?

i'm documenting what one might *properly* put in a site.conf file, since i've been seeing examples of people loading it with references to recipes and images and so on, which is totally inappropriate. from site.conf.sample, the obvious content is things like: * download dir * reference to

Re: [OE-core] [PATCH 1/1] runqemu-gen-tapdevs: fix file path in example

On Wed, 2017-03-22 at 17:23 +0800, Chen Qi wrote: > Fix the path in example so that '/usr/bin/tunctl' could be found under > this path. > > Signed-off-by: Chen Qi > --- >  scripts/runqemu-gen-tapdevs | 2 +- >  1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

[OE-core] [PATCH] sstate: Ensure installation directory is empty before execution

When you enable the systemd DISTRO_FEATURE, opkg-native contains systemd units which have a relocation fixme list. When systemd isn't in DISTRO_FEATURES, there are no fixmes required. Unfortunately as sstate isn't cleaning up its installation directory before use, if you install the systemd

[OE-core] [PATCH 1/1] runqemu-gen-tapdevs: fix file path in example

Fix the path in example so that '/usr/bin/tunctl' could be found under this path. Signed-off-by: Chen Qi --- scripts/runqemu-gen-tapdevs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/runqemu-gen-tapdevs b/scripts/runqemu-gen-tapdevs index

[OE-core] [PATCH 0/1] runqemu-gen-tapdevs: fix file path in example

The following changes since commit 9fc3fec4499e6110031245d7b56e580c903e77e5: Revert "file: update SRCREV for 5.30 to fix fetch fail on missing commit" (2017-03-21 22:39:17 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/example-path