Date   

[meta-security][PATCh] oeqa: fix checksec runtime test

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
lib/oeqa/runtime/cases/checksec.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/oeqa/runtime/cases/checksec.py b/lib/oeqa/runtime/cases/checksec.py
index e46744c..53e6c1d 100644
--- a/lib/oeqa/runtime/cases/checksec.py
+++ b/lib/oeqa/runtime/cases/checksec.py
@@ -19,7 +19,7 @@ class CheckSecTest(OERuntimeTestCase):

@OETestDepends(['checksec.CheckSecTest.test_checksec_help'])
def test_checksec_xml(self):
- status, output = self.target.run('checksec --format xml --proc-all')
+ status, output = self.target.run('checksec --format=xml --proc=1')
msg = ('checksec xml failed. Output: %s' % output)
self.assertEqual(status, 0, msg = msg)

--
2.25.1


[meta-security][PATCH 4/4] packagegroup-core-security.bbappend: add sssd

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
.../packagegroup/packagegroup-core-security.bbappend | 4 ++++
1 file changed, 4 insertions(+)
create mode 100644 dynamic-layers/networking-layer/recipes-core/packagegroup/packagegroup-core-security.bbappend

diff --git a/dynamic-layers/networking-layer/recipes-core/packagegroup/packagegroup-core-security.bbappend b/dynamic-layers/networking-layer/recipes-core/packagegroup/packagegroup-core-security.bbappend
new file mode 100644
index 0000000..6bafd9f
--- /dev/null
+++ b/dynamic-layers/networking-layer/recipes-core/packagegroup/packagegroup-core-security.bbappend
@@ -0,0 +1,4 @@
+
+RDEPENDS:packagegroup-security-utils += "\
+ ${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd", "",d)} \
+"
--
2.25.1


[meta-security][PATCH 3/4] packagegroup-core-security: drop sssd

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index f381d91..636563f 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -36,7 +36,7 @@ RDEPENDS:packagegroup-security-utils = "\
softhsm \
sshguard \
${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 ", "", " libseccomp",d)} \
- ${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd google-authenticator-libpam", "",d)} \
+ ${@bb.utils.contains("DISTRO_FEATURES", "pam", "google-authenticator-libpam", "",d)} \
${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils packctl", "",d)} \
"

--
2.25.1


[meta-security][PATCH 2/4] layer.conf:add meta-netorking to BBFILES_DYNAMIC

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
conf/layer.conf | 2 ++
1 file changed, 2 insertions(+)

diff --git a/conf/layer.conf b/conf/layer.conf
index fa7d79e..470c7f6 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -18,6 +18,8 @@ BBFILES_DYNAMIC += " \
perl-layer:${LAYERDIR}/dynamic-layers/meta-perl/recipes-*/*/*.bbappend \
meta-python:${LAYERDIR}/dynamic-layers/meta-python/recipes-*/*/*.bb \
meta-python:${LAYERDIR}/dynamic-layers/meta-python/recipes-*/*/*.bbappend \
+ networking-layer:${LAYERDIR}/dynamic-layers/networking-layer/recipes-*/*/*.bb \
+ networking-layer:${LAYERDIR}/dynamic-layers/networking-layer/recipes-*/*/*.bbappend \
"

# Sanity check for meta-security layer.
--
2.25.1


[meta-security][PATCH 1/4] sssd:move to dynamic networking-layer

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
.../recipes-security}/sssd/files/CVE-2021-3621.patch | 0
.../recipes-security}/sssd/files/drop_ntpdate_chk.patch | 0
.../recipes-security}/sssd/files/fix-ldblibdir.patch | 0
.../networking-layer/recipes-security}/sssd/files/fix_gid.patch | 0
.../recipes-security}/sssd/files/musl_fixup.patch | 0
.../networking-layer/recipes-security}/sssd/files/no_gen.patch | 0
.../networking-layer/recipes-security}/sssd/files/sssd.conf | 0
.../recipes-security}/sssd/files/volatiles.99_sssd | 0
.../networking-layer/recipes-security}/sssd/sssd_2.5.2.bb | 0
9 files changed, 0 insertions(+), 0 deletions(-)
rename {recipes-security => dynamic-layers/networking-layer/recipes-security}/sssd/files/CVE-2021-3621.patch (100%)
rename {recipes-security => dynamic-layers/networking-layer/recipes-security}/sssd/files/drop_ntpdate_chk.patch (100%)
rename {recipes-security => dynamic-layers/networking-layer/recipes-security}/sssd/files/fix-ldblibdir.patch (100%)
rename {recipes-security => dynamic-layers/networking-layer/recipes-security}/sssd/files/fix_gid.patch (100%)
rename {recipes-security => dynamic-layers/networking-layer/recipes-security}/sssd/files/musl_fixup.patch (100%)
rename {recipes-security => dynamic-layers/networking-layer/recipes-security}/sssd/files/no_gen.patch (100%)
rename {recipes-security => dynamic-layers/networking-layer/recipes-security}/sssd/files/sssd.conf (100%)
rename {recipes-security => dynamic-layers/networking-layer/recipes-security}/sssd/files/volatiles.99_sssd (100%)
rename {recipes-security => dynamic-layers/networking-layer/recipes-security}/sssd/sssd_2.5.2.bb (100%)

diff --git a/recipes-security/sssd/files/CVE-2021-3621.patch b/dynamic-layers/networking-layer/recipes-security/sssd/files/CVE-2021-3621.patch
similarity index 100%
rename from recipes-security/sssd/files/CVE-2021-3621.patch
rename to dynamic-layers/networking-layer/recipes-security/sssd/files/CVE-2021-3621.patch
diff --git a/recipes-security/sssd/files/drop_ntpdate_chk.patch b/dynamic-layers/networking-layer/recipes-security/sssd/files/drop_ntpdate_chk.patch
similarity index 100%
rename from recipes-security/sssd/files/drop_ntpdate_chk.patch
rename to dynamic-layers/networking-layer/recipes-security/sssd/files/drop_ntpdate_chk.patch
diff --git a/recipes-security/sssd/files/fix-ldblibdir.patch b/dynamic-layers/networking-layer/recipes-security/sssd/files/fix-ldblibdir.patch
similarity index 100%
rename from recipes-security/sssd/files/fix-ldblibdir.patch
rename to dynamic-layers/networking-layer/recipes-security/sssd/files/fix-ldblibdir.patch
diff --git a/recipes-security/sssd/files/fix_gid.patch b/dynamic-layers/networking-layer/recipes-security/sssd/files/fix_gid.patch
similarity index 100%
rename from recipes-security/sssd/files/fix_gid.patch
rename to dynamic-layers/networking-layer/recipes-security/sssd/files/fix_gid.patch
diff --git a/recipes-security/sssd/files/musl_fixup.patch b/dynamic-layers/networking-layer/recipes-security/sssd/files/musl_fixup.patch
similarity index 100%
rename from recipes-security/sssd/files/musl_fixup.patch
rename to dynamic-layers/networking-layer/recipes-security/sssd/files/musl_fixup.patch
diff --git a/recipes-security/sssd/files/no_gen.patch b/dynamic-layers/networking-layer/recipes-security/sssd/files/no_gen.patch
similarity index 100%
rename from recipes-security/sssd/files/no_gen.patch
rename to dynamic-layers/networking-layer/recipes-security/sssd/files/no_gen.patch
diff --git a/recipes-security/sssd/files/sssd.conf b/dynamic-layers/networking-layer/recipes-security/sssd/files/sssd.conf
similarity index 100%
rename from recipes-security/sssd/files/sssd.conf
rename to dynamic-layers/networking-layer/recipes-security/sssd/files/sssd.conf
diff --git a/recipes-security/sssd/files/volatiles.99_sssd b/dynamic-layers/networking-layer/recipes-security/sssd/files/volatiles.99_sssd
similarity index 100%
rename from recipes-security/sssd/files/volatiles.99_sssd
rename to dynamic-layers/networking-layer/recipes-security/sssd/files/volatiles.99_sssd
diff --git a/recipes-security/sssd/sssd_2.5.2.bb b/dynamic-layers/networking-layer/recipes-security/sssd/sssd_2.5.2.bb
similarity index 100%
rename from recipes-security/sssd/sssd_2.5.2.bb
rename to dynamic-layers/networking-layer/recipes-security/sssd/sssd_2.5.2.bb
--
2.25.1


Re: Question about psuedo abort errors

Richard Purdie
 

On Thu, 2022-06-09 at 10:38 -0600, Rusty Howell wrote:
My company is using yocto.  When building our own recipes, I get
pseudo abort errors rather often.  I've read the wiki page about
them, but I'm not sure exactly what we are doing wrong that is making
this happen.  We have many recipes for various libraries and
applications.  The files listed in the abort error log are usually
C++ header files.

A coworker has told me that setting PACKAGE_DEBUG_SPLIT_STYLE =
"debug-without-src" in the local.conf will allow bitbake to ignore
this error. But in the end, I would like to understand what exactly
is the root cause, so that I can adjust our recipes to fix this.

Here is the pseudo.log from the most recent failure. I know a lot of
proprietary context is missing for anyone in the OSS community to
give super confident answers, but I appreciate any suggestions.

Some context here: 
* We have a legacy git repo that contains the source for several
different libraries. 
* We use CMake recursively to build all the libs from the top level.
* Some libs depend on other libs in the repo.
* I am trying to build the recipe "libc4statsclient", which is just
one of the libs in the repo.
* The header file shown in the error is part of another library and
recipe.


