From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Khem Raj <raj.khem@gmail.com>
Cc: Poky <poky@lists.pokylinux.org>,
Koen Kooi <koen@dominion.thruhere.net>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [poky] Is sstate broken
Date: Wed, 09 Mar 2011 15:04:07 -0800 [thread overview]
Message-ID: <1299711847.602.1015.camel@rex> (raw)
In-Reply-To: <AANLkTin6pW+Om2qF1Ey5=ftWfkNh3FtzRB01fqCmo+EP@mail.gmail.com>
On Wed, 2011-03-09 at 13:51 -0800, Khem Raj wrote:
> On Wed, Mar 9, 2011 at 11:30 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >
> > Op 9 mrt 2011, om 20:04 heeft Richard Purdie het volgende geschreven:
> >
> >> On Wed, 2011-03-09 at 11:42 -0700, Gary Thomas wrote:
> >>> I updated to master (fab742bd4693ed3092690a20dd32d53fe27c3d4c) and tried again.
> >>> I don't see any difference - the run using the sstate cache as a mirror
> >>> seems to do all the same work as without. Here's how I tested it.
> >>>
> >>> * Build original tree
> >>> % POKYCONF=meta-cobra3530p60/conf . /tmp/poky-amltd/poky-init-build-env /local/p60_step1
> >>> ... adjust conf/local.conf
> >>> % bitbake amltd-console-image
> >>>
> >>> * Rebuild, using previous result for SSTATE_MIRRORS
> >>> % POKYCONF=meta-cobra3530p60/conf . /tmp/poky-amltd/poky-init-build-env /local/p60_step2
> >>> ... adjust conf/local.conf
> >>> % bitbake amltd-console-image
> >>>
> >>> The only difference between the two runs is enabling SSTATE_MIRRORS in local.conf
> >>> % diff -u /local/p60_step?/conf/local.conf
> >>> --- /local/p60_step1/conf/local.conf 2011-03-09 08:28:18.266933061 -0700
> >>> +++ /local/p60_step2/conf/local.conf 2011-03-09 09:57:51.365932951 -0700
> >>> @@ -53,4 +53,7 @@
> >>> IMAGE_LINGUAS ?= "en-us"
> >>>
> >>> # Minimize feature set
> >>> DISTRO_FEATURES ?= "alsa"
> >>> +SSTATE_MIRRORS ?= "\
> >>> +file://.* file:///local/p60_step1/sstate-cache/"
> >>>
> >>> The results seem to have gone through all the same steps (or nearly so). The output
> >>> from the runs is at
> >>> http://www.mlbassoc.com/poky/build.step1
> >>> http://www.mlbassoc.com/poky/build.step2
> >>>
> >>> Comparing the two build trees:
> >>> % ls /local/p60_step1/tmp/work/*/*/temp/log.do_compile | wc
> >>> 144 144 12521
> >>> % ls /local/p60_step2/tmp/work/*/*/temp/log.do_compile | wc
> >>> 143 143 12427
> >>> % du -s /local/p60_step?
> >>> 15229296 /local/p60_step1
> >>> 15162760 /local/p60_step2
> >>>
> >>> I know this procedure used to work (or at least close). Am I doing
> >>> something wrong?
> >>
> >> You're not doing anything wrong and this is the same scenario I've been
> >> testing with. After I'd fixed the origin problem it created a problem
> >> with file urls containing globing. I managed to break the original patch
> >> with the globing fix. The good news is the problem is simple and I've
> >> pushed a fix.
> >
> > Is that fix in oe-core as well?
>
> I guess its hardening in yocto and eventually will make into oe-core
> which is good.
Its a bitbake change and will head into bitbake as soon as we've got
some positive test reports back from Gary and Yocto's QA people.
Cheers,
Richard
WARNING: multiple messages have this Message-ID (diff)
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Khem Raj <raj.khem@gmail.com>
Cc: Poky <poky@lists.pokylinux.org>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Is sstate broken
Date: Wed, 09 Mar 2011 15:04:07 -0800 [thread overview]
Message-ID: <1299711847.602.1015.camel@rex> (raw)
In-Reply-To: <AANLkTin6pW+Om2qF1Ey5=ftWfkNh3FtzRB01fqCmo+EP@mail.gmail.com>
On Wed, 2011-03-09 at 13:51 -0800, Khem Raj wrote:
> On Wed, Mar 9, 2011 at 11:30 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >
> > Op 9 mrt 2011, om 20:04 heeft Richard Purdie het volgende geschreven:
> >
> >> On Wed, 2011-03-09 at 11:42 -0700, Gary Thomas wrote:
> >>> I updated to master (fab742bd4693ed3092690a20dd32d53fe27c3d4c) and tried again.
> >>> I don't see any difference - the run using the sstate cache as a mirror
> >>> seems to do all the same work as without. Here's how I tested it.
> >>>
> >>> * Build original tree
> >>> % POKYCONF=meta-cobra3530p60/conf . /tmp/poky-amltd/poky-init-build-env /local/p60_step1
> >>> ... adjust conf/local.conf
> >>> % bitbake amltd-console-image
> >>>
> >>> * Rebuild, using previous result for SSTATE_MIRRORS
> >>> % POKYCONF=meta-cobra3530p60/conf . /tmp/poky-amltd/poky-init-build-env /local/p60_step2
> >>> ... adjust conf/local.conf
> >>> % bitbake amltd-console-image
> >>>
> >>> The only difference between the two runs is enabling SSTATE_MIRRORS in local.conf
> >>> % diff -u /local/p60_step?/conf/local.conf
> >>> --- /local/p60_step1/conf/local.conf 2011-03-09 08:28:18.266933061 -0700
> >>> +++ /local/p60_step2/conf/local.conf 2011-03-09 09:57:51.365932951 -0700
> >>> @@ -53,4 +53,7 @@
> >>> IMAGE_LINGUAS ?= "en-us"
> >>>
> >>> # Minimize feature set
> >>> DISTRO_FEATURES ?= "alsa"
> >>> +SSTATE_MIRRORS ?= "\
> >>> +file://.* file:///local/p60_step1/sstate-cache/"
> >>>
> >>> The results seem to have gone through all the same steps (or nearly so). The output
> >>> from the runs is at
> >>> http://www.mlbassoc.com/poky/build.step1
> >>> http://www.mlbassoc.com/poky/build.step2
> >>>
> >>> Comparing the two build trees:
> >>> % ls /local/p60_step1/tmp/work/*/*/temp/log.do_compile | wc
> >>> 144 144 12521
> >>> % ls /local/p60_step2/tmp/work/*/*/temp/log.do_compile | wc
> >>> 143 143 12427
> >>> % du -s /local/p60_step?
> >>> 15229296 /local/p60_step1
> >>> 15162760 /local/p60_step2
> >>>
> >>> I know this procedure used to work (or at least close). Am I doing
> >>> something wrong?
> >>
> >> You're not doing anything wrong and this is the same scenario I've been
> >> testing with. After I'd fixed the origin problem it created a problem
> >> with file urls containing globing. I managed to break the original patch
> >> with the globing fix. The good news is the problem is simple and I've
> >> pushed a fix.
> >
> > Is that fix in oe-core as well?
>
> I guess its hardening in yocto and eventually will make into oe-core
> which is good.
Its a bitbake change and will head into bitbake as soon as we've got
some positive test reports back from Gary and Yocto's QA people.
Cheers,
Richard
next prev parent reply other threads:[~2011-03-10 1:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-24 15:14 Is sstate broken Gary Thomas
2011-02-28 6:07 ` Zhai, Edwin
2011-03-03 12:56 ` Gary Thomas
2011-03-04 1:59 ` Zhai, Edwin
2011-03-04 11:34 ` Gary Thomas
2011-03-09 1:29 ` Richard Purdie
2011-03-09 18:42 ` Gary Thomas
2011-03-09 19:04 ` Richard Purdie
2011-03-09 19:30 ` [poky] " Koen Kooi
2011-03-09 19:30 ` Koen Kooi
2011-03-09 21:51 ` [poky] " Khem Raj
2011-03-09 21:51 ` Khem Raj
2011-03-09 23:04 ` Richard Purdie [this message]
2011-03-09 23:04 ` Richard Purdie
2011-03-09 20:26 ` Gary Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1299711847.602.1015.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--cc=koen@dominion.thruhere.net \
--cc=openembedded-core@lists.openembedded.org \
--cc=poky@lists.pokylinux.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.