Date   

Re: SCM usage in source urls and bandwidth

Richard Purdie
 

On Wed, 2022-03-30 at 10:05 -0400, Claude Bing wrote:
On 3/30/22 09:53, Alexandre Belloni via lists.yoctoproject.org wrote:
On 30/03/2022 11:42:46+0100, Richard Purdie wrote:
[list address fixed, sorry]

We've been having bandwidth trouble with downloads.yoctoproject.org so we did
some quick analysis to see what the issue is. Basically in speeding up the
server which was the rate limit, we hit the limits of the hosting pipe. I'd note
a few things:

a) it isn't the sstate mirroring, it is nearly all being used by downloads.

b) 25% of all our bandwidth is going on "git2_sourceware.org.git.binutils-
gdb.git.tar.gz" - i.e. downloading the source mirror binutils tarball

c) 15% is on git2_sourceware.org.git.glibc.git.tar.gz i.e. glibc

d) OE-Core has downloads.yoctoproject.org as a MIRROR

e) poky has it as a PREMIRROR

What are our options? As far as I can see we could:

a) increase the pipe from downloads.yoctoproject.org but that does come at a
non-trivial cost to the project.

b) Seek help with hosting some of the larger mirror tarballs from people better
able to host them and have that as a first premirror?

c) Switch the binutils and glibc recipes to tarballs and patches. I know Khem
finds this less convenient and they keep moving back and forward but we keep
running into this issue and having to switch back from git.

d) To soften the blow of c) we could add devupstream support to the recipes? We
could script updating the recipe to add the patches?

e) We could drop the PREMIRRORS from poky. This would stop the SCM targets from
hitting our mirrors first. That does transfer load to the upstream project SCMs
though and I'm not sure that will be appreciated. I did sent that patch, I'm not
sure about it though.
I would simply drop PREMIRRORS, this is actually a privacy concern for
some of our customers that didn't realize they are leaking the names of
their internal git repositories to downloads.yoctoproject.org.
Indeed, that would be concerning for us as well. Would it be possible to
ignore PREMIRRORS based on the recipe layer? Alternatively, we could
create blocklists for heavy packages that need to fetch from upstream
first rather than drop PREMIRRORS completely. Sometimes, having a
secondary source could save valuable time when the upstream is not
responsive.
We don't have any support for "per-layer" overrides at this time which would be
the way to do that. It is something I think we probably do want to consider
adding but I haven't had the bandwidth to look at it.

I'd note that these mirrors in PREMIRRORS are also in MIRRORS already in OE-Core
so there is a fallback, it just controls the order they're tried in.

Cheers,

Richard


Re: SCM usage in source urls and bandwidth

Claude Bing
 

On 3/30/22 09:53, Alexandre Belloni via lists.yoctoproject.org wrote:
On 30/03/2022 11:42:46+0100, Richard Purdie wrote:
[list address fixed, sorry]

We've been having bandwidth trouble with downloads.yoctoproject.org so we did
some quick analysis to see what the issue is. Basically in speeding up the
server which was the rate limit, we hit the limits of the hosting pipe. I'd note
a few things:

a) it isn't the sstate mirroring, it is nearly all being used by downloads.

b) 25% of all our bandwidth is going on "git2_sourceware.org.git.binutils-
gdb.git.tar.gz" - i.e. downloading the source mirror binutils tarball

c) 15% is on git2_sourceware.org.git.glibc.git.tar.gz i.e. glibc

d) OE-Core has downloads.yoctoproject.org as a MIRROR

e) poky has it as a PREMIRROR

What are our options? As far as I can see we could:

a) increase the pipe from downloads.yoctoproject.org but that does come at a
non-trivial cost to the project.

b) Seek help with hosting some of the larger mirror tarballs from people better
able to host them and have that as a first premirror?

c) Switch the binutils and glibc recipes to tarballs and patches. I know Khem
finds this less convenient and they keep moving back and forward but we keep
running into this issue and having to switch back from git.

d) To soften the blow of c) we could add devupstream support to the recipes? We
could script updating the recipe to add the patches?

e) We could drop the PREMIRRORS from poky. This would stop the SCM targets from
hitting our mirrors first. That does transfer load to the upstream project SCMs
though and I'm not sure that will be appreciated. I did sent that patch, I'm not
sure about it though.
I would simply drop PREMIRRORS, this is actually a privacy concern for
some of our customers that didn't realize they are leaking the names of
their internal git repositories to downloads.yoctoproject.org.
Indeed, that would be concerning for us as well. Would it be possible to
ignore PREMIRRORS based on the recipe layer? Alternatively, we could
create blocklists for heavy packages that need to fetch from upstream
first rather than drop PREMIRRORS completely. Sometimes, having a
secondary source could save valuable time when the upstream is not
responsive.








Re: SCM usage in source urls and bandwidth

Alexandre Belloni
 

On 30/03/2022 11:42:46+0100, Richard Purdie wrote:
[list address fixed, sorry]

We've been having bandwidth trouble with downloads.yoctoproject.org so we did
some quick analysis to see what the issue is. Basically in speeding up the
server which was the rate limit, we hit the limits of the hosting pipe. I'd note
a few things:

a) it isn't the sstate mirroring, it is nearly all being used by downloads.

b) 25% of all our bandwidth is going on "git2_sourceware.org.git.binutils-
gdb.git.tar.gz" - i.e. downloading the source mirror binutils tarball

c) 15% is on git2_sourceware.org.git.glibc.git.tar.gz i.e. glibc

d) OE-Core has downloads.yoctoproject.org as a MIRROR

e) poky has it as a PREMIRROR

What are our options? As far as I can see we could:

a) increase the pipe from downloads.yoctoproject.org but that does come at a
non-trivial cost to the project.

b) Seek help with hosting some of the larger mirror tarballs from people better
able to host them and have that as a first premirror?

c) Switch the binutils and glibc recipes to tarballs and patches. I know Khem
finds this less convenient and they keep moving back and forward but we keep
running into this issue and having to switch back from git.

d) To soften the blow of c) we could add devupstream support to the recipes? We
could script updating the recipe to add the patches?

e) We could drop the PREMIRRORS from poky. This would stop the SCM targets from
hitting our mirrors first. That does transfer load to the upstream project SCMs
though and I'm not sure that will be appreciated. I did sent that patch, I'm not
sure about it though.
I would simply drop PREMIRRORS, this is actually a privacy concern for
some of our customers that didn't realize they are leaking the names of
their internal git repositories to downloads.yoctoproject.org.



--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: Strange sporadic build issues (incremental builds in docker container)

Trevor Woerner
 

Hi Matthias,

On Wed 2022-03-30 @ 06:32:00 AM, Matthias Klein wrote:
Yes, you are right, it is mostly the same recipes that fail. But they also change from time to time.
Today it happened to me even without Jenkins and Docker, normally in the console with the recipe keymaps_1.0.bb.
And keymaps follows the exact same pattern as modutils-initscripts and
initscripts; namely that their sources are entirely contained in-tree:

keymaps/
├── files
│   ├── GPLv2.patch
│   └── keymap.sh
└── keymaps_1.0.bb

keymaps/keymaps_1.0.bb
23 SRC_URI = "file://keymap.sh \
24 file://GPLv2.patch"

Any recipe that follows this pattern is susceptible, it's probably just a
coincidence that most of my failures happened to be with the two recipes I
mentioned.

This issue has revealed a bug, and fixing that bug would be great. However,
the thing is, keymap.sh is a shell program written 12 years ago which hasn't
changed since. The GPL/COPYING file is only there for "reasons". The license
file doesn't *need* to be moved into the build area for this recipe to get its
job done (namely installing keymap.sh into the image's sysvinit).

Best regards,
Trevor


Re : Fetching source from Private git repo

Poornesh G
 

Greetings !

Can anyone help me with the procedure , how I can fetch the source from a private gitlab account .
Thanks in advance !



IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof.

Please, consider your environmental responsibility. Before printing this e-mail ask yourself: "Do I need a hard copy?"


Re: SCM usage in source urls and bandwidth

Richard Purdie
 

On Wed, 2022-03-30 at 12:18 +0100, Ross Burton wrote:
On Wed, 30 Mar 2022 at 12:10, Richard Purdie
<richard.purdie@...> wrote:
f) Switch the problematic recipes to use shallow clones with something like:

BB_GIT_SHALLOW:pn-binutils = "1"
BB_GIT_SHALLOW:pn-binutils-cross-${TARGET_ARCH} = "1"
BB_GIT_SHALLOW:pn-binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} = "1"
BB_GIT_SHALLOW:pn-binutils-cross-testsuite = "1"
BB_GIT_SHALLOW:pn-binutils-crosssdk-${SDK_SYS} = "1"
BB_GIT_SHALLOW:pn-glibc = "1"

The challenge here is that in order to be effective, there needs to be a
PREMIRROR setup with the shallow tarballs on it. This means we couldn't do e)
above and have this have much effect unless we craft some very specific
PREMIRROR entries too.
Even without premirrors this is a lot faster for glibc:

$ time git clone git://sourceware.org/git/glibc.git
Cloning into 'glibc'...
remote: Enumerating objects: 6956, done.
remote: Counting objects: 100% (6956/6956), done.
remote: Compressing objects: 100% (2938/2938), done.
remote: Total 670093 (delta 5328), reused 4750 (delta 3932), pack-reused 663137
Receiving objects: 100% (670093/670093), 205.19 MiB | 16.39 MiB/s, done.
Resolving deltas: 100% (573265/573265), done.
Updating files: 100% (19011/19011), done.

real 1m56.255s

$ time git clone git://sourceware.org/git/glibc.git --depth 1
Cloning into 'glibc'...
remote: Enumerating objects: 18809, done.
remote: Counting objects: 100% (18809/18809), done.
remote: Compressing objects: 100% (9704/9704), done.
remote: Total 18809 (delta 8812), reused 12185 (delta 7968), pack-reused 0
Receiving objects: 100% (18809/18809), 41.79 MiB | 11.96 MiB/s, done.
Resolving deltas: 100% (8812/8812), done.
Updating files: 100% (19011/19011), done.

real 0m8.701s

A full clone fetches 200MB and takes 2 minutes (a lot of that is
actually resolving the deltas, not the fetch). A shallow clone of the
current HEAD fetches 40MB and is done in 8 seconds.

Why would we need a premirror?
The code doesn't do "--depth=1".

https://git.yoctoproject.org/poky/commit/?id=27d56982c7ba05e86a100b0cca2411ee5ac7a85e

"""
This implements support for shallow mirror tarballs, not shallow clones.
Supporting shallow clones directly is not really doable for us, as we'd need
to hardcode the depth between branch HEAD and the SRCREV, and that depth would
change as the branch is updated.
"""

Put another way, you didn't specify a revision in your clone above and if you
try, it becomes rather tricky.

To make this work we therefore need a mirror with the shallow tarballs on it.

Just for info, the binutils mirror tarball is ~1.3GB, the shallow tarball is
65MB.

Cheers,

Richard


Re: SCM usage in source urls and bandwidth

Ross Burton <ross@...>
 

On Wed, 30 Mar 2022 at 12:10, Richard Purdie
<richard.purdie@...> wrote:
f) Switch the problematic recipes to use shallow clones with something like:

BB_GIT_SHALLOW:pn-binutils = "1"
BB_GIT_SHALLOW:pn-binutils-cross-${TARGET_ARCH} = "1"
BB_GIT_SHALLOW:pn-binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} = "1"
BB_GIT_SHALLOW:pn-binutils-cross-testsuite = "1"
BB_GIT_SHALLOW:pn-binutils-crosssdk-${SDK_SYS} = "1"
BB_GIT_SHALLOW:pn-glibc = "1"

The challenge here is that in order to be effective, there needs to be a
PREMIRROR setup with the shallow tarballs on it. This means we couldn't do e)
above and have this have much effect unless we craft some very specific
PREMIRROR entries too.
Even without premirrors this is a lot faster for glibc:

$ time git clone git://sourceware.org/git/glibc.git
Cloning into 'glibc'...
remote: Enumerating objects: 6956, done.
remote: Counting objects: 100% (6956/6956), done.
remote: Compressing objects: 100% (2938/2938), done.
remote: Total 670093 (delta 5328), reused 4750 (delta 3932), pack-reused 663137
Receiving objects: 100% (670093/670093), 205.19 MiB | 16.39 MiB/s, done.
Resolving deltas: 100% (573265/573265), done.
Updating files: 100% (19011/19011), done.

real 1m56.255s

$ time git clone git://sourceware.org/git/glibc.git --depth 1
Cloning into 'glibc'...
remote: Enumerating objects: 18809, done.
remote: Counting objects: 100% (18809/18809), done.
remote: Compressing objects: 100% (9704/9704), done.
remote: Total 18809 (delta 8812), reused 12185 (delta 7968), pack-reused 0
Receiving objects: 100% (18809/18809), 41.79 MiB | 11.96 MiB/s, done.
Resolving deltas: 100% (8812/8812), done.
Updating files: 100% (19011/19011), done.

real 0m8.701s

A full clone fetches 200MB and takes 2 minutes (a lot of that is
actually resolving the deltas, not the fetch). A shallow clone of the
current HEAD fetches 40MB and is done in 8 seconds.

Why would we need a premirror?

Ross


Re: SCM usage in source urls and bandwidth

Richard Purdie
 

On Wed, 2022-03-30 at 11:42 +0100, Richard Purdie via lists.yoctoproject.org
wrote:
What are our options? As far as I can see we could:

a) increase the pipe from downloads.yoctoproject.org but that does come at a
non-trivial cost to the project.

b) Seek help with hosting some of the larger mirror tarballs from people better
able to host them and have that as a first premirror?

c) Switch the binutils and glibc recipes to tarballs and patches. I know Khem
finds this less convenient and they keep moving back and forward but we keep
running into this issue and having to switch back from git.

d) To soften the blow of c) we could add devupstream support to the recipes? We
could script updating the recipe to add the patches?

e) We could drop the PREMIRRORS from poky. This would stop the SCM targets from
hitting our mirrors first. That does transfer load to the upstream project SCMs
though and I'm not sure that will be appreciated. I did sent that patch, I'm not
sure about it though.
I meant to add:

f) Switch the problematic recipes to use shallow clones with something like:

BB_GIT_SHALLOW:pn-binutils = "1"
BB_GIT_SHALLOW:pn-binutils-cross-${TARGET_ARCH} = "1"
BB_GIT_SHALLOW:pn-binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} = "1"
BB_GIT_SHALLOW:pn-binutils-cross-testsuite = "1"
BB_GIT_SHALLOW:pn-binutils-crosssdk-${SDK_SYS} = "1"
BB_GIT_SHALLOW:pn-glibc = "1"

The challenge here is that in order to be effective, there needs to be a
PREMIRROR setup with the shallow tarballs on it. This means we couldn't do e)
above and have this have much effect unless we craft some very specific
PREMIRROR entries too.

Cheers,

Richard


SCM usage in source urls and bandwidth

Richard Purdie
 

[list address fixed, sorry]

We've been having bandwidth trouble with downloads.yoctoproject.org so we did
some quick analysis to see what the issue is. Basically in speeding up the
server which was the rate limit, we hit the limits of the hosting pipe. I'd note
a few things:

a) it isn't the sstate mirroring, it is nearly all being used by downloads.

b) 25% of all our bandwidth is going on "git2_sourceware.org.git.binutils-
gdb.git.tar.gz" - i.e. downloading the source mirror binutils tarball

c) 15% is on git2_sourceware.org.git.glibc.git.tar.gz i.e. glibc

d) OE-Core has downloads.yoctoproject.org as a MIRROR

e) poky has it as a PREMIRROR

What are our options? As far as I can see we could:

a) increase the pipe from downloads.yoctoproject.org but that does come at a
non-trivial cost to the project.

b) Seek help with hosting some of the larger mirror tarballs from people better
able to host them and have that as a first premirror?

c) Switch the binutils and glibc recipes to tarballs and patches. I know Khem
finds this less convenient and they keep moving back and forward but we keep
running into this issue and having to switch back from git.

d) To soften the blow of c) we could add devupstream support to the recipes? We
could script updating the recipe to add the patches?

e) We could drop the PREMIRRORS from poky. This would stop the SCM targets from
hitting our mirrors first. That does transfer load to the upstream project SCMs
though and I'm not sure that will be appreciated. I did sent that patch, I'm not
sure about it though.

We are going to need to do *something* though as the current situation can't
continue. I'm open to other ideas...

Cheers,

Richard


Re: [OE-core] Which vendors maintain SDIO WiFi in mainline stable kernel

Quentin Schulz
 

Hi Jupiter,