ERROR: Task (/home/rhowell/corex-develop/yocto/sources/c4-distro/meta-c4/recipes-c4/libc4statsdclient/libc4statsdclient_git.bb:do_install) failed with exit code '1'
Pseudo log:
Setup complete, sending SIGUSR1 to pid 3063620.
path mismatch [3 links]: ino 3804719 db '/home/rhowell/corex-develop/yocto/build.imx8mq-core/tmp/work/imx8mq_core-control4-linux/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/package/usr/src/debug/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp' req '/home/rhowell/corex-develop/yocto/build.imx8mq-core/tmp/work/imx8mq_core-control4-linux/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp'.

Thanks for your time and any suggestions.
Starting with the error message, it says that a path of:

WORKDIR/git/control4/c4shared/logger/logger.hpp

was accessed and it was found in the pseudo database as:

WORKDIR/package/usr/src/debug/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp

This doesn't seem so unusual to me since recipe source files would
often be hardlinked into package/usr/src/debug as part of the build,
however the ordering is backwards, the git/ should be created first,
then the WORKDIR/package one.

I was thinking this was really odd, then I realised you say this
aborted in do_install. WORKDIR/package is created by do_package, *not*
do_install which runs before do_package. This probably starts to hint
at what is going on.

Is this a directory where a previous build has run? If so, what changed
between the build runs?

My suspicion is that WORKDIR/package is being deleted outside of pseudo
and that is confusing things. The question is what/where it is being
deleted. Are you using rm_work?

The WORKDIR/temp/log.task_order file can be interesting to see which
tasks reran and in which order.

I appreciate this isn't an answer but it might give you an idea where
to look...

Cheers,

Richard


Question about psuedo abort errors

Rusty Howell
 

Hello,

My company is using yocto.  When building our own recipes, I get pseudo abort errors rather often.  I've read the wiki page about them, but I'm not sure exactly what we are doing wrong that is making this happen.  We have many recipes for various libraries and applications.  The files listed in the abort error log are usually C++ header files.

A coworker has told me that setting PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src" in the local.conf will allow bitbake to ignore this error. But in the end, I would like to understand what exactly is the root cause, so that I can adjust our recipes to fix this.

Here is the pseudo.log from the most recent failure. I know a lot of proprietary context is missing for anyone in the OSS community to give super confident answers, but I appreciate any suggestions.

Some context here: 
* We have a legacy git repo that contains the source for several different libraries. 
* We use CMake recursively to build all the libs from the top level.
* Some libs depend on other libs in the repo.
* I am trying to build the recipe "libc4statsclient", which is just one of the libs in the repo.
* The header file shown in the error is part of another library and recipe.


ERROR: Task (/home/rhowell/corex-develop/yocto/sources/c4-distro/meta-c4/recipes-c4/libc4statsdclient/libc4statsdclient_git.bb:do_install) failed with exit code '1'
Pseudo log:
Setup complete, sending SIGUSR1 to pid 3063620.
path mismatch [3 links]: ino 3804719 db '/home/rhowell/corex-develop/yocto/build.imx8mq-core/tmp/work/imx8mq_core-control4-linux/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/package/usr/src/debug/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp' req '/home/rhowell/corex-develop/yocto/build.imx8mq-core/tmp/work/imx8mq_core-control4-linux/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp'.

Thanks for your time and any suggestions.
Rusty Howell


Re: Minutes: Yocto Project Weekly Triage Meeting 6/9/2022

Richard Purdie
 

On Thu, 2022-06-09 at 12:10 -0400, Sakib Sajal wrote:
Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage
Attendees: Richard, Steve Sakoman, Tim Orling, Pavel, Aryaman Gupta,
Stephen Jolley, Randy, Luca Ceresoli, Michael Opdenacker
ARs:
Richard:
    - Bug 9762: close with a sensible log message
Done.

Cheers,

Richard


Minutes: Yocto Project Weekly Triage Meeting 6/9/2022

sakib.sajal@...
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Richard, Steve Sakoman, Tim Orling, Pavel, Aryaman Gupta, Stephen Jolley, Randy, Luca Ceresoli, Michael Opdenacker

ARs:

Richard:

    - Bug 9762: close with a sensible log message

Notes:
N/A

Medium+ 4.1 Unassigned Enhancements/Bugs: 73 (Last week 74)

Medium+ 4.99 Unassigned Enhancements/Bugs: 45 (Last week 47)

AB Bugs: 47 (Last week 47)


Re: How to remove the python3 from Yocto SDK

Ross Burton
 

It would be fairly simple to make a ‘dummy’ python3 recipe, like there already is for perl, which you can explicitly add to the SDK to use the host python. This would break anything inside the SDK which is a Python module with a C extension, as those need to be build against the right python.

 

Ross

 

