On Thu, 2024-05-23 at 10:35 +0200, Alexander Kanavin wrote:
> On Wed, 22 May 2024 at 10:24, Richard Purdie
> wrote:
> > So yes, there may well be a long list of things you want to remove from
> > core, however, we also have to think about the project's use and why
> > pe
Hi Alex,
On Wed, 2024-05-22 at 09:53 +0200, Alexander Kanavin via lists.openembedded.org
wrote:
> right now it's extremely difficult to remove anything from oe-core.
> The reasons are that either we don't know how removal will affect
> possible users, or we do know that and we don't want to
Now that there is a roughly ready patchset for this I wanted to write
down a quick guide to converting recipes.
S = ${WORKDIR}
==
If a recipe has S set to be WORKDIR this is no longer supported.
Currently you'll see warnings, those will become errors very soon and
even now, the code
I think I need to write down a bit of a summary status on where we (and
I) am at with things.
The good news is that scarthgap is released. On the downside, we messed
up the public hash server url in local.conf.sample so we have a point
release in progress to fix that.
The Sovereign Tech Fund
On Mon, 2024-04-29 at 09:27 +0200, Esben Haabendal wrote:
> "Richard Purdie" writes:
>
> > ...
> >
> > b) Change recipes that use S = "${WORKDIR}" to
> >
> > S = "${WORKDIR}/sources"
> > UNPACKDIR = "${S}"
&
On Mon, 2024-04-29 at 15:29 +0200, Marta Rybczynska wrote:
> https://medium.com/@cve_program/new-cve-record-format-enables-additional-data-fields-at-time-of-disclosure-82eef1d4035e
>
> Quote:
>
> The CVE Board is proud to announce that the CVE Program has evolved
> its record format to enhance
One interesting side effect I've noticed with testing the a-c patches
was a failure in meta-virtualization.
The issue is a bbappend to sysvinit which does:
"""
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "file://getty-wrapper"
do_install:append() {
install -d
On Sun, 2024-04-28 at 11:10 +0100, Paul Barker wrote:
> On 25/04/2024 22:38, Richard Purdie via lists.openembedded.org wrote:
> > As people probably realise, WORKDIR is a bit of a mess at the moment.
> > do_unpack writes things directly into there and we don't keep track of
>
As people probably realise, WORKDIR is a bit of a mess at the moment.
do_unpack writes things directly into there and we don't keep track of
what it writes there very easily. I know there are source tracer
solutions but the whole situation is messy.
I'd like to try and improve things somehow but
The recent NVD changes have impacted a number of projects and there are
quite a few uneasy developers out there, not just in the Yocto Project
community but much more widely. There could be some simple changes or
process improvements that the CVE Project could make which would
massively help
On Tue, 2024-04-02 at 22:33 +, Peter Kjellerstedt wrote:
>
> To whoever is responsible for updating
> https://www.yoctoproject.org/community/mailing-lists/: the links for
> the two new lists both refer to yocto-announce rather than yocto-
> status and yocto-patches.
That should be fixed
On Fri, 2024-02-23 at 11:02 +0100, Alexander Kanavin wrote:
> As someone completely out of this, I want to ask: should genericarm64
> definition go to a mixin layer until it meets the criteria? Could it
> even be backported to LTS proper when it does? It's a machine
> definition, and so won't
I'm now in a pretty horrible position.
We've now passed feature freeze. This freeze is pretty critical since
it concerns the LTS so if things miss this, they're out for the next
two years. The deadline shouldn't be a surprise to anyone.
I'd "committed" to genericarm64 being a feature for this
On Wed, 2024-02-21 at 10:57 +, Ross Burton wrote:
> From: Ross Burton
>
> This is a new 64-bit "generic" Arm machine, that expects the hardware to
> be SystemReady IR compatible. This is slightly forward-leaning as there's
> not a _lot_ of SystemReady hardware in the wild, but most modern
On Wed, 2024-02-21 at 11:06 +0100, Alexander Kanavin wrote:
> the next missing piece in the official setup and configuration
> management is configuration fragments, so I'd like to describe how I
> see them:
>
> 1. They are regular .inc files, residing in
>
The project is aware that the kernel versions that ship in our next LTS
in April will likely not have support for the full lifetime of our LTS
(four years). We've been asked a few questions about this so we wanted
to write down what our plan is.
Our intent is to support the versions we ship with
On Mon, 2024-01-08 at 17:08 +, chris.lapla...@agilent.com wrote:
> > > Having thought a bit more about this, I've wondered if
> > > "inherit_defer"
> > > is slightly better phrasing than "inherit_deferred".
> > >
> >
> > FWIW. I like the new syntax, as the semantics of variable use in
> >
On Tue, 2024-01-02 at 23:47 +, Richard Purdie via
lists.openembedded.org wrote:
> It isn't every day I propose new syntax and the bar for doing so is
> high but I think we have a good case for making his change.
>
> I've put together a proof of concept patch here
It isn't every day I propose new syntax and the bar for doing so is
high but I think we have a good case for making his change.
I've put together a proof of concept patch here:
https://lists.openembedded.org/g/bitbake-devel/message/15738
The idea is to add syntax for:
inherit_deferred
On Tue, 2024-01-02 at 14:28 +0100, Adrian Freihofer wrote:
> On Wed, 2023-12-27 at 07:03 +, Peter Kjellerstedt via
> lists.openembedded.org wrote:
> > > -Original Message-
> > > From:
> > > openembedded-architecture@lists.openembedded.org > > architect...@lists.openembedded.org> On
I wanted to share/summarise my findings on the recent qemurunner
changes as the patches themselves are quite dry and the shear horror of
what is happening is at risk of getting lost.
Whilst I'm fully aware of our stable branch policies, there is probably
a case for making a more invasive change
On Tue, 2023-12-19 at 13:19 -0700, Joshua Watt wrote:
> This message is to start a discussion about removal of undesired
> recipe PACKAGECONFIG options.
>
> Background:
> Since the dawn of using OpenEmbedded as part of my day job, we've used
> meta-gplv2 to avoid GPLv3 code in our products.
On Wed, 2023-12-20 at 22:07 +0100, Alexander Kanavin wrote:
> FWIW, I think that the right way out is to convert all recipes to use
> = for default PACKAGECONFIG sets., and drop the confusing ?=/??=
> stuff. What we should offer is a sane default, and an easy, obvious
> way to add and subtract
On Thu, 2023-12-07 at 07:59 -0700, Joshua Watt wrote:
> On Thu, Dec 7, 2023 at 5:36 AM Ross Burton
> wrote:
> >
> > For many years we’ve been carrying patches to recipes to move some
> > libraries or binaries into /bin and /lib, on the argument that
> > people might have /usr on another mount.
>
I keep seeing people argue that adding dependencies between setscene
tasks "is fine" and "just works" and isn't a problem.
It is probably apparent that I get really nervous about doing this and
yet I've not been able to articulate clearly why this is such a really
bad idea. Having dug into it
On Tue, 2023-11-07 at 06:30 -0800, Mathieu Anquetin wrote:
>
> >
> > Also, the packages wouldn't be that useful since if you change
> > VIRTUAL-RUNTIME_init-manager, all the packages are going to end up
> > being rebuilt anyway.
> >
> > As such, I think the proposed solution would need a lot
On Tue, 2023-11-07 at 09:30 +, ANQUETIN Mathieu wrote:
> Hello all,
>
> I would like to discuss an architecture solution to ease support for
> alternative init systems.
>
> As of now, OpenEmbedded supports sysvinit and systemd as first-class
> citizens but does so by including required files
On Sat, 2023-11-04 at 11:29 +0100, adrian.freiho...@gmail.com wrote:
> Hi Alex, hi Richard
>
> After some internal discussions, I would like to clarify my previous
> answers on this topic.
>
> * Usually there are two different workflows
> - application developers: could use an SDK with a
On Tue, 2023-10-31 at 13:08 +0100, Alexander Kanavin wrote:
> On Mon, 30 Oct 2023 at 16:02, Alexander Kanavin via
> lists.openembedded.org
> wrote:
> > So here's what could be done:
> >
> > - esdk tools become symlinks in poky/scripts/esdk-tools/. esdk
> > environment script puts that in PATH,
On Mon, 2023-10-30 at 14:50 +0100, Alexander Kanavin wrote:
> On Thu, 14 Sept 2023 at 14:56, Richard Purdie
> wrote:
> > There are design elements to this work. We need to work out how we can
> > make eSDK and "normal" builds more similar and less of an overhe
>
> On 10/20/23 05:49, Richard Purdie via lists.openembedded.org wrote:
> > On Fri, 2023-10-20 at 10:56 +0200, Marta Rybczynska wrote:
> > > While working on multiple aspects of security processes, one question
> > > comes back frequently: which are th
On Fri, 2023-10-20 at 11:25 -0400, akuster808 wrote:
>
> On 10/20/23 5:49 AM, Richard Purdie wrote:
> > On Fri, 2023-10-20 at 10:56 +0200, Marta Rybczynska wrote:
> > > While working on multiple aspects of security processes, one question
> > > comes back frequ
On Fri, 2023-10-20 at 10:56 +0200, Marta Rybczynska wrote:
> While working on multiple aspects of security processes, one question
> comes back frequently: which are the layers we support with those
> processes? This has impact on the number of SECURITY.md I will be
> submitting, of configuring
On Tue, 2023-10-17 at 12:09 +0200, Marta Rybczynska wrote:
> Hello all,
> This has been a moment working on the YP security team and I think
> that the current version of the document contains everything that it
> should have to get it a go. Please have a look and let me know if you
> have any
On Fri, 2023-09-29 at 14:06 +0200, Alexander Kanavin wrote:
> On Thu, 28 Sept 2023 at 18:49, Richard Purdie
> wrote:
>
> > I'm curious to see what you find with analysis of bitbake-whatchanged.
>
> I've taken a look a the script. It obtains the current location of
&g
On Thu, 2023-09-28 at 18:43 +0200, Alexander Kanavin wrote:
> On Fri, 22 Sept 2023 at 12:42, Richard Purdie
> wrote:
>
> > Things which used to be problematic:
> >
> > a) changes involving changes to gcc-source since it uses a shared
> > sources stamps which
On Fri, 2023-09-22 at 11:17 +0200, Alexander Kanavin wrote:
> On Thu, 21 Sept 2023 at 16:39, chris.lapla...@agilent.com
> wrote:
>
> > That is very impressive and I'd also love to hear about what heuristics it
> > uses.
>
> It's actually rather simple. It uses glob.glob on stamps in tmp/, then
On Sun, 2023-09-17 at 10:54 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Fri, 2023-09-15 at 22:08 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > Just to follow up with where I got to with this.
> >
> > The problem is that inotify
On Fri, 2023-09-15 at 22:08 +0100, Richard Purdie via
lists.openembedded.org wrote:
> Just to follow up with where I got to with this.
>
> The problem is that inotify isn't delivering change notifications in a
> timely fashion.
>
> With the patch applied and BB_SERVER_TIMEO
On Fri, 2023-09-15 at 15:29 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Fri, 2023-09-15 at 13:59 +, Peter Kjellerstedt wrote:
> >
> > While the problem the patch tried to fix is real, it seems a lot less
> > problematic than the result of applying the pat
On Fri, 2023-09-15 at 10:58 -0400, Philip Balister wrote:
> On 9/15/23 09:59, Peter Kjellerstedt wrote:
> > > -Original Message-
> > > From: bitbake-de...@lists.openembedded.org
> > > On Behalf Of Richard Purdie
> > > Sent: den 15 se
On Fri, 2023-09-15 at 13:59 +, Peter Kjellerstedt wrote:
>
> While the problem the patch tried to fix is real, it seems a lot less
> problematic than the result of applying the patch. So from a release
> perspective, I would keep the current code and possibly add it as a
> known bug to the
On Fri, 2023-09-15 at 09:40 +0100, Richard Purdie via lists.openembedded.org
wrote:
> The question at this point is what do people want me to do. We clearly
> have a really nasty bug in here. The patch is "right" and we do need to
> fix this. If I merge it, I suspect I'm goi
On Thu, 2023-09-14 at 17:28 +0100, Richard Purdie via
lists.openembedded.org wrote:
> We've been chasing bitbake timeouts for a while and it was unclear where
> things
> were blocking on IO. It appears the flush() call in server logging can cause
> pauses up to minutes long on syste
On Thu, 2023-09-14 at 20:51 +0200, Alexander Kanavin wrote:
> On Thu, 14 Sept 2023 at 14:56, Richard Purdie
> wrote:
> > For the task signatures, we need to think about some questions. If I
> > make a change locally, can I query how much will rebuild and how much
On Thu, 2023-09-14 at 13:52 +0200, Alexander Kanavin wrote:
> On Tue, 12 Sept 2023 at 16:44, Stephen Jolley wrote:
> > Alexander Kanavin will be working on the core workflow topic
>
> I am now ready to start doing this, but before I do, I'd like to
> decompose the subject into manageable tasks
It is clear that mips and powerpc usage is in decline. I'm reluctant to
drop support completely as I think it is a valuable asset for OE but I
think the time has come to cut back on the testing we're doing. A lot
of the burden for keeping these alive is falling to a small group of
people who
I've been concerned for a while about the process of adding
documentation influencing changes. Our docs are in a separate repo and
this does have advantages. They do span multiple areas of the project
and in general this does work well for us. It does mean the docs are
consistent and have a common
Hi All,
The OE TSC has been aware of the feedback around our contributions
process and the state of our docs on the subject, with many different
wiki pages, some of which disagree with each other.
It isn't something a newcomer to the project can untangle, it needed
people with authority and in
On Fri, 2023-08-18 at 16:01 +, Peter Kjellerstedt wrote:
>
> I think we can live without it. If I am not mistaken we can always
> inject our extra information by doing something like
> PKGV:append = "${MAINTPV}" in recipes where we need it and then rely on
> your code to add the SHA-1 if
On Tue, 2023-08-15 at 15:11 +, chris.lapla...@agilent.com wrote:
> Hi Richard,
>
> > I tried some experiments and this doesn't actually turn out to be so
> > difficult
> > to do. I've included a patch below which basically drops the SRCPV pieces
> > into PKGV, the conditional can probably be
On Tue, 2023-08-15 at 21:27 +, Peter Kjellerstedt wrote:
>
> I decided to give the related changes you have in master-next a try. I
> cherry-picked the following three commits:
>
> bitbake: fetch2: Add new srcrev fetcher API
> recipes/classes/scripts: Drop SRCPV usage in OE-Core
>
On Tue, 2023-08-15 at 21:27 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-architecture@lists.openembedded.org
> > On Behalf Of
> > Richard Purdie
> > Sent: den 10 augusti 2023 18:53
> > To: openembedded-architecture
On Tue, 2023-08-08 at 10:10 +0100, Richard Purdie via lists.openembedded.org
wrote:
> There is a recent discussion about AUTOREV which has got me thinking a
> bit about the big picture and incremental development.
>
> Currently AUTOREV injects into PV. The reasons for that are histor
On Wed, 2023-08-09 at 22:49 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Wed, 2023-08-09 at 14:03 +, Peter Kjellerstedt wrote:
> >
> > One question though: would any of this make it possible to use
> > ${AUTOREV} together with BB_SRCREV_POLICY = "ca
On Wed, 2023-08-09 at 14:03 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-architecture@lists.openembedded.org
> > > architect...@lists.openembedded.org> On Behalf Of Richard Purdie
> > Sent: den 8 augusti 2023 11:11
>
On Wed, 2023-08-09 at 08:21 -0500, Ryan Eatmon via
lists.openembedded.org wrote:
> We are seeing a lot failures with the git.openembedded.org server while
> running our regular CICD builds. Does the server need to be kicked or
> something? Also, is the right list to report/discuss issues like
There is a recent discussion about AUTOREV which has got me thinking a
bit about the big picture and incremental development.
Currently AUTOREV injects into PV. The reasons for that are historical,
when OE was not taskhash based we had to do that to trigger updates.
There are now different ways
On Mon, 2023-07-24 at 10:21 -0400, Alex Stewart wrote:
>
> On 7/24/23 09:37, Richard Purdie wrote:
> > On Mon, 2023-07-24 at 09:23 -0400, Alex Stewart wrote:
> > > Thanks for the feedback. Does anyone on the list know who the authority
> > > would be to approve (or d
On Mon, 2023-07-24 at 09:23 -0400, Alex Stewart wrote:
> Thanks for the feedback. Does anyone on the list know who the authority
> would be to approve (or deny) this move would be? I can make a
> recommendation as the repo maintainer, but I'm not sure I have the
> *ownership* to change the
Hi All,
I'm sending this to oe-arch as it seems the best place to
mention/discuss it.
After reading an email about encouraging best practises when supporting
older software releases, it got me thinking about our LTS and spdx/sbom
support. We don't have create-spdx there and our official policy
On Tue, 2023-02-28 at 22:28 -0500, Denys Dmytriyenko wrote:
> On Sat, Feb 25, 2023 at 10:24:17AM +0000, Richard Purdie wrote:
> > Hi All,
>
>
>
> > Reasons vary but the easy to understand case is where the code is just
> > development headers and all ends up in ${P
Hi All,
There has been some interest in some older bugs about empty packages
and bogus dependencies and what we should do about them. Yohan and
Fawzi were kind enough to post some patches to prompt some discussion
and this did indeed get me thinking.
I personally think that we shouldn't be
On Sat, 2022-12-31 at 10:47 -0600, Mark Hatle wrote:
>
> On 12/29/22 9:06 AM, Richard Purdie wrote:
> > On Thu, 2022-12-29 at 08:50 -0600, Joshua Watt wrote:
> > > On Thu, Dec 29, 2022 at 7:56 AM Richard Purdie
> > > wrote:
> > > >
> > > > I
On Thu, 2022-12-29 at 08:50 -0600, Joshua Watt wrote:
> On Thu, Dec 29, 2022 at 7:56 AM Richard Purdie
> wrote:
> >
> > I was asked about a WORKDIR/fetcher interaction problem and the bugs it
> > results in. I've tried to write down my thoughts.
> >
> >
I was asked about a WORKDIR/fetcher interaction problem and the bugs it
results in. I've tried to write down my thoughts.
The unpack task writes it's output to WORKDIR as base.bbclass says:
fetcher = bb.fetch2.Fetch(src_uri, d)
fetcher.unpack(d.getVar('WORKDIR')
We historically
On Fri, 2022-12-02 at 16:54 +0800, Matt Johnston wrote:
> Your email prompted me to check my own software (Dropbear) and it showed a
> few y2038 issues to fix. Those bugs wouldn't be noticed from a quick test -
> it "only" prevented auth and idle timeouts from occurring.
>
> gcc and clang are
On Mon, 2022-12-05 at 11:00 +0100, Ola x Nilsson wrote:
> On Wed, Nov 30 2022, Richard Purdie wrote:
>
> > On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:
> > > On 30/11/2022 16:46:17+, Ross Burton wrote:
> > > > On 30 Nov 2
On Thu, 2022-12-01 at 11:27 +0100, Alexander Kanavin wrote:
> On Wed, 30 Nov 2022 at 14:15, Richard Purdie
> wrote:
> > * We need to have a 32 bit ptest run on the autobuilder (qemux86 should
> > work, not sure we can make qemuarm fast). Whether this is manually
> > trigg
On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:
> On 30/11/2022 16:46:17+, Ross Burton wrote:
> > On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org
> > wrote:
> > > > > * Could we optionally disable some of the glibc 32 bit func
On Wed, 2022-11-30 at 14:36 +0100, Lukasz Majewski wrote:
> > On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote:
> > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley
> > > wrote:
> > > > We’d welcome a proposal/series on how to move forward with the
> > > > Y2038 work for 32 bit
On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote:
> On Tue, 29 Nov 2022 at 16:45, Stephen Jolley wrote:
> > We’d welcome a proposal/series on how to move forward with the Y2038 work
> > for 32 bit platforms.
>
> I have the following proposal:
>
> 1. A branch is made where:
> a.
On Wed, 2022-11-30 at 13:07 +0100, Alexander Kanavin wrote:
> On Wed, 30 Nov 2022 at 12:40, Richard Purdie
> wrote:
>
> > To be clear, we don't run ptests on 32 bit targets, only on qemux86-64
> > and qemuarm64 where we have KVM available. We do run image, sdk and
> >
On Wed, 2022-11-30 at 12:02 +0100, Alexandre Belloni via
lists.openembedded.org wrote:
> On 30/11/2022 09:07:50+0100, Alexander Kanavin wrote:
> > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley
> > wrote:
> > > We’d welcome a proposal/series on how to move forward with the Y2038 work
> > > for 32
Hi,
I've a few things I've been pondering for a while and given the summit
and OEDVM this week, I thought I'd sent out this email and some RFC
patches.
Export variable flag (and unexport/network)
---
The patch sent as an RFC to the bitbake list has the
On Thu, 2022-11-03 at 10:20 -0400, Paul Gortmaker wrote:
> [Relocatable binaries - better kernel support?] On 03/11/2022 (Thu 13:56)
> Richard Purdie wrote:
>
> [...]
>
> > The code that handles the interpreter is in the kernel, in
> > fs/binfmt_elf.c:load_elf_binary(
On Thu, 2022-11-03 at 15:24 +0100, Alexander Kanavin wrote:
> On Thu, 3 Nov 2022 at 14:56, Richard Purdie
> wrote:
>
> > The code that handles the interpreter is in the kernel, in
> > fs/binfmt_elf.c:load_elf_binary(). The idea would be to add support for
> > $O
I thought I'd quickly write down some notes on the relocatable binary
"problem" we have.
We have a need to be able to run our binaries with a different dynamic
loader in a few cases which basically come down to:
* uninative relocation of "native" binaries so they work on different
distros via
On Wed, 2022-09-28 at 20:02 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: Alexander Kanavin
> > Sent: den 28 september 2022 16:41
> > To: Peter Kjellerstedt
> > Cc: Richard Purdie ;
> > openembedded-
> > architecture
>
On Wed, 2022-09-28 at 10:48 +0200, Alexander Kanavin wrote:
> For future enhancements, I would want to keep some kind of record
> inside build/conf of where the original template was taken from. I
> agree that build init scripts should not use it at all, but that
> record can be utilized to either
I'm starting a new thread/discussion on this with a new perspective.
I did a little research myself on how these files are being used. My
conclusion is that templateconf.cfg isn't really used by much at all
other than to decide whether to rerun setup pieces.
I'm going to make the assumption that
On Sun, 2022-09-25 at 10:53 +0200, Konrad Weihmann wrote:
> Hi all,
>
> On 24.09.22 04:02, Lee Chee Yang wrote:
> > Hi
> >
> > We are pleased to announce the third milestone release for Yocto Project
> > 4.1 (yocto-4.1_M3) is now available for download.
> >
> > Download:
> >
> >
>
> > On Fri, 2022-09-16 at 17:18 +0200, Alberto Pianon wrote:
> > > Il 2022-09-15 14:16 Richard Purdie wrote:
> > > >
> > > > For the source issues above it basically it comes down to how much
> > > > "pain" we want to push onto
On Fri, 2022-09-16 at 17:18 +0200, Alberto Pianon wrote:
> Il 2022-09-15 14:16 Richard Purdie wrote:
> >
> > For the source issues above it basically it comes down to how much
> > "pain" we want to push onto all users for the sake of adding in this
> > data
On Wed, 2022-09-14 at 16:16 +0200, Marta Rybczynska wrote:
> The sources with a long README are available at
> https://gitlab.eclipse.org/eclipse/oniro-compliancetoolchain/toolchain/tinfoilhat/-/tree/srctracker/srctracker
>
> What do you think of this work? Would it be of interest to integrate
>
I was asked about getting official support for the TOOLCHAIN variable
in core. This is obviously late in the release cycle and after a bit of
thought, the answer is no. I wanted to document why since I was forced
into thinking this through.
As background, meta-clang uses TOOLCHAIN internally to
Hi Marius,
On Mon, 2022-09-05 at 13:25 +0200, Marius Kriegerowski wrote:
> Picking up on this thread now, almost half a year later :) Sorry for
> the late reply but turned out (a little surprising) that I’m going to
> have a daughter soon which shifted my priorities a little…
Understandable,
On Tue, 2022-05-17 at 10:13 +0100, Richard Purdie via
lists.openembedded.org wrote:
> I've been worrying about license and copyright information in our
> codebase for a while. We're slowly getting there with license info and
> scripts have good information now. We still need to work ou
On Wed, 2022-08-03 at 10:33 +0200, Michael Opdenacker via
lists.openembedded.org wrote:
> Hi Lee
>
> Thanks for the milestone release!
>
> Have you seen the discussion on the Openembedded-architecture mailing
> list? It seems there's a consensus to drop meta-gplv2 from master, and
> also from
On Tue, 2022-08-02 at 10:08 +0200, Alexander Kanavin wrote:
> I tend to agree that warnings popping out of nowhere when the stable
> branch is close to (or beyond) EOL is 'too late' - if you got yourself
> into that situation, you're likely to have a broader maintainability
> problem.
>
>
On Mon, 2022-08-01 at 19:30 +0200, Alexander Kanavin wrote:
> On Mon, 1 Aug 2022 at 13:22, Ross Burton wrote:
> > Would this be something done in oe-core, or something that distros
> > (such as Poky) can opt in to? We don’t want to start warning when
> > oe-core is EOL if the user is using a
On Wed, 2022-07-20 at 10:49 +0200, Alexander Kanavin wrote:
> Note: this update fails on x32 with
>
> > configure: error: unrecognized GNU build triplet linux-gnux32
>
> This time I want to put my foot down and suggest that we just drop the
> whole x32 variant from the autobuilder (I had already
On Wed, 2022-07-06 at 18:50 +0200, Alexander Kanavin wrote:
> On Wed, 6 Jul 2022 at 18:46, Khem Raj wrote:
> > I agree that we need to act upon this situation and once we have
> > relevant reference images in core then need for this should be less
> > with time.
>
> But we do:
>
meta-gplv2 makes the TSCs very nervous (certainly YP and I believe OE
TSC people too although it hasn't had an official discussion there). It
has a load of old "pre GPLv3 license" versions of software that haven't
seen security fixes for years. We've limped it along to our last LTS.
It has no
On Tue, 2022-06-14 at 07:08 -1000, Steve Sakoman wrote:
> At today's Yocto Project Technical Team Meeting Armin raised a
> question about the proper way to set up local.conf to use the Yocto
> Project state mirror for dunfell. This email is intended to bring
> those not attending up to speed and
On Tue, 2022-05-31 at 07:11 -0700, Khem Raj wrote:
>
>
> On Mon, May 30, 2022 at 3:51 AM Richard Purdie
> wrote:
> > I've gone around in circles on this for a long time. The background
> > isn't obvious at first glance.
> >
> > "S" represents whe
On Mon, 2022-05-30 at 13:26 +0200, Alexander Kanavin wrote:
> Is it possible to transition from dumping source artifacts and patches
> directly into $WORKDIR to having a clean set of sub-directories for
> SRC_URI items? Not having to set S separately for git recipes would be
> nice too.
The
I've gone around in circles on this for a long time. The background
isn't obvious at first glance.
"S" represents where our source is. There is code like do_unpack which
wants to clean S before rerunning the task. It can't just clean
everything in WORKDIR as there is T, recipe-sysroot* and more
I've been worrying about license and copyright information in our
codebase for a while. We're slowly getting there with license info and
scripts have good information now. We still need to work out license
info for recipe metadata and patches but one step at a time.
For copyright, I think we need
I've been asked about my thoughts on the eSDK. I'm going to try and
write down some of my ideas and thinking about it. I don't have a fully
thought out plan to pull off the shelf but can at least share the
ideas.
In summary, I think many of the concepts in the eSDK are good but the
implementation
1 - 100 of 247 matches
Mail list logo
