On Thu, 14 Sept 2023 at 13:52, 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 thought I'd write a summary of where we are with these subjects, and
make a plan for what needs to be done still:
On 11/5/23 1:43 PM, Adrian Freihofer wrote:
On Sat, 2023-11-04 at 11:09 +, Richard Purdie wrote:
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.
*
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 Sat, 2023-11-04 at 11:09 +, Richard Purdie wrote:
> 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
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
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 locked sstate-cache.
- Yocto/BSP developers: need an unlocked SDK. They change
On Wed, 2023-11-01 at 16:19 +0100, Alexander Kanavin via
lists.openembedded.org wrote:
> 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
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
Hi Alex, hi Richard
The discussion looks really interesting. I would like to contribute
some comments from the point of view of a rather naive user and try to
understand the workflows for which these improvements would be
beneficial also on a bigger picture.
On Thu, 2023-09-14 at 20:51 +0200,
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 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, 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 code to generate that
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 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 overhead to
> > switch between one and the
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
Unless I missed something, I think I fixed all comments from RP on the
branch I force pushed :)
Cheers
Julien
Le mer. 20 sept. 2023 à 16:31, Alexander Kanavin
a écrit :
>
> That’s great to hear! When you have a new patch set please post it here. I
> think there’s also a new reply from RP that
That’s great to hear! When you have a new patch set please post it here. I
think there’s also a new reply from RP that you need to consider.
Alex
On Wed 20. Sep 2023 at 16.25, Julien Stephan wrote:
> Hi Alexander,
> About bblock tool: I just force pushed my branch on poky-contrib
>
Hi Alexander,
About bblock tool: I just force pushed my branch on poky-contrib
(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
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 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
> > will be reused? There is
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 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
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:
24 matches
Mail list logo