From: yocto@... <yocto@...> on behalf of Alexander Kanavin via lists.yoctoproject.org <alex.kanavin=gmail.com@...>
Date: Tuesday, 7 June 2022 at 14:56
To: Vinothkumar Eswaran <evinoth1206@...>
Cc: Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] How to remove the python3 from Yocto SDK

Python3 isn't directly pulled into the SDK, but is a runtime
dependency of other items, such as meson. You can check that by

$ bitbake core-image-minimal -g -c populate_sdk

and reading/grepping the .dot file for nativesdk-python3.

Meson in turn is pulled in by the sdk packagegroup:

$ grep nativesdk-meson task-depends.dot |grep packagegroup
"nativesdk-packagegroup-sdk-host.do_package_write_rpm" ->
"nativesdk-meson.do_packagedata"

I guess if you drop all python consumers from packagegroups, then
python won't get pulled in either, but that is swimming in uncharted
waters, and you'll need to ensure replacements from the host are
available.

Alex

On Tue, 7 Jun 2022 at 14:21, Vinothkumar Eswaran <evinoth1206@...> wrote:
>
> Hi Alex,
>
> yes the absolute path works. May I ask why python3 is part of the SDK and is it possible to remove it from the SDK ?
>
> regards,
>
> Vinothkumar
>
>
>
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


[meta-security][PATCH] apparmor: fix ownership issues

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-mac/AppArmor/apparmor_3.0.4.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-mac/AppArmor/apparmor_3.0.4.bb b/recipes-mac/AppArmor/apparmor_3.0.4.bb
index 046a3a0..896abfe 100644
--- a/recipes-mac/AppArmor/apparmor_3.0.4.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.4.bb
@@ -101,6 +101,8 @@ do_install () {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
oe_runmake -C ${B}/parser DESTDIR="${D}" install-systemd
fi
+ chown root:root -R ${D}/${sysconfdir}/apparmor.d
+ chown root:root -R ${D}/${datadir}/apparmor
}

#Building ptest on arm fails.
--
2.25.1


Re: Force binary package install

Richard Purdie
 

On Tue, 2022-06-07 at 18:17 -0700, Rudolf J Streif wrote:

On 6/7/22 4:36 PM, Chuck Wolber wrote:
 
 

 
 
 
 >> Is there an elegant way around it?
 >>
 >>
 >> Error:
 >>    Problem: conflicting requests
 >>     - nothing provides libdl.so.2 needed by
 >> xxx-single-group-0.1-r0.cortexa53_crypto
 >>     - nothing provides libdl.so.2(GLIBC_2.0) needed by
Could this be considered a bug in the package_rpm.bbclass? It seems
to me that if you skip files-rdeps,
we might not want to be adding anything into splitpreinst.
Otherwise it seems silly to tell insane.bbclass
to skip something that RPM is going to ding you on later anyway. Or
maybe I am confused...

In any case, I believe what you may be seeing can be viewed as an
RPM-ism, and not necessarily a
yocto-ism per se. So you might consider trying one of the following
to work around the problem:
It's Yocto that creates the spec file for rpm. Apparently, besides
relying on what is declared in RDEPENDS, it
 actually iterates over the files and appends the dependencies (and
their versions). It results in this:
Requires: libc.so.6
 Requires: libc.so.6()(64bit)
 Requires: libc.so.6(GLIBC_2.0)
 Requires: libc.so.6(GLIBC_2.1)
 Requires: libc.so.6(GLIBC_2.1.3)
 Requires: libc.so.6(GLIBC_2.17)(64bit)
 Requires: libc.so.6(GLIBC_2.2)
 Requires: libc.so.6(GLIBC_2.28)(64bit)
 Requires: libc.so.6(GLIBC_2.3)
 Requires: libc.so.6(GLIBC_2.3.4)
 Requires: libc.so.6(GLIBC_2.4)
 Requires: libc.so.6(GLIBC_2.7)
Removing anything but the first two lines would probably do the
trick. So if file-rdeps is declared in INSANE_SKIP
 it should simply only use the declared RDEPENDS and not analyze the
files.
 

If that works at runtime it makes me wonder if our glibc shouldn't be
providing some of those things? What does our glibc package say it is
providing? How does that compare to what objdump says?

Cheers,

Richard


Re: Force binary package install

Alexander Kanavin
 

I think what should help you is
EXCLUDE_FROM_SHLIBS = "1"
which disables poking into libraries to auto-generate those
dependencies that otherwise cause both qa and dnf errors.

Alex

On Wed, 8 Jun 2022 at 00:48, Rudolf J Streif <rudolf.streif@...> wrote:


On 6/7/22 3:12 PM, Alexander Kanavin wrote:

Can you drop insane_skip for a moment and show what errors then happen?


Yes, thank you.

ERROR: xxx-single-group-0.1-r0 do_package_qa: QA Issue: /opt/binstuf/linux-allwinneryocto-armle-opengles_2.0-obj/lib/libfbxsdk.so contained in package xxx-single-group requires libpthread.so.0(GLIBC_2.2), but no providers found in RDEPENDS:xxx-single-group? [file-rdeps]

