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
On Wed, 2022-04-27 at 08:26 -0500, Joshua Watt wrote:
> On Wed, Apr 27, 2022 at 6:04 AM Richard Purdie
> wrote:
> >
> > On Wed, 2022-04-27 at 12:39 +0200, Jacob Kroon wrote:
> > > On 4/27/22 12:12, Richard Purdie wrote:
> > > > On Wed, 2022-04-27 at 11:06
On Wed, 2022-04-27 at 12:39 +0200, Jacob Kroon wrote:
> On 4/27/22 12:12, Richard Purdie wrote:
> > On Wed, 2022-04-27 at 11:06 +0200, Jacob Kroon wrote:
> > > Hi Richard and Joshua,
> > >
> > > When using hash equivalency, since commits
> > >
> &g
On Wed, 2022-04-27 at 11:06 +0200, Jacob Kroon wrote:
> Hi Richard and Joshua,
>
> When using hash equivalency, since commits
>
> https://git.openembedded.org/openembedded-core/commit/?id=d6c7b9f4f0e
> https://git.openembedded.org/openembedded-core/commit/?id=1cf62882bba
>
> scrambling a header
On Sat, 2022-04-16 at 17:15 +0200, Marius Kriegerowski wrote:
> Dear Richard,
>
> Thanks for the comprehensive answer! That helped me to get a better overview
> of
> what is there and how to proceed.
>
> I'll leave cosmetics for a later phase, stick to unittest and fix the
> integration so
On Sat, 2022-04-16 at 13:40 +0200, Marius Kriegerowski wrote:
> Ok, one final thing for now...
>
> Speaking of CI: is there a framework that integrates into the current
> architecture? Do you run a self-hosted Jenkins, drone-ci, or alike somewhere
> that I can make use of?
We have the project
Hi,
Thanks for looping back to this.
On Sat, 2022-04-16 at 13:28 +0200, Marius Kriegerowski wrote:
> After some time I found the time and took a deeper dive into patchtest. It’s
> not
> in the prettiest state and has a couple of design choices which make me wonder
> if it wouldn’t be better to
On Sat, 2022-04-16 at 13:38 +0200, Marius Kriegerowski wrote:
> One more thing: As I heard patchtest is basically dead at the moment. If I
> pick up on it I’ll first add documentation and fix all PEP8 violations, and
> add some CI to run (at least) flake8 and pytest. I’ll also add type hints as
>
On Thu, 2022-03-24 at 09:29 -0700, Michael Halstead wrote:
>
>
> On Wed, Mar 23, 2022 at 4:58 AM Richard Purdie
> wrote:
> > Hi All,
> >
> > There are a few different discussions I'd like to pull together and talk
> > about
> > some QA and release pro
Hi All,
I wanted to update people on some of the results of the "5 year plan"
discussions that have been going on. A lot of the discussion was summarised into
this wiki page:
https://wiki.yoctoproject.org/wiki/Future_Directions
On there there is a list of topic areas which were raised as
On Mon, 2022-03-14 at 15:41 +, Martin Leduc wrote:
> Thank you Richard,
>
> Any input with respect to Morty and warrior? Yes or No will be sufficient .
Against my better judgement, warrior has:
https://git.yoctoproject.org/poky/commit/?h=warrior=d4b57c68b22027c2bedff335dee06af963e4f8a8
[Just to be clear, this related to github dropping git protocol support]
On Mon, 2022-03-14 at 14:55 +, Martin Leduc wrote:
> I’m wondering if the Yocto OE recipes are ready for this tomorrow?
We've tried to be.
> Do we know which Yocto release will support this change?
Dunfell has:
On Tue, 2022-02-22 at 18:30 +, Martin Leduc wrote:
> Hi Ross, after doing a grep to fine the defines, I've found that the defines
> refer to __USE_TIME_BITS64, instead of _TIME_BITS=64.
>
> The two defined flags appear to do not work "CFLAGS:append = "
> -D_TIME_BITS=64 -D_USE_TIME_BITS64"
Hi All,
Feature freeze time in upon us for 3.5/Kirkstone, technically tomorrow (Mon
21st). I think I have a reasonably clear idea of what I intend to do now.
I'm intending the inclusive language changes will merge. Most of these are in
master-next and are now basically ready IMO. We're missing
On Fri, 2022-02-18 at 11:41 -0800, Saul Wold wrote:
> As a follow-on to yesterday's email and replies, I would like to make
> the following proposal for dealing with the changes to
> INCOMPATIBLE_LICENSE and associated variables.
>
> Current Usage:
>
> INCOMPATIBLE_LICENSE is a list of
-Original Message-
> > From: openembedded-de...@lists.openembedded.org > de...@lists.openembedded.org> On Behalf Of Richard Purdie
> > Sent: den 18 februari 2022 15:14
> > To: Saul Wold ; openembedded-
> > architect...@lists.openembedded.org; OE-core > c...@
On Fri, 2022-02-18 at 22:56 +0100, Konrad Weihmann wrote:
>
> On 18.02.22 21:44, Denys Dmytriyenko wrote:
> > On Fri, Feb 18, 2022 at 08:51:58PM +0100, Konrad Weihmann wrote:
> > > Just out of curiosity: is this all considered to be part of
> > > kirkstone release?
> >
> > This was originally
On Fri, 2022-02-18 at 14:13 +, Richard Purdie via lists.openembedded.org
wrote:
> On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote:
> > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used
> > and processed to possibly include a COMPATIBLE_LICENSES variab
On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote:
> I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used
> and processed to possibly include a COMPATIBLE_LICENSES variable as
> well, see PeterK's email [0]
>
> I am trying to determine the usage of WHITELIST_ which would be
On Thu, 2022-02-17 at 10:17 +, Richard Purdie via lists.openembedded.org
wrote:
> On Tue, 2022-02-15 at 12:08 +0000, Richard Purdie via lists.openembedded.org
> wrote:
> > In all the above cases there are still the issues that:
> >
> > 1) showing errors doesn't m
On Tue, 2022-02-15 at 12:08 +, Richard Purdie via lists.openembedded.org
wrote:
> In all the above cases there are still the issues that:
>
> 1) showing errors doesn't make bitbake exit or stop the build
> 2) It won't handle variables from the shell environment. This will
Hi All,
I'm a little saddened/annoyed/frustrated that we're less that a week before
feature freeze and yet there is still no mechanism in bitbake to handle variable
deprecation/renaming. There has also been no real discussion about how this
could/should work. People have sent out odd patches
Sharing a copy of this to openembedded-architecture.
Cheers,
Richard
--- Begin Message ---
Good morning everybody,
We started a discussion about integrating a linter to meta-openembedded to ease
the review process, provide direct feedback to contributors and increase
consistency across
On Tue, 2022-01-18 at 15:00 +0100, Stefan Herbrechtsmeier wrote:
> Am 18.01.2022 um 14:40 schrieb Richard Purdie:
> > On Tue, 2022-01-18 at 14:00 +0100, Stefan Herbrechtsmeier wrote:
> > > In summary we use a language specific lock file based approach which
> > > sup
On Tue, 2022-01-18 at 14:00 +0100, Stefan Herbrechtsmeier wrote:
> In summary we use a language specific lock file based approach which
> support offline build, license checks and CVE scans and leaves the
> dependency management and fixing outside of OE to limit the recipe count
> and required
On Tue, 2022-01-18 at 08:54 +0100, Stefan Herbrechtsmeier wrote:
> Hi Richard,
>
> Am 17.01.2022 um 23:46 schrieb Richard Purdie:
> > On Mon, 2022-01-17 at 13:50 +0100, Stefan Herbrechtsmeier wrote:
> >
> > > I really miss a comment from a npm user and a TSC mem
On Mon, 2022-01-17 at 13:50 +0100, Stefan Herbrechtsmeier wrote:
> Hi Mark,
>
> Am 14.01.2022 um 21:09 schrieb Mark Asselstine:
> >
> >
> > On 2022-01-14 14:38, Stefan Herbrechtsmeier wrote:
> > > Hi Mark,
> > >
> > > Am 14.01.2022 um 17:58 schrieb Mark Asselstine:
> > > > On 2022-01-14 11:35,
On Tue, 2021-12-14 at 11:27 +, Ross Burton wrote:
> On Tue, 14 Dec 2021 at 10:38, Alexander Kanavin
> wrote:
> >
> > On Tue, 14 Dec 2021 at 11:30, Michael Opdenacker
> > wrote:
> > >
> > > Are you suggesting to expand the official Yocto Project docs on this
> > > topic?
> > > Actually,
On Sat, 2021-12-11 at 06:55 -0800, akuster808 wrote:
>
> On 12/11/21 6:15 AM, Richard Purdie wrote:
> > On Sat, 2021-12-11 at 06:12 -0800, akuster808 wrote:
> > > On 12/10/21 2:47 AM, Alexander Kanavin wrote:
> > > > On Thu, 9 Dec 2021 at 18:05, Richard Purdie
&
On Sat, 2021-12-11 at 06:12 -0800, akuster808 wrote:
>
> On 12/10/21 2:47 AM, Alexander Kanavin wrote:
> > On Thu, 9 Dec 2021 at 18:05, Richard Purdie
> > > <mailto:richard.pur...@linuxfoundation.org>> wrote:
> >
> >
> > I'm in favour
On Thu, 2021-12-09 at 15:48 +0100, Konrad Weihmann wrote:
> I support that idea.
>
> as said in the other ML conversation the format should look like
>
> Upstream-Status: Inactive-Upstream [(, date>)]
>
> with the part in the ()-brackets being opinion, as we mainly aim for
> using releases
On Tue, 2021-12-07 at 11:09 -0800, Andre McCurdy wrote:
> On Tue, Dec 7, 2021 at 9:58 AM Richard Purdie wrote:
> >
> > On Tue, 2021-12-07 at 17:53 +, Ross Burton wrote:
> > > On Tue, 7 Dec 2021 at 17:15, Konrad Weihmann
> > > wrote:
> > > &g
On Tue, 2021-12-07 at 17:53 +, Ross Burton wrote:
> On Tue, 7 Dec 2021 at 17:15, Konrad Weihmann wrote:
> > TBF
> >
> > the correct fix would be
> >
> > magic.bbclass
> > ---
> > DEPENDS:append = " magic-dependency"
> > ---
> >
> > but unfortunately sometimes this is out of our control (as
On Mon, 2021-11-22 at 16:41 +, Richard Purdie via lists.openembedded.org
wrote:
> I think this would be something really useful to fix. For ranlib, we can
> probably just patch BUILD_RANLIB to add the flag. For ar, we need to remove
> the
> u option so it can only re
On Mon, 2021-11-22 at 14:12 +0100, Jacob Kroon wrote:
> On 11/22/21 09:00, Jacob Kroon via lists.openembedded.org wrote:
> > Hi,
> >
> > Some days ago there was a patch in OE-Core that updated the
> > Upstream-Status tags in a couple of the gcc patches. I figured this
> > wouldn't cause too much
On Tue, 2021-11-09 at 18:14 +0100, Quentin Schulz wrote:
> Hi Richard,
>
> On November 9, 2021 4:15:16 PM GMT+01:00, Richard Purdie
> wrote:
> > Hi All,
> >
> > I shared a patch on the bitbake mailing list to make some syntax generate
> > warni
Hi All,
I shared a patch on the bitbake mailing list to make some syntax generate
warnings, specifically things of the form:
XXX_append += "YYY"
XXX_prepend += "YYY"
XXX_remove += "YYY"
and the ?=, =+, .= and =. variants. This also covers variants with overrides in
there too. It would basically
On Tue, 2021-11-02 at 08:16 -0700, Khem Raj wrote:
> Can we change bitbake fetcher to default to https instead git
> anonymous protocol as fallback? this will be good security measure
> too.
Some servers out there (e.g. our own git.yoctoproject.org) have slightly
different git and https urls so
On Tue, 2021-11-02 at 12:32 +, Richard Purdie via lists.openembedded.org
wrote:
> On Tue, 2021-11-02 at 11:56 +, Andrei Gherzan wrote:
> > On Tue, 2 Nov 2021, at 11:52, Martin Jansa wrote:
> > > On Tue, Nov 2, 2021 at 12:46 PM Richard Purdie
> > > wrote:
>
On Tue, 2021-11-02 at 11:56 +, Andrei Gherzan wrote:
> On Tue, 2 Nov 2021, at 11:52, Martin Jansa wrote:
> > On Tue, Nov 2, 2021 at 12:46 PM Richard Purdie
> > wrote:
> > > On Tue, 2021-11-02 at 11:32 +0100, Martin Jansa wrote:
> > > > There is e
On Tue, 2021-11-02 at 11:32 +0100, Martin Jansa wrote:
> There is even bigger issue with git repos from github.com now:
>
> https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git
>
> bitbake git fetcher uses git:// protocol by default and as of today
On Fri, 2021-10-29 at 15:45 +0200, Konrad Weihmann wrote:
>
> On 29.10.21 15:09, Richard Purdie wrote:
> > We've had concerns about the default behaviours of tools like git and how
> > they'll handle the default branch names going forward. There are also
> > concerns
We've had concerns about the default behaviours of tools like git and how
they'll handle the default branch names going forward. There are also concerns
about what providers like github may do, and the potential impact on our tools
like recipetool.
A bug was filed about some of this:
On Tue, 2021-09-21 at 09:43 +1200, Paul Eggleton wrote:
> On Friday, 10 September 2021 19:54:11 NZST Richard Purdie wrote:
> > > > Do we change the master branch to something else? I personally have a
> > > > preference for "devel" over "
On Thu, 2021-09-09 at 20:43 -0700, akuster808 wrote:
>
> On 9/9/21 9:09 AM, Richard Purdie wrote:
> > Hi All,
> >
> > We have a decision facing us with 3.5. There are a number of invasive issues
> > looming on the horizon and I'm not sure exactly what the best
Hi All,
We have a decision facing us with 3.5. There are a number of invasive issues
looming on the horizon and I'm not sure exactly what the best thing to do with
them is.
a) Inclusive language
A lot of variables potentially need renaming with varying options for backwards
compatibility. Do we
On Sat, 2021-07-31 at 15:29 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-architecture@lists.openembedded.org > architect...@lists.openembedded.org> On Behalf Of Richard Purdie
> > Sent: den 30 juli 2021 15:40
> > To: openembe
On Wed, 2021-07-28 at 16:43 +0100, Richard Purdie via lists.openembedded.org
wrote:
> I think the challenge is going to be the flag day issue for master branches.
> For example, there is code in devtool and other places which knows about the
> override character. If we allow mixing the
Hi Marco,
On Thu, 2021-07-29 at 08:50 +0200, Marco Cavallini wrote:
> IMHO it is important to produce a clear documentation about the new
> features maybe providing some practical cases.
I agree it is important this is documented. I've sent a patch to the manuals
to add a section to the 3.4
Hi All,
I've spent quite a bit of time seeing how to progress things. I now
have a script which can convert layers and seems to have reasonable success
on OE-Core, bitbake, yocto-docs, meta-yocto, meta-gplv2 and meta-mingw. I've
proposed this for OE-Core along with an example conversion patch for
On Tue, 2021-07-27 at 12:38 -0400, Denys Dmytriyenko wrote:
> On Tue, Jul 27, 2021 at 08:18:13AM +0100, Richard Purdie wrote:
> > On Mon, 2021-07-26 at 23:51 -0400, Denys Dmytriyenko wrote:
> > > All,
> > >
> > > The layer has been updated and moved to git.yoc
On Mon, 2021-07-26 at 23:51 -0400, Denys Dmytriyenko wrote:
> All,
>
> The layer has been updated and moved to git.yoctoproject.org under a central
> mixin repo called "meta-lts-mixins", branch "dunfell/kernel":
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-lts-mixins/
>
> The naming is in
Hi All,
I now have an actual proposed plan for changing override syntax which I hope
will mitigate the issues raised in the previous discussion as far a is possible
whilst still letting the project move forward.
Firstly, I'd like to merge a patch I sent to the bitbake list:
On Fri, 2021-07-16 at 17:46 +0100, Richard Purdie via lists.openembedded.org
wrote:
> Just to update, I have an experiment:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/overrides-convert
>
> This contains a conversion script which can convert poky to use
On Fri, 2021-07-16 at 11:44 -0500, Mark Hatle wrote:
>
> On 7/16/21 4:22 AM, Richard Purdie wrote:
> > On Thu, 2021-07-15 at 09:26 -0500, Mark Hatle wrote:
> > >
> > > On 7/15/21 8:56 AM, Richard Purdie wrote:
> > > > Breaking things down a b
Just to update, I have an experiment:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/overrides-convert
This contains a conversion script which can convert poky to use ":"
instead of "_" as the override character (i.e. all of oe-core, meta-yocto,
docs and bitbake inc. tests).
On Fri, 2021-07-16 at 14:35 +, Peter Kjellerstedt wrote:
>
> This is a long answer, and responding to multiple subjects that have been
> brought up in the different threads, so please bear with me.
>
> I would love to see improvements to the bitbake syntax when it comes to
> overrides.
On Fri, 2021-07-16 at 10:12 +0200, Nicolas Dechesne wrote:
> hey!
>
> On Thu, Jul 15, 2021 at 3:56 PM Richard Purdie
> wrote:
> > b) Some of the packaging code (at the very least) needs rewriting as it
> > accesses
> > both RDEPENDS_${PN} and puts ${PN} in O
On Thu, 2021-07-15 at 23:48 -0400, Denys Dmytriyenko wrote:
> On Thu, Jul 15, 2021 at 02:56:38PM +0100, Richard Purdie wrote:
> > Breaking things down a bit, one thing I keep running into with our current
> > codebase and metadata is that overrides are not clear. In my
On Thu, 2021-07-15 at 09:26 -0500, Mark Hatle wrote:
>
> On 7/15/21 8:56 AM, Richard Purdie wrote:
> > Breaking things down a bit, one thing I keep running into with our current
> > codebase and metadata is that overrides are not clear. In my previous emai
Breaking things down a bit, one thing I keep running into with our current
codebase and metadata is that overrides are not clear. In my previous email,
the example was:
do_configure_class-native
A human can usually spot "class-native" is and "configure" or
"configure_class-native" is not.
I've been quiet but have been thinking a lot about the syntax discussions.
I believe we do need to simplify things, at least so the majority of recipes
have simpler assignment syntax that is understandable to new users. There was
a recent question about whether it was preferred to use += or
On Wed, 2021-07-07 at 10:22 -0500, Mark Hatle wrote:
>
> On 7/7/21 7:30 AM, Armin Kuster wrote:
> > Hello all,
> >
> > The Yocto Project TSC has created a wiki page to start making notes of
> > offending names and possible replacements. At some point, this wiki page
> > should include a plan on
On Tue, 2021-06-15 at 17:10 +0200, Phil Blundell wrote:
> On Tue, Jun 15, 2021 at 02:29:16PM +0100, Richard Purdie wrote:
> > For that reason I would like to change the initramfs recipe somehow to
> > improve usability and ensure people don't hit this. Right now I can't see
&g
On Tue, 2021-06-15 at 16:50 +0300, Petr Nechaev wrote:
> Hi All,
>
> I've been using bitbake for >5 years now, however I do not understand
> the nature of the problem at all. Could you clarify what the problem is
> i.e. what's the difference between these lines:
>
> IMAGE_FSTYPES =
On Tue, 2021-06-15 at 09:38 -0400, Tom Rini wrote:
> Thanks for all the details here. Since this is stemming from a specific
> BSP, I think at this point it might be good to share what exactly it is,
> and it wouldn't be seen as "shaming" that BSP at this point as it's
> exposed a rather, as you
I should apologise for being a little grumpy in some of my replies,
it is fair to say that everything is getting to me a little as continual
build failures and being continually asked for reasoned arguments for
saying "no" to things is wearing me down. We have bugs in many core pieces
of the
On Tue, 2021-06-15 at 09:32 -0300, Otavio Salvador wrote:
> Hello Richard,
>
> Em ter., 15 de jun. de 2021 às 07:29, Richard Purdie
> escreveu:
> > I wondered about making := clear existing overrides/appends/prepends/removes
> > but then I wondered if we should have a
On Tue, 2021-06-15 at 13:55 +0200, Phil Blundell wrote:
> On Tue, Jun 15, 2021 at 11:29:01AM +0100, Richard Purdie wrote:
> > a) is another assignment operator a good idea?
>
> I'm not terribly convinced it is. If the problem is that there's no
> way to clear the OVERRIDE
On Tue, 2021-06-15 at 11:42 +, Quentin Schulz wrote:
>
> On June 15, 2021 10:29:01 AM UTC, Richard Purdie
> wrote:
> > We have an interesting problem with initramfs images. They do something
> > like:
> >
> > IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}
We have an interesting problem with initramfs images. They do something like:
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
which looks innocent enough until a BSP does:
IMAGE_FSTYPES_collie = "xxx"
where collie is MACHINE, hence an override which causes confusion as
the value of INITRAMFS_FSTYPES
On Mon, 2021-05-10 at 13:52 -0700, akuster808 wrote:
>
> On 5/10/21 8:14 AM, Richard Purdie wrote:
> > I appreciate these are difficult times, both for individuals and for
> > businesses. I'd like to conclude by thanking everyone who does participate
> > and contribut
TLDR: The project is seen as mature, employers don't prioritise maintaining
things and we're struggling for maintainers and help with day to day work
Open source projects survive, not just through development work and
contributions of new features but through a whole load of "unglamorous"
day
I'm pleased to be able to announce that the project is planning to have
the April 2022 release next year be our next LTS release.
This fits in with our original announced plan of 2 year cycles and
recognises that the LTS has been well received by members and our
community. It also aligns well
On Mon, 2021-04-26 at 14:44 +, chris.lapla...@agilent.com wrote:
> > Just FWIW, much of our parsing speed pain now is in the tons of anonymous
> > python people keep adding, thinking little of the overhead about trying to
> > parse it all for dependencies and run it all...
>
> Is there a
On Mon, 2021-04-26 at 11:46 +0200, Quentin Schulz wrote:
> Hi all,
>
> I submitted a presentation about OVERRIDES, _append, +=, =. and others
> for YP Summit 2021 in a month. While sharing the description with some
> people in the Yocto community, I've been made aware that I'm missing
> some
In looking at some of the reproducibility failures, I realised that
several are from a common cause, basically tasks missing a umask
setting. Our common tasks have this but for example:
kernel-devsrc - copies files from ${S} which are created in special
kernel tasks which don't have umask set
Being able to verify build artefacts is a hot topic at the moment. I
think we need to promote that the project can do this. I did that a
little here on the reproducible builds list:
https://lists.reproducible-builds.org/pipermail/rb-general/2021-January/002175.html
Thought it may be of interest
I (and the YP TSC) are seeing various interesting things happening with
the LTS. I think in general its good for the project, it is helping
users and it is being positively received. We are starting to see
various "pressures" on how it is being used as master and dunfell
diverge naturally over
On Wed, 2020-09-16 at 14:13 -0700, akuster808 wrote:
>
> On 7/27/20 6:09 AM, Richard Purdie wrote:
> > The OE TSC recognises there are issues related to inclusive
> > language
> > which the project needs to address and that we need a plan for
> > doing so
> &g
On Thu, 2020-09-10 at 22:03 +0200, Andreas Müller wrote:
> On Thu, Sep 10, 2020 at 9:52 PM Alexander Kanavin
> wrote:
> > Hello all,
> >
> > I just read this article, called "Supporting Linux kernel
> > development in Rust"
> > https://lwn.net/Articles/829858/
> > and it looks like the future is
On Mon, 2020-09-07 at 17:19 -0400, Tom Rini wrote:
> On Mon, Sep 07, 2020 at 10:03:36PM +0100, Richard Purdie wrote:
> > On Mon, 2020-09-07 at 16:55 -0400, Tom Rini wrote:
> > The autobuilder is setup for speed so there aren't VMs involved, its
> > 'baremetal'. Contain
On Mon, 2020-09-07 at 16:55 -0400, Tom Rini wrote:
> On Mon, Sep 07, 2020 at 02:59:41PM -0300, Otavio Salvador wrote:
> > Hello all,
> >
> > Em seg., 7 de set. de 2020 às 13:14, Richard Purdie
> > escreveu:
> > > ...
> > > Any thoughts from anyone
I wanted to write down my findings on trying to getting and keeping
stable branch builds working on the autobuilder. I also have a proposal
in mind for moving this forward.
Jeremy did good work in getting thud nearly building, building upon
work I'd done in getting buildtools-extended-tarball
On Sat, 2020-09-05 at 08:15 -0700, Achara, Jagdish P wrote:
> Hi,
>
> Currently we have the option to choose either sysvinit or systemd .
> Would, at some point, openrc be included in this list of options to
> choose from?
It comes down to the demand for it, whether there are people willing
the
Hi,
The YP TSC has been discussing the topic of future development
directions for a while. We're written up a summary of those onto the
wiki:
https://wiki.yoctoproject.org/wiki/Future_Directions
These have been shared and discussed with the YP members. Most of these
topics are resource
The OE TSC recognises there are issues related to inclusive language
which the project needs to address and that we need a plan for doing so
moving forward. It is unclear how much change the project members wish
to see or can cope with at this point in time, nor how much help is
available to make
Hi Paul,
On Mon, 2020-07-20 at 19:58 +0100, Paul Barker wrote:
> I took a look at our mirrored repositories on GitHub under
> https://github.com/openembedded and considered the experience of new
> potential contributors and others from outside our project community.
> As many projects use GitHub
On Wed, 2020-07-15 at 16:03 -0400, Trevor Woerner wrote:
> On Wed 2020-07-15 @ 07:02:13 PM, Richard Purdie wrote:
> > On Wed, 2020-07-15 at 09:09 -0700, akuster wrote:
> > What may also be a bigger issue is member companies placing
> > requirements on the project.
&g
On Wed, 2020-07-15 at 09:09 -0700, akuster wrote:
> Well, as I see it, the LF will make a ruling and then the Yocto
> Project with have to follow. If OE decides not to change then this
> put the two projects at odds.
To be really clear, whilst you keep saying this, I have heard of no
such plans
Thanks for bringing this up and writing a summary. The OE and YP TSCs
are aware of this and are starting to have discussions about it. I have
also been looking at what other projects and the Linux Foundation are
doing. As yet there aren't any real conclusions, I've been kind of
waiting for git
On Tue, 2020-07-07 at 08:58 -0500, Joshua Watt wrote:
>
> On 7/7/20 6:42 AM, Richard Purdie wrote:
> > A number of upstream git repos we build from are transitioning
> > "master"
> > branches to "main" branches. They're doing this and remov
A number of upstream git repos we build from are transitioning "master"
branches to "main" branches. They're doing this and removing the old
name.
The scale of the problem this causes us is only just becoming apparent.
iso-codes did this, I tested a patch to update master-next. Everything
was
On Fri, 2020-07-03 at 20:44 +0200, Konrad Weihmann wrote:
> I totally agree that there is an usability issue. I myself have been
> confused for a long time about all these options and how they work
> together (or don't) and having now a hard time telling other ppl to
> avoid some corner cases.
On Fri, 2020-07-03 at 23:23 +0200, Alexander Kanavin wrote:
> Maybe we could ask, what are the typical intentions behind those
> additions and removals and assignments? E.g. for DISTRO_FEATURES I
> can think of these:
>
> 1. Features A B C can be present in DISTRO_FEATURES if no other wish
> is
On Fri, 2020-07-03 at 14:08 -0700, Christopher Larson wrote:
> I definitely think there’s a usability issue here. It’d be nice if
> +=/=+/.=/=. were recorded operations against the current or default
> value. Now that _append/_prepend/_remove are applied at getVar time,
> not at the end of the
I'm growing increasingly concerned about default value assignments in
OE. The basic problem is people don't understand the way default values
work and the mechanisms we do have don't let people do all the things
they want to do.
I'll pick on the example found by Ross/Jon in meta-arm. If you set:
Hi,
Back in 2009, regex support was added in ASSUME_PROVIDED:
https://git.openembedded.org/bitbake/commit/lib/bb/taskdata.py?id=efb0474231ed286073a5a5904094320da8cab28d
Looking at this now, I'm thinking its a bad idea.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13893
shows that adding:
On Wed, 2020-06-03 at 13:24 +0300, Adrian Bunk wrote:
> On Wed, Jun 03, 2020 at 10:27:00AM +0100, Richard Purdie wrote:
> > ...
> > If we do this, I would say as a TSC member that we'd do it without
> > setting any precedent, this is being discussed based on the
>
Hi All,
We'd like to get the first 3.1 point release Dunfell LTS out soon.
There is one issue we need to resolve first.
meta-arm has recently been established and the hope is to avoid
duplication of a set of recipes in multiple BSP layers, a goal which I
believe is in everyone's interests. As
101 - 200 of 248 matches
Mail list logo
