From: Mark Hatle <mark.hatle@windriver.com>
To: Chris Tapp <opensource@keylevel.com>
Cc: yocto@yoctoproject.org
Subject: Re: What builds 'netbase'?
Date: Sun, 20 Feb 2011 09:37:33 -0600 [thread overview]
Message-ID: <4D61353D.9040808@windriver.com> (raw)
In-Reply-To: <72C3267D-6313-42A0-A105-A288B7576F53@keylevel.com>
On 2/20/11 9:31 AM, Chris Tapp wrote:
> On 20 Feb 2011, at 14:51, Mark Hatle wrote:
>
>> If you already have a built copy of netbase in your sstate-cache,
>> all clean will
>> do is remove the built version, and resync from the cache. (bitbake
>> -c cleanall
>> will remove the sstate-cache files as well, forcing a complete
>> rebuild from
>> fetch down to packaging...)
>
> That's what I thought, but if I look to see the sstate files that
> exist after building I see:
>
> ls sstate-cache/sstate-net*
> sstate-cache/sstate-netbase-qemux86-poky-linux-4.41-r1-
> i586-1-5116b681b84a7131255c1771674a020a_deploy-ipk.tgz
> sstate-cache/sstate-netbase-qemux86-poky-linux-4.41-r1-
> i586-1-5116b681b84a7131255c1771674a020a_deploy-ipk.tgz.siginfo
> sstate-cache/sstate-netbase-qemux86-poky-linux-4.41-r1-
> i586-1-733405fb78b4c7e19a746582a97504b2_deploy-rpm.tgz
> sstate-cache/sstate-netbase-qemux86-poky-linux-4.41-r1-
> i586-1-733405fb78b4c7e19a746582a97504b2_deploy-rpm.tgz.siginfo
> sstate-cache/sstate-netbase-qemux86-poky-linux-4.41-r1-
> i586-1-7422fec9d26be091358f8e930110bf37_populate-sysroot.tgz
> sstate-cache/sstate-netbase-qemux86-poky-linux-4.41-r1-
> i586-1-7422fec9d26be091358f8e930110bf37_populate-sysroot.tgz.siginfo
> sstate-cache/sstate-netbase-qemux86-poky-linux-4.41-r1-i586-1-
> f1585ecd0d04332f3ff9b372cac08dd0_package.tgz
> sstate-cache/sstate-netbase-qemux86-poky-linux-4.41-r1-i586-1-
> f1585ecd0d04332f3ff9b372cac08dd0_package.tgz.siginfo
>
> bitbake -c cleanall netbase reports:
> ...
> NOTE: package netbase-4.41-r1: task do_cleanall: Started
> NOTE: Removing /home/chris/yocto/sjs-build/sstate-cache/sstate-netbase-
> qemux86-poky-linux-4.41-r1-
> i586-1-4c81cdca2e1c8da43ee609321b93895f_populate-sysroot.tgz
> NOTE: Removing /home/chris/yocto/sjs-build/sstate-cache/sstate-netbase-
> qemux86-poky-linux-4.41-r1-
> i586-1-4c81cdca2e1c8da43ee609321b93895f_package.tgz
> NOTE: Removing /home/chris/yocto/sjs-build/sstate-cache/sstate-netbase-
> qemux86-poky-linux-4.41-r1-
> i586-1-4c81cdca2e1c8da43ee609321b93895f_deploy-rpm.tgz
> NOTE: Removing /home/chris/yocto/sjs-build/sstate-cache/sstate-netbase-
> qemux86-poky-linux-4.41-r1-
> i586-1-4c81cdca2e1c8da43ee609321b93895f_deploy-ipk.tgz
> NOTE: Removing /home/chris/yocto/yocto-downloads/netbase_4.41.tar.gz*
> NOTE: package netbase-4.41-r1: task do_cleanall: Succeeded
>
> Which looks to me like it just tried to delete the wrong files.
> Looking in sstate-cache shows that the original files are still present.
To me it looks like it deleted exactly what you asked it to. All of the
sstate-netbase-* files, and the downloaded netbase_4.41.tar.gz.
The siginfo files, if they were not deleted won't matter because there is no
matching sstate-cache file. If they do exist, it's likely a small bug -- but
not one to impact functionality.
> This is with a virgin laverne-4.0.1.
>
>> To avoid this, the best way (after changing the netbase) is to
>> adjust the PR
>> within the recipe.
>>
>> My suggestion is if the PR is "12", change it to "12.1" on your first
>> modification, "12.2" on your second, etc..
>
> I'll give that a try. Thanks.
But yes, the best way is to tell bitbake you have a new version rather then
trying to keep cleaning out the older versions and rebuilding them.
For the latest changes in master, we've got planned a bit more control then
simply "clean" and "cleanall", but I don't believe it's implemented yet.
--Mark
next prev parent reply other threads:[~2011-02-20 15:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-19 14:58 What builds 'netbase'? Chris Tapp
2011-02-19 16:16 ` Gary Thomas
2011-02-19 21:39 ` Chris Tapp
2011-02-21 2:25 ` Tian, Kevin
2011-02-20 14:51 ` Mark Hatle
2011-02-20 15:31 ` Chris Tapp
2011-02-20 15:37 ` Mark Hatle [this message]
2011-02-20 15:50 ` Chris Tapp
2011-02-20 17:46 ` Mark Hatle
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=4D61353D.9040808@windriver.com \
--to=mark.hatle@windriver.com \
--cc=opensource@keylevel.com \
--cc=yocto@yoctoproject.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 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.