For what it's worth, I have started a similar project, but in a more
radical way: rewrite existing recipe (unmaintainable mess imo), bring
in perl-cross overlay from buildroot to do cross-builds without
resorting to ugly hacks. I got a bit further: the whole thing builds
and packages without
Hello all,
I just posted a patchset that enables OpenGL acceleration in QEMU, and
thought I would seek feedback here as well.
The rationale is:
1. I think we are heading towards a reality where some kind of working
GL is a 'must' for any kind of UI work.
2. Typically people build images and then
If you do package version upgrades regularly in master, I’d say that you
eventually learn about whether stable releases can be trusted. I wouldn’t need
to do any research to say that boost shouldn’t be touched but OpenSSL is fine,
and can similarly split the rest of what I maintain.
Alex
> On
I specifically meant letter releases, which are the true ‘point’ releases in
OpenSSL. (E.g. 1.1.1a -> 1.1.1b)
Alex
> On 18 Mar 2019, at 17.03, akuster808 wrote:
>
>
>
>> On 3/18/19 8:49 AM, Alexander Kanavin wrote:
>> If you do package version upgrades regularly
On Wed, 11 Dec 2019 at 13:58, Adrian Bunk wrote:
> >...
> > Creating containers, whilst easier than it ever used to be, does
> > usually require elevated permissions and can cause problems with things
> > like qemu acceleration and networking. If you've already dealt with
> > that, fine but some
everything that could be insecure is not there.
Alex
On Wed 4. Mar 2020 at 15.01, Adrian Bunk wrote:
> On Wed, Mar 04, 2020 at 01:13:19PM +0100, Alexander Kanavin wrote:
> > On Wed, 4 Mar 2020 at 12:32, Adrian Bunk wrote:
> >
> > > I am sure there will be an update to the anno
:57, Alexander Kanavin
wrote:
> The question is: what are the use cases for an 'example/reference UI'? Why
> have one at all at this point? Remember, the core project is severely
> under-staffed and we need to commit our limited resources wisely.
>
> Alex
>
> On Tue, 11 Feb
01:49:27PM +0100, Alexander Kanavin wrote:
> >...
> > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and
> does
> > not have a Wayland compositor. Yocto project does not have the resources
> to
> > do the gtk4 port, or add a compositor.
> >
&
.
Alex
On Tue, 11 Feb 2020 at 15:13, Adrian Bunk wrote:
> On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote:
> > Specifically (sorry for the rapid-followup), I think the main value
> > proposition of core is integration and testing of various language
> >
Hello,
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 they're
transitioning it to 'hard maintenance mode'
On Tue, 11 Feb 2020 at 18:53, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
>
> I still strongly believe we need something in core which pulls together
> all our pieces into a UI where you can test key elements of what we
> build. If we don't have sato how do we actually test the
On Tue, 11 Feb 2020 at 16:58, Mark Hatle
wrote:
>
> I also don't think oe-core itself needs a 'real' UI, and as my previous
> response
> said -- we do need something though to test that the graphical framework is
> working properly.
>
> In the past this often comes back to needing a LOT of a UI
On Tue, 11 Feb 2020 at 18:46, Alexander Kanavin
wrote:
> On Tue, 11 Feb 2020 at 16:58, Mark Hatle
> wrote:
>
>>
>> I also don't think oe-core itself needs a 'real' UI, and as my previous
>> response
>> said -- we do need something though to test that the gra
For what it's worth, we (a major car manufacturer :) do use meta-gpl2 here,
but it was always intended as a temporary solution, and once we have master
branch builds up and running (currently everything is based on thud), work
will get underway to take per-image license restriction into use, drop
On Wed, 22 Jan 2020 at 13:31, Ross Burton wrote:
>
> Some quick poking doing a core-image-sato for qemux86-64:
>
> - dosfstools is GPLv3 and pulled into qemu images now via the vfat
> machine feature. Easy enough to make that dependency conditional on
> license blacklist.
>
> - Lots of ptests
On Wed, 22 Jan 2020 at 22:08, Andre McCurdy wrote:
> Another tricky point is libraries such as gmp and nettle, which are
> now either LGPLv3 (and so problematic for signed firmware images, etc)
> or GPLv2 (and so problematic if somehow linked with proprietary code).
>
> meta-gplv2 solves that
On Sun, 8 Mar 2020 at 22:46, Adrian Bunk wrote:
> It is on YP to make it clear to users whether or not Yocto comes with
> the same set of security guarantees as distributions like Ubuntu or
> Debian.
> If it is the duty of every user of Yocto to track and fix CVEs,
> then this has to be stated
Hello all,
the current maintenance model in openembedded-core is problematic due to
lack of well-working process of finding maintainers, and replacing them
when they're no longer able to contribute. This becomes especially
frustrating when maintainers silently disappear, and perfectly fine
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 general for OpenSource has had to
> address over the years.
> >
> >
On Mon, 4 May 2020 at 00:16, akuster wrote:
> the current maintenance model in openembedded-core is problematic due to
> lack of well-working process of finding maintainers, and replacing them
> when they're no longer able to contribute. This becomes especially
> frustrating when maintainers
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 set, and particularly the Yocto project
should prepare for it.
Thoughts?
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent
On Thu, 10 Sep 2020 at 22:24, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> This has been talked about a lot but there is work to be done to get
> this into core. Not many people seem willing to step up and do that
> work so progress has been slow.
>
> The hardest part may be
On Wed, 15 Jul 2020 at 21:33, Trevor Woerner wrote:
> > > Some projects are replacing "master" in isolation; such as when used
> as a branch
> > > name. Other projects are only replacing "master" when paired with
> "slave".
> >
> > "Master" has been used in commit headers, so do we intend on
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
expressed
2. Features D E F must be present in DISTRO_FEATURES
3.
On Wed, 6 Oct 2021 at 22:40, Denys Dmytriyenko wrote:
>
> Yes, I believe that was the intended usage:
> $ git clone git://git.yoctoproject.org/meta-lts-mixins -b dunfell/kernel
> meta-lts-kernel-mixin
> $ git clone git://git.yoctoproject.org/meta-lts-mixins -b dunfell/gizmo
>
On Tue, 27 Jul 2021 at 18:54, Denys Dmytriyenko wrote:
> Not necessarily. Providing latest LTS kernels for Dunfell also seems very
> specific. For every extra year of official support for Dunfell, this can
> offer a new LTS kernel version, that can be selected by PREFERRED_VERSION.
> Creating a
We also clearly need to extend automated reproducibility testing to native
recipes - I’ll look into that. It’s fine to have core items in repro
exception list, we just need to know what they are.
Alex
On Mon 22. Nov 2021 at 9.00, Jacob Kroon wrote:
> Hi,
>
> Some days ago there was a patch in
Hello,
the ongoing patch review revealed that we need more clear markers for
patches which should be upstreamed but where upstream is defunct. Existing
docs[1] suggest:
Upstream-Status: Inappropriate [no upstream]
but that is problematic due to perception of 'Inappropriate' patches
as something
On Thu, 9 Dec 2021 at 18:05, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
>
> I'm in favour of adding the new category and I agree some kind of dates in
> the
> [reason] space would be nice to have.
>
> For the purposes of a patch upstream, the last commit date is much more
>
On Thu, 9 Dec 2021 at 18:05, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> 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 [(, >
On Tue, 14 Dec 2021 at 11:30, Michael Opdenacker <
michael.opdenac...@bootlin.com> wrote:
> Are you suggesting to expand the official Yocto Project docs on this topic?
> Actually, I only see
> https://docs.yoctoproject.org/dev-manual/common-tasks.html#patching-code
> which explains the use of
will be
dropped on version upgrade regardless of its status.
Alex
On Tue, 14 Dec 2021 at 19:49, Khem Raj wrote:
> On Tue, Dec 14, 2021 at 9:41 AM Ross Burton wrote:
> >
> > On Mon, 13 Dec 2021 at 17:38, Alexander Kanavin
> wrote:
> > > I added the following to the wiki:
> >
Three possible solutions, please:
c) improve npm and go tooling in collaboration with respective upstreams so
that it fulfils our use cases.
Both a and b are not tenable in my opinion.
Alex
On Fri, 14 Jan 2022 at 11:09, Stefan Herbrechtsmeier <
stefan.herbrechtsmeier-...@weidmueller.com>
eb Mark Asselstine:
> > > > > > > On 2022-01-14 10:05, Stefan Herbrechtsmeier wrote:
> > > > > > > > Am 14.01.2022 um 15:15 schrieb Mark Asselstine via
> > > > > > > > lists.openembedded.org:
> > > > > > > >
Please no. EOL means EOL, if you want additional commits, make a
private fork and cherry-pick there. Or arrange some kind of community
ELTS effort (those tend to fizzle out though :).
Alex
On Sat, 19 Mar 2022 at 05:05, Trevor Woerner wrote:
>
> On Sat 2022-03-19 @ 12:00:36 AM, Trevor Woerner
You should really try per-image INCOMPATIBLE_LICENSE :) Maintaining
those whitelists/excludes is awkward, as developers constantly want
more of them.
Alex
On Fri, 18 Feb 2022 at 09:00, Mikko Rapeli wrote:
>
> Hi,
>
> On Thu, Feb 17, 2022 at 04:20:01PM -0800, Andre McCurdy wrote:
> > On Thu, Feb
<
marius.kriegerow...@gmail.com> wrote:
> Dear Alex,
>
> Richard was kind enough to forward my email. Thanks @Richard. I’m happy to
> continue the discussion here.
>
> Best
> Marius
>
>
> On 29. Jan 2022, at 13:40, Alexander Kanavin
> wrote:
>
> Marius, I know yo
Marius, I know you want everyone to move to github and abandon email
(seeing the previous thread), but asking everyone to go there for the
'discussion' won't get you far.
Please write a proposal, send it here to oe-architecture list, and do
include a plan for transparently adding the linter to
On Sat, 29 Jan 2022 at 15:31, Marius Kriegerowski <
marius.kriegerow...@gmail.com> wrote:
> Another more technical question to discuss once a set of rules is found:
> how could this be integrated into the established workflow?
>
This is the harder issue that needs to be resolved and implemented
On Fri, 14 Jan 2022 at 20:38, Stefan Herbrechtsmeier <
stefan.herbrechtsmeier-...@weidmueller.com> wrote:
>
> Do you really thing YP should switch to a distributed approach? Doesn't
> Log4Shell, 'colors' and 'faker' shows the disadvantages of this approach?
>
Once again, the world has decided
o and npm support before moving them back into core
> - add real life consumers to core to avoid future regressions
>
> No idea what that would mean in terms of work and if that is even doable
>
> On 14.01.22 12:16, Alexander Kanavin wrote:
> > Three possible solutions, please:
>
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
> will be reused? There is bitbake --dry-run but perhaps it is time for a
> an option (or dedicated
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 with a bit of help from RP
and the community:
ht
On Thu, 14 Sept 2023 at 21:54, Richard Purdie
wrote:
> Effectively those "configs" are what the eSDK is, you're just proposing
> a server side set of them rather than a built copy. In many ways that
> could be useful way of possibly rethinking the way the eSDK works.
>
> So in that sense I like
On Wed, 1 Nov 2023 at 15:18, wrote:
> We are currently experimenting with replacing the eSDK installer with
> the bitbake build environment for our users. Part of this
> transformation is, of course, the shared sstate-cache, for which this
> discussion seems quite relevant. The workflow we are
On Wed, 1 Nov 2023 at 16:45, wrote:
> I think these differences between SDK and bitbake environment are no
> longer required and they have been problematic. I would try to make the
> bitbake environment usable like the eSDK environment was without trying
> to replicate all the details of the eSDK
On Thu, 2 Nov 2023 at 09:32, wrote:
> Sorry for repeating some parts which we already had in other emails.
> But I tried to summarize the lengthy discussion a bit in one place.
So here's what I'd like to try:
- write a new populate_build_replica task that writes a few things
under
On Thu, 2 Nov 2023 at 10:02, Alexander Kanavin via
lists.yoctoproject.org
wrote:
> So here's what I'd like to try:
>
> - write a new populate_build_replica task that writes a few things
> under ${WORKDIR}/replica
> -- setup-layers json and script
> (another option is to co
On Tue, 7 Nov 2023 at 10:30, ANQUETIN Mathieu
wrote:
> 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 in the main package
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, rather than some custom
> esdk-specific location (the c
On Tue, 31 Oct 2023 at 13:28, Richard Purdie
wrote:
> > Then we can pull all of it together into 'devtool esdk '
> > command (or similar), which would enter the esdk environment directly
> > via:
> > - running 'bitbake meta-ide-support'
> > - running the above mentioned bitbake local.conf task
On Sun, 5 Nov 2023 at 20:43, wrote:
> Another topic where additional meta data about the sstate-cache seams
> to be beneficial is sstate-mirror retention. Knowing which artifact was
> compiled for which tag or commit of the bitbake layer could help to
> wipe out some artifacts which are not
On Mon, 30 Oct 2023 at 15:07, Richard Purdie
wrote:
> > a) esdk sets a number of variables from its initialization script that
> > aid with cross-compiling components directly (e.g. the core use case
> > of SDKs). Normal mode doesn't do that, but recently added
> > meta-ide-support will generate
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 overhead to
> switch between one and the other. A "bblock all" command does partly
> get you to an eSDK
On Thu, 14 Sept 2023 at 21:54, Richard Purdie
wrote:
> The tools are already supposed to support doing this with local file
> sstate sources, they just do a bad job at getting the diffs right. One
> intent of this work item was to try and understand why they don't work
> and address that so at
t; (https://git.yoctoproject.org/poky-contrib/log/?h=jstephan/bblock),
> trying to fix an autobuilder issue reported by Alexandre Belloni.
> I am still working on this, and I would be very happy to get this merged :)
>
> Cheers
> Julien
>
> Le ven. 15 sept. 2023 à 10:28
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 local sstate to find possible matches, then sorts them by mtime and
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 confused the tools (at least used to). That may
> have been before gcc-source became a recipe?
> b) changes to
On Thu, 28 Sept 2023 at 18:49, Richard Purdie
wrote:
> I've wondered if we should split bitbake -S printdiff into a separate
> utility? It exists from a time before we had bitbake command APIs.
It can also be a simple shell wrapper.
I've separated -S lockedsigs into it's own option as well, so
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
STAMPS_DIR, then runs this:
# Generate the new stamps dir
print("Generating the new
On Fri, 29 Sept 2023 at 14:27, Richard Purdie
wrote:
> I'd prefer to see some dedicated bitbake API used even if we need to
> create/add it. tinfoil and some of the bblock/unlock work shows we can
> get stamp data, the question would be how to get it without
> "disturbing" the existing build.
>
Hello Philip,
when would the time slots be allocated? It doesn't look optimal to
leave this to the last minute, as people need to plan their day.
Alex
On Tue, 17 May 2022 at 03:53, Philip Balister wrote:
>
> We are finalizing the agenda for the developer meeting this Friday (May
> 20). The
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.
Alex
On Mon, 30 May 2022 at 12:51, Richard Purdie
wrote:
>
> I've gone
So let me summarize where I think things should be heading:
1. Any new sdk work should be aiming to adjust the 'core yocto
workflow', e.g. a standard layer checkout, and not create or extend
any separate workflows with their own input artifacts, tests, and code
paths.
2. bblock/bbunlock as core,
On Wed, 18 May 2022 at 09:50, Pascal Bach wrote:
> The advantages of this approach is:
> 1. The bitbake environment and the "sdkenv" are the same. The only
> difference is how you use it (devtool or bitbake) and how much you
> reley on the sstate cache.
> 2. Developers always have the full power
/bbunlock.
Alex
On Wed, 29 Jun 2022 at 11:13, Bach, Pascal wrote:
>
> Hi Alex,
>
> On Wed, 2022-06-22 at 12:38 +0200, Alexander Kanavin via
> lists.openembedded.org wrote:
> > On Wed, 18 May 2022 at 09:50, Pascal Bach
> > wrote:
> >
> > > The advantages
On Wed, 29 Jun 2022 at 11:33, Alexander Kanavin via
lists.openembedded.org
wrote:
> I'm now prototyping the other missing piece for the 'direct SDK
> workflow', which is layer management.
And here it is:
https://lists.openembedded.org/g/openembedded-core/message/167540
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:
On Wed, 6 Jul 2022 at 18:52, Richard Purdie
wrote:
> In particular, it doesn't work with ptests or anything needing bash :(
For bash, I wanted to play with busybox's replacement for it, and see
if it's feasible to set up as alternative, or even default. Too
pressed for time :-(
Alex
On Wed, 20 Jul 2022 at 11:50, Ross Burton wrote:
> Also, Intel should get to have an opinion on this. If they actually care
> about x32 then they can help fix the issues, if they don’t then we can easily
> switch to a platform that has support.
Ok, let's ask Intel, specifically Anuj :-)
On Wed, 20 Jul 2022 at 11:23, Richard Purdie
wrote:
> That amounts to dropping x32 support because as soon as we remove these
> tests, it will bitrot.
>
> There is still some value in the project being able to support
> different architectures and different type sizes so I do still lean
> towards
to ship anything
to customers, and was only devised to look better in benchmarks
against competition.
Alex
On Wed, 20 Jul 2022 at 10:44, Alexander Kanavin via
lists.openembedded.org
wrote:
>
> Signed-off-by: Alexander Kanavin
> ---
> .../rpm/files/0001-CVE-2021-3521.patch
On Wed, 20 Jul 2022 at 17:41, Mittal, Anuj wrote:
> I don't know if there are any Yocto users of it who might notice.
>
> Instead of dropping the testing completely, may be we should switch to
> building/testing just the core-image-minimal image on autobuilder and
> keep at least some minimal
Hello,
an idea just popped into my head that I don't remember having been discussed:
Should stable-branch oe-core issue a warning via bitbake when it is
close to EOL and perhaps a stronger warning when it has crossed it?
I feel that this page:
https://wiki.yoctoproject.org/wiki/Releases
is not
The standard SDK is not going anywhere. Obviously we're not removing
something that has a lot of existing users.
However I think it's still worth for you to play with the 'direct SDK'
(the patches just landed in master) [1]. The built-in extensibility
and ability to trivially update everything is
On Wed, 20 Jul 2022 at 17:46, Alexander Kanavin via
lists.yoctoproject.org
wrote:
>
> On Wed, 20 Jul 2022 at 17:41, Mittal, Anuj wrote:
> > I don't know if there are any Yocto users of it who might notice.
> >
> > Instead of dropping the testing completely,
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 commercial Yocto release which still has support for many
> years.
>
On Tue, 2 Aug 2022 at 09:58, Andre McCurdy wrote:
> Who is the user base you're referring to? The end customer? They don't
> see build logs or EOL warnings. The OEM creating releases to add new
> features to the boxes in the field? They would see the EOL warnings,
> but don't have skills or
On Tue, 2 Aug 2022 at 10:28, Andre McCurdy wrote:
> If your goal is to educate users who might now be aware of the OE
> release cycles then just put a banner such as "This is OE 3.1,
> expected to be supported until at least xxx" as the start of every
> build. No need to wait until EOL, just
On Thu, 18 Aug 2022 at 11:27, Richard Purdie
wrote:
> The intent is the user could add something like:
>
> require conf/yocto-autobuilder/x32.inc
>
> or
>
> require conf/yocto-autobuilder/multilib-mipsn32.inc
>
> and similar to their local.conf and more easily replicate
> configurations.
This
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 update the build config from an
updated template (with an explicit,
On Wed, 28 Sept 2022 at 10:55, Richard Purdie
wrote:
> I wondered about that. The thing is if you're planning to decide to do
> some kind of automated update or user warning message, you need a
> version string in the file itself to know what version you're dealing
> with so whilst I can see why
On Wed, 28 Sept 2022 at 16:25, Peter Kjellerstedt
wrote:
> Personally, I would expect the file to contain the latest value used
> for TEMPLATECONF. I.e., if I remove the local.conf file to regenerate
> it because there has been upstream changes, I would expect it to use
> the TEMPLATECONF I
On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote:
> Please find a few comments:
>
> 1. There is already provided meta-y2038 [1] to test if 32 bit systems
> correctly support Y2038 problem. It uses qemu machines from OE/Yocto
>
> 2. There are ptest available [2] to validate if the Y2038 problem
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. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally.
b. qemu is always
On Wed, 30 Nov 2022 at 10:40, Lukasz Majewski wrote:
> It would be even better if the meta-y2038 could be dropped and _all_
> its functionality could be merged to poky.
>
> That would be _awesome_.
>
> Please just be aware that this meta layer has some fixes for some
> packages (for Y2038 ready
On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote:
> 2. There are ptest available [2] to validate if the Y2038 problem works
> correctly.
>
> 3. Support for running ptests mentioned in point 2. is already
> available in the poky repository [3].
I just ran these tests in (32 bit) qemux86 on top
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
> triggered, not sure. We could have a smaller set of ptests to run for
> it?
I just ran qemux86 full
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
> eSDK tests on our supported qemu targets, 32 and 64 bit.
I think kvm does allow 32 bit guest on a
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
> $ORIGIN there so that $ORIGIN is replaced with the location of the
> binary.
>
> Does anyone have an idea if
I think this can be fixed with a patch that you can propose? E.g.
change the logic to first copy conf-notes.txt into the build dir with
the same conditions as local.conf.sample, then display it out of the
build dir.
Alex
On Sun, 11 Jun 2023 at 16:06, wrote:
>
> Hi,
>
> Sorry for the duplicate
May I suggest trying out sourcehut as the hosting provider for opkg?
https://sourcehut.org
It has all the web niceties, but it's also been built from the ground
up to integrate with the email workflow, unlike any of the 'big' SCM
providers, so if that works out well for opkg, we could consider
For better or worse we do not notify contributors when their patches
have been merged. So you need to pull from master and rebase to see if
your change has landed. Has it?
Alex
On Sat, 22 Jul 2023 at 16:23, Stéphane Veyret wrote:
>
> Hi there,
>
> I sent the patch a few weeks ago now but have
Hello,
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
meta-somelayer/conf/fragments/category/. No special tooling is needed:
you can 'cat fragment.inc >
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 from it. Is there a real need to completely
reset the overall value?
Thanks Peter, this is the argument that I tried but clearly failed to make.
How about I make a patch that sets things to = across all of poky, give it
to a-full build and then we can see what, if anything, falls out? Whatever
the eventual plan may be, this is an experiment worth doing.
Alex
On
On Tue, 2 Jan 2024 at 14:28, Adrian Freihofer
wrote:
> Could some additional operators such as ?+=, ??+=, ?=+, ??=+, -=, ?-=,
> ??-=, =-, ?=-, ??=- make this behavior more obvious?
After working with yocto for (soon) 10 years, I still don't really
understand even how the existing operators work.
On Wed, 22 Nov 2023 at 21:04, Michael Opdenacker via
lists.openembedded.org
wrote:
> The first prototype would only target the below architectures:
>
> - "genericx86-64" architecture through the "genericx86-64" machine
>
On Wed, 22 Nov 2023 at 21:04, Michael Opdenacker via
lists.openembedded.org
wrote:
> - Beginner use case: begin by fetching a binary image, ready to boot on a
>target machine. Extend the system by installing extra applications
> through
>package feeds.
>
> - Intermediate use case: tweak
On Sat, 25 Nov 2023 at 12:50, Sudip Mukherjee
wrote:
> - consider that we may need a divorce from the rpm ecosystem. We don't
> have a particularly well-established relationship with them, and have
> no influence on their roadmap and goals. So maybe we should mark rpm
> package format as
1 - 100 of 106 matches
Mail list logo
