linux-yocto: build changes, 4.1 and libc-headers

Hi all,

This series absolutely needs some more testing and runs through the autobuilder, but I've done pretty much all I can do with it here.

I have more changes to the build process that will follow this, but these changes need to show that they are stable, so here's the first blast.

With this series:

- I create the 4.1, and 4.1-rt linux-yocto content. This will be the new LTSI kernel. Deletion of 3.14 and 3.19 will follow once all machines have been moved forward.

- libc-headers updated to match the 4.1 kernel version.

And the one that could cause some issues/compatibility issues is the split of the kernel configuration data from the kernel tree itself.

From the commit log:

The linux-yocto tree has always been a combined set of kernel changes and configuration (meta) data carried in a single tree. While this format is effective at keeping kernel configuration and source modifications synchronized, it isn't always obvious to developers on how to manipulate the meta data versus the source.

With this change, we remove the meta data processing from the kernel-yocto class and use the external meta-data repository that has always been used to seed the linux-yocto meta branch.

After this change, linux-yocto can no longer process combined trees, and is simplified as a result.

I'm interested to find out if we get any breakages or severe compability issues with the change. I don't want to support both variants of the meta data (in and out of tree), since the goal is to reduce complexity in the code. Once this change lands, I'll further streamline things.

I've built core-image-kernel-dev and boot tested the qemu* machines. qemuppc continues to show a boot failure with systemd, but we have a bugzilla to track that.

I'm now doing graphical testing, but wanted to get this out and soaking for other images types while I wait for builds to churn.

Cheers,

Bruce

The following changes since commit 0f8d89ce66cfffccc9911d6c61470a585173b79d:

