autobuilder failure http://autobuilder.pokylinux.org:8010/builders/nightly-x86/builds/433

autobuilder failure http://autobuilder.pokylinux.org:8010/builders/nightly-x86/builds/433

[Lu, Lianhao]

Hi Saul,

I think I might have some clues why the python-nativesdk failed at http://autobuilder.pokylinux.org:8010/builders/nightly-x86/builds/433. It's due to the commit http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stage/master_under_test&id=a1f1cc4c27b5091870b1dbd9ede7c24c38d765dd. 

I guess the above commit which changed eglibc-nativesdk to version 2.15 has some conflict to the sstate-cache the autobuilder used, which might contains content from old eglibc-nativesdk 2.13.

-Lianhao

Re: autobuilder failure http://autobuilder.pokylinux.org:8010/builders/nightly-x86/builds/433

[Saul Wold]

On 04/10/2012 08:16 AM, Lu, Lianhao wrote:
> Hi Saul,
>
> I think I might have some clues why the python-nativesdk failed at http://autobuilder.pokylinux.org:8010/builders/nightly-x86/builds/433. It's due to the commit http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stage/master_under_test&id=a1f1cc4c27b5091870b1dbd9ede7c24c38d765dd.
>
> I guess the above commit which changed eglibc-nativesdk to version 2.15 has some conflict to the sstate-cache the autobuilder used, which might contains content from old eglibc-nativesdk 2.13.
>
Yes, that would do it, I will hit the sstate reset button and do a build 
that should clear this, but will cause problems for most people, I 
wonder if we need a PR bump in eglibc also?

Sau!


> -Lianhao

Re: autobuilder failure http://autobuilder.pokylinux.org:8010/builders/nightly-x86/builds/433

[Lu, Lianhao]

Saul Wold wrote on 2012-04-11:
> On 04/10/2012 08:16 AM, Lu, Lianhao wrote:
>> Hi Saul,
>> 
>> I think I might have some clues why the python-nativesdk failed at http://autobuilder.pokylinux.org:8010/builders/nightly-x86/builds/433.
> It's due to the commit
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stage/ma
> ster_under_test&id=a1f1cc4c27b5091870b1dbd9ede7c24c38d 765dd.
>> 
>> I guess the above commit which changed eglibc-nativesdk to version 2.15
>> has some conflict to the sstate-cache the autobuilder used, which might
>> contains content from old eglibc-nativesdk 2.13.
>> 
> Yes, that would do it, I will hit the sstate reset button and do a build
> that should clear this, but will cause problems for most people, I
> wonder if we need a PR bump in eglibc also?
> 

I think theoretically the PV change from 2.13 to 2.15 has the same effect of PR bump. I guess maybe some -nativesdk packages(other than eglibc-nativesdk) which was built upon eglibc-nativesdk 2.13 didn't get rebuilt somehow and went from sstate-cache directly into sysroot. 

Since I can't reproduce this compile failure on my local build, do we have the failure environment on autobuilder which I can log on and check?

Best Regards,
Lianhao

Re: autobuilder failure http://autobuilder.pokylinux.org:8010/builders/nightly-x86/builds/433

[McClintock Matthew-B29882]

On Tue, Apr 10, 2012 at 8:40 PM, Lu, Lianhao <lianhao.lu@intel.com> wrote:
> Saul Wold wrote on 2012-04-11:
>> On 04/10/2012 08:16 AM, Lu, Lianhao wrote:
>>> Hi Saul,
>>>
>>> I think I might have some clues why the python-nativesdk failed at http://autobuilder.pokylinux.org:8010/builders/nightly-x86/builds/433.
>> It's due to the commit
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stage/ma
>> ster_under_test&id=a1f1cc4c27b5091870b1dbd9ede7c24c38d 765dd.
>>>
>>> I guess the above commit which changed eglibc-nativesdk to version 2.15
>>> has some conflict to the sstate-cache the autobuilder used, which might
>>> contains content from old eglibc-nativesdk 2.13.
>>>
>> Yes, that would do it, I will hit the sstate reset button and do a build
>> that should clear this, but will cause problems for most people, I
>> wonder if we need a PR bump in eglibc also?
>>
>
> I think theoretically the PV change from 2.13 to 2.15 has the same effect of PR bump. I guess maybe some -nativesdk packages(other than eglibc-nativesdk) which was built upon eglibc-nativesdk 2.13 didn't get rebuilt somehow and went from sstate-cache directly into sysroot.
>
> Since I can't reproduce this compile failure on my local build, do we have the failure environment on autobuilder which I can log on and check?

Should the new OEBasicHash force a rebuild of those packages though?

-M