lnux-yocto: 3.14 updates
cover lnux-yocto: 3.14 updates
Richard/Saul,
Here are the remaining changes from my previous pull request for linux-yocto updates.
Now that 3.14 has been released, we have the full 3.14 kernel and associated libc-headers .. with no PV games.
There is one new change in the libc-headers series, to adapt to the xz compression of new headers, but otherwise, it is the same as before.
[
Subject: [PATCH 2/5] linux-libc-headers: make compression format configurable
As of the 3.13 kernel bz2 compressed tarballs are not available. To support older header tarballs, and newer ones that require the 'xz' compressed bundles, we can break out a variable that allows versioned libc headers to select the archive format that works.
]
I've built and booted qemu* for this, so everything appears to be sane.
Cheers,
Bruce
The following changes since commit 4f80de9a568bcf0280c7e8b8f89ee6c2adfa477d:
linux-yocto/3.10: fix qemuarm build failure (2014-03-30 23:53:00 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib zedd/kernel
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel
Bruce Ashfield (5):
linux-yocto/3.14: introduce versioned recipes
linux-libc-headers: make compression format configurable
linux-libc-headers: add 3.14 libc headers
libc-headers: set TC default to 3.14
linux-libc-headers: remove 3.10 recipe
meta/conf/distro/include/tcmode-default.inc | 2 +- .../linux-libc-headers/linux-libc-headers.inc | 4 +- ...1-ptrace.h-remove-ptrace_peeksiginfo_args.patch | 50 ------------------ ...lude-asm-byteorder.h-in-linux-raid-md_p.h.patch | 34 ------------- ...efile.headersinst-install-headers-from-sc.patch | 59 ---------------------- .../linux-libc-headers/linux-libc-headers_3.10.bb | 11 ---- .../linux-libc-headers/linux-libc-headers_3.14.bb | 7 +++ meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21 ++++++++ meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37 ++++++++++++++ 9 files changed, 69 insertions(+), 156 deletions(-) delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb
Signature · 1 line
1.8.1.2
PATCH 1/5 linux-yocto/3.14: introduce versioned recipes
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce the versioned recipes here.
--- meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21 ++++++++++++ meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37 ++++++++++++++++++++++ 2 files changed, 58 insertions(+) create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb new file +21 -0
@@ -0,0 +1,21 @@ +require recipes-kernel/linux/linux-yocto.inc + +KBRANCH = "standard/tiny/base" +LINUX_KERNEL_TYPE = "tiny" +KCONFIG_MODE = "--allnoconfig" + +LINUX_VERSION ?= "3.14" + +KMETA = "meta" + +SRCREV_machine ?= "0143c6ebb4a2d63b241df5f608b19f483f7eb9e0" +SRCREV_meta ?= "fc8c30398dbc3cdea787a1042242d4aab689d0ae" + +PV = "${LINUX_VERSION}+git${SRCPV}" + +SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta" + +COMPATIBLE_MACHINE = "(qemux86)" + +# Functionality flags +KERNEL_FEATURES = ""
meta/recipes-kernel/linux/linux-yocto_3.14.bb new file +37 -0
@@ -0,0 +1,37 @@ +require recipes-kernel/linux/linux-yocto.inc + +KBRANCH = "standard/base" + +# board specific branches +KBRANCH_qemuarm = "standard/arm-versatile-926ejs" +KBRANCH_qemumips = "standard/mti-malta32" +KBRANCH_qemuppc = "standard/qemuppc" +KBRANCH_qemux86 = "standard/common-pc/base" +KBRANCH_qemux86-64 = "standard/common-pc-64/base" +KBRANCH_qemumips64 = "standard/mti-malta64" + +SRCREV_machine_qemuarm ?= "c966987f88a0ee5753c3dee87e7a962d0cad5376" +SRCREV_machine_qemumips ?= "61811c215c601ee96ccbf79333bbc73482b0f017" +SRCREV_machine_qemuppc ?= "0d5cf5e938f4e6d3c6a398e98c8ece3ce05539f7" +SRCREV_machine_qemux86 ?= "0143c6ebb4a2d63b241df5f608b19f483f7eb9e0" +SRCREV_machine_qemux86-64 ?= "0143c6ebb4a2d63b241df5f608b19f483f7eb9e0" +SRCREV_machine_qemumips64 ?= "ccb2a788551a7951563ac44a27175c6f28501008" +SRCREV_machine ?= "0143c6ebb4a2d63b241df5f608b19f483f7eb9e0" +SRCREV_meta ?= "fc8c30398dbc3cdea787a1042242d4aab689d0ae" + +SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta" + +LINUX_VERSION ?= "3.14" + +PV = "${LINUX_VERSION}+git${SRCPV}" + +KMETA = "meta" + +COMPATIBLE_MACHINE = "qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64" + +# Functionality flags +KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc" +KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" +KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" +KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc" +KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " cfg/x32.scc", "" ,d)}"
Signature · 1 line
1.8.1.2
Re: [PATCH 1/5] linux-yocto/3.14: introduce versioned recipes
Quoted 3 lines · Bruce Ashfield
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce the versioned recipes here.
Should this say Yocto 1.6?
Signature · 4 lines
Paul Barker Email: [email protected] http://www.paulbarker.me.uk
Re: [PATCH 1/5] linux-yocto/3.14: introduce versioned recipes
Quoted 6 lines · Paul Barker
Quoted 3 lines · Bruce Ashfield
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce the versioned recipes here.
Should this say Yocto 1.6?
Ha. Yes it should!
Bruce
Quoted 1 line
PATCH 2/5 linux-libc-headers: make compression format configurable
In reply to Bruce AshfieldAs of the 3.13 kernel bz2 compressed tarballs are not available. To support older header tarballs, and newer ones that require the 'xz' compressed bundles, we can break out a variable that allows versioned libc headers to select the archive format that works.
--- meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +3 -1
@@ -41,7 +41,9 @@ python __anonymous () { inherit kernel-arch -SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.bz2" +KORG_ARCHIVE_COMPRESSION ?= "bz2" + +SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION}" S = "${WORKDIR}/linux-${PV}"
Signature · 1 line
1.8.1.2
PATCH 3/5 linux-libc-headers: add 3.14 libc headers
In reply to Bruce AshfieldIntroduce the 3.14 linux-libc-headers recipe, now that the 3.14 kernel is available, and the default for the qemu reference BSPs.
The three patches which were required for the previous 3.10 libc-headers are not required for 3.14 and can be ignored.
--- meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb new file +7 -0
@@ -0,0 +1,7 @@ +KORG_ARCHIVE_COMPRESSION = "xz" + +require linux-libc-headers.inc + +SRC_URI[md5sum] = "b621207b3f6ecbb67db18b13258f8ea8" +SRC_URI[sha256sum] = "61558aa490855f42b6340d1a1596be47454909629327c49a5e4e10268065dffa" +
Signature · 1 line
1.8.1.2
PATCH 4/5 libc-headers: set TC default to 3.14
In reply to Bruce Ashfield--- meta/conf/distro/include/tcmode-default.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/conf/distro/include/tcmode-default.inc +1 -1
@@ -22,7 +22,7 @@ SDKGCCVERSION ?= "${GCCVERSION}" BINUVERSION ?= "2.24" EGLIBCVERSION ?= "2.19" UCLIBCVERSION ?= "0.9.33+git%" -LINUXLIBCVERSION ?= "3.10" +LINUXLIBCVERSION ?= "3.14" PREFERRED_VERSION_gcc ?= "${GCCVERSION}" PREFERRED_VERSION_gcc-cross ?= "${GCCVERSION}"
Signature · 1 line
1.8.1.2
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
meta/conf/distro/include/tcmode-default.inc SDKGCCVERSION ?= "${GCCVERSION}" · line 25
Quoted 3 lines · Bruce Ashfield
meta/conf/distro/include/tcmode-default.inc +1
-1-LINUXLIBCVERSION ?= "3.10" +LINUXLIBCVERSION ?= "3.14"
Does this buy us much ? Infact its too late to change usespace APIs at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
Quoted 7 lines · Khem Raj
meta/conf/distro/include/tcmode-default.inc SDKGCCVERSION ?= "${GCCVERSION}" · line 25
Quoted 3 lines · Bruce Ashfield
meta/conf/distro/include/tcmode-default.inc +1
-1-LINUXLIBCVERSION ?= "3.10" +LINUXLIBCVERSION ?= "3.14"Does this buy us much ? Infact its too late to change usespace APIs
This was always the plan. I've been building with all the 3.14 -rc headers for ages .. and as we've talked about in the past, we always will update them to the newest kernel in any release.
They are compatible with 3.10, and I've tested the combinations of old kernels, new libc and new kernels with the new libc interfaces.
Quoted 2 lines
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.
Sure 3.14 slipping out by a few weeks upstream was a problem, but its not like we haven't been testing with it.
Bruce
Quoted 1 line
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
-Khem
Quoted 14 lines · Bruce Ashfield
Quoted 10 lines · Khem Raj
meta/conf/distro/include/tcmode-default.inc SDKGCCVERSION ?= "${GCCVERSION}" · line 25
Quoted 4 lines · Bruce Ashfield
meta/conf/distro/include/tcmode-default.inc +1
-1-LINUXLIBCVERSION ?= "3.10" +LINUXLIBCVERSION ?= "3.14"Does this buy us much ? Infact its too late to change usespace APIs
Quoted 3 lines
This was always the plan. I've been building with all the 3.14 -rc headers for ages .. and as we've talked about in the past, we always will update them to the newest kernel in any release.
well i think its good to update them however may be some components should be given enough soak time and kernel headers are one of such pieces since its effects are across layers and they will start testing them now.
Quoted 3 lines
They are compatible with 3.10, and I've tested the combinations of old kernels, new libc and new kernels with the new libc interfaces.
i dont believe you tested all layer combinations
Quoted 8 lines
Quoted 4 lines
at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10I 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
Quoted 8 lines
Sure 3.14 slipping out by a few weeks upstream was a problem, but its not like we haven't been testing with it.
Bruce
Quoted 1 line
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
Quoted 18 lines · Khem Raj
-Khem
Quoted 5 lines · On Mar 31, 2014 12:33 PM, "Bruce Ashfield" <[email protected]…
Quoted 3 lines · Khem Raj
On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield <[email protected] <mailto:[email protected]>>
Quoted 9 lines · wrote:
Quoted 7 lines
meta/conf/distro/include/tcmode-default.inc SDKGCCVERSION ?= "${GCCVERSION}" · line 25
Quoted 4 lines
meta/conf/distro/include/tcmode-default.inc +1
-1-LINUXLIBCVERSION ?= "3.10" +LINUXLIBCVERSION ?= "3.14"Does this buy us much ? Infact its too late to change usespace APIs
Quoted 8 lines
Quoted 3 lines
This was always the plan. I've been building with all the 3.14 -rc headers for ages .. and as we've talked about in the past, we always will update them to the newest kernel in any release.
well i think its good to update them however may be some components should be given enough soak time and kernel headers are one of such pieces since its effects are across layers and they will start testing them now.
To be fair, we've had the -dev kernel and headers available for over a month now.
This is also my second send of this series, so it isn't like this hasn't been available or broadcast.
People noticing it now, or being busy, isn't something I can directly control.
Quoted 5 lines
Quoted 3 lines
They are compatible with 3.10, and I've tested the combinations of old kernels, new libc and new kernels with the new libc interfaces.
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.
Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10I 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, 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.
Bruce
Quoted 9 lines
Quoted 8 lines
Sure 3.14 slipping out by a few weeks upstream was a problem, but its not like we haven't been testing with it.
Bruce
Quoted 1 line
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
Quoted 14 lines · Bruce Ashfield
Quoted 1 line
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.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10I 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
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.
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
Quoted 30 lines · Khem Raj
Quoted 14 lines · Bruce Ashfield
Quoted 1 line
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.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10I 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
Quoted 1 line
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.
Cheers,
Bruce
Quoted 1 line
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
Quoted 40 lines · Bruce Ashfield
Quoted 30 lines · Khem Raj
Quoted 14 lines · Bruce Ashfield
Quoted 1 line
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.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10I 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 4 lines
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.Quoted 5 lines
Quoted 1 line
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!
Quoted 7 lines
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)
| ^
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
Quoted 49 lines · Martin Jansa
Quoted 40 lines · Bruce Ashfield
Quoted 30 lines · Khem Raj
Quoted 14 lines · Bruce Ashfield
Quoted 1 line
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.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10I 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 4 lines
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.Quoted 5 lines
Quoted 1 line
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!
Quoted 7 lines
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.
Quoted 6 lines
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
Quoted 2 lines
| ^
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
Quoted 57 lines · Bruce Ashfield
Quoted 49 lines · Martin Jansa
Quoted 40 lines · Bruce Ashfield
Quoted 30 lines · Khem Raj
Quoted 14 lines · Bruce Ashfield
Quoted 1 line
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.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10I 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 4 lines
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.Quoted 5 lines
Quoted 1 line
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!
Quoted 7 lines
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.
Quoted 6 lines
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)
Quoted 4 lines
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
Re: [PATCH 4/5] libc-headers: set TC default to 3.14
Quoted 58 lines · Richard Purdie
Quoted 57 lines · Bruce Ashfield
Quoted 55 lines · Martin Jansa
Quoted 40 lines · Bruce Ashfield
Quoted 30 lines · Khem Raj
Quoted 14 lines · Bruce Ashfield
Quoted 1 line
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.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10I 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 4 lines
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.Quoted 5 lines
Quoted 1 line
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!
Quoted 7 lines
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)
Quoted 6 lines
Quoted 4 lines
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)
------------
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)
----------
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
Quoted 5 lines
Cheers,
Richard
PATCH 5/5 linux-libc-headers: remove 3.10 recipe
In reply to Bruce Ashfield3.14 is now the reference for libc-headers. After building and booting 3.x based BSPs against the 3.14 headers, we can safely remove the old version and patches that are now part of the mainline kernel.
--- ...1-ptrace.h-remove-ptrace_peeksiginfo_args.patch | 50 ------------------ ...lude-asm-byteorder.h-in-linux-raid-md_p.h.patch | 34 ------------- ...efile.headersinst-install-headers-from-sc.patch | 59 ---------------------- .../linux-libc-headers/linux-libc-headers_3.10.bb | 11 ---- 4 files changed, 154 deletions(-) delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch deleted +0 -50
@@ -1,50 +0,0 @@ -From 7dddfb8fec5317ea16154d30e8e18b6559979b60 Mon Sep 17 00:00:00 2001 -From: Bruce Ashfield <[email protected]> -Date: Sun, 25 Aug 2013 22:51:07 -0400 -Subject: [PATCH] ptrace.h: remove ptrace_peeksiginfo_args - -The addition of ptrace_peeksiginfo_args to the uapi in kernel commit -84c751bd [ptrace: add ability to retrieve signals without removing from a queue (v4)] -means that existing applications using glibc versions that define ptrace_peeksiginfo_args -in sys/ptrace.h will get duplicate structure definitions like: - - | In file included from /poky-master/build/tmp/work/i586-poky-linux/strace/4.8-r0/strace-4.8/process.c:66:0: - | /poky-master/build/tmp/sysroots/qemux86/usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct ptrace_peeksiginfo_args' - | struct ptrace_peeksiginfo_args { - | ^ - | In file included from /poky-master/build/tmp/work/i586-poky-linux/strace/4.8-r0/strace-4.8/defs.h:159:0, - | from /poky-master/build/tmp/work/i586-poky-linux/strace/4.8-r0/strace-4.8/process.c:37: - | /poky-master/build/tmp/sysroots/qemux86/usr/include/sys/ptrace.h:191:8: note: originally defined here - | struct ptrace_peeksiginfo_args - | ^ - | make[2]: *** [process.o] Error 1 - -Reverting to the previous status of not exporting this structure temporarily -fixes applications, until they can be adjusted to not mix sys/ptrace.h and -linux/ptrace.h includes. - -Signed-off-by: Bruce Ashfield <[email protected]> ---- - include/uapi/linux/ptrace.h | 6 ------ - 1 file changed, 6 deletions(-) - -diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h -index 52ebcc8..524599d 100644 ---- a/include/uapi/linux/ptrace.h -+++ b/include/uapi/linux/ptrace.h -@@ -55,12 +55,6 @@ - - #define PTRACE_PEEKSIGINFO 0x4209 - --struct ptrace_peeksiginfo_args { -- __u64 off; /* from which siginfo to start */ -- __u32 flags; -- __s32 nr; /* how may siginfos to take */ --}; -- - /* Read signals from a shared (process wide) queue */ - #define PTRACE_PEEKSIGINFO_SHARED (1 << 0) - --- -1.7.10.4 -
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch deleted +0 -34
@@ -1,34 +0,0 @@ -From c0f8bd146a8b3e630798561c605f5669823107af Mon Sep 17 00:00:00 2001 -From: Aurelien Jarno <[email protected]> -Date: Thu, 14 Nov 2013 15:16:19 +1100 -Subject: [PATCH] UAPI: include <asm/byteorder.h> in linux/raid/md_p.h - -linux/raid/md_p.h is using conditionals depending on endianess and fails -with an error if neither of __BIG_ENDIAN, __LITTLE_ENDIAN or -__BYTE_ORDER are defined, but it doesn't include any header which can -define these constants. This make this header unusable alone. - -This patch adds a #include <asm/byteorder.h> at the beginning of this -header to make it usable alone. This is needed to compile klibc on MIPS. - -Signed-off-by: Aurelien Jarno <[email protected]> -Signed-off-by: NeilBrown <[email protected]> ---- - include/uapi/linux/raid/md_p.h | 1 + - 1 file changed, 1 insertion(+) - -diff --git a/include/uapi/linux/raid/md_p.h b/include/uapi/linux/raid/md_p.h -index fe1a540..f7cf7f3 100644 ---- a/include/uapi/linux/raid/md_p.h -+++ b/include/uapi/linux/raid/md_p.h -@@ -16,6 +16,7 @@ - #define _MD_P_H - - #include <linux/types.h> -+#include <asm/byteorder.h> - - /* - * RAID superblock. --- -1.8.1.2 -
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch deleted +0 -59
59 lines not on this page · raw message
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb deleted +0 -11
@@ -1,11 +0,0 @@ -require linux-libc-headers.inc - -SRC_URI += "file://0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch" -SRC_URI += "file://scripts-Makefile.headersinst-install-headers-from-sc.patch" - -# fixes klibc build for MIPS, drop when libc-headers > 3.13 -SRC_URI += "file://UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch" - -SRC_URI[md5sum] = "72d0a9b3e60cd86fabcd3f24b1708944" -SRC_URI[sha256sum] = "46c9e55e1fddf40813b8d697d5645037a8e2af5c1a8dff52b3fe82b5021582b8" -
Signature · 1 line
1.8.1.2
Quoted 7 lines · Bruce Ashfield
Richard/Saul,
Here are the remaining changes from my previous pull request for linux-yocto updates.
Now that 3.14 has been released, we have the full 3.14 kernel and associated libc-headers .. with no PV games.
As a follow up to this, make sure that you have a clean sysroot when building, we've
heard of a couple of perf build failures (again), that sound like the header file issues
you'll see if an older kernel for a given machine is in the sysroot.
I'm trying another build of qemux86 to see if I can duplicate any issues, but won't
be around for a few hours to confirm or deny anything.
Bruce
Quoted 64 lines
There is one new change in the libc-headers series, to adapt to the xz compression of new headers, but otherwise, it is the same as before.
[
Subject: [PATCH 2/5] linux-libc-headers: make compression format configurableAs of the 3.13 kernel bz2 compressed tarballs are not available. To support older header tarballs, and newer ones that require the 'xz' compressed bundles, we can break out a variable that allows versioned libc headers to select the archive format that works.
Signed-off-by Bruce Ashfield <[email protected]>]
I've built and booted qemu* for this, so everything appears to be sane.
Cheers,
Bruce
The following changes since commit
4f80de9a568bcf0280c7e8b8f89ee6c2adfa477d:linux-yocto/3.10: fix qemuarm build failure (2014-03-30 23:53:00 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contribzedd/kernel
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernelBruce Ashfield (5):
linux-yocto/3.14: introduce versioned recipes
linux-libc-headers: make compression format configurable
linux-libc-headers: add 3.14 libc headers
libc-headers: set TC default to 3.14
linux-libc-headers: remove 3.10 recipemeta/conf/distro/include/tcmode-default.inc | 2 +- .../linux-libc-headers/linux-libc-headers.inc | 4 +- ...1-ptrace.h-remove-ptrace_peeksiginfo_args.patch | 50 ------------------ ...lude-asm-byteorder.h-in-linux-raid-md_p.h.patch | 34 ------------- ...efile.headersinst-install-headers-from-sc.patch | 59 ---------------------- .../linux-libc-headers/linux-libc-headers_3.10.bb | 11 ---- .../linux-libc-headers/linux-libc-headers_3.14.bb | 7 +++ meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21 ++++++++ meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37 ++++++++++++++ 9 files changed, 69 insertions(+), 156 deletions(-) delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb--
1.8.1.2--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 7 lines · Bruce Ashfield
Quoted 5 lines · Bruce Ashfield
Richard/Saul,
Here are the remaining changes from my previous pull request for linux-yocto updates.
Quoted 8 lines
Quoted 2 lines
Now that 3.14 has been released, we have the full 3.14 kernel and associated libc-headers .. with no PV games.
As a follow up to this, make sure that you have a clean sysroot when building, we've
heard of a couple of perf build failures (again), that sound like the header file issues
you'll see if an older kernel for a given machine is in the sysroot.
replying to myself before I head out for food! The build of perf that broke here, was
indeed a sysroot with 3.10 and 3.14 conflicting header files. My clean of the sysroot and a rebuild has worked. So I don't know of any reproducible perf build errors at the moment.
Bruce
Quoted 77 lines
I'm trying another build of qemux86 to see if I can duplicate any issues, but won't
be around for a few hours to confirm or deny anything.Bruce
Quoted 56 lines
There is one new change in the libc-headers series, to adapt to the xz compression of new headers, but otherwise, it is the same as before.
[
Subject: [PATCH 2/5] linux-libc-headers: make compression format configurableAs of the 3.13 kernel bz2 compressed tarballs are not available. To support older header tarballs, and newer ones that require the 'xz' compressed bundles, we can break out a variable that allows versioned libc headers to select the archive format that works.
Signed-off-by Bruce Ashfield <[email protected]>]
I've built and booted qemu* for this, so everything appears to be sane.
Cheers,
Bruce
The following changes since commit
4f80de9a568bcf0280c7e8b8f89ee6c2adfa477d:linux-yocto/3.10: fix qemuarm build failure (2014-03-30 23:53:00 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contribzedd/kernel
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernelBruce Ashfield (5):
linux-yocto/3.14: introduce versioned recipes
linux-libc-headers: make compression format configurable
linux-libc-headers: add 3.14 libc headers
libc-headers: set TC default to 3.14
linux-libc-headers: remove 3.10 recipemeta/conf/distro/include/tcmode-default.inc | 2 +- .../linux-libc-headers/linux-libc-headers.inc | 4 +- ...1-ptrace.h-remove-ptrace_peeksiginfo_args.patch | 50 ------------------ ...lude-asm-byteorder.h-in-linux-raid-md_p.h.patch | 34 ------------- ...efile.headersinst-install-headers-from-sc.patch | 59 ---------------------- .../linux-libc-headers/linux-libc-headers_3.10.bb | 11 ---- .../linux-libc-headers/linux-libc-headers_3.14.bb | 7 +++ meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21 ++++++++ meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37 ++++++++++++++ 9 files changed, 69 insertions(+), 156 deletions(-) delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bbQuoted 8 lines
--
1.8.1.2--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"