core-image-lsb-sdk: use kernel-devsrc to ensure kernel module builds work (2015-07-20 10:40:42 +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 (4):
linux-yocto: split meta data from kernel repository
kern-tools: standalone tree configuration
linux-libc-headers: update to 4.1
linux-yocto: introduce 4.1 versioned recipes

 meta/classes/kernel-yocto.bbclass                  | 76 ++--------------------
 meta/conf/distro/include/tcmode-default.inc        |  2 +-
 .../kern-tools/kern-tools-native_git.bb            |  2 +-
 .../linux-libc-headers/linux-libc-headers.inc      |  2 +
 .../linux-libc-headers/linux-libc-headers_3.19.bb  |  7 --
 .../linux-libc-headers/linux-libc-headers_4.1.bb   |  7 ++
 meta/recipes-kernel/linux/linux-yocto-dev.bb       |  5 +-
 meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb   |  7 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb    | 26 ++++++++
 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb |  7 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb |  7 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb  | 23 +++++++
 meta/recipes-kernel/linux/linux-yocto_3.14.bb      |  7 +-
 meta/recipes-kernel/linux/linux-yocto_3.19.bb      |  7 +-
 meta/recipes-kernel/linux/linux-yocto_4.1.bb       | 41 ++++++++++++
 15 files changed, 129 insertions(+), 97 deletions(-)
 delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb
 create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.1.bb

--
2.1.0

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 44 lines · Bruce Ashfield

Hi all,

This series absolutely needs some more testing and runs through the autobuilder, but I've done pretty much all I can do with it here.

I have more changes to the build process that will follow this, but these changes need to show that they are stable, so here's the first blast.

With this series:

- I create the 4.1, and 4.1-rt linux-yocto content. This will be the new LTSI kernel. Deletion of 3.14 and 3.19 will follow once all machines have been moved forward.

- libc-headers updated to match the 4.1 kernel version.

And the one that could cause some issues/compatibility issues is the split of the kernel configuration data from the kernel tree itself.

From the commit log:

The linux-yocto tree has always been a combined set of kernel changes and configuration (meta) data carried in a single tree. While this format is effective at keeping kernel configuration and source modifications synchronized, it isn't always obvious to developers on how to manipulate the meta data versus the source.

With this change, we remove the meta data processing from the kernel-yocto class and use the external meta-data repository that has always been used to seed the linux-yocto meta branch.

After this change, linux-yocto can no longer process combined trees, and is simplified as a result.

I'm interested to find out if we get any breakages or severe compability issues with the change. I don't want to support both variants of the meta data (in and out of tree), since the goal is to reduce complexity in the code. Once this change lands, I'll further streamline things.

I've built core-image-kernel-dev and boot tested the qemu* machines. qemuppc continues to show a boot failure with systemd, but we have a bugzilla to track that.

Quoted 2 lines

I'm now doing graphical testing, but wanted to get this out and soaking for other images types while I wait for builds to churn.

As a follow up, my qemuarm boots that worked on Friday, are now hanging. I'm bisecting to find out what happened.

But I have tested graphics on x86 and mips without issue.

Cheers,

Bruce

Quoted 42 lines

Cheers,

Bruce

The following changes since commit 0f8d89ce66cfffccc9911d6c61470a585173b79d:

core-image-lsb-sdk: use kernel-devsrc to ensure kernel module builds work (2015-07-20 10:40:42 +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 (4):
linux-yocto: split meta data from kernel repository
kern-tools: standalone tree configuration
linux-libc-headers: update to 4.1
linux-yocto: introduce 4.1 versioned recipes

 meta/classes/kernel-yocto.bbclass                  | 76 ++--------------------
 meta/conf/distro/include/tcmode-default.inc        |  2 +-
 .../kern-tools/kern-tools-native_git.bb            |  2 +-
 .../linux-libc-headers/linux-libc-headers.inc      |  2 +
 .../linux-libc-headers/linux-libc-headers_3.19.bb  |  7 --
 .../linux-libc-headers/linux-libc-headers_4.1.bb   |  7 ++
 meta/recipes-kernel/linux/linux-yocto-dev.bb       |  5 +-
 meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb   |  7 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb    | 26 ++++++++
 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb |  7 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb |  7 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb  | 23 +++++++
 meta/recipes-kernel/linux/linux-yocto_3.14.bb      |  7 +-
 meta/recipes-kernel/linux/linux-yocto_3.19.bb      |  7 +-
 meta/recipes-kernel/linux/linux-yocto_4.1.bb       | 41 ++++++++++++
 15 files changed, 129 insertions(+), 97 deletions(-)
 delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb
 create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.1.bb

Quoted 8 lines

--
2.1.0

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

Quoted 46 lines · Bruce Ashfield

Quoted 44 lines · Bruce Ashfield

Hi all,

This series absolutely needs some more testing and runs through the autobuilder, but I've done pretty much all I can do with it here.

I have more changes to the build process that will follow this, but these changes need to show that they are stable, so here's the first blast.

With this series:

- I create the 4.1, and 4.1-rt linux-yocto content. This will be the new LTSI kernel. Deletion of 3.14 and 3.19 will follow once all machines have been moved forward.

- libc-headers updated to match the 4.1 kernel version.

And the one that could cause some issues/compatibility issues is the split of the kernel configuration data from the kernel tree itself.

From the commit log:

The linux-yocto tree has always been a combined set of kernel changes and configuration (meta) data carried in a single tree. While this format is effective at keeping kernel configuration and source modifications synchronized, it isn't always obvious to developers on how to manipulate the meta data versus the source.

With this change, we remove the meta data processing from the kernel-yocto class and use the external meta-data repository that has always been used to seed the linux-yocto meta branch.

After this change, linux-yocto can no longer process combined trees, and is simplified as a result.

I'm interested to find out if we get any breakages or severe compability issues with the change. I don't want to support both variants of the meta data (in and out of tree), since the goal is to reduce complexity in the code. Once this change lands, I'll further streamline things.

I've built core-image-kernel-dev and boot tested the qemu* machines. qemuppc continues to show a boot failure with systemd, but we have a bugzilla to track that.

Quoted 5 lines

Quoted 2 lines

I'm now doing graphical testing, but wanted to get this out and soaking for other images types while I wait for builds to churn.

As a follow up, my qemuarm boots that worked on Friday, are now hanging. I'm bisecting to find out what happened.

And a final follow up.

qemuarm (console and graphics) works fine .. but only if you use gcc 4.9.x, gcc 5.1
is doing something evil.

We've looked into this in the past, so it is a known issue, but I need to handle these
separately.

Quoted 56 lines · Bruce Ashfield

Quoted 46 lines · Bruce Ashfield

Quoted 44 lines · Bruce Ashfield

Hi all,

This series absolutely needs some more testing and runs through the autobuilder, but I've done pretty much all I can do with it here.

I have more changes to the build process that will follow this, but these changes need to show that they are stable, so here's the first blast.

With this series:

- I create the 4.1, and 4.1-rt linux-yocto content. This will be the new LTSI kernel. Deletion of 3.14 and 3.19 will follow once all machines have been moved forward.

- libc-headers updated to match the 4.1 kernel version.

And the one that could cause some issues/compatibility issues is the split of the kernel configuration data from the kernel tree itself.

From the commit log:

The linux-yocto tree has always been a combined set of kernel changes and configuration (meta) data carried in a single tree. While this format is effective at keeping kernel configuration and source modifications synchronized, it isn't always obvious to developers on how to manipulate the meta data versus the source.

With this change, we remove the meta data processing from the kernel-yocto class and use the external meta-data repository that has always been used to seed the linux-yocto meta branch.

After this change, linux-yocto can no longer process combined trees, and is simplified as a result.

I'm interested to find out if we get any breakages or severe compability issues with the change. I don't want to support both variants of the meta data (in and out of tree), since the goal is to reduce complexity in the code. Once this change lands, I'll further streamline things.

I've built core-image-kernel-dev and boot tested the qemu* machines. qemuppc continues to show a boot failure with systemd, but we have a bugzilla to track that.

Quoted 5 lines

Quoted 2 lines

I'm now doing graphical testing, but wanted to get this out and soaking for other images types while I wait for builds to churn.

As a follow up, my qemuarm boots that worked on Friday, are now hanging. I'm bisecting to find out what happened.

And a final follow up.

Quoted 7 lines

qemuarm (console and graphics) works fine .. but only if you use gcc 4.9.x, gcc 5.1
is doing something evil.

We've looked into this in the past, so it is a known issue, but I need to handle these
separately.

We got the results of a run of those changes through the autobuilder without the noise of other failures. The error reporting system shows:

http://errors.yoctoproject.org/Errors/Search/?items=10&query=d687cdfd04f3d97923c93239ea902bb38e2ea336

and I believe we have the following issues:

a) qemux86/qemux86-64 are throwing warnings about errors in logs
b) perf has some weird make race
c) the qemuarm build looks like qemu either segfaulted or was killed
d) we're occasionally seeing 3.19 and 3.14 fetch failures:
https://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/394/steps/BuildImages/logs/stdio
https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/87/steps/Running%20oe-selftest/logs/stdio