On 3/29/22 07:16, JH wrote:
Hi,
I could not understand why so many large WiFi chip vendors retreat to
stop maintaining WiFi SDIO chips to mainline Linux kernel, and to
settle it's chip support to out of the tree, use its own SDK and
proprietary kernel tree to source.codeaurora.org or private repository
which are not compatible to mainline stable kernel, the kernel
configures are also different.
It is extremely rare to have vendors not have out-of-tree drivers or forked branches (I don't know of any, personally). Some vendors do end up upstreaming some of their patches in the end to reduce the amount of maintenance they have to do on their downstream drivers/kernel tree.

Upstreaming takes time, knowledge and soft (as in "communicating with people") skills that some vendors aren't willing to invest in. It's also usually not an urgent matter (as opposed to have *something* that works, so they can sell the product ASAP).

Also, quality of vendor (understand downstream) code is often subpar (to be polite) and would not be accepted as-is in Linux kernel upstream git repository.

Finally, it is also a strategical choice for vendors to have an out-of-tree driver so that people stuck with an older kernel can still use this driver/product. One simple example: a bad vendor sells you an SoC with BSP supporting kernel 4.4 (let's say). Now, you want to use a specific WiFi module with this SoC. Fortunately, there's upstream support for it, but only in 5.10 and later. Considering the number of changes between 4.4 and 5.10, you won't be able to easily backport the driver to work on 4.4. This means the WiFi module vendor loses you as a customer because you wont be able to use their solution.

Now, you could also have a nicer SoC vendor which provides you with a 5.10 kernel. However, there's an important fix available in 5.16 that isn't in the WiFi driver you have on 5.10. You could try to backport this yourself but not all customers of said WiFi vendor are skilled enough to do this. The WiFi vendor needs to provide support for backporting this for the customer and/or deal with unhappy customers.

However, with an out-of-tree driver with appropriate ifdefs everywhere to adapt for specific versions of the Linux kernel ABI, they have ONE driver that is known to work on many different Linux kernel versions. It also makes the maintenance of the driver much more simple for them. This also allows them to do releases much more often than the Linux kernel allows (one every 2-3 months). Considering the usually bad quality of code and maybe lack of proper reviews, you might end up with regressions and more importantly security issues that will never be discovered because less eyes will be on the code.

Out-of-tree drivers make sense in a self-feeding loop of vendors not upstreaming stuff because they need to support other vendors not upstreaming, even if they wanted to in the first place.

Finally, I've had to patch locally about 3-4 WiFi drivers and the changes weren't implemented by the vendor in the next releases. So you might just have issues other companies have fixed but it was never reported or fixed by the vendor. (Note that upstreaming does not necessarily fix this issue, it just makes it in theory less likely to happen since more people are supposed to use it than some vendor kernel).

Also, some vendors are historically reluctant to contribute anything to the upstream Linux kernel and the support of their hardware was added by hobbyists or one of their clients, bearing the costs themselves.

I looked at the following link, the mwifiex and mwifiex_sdio support
the Marvell (NXP) 88W88 chipset, but only kernel 4.19 was able to
build and to run, kernel 5 cannot support 88W88 chipset, any more.
You'd need to request the newer versions of mwifiex to NXP (which acquired Marvell some years ago) or patch it yourself. Welcome to the world of downstream support :)

Same to Qualcomm, the old Atheros WiFi modules are supported, the
QCA-9377-3 chipset is in source.codeaurora.org only supported by old
kernel 4.9.
Given the OE/Yocto poky kernel build is based on a mainline stable
kernel repository, how can I build kernel 5 for 88W88 chipset or
QCA-9377-3 from source.codeaurora.org or private repository? Or which
WiFi vendors are still well maintaining the WiFi chips for kernel 5,
the only sensible solution is to switch WiFi SDIO chips? Appreciate
your advice and comments.
Yocto only builds what you tell it to build. The company I work for provides[1] Yocto support for a vendor kernel based on Android-flavored 4.4 (note: though we do actually support and encourage using mainline, GPU/VPU support was - years ago - just not comparable between vendor and upstream kernels) for our System on Module, all of this on Honister (latest release of Yocto to date). You just need to create your own recipe (or adapt an existing one) to point to the BSP components your vendor gave you (or whatever you want to use) and build it. Nothing forces you to use linux-yocto 5.14 or whatever else.

[1] https://git.theobroma-systems.com/yocto-layers/meta-theobroma-systems-bsp.git/tree/recipes-kernel/linux/linux-tsd_4.4.bb

Cheers,
Quentin


Running chromium with read-only-rootfs

benabid.houssem11@...
 


Hello Friends ;
I have My own Image based on Wayland-Weston image. My Image should be on read-only- rootfs so i use this :
IMAGE_FEATURES += "read-only-rootfs"
But I have a problem when running chromium in my image, i think that it can't work in read-only so i find that there's something called VOLATILE-BINDS that can help.
can someone help me to configure this VOLATILE-BINDS to get the work done.
The Error when running chromium in my image is : Error /root/.config/**/** is read-only

Thanks in advance


Re: Strange sporadic build issues (incremental builds in docker container)

Matthias Klein
 

Hi Trevor,

thank you very much for the detailed answer.

Yes, you are right, it is mostly the same recipes that fail. But they also change from time to time.
Today it happened to me even without Jenkins and Docker, normally in the console with the recipe keymaps_1.0.bb.

With the nighly builds over the Jenkins I help myself at the moment that I delete build/tmp before.
So far, the problem has not occurred again.

Many greetings,
Matthias

-----Ursprüngliche Nachricht-----
Von: Trevor Woerner <twoerner@...>
Gesendet: Dienstag, 29. März 2022 18:23
An: Alexander Kanavin <alex.kanavin@...>
Cc: Matthias Klein <matthias.klein@...>; yocto@...
Betreff: Re: [yocto] Strange sporadic build issues (incremental builds in docker container)

On Thu 2022-03-24 @ 09:31:25 AM, Alexander Kanavin wrote:
I don't. You need to inspect the build tree to find clues why the
patch was applied twice. Or simpy wipe tmp/ before builds, if your
sstate works properly that won't make the builds longer.

Alex

On Thu, 24 Mar 2022 at 07:43, Matthias Klein <matthias.klein@...> wrote:

Hello Alex,

it occurred again:

NOTE: recipe gawk-5.1.1-r0: task do_patch: Succeeded
NOTE: Running task 1673 of 4524
(/var/jenkins_home/workspace/yocto-raspberrypi/yocto/poky/meta/recip
es-devtools/python/python3-six_1.16.0.bb:do_patch)
NOTE: recipe firstboot-1.0-r0: task do_populate_sysroot: Started
NOTE: recipe keymaps-1.0-r31: task do_patch: Started
NOTE: recipe python3-six-1.16.0-r0: task do_patch: Started
NOTE: recipe python3-six-1.16.0-r0: task do_patch: Succeeded
NOTE: Running task 1676 of 4524
(/var/jenkins_home/workspace/yocto-raspberrypi/yocto/poky/meta/recip
es-devtools/perl/perl_5.34.1.bb:do_patch)
NOTE: recipe e2fsprogs-1.46.5-r0: task do_patch: Succeeded
ERROR: keymaps-1.0-r31 do_patch: Applying patch 'GPLv2.patch' on target directory '/var/jenkins_home/workspace/yocto-raspberrypi/build/tmp/work/raspberrypi3_64-poky-linux/keymaps/1.0-r31'
CmdError('quilt --quiltrc /var/jenkins_home/workspace/yocto-raspberrypi/build/tmp/work/raspberrypi3_64-poky-linux/keymaps/1.0-r31/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout:
stderr: File series fully applied, ends at patch GPLv2.patch
')
ERROR: Logfile of failure stored in:
/var/jenkins_home/workspace/yocto-raspberrypi/build/tmp/work/raspber
rypi3_64-poky-linux/keymaps/1.0-r31/temp/log.do_patch.353982
NOTE: recipe keymaps-1.0-r31: task do_patch: Failed
NOTE: Running task 1679 of 4524
(/var/jenkins_home/workspace/yocto-raspberrypi/yocto/poky/meta/recip
es-bsp/alsa-state/alsa-state.bb:do_patch)
ERROR: Task (/var/jenkins_home/workspace/yocto-raspberrypi/yocto/poky/meta/recipes-bsp/keymaps/keymaps_1.0.bb:do_patch) failed with exit code '1'

Do you have an idea?

Best regards,
Matthias

-----Ursprüngliche Nachricht-----
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Dienstag, 22. März 2022 10:26
An: Matthias Klein <matthias.klein@...>
Cc: yocto@...
Betreff: Re: [yocto] Strange sporadic build issues (incremental
builds in docker container)

It's hard to say without the full error message, and the build directory of the affected recipe. The easy way out is to simply wipe tmp/ before each build.

Alex

On Tue, 22 Mar 2022 at 09:51, Matthias Klein <matthias.klein@...> wrote:

Hello together,

I am building various kirkstone/master yoctos every night via Jenkins inside a Debian Bullseye Docker container.
These are incremental builds, reusing the build directory and sstate-cache of the previous build. The different yoctos are built in order. Each time, a new Docker container is launched.
(The same environment builds dunfell yoctos without any problems).

Now it happens sporadically that one of the builds aborts with the following message:

stderr: The series file no longer matches the applied patches. Please run 'quilt pop -a'.

They are usually alternating packages where the patch step fails with the above message. Also different yoctos are affected. But it is always the above message.
If I then restart the failed build it usually builds cleanly.

Does anyone have an idea in which direction the problem goes?
Yes I've been seeing exactly these issues as well.

I'm not using any sort of virtualization, I'm using Jenkins to do nightly builds directly on my host. My host machine is openSUSE 15.3. These problems started on Feb 21 for me.

Each of my builds starts by doing a "git pull" on each of the repositories, then kicks off a build if any of the repositories changed. A fresh build will always succeed. Doing a "clean" and rebuilding will (I believe) always succeed. My gut feeling is that it somehow has something to do with having an existing build, refreshing the repositories, then rebuilding.

I spent weeks trying to find a reproducer. I wrote a script to checkout one version of the repositories (before), build, checkout a newer version of the repositories (after) and rebuilding. Even in cases where I used the exact same hashes that had failed on my Jenkins build and repeating 20 times, in some cases I wasn't able to reproduce the error. I was able to find 1 reproducer involving a build for an imx28evk MACHINE, but even then after 20 iterations
13 were bad and 7 were good. I repeated that set of 20 builds many times and it was never 100% bad.

My investigations led me to believe that it might be related to rm_work and/or BB_NUMBER_THREADS/PARALLEL_MAKE. In my Jenkins builds I enable 'INHERIT += "rm_work"' and I also limit the BB_NUMBER_THREADS and set PARALLEL_MAKE. On the cmdline I was able to reduce the number of failures (sometimes to none) by removing the rm_work and THREADS/PARALLEL, but never completely eliminate it.
In Jenkins the build failures still felt as random as they were without the change, so I can't say that it's having much effect in Jenkins, but seems to have some effect on the cmdline.

I can say this with certainty: Matthias says it seems that the specific recipe that fails is random, but it's not. In every case the recipe that fails is a recipe whose source files are contained in the meta layer itself. For me the failing recipes were always:
modutils-initscripts
initscripts

If you look at the recipes for those packages they do not have a SRC_URI that fetches code from some remote location then uses quilt to apply some patches.
In both cases all of the "source" code exists in the layer itself, and somehow quilt is involved in placing them in the build area.

I have dozens and dozens of these failures recorded and it is always with a recipe that follows that pattern. But 99%-ish percent of the failures are with the two packages I listed above.

The failures aren't related to days when those packages change. The failures are just... sporadic.

So the issue is related to:
- recipes with in-layer sources
- quilt (being run twice (?))
- updating layers, and rebuilding in a build area with an existing build
- Feb 21 2022 (or thereabouts)

The issue might be related to:
- jenkins?
- my build host?
- rm_work?
- BB_NUMBER_THREADS?
- PARALLEL_MAKE?


Re: OpenEmbedded Happy Hour March 30 5pm/1700 UTC

Denys Dmytriyenko
 

Reminder, OpenEmbedded Happy Hour is tomorrow. See you all there.

On Thu, Mar 24, 2022 at 06:41:58PM -0400, Denys Dmytriyenko wrote:
All,

You are cordially invited to the next OpenEmbedded Happy Hour on March 30
for Europe/Americas timezones @ 1700/5pm UTC (1pm ET / 10am PT):

https://www.openembedded.org/wiki/Calendar
https://www.openembedded.org/wiki/Happy_Hours
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+March+30&iso=20220330T17
--
Regards,
Denys Dmytriyenko <denis@...>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


[yocto 3.1] adding custom testsdk script in own layer

Karthik Poduval
 

Hi All,

We were trying to add a custom sdktest script as shown in example https://docs.yoctoproject.org/test-manual/intro.html#testsdk.

The script gets invoked when placed in meta/lib/oeqa/sdk/cases/mysdktest.py

However when placed under.
<my layer>/lib/oeqa/sdk/cases/mysdktest.py
It does not get invoked when running 
bitbake <my image> -c testsdk

The testimage scripts do work when placed under 
<my layer>/lib/oeqa/runtime/cases/ 
as they are controlled by the TEST_SUITES variable.

Kindly advise on how to proceed.

--
Regards,
Karthik Poduval


Re: firewalld isssue #yocto

Randy MacLeod
 

On 2022-03-28 03:18, Nicolas Jeker wrote:
On Sun, 2022-03-27 at 23:39 -0700, sateesh m wrote:
Hi Team,

                I have built a custom image core-image-base on riscv
target machine installed nftables,firewalld,JSON packages support. I
am using firewalld_0.9.3 sources depends nftables-python is present.
But I am getting error python-nftables. Can you please guide me on
what dependent I missed here? If suppose firewalld should work means,
What packages should  I install?

But while running firewalld status is always failed mode.
Using $firewall-cmd --reload  I am facing a  problem

Error: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0:
Error: Could not process rule: No such file or directory
Judging by this stack exchange thread[1] from a quick search, you might
be missing the appropriate kernel configs[2].

[1]: https://unix.stackexchange.com/questions/632113
[2]: https://wiki.gentoo.org/wiki/Nftables#Kernel
Trevor was looking into this as well so I've CCed him.

../Randy


JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"raw_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -
290}}}, {"add": {"chain": {"family": "inet", "table": "firewalld",
"name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting",
"prio": -140}}}, {"add": {"chain": {"family": "inet", "table":
"firewalld", "name": "mangle_PREROUTING_POLICIES_pre"}}}, {"add":
{"rule": {"family": "inet", "table": "firewalld", "chain":
"mangle_PREROUTING", "expr": [{"jump": {"target":
"mangle_PREROUTING_POLICIES_pre"}}]}}}, {"add": {"chain": {"family":
"inet", "table": "firewalld", "name": "mangle_PREROUTING_ZONES"}}},
{"add": {"rule": {"family": "inet", "table": "firewalld", "chain":
"mangle_PREROUTING", "expr": [{"jump": {"target":
"mangle_PREROUTING_ZONES"}}]}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "mangle_PREROUTING_POLICIES_post"}}},
{"add": {"rule": {"family": "inet", "table": "firewalld", "chain":
"mangle_PREROUTING", "expr": [{"jump": {"target":
"mangle_PREROUTING_POLICIES_post"}}]}}}, {"add": {"chain": {"family":
"ip", "table": "firewalld", "name": "nat_PREROUTING", "type": "nat",
"hook": "prerouting", "prio": -90}}}, {"add": {"chain": {"family":
"ip", "table": "firewalld", "name": "nat_PREROUTING_POLICIES_pre"}}},
{"add": {"rule": {"family": "ip", "table": "firewalld", "chain":
"nat_PREROUTING", "expr": [{"jump": {"target":
"nat_PREROUTING_POLICIES_pre"}}]}}}, {"add": {"chain": {"family":
"ip", "table": "firewalld", "name": "nat_PREROUTING_ZONES"}}},
{"add": {"rule": {"family": "ip", "table": "firewalld", "chain":
"nat_PREROUTING", "expr": [{"jump": {"target":
"nat_PREROUTING_ZONES"}}]}}}, {"add": {"chain": {"family": "ip",
"table": "firewalld", "name": "nat_PREROUTING_POLICIES_post"}}},
{"add": {"rule": {"family": "ip", "table": "firewalld", "chain":
"nat_PREROUTING", "expr": [{"jump": {"target":
"nat_PREROUTING_POLICIES_post"}}]}}}, {"add": {"chain": {"family":
"ip", "table": "firewalld", "name": "nat_POSTROUTING", "type": "nat",
"hook": "postrouting", "prio": 110}}}, {"add": {"chain": {"family":
"ip", "table": "firewalld", "name":
"nat_POSTROUTING_POLICIES_pre"}}}, {"add": {"rule": {"family": "ip",
"table": "firewalld", "chain": "nat_POSTROUTING", "expr": [{"jump":
{"target": "nat_POSTROUTING_POLICIES_pre"}}]}}}, {"add": {"chain":
{"family": "ip", "table": "firewalld", "name":
"nat_POSTROUTING_ZONES"}}}, {"add": {"rule": {"family": "ip",
"table": "firewalld", "chain": "nat_POSTROUTING", "expr": [{"jump":
{"target": "nat_POSTROUTING_ZONES"}}]}}}, {"add": {"chain":
{"family": "ip", "table": "firewalld", "name":
"nat_POSTROUTING_POLICIES_post"}}}, {"add": {"rule": {"family": "ip",
"table": "firewalld", "chain": "nat_POSTROUTING", "expr": [{"jump":
{"target": "nat_POSTROUTING_POLICIES_post"}}]}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name": "nat_PREROUTING",
"type": "nat", "hook": "prerouting", "prio": -90}}}, {"add":
{"chain": {"family": "ip6", "table": "firewalld", "name":
"nat_PREROUTING_POLICIES_pre"}}}, {"add": {"rule": {"family": "ip6",
"table": "firewalld", "chain": "nat_PREROUTING", "expr": [{"jump":
{"target": "nat_PREROUTING_POLICIES_pre"}}]}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name":
"nat_PREROUTING_ZONES"}}}, {"add": {"rule": {"family": "ip6",
"table": "firewalld", "chain": "nat_PREROUTING", "expr": [{"jump":
{"target": "nat_PREROUTING_ZONES"}}]}}}, {"add": {"chain": {"family":
"ip6", "table": "firewalld", "name":
"nat_PREROUTING_POLICIES_post"}}}, {"add": {"rule": {"family": "ip6",
"table": "firewalld", "chain": "nat_PREROUTING", "expr": [{"jump":
{"target": "nat_PREROUTING_POLICIES_post"}}]}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name": "nat_POSTROUTING",
"type": "nat", "hook": "postrouting", "prio": 110}}}, {"add":
{"chain": {"family": "ip6", "table": "firewalld", "name":
"nat_POSTROUTING_POLICIES_pre"}}}, {"add": {"rule": {"family": "ip6",
"table": "firewalld", "chain": "nat_POSTROUTING", "expr": [{"jump":
{"target": "nat_POSTROUTING_POLICIES_pre"}}]}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name":
"nat_POSTROUTING_ZONES"}}}, {"add": {"rule": {"family": "ip6",
"table": "firewalld", "chain": "nat_POSTROUTING", "expr": [{"jump":
{"target": "nat_POSTROUTING_ZONES"}}]}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name":
"nat_POSTROUTING_POLICIES_post"}}}, {"add": {"rule": {"family":
"ip6", "table": "firewalld", "chain": "nat_POSTROUTING", "expr":
[{"jump": {"target": "nat_POSTROUTING_POLICIES_post"}}]}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"filter_INPUT", "type": "filter", "hook": "input", "prio": 10}}},
{"add": {"chain": {"family": "inet", "table": "firewalld", "name":
"filter_FORWARD", "type": "filter", "hook": "forward", "prio": 10}}},
{"add": {"chain": {"family": "inet", "table": "firewalld", "name":
"filter_OUTPUT", "type": "filter", "hook": "output", "prio": 10}}},
{"add": {"rule": {"family": "inet", "table": "firewalld", "chain":
"filter_INPUT", "expr": [{"match": {"left": {"ct": {"key": "state"}},
"op": "in", "right": {"set": ["established", "related"]}}},
{"accept": null}]}}}, {"add": {"rule": {"family": "inet", "table":
"firewalld", "chain": "filter_INPUT", "expr": [{"match": {"left":
{"ct": {"key": "status"}}, "op": "in", "right": "dnat"}}, {"accept":
null}]}}}, {"add": {"rule": {"family": "inet", "table": "firewalld",
"chain": "filter_INPUT", "expr": [{"match": {"left": {"meta": {"key":
"iifname"}}, "op": "==", "right": "lo"}}, {"accept": null}]}}},
{"add": {"chain": {"family": "inet", "table": "firewalld", "name":
"filter_INPUT_POLICIES_pre"}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_INPUT", "expr": [{"jump":
{"target": "filter_INPUT_POLICIES_pre"}}]}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"filter_INPUT_ZONES"}}}, {"add": {"rule": {"family": "inet", "table":
"firewalld", "chain": "filter_INPUT", "expr": [{"jump": {"target":
"filter_INPUT_ZONES"}}]}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "filter_INPUT_POLICIES_post"}}},
{"add": {"rule": {"family": "inet", "table": "firewalld", "chain":
"filter_INPUT", "expr": [{"jump": {"target":
"filter_INPUT_POLICIES_post"}}]}}}, {"add": {"rule": {"family":
"inet", "table": "firewalld", "chain": "filter_INPUT", "expr":
[{"match": {"left": {"ct": {"key": "state"}}, "op": "in", "right":
{"set": ["invalid"]}}}, {"drop": null}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain": "filter_INPUT",
"expr": [{"reject": {"type": "icmpx", "expr": "admin-
prohibited"}}]}}}, {"add": {"rule": {"family": "inet", "table":
"firewalld", "chain": "filter_FORWARD", "expr": [{"match": {"left":
{"ct": {"key": "state"}}, "op": "in", "right": {"set":
["established", "related"]}}}, {"accept": null}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain": "filter_FORWARD",
"expr": [{"match": {"left": {"ct": {"key": "status"}}, "op": "in",
"right": "dnat"}}, {"accept": null}]}}}, {"add": {"rule": {"family":
"inet", "table": "firewalld", "chain": "filter_FORWARD", "expr":
[{"match": {"left": {"meta": {"key": "iifname"}}, "op": "==",
"right": "lo"}}, {"accept": null}]}}}, {"add": {"chain": {"family":
"inet", "table": "firewalld", "name":
"filter_FORWARD_POLICIES_pre"}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_FORWARD", "expr": [{"jump":
{"target": "filter_FORWARD_POLICIES_pre"}}]}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"filter_FORWARD_IN_ZONES"}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_FORWARD", "expr": [{"jump":
{"target": "filter_FORWARD_IN_ZONES"}}]}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"filter_FORWARD_OUT_ZONES"}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_FORWARD", "expr": [{"jump":
{"target": "filter_FORWARD_OUT_ZONES"}}]}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"filter_FORWARD_POLICIES_post"}}}, {"add": {"rule": {"family":
"inet", "table": "firewalld", "chain": "filter_FORWARD", "expr":
[{"jump": {"target": "filter_FORWARD_POLICIES_post"}}]}}}, {"add":
{"rule": {"family": "inet", "table": "firewalld", "chain":
"filter_FORWARD", "expr": [{"match": {"left": {"ct": {"key":
"state"}}, "op": "in", "right": {"set": ["invalid"]}}}, {"drop":
null}]}}}, {"add": {"rule": {"family": "inet", "table": "firewalld",
"chain": "filter_FORWARD", "expr": [{"reject": {"type": "icmpx",
"expr": "admin-prohibited"}}]}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_OUTPUT", "expr": [{"match":
{"left": {"meta": {"key": "oifname"}}, "op": "==", "right": "lo"}},
{"accept": null}]}}}, {"add": {"chain": {"family": "inet", "table":
"firewalld", "name": "filter_OUTPUT_POLICIES_pre"}}}, {"add":
{"rule": {"family": "inet", "table": "firewalld", "chain":
"filter_OUTPUT", "expr": [{"jump": {"target":
"filter_OUTPUT_POLICIES_pre"}}]}}}, {"add": {"chain": {"family":
"inet", "table": "firewalld", "name":
"filter_OUTPUT_POLICIES_post"}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_OUTPUT", "expr": [{"jump":
{"target": "filter_OUTPUT_POLICIES_post"}}]}}}, {"insert": {"rule":
{"family": "inet", "table": "firewalld", "chain": "raw_PREROUTING",
"expr": [{"match": {"left": {"meta": {"key": "nfproto"}}, "op": "==",
"right": "ipv6"}}, {"match": {"left": {"fib": {"flags": ["saddr",
"iif"], "result": "oif"}}, "op": "==", "right": false}}, {"drop":
null}]}}}, {"insert": {"rule": {"family": "inet", "table":
"firewalld", "chain": "raw_PREROUTING", "expr": [{"match": {"left":
{"payload": {"protocol": "icmpv6", "field": "type"}}, "op": "==",
"right": {"set": ["nd-router-advert", "nd-neighbor-solicit"]}}},
{"accept": null}]}}}, {"add": {"rule": {"family": "inet", "table":
"firewalld", "chain": "filter_OUTPUT", "index": 0, "expr": [{"match":
{"left": {"payload": {"protocol": "ip6", "field": "daddr"}}, "op":
"==", "right": {"set": [{"prefix": {"addr": "::0.0.0.0", "len": 96}},
{"prefix": {"addr": "::ffff:0.0.0.0", "len": 96}}, {"prefix":
{"addr": "2002:0000::", "len": 24}}, {"prefix": {"addr":
"2002:0a00::", "len": 24}}, {"prefix": {"addr": "2002:7f00::", "len":
24}}, {"prefix": {"addr": "2002:ac10::", "len": 28}}, {"prefix":
{"addr": "2002:c0a8::", "len": 32}}, {"prefix": {"addr":
"2002:a9fe::", "len": 32}}, {"prefix": {"addr": "2002:e000::", "len":
19}}]}}}, {"reject": {"type": "icmpv6", "expr": "addr-
unreachable"}}]}}}, {"add": {"rule": {"family": "inet", "table":
"firewalld", "chain": "filter_FORWARD", "index": 2, "expr":
[{"match": {"left": {"payload": {"protocol": "ip6", "field":
"daddr"}}, "op": "==", "right": {"set": [{"prefix": {"addr":
"::0.0.0.0", "len": 96}}, {"prefix": {"addr": "::ffff:0.0.0.0",
"len": 96}}, {"prefix": {"addr": "2002:0000::", "len": 24}},
{"prefix": {"addr": "2002:0a00::", "len": 24}}, {"prefix": {"addr":
"2002:7f00::", "len": 24}}, {"prefix": {"addr": "2002:ac10::", "len":
28}}, {"prefix": {"addr": "2002:c0a8::", "len": 32}}, {"prefix":
{"addr": "2002:a9fe::", "len": 32}}, {"prefix": {"addr":
"2002:e000::", "len": 19}}]}}}, {"reject": {"type": "icmpv6", "expr":
"addr-unreachable"}}]}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "filter_IN_public"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"filter_IN_public_pre"}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "filter_IN_public_log"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"filter_IN_public_deny"}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "filter_IN_public_allow"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"filter_IN_public_post"}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_IN_public", "expr": [{"jump":
{"target": "filter_IN_public_pre"}}]}}}, {"add": {"rule": {"family":
"inet", "table": "firewalld", "chain": "filter_IN_public", "expr":
[{"jump": {"target": "filter_IN_public_log"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain": "filter_IN_public",
"expr": [{"jump": {"target": "filter_IN_public_deny"}}]}}}, {"add":
{"rule": {"family": "inet", "table": "firewalld", "chain":
"filter_IN_public", "expr": [{"jump": {"target":
"filter_IN_public_allow"}}]}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_IN_public", "expr": [{"jump":
{"target": "filter_IN_public_post"}}]}}}, {"add": {"rule": {"family":
"inet", "table": "firewalld", "chain": "filter_IN_public_allow",
"expr": [{"match": {"left": {"payload": {"protocol": "tcp", "field":
"dport"}}, "op": "==", "right": 22}}, {"match": {"left": {"ct":
{"key": "state"}}, "op": "in", "right": {"set": ["new",
"untracked"]}}}, {"accept": null}]}}}, {"add": {"rule": {"family":
"inet", "table": "firewalld", "chain": "filter_IN_public_allow",
"expr": [{"match": {"left": {"payload": {"protocol": "ip6", "field":
"daddr"}}, "op": "==", "right": {"prefix": {"addr": "fe80::", "len":
64}}}}, {"match": {"left": {"payload": {"protocol": "udp", "field":
"dport"}}, "op": "==", "right": 546}}, {"match": {"left": {"ct":
{"key": "state"}}, "op": "in", "right": {"set": ["new",
"untracked"]}}}, {"accept": null}]}}}, {"add": {"chain": {"family":
"inet", "table": "firewalld", "name": "filter_FWDO_public"}}},
{"add": {"chain": {"family": "inet", "table": "firewalld", "name":
"filter_FWDO_public_pre"}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "filter_FWDO_public_log"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"filter_FWDO_public_deny"}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "filter_FWDO_public_allow"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"filter_FWDO_public_post"}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_FWDO_public", "expr":
[{"jump": {"target": "filter_FWDO_public_pre"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_FWDO_public", "expr": [{"jump": {"target":
"filter_FWDO_public_log"}}]}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_FWDO_public", "expr":
[{"jump": {"target": "filter_FWDO_public_deny"}}]}}}, {"add":
{"rule": {"family": "inet", "table": "firewalld", "chain":
"filter_FWDO_public", "expr": [{"jump": {"target":
"filter_FWDO_public_allow"}}]}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_FWDO_public", "expr":
[{"jump": {"target": "filter_FWDO_public_post"}}]}}}, {"add":
{"chain": {"family": "ip", "table": "firewalld", "name":
"nat_POST_public"}}}, {"add": {"chain": {"family": "ip", "table":
"firewalld", "name": "nat_POST_public_pre"}}}, {"add": {"chain":
{"family": "ip", "table": "firewalld", "name":
"nat_POST_public_log"}}}, {"add": {"chain": {"family": "ip", "table":
"firewalld", "name": "nat_POST_public_deny"}}}, {"add": {"chain":
{"family": "ip", "table": "firewalld", "name":
"nat_POST_public_allow"}}}, {"add": {"chain": {"family": "ip",
"table": "firewalld", "name": "nat_POST_public_post"}}}, {"add":
{"rule": {"family": "ip", "table": "firewalld", "chain":
"nat_POST_public", "expr": [{"jump": {"target":
"nat_POST_public_pre"}}]}}}, {"add": {"rule": {"family": "ip",
"table": "firewalld", "chain": "nat_POST_public", "expr": [{"jump":
{"target": "nat_POST_public_log"}}]}}}, {"add": {"rule": {"family":
"ip", "table": "firewalld", "chain": "nat_POST_public", "expr":
[{"jump": {"target": "nat_POST_public_deny"}}]}}}, {"add": {"rule":
{"family": "ip", "table": "firewalld", "chain": "nat_POST_public",
"expr": [{"jump": {"target": "nat_POST_public_allow"}}]}}}, {"add":
{"rule": {"family": "ip", "table": "firewalld", "chain":
"nat_POST_public", "expr": [{"jump": {"target":
"nat_POST_public_post"}}]}}}, {"add": {"chain": {"family": "ip6",
"table": "firewalld", "name": "nat_POST_public"}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name":
"nat_POST_public_pre"}}}, {"add": {"chain": {"family": "ip6",
"table": "firewalld", "name": "nat_POST_public_log"}}}, {"add":
{"chain": {"family": "ip6", "table": "firewalld", "name":
"nat_POST_public_deny"}}}, {"add": {"chain": {"family": "ip6",
"table": "firewalld", "name": "nat_POST_public_allow"}}}, {"add":
{"chain": {"family": "ip6", "table": "firewalld", "name":
"nat_POST_public_post"}}}, {"add": {"rule": {"family": "ip6",
"table": "firewalld", "chain": "nat_POST_public", "expr": [{"jump":
{"target": "nat_POST_public_pre"}}]}}}, {"add": {"rule": {"family":
"ip6", "table": "firewalld", "chain": "nat_POST_public", "expr":
[{"jump": {"target": "nat_POST_public_log"}}]}}}, {"add": {"rule":
{"family": "ip6", "table": "firewalld", "chain": "nat_POST_public",
"expr": [{"jump": {"target": "nat_POST_public_deny"}}]}}}, {"add":
{"rule": {"family": "ip6", "table": "firewalld", "chain":
"nat_POST_public", "expr": [{"jump": {"target":
"nat_POST_public_allow"}}]}}}, {"add": {"rule": {"family": "ip6",
"table": "firewalld", "chain": "nat_POST_public", "expr": [{"jump":
{"target": "nat_POST_public_post"}}]}}}, {"add": {"chain": {"family":
"inet", "table": "firewalld", "name": "filter_FWDI_public"}}},
{"add": {"chain": {"family": "inet", "table": "firewalld", "name":
"filter_FWDI_public_pre"}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "filter_FWDI_public_log"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"filter_FWDI_public_deny"}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "filter_FWDI_public_allow"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"filter_FWDI_public_post"}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_FWDI_public", "expr":
[{"jump": {"target": "filter_FWDI_public_pre"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_FWDI_public", "expr": [{"jump": {"target":
"filter_FWDI_public_log"}}]}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_FWDI_public", "expr":
[{"jump": {"target": "filter_FWDI_public_deny"}}]}}}, {"add":
{"rule": {"family": "inet", "table": "firewalld", "chain":
"filter_FWDI_public", "expr": [{"jump": {"target":
"filter_FWDI_public_allow"}}]}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_FWDI_public", "expr":
[{"jump": {"target": "filter_FWDI_public_post"}}]}}}, {"add":
{"chain": {"family": "ip", "table": "firewalld", "name":
"nat_PRE_public"}}}, {"add": {"chain": {"family": "ip", "table":
"firewalld", "name": "nat_PRE_public_pre"}}}, {"add": {"chain":
{"family": "ip", "table": "firewalld", "name":
"nat_PRE_public_log"}}}, {"add": {"chain": {"family": "ip", "table":
"firewalld", "name": "nat_PRE_public_deny"}}}, {"add": {"chain":
{"family": "ip", "table": "firewalld", "name":
"nat_PRE_public_allow"}}}, {"add": {"chain": {"family": "ip",
"table": "firewalld", "name": "nat_PRE_public_post"}}}, {"add":
{"rule": {"family": "ip", "table": "firewalld", "chain":
"nat_PRE_public", "expr": [{"jump": {"target":
"nat_PRE_public_pre"}}]}}}, {"add": {"rule": {"family": "ip",
"table": "firewalld", "chain": "nat_PRE_public", "expr": [{"jump":
{"target": "nat_PRE_public_log"}}]}}}, {"add": {"rule": {"family":
"ip", "table": "firewalld", "chain": "nat_PRE_public", "expr":
[{"jump": {"target": "nat_PRE_public_deny"}}]}}}, {"add": {"rule":
{"family": "ip", "table": "firewalld", "chain": "nat_PRE_public",
"expr": [{"jump": {"target": "nat_PRE_public_allow"}}]}}}, {"add":
{"rule": {"family": "ip", "table": "firewalld", "chain":
"nat_PRE_public", "expr": [{"jump": {"target":
"nat_PRE_public_post"}}]}}}, {"add": {"chain": {"family": "ip6",
"table": "firewalld", "name": "nat_PRE_public"}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name":
"nat_PRE_public_pre"}}}, {"add": {"chain": {"family": "ip6", "table":
"firewalld", "name": "nat_PRE_public_log"}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name":
"nat_PRE_public_deny"}}}, {"add": {"chain": {"family": "ip6",
"table": "firewalld", "name": "nat_PRE_public_allow"}}}, {"add":
{"chain": {"family": "ip6", "table": "firewalld", "name":
"nat_PRE_public_post"}}}, {"add": {"rule": {"family": "ip6", "table":
"firewalld", "chain": "nat_PRE_public", "expr": [{"jump": {"target":
"nat_PRE_public_pre"}}]}}}, {"add": {"rule": {"family": "ip6",
"table": "firewalld", "chain": "nat_PRE_public", "expr": [{"jump":
{"target": "nat_PRE_public_log"}}]}}}, {"add": {"rule": {"family":
"ip6", "table": "firewalld", "chain": "nat_PRE_public", "expr":
[{"jump": {"target": "nat_PRE_public_deny"}}]}}}, {"add": {"rule":
{"family": "ip6", "table": "firewalld", "chain": "nat_PRE_public",
"expr": [{"jump": {"target": "nat_PRE_public_allow"}}]}}}, {"add":
{"rule": {"family": "ip6", "table": "firewalld", "chain":
"nat_PRE_public", "expr": [{"jump": {"target":
"nat_PRE_public_post"}}]}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "mangle_PRE_public"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"mangle_PRE_public_pre"}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "mangle_PRE_public_log"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"mangle_PRE_public_deny"}}}, {"add": {"chain": {"family": "inet",
"table": "firewalld", "name": "mangle_PRE_public_allow"}}}, {"add":
{"chain": {"family": "inet", "table": "firewalld", "name":
"mangle_PRE_public_post"}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "mangle_PRE_public", "expr": [{"jump":
{"target": "mangle_PRE_public_pre"}}]}}}, {"add": {"rule": {"family":
"inet", "table": "firewalld", "chain": "mangle_PRE_public", "expr":
[{"jump": {"target": "mangle_PRE_public_log"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"mangle_PRE_public", "expr": [{"jump": {"target":
"mangle_PRE_public_deny"}}]}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "mangle_PRE_public", "expr": [{"jump":
{"target": "mangle_PRE_public_allow"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"mangle_PRE_public", "expr": [{"jump": {"target":
"mangle_PRE_public_post"}}]}}}, {"add": {"rule": {"family": "inet",
"table": "firewalld", "chain": "filter_IN_public", "index": 4,
"expr": [{"match": {"left": {"meta": {"key": "l4proto"}}, "op": "==",
"right": {"set": ["icmp", "icmpv6"]}}}, {"accept": null}]}}}, {"add":
{"rule": {"family": "inet", "table": "firewalld", "chain":
"filter_FWDI_public", "index": 4, "expr": [{"match": {"left":
{"meta": {"key": "l4proto"}}, "op": "==", "right": {"set": ["icmp",
"icmpv6"]}}}, {"accept": null}]}}}, {"add": {"rule": {"family":
"inet", "table": "firewalld", "chain": "filter_INPUT_ZONES", "expr":
[{"goto": {"target": "filter_IN_public"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_FORWARD_OUT_ZONES", "expr": [{"goto": {"target":
"filter_FWDO_public"}}]}}}, {"add": {"rule": {"family": "ip",
"table": "firewalld", "chain": "nat_POSTROUTING_ZONES", "expr":
[{"goto": {"target": "nat_POST_public"}}]}}}, {"add": {"rule":
{"family": "ip6", "table": "firewalld", "chain":
"nat_POSTROUTING_ZONES", "expr": [{"goto": {"target":
"nat_POST_public"}}]}}}, {"add": {"rule": {"family": "inet", "table":
"firewalld", "chain": "filter_FORWARD_IN_ZONES", "expr": [{"goto":
{"target": "filter_FWDI_public"}}]}}}, {"add": {"rule": {"family":
"ip", "table": "firewalld", "chain": "nat_PREROUTING_ZONES", "expr":
[{"goto": {"target": "nat_PRE_public"}}]}}}, {"add": {"rule":
{"family": "ip6", "table": "firewalld", "chain":
"nat_PREROUTING_ZONES", "expr": [{"goto": {"target":
"nat_PRE_public"}}]}}}, {"add": {"rule": {"family": "inet", "table":
"firewalld", "chain": "mangle_PREROUTING_ZONES", "expr": [{"goto":
{"target": "mangle_PRE_public"}}]}}}, {"add": {"chain": {"family":
"inet", "table": "firewalld", "name": "filter_IN_policy_allow-host-
ipv6"}}}, {"add": {"chain": {"family": "inet", "table": "firewalld",
"name": "filter_IN_policy_allow-host-ipv6_pre"}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"filter_IN_policy_allow-host-ipv6_log"}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"filter_IN_policy_allow-host-ipv6_deny"}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"filter_IN_policy_allow-host-ipv6_allow"}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"filter_IN_policy_allow-host-ipv6_post"}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_IN_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"filter_IN_policy_allow-host-ipv6_pre"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_IN_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"filter_IN_policy_allow-host-ipv6_log"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_IN_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"filter_IN_policy_allow-host-ipv6_deny"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_IN_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"filter_IN_policy_allow-host-ipv6_allow"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_IN_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"filter_IN_policy_allow-host-ipv6_post"}}]}}}, {"add": {"chain":
{"family": "ip", "table": "firewalld", "name": "nat_PRE_policy_allow-
host-ipv6"}}}, {"add": {"chain": {"family": "ip", "table":
"firewalld", "name": "nat_PRE_policy_allow-host-ipv6_pre"}}}, {"add":
{"chain": {"family": "ip", "table": "firewalld", "name":
"nat_PRE_policy_allow-host-ipv6_log"}}}, {"add": {"chain": {"family":
"ip", "table": "firewalld", "name": "nat_PRE_policy_allow-host-
ipv6_deny"}}}, {"add": {"chain": {"family": "ip", "table":
"firewalld", "name": "nat_PRE_policy_allow-host-ipv6_allow"}}},
{"add": {"chain": {"family": "ip", "table": "firewalld", "name":
"nat_PRE_policy_allow-host-ipv6_post"}}}, {"add": {"rule": {"family":
"ip", "table": "firewalld", "chain": "nat_PRE_policy_allow-host-
ipv6", "expr": [{"jump": {"target": "nat_PRE_policy_allow-host-
ipv6_pre"}}]}}}, {"add": {"rule": {"family": "ip", "table":
"firewalld", "chain": "nat_PRE_policy_allow-host-ipv6", "expr":
[{"jump": {"target": "nat_PRE_policy_allow-host-ipv6_log"}}]}}},
{"add": {"rule": {"family": "ip", "table": "firewalld", "chain":
"nat_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"nat_PRE_policy_allow-host-ipv6_deny"}}]}}}, {"add": {"rule":
{"family": "ip", "table": "firewalld", "chain":
"nat_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"nat_PRE_policy_allow-host-ipv6_allow"}}]}}}, {"add": {"rule":
{"family": "ip", "table": "firewalld", "chain":
"nat_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"nat_PRE_policy_allow-host-ipv6_post"}}]}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name":
"nat_PRE_policy_allow-host-ipv6"}}}, {"add": {"chain": {"family":
"ip6", "table": "firewalld", "name": "nat_PRE_policy_allow-host-
ipv6_pre"}}}, {"add": {"chain": {"family": "ip6", "table":
"firewalld", "name": "nat_PRE_policy_allow-host-ipv6_log"}}}, {"add":
{"chain": {"family": "ip6", "table": "firewalld", "name":
"nat_PRE_policy_allow-host-ipv6_deny"}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name":
"nat_PRE_policy_allow-host-ipv6_allow"}}}, {"add": {"chain":
{"family": "ip6", "table": "firewalld", "name":
"nat_PRE_policy_allow-host-ipv6_post"}}}, {"add": {"rule": {"family":
"ip6", "table": "firewalld", "chain": "nat_PRE_policy_allow-host-
ipv6", "expr": [{"jump": {"target": "nat_PRE_policy_allow-host-
ipv6_pre"}}]}}}, {"add": {"rule": {"family": "ip6", "table":
"firewalld", "chain": "nat_PRE_policy_allow-host-ipv6", "expr":
[{"jump": {"target": "nat_PRE_policy_allow-host-ipv6_log"}}]}}},
{"add": {"rule": {"family": "ip6", "table": "firewalld", "chain":
"nat_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"nat_PRE_policy_allow-host-ipv6_deny"}}]}}}, {"add": {"rule":
{"family": "ip6", "table": "firewalld", "chain":
"nat_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"nat_PRE_policy_allow-host-ipv6_allow"}}]}}}, {"add": {"rule":
{"family": "ip6", "table": "firewalld", "chain":
"nat_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"nat_PRE_policy_allow-host-ipv6_post"}}]}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"mangle_PRE_policy_allow-host-ipv6"}}}, {"add": {"chain": {"family":
"inet", "table": "firewalld", "name": "mangle_PRE_policy_allow-host-
ipv6_pre"}}}, {"add": {"chain": {"family": "inet", "table":
"firewalld", "name": "mangle_PRE_policy_allow-host-ipv6_log"}}},
{"add": {"chain": {"family": "inet", "table": "firewalld", "name":
"mangle_PRE_policy_allow-host-ipv6_deny"}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"mangle_PRE_policy_allow-host-ipv6_allow"}}}, {"add": {"chain":
{"family": "inet", "table": "firewalld", "name":
"mangle_PRE_policy_allow-host-ipv6_post"}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"mangle_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"mangle_PRE_policy_allow-host-ipv6_pre"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"mangle_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"mangle_PRE_policy_allow-host-ipv6_log"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"mangle_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"mangle_PRE_policy_allow-host-ipv6_deny"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"mangle_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"mangle_PRE_policy_allow-host-ipv6_allow"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"mangle_PRE_policy_allow-host-ipv6", "expr": [{"jump": {"target":
"mangle_PRE_policy_allow-host-ipv6_post"}}]}}}, {"insert": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_INPUT_POLICIES_pre", "expr": [{"jump": {"target":
"filter_IN_policy_allow-host-ipv6"}}]}}}, {"insert": {"rule":
{"family": "ip", "table": "firewalld", "chain":
"nat_PREROUTING_POLICIES_pre", "expr": [{"jump": {"target":
"nat_PRE_policy_allow-host-ipv6"}}]}}}, {"insert": {"rule":
{"family": "ip6", "table": "firewalld", "chain":
"nat_PREROUTING_POLICIES_pre", "expr": [{"jump": {"target":
"nat_PRE_policy_allow-host-ipv6"}}]}}}, {"insert": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"mangle_PREROUTING_POLICIES_pre", "expr": [{"jump": {"target":
"mangle_PRE_policy_allow-host-ipv6"}}]}}}, {"add": {"rule":
{"family": "inet", "table": "firewalld", "chain":
"filter_IN_policy_allow-host-ipv6_allow", "expr": [{"match": {"left":
{"meta": {"key": "nfproto"}}, "op": "==", "right": "ipv6"}},
{"match": {"left": {"payload": {"protocol": "icmpv6", "field":
"type"}}, "op": "==", "right": "nd-neighbor-advert"}}, {"accept":
null}]}}}, {"add": {"rule": {"family": "inet", "table": "firewalld",
"chain": "filter_IN_policy_allow-host-ipv6_allow", "expr": [{"match":
{"left": {"meta": {"key": "nfproto"}}, "op": "==", "right": "ipv6"}},
{"match": {"left": {"payload": {"protocol": "icmpv6", "field":
"type"}}, "op": "==", "right": "nd-neighbor-solicit"}}, {"accept":
null}]}}}, {"add": {"rule": {"family": "inet", "table": "firewalld",
"chain": "filter_IN_policy_allow-host-ipv6_allow", "expr": [{"match":
{"left": {"meta": {"key": "nfproto"}}, "op": "==", "right": "ipv6"}},
{"match": {"left": {"payload": {"protocol": "icmpv6", "field":
"type"}}, "op": "==", "right": "nd-router-advert"}}, {"accept":
null}]}}}, {"add": {"rule": {"family": "inet", "table": "firewalld",
"chain": "filter_IN_policy_allow-host-ipv6_allow", "expr": [{"match":
{"left": {"meta": {"key": "nfproto"}}, "op": "==", "right": "ipv6"}},
{"match": {"left": {"payload": {"protocol": "icmpv6", "field":
"type"}}, "op": "==", "right": "nd-redirect"}}, {"accept":
null}]}}}]}

