testing 2010-12-10 (wiki, results, bluez-libs)

testing 2010-12-10 (wiki, results, bluez-libs)

[Frans Meulenbroeks]

Dear all,

I just wanted to update the testing table with my entries and I
noticed two (possibly related) things.
- no other entries for 2010-12-10 are there yet (and it is already wednesday)
- when I tried to save my data the wiki gave me an error (which is
reported in a separate mail, but which might be the cause that no
other entries are there).

So here my results:
neek: fails in udev:
nslu2le, nslu2be, calamari, mpc8313e, sheevaplug: build.

Remark:
The last three still give me this error:

ERROR: Multiple .bb files are due to be built which each provide
bluez-libs (/home/hudson/jobs/OE_test/workspace/openembedded/recipes/bluez/bluez4_4.42.bb
/home/hudson/jobs/OE_test/workspace/openembedded/recipes/bluez/bluez-libs_3.36.bb).
 This usually means one provides something the other doesn't and should.
NOTE: Preparing runqueue
ERROR: Multiple .bb files are due to be built which each provide
bluez-libs (/home/hudson/jobs/OE_test/workspace/openembedded/recipes/bluez/bluez4_4.42.bb
/home/hudson/jobs/OE_test/workspace/openembedded/recipes/bluez/bluez-libs_3.36.bb).
 This usually means one provides something the other doesn't and should.

First of all I get it twice (where once would suffice).
Secondly I'd like to get rid of this. I tried pinning in the past, but
that did not help.
Not sure if the 3.36 stuff is still used/useful. Or should we go (or
have gone) for bluez4-libs?
Or do we need a virtual/bluez-libs ?

Suggestions are appreciated.

Frans

Re: testing 2010-12-10 (wiki, results, bluez-libs)

[Tom Rini]

On 12/15/2010 12:51 AM, Frans Meulenbroeks wrote:
> Dear all,
>
> I just wanted to update the testing table with my entries and I
> noticed two (possibly related) things.
> - no other entries for 2010-12-10 are there yet (and it is already wednesday)

I haven't updated the stuff we're building since just about everything 
failed due to the gcc issue Khem fixed in 
2c8570552549da2e11428d08b2bc08849cac39b1.  This is why I sometimes 
wonder if it would be desirable to cherry-pick a few things in to the 
testing-next branch.

-- 
Tom Rini
Mentor Graphics Corporation

Re: testing 2010-12-10 (wiki, results, bluez-libs)

[Frans Meulenbroeks]

2010/12/15 Tom Rini <tom_rini@mentor.com>:
> On 12/15/2010 12:51 AM, Frans Meulenbroeks wrote:
>>
>> Dear all,
>>
>> I just wanted to update the testing table with my entries and I
>> noticed two (possibly related) things.
>> - no other entries for 2010-12-10 are there yet (and it is already
>> wednesday)
>
> I haven't updated the stuff we're building since just about everything
> failed due to the gcc issue Khem fixed in
> 2c8570552549da2e11428d08b2bc08849cac39b1.  This is why I sometimes wonder if
> it would be desirable to cherry-pick a few things in to the testing-next
> branch.

Hm. Yeah. I've re-checked and I am definitely building the
testing-next branch, not git head.
Then again I only build console-image and no high end images.
My james-image also had quite some issues (js, samba) which are now resolved.
Only issue left for now seems to be gettext/libtool related.

Frans

Re: testing 2010-12-10 (wiki, results, bluez-libs)

[Tom Rini]

On 12/15/2010 08:33 AM, Frans Meulenbroeks wrote:
> 2010/12/15 Tom Rini<tom_rini@mentor.com>:
>> On 12/15/2010 12:51 AM, Frans Meulenbroeks wrote:
>>>
>>> Dear all,
>>>
>>> I just wanted to update the testing table with my entries and I
>>> noticed two (possibly related) things.
>>> - no other entries for 2010-12-10 are there yet (and it is already
>>> wednesday)
>>
>> I haven't updated the stuff we're building since just about everything
>> failed due to the gcc issue Khem fixed in
>> 2c8570552549da2e11428d08b2bc08849cac39b1.  This is why I sometimes wonder if
>> it would be desirable to cherry-pick a few things in to the testing-next
>> branch.
>
> Hm. Yeah. I've re-checked and I am definitely building the
> testing-next branch, not git head.
> Then again I only build console-image and no high end images.
> My james-image also had quite some issues (js, samba) which are now resolved.
> Only issue left for now seems to be gettext/libtool related.

What distro?  Almost _everything_ was broken for me since it was 
micro/minimal (including console-image).

-- 
Tom Rini
Mentor Graphics Corporation

Re: testing 2010-12-10 (wiki, results, bluez-libs)