There are many more of these errors.


Objdump on libfbxsdk.so:

Version References:
required from libgcc_s.so.1:
0x0b792650 0x00 12 GCC_3.0
required from libpthread.so.0:
0x0d696912 0x00 10 GLIBC_2.2
0x09691972 0x00 07 GLIBC_2.3.2
0x0d696911 0x00 05 GLIBC_2.1
0x0d696910 0x00 03 GLIBC_2.0
required from libc.so.6:
0x0d696912 0x00 11 GLIBC_2.2
0x0d696917 0x00 09 GLIBC_2.7
0x0d696911 0x00 08 GLIBC_2.1
0x0d696913 0x00 06 GLIBC_2.3
0x09691f73 0x00 04 GLIBC_2.1.3
0x0d696910 0x00 02 GLIBC_2.0

Objdump on libpthread.so.0:

Version definitions:
1 0x01 0x0e2f2c50 libpthread.so.0
2 0x00 0x06969197 GLIBC_2.17
3 0x00 0x06969198 GLIBC_2.18
GLIBC_2.17
4 0x00 0x06969188 GLIBC_2.28
GLIBC_2.18
5 0x00 0x069691b0 GLIBC_2.30
GLIBC_2.28
6 0x00 0x069691b1 GLIBC_2.31
GLIBC_2.30


The versions don't match hence dnf throws an error. I guess I can defer the error with INSANE_SKIP += "file-rdeps" but then it comes up again when installing.



Alex

On Tue 7. Jun 2022 at 22.57, Rudolf J Streif <rudolf.streif@...> wrote:


On 6/7/22 12:44 PM, Alexander Kanavin wrote:
Can you show the recipe that you wrote for the blob?
Not exactly as is because of customer names, but below is a sanitized
version:


SUMMARY = "Binary Stuff"

LICENSE = "CLOSED"

SRC_URI = "file://binary_installer.tgz \
"

do_install() {

install -d -m 0755 ${D}/opt/binstuff

tar cf - -C ${WORKDIR}/opt/binstuff . | tar xf - -C ${D}/binstuff

}

FILES:${PN} = "/opt/binstuff"


RDEPENDS:${PN} += "libsystemd libudev libgpiod wayland"
INSANE_SKIP:${PN} += "ldflags file-rdeps arch staticdev"

The recipe itself builds just fine and creates the RPM package. However,
the some of the binaries inside the package have been built against
shared libs of older versions. The libs are there of course but with the
wrong version. Adding file-rdeps to INSANE_SKIP addresses this at build
time. But when installing the package in the rootfs dnf does a
dependency check which then fails.

I don't know if there is an elegant way of overriding dnf to force
installation of the package.



Alex

On Tue, 7 Jun 2022 at 20:59, Rudolf J Streif <rudolf.streif@...> wrote:
I have been handed a binary package that I am integrating into a Yocto
build.

When dnf runs it complains about missing dependencies. These are
standard libraries of course but the culprit is the incompatible
version. The software runs fine when I install it on the target using
the script/tar installation it comes with. Needless to say that YP
packaging QA complains about this already when assembling the package.
However, there I can silence the complaints with INSANE_SKIP.

Unfortunately I have not found a method doing the same when the package
is installed by the image class.

Is there an elegant way around it?


Error:
Problem: conflicting requests
- nothing provides libdl.so.2 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libdl.so.2(GLIBC_2.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libdl.so.2(GLIBC_2.1) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libgcc_s.so.1 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libgcc_s.so.1(GCC_3.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libm.so.6 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libm.so.6(GLIBC_2.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libm.so.6(GLIBC_2.1) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.1) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.2) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.3.2) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides librt.so.1 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides librt.so.1(GLIBC_2.2) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
(try to add '--skip-broken' to skip uninstallable packages)


--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700



--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700
--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.17.rc2)

Teoh, Jay Shen
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.17.rc2. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. NUC 7
3. NUC 6
4. Edgerouter
5. Beaglebone

ETA for completion next Monday, June 13.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Wednesday, 8 June, 2022 12:58 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.1.17.rc2)


A build flagged for QA (yocto-3.1.17.rc2) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.17.rc2


Build hash information:

bitbake: 0784db7dd0fef6f0621ad8d74372f44e87fef950
meta-agl: 34309bc1e6b092e3af5c5d559ad17cee77e99eca
meta-arm: 5c09684863be8e803e3e987a5ce4940721c3f39a
meta-aws: de60da566a16b1af8d585ff7d4d48290169d8f46
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: affda10724e5e3c7948200e888a91ffdb5d32a11
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: deee226017877d51188e0a46f9e6b93c10ffbb34
meta-virtualization: f6b88c1d2f515ffac90457c0d649d6c805fff736
oecore: 4051d1a3aa5f70da96c381f9dea5f52cd9306939
poky: 1e298a42223dd2628288b372caf66c52506a8081



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...







