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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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...

Cheers,

Richard