Re: [PATCH 4/5] libc-headers: set TC default to 3.14

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 14-04-01 10:50 AM, Martin Jansa wrote:
> On Tue, Apr 01, 2014 at 08:54:42AM -0400, Bruce Ashfield wrote:
>> On 14-04-01 02:42 AM, Khem Raj wrote:
>>>
>>> On Mar 31, 2014, at 12:50 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
>>>
>>>>> i dont believe you tested all layer combinations
>>>>
>>>> I've tested everything I can, as has the autobuilder. I can't offer
>>>> any more than this.
>>>>
>>>>>>
>>>>>>
>>>>>>> at this point. 3.10 being LTS
>>>>>>> I would assume its a better option to keep at 3.10
>>>>>>
>>>>>>
>>>>>> I disagree, this is consistent with other releases and the documented
>>>>>> plan of action. I'd rather not have a massive version jump in the fall.
>>>>>
>>>>> its probably not a bad option to stick to LTS version for kernel headers
>>>>> after all
>>>>
>>>> Again, I disagree.
>>>>
>>>> We can maybe keep the 3.10 recipe around,
>>>
>>> Thats ugly too. We decided to stick to one version of headers last time.
>>>
>>>> but the default should
>>>> be 3.14, we need a matched kernel and libc-headers to get the best integration
>>>> and leveraging of the latest features.
>>>>
>>>> If we pull the headers, pull the kernel.
>>>
>>> this all is understood, however we have to get better with timings especially
>>> changing something like kernel headers whose impact is far reaching then
>>>    just updating kernel proper.
>>
>> We do the best we can and I can only play the timing that is dealt
>> by the upstream projects ... but we all know that!
>>
>> We arranged for as much soak testing and building as we could behind
>> the scenes.
>>
>> That being said, we are going to introduce the versioned kernel and
>> libc-headers recipes in the -rc1 timeframe next time around and we
>> captured that intention on the kernel planning wiki for 1.7 .. so that
>> should help in the next cycle.
>
> This failure also seems new:
>
> |
> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/lttng-modules/2.3.3-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:344:24:
> error: 'struct bio' has no member named 'bi_sector'
> |    tp_assign(sector, bio->bi_sector)

For qemuarm. Hmm. I did build lttng modules for it here, as I presume
the autobuilder did as well.

But I'll launch another build to see what happens here.

Bruce

> |                         ^
>