Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: sstate.bbclass: Ensure machine specific stamps are only wiped for the current task
Date: Mon, 10 Oct 2011 16:41:36 +0200	[thread overview]
Message-ID: <20111010144136.GD5065@jama.jama.net> (raw)
In-Reply-To: <20848535-6A4E-47B5-9F7D-E96F00402867@dominion.thruhere.net>

[-- Attachment #1: Type: text/plain, Size: 5153 bytes --]

On Mon, Oct 10, 2011 at 04:37:51PM +0200, Koen Kooi wrote:
> 
> Op 10 okt. 2011, om 16:16 heeft Richard Purdie het volgende geschreven:
> 
> > On Mon, 2011-10-10 at 13:45 +0200, Martin Jansa wrote:
> >> On Sun, Oct 09, 2011 at 08:11:45PM +0200, Koen Kooi wrote:
> >>> 
> >>> Op 9 okt. 2011, om 20:10 heeft Martin Jansa het volgende geschreven:
> >>> 
> >>>> On Sun, Oct 09, 2011 at 01:25:09PM +0200, Koen Kooi wrote:
> >>>>> 
> >>>>> Op 6 okt. 2011, om 16:19 heeft Richard Purdie het volgende geschreven:
> >>>>> 
> >>>>>> sstate was being a little too ethusiastic about removing stamp files and
> >>>>>> was removing stamp files for other machines when it shouldn't have been.
> >>>>>> 
> >>>>>> This patch teaches sstate about machine specific stamp extensions and
> >>>>>> allows it to only remove the current task's stampfiles.
> >>>>> 
> >>>>> Not sure if it's related to this problem or not but sstate is still not working as intented for me when switching machines, it keeps rebuilding the toolchain when switching machine. What I did this morning:
> >>>>> 
> >>>>> 1) wipe out tmp, sstate-cache, pseudodone
> >>>>> 2) MACHINE=beagleboard bitbake u-boot
> >>>>> 3) cp conf/machine/beagleboard.conf conf/machine/brokensstate.conf
> >>>>> 4) MACHINE=brokensstate bitbake u-boot
> >>>> 
> >>>> Same here.. :/ (building 3 armv7 machines.. always "from scratch").
> >>> 
> >>> To eliminate varables: Angstrom/shr/aurora/micro/other/all of the above?
> >> 
> >> DISTRO=shr
> >> 
> >> MACHINE=nokia900 bitbake shr-image -> builds from scratch, finished ok
> >> MACHINE=palmpre bitbake shr-image -> builds from scratch, finished ok
> >> MACHINE=palmpre2 bitbake shr-image -> builds from scratch, finished ok
> >> 
> >> without wiping anything (same tmp, same sstate-cache, same pseudodone)
> >> 
> >> MACHINE=palmpre bitbake shr-image -> builds from scratch, again!, finished ok
> >> MACHINE=palmpre2 bitbake shr-image -> builds from scratch, again!, finished ok
> >> MACHINE=nokia900 bitbake shr-image -> builds from scratch, again!, finished ok
> >> 
> >> palmpre and palmpre2 are "the same"
> >> $ cat meta-smartphone/meta-palm/conf/machine/palmpre.conf | grep -v ^#
> >> require conf/machine/include/palmpre.inc
> >> 
> >> $ cat meta-smartphone/meta-palm/conf/machine/palmpre2.conf | grep -v ^#
> >> require conf/machine/include/palmpre.inc
> >> 
> >> nokia900 is also armv7a-vfp-neon (that's why all packages except
> >> MACHINE_ARCH were always reused without rebuilding in OE-classic).
> >> 
> >> I have tried to debug sigdata files to see why and also tried to add
> >> MACHINEOVERRIDES[vardepsexclude] = "MACHINE"
> >> as RP suggested, but sofar haven't found solution at least to reuse
> >> already built sstate packages for armv7a-vfp-neon.
> > 
> > Also as a tip for debugging this, you can do what is in the following
> > commit (patch also inline below):
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip9&id=1261cc69b152f33b934c2448020dfa3c95f312c6
> > 
> > which will mean bitbake -n generates stamp files for a given bitbake
> > run. You can then quickly do:
> > 
> > MACHINE=A bitbake -n foo
> > MACHINE=B bitbake -n foo
> > 
> > for example and then look for cases where two stamp sigdata files were
> > generated. If you see them you can "bitbake-diffsigs A B" and I'll be
> > very interested in the results of that and "bitbake-diffsigs A"...
> > 
> > Cheers,
> > 
> > Richard
> > 
> > bitbake: Allow easier dry run stamp debugging
> > 
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> > diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py
> 
> This seems to be against poky instead of bitbake and doesn't apply against bitbake master:
> 
> koen@dominion:/OE/tentacle/sources/bitbake$ patch -p2 < dry 
> patching file lib/bb/build.py
> Hunk #1 succeeded at 257 (offset 2 lines).
> Hunk #2 succeeded at 319 (offset 2 lines).
> Hunk #3 succeeded at 360 (offset 2 lines).
> patching file lib/bb/runqueue.py
> Hunk #1 FAILED at 1156.
> 1 out of 1 hunk FAILED -- saving rejects to file lib/bb/runqueue.py.rej

Same problem here.. seems like diff is bigger then it was before:
both current master

OE @ ~/projects $ diff -rq poky/bitbake/ bitbake/ | grep -v pyc | grep -v pyo | grep -v .git
Only in bitbake/: MANIFEST.in
Only in bitbake/: TODO
Only in poky/bitbake/bin: bitbake-runtask
Only in bitbake/: classes
Only in bitbake/: conf
Files poky/bitbake/lib/bb/__init__.py and bitbake/lib/bb/__init__.py differ
Files poky/bitbake/lib/bb/build.py and bitbake/lib/bb/build.py differ
Files poky/bitbake/lib/bb/cooker.py and bitbake/lib/bb/cooker.py differ
Files poky/bitbake/lib/bb/parse/parse_py/BBHandler.py and bitbake/lib/bb/parse/parse_py/BBHandler.py differ
Files poky/bitbake/lib/bb/pysh/pyshtables.py and bitbake/lib/bb/pysh/pyshtables.py differ
Files poky/bitbake/lib/bb/runqueue.py and bitbake/lib/bb/runqueue.py differ
Only in poky/bitbake/lib/bb: shell.py
Only in bitbake/: setup.py

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

  reply	other threads:[~2011-10-10 14:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-06 14:19 sstate.bbclass: Ensure machine specific stamps are only wiped for the current task Richard Purdie
2011-10-06 20:57 ` Koen Kooi
2011-10-09 11:25 ` Koen Kooi
2011-10-09 18:10   ` Martin Jansa
2011-10-09 18:11     ` Koen Kooi
2011-10-10 11:45       ` Martin Jansa
2011-10-10 14:16         ` Richard Purdie
2011-10-10 14:37           ` Koen Kooi
2011-10-10 14:41             ` Martin Jansa [this message]
2011-10-10 15:17               ` Richard Purdie
2011-10-10 14:17         ` Richard Purdie
2011-11-03 16:33           ` Martin Jansa
2011-11-03 22:08             ` Martin Jansa
2011-11-04  9:32               ` Martin Jansa

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=20111010144136.GD5065@jama.jama.net \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox