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 recipe which provides
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 appe
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 unma
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:
> http://lists.openem
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
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 (i.e
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 to
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
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 computat
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 b
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 fine
> -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
> 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 test
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 original
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 file changed, 1 insertion(+),
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 w
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 +-
meta/classes/package.bbclass
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
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
https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#crea
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
> > > but it reduces glibc baggage for fut
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: 11ebb5054e5ec1171ade90249e3a30ac8174a35a)
>
> Signed-of
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 will definitely do this?
>
I have st
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
and
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
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
>
> This and atk
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:
https://autobuilder.yocto.io/builders/nightly-x32/builds/9
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.
> libcrypt is now provided by libxcrypt as ex
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
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 b
[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
b/scripts/lib/checklayer/__init__.py
index 288c457822d..2618416f
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
> 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 manifest
== 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 propos
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 +++
meta/recipes-devtools/perl/perl_5.2
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 c
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 F
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 lo
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 deletions(-)
diff --git a/meta-selftes
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 ROS mailing-list and to ROS
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 wrote:
> 1. i'd like to
== 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
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 | 23 -
2 files chang
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 usin
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 being followed in this li
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
Ope
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
http://wiki.
46 matches
Mail list logo
