Re: [OE-core] [RFC PATCH] devicetree.bbclass: User/BSP device tree source compilation class

Acked-by: Martin Hundebøll Thanks Nathan; this could be very useful for us. // Martin On 2018-04-05 12:48, Nathan Rossi wrote: This bbclass implements the device tree compilation for user provided device trees. In order to use this class, it should be inherited in a BSP

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

Thanks Richard https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LAYERSERIES_COMPAT Scott On Fri, Apr 6, 2018 at 3:25 PM, Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Fri, 2018-04-06 at 11:16 -0700, Scott Rifenbark wrote: > > We have this variable

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

On Fri, 2018-04-06 at 11:16 -0700, Scott Rifenbark wrote: > We have this variable appearing in a couple manuals BTW.  If anyone > has any feedback on what is being said here I can update. Some small suggested tweaks: "Using the LAYERSERIES_COMPAT variable makes it clear when a given layer is

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

On Fri, 2018-04-06 at 20:25 +0200, Martin Jansa wrote: > FWIW: I've updated some layers with this LAYERSERIES_COMPAT_ > today and I think it's good idea. Thanks. I know its late in the cycle but I think it will help. > It probably won't be enough to stop questions like this: >

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

On Fri, 2018-04-06 at 13:46 -0700, akuster808 wrote: > Shouldn't Master get all these changes first then we switch to stable > branch when we have a new release? > > My German genes are raging about "Rules" ; ) master did get them? To be really clear, "master" is never a value that would appear

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

On Fri, 2018-04-06 at 14:58 -0400, Denys Dmytriyenko wrote: > I understand the need to reduce the support burden. But there are > some valid  > cases when you want to use components/layers from a different set of > releases.  > > It can sometimes be an older component in otherwise newer setup

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

Shouldn't Master get all these changes first then we switch to stable branch when we have a new release? My German genes are raging about "Rules" ; ) - armin On 04/06/2018 08:29 AM, Richard Purdie wrote: > On Fri, 2018-04-06 at 10:16 -0400, Trevor Woerner wrote: >> A) Some layers only switch

Re: [OE-core] [morty][PATCH 1/2] glibc: add missing TRAP_BRANCH/TRAP_HWBKPT definitions

On 04/06/2018 10:08 AM, Daniel Díaz Rodríguez wrote: > Ping on this series for Morty. This needs to be ported to Pyro first. I do it this weekend and morty too. - armin > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org

[OE-core] [PATCH 1/1] python-xcbgen_1.12: improve reproducibility

In order to remove timestamps from all .pyc files we need to recompile them with python3-native, as we cannot rely on the host python being able to do that. Both python-native and python3-native derive the timestamp from SOURCE_DATE_EPOCH if present. However, building python3-native can be

[OE-core] [PATCH 0/1] python-xcbgen: improve reproducibility

This patch addresses the last remaining non-reproducible package for core-image-minimal (with current "sumo"). A short explanation: When building core-image-minimal in two different folders with current "sumo" (http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=sumo ) : $ source oe-build-env

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