--
Regards,
Sateesh


--
# Randy MacLeod
# Wind River Linux


[meta-security][PATCH 1/1] LICENSE: adopt SPDX standard names

Joe Slater <joe.slater@...>
 

From: Robert Yang <liezhi.yang@...>

Modify LICENSE for ding-libs and libmhash.

Signed-off-by: Joe Slater <joe.slater@...>
---
recipes-security/libdhash/ding-libs_0.6.1.bb | 2 +-
recipes-security/libmhash/libmhash_0.9.9.9.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-security/libdhash/ding-libs_0.6.1.bb b/recipes-security/libdhash/ding-libs_0.6.1.bb
index 6046fa0..843850f 100644
--- a/recipes-security/libdhash/ding-libs_0.6.1.bb
+++ b/recipes-security/libdhash/ding-libs_0.6.1.bb
@@ -2,7 +2,7 @@ SUMMARY = "Dynamic hash table implementation"
DESCRIPTION = "Dynamic hash table implementation"
HOMEPAGE = "https://fedorahosted.org/released/ding-libs"
SECTION = "base"
-LICENSE = "GPLv3+"
+LICENSE = "GPL-3.0-or-later"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"

SRC_URI = "https://fedorahosted.org/released/${BPN}/${BP}.tar.gz"
diff --git a/recipes-security/libmhash/libmhash_0.9.9.9.bb b/recipes-security/libmhash/libmhash_0.9.9.9.bb
index 9b34cb1..35c5ff8 100644
--- a/recipes-security/libmhash/libmhash_0.9.9.9.bb
+++ b/recipes-security/libmhash/libmhash_0.9.9.9.bb
@@ -7,7 +7,7 @@ DESCRIPTION = "\
"
HOMEPAGE = "http://mhash.sourceforge.net/"

