[PATCH 0/5] lnux-yocto: 3.14 updates

[PATCH 0/5] lnux-yocto: 3.14 updates

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

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.

   Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
]

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

-- 
1.8.1.2

[PATCH 1/5] linux-yocto/3.14: introduce versioned recipes

[Bruce Ashfield]

The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce
the versioned recipes here.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 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

diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
new file mode 100644
index 000000000000..2e142bfd9029
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -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 = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
new file mode 100644
index 000000000000..d5202cd4391a
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
@@ -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)}"
-- 
1.8.1.2

[PATCH 2/5] linux-libc-headers: make compression format configurable

[Bruce Ashfield]

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.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index 3f27afa4c922..b18d09fd6c3e 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -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}"
 
-- 
1.8.1.2

[PATCH 3/5] linux-libc-headers: add 3.14 libc headers

[Bruce Ashfield]

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

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 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

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb
new file mode 100644
index 000000000000..9ac70af942a1
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb
@@ -0,0 +1,7 @@
+KORG_ARCHIVE_COMPRESSION = "xz"
+
+require linux-libc-headers.inc
+
+SRC_URI[md5sum] = "b621207b3f6ecbb67db18b13258f8ea8"
+SRC_URI[sha256sum] = "61558aa490855f42b6340d1a1596be47454909629327c49a5e4e10268065dffa"
+
-- 
1.8.1.2

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

[Bruce Ashfield]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/conf/distro/include/tcmode-default.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc
index d6a626cfab8c..300deeaf5fb9 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -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}"
-- 
1.8.1.2

[PATCH 5/5] linux-libc-headers: remove 3.10 recipe

[Bruce Ashfield]

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

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 ...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

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch
deleted file mode 100644
index da2e117a486d..000000000000
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch
+++ /dev/null
@@ -1,50 +0,0 @@
-From 7dddfb8fec5317ea16154d30e8e18b6559979b60 Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield <bruce.ashfield@windriver.com>
-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 <bruce.ashfield@windriver.com>
----
- 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
-
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch
deleted file mode 100644
index 1bf0e7ec85f0..000000000000
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From c0f8bd146a8b3e630798561c605f5669823107af Mon Sep 17 00:00:00 2001
-From: Aurelien Jarno <aurelien@aurel32.net>
-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 <aurelien@aurel32.net>
-Signed-off-by: NeilBrown <neilb@suse.de>
----
- 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
-
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch
deleted file mode 100644
index 7eb7defcde13..000000000000
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch
+++ /dev/null
@@ -1,59 +0,0 @@
-From b200d4bcffc86bb08fd3898bc7cde00f0686f62d Mon Sep 17 00:00:00 2001
-From: Robert Yang <liezhi.yang@windriver.com>
-Date: Fri, 13 Sep 2013 22:01:02 -0400
-Subject: [PATCH] scripts/Makefile.headersinst: install headers from scratch file
-
-If headers_install is executed from a deep/long directory structure, the
-shell's maximum argument length can be execeeded, which breaks the operation
-with:
-
-| make[2]: execvp: /bin/sh: Argument list too long
-| make[2]: ***
-
-By dumping the input files to a scratch file and using xargs to read the
-input list from the scratch file, we can avoid blowing out the maximum
-argument size and install headers in a long path name environment.
-
-Robert:
-Use "$(foreach ,,$(shell echo))" rather than "echo" to make it work when
-len(TMPDIR) <= 410.
-
-Upstream-Status: Inappropriate [oe-specific]
-
-Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
-Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
----
-RP: Refreshed for 3.10 as the problem still exists there on the autobuilders
- scripts/Makefile.headersinst |    9 ++++++++-
- 1 file changed, 8 insertions(+), 1 deletion(-)
-
-diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
---- a/scripts/Makefile.headersinst
-+++ b/scripts/Makefile.headersinst
-@@ -72,7 +72,7 @@ printdir = $(patsubst $(INSTALL_HDR_PATH)/%/,%,$(dir $@))
- quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\
-                             file$(if $(word 2, $(all-files)),s))
-       cmd_install = \
--        $(CONFIG_SHELL) $< $(installdir) $(input-files); \
-+        xargs $(CONFIG_SHELL) $< $(installdir) < $(INSTALL_HDR_PATH)/.input-files; \
-         for F in $(wrapper-files); do                                   \
-                 echo "\#include <asm-generic/$$F>" > $(installdir)/$$F;    \
-         done;                                                           \
-@@ -98,10 +98,17 @@ __headersinst: $(subdirs) $(install-file)
- 	@:
- 
- targets += $(install-file)
-+# Use the $(foreach ,,$(shell echo)) to avoid the "Argument list too
-+# long" error, and use the "$(shell echo)" rather than "echo" to keep
-+# the order.
- $(install-file): scripts/headers_install.sh $(input-files) FORCE
- 	$(if $(unwanted),$(call cmd,remove),)
- 	$(if $(wildcard $(dir $@)),,$(shell mkdir -p $(dir $@)))
-+	$(shell echo -n > $(INSTALL_HDR_PATH)/.input-files)
-+	$(foreach f,$(input-files),$(shell echo -n "$(f) " >> \
-+			$(INSTALL_HDR_PATH)/.input-files))
- 	$(call if_changed,install)
-+	@rm $(INSTALL_HDR_PATH)/.input-files
- 
- else
- __headerscheck: $(subdirs) $(check-file)
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb
deleted file mode 100644
index a78d4ba59a62..000000000000
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb
+++ /dev/null
@@ -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"
-
-- 
1.8.1.2

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

[Khem Raj]

On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
>
> -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

[Bruce Ashfield]

On 14-03-31 03:29 PM, Khem Raj wrote:
> On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield
> <bruce.ashfield@windriver.com> wrote:
>>
>> -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.

> 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

>

Re: [PATCH 1/5] linux-yocto/3.14: introduce versioned recipes

[Paul Barker]

On 31 March 2014 18:56, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
> 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?

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: [PATCH 1/5] linux-yocto/3.14: introduce versioned recipes

[Bruce Ashfield]

On 14-03-31 03:39 PM, Paul Barker wrote:
> On 31 March 2014 18:56, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
>> 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

>

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

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

-Khem
On Mar 31, 2014 12:33 PM, "Bruce Ashfield" <bruce.ashfield@windriver.com>
wrote:
>
> On 14-03-31 03:29 PM, Khem Raj wrote:
>>
>> On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield
>> <bruce.ashfield@windriver.com> wrote:
>>>
>>>
>>> -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.

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

[-- Attachment #2: Type: text/html, Size: 2050 bytes --]

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

[Bruce Ashfield]

On 14-03-31 03:47 PM, Khem Raj wrote:
> -Khem
> On Mar 31, 2014 12:33 PM, "Bruce Ashfield" <bruce.ashfield@windriver.com
> <mailto:bruce.ashfield@windriver.com>> wrote:
>  >
>  > On 14-03-31 03:29 PM, Khem Raj wrote:
>  >>
>  >> On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield
>  >> <bruce.ashfield@windriver.com <mailto:bruce.ashfield@windriver.com>>
> wrote:
>  >>>
>  >>>
>  >>> -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.
>
> 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.

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

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

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

Re: [PATCH 0/5] lnux-yocto: 3.14 updates

[Bruce Ashfield]

On Mon, Mar 31, 2014 at 1:56 PM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
> 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

>
> 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.
>
>    Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ]
>
> 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
>
> --
> 1.8.1.2
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/5] lnux-yocto: 3.14 updates

[Bruce Ashfield]

On Mon, Mar 31, 2014 at 5:09 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Mon, Mar 31, 2014 at 1:56 PM, Bruce Ashfield
> <bruce.ashfield@windriver.com> wrote:
>> 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.

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

>
> 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
>
>>
>> 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.
>>
>>    Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ]
>>
>> 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
>>
>> --
>> 1.8.1.2
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

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

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]


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.  

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

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

[Bruce Ashfield]

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.

Cheers,

Bruce

>

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

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)
|                         ^

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Bruce Ashfield]

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.

Bruce

> |                         ^
>

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

[Richard Purdie]

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

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

[Bruce Ashfield]

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
>