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 <[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...
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
------------
Tom also has the fix for bio*:
commit b465c0cb32696eed3ecc42fe4b5b478e4ba07914
Author: Tom Zanussi <[email protected]>
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 <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
----------
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
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