-LICENSE = "LGPLv2.0"
+LICENSE = "LGPL-2.0-only"
LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"

S = "${WORKDIR}/mhash-${PV}"
--
2.35.1


Re: Yocto poky/meta/recipes-devtool/perl

Alexander Kanavin
 

Can you please attach log.do_patch where the problem can be seen?

Alex

On Tue, 29 Mar 2022 at 15:11, Mike Ulan <mausvt@...> wrote:

Hi,
I have the question: is anybody aware that patches in a recipe are not fully applied?

When retrieved the archive for package unpacked.
Аttributes of multiple files are set as readonly.

For 5.30.1 https://www.cpan.org/src/5.0/perl-${PV}.tar.gz;name=perl
or for 5.22.1 and 5.22 and 5.20 http://www.cpan.org/src/5.0/${BP}.tar.xz
lots of read only files in archives.

Form man of Patch behavior --read-only=warn by default.
So files to be patched with read only attributes remain unchanged.

For override patch default behavior on --read-only, i placed in poky/bitbake/bin file with name patch and content:
#!/bin/sh
/usr/bin/patch --read-only=fail "$@"
exvar=$?
echo "patch wraper readonly fail" "$@"
perror $exvar
exit $exvar

And as a clearly predictable result, the build of perl failed.
To fix problem and apply all patches and particularly my patch to backport issue for my host environment
I added to perl_${PV}.bb recipe this:
do_patch_prepend() {
os.system('chmod -R +rw %s' % d.getVar('S'))
}




