From: Andrei Gherzan <andrei.gherzan@...>

clang-based builds are still broken due to:
https://github.com/llvm/llvm-project/issues/53999

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
recipes-containers/podman/podman_git.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-containers/podman/podman_git.bb b/recipes-containers/podman/podman_git.bb
index 2bbc4dc..9b92094 100644
--- a/recipes-containers/podman/podman_git.bb
+++ b/recipes-containers/podman/podman_git.bb
@@ -44,6 +44,9 @@ exclude_graphdriver_btrfs exclude_graphdriver_devicemapper"
# overide LDFLAGS to allow podman to build without: "flag provided but not # defined: -Wl,-O1
export LDFLAGS=""

+# https://github.com/llvm/llvm-project/issues/53999
+TOOLCHAIN = "gcc"
+
inherit go goarch
inherit systemd pkgconfig

--
2.25.1

From: Andrei Gherzan <andrei.gherzan@...>

This will fix clang-based builds.

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
...efine-ActKillThread-equal-to-ActKill.patch | 90 +++++++++++++++++++
recipes-containers/podman/podman_git.bb | 1 +
2 files changed, 91 insertions(+)
create mode 100644 recipes-containers/podman/podman/0002-Define-ActKillThread-equal-to-ActKill.patch

diff --git a/recipes-containers/podman/podman/0002-Define-ActKillThread-equal-to-ActKill.patch b/recipes-containers/podman/podman/0002-Define-ActKillThread-equal-to-ActKill.patch
new file mode 100644
index 0000000..8ed5503
--- /dev/null
+++ b/recipes-containers/podman/podman/0002-Define-ActKillThread-equal-to-ActKill.patch
@@ -0,0 +1,90 @@
+From f2aa0359bcc776239bda8a4eb84957b97ef55c35 Mon Sep 17 00:00:00 2001
+From: Tonis Tiigi <tonistiigi@...>
+Date: Fri, 28 Jan 2022 14:44:56 -0800
+Subject: [PATCH] Define ActKillThread equal to ActKill
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+These constants are equal in libseccomp but Go definitions
+were defined separately. This resulted in dead code that
+never executed due to identical case statements in switch.
+Go can usually detect these error cases and refuses to build
+but for some reason this detection doesn’t work with cgo+gcc.
+Clang detects the equal constants correctly and therefore
+libseccomp-golang builds with clang broke after ActKillThread
+was added.
+
+In order to fix the clang build only removal of the
+switch case is needed. But I assumed that the setter/getter
+logic is supposed to work for ActKillThread as well
+and only way to ensure that is to set them equal like they
+are in C.
+
+Signed-off-by: Tonis Tiigi <tonistiigi@...>
+Signed-off-by: Sebastiaan van Stijn <github@...>
+Acked-by: Tom Hromatka <tom.hromatka@...>
+Signed-off-by: Paul Moore <paul@...>
+Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
+Upstrea-status: Backport [https://github.com/seccomp/libseccomp-golang/commit/c35397d0ea8f285a0be78693bb2fd37b06952453]
+---
+ seccomp.go | 8 ++++----
+ seccomp_internal.go | 4 ----
+ 2 files changed, 4 insertions(+), 8 deletions(-)
+
+diff --git a/seccomp.go b/seccomp.go
+index e9b92e2..32f6ab2 100644
+--- a/seccomp.go
++++ b/seccomp.go
+@@ -214,14 +214,14 @@ const (
+ // This action is only usable when libseccomp API level 3 or higher is
+ // supported.
+ ActLog ScmpAction = iota
+- // ActKillThread kills the thread that violated the rule. It is the same as ActKill.
+- // All other threads from the same thread group will continue to execute.
+- ActKillThread ScmpAction = iota
+ // ActKillProcess kills the process that violated the rule.
+ // All threads in the thread group are also terminated.
+ // This action is only usable when libseccomp API level 3 or higher is
+ // supported.
+ ActKillProcess ScmpAction = iota
++ // ActKillThread kills the thread that violated the rule. It is the same as ActKill.
++ // All other threads from the same thread group will continue to execute.
++ ActKillThread = ActKill
+ )
+
+ const (
+@@ -394,7 +394,7 @@ func (a ScmpCompareOp) String() string {
+ // String returns a string representation of a seccomp match action
+ func (a ScmpAction) String() string {
+ switch a & 0xFFFF {
+- case ActKill, ActKillThread:
++ case ActKillThread:
+ return "Action: Kill thread"
+ case ActKillProcess:
+ return "Action: Kill process"
+diff --git a/seccomp_internal.go b/seccomp_internal.go
+index 8dc7b29..8fc9914 100644
+--- a/seccomp_internal.go
++++ b/seccomp_internal.go
+@@ -612,8 +612,6 @@ func (a ScmpCompareOp) toNative() C.int {
+ func actionFromNative(a C.uint32_t) (ScmpAction, error) {
+ aTmp := a & 0xFFFF
+ switch a & 0xFFFF0000 {
+- case C.C_ACT_KILL:
+- return ActKill, nil
+ case C.C_ACT_KILL_PROCESS:
+ return ActKillProcess, nil
+ case C.C_ACT_KILL_THREAD:
+@@ -638,8 +636,6 @@ func actionFromNative(a C.uint32_t) (ScmpAction, error) {
+ // Only use with sanitized actions, no error handling
+ func (a ScmpAction) toNative() C.uint32_t {
+ switch a & 0xFFFF {
+- case ActKill:
+- return C.C_ACT_KILL
+ case ActKillProcess:
+ return C.C_ACT_KILL_PROCESS
+ case ActKillThread:
+--
+2.25.1
+
diff --git a/recipes-containers/podman/podman_git.bb b/recipes-containers/podman/podman_git.bb
index 73d3c93..2bbc4dc 100644
--- a/recipes-containers/podman/podman_git.bb
+++ b/recipes-containers/podman/podman_git.bb
@@ -21,6 +21,7 @@ SRCREV = "cedbbfa543651a13055a1fe093a4d0a2a28ccdfd"
SRC_URI = " \
git://github.com/containers/libpod.git;branch=v4.1;protocol=https \
file://0001-Rename-BUILDFLAGS-to-GOBUILDFLAGS.patch;patchdir=src/import \
+ file://0002-Define-ActKillThread-equal-to-ActKill.patch;patchdir=src/import/vendor/github.com/seccomp/libseccomp-golang \
${@bb.utils.contains('PACKAGECONFIG', 'rootless', 'file://00-podman-rootless.conf', '', d)} \
"

--
2.25.1

From: Andrei Gherzan <andrei.gherzan@...>

This will fix clang-based builds.

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
...efine-ActKillThread-equal-to-ActKill.patch | 90 +++++++++++++++++++
.../runc/runc-opencontainers_git.bb | 1 +
2 files changed, 91 insertions(+)
create mode 100644 recipes-containers/runc/files/0002-Define-ActKillThread-equal-to-ActKill.patch

diff --git a/recipes-containers/runc/files/0002-Define-ActKillThread-equal-to-ActKill.patch b/recipes-containers/runc/files/0002-Define-ActKillThread-equal-to-ActKill.patch
new file mode 100644
index 0000000..8ed5503
--- /dev/null
+++ b/recipes-containers/runc/files/0002-Define-ActKillThread-equal-to-ActKill.patch
@@ -0,0 +1,90 @@
+From f2aa0359bcc776239bda8a4eb84957b97ef55c35 Mon Sep 17 00:00:00 2001
+From: Tonis Tiigi <tonistiigi@...>
+Date: Fri, 28 Jan 2022 14:44:56 -0800
+Subject: [PATCH] Define ActKillThread equal to ActKill
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+These constants are equal in libseccomp but Go definitions
+were defined separately. This resulted in dead code that
+never executed due to identical case statements in switch.
+Go can usually detect these error cases and refuses to build
+but for some reason this detection doesn’t work with cgo+gcc.
+Clang detects the equal constants correctly and therefore
+libseccomp-golang builds with clang broke after ActKillThread
+was added.
+
+In order to fix the clang build only removal of the
+switch case is needed. But I assumed that the setter/getter
+logic is supposed to work for ActKillThread as well
+and only way to ensure that is to set them equal like they
+are in C.
+
+Signed-off-by: Tonis Tiigi <tonistiigi@...>
+Signed-off-by: Sebastiaan van Stijn <github@...>
+Acked-by: Tom Hromatka <tom.hromatka@...>
+Signed-off-by: Paul Moore <paul@...>
+Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
+Upstrea-status: Backport [https://github.com/seccomp/libseccomp-golang/commit/c35397d0ea8f285a0be78693bb2fd37b06952453]
+---
+ seccomp.go | 8 ++++----
+ seccomp_internal.go | 4 ----
+ 2 files changed, 4 insertions(+), 8 deletions(-)
+
+diff --git a/seccomp.go b/seccomp.go
+index e9b92e2..32f6ab2 100644
+--- a/seccomp.go
++++ b/seccomp.go
+@@ -214,14 +214,14 @@ const (
+ // This action is only usable when libseccomp API level 3 or higher is
+ // supported.
+ ActLog ScmpAction = iota
+- // ActKillThread kills the thread that violated the rule. It is the same as ActKill.
+- // All other threads from the same thread group will continue to execute.
+- ActKillThread ScmpAction = iota
+ // ActKillProcess kills the process that violated the rule.
+ // All threads in the thread group are also terminated.
+ // This action is only usable when libseccomp API level 3 or higher is
+ // supported.
+ ActKillProcess ScmpAction = iota
++ // ActKillThread kills the thread that violated the rule. It is the same as ActKill.
++ // All other threads from the same thread group will continue to execute.
++ ActKillThread = ActKill
+ )
+
+ const (
+@@ -394,7 +394,7 @@ func (a ScmpCompareOp) String() string {
+ // String returns a string representation of a seccomp match action
+ func (a ScmpAction) String() string {
+ switch a & 0xFFFF {
+- case ActKill, ActKillThread:
++ case ActKillThread:
+ return "Action: Kill thread"
+ case ActKillProcess:
+ return "Action: Kill process"
+diff --git a/seccomp_internal.go b/seccomp_internal.go
+index 8dc7b29..8fc9914 100644
+--- a/seccomp_internal.go
++++ b/seccomp_internal.go
+@@ -612,8 +612,6 @@ func (a ScmpCompareOp) toNative() C.int {
+ func actionFromNative(a C.uint32_t) (ScmpAction, error) {
+ aTmp := a & 0xFFFF
+ switch a & 0xFFFF0000 {
+- case C.C_ACT_KILL:
+- return ActKill, nil
+ case C.C_ACT_KILL_PROCESS:
+ return ActKillProcess, nil
+ case C.C_ACT_KILL_THREAD:
+@@ -638,8 +636,6 @@ func actionFromNative(a C.uint32_t) (ScmpAction, error) {
+ // Only use with sanitized actions, no error handling
+ func (a ScmpAction) toNative() C.uint32_t {
+ switch a & 0xFFFF {
+- case ActKill:
+- return C.C_ACT_KILL
+ case ActKillProcess:
+ return C.C_ACT_KILL_PROCESS
+ case ActKillThread:
+--
+2.25.1
+
diff --git a/recipes-containers/runc/runc-opencontainers_git.bb b/recipes-containers/runc/runc-opencontainers_git.bb
index 14570b9..f9dae6a 100644
--- a/recipes-containers/runc/runc-opencontainers_git.bb
+++ b/recipes-containers/runc/runc-opencontainers_git.bb
@@ -4,6 +4,7 @@ SRCREV = "b507e2da6c6a3a328f208fa415a56ad7cd58761b"
SRC_URI = " \
git://github.com/opencontainers/runc;branch=release-1.1;protocol=https \
file://0001-Makefile-respect-GOBUILDFLAGS-for-runc-and-remove-re.patch \
+ file://0002-Define-ActKillThread-equal-to-ActKill.patch;patchdir=src/import/vendor/github.com/seccomp/libseccomp-golang \
"
RUNC_VERSION = "1.1.2"

--
2.25.1

On Wed, Jul 27, 2022 at 3:24 AM Ibrahim Erturk via
lists.yoctoproject.org <ierturk=ieee.org@...>
wrote:

Hello,

I added the following line into local.conf to get the packages docker and docker-compose on Rapberry Pi (meta-raspberrypi) with the branch kirkstone.

# Virtualization
DISTRO_FEATURES:append = " virtualization"
IMAGE_INSTALL:append = " docker-ce"
IMAGE_INSTALL:append = " python3-docker-compose”
# IMAGE_INSTALL:append = " python3-distutils"

However, due to python3-distutils deprecated as of Python3.10, I got the following error.

raspberrypi3:~$ docker-compose
Traceback (most recent call last):
File "/usr/bin/docker-compose", line 5, in <module>
from compose.cli.main import main
File "/usr/lib/python3.10/site-packages/compose/cli/main.py", line 9, in <module>
from distutils.spawn import find_executable
ModuleNotFoundError: No module named ‘distutils’

Is there any workaround regarding this issue or am I missing some configuration?

I'm not sure I'm following.

docker-compose has been on the same version for quite some time (mid
2021) on pypi (the source repo does have newer versions, so we could
consider switching to source vs pypi).

and yes, that version is still using distutils. So either you need to
install the depreciated module, or do an uprev to a newer version
using the github repo.

Bruce

Thanks in advance.

Regards,
Ibrahim ERTURK

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

On Wed, Jul 27, 2022 at 3:19 AM Diego Sueiro <diego.sueiro@...> wrote:

Hi Bruce,

On Mon, Jun 27, 2022 at 01:51 PM, Bruce Ashfield wrote:

On Mon, Jun 27, 2022 at 6:00 AM Kamil Dzieżyk <Kamil.Dziezyk@...> wrote:

Hello Bruce,

There is a problem with the k3s service starting when the Yocto image is

built with the meta-virtualization master branch.

This issue might be related to the go-lang version(1.18) used to build the

k3s.

After this patch was merged:

https://git.yoctoproject.org/poky/commit/?id=8dc1f28aa10c775e64b5275679b1f8142e8cd038

a warning pops up during the k3s build:
```
WARNING: k3s-v1.22.6+k3s1+git4262c6b91a43ef8411870f72ff8b8715949f90e2-r0

do_package_qa: QA Issue: k3s: ELF binary /usr/local/bin/k3s has relocations in
.text [textrel]

That warning has actually been around for a while.

```
See k3s service start logs here: https://pastebin.com/uXvsjPFu
I have tried a more recent version of k3s 1.22.8 with a small change and

this version of the k3s starts successfully.

However, I did not manage to update all k3s build dependency sources from

the recipes-container/k3s/src_uri.inc.

I have built the k3s with this change: https://pastebin.com/3QGvcqta

Could you update the k3s recipe on the master branch, to build a more recent

version 1.23 or 1.24?

I have a 1.24 update already underway. So hopefully things will be
sorted out shortly.

Do you have an ETA for this?

I ran into some really nasty runtime issues, along with build issues,
so I'm now on the 4th micro bump to deal with problems.

There was also a week of squashing buildpath issues in oe-core that
slowed things down.

I have an arbitrary deadline of M3 for these sorts of updates, so that
is the goal and one that is quickly approaching!

Bruce

--
Diego Sueiro

Bruce

Thanks,

Kamil Dzieżyk

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

On Wed, Jul 27, 2022 at 3:15 AM Vasileios Anagnostopoulos
<vasileios.anagnostopoulos@...> wrote:

Hello Everyone,



I was wondering what is the general workflow for updating the golang projects (e.g. k3s, nerdctl, etc)?

Right now, at least for the project / official branches, it is
something that I do in the M3 timeframe of the release :) Experience
has shown that I need to batch the dependencies, and do a significant
level of testing to get things functional.

I have some changes already queued on master-next, with more to come
in the upcoming weeks. I have a talk at Embedded Linux Europe that
uses the components as well, so that drives the timeline as well.

For smaller updates (i.e. CVEs, etc), then bumps of the individual
SRCREVs in the giant SRC_URI can be manually done, since they are more
contained. Larger updates can of course also be done like this, but
that is definitely more effort iterating the SRCREVs.

In the mailing list, there was [a reference for a tool](https://lists.yoctoproject.org/g/meta-virtualization/message/7183?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3ACreated%2C%2Ck3s%2C20%2C2%2C0%2C82714461), but I could not located it. Is it still WIP or is it located somewhere that I did not notice ?

The script still exists, but is still just in my sandbox, it blew up
spectacularly when I implemented some site mapping for the golang
bits, which meant manual fixups and a day or two of work. Which meant,
I wouldn't have time to both release it and help folks fight through
issues (It really isn't great quality yet) .. so that and there's only
a general consensus on the approach to these types of recipes (some
other generation/update integrations were released, but I haven't
tried them or had to close a look at them myself) .. and I didn't
want to confuse things more at the time those other efforts were
released.

I'm working through a K3S system level update right now, and have been
fixing more issues in the script and the recipe(s) .. with any luck,
the quality won't be so bad (and the curse words removed), once I'm
through that :P

Bruce

Thank you in advance and kind regards,



Vasileios

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Hello,

I added the following line into local.conf to get the packages docker and docker-compose on Rapberry Pi (meta-raspberrypi) with the branch kirkstone.

# Virtualization
DISTRO_FEATURES:append = " virtualization"
IMAGE_INSTALL:append = " docker-ce"
IMAGE_INSTALL:append = " python3-docker-compose”
# IMAGE_INSTALL:append = " python3-distutils"

However, due to python3-distutils deprecated as of Python3.10, I got the following error.

raspberrypi3:~$ docker-compose
Traceback (most recent call last):
File "/usr/bin/docker-compose", line 5, in <module>
from compose.cli.main import main
File "/usr/lib/python3.10/site-packages/compose/cli/main.py", line 9, in <module>
from distutils.spawn import find_executable
ModuleNotFoundError: No module named ‘distutils’

Is there any workaround regarding this issue or am I missing some configuration?

Thanks in advance.

Regards,
Ibrahim ERTURK

Hi Bruce,

On Mon, Jun 27, 2022 at 01:51 PM, Bruce Ashfield wrote:

On Mon, Jun 27, 2022 at 6:00 AM Kamil Dzieżyk <Kamil.Dziezyk@...> wrote:

Hello Bruce,

There is a problem with the k3s service starting when the Yocto image is

built with the meta-virtualization master branch.

This issue might be related to the go-lang version(1.18) used to build the

k3s.

After this patch was merged:

https://git.yoctoproject.org/poky/commit/?id=8dc1f28aa10c775e64b5275679b1f8142e8cd038

a warning pops up during the k3s build:
```
WARNING: k3s-v1.22.6+k3s1+git4262c6b91a43ef8411870f72ff8b8715949f90e2-r0

do_package_qa: QA Issue: k3s: ELF binary /usr/local/bin/k3s has relocations in
.text [textrel]

That warning has actually been around for a while.

```
See k3s service start logs here: https://pastebin.com/uXvsjPFu
I have tried a more recent version of k3s 1.22.8 with a small change and

this version of the k3s starts successfully.

However, I did not manage to update all k3s build dependency sources from

the recipes-container/k3s/src_uri.inc.

I have built the k3s with this change: https://pastebin.com/3QGvcqta

Could you update the k3s recipe on the master branch, to build a more recent

version 1.23 or 1.24?

I have a 1.24 update already underway. So hopefully things will be
sorted out shortly.

Do you have an ETA for this?

--
Diego Sueiro

Bruce

Thanks,

Kamil Dzieżyk

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

From: Changqing Li <changqing.li@...>

Signed-off-by: Changqing Li <changqing.li@...>
---
recipes-containers/criu/criu_git.bb | 6 +--
...001-criu-Skip-documentation-install.patch} | 14 +++---
...-Change-libraries-install-directory.patch} | 16 ++++---
...write-install-lib-to-allow-multiarc.patch} | 12 ++---
...-building-on-newest-glibc-and-kernel.patch | 45 -------------------
5 files changed, 27 insertions(+), 66 deletions(-)
rename recipes-containers/criu/files/{0002-criu-Skip-documentation-install.patch => 0001-criu-Skip-documentation-install.patch} (66%)
rename recipes-containers/criu/files/{0001-criu-Change-libraries-install-directory.patch => 0002-criu-Change-libraries-install-directory.patch} (83%)
rename recipes-containers/criu/files/{lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch => 0003-lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch} (79%)
delete mode 100644 recipes-containers/criu/files/fix-building-on-newest-glibc-and-kernel.patch

diff --git a/recipes-containers/criu/criu_git.bb b/recipes-containers/criu/criu_git.bb
index 4b616cc..f5ae514 100644
--- a/recipes-containers/criu/criu_git.bb
+++ b/recipes-containers/criu/criu_git.bb
@@ -17,9 +17,9 @@ SRCREV = "4f8f295e57e68740699479d12c1ad251e6dd859f"
PV = "3.17+git${SRCPV}"

SRC_URI = "git://github.com/checkpoint-restore/criu.git;branch=master;protocol=https \
- file://0002-criu-Skip-documentation-install.patch \
- file://0001-criu-Change-libraries-install-directory.patch \
- file://lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch \
+ file://0001-criu-Skip-documentation-install.patch \
+ file://0002-criu-Change-libraries-install-directory.patch \
+ file://0003-lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch \
"

COMPATIBLE_HOST = "(x86_64|arm|aarch64).*-linux"
diff --git a/recipes-containers/criu/files/0002-criu-Skip-documentation-install.patch b/recipes-containers/criu/files/0001-criu-Skip-documentation-install.patch
similarity index 66%
rename from recipes-containers/criu/files/0002-criu-Skip-documentation-install.patch
rename to recipes-containers/criu/files/0001-criu-Skip-documentation-install.patch
index af45db7..43e2704 100644
--- a/recipes-containers/criu/files/0002-criu-Skip-documentation-install.patch
+++ b/recipes-containers/criu/files/0001-criu-Skip-documentation-install.patch
@@ -1,22 +1,21 @@
-From 45d74ae8a314c481398ba91a3697ffbd074cd98b Mon Sep 17 00:00:00 2001
+From 485e957a4c3289d105dd6203af31c0e4e1438ac6 Mon Sep 17 00:00:00 2001
From: Jianchuan Wang <jianchuan.wang@...>
Date: Tue, 16 Aug 2016 09:42:24 +0800
-Subject: [PATCH] criu: Skip documentation install
+Subject: [PATCH 1/3] criu: Skip documentation install

asciidoc is needed to generate CRIU documentation, so skip it in install.

Signed-off-by: Jianchuan Wang <jianchuan.wang@...>
-
---
Makefile.install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.install b/Makefile.install
-index 3987bcc..1def3cf 100644
+index aafb95469..1b02b70af 100644
--- a/Makefile.install
+++ b/Makefile.install
-@@ -29,7 +29,7 @@ export PREFIX BINDIR SBINDIR MANDIR RUNDIR
- export LIBDIR INCLUDEDIR LIBEXECDIR
+@@ -30,7 +30,7 @@ export PREFIX BINDIR SBINDIR MANDIR RUNDIR
+ export LIBDIR INCLUDEDIR LIBEXECDIR PLUGINDIR

install-man:
- $(Q) $(MAKE) -C Documentation install
@@ -24,3 +23,6 @@ index 3987bcc..1def3cf 100644
.PHONY: install-man

install-lib: lib
+--
+2.25.1
+
diff --git a/recipes-containers/criu/files/0001-criu-Change-libraries-install-directory.patch b/recipes-containers/criu/files/0002-criu-Change-libraries-install-directory.patch
similarity index 83%
rename from recipes-containers/criu/files/0001-criu-Change-libraries-install-directory.patch
rename to recipes-containers/criu/files/0002-criu-Change-libraries-install-directory.patch
index afb1332..453be13 100644
--- a/recipes-containers/criu/files/0001-criu-Change-libraries-install-directory.patch
+++ b/recipes-containers/criu/files/0002-criu-Change-libraries-install-directory.patch
@@ -1,25 +1,25 @@
-From f64fbca70e6049dad3c404d871f2383d97725d2d Mon Sep 17 00:00:00 2001
+From dcbf7f8ad1b07ff718eac2ce79ed522ac1cee189 Mon Sep 17 00:00:00 2001
From: Mark Asselstine <mark.asselstine@...>
Date: Fri, 8 Sep 2017 15:11:31 -0400
-Subject: [PATCH] criu: Change libraries install directory
+Subject: [PATCH 2/3] criu: Change libraries install directory

Install the libraries into /usr/lib(or /usr/lib64)

Signed-off-by: Jianchuan Wang <jianchuan.wang@...>
Signed-off-by: Mark Asselstine <mark.asselstine@...>
-
---
Makefile.install | 13 -------------
1 file changed, 13 deletions(-)

diff --git a/Makefile.install b/Makefile.install
-index 1def3cf..d020eef 100644
+index 1b02b70af..2839ef5fe 100644
--- a/Makefile.install
+++ b/Makefile.install
@@ -9,19 +9,6 @@ LIBEXECDIR ?= $(PREFIX)/libexec
RUNDIR ?= /run
+ PLUGINDIR ?= /var/lib/criu

- #
+-#
-# For recent Debian/Ubuntu with multiarch support.
-DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH 2>/dev/null)
-ifneq "$(DEB_HOST_MULTIARCH)" ""
@@ -32,7 +32,9 @@ index 1def3cf..d020eef 100644
- endif
-endif
-
--#
+ #
# LIBDIR falls back to the standard path.
LIBDIR ?= $(PREFIX)/lib
-
+--
+2.25.1
+
diff --git a/recipes-containers/criu/files/lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch b/recipes-containers/criu/files/0003-lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch
similarity index 79%
rename from recipes-containers/criu/files/lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch
rename to recipes-containers/criu/files/0003-lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch
index 70ccb28..210fbe7 100644
--- a/recipes-containers/criu/files/lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch
+++ b/recipes-containers/criu/files/0003-lib-Makefile-overwrite-install-lib-to-allow-multiarc.patch
@@ -1,23 +1,22 @@
-From 6caf90592d61c8c45b32cb7ff76709f9326030e2 Mon Sep 17 00:00:00 2001
+From 0a04c5bc80319485e17e9a86e799fe2c5bfa3d38 Mon Sep 17 00:00:00 2001
From: Mark Asselstine <mark.asselstine@...>
Date: Fri, 8 Sep 2017 15:40:49 -0400
-Subject: [PATCH] lib/Makefile: overwrite install-lib, to allow multiarch
+Subject: [PATCH 3/3] lib/Makefile: overwrite install-lib, to allow multiarch

I am not sure why Yocto installs python modules in arch specific
/usr/libXX directories but it does. Allow the recipe to pass this via
INSTALL_LIB.

Signed-off-by: Mark Asselstine <mark.asselstine@...>
-
---
lib/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Makefile b/lib/Makefile
-index b1bb057..06f5c5d 100644
+index 575a7bad3..f503d430b 100644
--- a/lib/Makefile
+++ b/lib/Makefile
-@@ -53,7 +53,7 @@ install: lib-c lib-py crit/crit lib/c/criu.pc.in
+@@ -59,7 +59,7 @@ install: lib-c lib-a lib-py crit/crit lib/c/criu.pc.in
$(Q) sed -e 's,@version@,$(CRIU_VERSION),' -e 's,@libdir@,$(LIBDIR),' -e 's,@includedir@,$(dir $(INCLUDEDIR)/criu/),' lib/c/criu.pc.in > lib/c/criu.pc
$(Q) install -m 644 lib/c/criu.pc $(DESTDIR)$(LIBDIR)/pkgconfig
$(E) " INSTALL " crit
@@ -26,3 +25,6 @@ index b1bb057..06f5c5d 100644
.PHONY: install

uninstall:
+--
+2.25.1
+
diff --git a/recipes-containers/criu/files/fix-building-on-newest-glibc-and-kernel.patch b/recipes-containers/criu/files/fix-building-on-newest-glibc-and-kernel.patch
deleted file mode 100644
index 9361adc..0000000
--- a/recipes-containers/criu/files/fix-building-on-newest-glibc-and-kernel.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-From b59947007362b53e9f41f1e5a33071dedf1c59ac Mon Sep 17 00:00:00 2001
-From: Adrian Reber <areber@...>
-Date: Thu, 28 Sep 2017 09:13:33 +0000
-Subject: [PATCH] fix building on newest glibc and kernel
-
-On Fedora rawhide with kernel-headers-4.14.0-0.rc2.git0.1.fc28.x86_64
-glibc-devel-2.26.90-15.fc28.x86_64 criu does not build any more:
-
-In file included from /usr/include/linux/aio_abi.h:31:0,
- from criu/cr-check.c:24:
-/usr/include/sys/mount.h:35:3: error: expected identifier before numeric constant
- MS_RDONLY = 1, /* Mount read-only. */
- ^
-make[2]: *** [/builddir/build/BUILD/criu-3.5/scripts/nmk/scripts/build.mk:111: criu/cr-check.o] Error 1
-make[1]: *** [criu/Makefile:73: criu/built-in.o] Error 2
-make: *** [Makefile:233: criu] Error 2
-
-This simple re-ordering of includes fixes it for me.
-
-Signed-off-by: Adrian Reber <areber@...>
-Signed-off-by: Andrei Vagin <avagin@...>
-
-Upstream-Status: Backport
-[https://github.com/checkpoint-restore/criu/commit/f41e386d4d40e3e26b0cfdc85a812b7edb337f1d#diff-cc847b1cc975358c6582595be92d48db]
-
-Signed-off-by: Yi Zhao <yi.zhao@...>
-
----
- criu/cr-check.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/criu/cr-check.c b/criu/cr-check.c
-index 1dd887a..93df2ab 100644
---- a/criu/cr-check.c
-+++ b/criu/cr-check.c
-@@ -21,8 +21,8 @@
- #include <netinet/in.h>
- #include <sys/prctl.h>
- #include <sched.h>
--#include <linux/aio_abi.h>
- #include <sys/mount.h>
-+#include <linux/aio_abi.h>
-
- #include "../soccr/soccr.h"
-
--
2.25.1

merged.

Bruce

In message: [meta-virtualization][PATCH] xen-image-minimal: reduce the x86 wic build dependencies
on 18/07/2022 Christopher Clark wrote:

On Tue, Jul 19, 2022 at 9:52 PM Chen, Qi <Qi.Chen@...> wrote:

Hi Bruce,

I just checked the commits on master-next. Hope everything is going well.
I also found two typos in the staged commits.

d73932c runc-docker: update to 1.3.3
f21dd94 runc: update to 1.3.3

The version should be '1.1.3' instead of '1.3.3'.

My scripts appear to have gotten the upgrade wrong, i fixed them manually.

As for the other upgrades, they are still under test as I'm having
some system level integration issues. But hopefully that is resolved
soon.

Bruce

Regards,
Qi
________________________________
From: Bruce Ashfield <bruce.ashfield@...>
Sent: Thursday, July 7, 2022 22:57
To: Chen, Qi <Qi.Chen@...>
Cc: meta-virtualization@... <meta-virtualization@...>
Subject: Re: [meta-virtualization][master][kirkstone][PATCH] containerd: upgrade to 1.6.6

I have a batched set of package updates pending, I've pushed
them to master-next, with more to come in the next few days.

Once I merge them to master, I'll cherry-pick the equivalent
update to this to kirkstone.

Bruce

In message: [meta-virtualization][master][kirkstone][PATCH] containerd: upgrade to 1.6.6
on 06/07/2022 Chen Qi wrote:

Signed-off-by: Chen Qi <Qi.Chen@...>
---
.../containerd/containerd-opencontainers_git.bb | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-containers/containerd/containerd-opencontainers_git.bb b/recipes-containers/containerd/containerd-opencontainers_git.bb
index b0f92b12..c28b1510 100644
--- a/recipes-containers/containerd/containerd-opencontainers_git.bb
+++ b/recipes-containers/containerd/containerd-opencontainers_git.bb
@@ -5,7 +5,7 @@ DESCRIPTION = "containerd is a daemon to control runC, built for performance and
support as well as checkpoint and restore for cloning and live migration of containers."


-SRCREV = "d12516713c315ea9e651eb1df89cf32ff7c8137c"
+SRCREV = "10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1"
SRC_URI = "git://github.com/containerd/containerd;branch=release/1.6;protocol=https \
file://0001-Add-build-option-GODEBUG-1.patch \
file://0001-Makefile-allow-GO_BUILD_FLAGS-to-be-externally-speci.patch \
@@ -15,8 +15,8 @@ SRC_URI = "git://github.com/containerd/containerd;branch=release/1.6;protocol=ht
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=1269f40c0d099c21a871163984590d89"

-CONTAINERD_VERSION = "v1.6.1"
-CVE_VERSION = "1.6.1"
+CONTAINERD_VERSION = "v1.6.6"
+CVE_VERSION = "1.6.6"

EXTRA_OEMAKE += "GODEBUG=1"

@@ -56,7 +56,7 @@ do_compile() {
metrics filters identifiers labels leases plugin server services \
cmd cio containers namespaces oci events log reaper sys rootfs nvidia seed apparmor seccomp \
cap cri userns atomic ioutil os registrar seutil runtimeoptions netns \
- shutdown schedcore tracing; do
+ shutdown schedcore tracing kmutex; do
if [ -d ${S}/src/import/${c} ]; then
ln -sfn ${S}/src/import/${c} ${S}/src/import/vendor/github.com/containerd/containerd/${c}
fi
--
2.37.0

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

The Xen image recipe provides a default WKS_FILE for x86 builds to enable
booting the image either in qemu or directly on hardware. Add settings
for WKS_FILE_DEFAULT_DEPENDS that specify the wic image build
dependencies, which are lower than the defaults used without it.

This change reduces the amount of build resources required for CI of
this image and images that are derived from it.

Since WKS_FILE is specified separately for x86-64 and qemux86-64
overrides, do the same for WKS_FILE_DEFAULT_DEPENDS, even though the
dependencies for the two separate WKS_FILEs are currently the same.

Signed-off-by: Christopher Clark <christopher.w.clark@...>
---
recipes-extended/images/xen-image-minimal.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-extended/images/xen-image-minimal.bb b/recipes-extended/images/xen-image-minimal.bb
index a8e72d1..ec0f2f5 100644
--- a/recipes-extended/images/xen-image-minimal.bb
+++ b/recipes-extended/images/xen-image-minimal.bb
@@ -79,7 +79,9 @@ build_syslinux_cfg () {

# Enable runqemu. eg: runqemu xen-image-minimal nographic slirp
WKS_FILE:x86-64 = "directdisk-xen.wks"
+WKS_FILE_DEPENDS_DEFAULT:x86-64 = "syslinux-native"
WKS_FILE:qemux86-64 = "qemuboot-xen-x86-64.wks"
+WKS_FILE_DEPENDS_DEFAULT:qemux86-64 = "syslinux-native"
QB_MEM ?= "-m 400"
QB_DEFAULT_KERNEL ?= "none"
QB_DEFAULT_FSTYPE ?= "wic"
--
2.25.1

On Mon, Jul 18, 2022 at 7:51 AM Anagnostopoulos, Vasileios
<vasileios.anagnostopoulos@...> wrote:

Hello Bruce,

Thank you for merging the changes for the image-oci-umoci in the master branch! I was wondering, if it makes sense to also back port these changes to the kirkstone branch? If yes, should I send new patches for the kirkostone branch?

I can do cherry picks. the tag change could easily be described as a
bug fix (since I did have other tag support already in sloci), the
stop signal is technically a "new feature", which I avoid backporting
.. but it is a new feature with no ability to impact existing
functionality.

To summarize the rambling first paragraph, I can cherry pick the two
changes to kirkstone :)

Bruce

Vasileios

-----Original Message-----
From: meta-virtualization@... <meta-virtualization@...> On Behalf Of Vasileios Anagnostopoulos via lists.yoctoproject.org
Sent: Thursday, 14 July 2022 08:50
To: Bruce Ashfield <bruce.ashfield@...>
Cc: meta-virtualization@...
Subject: Re: [meta-virtualization] [PATCH 3/3] image-oci-umoci: skip parent directory in tar

Hello Bruce,

Ok. Thank you for the extra info! Let me know if I can help in any way.

Vasileios

-----Original Message-----
From: Bruce Ashfield <bruce.ashfield@...>
Sent: Wednesday, 13 July 2022 22:37
To: Anagnostopoulos, Vasileios (SI BP R&D ZG FW ITW) <vasileios.anagnostopoulos@...>
Cc: meta-virtualization@...
Subject: Re: [meta-virtualization] [PATCH 3/3] image-oci-umoci: skip parent directory in tar

On Wed, Jul 13, 2022 at 3:19 AM Vasileios Anagnostopoulos <vasileios.anagnostopoulos@...> wrote:

Hello Bruce,

How do you generate the images and import them? Could you describe a bit more the use case?

With podman for example you can load the image by using `podman load
-i
build-oci/tmp/deploy/images/capricorn-64/name-of-the-image-capricorn-6
4-20220713063601.rootfs.tar`

Usually, the tools that support the oci image format also support the oci-archive image format. An exception is docker that does not support the oci image format and I have first to transform it using skopeo.

What is the advantage of first un-taring the image and then doing the import?

There's no advantage, it's just the support for the OCI image format when I added it, was around the oci image, not the oci-archive, and it was designed around oci-image-tools, runc, and directly executing / manipulating the images. The tgz version was something I added after, to make it easier to copy them around, stage them, and otherwise collect artifacts. docker, podman or any other specific runtime wasn't the target.

skopeo was from the beginning the tool that was used to copy/import the images, and that was with the oci: type .. not with the tarballs .. in those flows as well.

I'm just pondering the right way to not break existing layouts and flows, and that will take me a bit longer.

Probably the other 2 patches that I send it with this one (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fg%2Fmeta-virtualization%2Fmessage%2F7442&;data=05%7C01%7Cvasileios.anagnostopoulos%40siemens.com%7C45180cb757f947e2f63008da656510d4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637933782366613603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=OnmF%2BmqKwRl0uBfYVswDG7Ko3f62BOMwFyzqQ3zOwjU%3D&amp;reserved=0, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Fg%2Fmeta-virtualization%2Fmessage%2F7441&;data=05%7C01%7Cvasileios.anagnostopoulos%40siemens.com%7C45180cb757f947e2f63008da656510d4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637933782366613603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=%2Bo56q8uJz5WdxSdKh3rzpdw4n9EguCgbgihXmlNPBIM%3D&amp;reserved=0) are still relevant, because they are fixing other minor issues.

Yep, I still have those tagged in my "to-review" and "to-test" queues.

Cheers,

Bruce

Vasileios

--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Hello Bruce,

Thank you for merging the changes for the image-oci-umoci in the master branch! I was wondering, if it makes sense to also back port these changes to the kirkstone branch? If yes, should I send new patches for the kirkostone branch?

Vasileios