On Mon, Mar 04, 2019 at 04:21:48PM +, Richard Purdie wrote:
> On Mon, 2019-03-04 at 11:14 -0500, Tom Rini wrote:
> > On Mon, Mar 04, 2019 at 04:06:47PM +, Richard Purdie wrote:
> > > You mean like the BB_MIN_VERSION variable:
> > >
> > > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/
On Mon, 2019-03-04 at 11:14 -0500, Tom Rini wrote:
> On Mon, Mar 04, 2019 at 04:06:47PM +, Richard Purdie wrote:
> > You mean like the BB_MIN_VERSION variable:
> >
> > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/sanity.conf#n6
> >
> > ?
> >
> > :)
> >
> > The changes were inten
On Mon, Mar 4, 2019, 10:06 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Mon, 2019-03-04 at 10:58 -0500, Tom Rini wrote:
> > Ah, so "poky" got me thinking this morning. I was just on bitbake
> > v1.40
> > (since I usually use thud, and that's the version for that). Moving
>
On Mon, Mar 04, 2019 at 04:06:47PM +, Richard Purdie wrote:
> On Mon, 2019-03-04 at 10:58 -0500, Tom Rini wrote:
> > Ah, so "poky" got me thinking this morning. I was just on bitbake
> > v1.40
> > (since I usually use thud, and that's the version for that). Moving
> > to
> > bitbake master/ti
On Mon, 2019-03-04 at 10:58 -0500, Tom Rini wrote:
> Ah, so "poky" got me thinking this morning. I was just on bitbake
> v1.40
> (since I usually use thud, and that's the version for that). Moving
> to
> bitbake master/tip and I don't see the problem anymore.
>
> Is it possible to have some logi
On Sun, Mar 03, 2019 at 04:11:36PM -0600, Joshua Watt wrote:
> On Sun, Mar 3, 2019 at 3:25 PM Tom Rini wrote:
> >
> > On Sun, Mar 03, 2019 at 03:21:12PM -0600, Joshua Watt wrote:
> > > On Sun, Mar 3, 2019, 2:47 PM Tom Rini wrote:
> > >
> > > > Hey all,
> > > >
> > > > As part of the packagegroup-
On Mon, Mar 04, 2019 at 10:17:21AM +, Burton, Ross wrote:
> On Sun, 3 Mar 2019 at 22:52, Tom Rini wrote:
> > SSTATE_DIR =
> > "${HOME}/work/OE/sstate-cache-${DISTRO_VERSION}${TARGET_VENDOR}"
>
> FWIW there isn't much point in isolating sstate like that. You'll
> just rebuild stuff that woul
4TB of sstate is just for few weeks for me :).
On Mon, Mar 4, 2019 at 11:45 AM Burton, Ross wrote:
> On Mon, 4 Mar 2019 at 10:27, Martin Jansa wrote:
> > There is, you can prune outdated duplicate sstate archives while still
> separately building multiple DISTRO_VERSIONs.
>
> We don't all have
On Mon, 4 Mar 2019 at 10:27, Martin Jansa wrote:
> There is, you can prune outdated duplicate sstate archives while still
> separately building multiple DISTRO_VERSIONs.
We don't all have 4TB disks? :)
Ross
--
___
Openembedded-core mailing list
Opene
There is, you can prune outdated duplicate sstate archives while still
separately building multiple DISTRO_VERSIONs.
On Mon, Mar 4, 2019 at 11:17 AM Burton, Ross wrote:
> On Sun, 3 Mar 2019 at 22:52, Tom Rini wrote:
> > SSTATE_DIR =
> "${HOME}/work/OE/sstate-cache-${DISTRO_VERSION}${TARGET_VEND
On Sun, 3 Mar 2019 at 22:52, Tom Rini wrote:
> SSTATE_DIR = "${HOME}/work/OE/sstate-cache-${DISTRO_VERSION}${TARGET_VENDOR}"
FWIW there isn't much point in isolating sstate like that. You'll
just rebuild stuff that would have been available.
Ross
--
On Sun, Mar 03, 2019 at 04:20:49PM -0600, Joshua Watt wrote:
> On Sun, Mar 3, 2019 at 4:11 PM Joshua Watt wrote:
> >
> > On Sun, Mar 3, 2019 at 3:25 PM Tom Rini wrote:
> > >
> > > On Sun, Mar 03, 2019 at 03:21:12PM -0600, Joshua Watt wrote:
> > > > On Sun, Mar 3, 2019, 2:47 PM Tom Rini wrote:
>
On Sun, Mar 3, 2019 at 4:11 PM Joshua Watt wrote:
>
> On Sun, Mar 3, 2019 at 3:25 PM Tom Rini wrote:
> >
> > On Sun, Mar 03, 2019 at 03:21:12PM -0600, Joshua Watt wrote:
> > > On Sun, Mar 3, 2019, 2:47 PM Tom Rini wrote:
> > >
> > > > Hey all,
> > > >
> > > > As part of the packagegroup-core-bas
On Sun, Mar 3, 2019 at 3:25 PM Tom Rini wrote:
>
> On Sun, Mar 03, 2019 at 03:21:12PM -0600, Joshua Watt wrote:
> > On Sun, Mar 3, 2019, 2:47 PM Tom Rini wrote:
> >
> > > Hey all,
> > >
> > > As part of the packagegroup-core-base-utils series I noticed that
> > > with rm_work enabled like I usual
On Sun, Mar 03, 2019 at 03:21:12PM -0600, Joshua Watt wrote:
> On Sun, Mar 3, 2019, 2:47 PM Tom Rini wrote:
>
> > Hey all,
> >
> > As part of the packagegroup-core-base-utils series I noticed that
> > with rm_work enabled like I usually have, every build was starting over
> > with rebuilding linu
On Sun, Mar 3, 2019, 2:47 PM Tom Rini wrote:
> Hey all,
>
> As part of the packagegroup-core-base-utils series I noticed that
> with rm_work enabled like I usually have, every build was starting over
> with rebuilding linux-libc-headers and going down from there. I
> finished bisecting this now
Hey all,
As part of the packagegroup-core-base-utils series I noticed that
with rm_work enabled like I usually have, every build was starting over
with rebuilding linux-libc-headers and going down from there. I
finished bisecting this now and it comes down to:
commit d889acb4f8f06f09cece80fa1266
17 matches
Mail list logo