Re: [meta-security][PATCH 1/1] LICENSE: adopt standard SPDX names

Joe Slater <joe.slater@...>
 

I'll send again for ding-libs and libmhash. Joe

-----Original Message-----
From: akuster808 <akuster808@...>
Sent: Tuesday, March 29, 2022 1:27 PM
To: Slater, Joseph <joe.slater@...>; yocto@...
Cc: MacLeod, Randy <Randy.MacLeod@...>
Subject: Re: [yocto] [meta-security][PATCH 1/1] LICENSE: adopt standard SPDX
names



On 3/29/22 09:18, Joe Slater wrote:
Correct LICENSE for samhain, ecrypt-utils, ding-libs, libmhash, and
sssd.

Signed-off-by: Joe Slater <joe.slater@...>
---
recipes-ids/samhain/samhain.inc | 2 +-
recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb | 2 +-
recipes-security/libdhash/ding-libs_0.6.1.bb | 2 +-
recipes-security/libmhash/libmhash_0.9.9.9.bb | 2 +-
recipes-security/sssd/sssd_2.5.2.bb | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
Mater-next has these.

https://git.yoctoproject.org/meta-security/commit/?h=master-
next&id=ece41f7543bbd42c57f4208c7309f90cbd02e852

Looks like a few more need to be added based on these changes.

-armin

diff --git a/recipes-ids/samhain/samhain.inc
b/recipes-ids/samhain/samhain.inc index 077e118..fe0718d 100644
--- a/recipes-ids/samhain/samhain.inc
+++ b/recipes-ids/samhain/samhain.inc
@@ -1,6 +1,6 @@
DESCRIPTION = "Provides file integrity checking and log file
monitoring/analysis"
HOMEPAGE = "http://www.la-samhna.de/samhain/"
-LICENSE = "GPLv2"
+LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM =
"file://LICENSE;md5=8ca43cbc842c2336e835926c2166c28b"

PV = "4.4.6"
diff --git a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
index 9aefc32..5f8cf3c 100644
--- a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
+++ b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
@@ -6,7 +6,7 @@ DESCRIPTION = "eCryptfs is a stacked cryptographic
filesystem \
HOMEPAGE = "https://launchpad.net/ecryptfs"
SECTION = "base"

-LICENSE = "GPL-2.0"
+LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM =
"file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b"

DEPENDS = "keyutils libgcrypt intltool-native glib-2.0-native"
diff --git a/recipes-security/libdhash/ding-libs_0.6.1.bb
b/recipes-security/libdhash/ding-libs_0.6.1.bb
index 6046fa0..843850f 100644
--- a/recipes-security/libdhash/ding-libs_0.6.1.bb
+++ b/recipes-security/libdhash/ding-libs_0.6.1.bb
@@ -2,7 +2,7 @@ SUMMARY = "Dynamic hash table implementation"
DESCRIPTION = "Dynamic hash table implementation"
HOMEPAGE = "https://fedorahosted.org/released/ding-libs"
SECTION = "base"
-LICENSE = "GPLv3+"
+LICENSE = "GPL-3.0-or-later"
LIC_FILES_CHKSUM =
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"

