WebHob feedback on early design prototype

WebHob feedback on early design prototype

[Liu, Song]

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

Hi all,

This came up in today's technical team meeting (please see minutes). Design firm Tobias & Tobias are helping with the design of a web UI for analysing builds and images. They are looking for people willing to test & give feedback on an early-stage design prototype. Interviews will be conducted via phone or Skype and take about 30 minutes.

If you can participate, please email: chris.kaminski@tobias.tv<mailto:chris.kaminski@tobias.tv>. It will be very helpful to the project and most importantly to get your requirement/suggestion into the system earlier.

Thanks,
Song

[-- Attachment #2: Type: text/html, Size: 2567 bytes --]

Busybox still old version: Still looking for a clear understanding of an old mystery.

[Brian Smucker]

Hello All,

I'm a relative newbie to yocto/oe, but have got a ways down the road to 
understanding, but the gaps in my understanding cause me great grief at 
times.

I think this probably is a simple question, but somehow I'm doing 
something wrong.

I recompile busybox with a new config: bitbake -c menuconfig busybox
I make busybox: bitbake busybox
bitbake gets compiled.

Then I do a bitbake core-image-minimal.  It does the do_rootfs action 
and makes a new image.
But the busybox is not the newly-compiled one, it is old.
I expect the new version.
Maybe my expectations are wrong.  But I've struggled with this and 
similar scenarios time and time again, sometimes hitting on a 
combination of things that work or by selectively deleting a directory 
or so or by bitbake -c cleansstate -f on one target or another.

But it's always been kind of a mystery to me how to recompile a 
particular target, which then succeeds, and subsequently make sure that 
target is included in the image target (core-image-minimal). I've 
succeeded in a hit-or-miss way at times, but I would love to know a 
clear series of steps that will work definitively.

I know I can delete the entire tmp directory, but that seems far too 
extreme, not to mention slow to recover from.

Can someone help me?

I'm using Danny.

Thanks,
Brian

Re: Busybox still old version: Still looking for a clear understanding of an old mystery.

[Rudolf Streif]

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

Brian,

What are you exactly referring to as "new version"? The package version
that bitbake builds is defined by the recipe, through the version
designation in the recipe's file name or through explicitly setting PV.

I think what you are trying to do is to modify the busybox configuration
and then recompile and package. Bitbake will not automatically recompile
after menuconfig. Menuconfig does not invslidate the shared state cache.
Try this:

bitbake -c menuconfig busybox
bitbake -c -f compile busybox
bitbake busybox

BR,
Rudi
On Jan 15, 2013 1:27 PM, "Brian Smucker" <bds@bsmucker.eu.org> wrote:

> Hello All,
>
> I'm a relative newbie to yocto/oe, but have got a ways down the road to
> understanding, but the gaps in my understanding cause me great grief at
> times.
>
> I think this probably is a simple question, but somehow I'm doing
> something wrong.
>
> I recompile busybox with a new config: bitbake -c menuconfig busybox
> I make busybox: bitbake busybox
> bitbake gets compiled.
>
> Then I do a bitbake core-image-minimal.  It does the do_rootfs action and
> makes a new image.
> But the busybox is not the newly-compiled one, it is old.
> I expect the new version.
> Maybe my expectations are wrong.  But I've struggled with this and similar
> scenarios time and time again, sometimes hitting on a combination of things
> that work or by selectively deleting a directory or so or by bitbake -c
> cleansstate -f on one target or another.
>
> But it's always been kind of a mystery to me how to recompile a particular
> target, which then succeeds, and subsequently make sure that target is
> included in the image target (core-image-minimal). I've succeeded in a
> hit-or-miss way at times, but I would love to know a clear series of steps
> that will work definitively.
>
> I know I can delete the entire tmp directory, but that seems far too
> extreme, not to mention slow to recover from.
>
> Can someone help me?
>
> I'm using Danny.
>
> Thanks,
> Brian
>
>
>
>
>
>
> ______________________________**_________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>

[-- Attachment #2: Type: text/html, Size: 2755 bytes --]

Re: Busybox still old version: Still looking for a clear understanding of an old mystery.

[Brian Smucker]

Hi Rudolf,

On 1/15/2013 3:28 PM, Rudolf Streif wrote:
>
> Brian,
>
> What are you exactly referring to as "new version"? The package 
> version that bitbake builds is defined by the recipe, through the 
> version designation in the recipe's file name or through explicitly 
> setting PV.
>
> I think what you are trying to do is to modify the busybox 
> configuration and then recompile and package. Bitbake will not 
> automatically recompile after menuconfig. Menuconfig does not 
> invslidate the shared state cache. Try this:
>
> bitbake -c menuconfig busybox
> bitbake -c -f compile busybox
> bitbake busybox
>
>
So I have done the above.  That is not the question.  Busybox compiles 
fine and the new unstripped busybox is in the 
.../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/

My question is that after compiling busybox, I do

bitbake -c cleansstate core-image-minimal
bitbake core-image-minimal

expecting that the core image generated will contain the new busybox.  
It does not, it contains a busybox copy that was compiled days ago, not 
the custom one I just compiled.

Why is this?  How can I force the bitbake to include the newly-compiled 
busybox into my minimal image?

Thanks,

Brian

Re: Busybox still old version: Still looking for a clear understanding of an old mystery.

[Autif Khan]

On Tue, Jan 15, 2013 at 6:57 PM, Brian Smucker <bds@bsmucker.eu.org> wrote:
> Hi Rudolf,
>
>
> On 1/15/2013 3:28 PM, Rudolf Streif wrote:
>>
>>
>> Brian,
>>
>> What are you exactly referring to as "new version"? The package version
>> that bitbake builds is defined by the recipe, through the version
>> designation in the recipe's file name or through explicitly setting PV.
>>
>> I think what you are trying to do is to modify the busybox configuration
>> and then recompile and package. Bitbake will not automatically recompile
>> after menuconfig. Menuconfig does not invslidate the shared state cache. Try
>> this:
>>
>> bitbake -c menuconfig busybox
>> bitbake -c -f compile busybox
>> bitbake busybox
>>
>>
> So I have done the above.  That is not the question.  Busybox compiles fine
> and the new unstripped busybox is in the
> .../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/

What is the new version of busybox?

What is the full filename of the new recipe that you created to
compile a new version of busybox? For example the old one is
busybox_1.20.2.bb (in meta/recipes-core/busybox)

Also, can you please paste the .bb file in the email

> My question is that after compiling busybox, I do
>
> bitbake -c cleansstate core-image-minimal
> bitbake core-image-minimal
>
> expecting that the core image generated will contain the new busybox.  It
> does not, it contains a busybox copy that was compiled days ago, not the
> custom one I just compiled.
>
> Why is this?  How can I force the bitbake to include the newly-compiled
> busybox into my minimal image?
>
>
> Thanks,
>
> Brian
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Busybox still old version: Still looking for a clear understanding of an old mystery.

[Brian Smucker]

Hi,

The version of busybox is the same.  I've just temporarily done a 
bitbake -c menuconfig to change one of the options, recompiled using the 
custom config that's generated, and now I want to force its inclusion 
into core-image-minimal.

Thanks,

Brian

On 1/16/2013 6:13 AM, Autif Khan wrote:
> On Tue, Jan 15, 2013 at 6:57 PM, Brian Smucker <bds@bsmucker.eu.org> wrote:
>> Hi Rudolf,
>>
>>
>> On 1/15/2013 3:28 PM, Rudolf Streif wrote:
>>>
>>> Brian,
>>>
>>> What are you exactly referring to as "new version"? The package version
>>> that bitbake builds is defined by the recipe, through the version
>>> designation in the recipe's file name or through explicitly setting PV.
>>>
>>> I think what you are trying to do is to modify the busybox configuration
>>> and then recompile and package. Bitbake will not automatically recompile
>>> after menuconfig. Menuconfig does not invslidate the shared state cache. Try
>>> this:
>>>
>>> bitbake -c menuconfig busybox
>>> bitbake -c -f compile busybox
>>> bitbake busybox
>>>
>>>
>> So I have done the above.  That is not the question.  Busybox compiles fine
>> and the new unstripped busybox is in the
>> .../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/
> What is the new version of busybox?
>
> What is the full filename of the new recipe that you created to
> compile a new version of busybox? For example the old one is
> busybox_1.20.2.bb (in meta/recipes-core/busybox)
>
> Also, can you please paste the .bb file in the email
>
>> My question is that after compiling busybox, I do
>>
>> bitbake -c cleansstate core-image-minimal
>> bitbake core-image-minimal
>>
>> expecting that the core image generated will contain the new busybox.  It
>> does not, it contains a busybox copy that was compiled days ago, not the
>> custom one I just compiled.
>>
>> Why is this?  How can I force the bitbake to include the newly-compiled
>> busybox into my minimal image?
>>
>>
>> Thanks,
>>
>> Brian
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

Re: Busybox still old version: Still looking for a clear understanding of an old mystery.

[Autif Khan]

On Wed, Jan 16, 2013 at 10:23 AM, Brian Smucker <bds@bsmucker.eu.org> wrote:
> Hi,
>
> The version of busybox is the same.  I've just temporarily done a bitbake -c
> menuconfig to change one of the options, recompiled using the custom config
> that's generated, and now I want to force its inclusion into
> core-image-minimal.

I see. I think that is a bit unorthodox. (Mostly because I have never
tried it. Is it even supposed to work like you describe? I suppose
not. But that aside ...)

If I were doing this, I would create a busybox bbappend in my meta
layer and override the danny stock do_prepare_config() (in
meta/recipes-core/busybox/busybox.inc)

 96 do_prepare_config () {
 97         sed -e 's#@DATADIR@#${datadir}#g' \
 98                 < ${WORKDIR}/defconfig > ${S}/.config
 99         sed -i -e '/CONFIG_STATIC/d' .config
100         echo "# CONFIG_STATIC is not set" >> .config
101         for i in 'CROSS' 'DISTRO FEATURES'; do echo "### $i"; done >> \
102                 ${S}/.config
103         sed -i -e '${configmangle}' ${S}/.config
104         if test ${DO_IPv4} -eq 0 && test ${DO_IPv6} -eq 0; then
105           # disable networking applets
106           mv ${S}/.config ${S}/.config.oe-tmp
107           awk 'BEGIN{net=0}
108           /^# Networking Utilities/{net=1}
109           /^#$/{if(net){net=net+1}}
110           {if(net==2&&$0 !~ /^#/&&$1){print("# "$1" is not
set")}else{print}}' \
111                   ${S}/.config.oe-tmp > ${S}/.config
112         fi
113 }

> Thanks,
>
> Brian
>
>
> On 1/16/2013 6:13 AM, Autif Khan wrote:
>>
>> On Tue, Jan 15, 2013 at 6:57 PM, Brian Smucker <bds@bsmucker.eu.org>
>> wrote:
>>>
>>> Hi Rudolf,
>>>
>>>
>>> On 1/15/2013 3:28 PM, Rudolf Streif wrote:
>>>>
>>>>
>>>> Brian,
>>>>
>>>> What are you exactly referring to as "new version"? The package version
>>>> that bitbake builds is defined by the recipe, through the version
>>>> designation in the recipe's file name or through explicitly setting PV.
>>>>
>>>> I think what you are trying to do is to modify the busybox configuration
>>>> and then recompile and package. Bitbake will not automatically recompile
>>>> after menuconfig. Menuconfig does not invslidate the shared state cache.
>>>> Try
>>>> this:
>>>>
>>>> bitbake -c menuconfig busybox
>>>> bitbake -c -f compile busybox
>>>> bitbake busybox
>>>>
>>>>
>>> So I have done the above.  That is not the question.  Busybox compiles
>>> fine
>>> and the new unstripped busybox is in the
>>>
>>> .../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/
>>
>> What is the new version of busybox?
>>
>> What is the full filename of the new recipe that you created to
>> compile a new version of busybox? For example the old one is
>> busybox_1.20.2.bb (in meta/recipes-core/busybox)
>>
>> Also, can you please paste the .bb file in the email
>>
>>> My question is that after compiling busybox, I do
>>>
>>> bitbake -c cleansstate core-image-minimal
>>> bitbake core-image-minimal
>>>
>>> expecting that the core image generated will contain the new busybox.  It
>>> does not, it contains a busybox copy that was compiled days ago, not the
>>> custom one I just compiled.
>>>
>>> Why is this?  How can I force the bitbake to include the newly-compiled
>>> busybox into my minimal image?
>>>
>>>
>>> Thanks,
>>>
>>> Brian
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>
>

How to force newly-compiled busybox into core-image-minimal (restating an earlier post)

[Brian Smucker]

Hello all,

I'm not sure if my prior question was unclear or if the question was 
something nobody knows the answer to.

I think there's probably a simple answer, but maybe not.

So the background is this: A poky/danny setup where I have 
previously-compiled core-image-minimal.

I force busybox to be recompiled: bitbake -c -f compile busybox
I clean core-image-minimal: bitbake -c -f cleansstate core-image-minimal
I rebuild the core image: bitbake  core-image-minimal

Result:  The busybox that is included in the core-image rootfs is a 
busybox that was compiled earlier.  It has an earlier timestamp.

Question:  How do I force the newly-compiled busybox to be included in 
the core-image rootfs, so that the rootfs generation process does not 
retrieve some stale version of busybox from a cache somewhere? (Without 
deleting the tmp directory. I know that works.)

There's got to be a simple answer.

Thanks,

Brian

ps.  This is merely an interim way to test a particular permutation of 
the busybox config. I know how to make a recipe using bbappend and a new 
defconfig for busybox.  But I want to do a series of quick-and-dirty 
tests with various busybox config options.

Re: How to force newly-compiled busybox into core-image-minimal (restating an earlier post)

[Gary Thomas]

On 2013-01-16 12:02, Brian Smucker wrote:
> Hello all,
>
> I'm not sure if my prior question was unclear or if the question was something nobody knows the answer to.
>
> I think there's probably a simple answer, but maybe not.
>
> So the background is this: A poky/danny setup where I have previously-compiled core-image-minimal.
>
> I force busybox to be recompiled: bitbake -c -f compile busybox
> I clean core-image-minimal: bitbake -c -f cleansstate core-image-minimal
> I rebuild the core image: bitbake  core-image-minimal
>
> Result:  The busybox that is included in the core-image rootfs is a busybox that was compiled earlier.  It has an earlier timestamp.
>
> Question:  How do I force the newly-compiled busybox to be included in the core-image rootfs, so that the rootfs generation process does not retrieve some stale version of busybox
> from a cache somewhere? (Without deleting the tmp directory. I know that works.)
>
> There's got to be a simple answer.
>
> Thanks,
>
> Brian
>
> ps.  This is merely an interim way to test a particular permutation of the busybox config. I know how to make a recipe using bbappend and a new defconfig for busybox.  But I want
> to do a series of quick-and-dirty tests with various busybox config options.

The problem is that your rebuild of busybox only ran the compile step,
not any of the install or packaging steps.

Thankfully there is a new bitbake option which makes this much easier.
See if this does what you want:
   % bitbake busybox -C compile
   % bitbake core-image-minimal

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

Re: How to force newly-compiled busybox into core-image-minimal (restating an earlier post)

[Brian Smucker]

Gary,

Thank you.  It seems the bitbake -C option was indeed what I wanted.
And researching it helped fill in some of the gaps in my understanding.

Thanks,

Brian



On 1/16/2013 11:09 AM, Gary Thomas wrote:
> On 2013-01-16 12:02, Brian Smucker wrote:
>> Hello all,
>>
>> I'm not sure if my prior question was unclear or if the question was 
>> something nobody knows the answer to.
>>
>> I think there's probably a simple answer, but maybe not.
>>
>> So the background is this: A poky/danny setup where I have 
>> previously-compiled core-image-minimal.
>>
>> I force busybox to be recompiled: bitbake -c -f compile busybox
>> I clean core-image-minimal: bitbake -c -f cleansstate core-image-minimal
>> I rebuild the core image: bitbake  core-image-minimal
>>
>> Result:  The busybox that is included in the core-image rootfs is a 
>> busybox that was compiled earlier.  It has an earlier timestamp.
>>
>> Question:  How do I force the newly-compiled busybox to be included 
>> in the core-image rootfs, so that the rootfs generation process does 
>> not retrieve some stale version of busybox
>> from a cache somewhere? (Without deleting the tmp directory. I know 
>> that works.)
>>
>> There's got to be a simple answer.
>>
>> Thanks,
>>
>> Brian
>>
>> ps.  This is merely an interim way to test a particular permutation 
>> of the busybox config. I know how to make a recipe using bbappend and 
>> a new defconfig for busybox.  But I want
>> to do a series of quick-and-dirty tests with various busybox config 
>> options.
>
> The problem is that your rebuild of busybox only ran the compile step,
> not any of the install or packaging steps.
>
> Thankfully there is a new bitbake option which makes this much easier.
> See if this does what you want:
>   % bitbake busybox -C compile
>   % bitbake core-image-minimal
>

Re: Busybox still old version: Still looking for a clear understanding of an old mystery.

[Paul Eggleton]

On Tuesday 15 January 2013 15:28:25 Rudolf Streif wrote:
> What are you exactly referring to as "new version"? The package version
> that bitbake builds is defined by the recipe, through the version
> designation in the recipe's file name or through explicitly setting PV.
> 
> I think what you are trying to do is to modify the busybox configuration
> and then recompile and package. Bitbake will not automatically recompile
> after menuconfig. Menuconfig does not invslidate the shared state cache.

I think it possibly should though, since it does for the kernel.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre