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

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

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

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

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

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.

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

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

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

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

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

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

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

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

Can you show the recipe that you wrote for the blob?

Alex

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