What builds 'netbase'?

What builds 'netbase'?

[Chris Tapp]

I want to make some changes to /etc/interfaces.

It looks to me as if this this comes from 'netbase', but what do I  
need to rebuild to get my changes in to the rootfs? i.e. is there  
something I can

bitbake -c clean ???; bitbake ???

to get my changes in to the rootfs image?

I tried cleaning 'netbase', but that made no difference when I then  
'bitbake poky-image-minimal'.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: What builds 'netbase'?

[Gary Thomas]

On 02/19/2011 07:58 AM, Chris Tapp wrote:
> I want to make some changes to /etc/interfaces.
>
> It looks to me as if this this comes from 'netbase', but what do I need to rebuild to get my changes in to the rootfs? i.e. is there something I can
>
> bitbake -c clean ???; bitbake ???
>
> to get my changes in to the rootfs image?
>
> I tried cleaning 'netbase', but that made no difference when I then 'bitbake poky-image-minimal'.

Did you clean the shared state (sstate-cache) info that I told you about yesterday?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: What builds 'netbase'?

[Chris Tapp]

On 19 Feb 2011, at 16:16, Gary Thomas wrote:

> On 02/19/2011 07:58 AM, Chris Tapp wrote:
>> I want to make some changes to /etc/interfaces.
>>
>> It looks to me as if this this comes from 'netbase', but what do I  
>> need to rebuild to get my changes in to the rootfs? i.e. is there  
>> something I can
>>
>> bitbake -c clean ???; bitbake ???
>>
>> to get my changes in to the rootfs image?
>>
>> I tried cleaning 'netbase', but that made no difference when I then  
>> 'bitbake poky-image-minimal'.
>
> Did you clean the shared state (sstate-cache) info that I told you  
> about yesterday?

I have now, and it may have made a difference. I say 'may' because the  
build failed else where in a way I couldn't fix without deleting tmp/  
and rebuilding. I'll try again later ;-)

It seems as if this sstate-cache trick is worth using by default.

I'm having a problem with libSDL linking against libdirectfb-1.2, not  
the 1.4 that's in the build. I had previously done a 'cleanall'  
rebuild of libSDL to see if anything showed up, but there was nothing  
to see.

However, doing the same and deleting the sstate-cache items as well  
means that I can now see warnings to say that it uses /usr/include  
and /usr/lib (which is where it gets the 1.2 from).

Is this behaviour 'by design' (i.e. something that should always be  
done), or is it an issue with bitbake? I can't see anything in the  
Yocto bugzilla if it is.

Chris

Re: What builds 'netbase'?

[Mark Hatle]

On 2/19/11 8:58 AM, Chris Tapp wrote:
> I want to make some changes to /etc/interfaces.
> 
> It looks to me as if this this comes from 'netbase', but what do I  
> need to rebuild to get my changes in to the rootfs? i.e. is there  
> something I can
> 
> bitbake -c clean ???; bitbake ???
> 
> to get my changes in to the rootfs image?
> 
> I tried cleaning 'netbase', but that made no difference when I then  
> 'bitbake poky-image-minimal'.

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...)

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..

--Mark

> Chris Tapp
> 
> opensource@keylevel.com
> www.keylevel.com
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: What builds 'netbase'?

[Chris Tapp]

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.

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.

Chris

Re: What builds 'netbase'?

[Mark Hatle]

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

Re: What builds 'netbase'?

[Chris Tapp]

On 20 Feb 2011, at 15:37, Mark Hatle wrote:

> 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.

It's not that easy to see when the lines get mangled. Below are the  
ends of the 'ls' and 'cleanall' names for _populate_sysroot.

sstate: -7422fec9d26be091358f8e930110bf37_populate-sysroot.tgz  
(existing file after build)
NOTE:   -4c81cdca2e1c8da43ee609321b93895f_populate-sysroot.tgz  
(cleanall delete target)

Doesn't this show that the wrong one was targeted for deletion?

> 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.

That sounds interesting. For example, it would be nice to be able to  
clean everything except the download (useful when working off-line).

Chris

Re: What builds 'netbase'?

[Mark Hatle]

On 2/20/11 9:50 AM, Chris Tapp wrote:
> On 20 Feb 2011, at 15:37, Mark Hatle wrote:
> 
>> 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.
> 
> It's not that easy to see when the lines get mangled. Below are the  
> ends of the 'ls' and 'cleanall' names for _populate_sysroot.
> 
> sstate: -7422fec9d26be091358f8e930110bf37_populate-sysroot.tgz  
> (existing file after build)
> NOTE:   -4c81cdca2e1c8da43ee609321b93895f_populate-sysroot.tgz  
> (cleanall delete target)
> 
> Doesn't this show that the wrong one was targeted for deletion?

No, the md5sum is the signature of the recipe.  If the signature changes, it
should avoid the sstate-cache and rebuild.  If it's still pulling in the version
from the sstate, even though the signature changed.. this could indicate a problem.

(Any time you change the recipe or referenced files in the recipe the signature
should be changing...  this won't trigger a rebuild though until you do a
bitbake -c clean ...  It will recompute the signature, see it doesn't match the
sstate and build...)

--Mark

>> 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.
> 
> That sounds interesting. For example, it would be nice to be able to  
> clean everything except the download (useful when working off-line).
> 
> Chris
> 
> 

Re: What builds 'netbase'?

[Tian, Kevin]

> From: Gary Thomas
> Sent: Sunday, February 20, 2011 12:16 AM
> 
> On 02/19/2011 07:58 AM, Chris Tapp wrote:
> > I want to make some changes to /etc/interfaces.
> >
> > It looks to me as if this this comes from 'netbase', but what do I need to
> rebuild to get my changes in to the rootfs? i.e. is there something I can
> >
> > bitbake -c clean ???; bitbake ???
> >
> > to get my changes in to the rootfs image?
> >
> > I tried cleaning 'netbase', but that made no difference when I then 'bitbake
> poky-image-minimal'.
> 
> Did you clean the shared state (sstate-cache) info that I told you about
> yesterday?

I think we should extend checksum to cover local files/patches, instead of just
recipe variables. This way old sstate cache will be automatically invalided due
to different checksum from /etc/interfaces change.

On the other hand, bitbake task scheduling is done in a reverse order, i.e.
starting from poky-image-minimal.do_build, and then the task including netbase
and then netbase. Here if you bump up PR for netbase, the dependency is considered
and then all the recipes recursively depending on netbase will be rebuilt automatically.
If you don't want to bump up PR, then you have to also manually clean up 
task-poky-boot to make sure new netbase outputs integrated in new minimal image.

Thanks
Kevin