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

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

On 14-04-01 10:54 AM, Richard Purdie wrote:
> On Tue, 2014-04-01 at 10:52 -0400, Bruce Ashfield wrote:
>> 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.
>
> I can confirm we didn't see that on the autobuilder...

I was checking my core-image-kernel-dev builds for qemuarm, and managed
to confuse myself momentarily (when I didn't see a build trigger), and
then remembered.

------------

commit 7a974407379b43e40664cad4696b427ee8c18df0
Author: Tom Zanussi <tom.zanussi@intel.com>
Date:   Thu Mar 6 22:26:19 2014 -0600

     lttng-modules: Exclude arm

     lttng-modules and gcc-4.8 don't mix, according to the lttng ML
     'current_thread_info() not respecting program order with gcc 4.8.x',
     so remove it from arm builds.

     (From OE-Core rev: ccf687de7b856dbe6f347956743f07ff05c2533a)

     Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
     Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

------------

Tom also has the fix for bio*:

commit b465c0cb32696eed3ecc42fe4b5b478e4ba07914
Author: Tom Zanussi <tom.zanussi@intel.com>
Date:   Thu Mar 6 22:26:20 2014 -0600

     lttng-modules: Fix 3.14 bio tracepoints

     The mainline 3.14 commit 'block: Astract out bvec iterator' broke the
     lttng-modules tracepoints.  Fix them here.

     (From OE-Core rev: c11b29ff4f24af0445c3c6a694b8dc2037dcd7e4)

     Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
     Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

----------

So this one is expected, and avoided .. but of course if you build it
directly it will break.

If there's a fix that anyone knows of for ARM, I'm available to test
it here.

Summary: not introduced by the uprev directly, and it was known before
hand .. my foggy memory just managed to forget it..

Cheers,

Bruce

>
> Cheers,
>
> Richard
>