SRC_URI = "https://fedorahosted.org/released/${BPN}/${BP}.tar.gz"
diff --git a/recipes-security/libmhash/libmhash_0.9.9.9.bb
b/recipes-security/libmhash/libmhash_0.9.9.9.bb
index 9b34cb1..35c5ff8 100644
--- a/recipes-security/libmhash/libmhash_0.9.9.9.bb
+++ b/recipes-security/libmhash/libmhash_0.9.9.9.bb
@@ -7,7 +7,7 @@ DESCRIPTION = "\
"
HOMEPAGE = "http://mhash.sourceforge.net/"

-LICENSE = "LGPLv2.0"
+LICENSE = "LGPL-2.0-only"
LIC_FILES_CHKSUM =
"file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"

S = "${WORKDIR}/mhash-${PV}"
diff --git a/recipes-security/sssd/sssd_2.5.2.bb
b/recipes-security/sssd/sssd_2.5.2.bb
index 8bc8787..9f1d627 100644
--- a/recipes-security/sssd/sssd_2.5.2.bb
+++ b/recipes-security/sssd/sssd_2.5.2.bb
@@ -2,7 +2,7 @@ SUMMARY = "system security services daemon"
DESCRIPTION = "SSSD is a system security services daemon"
HOMEPAGE = "https://pagure.io/SSSD/sssd/"
SECTION = "base"
-LICENSE = "GPLv3+"
+LICENSE = "GPL-3.0-or-later"
LIC_FILES_CHKSUM =
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"

DEPENDS = "acl attr openldap cyrus-sasl libtdb ding-libs libpam c-ares krb5
autoconf-archive"



Re: [meta-security][PATCH 1/1] LICENSE: adopt standard SPDX names

Armin Kuster
 

On 3/29/22 09:18, Joe Slater wrote:
Correct LICENSE for samhain, ecrypt-utils, ding-libs,
libmhash, and sssd.

Signed-off-by: Joe Slater <joe.slater@...>
---
recipes-ids/samhain/samhain.inc | 2 +-
recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb | 2 +-
recipes-security/libdhash/ding-libs_0.6.1.bb | 2 +-
recipes-security/libmhash/libmhash_0.9.9.9.bb | 2 +-
recipes-security/sssd/sssd_2.5.2.bb | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
Mater-next has these.

https://git.yoctoproject.org/meta-security/commit/?h=master-next&id=ece41f7543bbd42c57f4208c7309f90cbd02e852

Looks like a few more need to be added based on these changes.

-armin

diff --git a/recipes-ids/samhain/samhain.inc b/recipes-ids/samhain/samhain.inc
index 077e118..fe0718d 100644
--- a/recipes-ids/samhain/samhain.inc
+++ b/recipes-ids/samhain/samhain.inc
@@ -1,6 +1,6 @@
DESCRIPTION = "Provides file integrity checking and log file monitoring/analysis"
HOMEPAGE = "http://www.la-samhna.de/samhain/"
-LICENSE = "GPLv2"
+LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM = "file://LICENSE;md5=8ca43cbc842c2336e835926c2166c28b"
PV = "4.4.6"
diff --git a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
index 9aefc32..5f8cf3c 100644
--- a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
+++ b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
@@ -6,7 +6,7 @@ DESCRIPTION = "eCryptfs is a stacked cryptographic filesystem \
HOMEPAGE = "https://launchpad.net/ecryptfs"
SECTION = "base"
-LICENSE = "GPL-2.0"
+LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b"
DEPENDS = "keyutils libgcrypt intltool-native glib-2.0-native"
diff --git a/recipes-security/libdhash/ding-libs_0.6.1.bb b/recipes-security/libdhash/ding-libs_0.6.1.bb
index 6046fa0..843850f 100644
--- a/recipes-security/libdhash/ding-libs_0.6.1.bb
+++ b/recipes-security/libdhash/ding-libs_0.6.1.bb
@@ -2,7 +2,7 @@ SUMMARY = "Dynamic hash table implementation"
DESCRIPTION = "Dynamic hash table implementation"
HOMEPAGE = "https://fedorahosted.org/released/ding-libs"
SECTION = "base"
-LICENSE = "GPLv3+"
+LICENSE = "GPL-3.0-or-later"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
SRC_URI = "https://fedorahosted.org/released/${BPN}/${BP}.tar.gz"
diff --git a/recipes-security/libmhash/libmhash_0.9.9.9.bb b/recipes-security/libmhash/libmhash_0.9.9.9.bb
index 9b34cb1..35c5ff8 100644
--- a/recipes-security/libmhash/libmhash_0.9.9.9.bb
+++ b/recipes-security/libmhash/libmhash_0.9.9.9.bb
@@ -7,7 +7,7 @@ DESCRIPTION = "\
"
HOMEPAGE = "http://mhash.sourceforge.net/"
-LICENSE = "LGPLv2.0"
+LICENSE = "LGPL-2.0-only"
LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
S = "${WORKDIR}/mhash-${PV}"
diff --git a/recipes-security/sssd/sssd_2.5.2.bb b/recipes-security/sssd/sssd_2.5.2.bb
index 8bc8787..9f1d627 100644
--- a/recipes-security/sssd/sssd_2.5.2.bb
+++ b/recipes-security/sssd/sssd_2.5.2.bb
@@ -2,7 +2,7 @@ SUMMARY = "system security services daemon"
DESCRIPTION = "SSSD is a system security services daemon"
HOMEPAGE = "https://pagure.io/SSSD/sssd/"
SECTION = "base"
-LICENSE = "GPLv3+"
+LICENSE = "GPL-3.0-or-later"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
DEPENDS = "acl attr openldap cyrus-sasl libtdb ding-libs libpam c-ares krb5 autoconf-archive"


Re: [meta-security][PATCH] openscap-daemon: inherit python_setuptools_build_meta

Armin Kuster
 

On 3/27/22 19:25, Chen Qi wrote:
setuptools_build_meta has been renamed to python_setuptools_build_meta.

Signed-off-by: Chen Qi <Qi.Chen@...>
---
.../recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb b/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb
index cf6d531..9659323 100644
--- a/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb
+++ b/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb
@@ -13,7 +13,7 @@ SRC_URI = "git://github.com/OpenSCAP/openscap-daemon.git;branch=master;protocol=
file://0001-Renamed-module-and-variables-to-get-rid-of-async.patch \
"
-inherit setuptools_build_meta
+inherit python_setuptools_build_meta
I believe this is sitting in master-next.
https://git.yoctoproject.org/meta-security/commit/?h=master-next&id=398047a7a6310b1ef70d22430fb6df4effd8cf92

S = "${WORKDIR}/git"

2081 - 2100 of 58635