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 > >>> <[email protected]> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