To try and promote more sstate cache reuse whilst we sort the remaining issues, I merged the linux-libc-header part, we need to get the above fixed before the other pieces can merge.

Cheers,

Richard

Quoted 70 lines · Richard Purdie

Quoted 56 lines · Bruce Ashfield

Quoted 46 lines · Bruce Ashfield

Quoted 44 lines · Bruce Ashfield

Hi all,

This series absolutely needs some more testing and runs through the autobuilder, but I've done pretty much all I can do with it here.

I have more changes to the build process that will follow this, but these changes need to show that they are stable, so here's the first blast.

With this series:

- I create the 4.1, and 4.1-rt linux-yocto content. This will be the new LTSI kernel. Deletion of 3.14 and 3.19 will follow once all machines have been moved forward.

- libc-headers updated to match the 4.1 kernel version.

And the one that could cause some issues/compatibility issues is the split of the kernel configuration data from the kernel tree itself.

From the commit log:

The linux-yocto tree has always been a combined set of kernel changes and configuration (meta) data carried in a single tree. While this format is effective at keeping kernel configuration and source modifications synchronized, it isn't always obvious to developers on how to manipulate the meta data versus the source.

With this change, we remove the meta data processing from the kernel-yocto class and use the external meta-data repository that has always been used to seed the linux-yocto meta branch.