[Frans Meulenbroeks]

2010/12/15 Tom Rini <tom_rini@mentor.com>:
> On 12/15/2010 08:33 AM, Frans Meulenbroeks wrote:
>>
>> 2010/12/15 Tom Rini<tom_rini@mentor.com>:
>>>
>>> On 12/15/2010 12:51 AM, Frans Meulenbroeks wrote:
>>>>
>>>> Dear all,
>>>>
>>>> I just wanted to update the testing table with my entries and I
>>>> noticed two (possibly related) things.
>>>> - no other entries for 2010-12-10 are there yet (and it is already
>>>> wednesday)
>>>
>>> I haven't updated the stuff we're building since just about everything
>>> failed due to the gcc issue Khem fixed in
>>> 2c8570552549da2e11428d08b2bc08849cac39b1.  This is why I sometimes wonder
>>> if
>>> it would be desirable to cherry-pick a few things in to the testing-next
>>> branch.
>>
>> Hm. Yeah. I've re-checked and I am definitely building the
>> testing-next branch, not git head.
>> Then again I only build console-image and no high end images.
>> My james-image also had quite some issues (js, samba) which are now
>> resolved.
>> Only issue left for now seems to be gettext/libtool related.
>
> What distro?  Almost _everything_ was broken for me since it was
> micro/minimal (including console-image).

Distro minimal, targets mpc8313e-rds, sheevaplug, calamari, neek
(latter does not build) recipe console-image
distro slugos, targets nlsu2le nslu2be, target slugos-image.

Frans

Re: testing 2010-12-10 (wiki, results, bluez-libs)

[Cliff Brake]

On Wed, Dec 15, 2010 at 9:43 AM, Tom Rini <tom_rini@mentor.com> wrote:
> On 12/15/2010 12:51 AM, Frans Meulenbroeks wrote:
>>
>> Dear all,
>>
>> I just wanted to update the testing table with my entries and I
>> noticed two (possibly related) things.
>> - no other entries for 2010-12-10 are there yet (and it is already
>> wednesday)
>
> I haven't updated the stuff we're building since just about everything
> failed due to the gcc issue Khem fixed in
> 2c8570552549da2e11428d08b2bc08849cac39b1.  This is why I sometimes wonder if
> it would be desirable to cherry-pick a few things in to the testing-next
> branch.

One of my concerns is coordinating with all the people doing testing
if we start committing to the testing-next branch.  How do we know who
restarted builds, etc.  I guess we could assume the cherry-picked
changes would be minor enough that people who have already finished
builds would not need to re-build.

At this point I'm just more inclined if the weekly testing branch
crashes and burns horribly to just throw away that week, and focus on
getting things fixed in the master for next week.  Its not perfect,
but with so many people participating, it seems like we need to keep
it as simple as possible.  But, keep the ideas flowing, and perhaps
something better will emerge.

Thanks,
Cliff

-- 
=================
http://bec-systems.com

Re: testing 2010-12-10 (wiki, results, bluez-libs)

[Khem Raj]

On (16/12/10 08:33), Cliff Brake wrote:
> On Wed, Dec 15, 2010 at 9:43 AM, Tom Rini <tom_rini@mentor.com> wrote:
> > On 12/15/2010 12:51 AM, Frans Meulenbroeks wrote:
> >>
> >> Dear all,
> >>
> >> I just wanted to update the testing table with my entries and I
> >> noticed two (possibly related) things.
> >> - no other entries for 2010-12-10 are there yet (and it is already
> >> wednesday)
> >
> > I haven't updated the stuff we're building since just about everything
> > failed due to the gcc issue Khem fixed in
> > 2c8570552549da2e11428d08b2bc08849cac39b1.  This is why I sometimes wonder if
> > it would be desirable to cherry-pick a few things in to the testing-next
> > branch.
> 
> One of my concerns is coordinating with all the people doing testing
> if we start committing to the testing-next branch.  How do we know who
> restarted builds, etc.  I guess we could assume the cherry-picked
> changes would be minor enough that people who have already finished
> builds would not need to re-build.

yeah without autobuilder which triggers a build on everycommit 
its hard

> 
> At this point I'm just more inclined if the weekly testing branch
> crashes and burns horribly to just throw away that week, and focus on
> getting things fixed in the master for next week.  Its not perfect,
> but with so many people participating, it seems like we need to keep
> it as simple as possible.  But, keep the ideas flowing, and perhaps
> something better will emerge.

I think the current method is good. What I do is if I see a problem
in the testing then I fix it there locally and keep going with build to
find more and apply the patch to master
for next cycle so far it has worked well.

> 
> Thanks,
> Cliff
> 
> -- 
> =================
> http://bec-systems.com
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel