The libseccomp package is only available if seccomp is in DISTRO_FEATURES.

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
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 9dcb21c..351f38b 100644
--- a/recipes-containers/podman/podman_git.bb
+++ b/recipes-containers/podman/podman_git.bb
@@ -6,6 +6,9 @@ DESCRIPTION = "Podman is a daemonless container engine for developing, \
`alias docker=podman`. \
"

+inherit features_check
+REQUIRED_DISTRO_FEATURES ?= "seccomp"
+
DEPENDS = " \
go-metalinter-native \
go-md2man-native \
--
2.17.1

What branch are you working with ?

Now that seccomp is in core, we no longer have those restrictions, so
I assume this is on an older branch ?

Bruce

--
- 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 Thu, Jun 24, 2021 at 3:45 PM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

What branch are you working with ?

Now that seccomp is in core, we no longer have those restrictions, so
I assume this is on an older branch ?

aha. never mind, I misread the change.

That being said, I honestly think this is a bug. If the main
libseccomp is dependent on a distro feature, each and every recipe
that has a hard dependency on it, should not have to do the distro
check.

so for now, I'm going to not apply these while I look for a better method.

Bruce

Bruce

On Thu, Jun 24, 2021 at 3:00 PM Diego Sueiro <diego.sueiro@...> wrote:

The libseccomp package is only available if seccomp is in DISTRO_FEATURES.

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
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 9dcb21c..351f38b 100644
--- a/recipes-containers/podman/podman_git.bb
+++ b/recipes-containers/podman/podman_git.bb
@@ -6,6 +6,9 @@ DESCRIPTION = "Podman is a daemonless container engine for developing, \
`alias docker=podman`. \
"

+inherit features_check
+REQUIRED_DISTRO_FEATURES ?= "seccomp"
+
DEPENDS = " \
go-metalinter-native \
go-md2man-native \
--
2.17.1

--
- 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 Thu, Jun 24, 2021 at 5:01 PM Martin Jansa <martin.jansa@...> wrote:

This change is correct, libseccomp still requires seccomp in DISTRO_FEATURES, so anything depending on it should have the same restriction.

Right, I understand how/why it works like this .. but it is super
clunky when we can't just depend on something that is now in core,
without needing to sprinkle distro checks everywhere.

As the list of recipes gets larger with that check, it really isn't an
optional distro feature for using meta virt at all, and it would be
nice if we could just do the check once and be done with it.

Bruce

seccomp is now in default DISTRO_FEATURES, but not through BACKFILL feature, so many existing DISTROs didn't get it automatically added and requiring it is the right way to automatically skip such recipes.

On Thu, Jun 24, 2021 at 12:45 PM Bruce Ashfield <bruce.ashfield@...> wrote:

What branch are you working with ?

Now that seccomp is in core, we no longer have those restrictions, so
I assume this is on an older branch ?

Bruce

On Thu, Jun 24, 2021 at 3:00 PM Diego Sueiro <diego.sueiro@...> wrote:

The libseccomp package is only available if seccomp is in DISTRO_FEATURES.

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
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 9dcb21c..351f38b 100644
--- a/recipes-containers/podman/podman_git.bb
+++ b/recipes-containers/podman/podman_git.bb
@@ -6,6 +6,9 @@ DESCRIPTION = "Podman is a daemonless container engine for developing, \
`alias docker=podman`. \
"

+inherit features_check
+REQUIRED_DISTRO_FEATURES ?= "seccomp"
+
DEPENDS = " \
go-metalinter-native \
go-md2man-native \
--
2.17.1

--
- 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 Fri, Jun 25, 2021 at 4:11 AM Diego Sueiro <Diego.Sueiro@...> wrote:

-----Original Message-----
From: Bruce Ashfield <bruce.ashfield@...>
Sent: 25 June 2021 03:49
To: Martin Jansa <martin.jansa@...>
Cc: Diego Sueiro <Diego.Sueiro@...>; meta-
virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization][PATCH 1/3] podman: Add seccomp as
REQUIRED_DISTRO_FEATURES

On Thu, Jun 24, 2021 at 5:01 PM Martin Jansa <martin.jansa@...>
wrote:

This change is correct, libseccomp still requires seccomp in

DISTRO_FEATURES, so anything depending on it should have the same
restriction.

Right, I understand how/why it works like this .. but it is super clunky when we
can't just depend on something that is now in core, without needing to
sprinkle distro checks everywhere.

As the list of recipes gets larger with that check, it really isn't an optional distro
feature for using meta virt at all, and it would be nice if we could just do the
check once and be done with it.

Just a side note that these patches fix issues with yocto-check-layer.

I've disagreed with check-layer before (and we've changed how it works)

That being said, the layer is checked on the AB, and Richard hasn't
reported any issues. So clearly there's something wrong with the AB
test or with something else.

Bruce

Diego

Bruce

seccomp is now in default DISTRO_FEATURES, but not through BACKFILL

feature, so many existing DISTROs didn't get it automatically added and
requiring it is the right way to automatically skip such recipes.

On Thu, Jun 24, 2021 at 12:45 PM Bruce Ashfield

<bruce.ashfield@...> wrote:

What branch are you working with ?

Now that seccomp is in core, we no longer have those restrictions, so
I assume this is on an older branch ?

Bruce

On Thu, Jun 24, 2021 at 3:00 PM Diego Sueiro <diego.sueiro@...>

wrote:

The libseccomp package is only available if seccomp is in

DISTRO_FEATURES.

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
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 9dcb21c..351f38b 100644
--- a/recipes-containers/podman/podman_git.bb
+++ b/recipes-containers/podman/podman_git.bb
@@ -6,6 +6,9 @@ DESCRIPTION = "Podman is a daemonless container

engine for developing, \

`alias docker=podman`. \
"

+inherit features_check
+REQUIRED_DISTRO_FEATURES ?= "seccomp"
+
DEPENDS = " \
go-metalinter-native \
go-md2man-native \
--
2.17.1

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

--
- 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 Fri, 2021-06-25 at 08:46 -0400, Bruce Ashfield wrote:

On Fri, Jun 25, 2021 at 4:11 AM Diego Sueiro <Diego.Sueiro@...> wrote:

-----Original Message-----
From: Bruce Ashfield <bruce.ashfield@...>
Sent: 25 June 2021 03:49
To: Martin Jansa <martin.jansa@...>
Cc: Diego Sueiro <Diego.Sueiro@...>; meta-
virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization][PATCH 1/3] podman: Add seccomp as
REQUIRED_DISTRO_FEATURES

On Thu, Jun 24, 2021 at 5:01 PM Martin Jansa <martin.jansa@...>
wrote:

This change is correct, libseccomp still requires seccomp in

DISTRO_FEATURES, so anything depending on it should have the same
restriction.

Right, I understand how/why it works like this .. but it is super clunky when we
can't just depend on something that is now in core, without needing to
sprinkle distro checks everywhere.

As the list of recipes gets larger with that check, it really isn't an optional distro
feature for using meta virt at all, and it would be nice if we could just do the
check once and be done with it.

Just a side note that these patches fix issues with yocto-check-layer.

I've disagreed with check-layer before (and we've changed how it works)

That being said, the layer is checked on the AB, and Richard hasn't
reported any issues. So clearly there's something wrong with the AB
test or with something else.

https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/110

Says green...

Obviously we just tweak the css :)

Cheers,

Richard

On Fri, Jun 25, 2021 at 10:16 AM Diego Sueiro <Diego.Sueiro@...> wrote:

I was getting the following when passing `--machines mymachine`:
```
ERROR: Nothing PROVIDES 'libseccomp' (but meta-virtualization/recipes-containers/podman/podman_git.bb, meta-virtualization/recipes-networking/slirp4netns/slirp4netns_0.4.1.bb DEPENDS on or otherwise requires it)

libseccomp was skipped: missing required distro feature 'seccomp' (not in DISTRO_FEATURES)
```



In a deeper investigation I found that the way mymachine was setting the DISTRO_FEATURES (with `+=`) it was preventing the inclusion of the `DISTRO_FEATURES_DEFAULT`



But still, since in `meta/recipes-support/libseccomp/libseccomp_2.5.1.bb` we have `REQUIRED_DISTRO_FEATURES = "seccomp"` don’t we need to add this check on the recipes that depends on it?
In a quick grep on meta-virt, I suppose that if this is the case, we will also need to update for cri-o_git.bb and crun_git.bb recipes.

Yes .. exactly :D

Or we can just remove `REQUIRED_DISTRO_FEATURES = "seccomp"` from `meta/recipes-support/libseccomp/libseccomp_2.5.1.bb`?

That is the core of what I was asking. A package that is now in core,
why is it only enabled by a distro feature ?

That is causing the proliferation of checks in meta-virt (and other
layers as well). With CNCF, seccomp is becoming required for proper
operation on many different runtimes, so it really isn't optional.

I was hoping for something centralized in the layer, but that of
course forces seccomp on kvm/lxc/xen and other use cases that still
(but I bet they will) don't need seccomp.

Alternatively, I was thinking the core distro feature could drop, or
that a backfill could be used .. but neither of those solve the short
term issue with a no-seccomp distro.

So I'm coming up empty in my search for something better, and will
likely just apply the patch and continue to see about those other
options.

Bruce

--

Diego



From: Martin Jansa <martin.jansa@...>
Sent: 25 June 2021 13:49
To: Bruce Ashfield <bruce.ashfield@...>
Cc: Diego Sueiro <Diego.Sueiro@...>; meta-virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization][PATCH 1/3] podman: Add seccomp as REQUIRED_DISTRO_FEATURES



AB would use the new default DISTRO_FEATURES which already contain seccomp.



On Fri, Jun 25, 2021 at 2:46 PM Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Jun 25, 2021 at 4:11 AM Diego Sueiro <Diego.Sueiro@...> wrote:

-----Original Message-----
From: Bruce Ashfield <bruce.ashfield@...>
Sent: 25 June 2021 03:49
To: Martin Jansa <martin.jansa@...>
Cc: Diego Sueiro <Diego.Sueiro@...>; meta-
virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization][PATCH 1/3] podman: Add seccomp as
REQUIRED_DISTRO_FEATURES

On Thu, Jun 24, 2021 at 5:01 PM Martin Jansa <martin.jansa@...>
wrote:

This change is correct, libseccomp still requires seccomp in

DISTRO_FEATURES, so anything depending on it should have the same
restriction.

Right, I understand how/why it works like this .. but it is super clunky when we
can't just depend on something that is now in core, without needing to
sprinkle distro checks everywhere.

As the list of recipes gets larger with that check, it really isn't an optional distro
feature for using meta virt at all, and it would be nice if we could just do the
check once and be done with it.

Just a side note that these patches fix issues with yocto-check-layer.

I've disagreed with check-layer before (and we've changed how it works)

That being said, the layer is checked on the AB, and Richard hasn't
reported any issues. So clearly there's something wrong with the AB
test or with something else.



Bruce

Diego

Bruce

seccomp is now in default DISTRO_FEATURES, but not through BACKFILL

feature, so many existing DISTROs didn't get it automatically added and
requiring it is the right way to automatically skip such recipes.

On Thu, Jun 24, 2021 at 12:45 PM Bruce Ashfield

<bruce.ashfield@...> wrote:

What branch are you working with ?

Now that seccomp is in core, we no longer have those restrictions, so
I assume this is on an older branch ?

Bruce

On Thu, Jun 24, 2021 at 3:00 PM Diego Sueiro <diego.sueiro@...>

wrote:

The libseccomp package is only available if seccomp is in

DISTRO_FEATURES.

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
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 9dcb21c..351f38b 100644
--- a/recipes-containers/podman/podman_git.bb
+++ b/recipes-containers/podman/podman_git.bb
@@ -6,6 +6,9 @@ DESCRIPTION = "Podman is a daemonless container

engine for developing, \

`alias docker=podman`. \
"

+inherit features_check
+REQUIRED_DISTRO_FEATURES ?= "seccomp"
+
DEPENDS = " \
go-metalinter-native \
go-md2man-native \
--
2.17.1

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

--
- 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 Fri, Jun 25, 2021 at 11:18 AM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

On Fri, Jun 25, 2021 at 10:16 AM Diego Sueiro <Diego.Sueiro@...> wrote:

I was getting the following when passing `--machines mymachine`:
```
ERROR: Nothing PROVIDES 'libseccomp' (but meta-virtualization/recipes-containers/podman/podman_git.bb, meta-virtualization/recipes-networking/slirp4netns/slirp4netns_0.4.1.bb DEPENDS on or otherwise requires it)

libseccomp was skipped: missing required distro feature 'seccomp' (not in DISTRO_FEATURES)
```



In a deeper investigation I found that the way mymachine was setting the DISTRO_FEATURES (with `+=`) it was preventing the inclusion of the `DISTRO_FEATURES_DEFAULT`



But still, since in `meta/recipes-support/libseccomp/libseccomp_2.5.1.bb` we have `REQUIRED_DISTRO_FEATURES = "seccomp"` don’t we need to add this check on the recipes that depends on it?
In a quick grep on meta-virt, I suppose that if this is the case, we will also need to update for cri-o_git.bb and crun_git.bb recipes.

Yes .. exactly :D

Or we can just remove `REQUIRED_DISTRO_FEATURES = "seccomp"` from `meta/recipes-support/libseccomp/libseccomp_2.5.1.bb`?

That is the core of what I was asking. A package that is now in core,
why is it only enabled by a distro feature ?

And for clarity, I realize that the systemd recipe checks for the
systemd distro feature .. so that is similar. But systemd is one of
many init managers, so I can see why it is used.

Bruce

That is causing the proliferation of checks in meta-virt (and other
layers as well). With CNCF, seccomp is becoming required for proper
operation on many different runtimes, so it really isn't optional.

I was hoping for something centralized in the layer, but that of
course forces seccomp on kvm/lxc/xen and other use cases that still
(but I bet they will) don't need seccomp.

Alternatively, I was thinking the core distro feature could drop, or
that a backfill could be used .. but neither of those solve the short
term issue with a no-seccomp distro.

So I'm coming up empty in my search for something better, and will
likely just apply the patch and continue to see about those other
options.

Bruce

--

Diego



From: Martin Jansa <martin.jansa@...>
Sent: 25 June 2021 13:49
To: Bruce Ashfield <bruce.ashfield@...>
Cc: Diego Sueiro <Diego.Sueiro@...>; meta-virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization][PATCH 1/3] podman: Add seccomp as REQUIRED_DISTRO_FEATURES



AB would use the new default DISTRO_FEATURES which already contain seccomp.



On Fri, Jun 25, 2021 at 2:46 PM Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Jun 25, 2021 at 4:11 AM Diego Sueiro <Diego.Sueiro@...> wrote:

-----Original Message-----
From: Bruce Ashfield <bruce.ashfield@...>
Sent: 25 June 2021 03:49
To: Martin Jansa <martin.jansa@...>
Cc: Diego Sueiro <Diego.Sueiro@...>; meta-
virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization][PATCH 1/3] podman: Add seccomp as
REQUIRED_DISTRO_FEATURES

On Thu, Jun 24, 2021 at 5:01 PM Martin Jansa <martin.jansa@...>
wrote:

This change is correct, libseccomp still requires seccomp in

DISTRO_FEATURES, so anything depending on it should have the same
restriction.

Right, I understand how/why it works like this .. but it is super clunky when we
can't just depend on something that is now in core, without needing to
sprinkle distro checks everywhere.

As the list of recipes gets larger with that check, it really isn't an optional distro
feature for using meta virt at all, and it would be nice if we could just do the
check once and be done with it.

Just a side note that these patches fix issues with yocto-check-layer.

I've disagreed with check-layer before (and we've changed how it works)

That being said, the layer is checked on the AB, and Richard hasn't
reported any issues. So clearly there's something wrong with the AB
test or with something else.



Bruce

Diego

Bruce

seccomp is now in default DISTRO_FEATURES, but not through BACKFILL

feature, so many existing DISTROs didn't get it automatically added and
requiring it is the right way to automatically skip such recipes.

On Thu, Jun 24, 2021 at 12:45 PM Bruce Ashfield

<bruce.ashfield@...> wrote:

What branch are you working with ?

Now that seccomp is in core, we no longer have those restrictions, so
I assume this is on an older branch ?

Bruce

On Thu, Jun 24, 2021 at 3:00 PM Diego Sueiro <diego.sueiro@...>

wrote:

The libseccomp package is only available if seccomp is in

DISTRO_FEATURES.

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
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 9dcb21c..351f38b 100644
--- a/recipes-containers/podman/podman_git.bb
+++ b/recipes-containers/podman/podman_git.bb
@@ -6,6 +6,9 @@ DESCRIPTION = "Podman is a daemonless container

engine for developing, \

`alias docker=podman`. \
"

+inherit features_check
+REQUIRED_DISTRO_FEATURES ?= "seccomp"
+
DEPENDS = " \
go-metalinter-native \
go-md2man-native \
--
2.17.1

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

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

--
- 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 Fri, Jun 25, 2021 at 11:21 AM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

On Fri, Jun 25, 2021 at 11:18 AM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

On Fri, Jun 25, 2021 at 10:16 AM Diego Sueiro <Diego.Sueiro@...> wrote:

I was getting the following when passing `--machines mymachine`:
```
ERROR: Nothing PROVIDES 'libseccomp' (but meta-virtualization/recipes-containers/podman/podman_git.bb, meta-virtualization/recipes-networking/slirp4netns/slirp4netns_0.4.1.bb DEPENDS on or otherwise requires it)

libseccomp was skipped: missing required distro feature 'seccomp' (not in DISTRO_FEATURES)
```



In a deeper investigation I found that the way mymachine was setting the DISTRO_FEATURES (with `+=`) it was preventing the inclusion of the `DISTRO_FEATURES_DEFAULT`



But still, since in `meta/recipes-support/libseccomp/libseccomp_2.5.1.bb` we have `REQUIRED_DISTRO_FEATURES = "seccomp"` don’t we need to add this check on the recipes that depends on it?
In a quick grep on meta-virt, I suppose that if this is the case, we will also need to update for cri-o_git.bb and crun_git.bb recipes.

Yes .. exactly :D

Or we can just remove `REQUIRED_DISTRO_FEATURES = "seccomp"` from `meta/recipes-support/libseccomp/libseccomp_2.5.1.bb`?

That is the core of what I was asking. A package that is now in core,
why is it only enabled by a distro feature ?

And for clarity, I realize that the systemd recipe checks for the
systemd distro feature .. so that is similar. But systemd is one of
many init managers, so I can see why it is used.

I still don't have a better solution to this, and while I see about
getting seccomp behaviour changed in core, I can get this into the
tree.

I've added the extra seccomp dependent recipes and expect to merge
this on Wednesday.

Bruce

Bruce

That is causing the proliferation of checks in meta-virt (and other
layers as well). With CNCF, seccomp is becoming required for proper
operation on many different runtimes, so it really isn't optional.

I was hoping for something centralized in the layer, but that of
course forces seccomp on kvm/lxc/xen and other use cases that still
(but I bet they will) don't need seccomp.

Alternatively, I was thinking the core distro feature could drop, or
that a backfill could be used .. but neither of those solve the short
term issue with a no-seccomp distro.

So I'm coming up empty in my search for something better, and will
likely just apply the patch and continue to see about those other
options.

Bruce

--

Diego



From: Martin Jansa <martin.jansa@...>
Sent: 25 June 2021 13:49
To: Bruce Ashfield <bruce.ashfield@...>
Cc: Diego Sueiro <Diego.Sueiro@...>; meta-virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization][PATCH 1/3] podman: Add seccomp as REQUIRED_DISTRO_FEATURES



AB would use the new default DISTRO_FEATURES which already contain seccomp.



On Fri, Jun 25, 2021 at 2:46 PM Bruce Ashfield <bruce.ashfield@...> wrote:

On Fri, Jun 25, 2021 at 4:11 AM Diego Sueiro <Diego.Sueiro@...> wrote:

-----Original Message-----
From: Bruce Ashfield <bruce.ashfield@...>
Sent: 25 June 2021 03:49
To: Martin Jansa <martin.jansa@...>
Cc: Diego Sueiro <Diego.Sueiro@...>; meta-
virtualization@...; nd <nd@...>
Subject: Re: [meta-virtualization][PATCH 1/3] podman: Add seccomp as
REQUIRED_DISTRO_FEATURES

On Thu, Jun 24, 2021 at 5:01 PM Martin Jansa <martin.jansa@...>
wrote:

This change is correct, libseccomp still requires seccomp in

DISTRO_FEATURES, so anything depending on it should have the same
restriction.

Right, I understand how/why it works like this .. but it is super clunky when we
can't just depend on something that is now in core, without needing to
sprinkle distro checks everywhere.

As the list of recipes gets larger with that check, it really isn't an optional distro
feature for using meta virt at all, and it would be nice if we could just do the
check once and be done with it.

Just a side note that these patches fix issues with yocto-check-layer.

I've disagreed with check-layer before (and we've changed how it works)

That being said, the layer is checked on the AB, and Richard hasn't
reported any issues. So clearly there's something wrong with the AB
test or with something else.



Bruce

Diego

Bruce

seccomp is now in default DISTRO_FEATURES, but not through BACKFILL

feature, so many existing DISTROs didn't get it automatically added and
requiring it is the right way to automatically skip such recipes.

On Thu, Jun 24, 2021 at 12:45 PM Bruce Ashfield

<bruce.ashfield@...> wrote:

What branch are you working with ?

Now that seccomp is in core, we no longer have those restrictions, so
I assume this is on an older branch ?

Bruce

On Thu, Jun 24, 2021 at 3:00 PM Diego Sueiro <diego.sueiro@...>

wrote:

The libseccomp package is only available if seccomp is in

DISTRO_FEATURES.

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
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 9dcb21c..351f38b 100644
--- a/recipes-containers/podman/podman_git.bb
+++ b/recipes-containers/podman/podman_git.bb
@@ -6,6 +6,9 @@ DESCRIPTION = "Podman is a daemonless container

engine for developing, \

`alias docker=podman`. \
"

+inherit features_check
+REQUIRED_DISTRO_FEATURES ?= "seccomp"
+
DEPENDS = " \
go-metalinter-native \
go-md2man-native \
--
2.17.1

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

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

--
- 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 Tue, 2021-06-29 at 23:27 -0400, Bruce Ashfield wrote:

On Fri, Jun 25, 2021 at 11:21 AM Bruce Ashfield via
lists.yoctoproject.org

That is the core of what I was asking. A package that is now in core,
why is it only enabled by a distro feature ?

And for clarity, I realize that the systemd recipe checks for the
systemd distro feature .. so that is similar. But systemd is one of
many init managers, so I can see why it is used.

I still don't have a better solution to this, and while I see about
getting seccomp behaviour changed in core, I can get this into the
tree.

I've added the extra seccomp dependent recipes and expect to merge
this on Wednesday.

The reason for the distro_feature is to have a way to configure multiple
packageconfigs on/off centrally. Some platforms don't support seccomp
at all (riscv/arc) so forcing it on everywhere isn't possible.

I think we can remove the DISTRO_FEATURE restriction in the seccomp recipe itself
in core and replace it with a COMPATIBLE_HOST declaration.

We could also add the option to the default distro backfill.

Cheers,

Richard

On Wed, Jun 30, 2021 at 3:58 AM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2021-06-29 at 23:27 -0400, Bruce Ashfield wrote:

On Fri, Jun 25, 2021 at 11:21 AM Bruce Ashfield via
lists.yoctoproject.org

That is the core of what I was asking. A package that is now in core,
why is it only enabled by a distro feature ?

And for clarity, I realize that the systemd recipe checks for the
systemd distro feature .. so that is similar. But systemd is one of
many init managers, so I can see why it is used.

I still don't have a better solution to this, and while I see about
getting seccomp behaviour changed in core, I can get this into the
tree.

I've added the extra seccomp dependent recipes and expect to merge
this on Wednesday.

The reason for the distro_feature is to have a way to configure multiple
packageconfigs on/off centrally. Some platforms don't support seccomp
at all (riscv/arc) so forcing it on everywhere isn't possible.

I think we can remove the DISTRO_FEATURE restriction in the seccomp recipe itself
in core and replace it with a COMPATIBLE_HOST declaration.

That would be preferable on my end, since these recipes that depend on
seccomp unconditionally, are also incompatible with that same set of
hosts (I state the obvious here).

We could also add the option to the default distro backfill.

I'm not as familiar with the backfill and when it should be used, but
I'll have a look at doing both of these for the seccomp work, and then
update the meta-virt recipes that can be simplified.

Bruce

Cheers,

Richard

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