After this change, linux-yocto can no longer process combined trees, and is simplified as a result.

I'm interested to find out if we get any breakages or severe compability issues with the change. I don't want to support both variants of the meta data (in and out of tree), since the goal is to reduce complexity in the code. Once this change lands, I'll further streamline things.

I've built core-image-kernel-dev and boot tested the qemu* machines. qemuppc continues to show a boot failure with systemd, but we have a bugzilla to track that.

Quoted 5 lines

Quoted 2 lines

I'm now doing graphical testing, but wanted to get this out and soaking for other images types while I wait for builds to churn.

As a follow up, my qemuarm boots that worked on Friday, are now hanging. I'm bisecting to find out what happened.

And a final follow up.

Quoted 7 lines

qemuarm (console and graphics) works fine .. but only if you use gcc 4.9.x, gcc 5.1
is doing something evil.

We've looked into this in the past, so it is a known issue, but I need to handle these
separately.

We got the results of a run of those changes through the autobuilder without the noise of other failures. The error reporting system shows:

http://errors.yoctoproject.org/Errors/Search/?items=10&query=d687cdfd04f3d97923c93239ea902bb38e2ea336

Quoted 8 lines

and I believe we have the following issues:

a) qemux86/qemux86-64 are throwing warnings about errors in logs
b) perf has some weird make race
c) the qemuarm build looks like qemu either segfaulted or was killed
d) we're occasionally seeing 3.19 and 3.14 fetch failures:
https://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/394/steps/BuildImages/logs/stdio
https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/87/steps/Running%20oe-selftest/logs/stdio

I explained to Ross that dependent layers need to be updated if they set their own SRCREV_meta, since the repository is completely different. I sent a patch for meta-intel to deal with it. Obviously, I only built with the core BSPs during testing.

I'll definitely need help on these, since I wasn't seeing any of these issues during my testing. Otherwise, this won't be done until September (vacation and other issues to deal with).

But I'll see what I can do.

I unfortunately can't merge anything but critical kernel patches until these go in as well
since the meta branch is gone in the new scripts, which means SRCREV_meta is a constant conflict.

Quoted 81 lines · Bruce Ashfield

Quoted 70 lines · Richard Purdie

Quoted 56 lines · Bruce Ashfield

Quoted 46 lines · Bruce Ashfield

Quoted 44 lines · Bruce Ashfield

Hi all,

This series absolutely needs some more testing and runs through the autobuilder, but I've done pretty much all I can do with it here.

I have more changes to the build process that will follow this, but these changes need to show that they are stable, so here's the first blast.

With this series:

- I create the 4.1, and 4.1-rt linux-yocto content. This will be the new LTSI kernel. Deletion of 3.14 and 3.19 will follow once all machines have been moved forward.

- libc-headers updated to match the 4.1 kernel version.

And the one that could cause some issues/compatibility issues is the split of the kernel configuration data from the kernel tree itself.

From the commit log:

The linux-yocto tree has always been a combined set of kernel changes and configuration (meta) data carried in a single tree. While this format is effective at keeping kernel configuration and source modifications synchronized, it isn't always obvious to developers on how to manipulate the meta data versus the source.

With this change, we remove the meta data processing from the kernel-yocto class and use the external meta-data repository that has always been used to seed the linux-yocto meta branch.

After this change, linux-yocto can no longer process combined trees, and is simplified as a result.

I'm interested to find out if we get any breakages or severe compability issues with the change. I don't want to support both variants of the meta data (in and out of tree), since the goal is to reduce complexity in the code. Once this change lands, I'll further streamline things.

I've built core-image-kernel-dev and boot tested the qemu* machines. qemuppc continues to show a boot failure with systemd, but we have a bugzilla to track that.