[meta-security][PATCH] aide: fix typo

Yi Zhao
 

Fix typo:
RDPENDS_${PN} -> RDEPENDS:${PN}

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-ids/aide/aide_0.17.4.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-ids/aide/aide_0.17.4.bb b/recipes-ids/aide/aide_0.17.4.bb
index 6bc2bfe..ebd6ac3 100644
--- a/recipes-ids/aide/aide_0.17.4.bb
+++ b/recipes-ids/aide/aide_0.17.4.bb
@@ -38,4 +38,5 @@ FILES:${PN} += "${libdir}/${PN} ${sysconfdir}/aide.conf"
pkg_postinst_ontarget:${PN} () {
/usr/bin/aide -i
}
-RDPENDS_${PN} = "bison, libpcre"
+
+RDEPENDS:${PN} = "bison libpcre"
--
2.25.1


Re: Force binary package install

Rudolf J Streif
 


On 6/7/22 4:36 PM, Chuck Wolber wrote:

>> Is there an elegant way around it?
>>
>>
>> Error:
>>    Problem: conflicting requests
>>     - nothing provides libdl.so.2 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libdl.so.2(GLIBC_2.0) needed by

Could this be considered a bug in the package_rpm.bbclass? It seems to me that if you skip files-rdeps,
we might not want to be adding anything into splitpreinst. Otherwise it seems silly to tell insane.bbclass
to skip something that RPM is going to ding you on later anyway. Or maybe I am confused...

In any case, I believe what you may be seeing can be viewed as an RPM-ism, and not necessarily a
yocto-ism per se. So you might consider trying one of the following to work around the problem:

It's Yocto that creates the spec file for rpm. Apparently, besides relying on what is declared in RDEPENDS, it
actually iterates over the files and appends the dependencies (and their versions). It results in this:

Requires: libc.so.6
Requires: libc.so.6()(64bit)
Requires: libc.so.6(GLIBC_2.0)
Requires: libc.so.6(GLIBC_2.1)
Requires: libc.so.6(GLIBC_2.1.3)
Requires: libc.so.6(GLIBC_2.17)(64bit)
Requires: libc.so.6(GLIBC_2.2)
Requires: libc.so.6(GLIBC_2.28)(64bit)
Requires: libc.so.6(GLIBC_2.3)
Requires: libc.so.6(GLIBC_2.3.4)
Requires: libc.so.6(GLIBC_2.4)
Requires: libc.so.6(GLIBC_2.7)

Removing anything but the first two lines would probably do the trick. So if file-rdeps is declared in INSANE_SKIP
it should simply only use the declared RDEPENDS and not analyze the files.

Experiment with using a virtual provider. It may be possible to just map the dependency manually to
what is already there.

If you _know_ that your dependency is truly isolated to your recipe, you may be able to set RPROVIDES
values in your recipe so the resulting RPM thinks the dependencies are met internally.

Patch package_rpm.bbclass to add a guard variable around the setting of splitpreinst. Add that
guard variable to your recipe so it selectively turns off the pre-install checks for that particular package.
Or just check for files-rdeps in INSANE_SKIP and do the same thing...
Yeah well, that's not really a good solution unless it's upstreameable.

Stop fighting RPM and switch to a different package type like IPK.
That would probably only work if the dependency mechanism is different for IPK. I have not checked that.

..Ch:W..

--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire
-- 
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Re: Force binary package install

Chuck Wolber
 


>> Is there an elegant way around it?
>>
>>
>> Error:
>>    Problem: conflicting requests
>>     - nothing provides libdl.so.2 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libdl.so.2(GLIBC_2.0) needed by

Could this be considered a bug in the package_rpm.bbclass? It seems to me that if you skip files-rdeps,
we might not want to be adding anything into splitpreinst. Otherwise it seems silly to tell insane.bbclass
to skip something that RPM is going to ding you on later anyway. Or maybe I am confused...

In any case, I believe what you may be seeing can be viewed as an RPM-ism, and not necessarily a
yocto-ism per se. So you might consider trying one of the following to work around the problem:

Experiment with using a virtual provider. It may be possible to just map the dependency manually to
what is already there.

If you _know_ that your dependency is truly isolated to your recipe, you may be able to set RPROVIDES
values in your recipe so the resulting RPM thinks the dependencies are met internally.

Patch package_rpm.bbclass to add a guard variable around the setting of splitpreinst. Add that
guard variable to your recipe so it selectively turns off the pre-install checks for that particular package.
Or just check for files-rdeps in INSANE_SKIP and do the same thing...

Stop fighting RPM and switch to a different package type like IPK.

..Ch:W..

--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


Re: Force binary package install

Rudolf J Streif
 


