On Tue, 2020-05-12 at 14:18 +0100, Richard Purdie wrote:
> The OE TSC would like to ask if there is anyone interested in stepping
> up to look after the dunfell branch of meta-openembedded?
>
> dunfell is an LTS release for Yocto Project and it would be good to
> have some kind o
The OE TSC would like to ask if there is anyone interested in stepping
up to look after the dunfell branch of meta-openembedded?
dunfell is an LTS release for Yocto Project and it would be good to
have some kind of plan for meta-openembedded as well.
We believe the 'policy' for the branch would
On Thu, 2020-05-07 at 15:24 +0200, Alexander Kanavin wrote:
> On Thu, 7 May 2020 at 14:38, Jens Rehsack wrote:
> > > I agree there should be a way to update maintainers e-main once
> > we determine they are not longer willing to take part in that
> > program or absent. I believe this an issue in
On Thu, 2020-04-23 at 22:03 +, Oleksandr Ocheretnyi via
lists.openembedded.org wrote:
> I've noticed that patch
> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/gcc/gcc-9.3/0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch?h=dunfell
> applied to gcc
On Wed, 2020-04-22 at 13:45 +, chris.lapla...@agilent.com wrote:
> > DEPENDS[filter] = "prefix_filter('${MLPREFIX}')
> > suffix_filter('${MY_SUFFIX}')"
> >
> > as it might be more obvious and searchable through grep? I don't
> > like ";" as a
> > delimiter as it doesn't work well with
On Tue, 2020-04-21 at 21:51 -0500, Joshua Watt wrote:
> On Sun, Apr 19, 2020 at 12:04 PM Richard Purdie
> wrote:
> Continuing the discussion from the OE TSC meeting, now that I've had
> a little time to digest the idea: I don't think the filter functions
> are necessarily a ba
On Wed, 2020-04-22 at 08:21 +0100, Paul Barker wrote:
> On Sun, 19 Apr 2020 18:04:34 +0100
> "Richard Purdie" wrote:
>
> > I'm a bit worried about some of the mulitlib issues we've seen
> > recently. In particular we have a bug where license exclusion
> >
I'm a bit worried about some of the mulitlib issues we've seen
recently. In particular we have a bug where license exclusion doesn't
work properly in multilib builds, which is fairly serious.
To dive into the details of what I found, as things stand today, the
code sequence is:
a)
On Mon, 2020-03-09 at 12:52 +0200, Adrian Bunk wrote:
> On Sat, Mar 07, 2020 at 04:17:28PM +0000, Richard Purdie wrote:
> > ...
> > This does mean we could drop gcc 4.8/4.9 support if we wanted to
> > and
> > rely on the tarball support for centos7/debian8.
> > ..
Hi,
I just wanted to mention that we now have the ability to wrap builds on
specific workers with specific buildtools tarballs.
Currently this functionality is in master, we do have the option of
porting the helper code to other stable branches.
We have had multiple issues, with the
On Fri, 2020-03-06 at 12:04 +0200, Adrian Bunk wrote:
> For most community companies there is no clear Return on Investment
> if they would use the opportunity to invest in upstream involvement.
That isn't true. If you fix something yourself and hold the change you
get to maintain it. If you work
Its posted at:
https://www.yoctoproject.org/yocto-project-long-term-support-announced/
but I'll copy it below since this is an important announcement
"""
To fulfill the evolving requirements of its members and users, the
Yocto Project announced a new plan to extend support for selected
releases.
Hi Alex,
Thanks for bringing this up.
On Tue, 2020-02-11 at 13:49 +0100, Alexander Kanavin wrote:
> I'd like to lay out a few ideas/thoughts on what should be done with
> sato (matchbox bits) and X going forward. The inputs are:
>
> - Red Hat is the only company doing X maintenance anymore, and
On Mon, 2020-02-03 at 19:23 +0200, Adrian Bunk wrote:
> On Mon, Feb 03, 2020 at 07:58:54AM -0800, akuster808 wrote:
> > On 2/3/20 1:38 AM, Adrian Bunk wrote:
> > > On Sun, Feb 02, 2020 at 11:48:49PM +0000, Richard Purdie wrote:
> > > > On Mon, 2020-02-03 at
On Mon, 2020-02-03 at 01:13 +0200, Adrian Bunk wrote:
> 1. The Yocto focus on point releases is below the standard of other
>distributions (also for non-LTS stable series)
>
> Having well-tested point releases every 3 or 6 months sounds good at
> first sight. The problem is that most
Hi,
This is ultimately a decision the YP TSC will need to make (it concerns
YP testing) but I wanted to give people an opportunity to provide
feedback.
There are two patch series for OE-Core master which both break meta-
gplv2. I personally have no enthusiasm for that layer and I don't think
its
There has been a lot of discussion about stable releases and how the
project might handle them going forward. The TSC has put together some
process/policy information on the project wiki:
https://wiki.yoctoproject.org/wiki/LTS
As part of this we've included information about how an LTS could
On Wed, 2019-12-11 at 14:13 +0200, Adrian Bunk wrote:
> On Wed, Dec 11, 2019 at 10:29:27AM +0000, Richard Purdie wrote:
> > On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
> > > On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
> > > Openembedde
On Wed, 2019-12-11 at 11:18 +0100, Andreas Müller wrote:
> On Wed, Dec 11, 2019 at 8:15 AM Diego Santa Cruz via
> Openembedded-architecture
> wrote:
> > > -Original Message-
> > > From: openembedded-architecture-boun...@lists.openembedded.org
> > > On
> > > Behalf Of
> > > Khem Raj
> > >
I just enabled hashequiv's server in local mode by default in poky.
This causes an unintended side effect of requiring python 3.5 as the
minimum version.
We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is also
extremely
On Mon, 2019-12-02 at 17:19 -0600, Mark Hatle wrote:
>
> On 12/2/19 3:58 PM, Richard Purdie wrote:
> > On Mon, 2019-12-02 at 15:37 -0600, Mark Hatle wrote:
> > > In all of the above examples, the user has manually configured
> > > the
> > > multiconfig withi
On Mon, 2019-12-02 at 15:27 -0800, Alejandro Enedino Hernandez
Samaniego wrote:
> So I have tried something similar to this, and while it does work,
> due to some parsing issue (I still have not figured out exactly what)
> the multiconfig dependencies between multiconfigs are not being taken
>
On Mon, 2019-12-02 at 21:58 +, Richard Purdie wrote:
> On Mon, 2019-12-02 at 15:37 -0600, Mark Hatle wrote:
> > In all of the above examples, the user has manually configured the
> > multiconfig within their project. There is a simple way to move
> > that
> > confi
It is with reluctance, after discussion with the TSC, that we've
decided to disband the build failure SWAT process.
The reason is simple, there were no longer enough people willing to
participate in the process to make it viable.
This process was there to try and offload some of the build
On Sat, 2019-10-26 at 10:34 -0400, Rich Persaud wrote:
> On Oct 26, 2019, at 7:11 AM, richard.pur...@linuxfoundation.org
> wrote:
> > On Fri, 2019-10-25 at 16:04 -0400, Rich Persaud wrote:
> > > There may be lessons in Microsoft's move from diverse hardware to
> > > VM-
> > > based testing:
> > >
On Fri, 2019-10-25 at 16:04 -0400, Rich Persaud wrote:
> There may be lessons in Microsoft's move from diverse hardware to VM-
> based testing:
> https://www.ghacks.net/2019/09/23/former-microsoft-employee-explains-why-bugs-in-windows-updates-increased/
I don't disagreed, real hardware does have
I'm posting this to openembedded-architecture since it probably is the
best place for discussions about OE/Yocto planning.
The Yocto Project TSC believes one of the things needed for YP and for
OE is more information being pulled together about how an LTS release
could work. The document linked
On Mon, 2019-07-15 at 15:35 +0100, Burton, Ross wrote:
> On Mon, 15 Jul 2019 at 15:33,
> wrote:
> > > Would you expect the yocto LSB kernels support move to that layer
> > > as
> > > well? IIRC, these the the ones that build the LTS kernels.
> >
> > No, "poky-lsb" should really be renamed
On Mon, 2019-07-15 at 07:25 -0700, akuster808 wrote:
> On 7/15/19 2:34 AM, Richard Purdie wrote:
> > Its been discussed before and I think everyone agrees that it
> > should
> > move to its own layer. I will therefore take a patch which does
> > that.
> >
>
On Wed, 2019-06-12 at 08:44 -0500, Joshua Watt wrote:
> On 6/12/19 7:35 AM, Richard Purdie wrote:
> > I'm not 100% sure whether I like this idea or not but wanted to
> > share
> > it and see what others think.
> >
> > We're looking at a recipe which
Apologies for cross posting but I wanted a wider audience to see this.
The triage team is starting to try and collect up and classify bugs
which a newcomer to the project would be able to work on in a way which
means people can find them. They're being listed on the triage page
under the
Hi All,
I just wanted to highlight that we're in the planning process for 2.8.
The google doc we're using for brainstorming is here:
https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU/
I've gone through and turned most of the things I contributed there
into bugs in
On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote:
>
> On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote:
> > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote:
> > > On 4/9/19 8:52 PM, Richard Purdie wrote:
> > > > I'm sorry to have to say th
I'm sorry to have to say this but the project is terminating its
official eclipse plugin support with immediate effect.
There is nobody willing to keep the builds going, fix bugs, port to new
eclipse releases or release the current plugin. This has been raised in
many forums, multiple times and
On Mon, 2019-03-18 at 10:26 -0500, Mark Hatle wrote:
> Let me start out with, I'm not against this proposal.
>
> But, I want to mention the cases in my experience where people get
> upset with version numbers changing.
>
> 1) "Regulated devices". For some reason there are a class of devices
>
On Mon, 2019-03-18 at 10:46 -0400, Tom Rini wrote:
> On Mon, Mar 18, 2019 at 02:01:37PM +, Burton, Ross wrote:
> > I don't really have a strong opinion on the mechanics behind
> > documenting the behaviour, but how do we decide what upstreams have
> > a
> > suitable stable release? We don't
On Mon, 2019-03-18 at 15:59 +0100, Martin Jansa wrote:
> On Mon, Mar 18, 2019 at 12:49:17PM +0000, Richard Purdie wrote:
> > Recently this issue came to light around some lttng* version
> > upgrades.
> > I do think that particular upstream is in keeping with what we'd
> &
On Mon, 2019-03-18 at 10:30 -0400, Jonathan Rajotte-Julien wrote:
> Note I did not cc the mailing list since
> I think it is moving the discussion away from the main focus.
It did make the list and FWIW I think it is important to ensure people
understand why we're dropping certain patches or
On Mon, 2019-03-18 at 14:01 +, Burton, Ross wrote:
> On Mon, 18 Mar 2019 at 12:49, Richard Purdie
> wrote:
> > My proposal is therefore that where an upstream has a stable
> > release
> > mechanism, we should work with that in OE-Core, taking direct
> > stable
&g
Since we established the stable branch maintenance guidelines for OE-
Core the world has changed a little. I'd like to propose we update the
guidelines to reflect this changing world and the current best
practises.
Partly this change has been influenced by a discussion I was part of
where GregKH
I wanted to mention we now have a few developments working in our QA
process/tooling workflow.
---
In summary:
We have buildhistory data comparing -next/mut builds to master:
On Thu, 2019-02-21 at 20:09 -0500, Rich Persaud wrote:
> > On Feb 21, 2019, at 18:51, Richard Purdie <
> > richard.pur...@linuxfoundation.org> wrote:
> >
> > Multiconfig is meant to support this workflow. Unfortunately there
> > are
> > open bugs and pe
On Thu, 2019-02-21 at 20:09 -0500, Rich Persaud wrote:
> > On Feb 21, 2019, at 18:51, Richard Purdie <
> > richard.pur...@linuxfoundation.org> wrote:
> >
> > Multiconfig is meant to support this workflow. Unfortunately there
> > are
> > open bugs and pe
Multiconfig is meant to support this workflow. Unfortunately there are
open bugs and people haven't the time to work on it so its stalled.
That said, the key pieces are already there.
A picture is worth a thousand words. I thought a demo might interest
people and "prove" this can work.
To make
On Tue, 2018-09-04 at 16:18 +1200, Paul Eggleton wrote:
> Hi folks,
>
> In the layer index / RRS code I have found that if it tries to use
> bitbake's git fetcher to access a git repository on github that has
> been renamed or gone private via http/https, I get prompted for a
> password
201 - 245 of 245 matches
Mail list logo