Quoted 5 lines

Quoted 2 lines

I'm now doing graphical testing, but wanted to get this out and soaking for other images types while I wait for builds to churn.

As a follow up, my qemuarm boots that worked on Friday, are now hanging. I'm bisecting to find out what happened.

And a final follow up.

Quoted 7 lines

qemuarm (console and graphics) works fine .. but only if you use gcc 4.9.x, gcc 5.1
is doing something evil.

We've looked into this in the past, so it is a known issue, but I need to handle these
separately.

We got the results of a run of those changes through the autobuilder without the noise of other failures. The error reporting system shows:

http://errors.yoctoproject.org/Errors/Search/?items=10&query=d687cdfd04f3d97923c93239ea902bb38e2ea336

Quoted 8 lines

and I believe we have the following issues:

a) qemux86/qemux86-64 are throwing warnings about errors in logs
b) perf has some weird make race
c) the qemuarm build looks like qemu either segfaulted or was killed
d) we're occasionally seeing 3.19 and 3.14 fetch failures:
https://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/394/steps/BuildImages/logs/stdio
https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/87/steps/Running%20oe-selftest/logs/stdio

Quoted 4 lines

I explained to Ross that dependent layers need to be updated if they set their own SRCREV_meta, since the repository is completely different. I sent a patch for meta-intel to deal with it. Obviously, I only built with the core BSPs during testing.

That could explain d). I believe c) is from the ongoing selftest issues we're having and I we've work in progress for that. That leaves a) and
b) to look into and fix.

Quoted 6 lines

I'll definitely need help on these, since I wasn't seeing any of these issues during my testing. Otherwise, this won't be done until September (vacation and other issues to deal with).

But I'll see what I can do.

Quoted 4 lines

I unfortunately can't merge anything but critical kernel patches until these go in as well
since the meta branch is gone in the new scripts, which means SRCREV_meta is a constant conflict.

a) should be straightfoward to fix, its just updating the message whitelists (again).

b) I'm less sure about. Are there any race fixes in mainline for perf? Hard to believe others don't see that one.

Cheers,

Richard

Quoted 2 lines

a) should be straightfoward to fix, its just updating the message whitelists (again).

I'm building a fresh qemux86-64 now, I'm going to see if the warnings are something
I should fix, versus the whitelist. I should know tomorrow on this one.

Quoted 23 lines · Richard Purdie

Quoted 11 lines · Bruce Ashfield

Quoted 6 lines

a) qemux86/qemux86-64 are throwing warnings about errors in logs
b) perf has some weird make race
c) the qemuarm build looks like qemu either segfaulted or was killed
d) we're occasionally seeing 3.19 and 3.14 fetch failures:
https://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/394/steps/BuildImages/logs/stdio
https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/87/steps/Running%20oe-selftest/logs/stdio

I explained to Ross that dependent layers need to be updated if they set their own SRCREV_meta, since the repository is completely different. I sent a patch for meta-intel to deal with it. Obviously, I only built with the core BSPs during testing.

That could explain d). I believe c) is from the ongoing selftest issues we're having and I we've work in progress for that. That leaves a) and
b) to look into and fix.

Quoted 6 lines

I'll definitely need help on these, since I wasn't seeing any of these issues during my testing. Otherwise, this won't be done until September (vacation and other issues to deal with).

But I'll see what I can do.

Quoted 7 lines

Quoted 4 lines

I unfortunately can't merge anything but critical kernel patches until these go in as well
since the meta branch is gone in the new scripts, which means SRCREV_meta is a constant conflict.

a) should be straightfoward to fix, its just updating the message whitelists (again).

I'm building a fresh qemux86-64 now, I'm going to see if the warnings are something
I should fix, versus the whitelist. I should know tomorrow on this one.

Quoted 1 line

Quoted 2 lines

b) I'm less sure about. Are there any race fixes in mainline for perf? Hard to believe others don't see that one.

I'm searching as well. I'll share any findings ASAP.