I understand the need to reduce the support burden. But there are some valid cases when you want to use components/layers from a different set of releases. It can sometimes be an older component in otherwise newer setup (i.e. one layer hasn't been updated yet from rocko, but it still works

Re: [OE-core] ✗ patchtest: failure for Fix problem with leftover files in tmp/sysroots-components

> -Original Message- > From: Patchwork [mailto:patchw...@patchwork.openembedded.org] > Sent: den 6 april 2018 20:34 > To: Peter Kjellerstedt > Cc: openembedded-core@lists.openembedded.org > Subject: ✗ patchtest: failure for Fix problem with leftover files in >

[OE-core] ✗ patchtest: failure for Fix problem with leftover files in tmp/sysroots-components

== Series Details == Series: Fix problem with leftover files in tmp/sysroots-components Revision: 1 URL : https://patchwork.openembedded.org/series/11706/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several

[OE-core] [PATCH 0/3] Fix problem with leftover files in tmp/sysroots-components

We have seen problems where sometimes files are leftover in tmp/sysroots-components when changing PACKAGE_ARCH for a package. This could then lead to those files being picked up instead of the real files when the RSS for another package was created. It turned out that this happened if the

[OE-core] [PATCH 1/3] Use ${MACHINE_ARCH} instead of ${MACHINE} for stamp-extra-info task flag

Without this change, there will be two sstate index files in tmp/sstate-control for any machine that contains a dash in the name. Signed-off-by: Peter Kjellerstedt --- meta/classes/deploy.bbclass| 2 +- meta/classes/image.bbclass | 2 +-

[OE-core] [PATCH 3/3] license.bbclass: Minor simplification of get_deployed_dependencies()

Since ${SSTATE_ARCHS} now contains ${PACKAGE_EXTRA_ARCHS} there is no longer any need to add those extra architectures to the list of architectures handled in get_deployed_dependencies(). Signed-off-by: Peter Kjellerstedt --- meta/classes/license.bbclass | 4 +--- 1

[OE-core] [PATCH 2/3] sstate.bbclass: Add ${PACKAGE_EXTRA_ARCHS} to SSTATE_ARCHS

This makes sure files provided by packages that use any of the extra architectures defined using ${PACKAGE_EXTRA_ARCHS} are cleaned from tmp/sysroot-components when sstate_eventhandler2() executes. Without this, changing a package from using one of the extra architectures to another architecture

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

FWIW: I've updated some layers with this LAYERSERIES_COMPAT_ today and I think it's good idea. It probably won't be enough to stop questions like this: http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149696.html but it's still better to show warning first and then some often

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

We have this variable appearing in a couple manuals BTW. If anyone has any feedback on what is being said here I can update. Thanks, Scott https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LAYERSERIES_COMPAT

Re: [OE-core] [PATCH 0/2] Split glibc and libcrypt

On Fri, 2018-04-06 at 09:27 -0700, Khem Raj wrote: > On Fri, Apr 6, 2018 at 8:42 AM, Richard Purdie > wrote: > > > > On Fri, 2018-04-06 at 08:03 -0700, Khem Raj wrote: > > > > > > this series is ok. Although dont like the fact its not upstream > > > yet > > >

Re: [OE-core] [morty][PATCH 1/2] glibc: add missing TRAP_BRANCH/TRAP_HWBKPT definitions

Ping on this series for Morty. -- ddiaz On 13 March 2018 at 11:17, Daniel Díaz wrote: > From: Fathi Boudra > > Patch submitted upstream, pending to be merged: > https://sourceware.org/bugzilla/show_bug.cgi?id=21286 > > (From OE-Core rev:

Re: [OE-core] [PATCH 0/2] Split glibc and libcrypt

On Fri, Apr 6, 2018 at 8:42 AM, Richard Purdie wrote: > On Fri, 2018-04-06 at 08:03 -0700, Khem Raj wrote: >> this series is ok. Although dont like the fact its not upstream yet >> but it reduces glibc baggage for future. > > Were you able to find out if glibc

Re: [OE-core] [PATCH 0/2] Split glibc and libcrypt

On Fri, 2018-04-06 at 08:03 -0700, Khem Raj wrote: > this series is ok. Although dont like the fact its not upstream yet > but it reduces glibc baggage for future. Were you able to find out if glibc will definitely do this? I think applying this nativesdk is the only thing we can do right now

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

On Fri, 2018-04-06 at 10:16 -0400, Trevor Woerner wrote: > A) Some layers only switch to an official branch name when the find a > reason to. E.g. branch "sumo" is created on openembedded-core but > meta-A keeps working on master unless an incompatible change is > created in openembedded-core that

Re: [OE-core] [PATCH 04/10] at-spi2-atk: upgrade to version 2.26.2

Hi RP, On Fri, Apr 06, 2018 at 04:05:36PM +0100, Richard Purdie wrote: > On Wed, 2018-04-04 at 18:32 +0300, Maxin B. John wrote: > > 1. convert to meson build > > 2. inherit gnomebase and associated cleanup > > 3. add libxml2 to DEPENDS list > > > > Signed-off-by: Maxin B. John

Re: [OE-core] [PATCH 04/10] at-spi2-atk: upgrade to version 2.26.2

On Wed, 2018-04-04 at 18:32 +0300, Maxin B. John wrote: > 1. convert to meson build > 2. inherit gnomebase and associated cleanup > 3. add libxml2 to DEPENDS list > > Signed-off-by: Maxin B. John This and atk seem to fail in gir on x32:

Re: [OE-core] [PATCH 0/2] Split glibc and libcrypt

this series is ok. Although dont like the fact its not upstream yet but it reduces glibc baggage for future. On Fri, Apr 6, 2018 at 5:53 AM, Charles-Antoine Couret wrote: > Fedora 28 is introducing a breaking change where glibc and libcrypt are split. >

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

A) Some layers only switch to an official branch name when the find a reason to. E.g. branch "sumo" is created on openembedded-core but meta-A keeps working on master unless an incompatible change is created in openembedded-core that forces meta-A to create a "sumo" branch. B) Other layers create

Re: [OE-core] [PATCH 00/38] Morty Next pull request

In this build I was starting with empty TMPDIR, there shouldn't be any old files, but will retry manually in different builds. On Fri, Apr 6, 2018 at 4:11 PM, Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Fri, 2018-04-06 at 16:07 +0200, Martin Jansa wrote: > > > Is it safe to

[OE-core] [PATCH] yocto-check-layer: add a test for correct setting of LAYERSERIES_COMPAT_collection