On 6/7/22 3:12 PM, Alexander Kanavin wrote:
Can you drop insane_skip for a moment and show what errors then happen?


Yes, thank you.

ERROR: xxx-single-group-0.1-r0 do_package_qa: QA Issue: /opt/binstuf/linux-allwinneryocto-armle-opengles_2.0-obj/lib/libfbxsdk.so contained in package xxx-single-group requires libpthread.so.0(GLIBC_2.2), but no providers found in RDEPENDS:xxx-single-group? [file-rdeps]

There are many more of these errors.


Objdump on libfbxsdk.so:

Version References:
  required from libgcc_s.so.1:
    0x0b792650 0x00 12 GCC_3.0
  required from libpthread.so.0:
    0x0d696912 0x00 10 GLIBC_2.2
    0x09691972 0x00 07 GLIBC_2.3.2
    0x0d696911 0x00 05 GLIBC_2.1
    0x0d696910 0x00 03 GLIBC_2.0
  required from libc.so.6:
    0x0d696912 0x00 11 GLIBC_2.2
    0x0d696917 0x00 09 GLIBC_2.7
    0x0d696911 0x00 08 GLIBC_2.1
    0x0d696913 0x00 06 GLIBC_2.3
    0x09691f73 0x00 04 GLIBC_2.1.3
    0x0d696910 0x00 02 GLIBC_2.0

Objdump on libpthread.so.0:

Version definitions:
1 0x01 0x0e2f2c50 libpthread.so.0
2 0x00 0x06969197 GLIBC_2.17
3 0x00 0x06969198 GLIBC_2.18
        GLIBC_2.17
4 0x00 0x06969188 GLIBC_2.28
        GLIBC_2.18
5 0x00 0x069691b0 GLIBC_2.30
        GLIBC_2.28
6 0x00 0x069691b1 GLIBC_2.31
        GLIBC_2.30


The versions don't match hence dnf throws an error. I guess I can defer the error with INSANE_SKIP += "file-rdeps" but then it comes up again when installing.



Alex

On Tue 7. Jun 2022 at 22.57, Rudolf J Streif <rudolf.streif@...> wrote:

On 6/7/22 12:44 PM, Alexander Kanavin wrote:
> Can you show the recipe that you wrote for the blob?

Not exactly as is because of customer names, but below is a sanitized
version:


SUMMARY = "Binary Stuff"

LICENSE = "CLOSED"

SRC_URI = "file://binary_installer.tgz \
           "

do_install() {

     install -d -m 0755 ${D}/opt/binstuff

     tar cf - -C ${WORKDIR}/opt/binstuff . | tar xf - -C ${D}/binstuff

}

FILES:${PN} = "/opt/binstuff"


RDEPENDS:${PN} += "libsystemd libudev libgpiod wayland"
INSANE_SKIP:${PN} += "ldflags file-rdeps arch staticdev"

The recipe itself builds just fine and creates the RPM package. However,
the some of the binaries inside the package have been built against
shared libs of older versions. The libs are there of course but with the
wrong version. Adding file-rdeps to INSANE_SKIP addresses this at build
time. But when installing the package in the rootfs dnf does a
dependency check which then fails.

I don't know if there is an elegant way of overriding dnf to force
installation of the package.


>
> Alex
>
> On Tue, 7 Jun 2022 at 20:59, Rudolf J Streif <rudolf.streif@...> wrote:
>> I have been handed a binary package that I am integrating into a Yocto
>> build.
>>
>> When dnf runs it complains about missing dependencies. These are
>> standard libraries of course but the culprit is the incompatible
>> version. The software runs fine when I install it on the target using
>> the script/tar installation it comes with. Needless to say that YP
>> packaging QA complains about this already when assembling the package.
>> However, there I can silence the complaints with INSANE_SKIP.
>>
>> Unfortunately I have not found a method doing the same when the package
>> is installed by the image class.
>>
>> Is there an elegant way around it?
>>
>>
>> Error:
>>    Problem: conflicting requests
>>     - nothing provides libdl.so.2 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libdl.so.2(GLIBC_2.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libdl.so.2(GLIBC_2.1) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libgcc_s.so.1 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libgcc_s.so.1(GCC_3.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libm.so.6 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libm.so.6(GLIBC_2.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libm.so.6(GLIBC_2.1) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.1) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.2) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.3.2) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides librt.so.1 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides librt.so.1(GLIBC_2.2) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>> (try to add '--skip-broken' to skip uninstallable packages)
>>
>>
>> --
>> Rudolf J Streif
>> CEO/CTO ibeeto
>> +1.855.442.3386 x700
>>
>>
>>
>>
--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

-- 
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Re: Force binary package install

Alexander Kanavin
 

Can you drop insane_skip for a moment and show what errors then happen?

Alex

On Tue 7. Jun 2022 at 22.57, Rudolf J Streif <rudolf.streif@...> wrote:

On 6/7/22 12:44 PM, Alexander Kanavin wrote:
> Can you show the recipe that you wrote for the blob?

Not exactly as is because of customer names, but below is a sanitized
version:


SUMMARY = "Binary Stuff"

LICENSE = "CLOSED"

SRC_URI = "file://binary_installer.tgz \
           "

do_install() {

     install -d -m 0755 ${D}/opt/binstuff

     tar cf - -C ${WORKDIR}/opt/binstuff . | tar xf - -C ${D}/binstuff

}

FILES:${PN} = "/opt/binstuff"


RDEPENDS:${PN} += "libsystemd libudev libgpiod wayland"
INSANE_SKIP:${PN} += "ldflags file-rdeps arch staticdev"

The recipe itself builds just fine and creates the RPM package. However,
the some of the binaries inside the package have been built against
shared libs of older versions. The libs are there of course but with the
wrong version. Adding file-rdeps to INSANE_SKIP addresses this at build
time. But when installing the package in the rootfs dnf does a
dependency check which then fails.

I don't know if there is an elegant way of overriding dnf to force
installation of the package.


>
> Alex
>
> On Tue, 7 Jun 2022 at 20:59, Rudolf J Streif <rudolf.streif@...> wrote:
>> I have been handed a binary package that I am integrating into a Yocto
>> build.
>>
>> When dnf runs it complains about missing dependencies. These are
>> standard libraries of course but the culprit is the incompatible
>> version. The software runs fine when I install it on the target using
>> the script/tar installation it comes with. Needless to say that YP
>> packaging QA complains about this already when assembling the package.
>> However, there I can silence the complaints with INSANE_SKIP.
>>
>> Unfortunately I have not found a method doing the same when the package
>> is installed by the image class.
>>
>> Is there an elegant way around it?
>>
>>
>> Error:
>>    Problem: conflicting requests
>>     - nothing provides libdl.so.2 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libdl.so.2(GLIBC_2.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libdl.so.2(GLIBC_2.1) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libgcc_s.so.1 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libgcc_s.so.1(GCC_3.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libm.so.6 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libm.so.6(GLIBC_2.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libm.so.6(GLIBC_2.1) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.1) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.2) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.3.2) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides librt.so.1 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides librt.so.1(GLIBC_2.2) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>> (try to add '--skip-broken' to skip uninstallable packages)
>>
>>
>> --
>> Rudolf J Streif
>> CEO/CTO ibeeto
>> +1.855.442.3386 x700
>>
>>
>>
>>
--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Re: Force binary package install

Rudolf J Streif
 

On 6/7/22 12:44 PM, Alexander Kanavin wrote:
Can you show the recipe that you wrote for the blob?
Not exactly as is because of customer names, but below is a sanitized version:


SUMMARY = "Binary Stuff"

LICENSE = "CLOSED"

SRC_URI = "file://binary_installer.tgz \
          "

do_install() {

    install -d -m 0755 ${D}/opt/binstuff

    tar cf - -C ${WORKDIR}/opt/binstuff . | tar xf - -C ${D}/binstuff

}

FILES:${PN} = "/opt/binstuff"


RDEPENDS:${PN} += "libsystemd libudev libgpiod wayland"
INSANE_SKIP:${PN} += "ldflags file-rdeps arch staticdev"

The recipe itself builds just fine and creates the RPM package. However, the some of the binaries inside the package have been built against shared libs of older versions. The libs are there of course but with the wrong version. Adding file-rdeps to INSANE_SKIP addresses this at build time. But when installing the package in the rootfs dnf does a dependency check which then fails.

I don't know if there is an elegant way of overriding dnf to force installation of the package.



Alex

On Tue, 7 Jun 2022 at 20:59, Rudolf J Streif <rudolf.streif@...> wrote:
I have been handed a binary package that I am integrating into a Yocto
build.

When dnf runs it complains about missing dependencies. These are
standard libraries of course but the culprit is the incompatible
version. The software runs fine when I install it on the target using
the script/tar installation it comes with. Needless to say that YP
packaging QA complains about this already when assembling the package.
However, there I can silence the complaints with INSANE_SKIP.

Unfortunately I have not found a method doing the same when the package
is installed by the image class.

Is there an elegant way around it?


Error:
Problem: conflicting requests
- nothing provides libdl.so.2 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libdl.so.2(GLIBC_2.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libdl.so.2(GLIBC_2.1) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libgcc_s.so.1 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libgcc_s.so.1(GCC_3.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libm.so.6 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libm.so.6(GLIBC_2.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libm.so.6(GLIBC_2.1) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.1) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.2) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.3.2) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides librt.so.1 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides librt.so.1(GLIBC_2.2) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
(try to add '--skip-broken' to skip uninstallable packages)


--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

1401 - 1420 of 58669