New fetch error

New fetch error

[Gary Thomas]

While testing the recent sstate changes (commit 4cd40dbaa8aef7b6b9ff9ce892a576b802f4b1ec),
I ran across this error:

NOTE: package linux-am-2.6.32-r0: task do_fetch: Started
NOTE: fetch http://www.mlbassoc.com/repos/public/linux-am-2.6.32.tar.bz2
ERROR: Task failed: Unknown fetch Error: local variable 'md5data' referenced before assignment
NOTE: package linux-am-2.6.32-r0: task do_fetch: Failed
ERROR: Task 5 (/work/local/poky-amltd/meta-amltd/packages/linux/linux-am_2.6.32.bb, do_fetch) failed with 256
ERROR: '/work/local/poky-amltd/meta-amltd/packages/linux/linux-am_2.6.32.bb' failed

This is for a local kernel which previously built (today,
using the same Poky tree).  The problem occurred after I
ran 'bitbake virtual/kernel -c cleanall'

Any ideas what caused this error?

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

Re: New fetch error

[Richard Purdie]

On Tue, 2010-12-21 at 07:58 -0700, Gary Thomas wrote:
> While testing the recent sstate changes (commit 4cd40dbaa8aef7b6b9ff9ce892a576b802f4b1ec),
> I ran across this error:
> 
> NOTE: package linux-am-2.6.32-r0: task do_fetch: Started
> NOTE: fetch http://www.mlbassoc.com/repos/public/linux-am-2.6.32.tar.bz2
> ERROR: Task failed: Unknown fetch Error: local variable 'md5data' referenced before assignment
> NOTE: package linux-am-2.6.32-r0: task do_fetch: Failed
> ERROR: Task 5 (/work/local/poky-amltd/meta-amltd/packages/linux/linux-am_2.6.32.bb, do_fetch) failed with 256
> ERROR: '/work/local/poky-amltd/meta-amltd/packages/linux/linux-am_2.6.32.bb' failed
> 
> This is for a local kernel which previously built (today,
> using the same Poky tree).  The problem occurred after I
> ran 'bitbake virtual/kernel -c cleanall'
> 
> Any ideas what caused this error?

My fault, I've pushed a fix, sorry about that.

Cheers,

Richard

Re: New fetch error

[Gary Thomas]

On 12/21/2010 08:16 AM, Richard Purdie wrote:
> On Tue, 2010-12-21 at 07:58 -0700, Gary Thomas wrote:
>> While testing the recent sstate changes (commit 4cd40dbaa8aef7b6b9ff9ce892a576b802f4b1ec),
>> I ran across this error:
>>
>> NOTE: package linux-am-2.6.32-r0: task do_fetch: Started
>> NOTE: fetch http://www.mlbassoc.com/repos/public/linux-am-2.6.32.tar.bz2
>> ERROR: Task failed: Unknown fetch Error: local variable 'md5data' referenced before assignment
>> NOTE: package linux-am-2.6.32-r0: task do_fetch: Failed
>> ERROR: Task 5 (/work/local/poky-amltd/meta-amltd/packages/linux/linux-am_2.6.32.bb, do_fetch) failed with 256
>> ERROR: '/work/local/poky-amltd/meta-amltd/packages/linux/linux-am_2.6.32.bb' failed
>>
>> This is for a local kernel which previously built (today,
>> using the same Poky tree).  The problem occurred after I
>> ran 'bitbake virtual/kernel -c cleanall'
>>
>> Any ideas what caused this error?
>
> My fault, I've pushed a fix, sorry about that.

Yes, this is fixed, thanks.

Query: is 'cleanall' expected to also remove files from $DL_DIR?
It does so, but produces no notes about it (it's pretty verbose
about all the other files it deletes)

If this is the case, could there be a 'cleansstate' or some
such?  All I really wanted to do was force a complete rebuild
of a package, ignoring the local sstate files.  'cleanall'
gave me more than I bargained for.

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

Re: New fetch error

[Richard Purdie]

On Tue, 2010-12-21 at 08:29 -0700, Gary Thomas wrote:
> Query: is 'cleanall' expected to also remove files from $DL_DIR?
> It does so, but produces no notes about it (it's pretty verbose
> about all the other files it deletes)
> 
> If this is the case, could there be a 'cleansstate' or some
> such?  All I really wanted to do was force a complete rebuild
> of a package, ignoring the local sstate files.  'cleanall'
> gave me more than I bargained for.

Which is one of the reasons I never really wanted to add more "clean"
options. Everyone has some different expectation about what a given
'clean' should actually remove and its not possible to satisfy
everyone :/. I don't really want to end up with twenty different cleans.

Ultimately, I think -c clean should plant something in the system that
has it ignore any sstate packages *anywhere* (including remote) and
rebuild that package.

'cleanall' then makes sense as it is and nothing else should be needed.

So the above is the big hint as to the patch I'd like to see :)

Cheers,

Richard