[YOCTO #12661] Signed-off-by: Alexander Kanavin --- scripts/lib/checklayer/__init__.py | 2 ++ scripts/lib/checklayer/cases/common.py | 5 + 2 files changed, 7 insertions(+) diff --git a/scripts/lib/checklayer/__init__.py

Re: [OE-core] [PATCH 00/38] Morty Next pull request

On Fri, 2018-04-06 at 16:07 +0200, Martin Jansa wrote: > > Is it safe to backport to morty, which doesn't have RSS? > > It doesn't work well for me, all the builds are now failing with: > > ERROR: glibc-2.24-r0 do_stash_locale_setscene: The recipe glibc is > trying to install files into a shared

Re: [OE-core] [PATCH 00/38] Morty Next pull request

> Is it safe to backport to morty, which doesn't have RSS? It doesn't work well for me, all the builds are now failing with: ERROR: glibc-2.24-r0 do_stash_locale_setscene: The recipe glibc is trying to install files into a shared area when those files already exist. Those files and their

[OE-core] ✗ patchtest: failure for Split glibc and libcrypt

== Series Details == Series: Split glibc and libcrypt Revision: 1 URL : https://patchwork.openembedded.org/series/11702/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the

[OE-core] [PATCH 1/2] glibc: split glibc and libcrypt

According to Fedora 28 change (https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt) and probably glibc upstream change, the nativesdk provides libcrypt from libxcrypt instead of pproviding from glibc itself. The purpose is to provide one uninative file compatible with

[OE-core] [PATCH 2/2] perl: add patch to solve libcrypt incompatibility

Add Perl's patch submitted to upstream to be compiled along with glibc with libcrypt split. Signed-off-by: Charles-Antoine Couret --- .../perl/perl-native_5.24.1.bb| 1 + .../perl-5.26.1-guard_old_libcrypt_fix.patch | 27

[OE-core] [PATCH 0/2] Split glibc and libcrypt

Fedora 28 is introducing a breaking change where glibc and libcrypt are split. libcrypt is now provided by libxcrypt as external library. It is backwards compatible, but not the converse. Currently Poky could not be compiled with Fedora 28 and the official yocto-uninative. The purpose of these

[OE-core] LAYERSERIES

I finally found 5 mins to sit and look at where I'd gotten to with the LAYERSERIES variable handling. I sent out discussion about this a while ago but as a reminder: We have a problem where people expect master branch of meta-X to work with OE-Core master. If meta-X hasn't been maintained for a

[OE-core] [PATCH] layer.conf: Update LAYERSERIES rocko -> sumo

Also set LAYERSERIES_COMPAT for core (we're compatible with ourself). Signed-off-by: Richard Purdie --- meta-selftest/conf/layer.conf | 2 +- meta-skeleton/conf/layer.conf | 2 +- meta/conf/layer.conf | 5 +++-- 3 files changed, 5 insertions(+), 4

Re: [OE-core] [oe] [meta-ros] ros build error on poky

Your error [name 'oe_filter_out' is not defined] means you don't have oe_filter_out function defined in poky/meta/classes/utils.bbclass 2018-04-06 11:06 GMT+02:00 Rajath C S : > i understand that this isnt specific to ros queries but i do have posted > the same at the

Re: [OE-core] [oe] [meta-ros] ros build error on poky

i understand that this isnt specific to ros queries but i do have posted the same at the ROS mailing-list and to ROS maintainers and the issue is to be yet resolved perfectly. Thanks Rajath C S, 9964182112, Bangalore - 560060 On Fri, Apr 6, 2018 at 12:34 PM, Rajath C S

[OE-core] ✗ patchtest: failure for libxcalibrate: Drop, no users anymore

== Series Details == Series: libxcalibrate: Drop, no users anymore Revision: 1 URL : https://patchwork.openembedded.org/series/11696/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed

[OE-core] [PATCH] libxcalibrate: Drop, no users anymore

xcalibrate was replaced with other xinput touchscreen protocols, drop this remaining remnant. Signed-off-by: Richard Purdie --- .../xorg-lib/libxcalibrate/fix-xcb.patch | 29 -- .../recipes-graphics/xorg-lib/libxcalibrate_git.bb

Re: [OE-core] [PATCH 20/22] procps: update to 3.3.13

On 04/05/2018 07:43 PM, Richard Purdie wrote: Does this build on musl? https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/389/st eps/BuildImages/logs/stdio or was there some other bad interaction in master-next? My bad, please remove the commit. The new version of procps is

Re: [OE-core] [oe] [meta-ros] ros build error on poky

Hi, You should contact ROS mailing-list or ROS maintainers, see https://github.com/bmwcarit/meta-ros#important-resources https://github.com/bmwcarit/meta-ros#maintainers Best regards, Vincent 2018-04-06 9:04 GMT+02:00 Rajath C S : > 1. i'd like to know does the process

Re: [OE-core] [PATCH] atk: make sure that introspection is enabled

On 04/06/2018 07:35 AM, Anuj Mittal wrote: Fix the meson flags to make sure that introspection files are built when it is enabled. This does fix the gtk/gtk3 issues observed on AB in master-next, thanks! Alex -- ___ Openembedded-core mailing list

[OE-core] [oe] [meta-ros] ros build error on poky

1. i'd like to know does the process being followed in this link lead us to installation of ROS-kinetic / indigo or others, hope i am clear..? that is want to know if the process of including and compiling meta-ros layer for yocto equal to install ros on ubuntu i mean in literal sense