* Force binary package install @ 2022-06-07 18:59 Rudolf J Streif 2022-06-07 19:44 ` [yocto] " Alexander Kanavin 0 siblings, 1 reply; 12+ messages in thread From: Rudolf J Streif @ 2022-06-07 18:59 UTC (permalink / raw) To: Yocto [-- Attachment #1.1.1: Type: text/plain, Size: 2273 bytes --] 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 [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 1717 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-07 18:59 Force binary package install Rudolf J Streif @ 2022-06-07 19:44 ` Alexander Kanavin 2022-06-07 19:57 ` Rudolf J Streif 0 siblings, 1 reply; 12+ messages in thread From: Alexander Kanavin @ 2022-06-07 19:44 UTC (permalink / raw) To: Rudolf J Streif; +Cc: Yocto Can you show the recipe that you wrote for the blob? Alex On Tue, 7 Jun 2022 at 20:59, Rudolf J Streif <rudolf.streif@ibeeto.com> 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 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#57296): https://lists.yoctoproject.org/g/yocto/message/57296 > Mute This Topic: https://lists.yoctoproject.org/mt/91607892/1686489 > Group Owner: yocto+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-07 19:44 ` [yocto] " Alexander Kanavin @ 2022-06-07 19:57 ` Rudolf J Streif 2022-06-07 22:12 ` Alexander Kanavin 0 siblings, 1 reply; 12+ messages in thread From: Rudolf J Streif @ 2022-06-07 19:57 UTC (permalink / raw) To: Alexander Kanavin; +Cc: Yocto [-- Attachment #1.1.1: Type: text/plain, Size: 4093 bytes --] 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@ibeeto.com> 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 >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#57296): https://lists.yoctoproject.org/g/yocto/message/57296 >> Mute This Topic: https://lists.yoctoproject.org/mt/91607892/1686489 >> Group Owner: yocto+owner@lists.yoctoproject.org >> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [alex.kanavin@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >> -- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700 [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 1717 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-07 19:57 ` Rudolf J Streif @ 2022-06-07 22:12 ` Alexander Kanavin 2022-06-07 22:48 ` Rudolf J Streif 0 siblings, 1 reply; 12+ messages in thread From: Alexander Kanavin @ 2022-06-07 22:12 UTC (permalink / raw) To: Rudolf J Streif; +Cc: Yocto [-- Attachment #1: Type: text/plain, Size: 4334 bytes --] 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@ibeeto.com> 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@ibeeto.com> > 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 > >> > >> > >> -=-=-=-=-=-=-=-=-=-=-=- > >> Links: You receive all messages sent to this group. > >> View/Reply Online (#57296): > https://lists.yoctoproject.org/g/yocto/message/57296 > >> Mute This Topic: https://lists.yoctoproject.org/mt/91607892/1686489 > >> Group Owner: yocto+owner@lists.yoctoproject.org > >> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [ > alex.kanavin@gmail.com] > >> -=-=-=-=-=-=-=-=-=-=-=- > >> > -- > Rudolf J Streif > CEO/CTO ibeeto > +1.855.442.3386 x700 > > [-- Attachment #2: Type: text/html, Size: 6111 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-07 22:12 ` Alexander Kanavin @ 2022-06-07 22:48 ` Rudolf J Streif 2022-06-07 23:36 ` Chuck Wolber 2022-06-08 9:59 ` Alexander Kanavin 0 siblings, 2 replies; 12+ messages in thread From: Rudolf J Streif @ 2022-06-07 22:48 UTC (permalink / raw) To: Alexander Kanavin; +Cc: Yocto [-- Attachment #1.1.1.1: Type: text/plain, Size: 6863 bytes --] 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@ibeeto.com > <mailto:rudolf.streif@ibeeto.com>> 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@ibeeto.com <mailto:rudolf.streif@ibeeto.com>> 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 > >> > >> > >> -=-=-=-=-=-=-=-=-=-=-=- > >> Links: You receive all messages sent to this group. > >> View/Reply Online (#57296): > https://lists.yoctoproject.org/g/yocto/message/57296 > <https://lists.yoctoproject.org/g/yocto/message/57296> > >> Mute This Topic: > https://lists.yoctoproject.org/mt/91607892/1686489 > <https://lists.yoctoproject.org/mt/91607892/1686489> > >> Group Owner: yocto+owner@lists.yoctoproject.org > <mailto:yocto%2Bowner@lists.yoctoproject.org> > >> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub > <https://lists.yoctoproject.org/g/yocto/unsub> > [alex.kanavin@gmail.com <mailto:alex.kanavin@gmail.com>] > >> -=-=-=-=-=-=-=-=-=-=-=- > >> > -- > Rudolf J Streif > CEO/CTO ibeeto > +1.855.442.3386 x700 > -- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700 [-- Attachment #1.1.1.2: Type: text/html, Size: 10913 bytes --] [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 1717 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-07 22:48 ` Rudolf J Streif @ 2022-06-07 23:36 ` Chuck Wolber 2022-06-08 1:17 ` Rudolf J Streif 2022-06-08 9:59 ` Alexander Kanavin 1 sibling, 1 reply; 12+ messages in thread From: Chuck Wolber @ 2022-06-07 23:36 UTC (permalink / raw) To: Rudolf J Streif; +Cc: Alexander Kanavin, Yocto [-- Attachment #1: Type: text/plain, Size: 1526 bytes --] > >> 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* [-- Attachment #2: Type: text/html, Size: 2566 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-07 23:36 ` Chuck Wolber @ 2022-06-08 1:17 ` Rudolf J Streif 2022-06-08 15:54 ` Richard Purdie 0 siblings, 1 reply; 12+ messages in thread From: Rudolf J Streif @ 2022-06-08 1:17 UTC (permalink / raw) To: Chuck Wolber; +Cc: Alexander Kanavin, Yocto [-- Attachment #1.1.1.1: Type: text/plain, Size: 2817 bytes --] 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 [-- Attachment #1.1.1.2: Type: text/html, Size: 5954 bytes --] [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 1717 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-08 1:17 ` Rudolf J Streif @ 2022-06-08 15:54 ` Richard Purdie 2022-06-13 20:08 ` Rudolf J Streif 0 siblings, 1 reply; 12+ messages in thread From: Richard Purdie @ 2022-06-08 15:54 UTC (permalink / raw) To: Rudolf J Streif, Chuck Wolber; +Cc: Alexander Kanavin, Yocto 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-08 15:54 ` Richard Purdie @ 2022-06-13 20:08 ` Rudolf J Streif 2022-06-13 21:32 ` Richard Purdie 0 siblings, 1 reply; 12+ messages in thread From: Rudolf J Streif @ 2022-06-13 20:08 UTC (permalink / raw) To: Richard Purdie, Chuck Wolber; +Cc: Alexander Kanavin, Yocto [-- Attachment #1.1.1.1: Type: text/plain, Size: 3988 bytes --] Thanks, Richard. I was sidetracked by other stuff, hence the delay. Please see below. On 6/8/22 8:54 AM, Richard Purdie wrote: > 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? That's the objdump on libc.so.6 on the target (aarch64, Honister): Version definitions: 1 0x01 0x0865f4e6 libc.so.6 2 0x00 0x06969197 GLIBC_2.17 3 0x00 0x06969198 GLIBC_2.18 GLIBC_2.17 4 0x00 0x06969182 GLIBC_2.22 GLIBC_2.18 5 0x00 0x06969183 GLIBC_2.23 GLIBC_2.22 6 0x00 0x06969184 GLIBC_2.24 GLIBC_2.23 7 0x00 0x06969185 GLIBC_2.25 GLIBC_2.24 8 0x00 0x06969186 GLIBC_2.26 GLIBC_2.25 9 0x00 0x06969187 GLIBC_2.27 GLIBC_2.26 10 0x00 0x06969188 GLIBC_2.28 GLIBC_2.27 11 0x00 0x06969189 GLIBC_2.29 GLIBC_2.28 12 0x00 0x069691b0 GLIBC_2.30 GLIBC_2.29 13 0x00 0x069691b1 GLIBC_2.31 GLIBC_2.30 14 0x00 0x069691b2 GLIBC_2.32 GLIBC_2.31 15 0x00 0x069691b3 GLIBC_2.33 GLIBC_2.32 16 0x00 0x069691b4 GLIBC_2.34 GLIBC_2.33 17 0x00 0x0963cf85 GLIBC_PRIVATE GLIBC_2.34 I don't exactly know how the glibc versioning works. I suppose the API versions are defined by the Version file of the various components. However, when I did more analysis on the libraries whose libc versions did not seem to be met, I found out that they were libraries for a different architecture (x86_64) which were not supposed to be included. Now I wonder if the check validates version compatibility only or also checks architecture compatibility. However, if the latter then the error message does not convey that. Thanks, Rudi > > Cheers, > > Richard -- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700 [-- Attachment #1.1.1.2: Type: text/html, Size: 5810 bytes --] [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 1717 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-13 20:08 ` Rudolf J Streif @ 2022-06-13 21:32 ` Richard Purdie 2022-06-14 0:09 ` Rudolf J Streif 0 siblings, 1 reply; 12+ messages in thread From: Richard Purdie @ 2022-06-13 21:32 UTC (permalink / raw) To: Rudolf J Streif, Chuck Wolber; +Cc: Alexander Kanavin, Yocto On Mon, 2022-06-13 at 13:08 -0700, Rudolf J Streif wrote: > I don't exactly know how the glibc versioning works. I suppose the > API versions are defined by the Version file of the various > components. > > However, when I did more analysis on the libraries whose libc > versions did not seem to be met, I found out that they were libraries > for a different architecture (x86_64) which were not supposed to be > included. Now I wonder if the check validates version compatibility > only or also checks architecture compatibility. However, if the > latter then the error message does not convey that. In glibc different architectures implemented different functionality at different times so the symbol versions don't match cross platform. I therefore wondering if it was an architecture mismatch or whether it was an older obsolete ABI we didn't show by default somehow. What puzzles me is that in theory you should have seen a different error about the architecture of the binaries not matching the target though? Cheers, Richard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-13 21:32 ` Richard Purdie @ 2022-06-14 0:09 ` Rudolf J Streif 0 siblings, 0 replies; 12+ messages in thread From: Rudolf J Streif @ 2022-06-14 0:09 UTC (permalink / raw) To: Richard Purdie, Chuck Wolber; +Cc: Alexander Kanavin, Yocto [-- Attachment #1.1.1: Type: text/plain, Size: 1575 bytes --] On 6/13/22 2:32 PM, Richard Purdie wrote: > On Mon, 2022-06-13 at 13:08 -0700, Rudolf J Streif wrote: >> I don't exactly know how the glibc versioning works. I suppose the >> API versions are defined by the Version file of the various >> components. >> >> However, when I did more analysis on the libraries whose libc >> versions did not seem to be met, I found out that they were libraries >> for a different architecture (x86_64) which were not supposed to be >> included. Now I wonder if the check validates version compatibility >> only or also checks architecture compatibility. However, if the >> latter then the error message does not convey that. > In glibc different architectures implemented different functionality at > different times so the symbol versions don't match cross platform. I > therefore wondering if it was an architecture mismatch or whether it > was an older obsolete ABI we didn't show by default somehow. It was definitely an architecture mismatch. I checked the architecture of the files with objdump. > > What puzzles me is that in theory you should have seen a different > error about the architecture of the binaries not matching the target > though? That is what threw me off in the first place. I simply checked the versions. They were off but I could not explain why. The architecture explains it as you say. When scrolling through the objdump output the architecture eventually caught my eye. Thanks, Rudi > > Cheers, > > Richard -- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700 [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 1717 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto] Force binary package install 2022-06-07 22:48 ` Rudolf J Streif 2022-06-07 23:36 ` Chuck Wolber @ 2022-06-08 9:59 ` Alexander Kanavin 1 sibling, 0 replies; 12+ messages in thread From: Alexander Kanavin @ 2022-06-08 9:59 UTC (permalink / raw) To: Rudolf J Streif; +Cc: Yocto 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@ibeeto.com> 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@ibeeto.com> 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@ibeeto.com> 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 >> >> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> >> Links: You receive all messages sent to this group. >> >> View/Reply Online (#57296): https://lists.yoctoproject.org/g/yocto/message/57296 >> >> Mute This Topic: https://lists.yoctoproject.org/mt/91607892/1686489 >> >> Group Owner: yocto+owner@lists.yoctoproject.org >> >> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [alex.kanavin@gmail.com] >> >> -=-=-=-=-=-=-=-=-=-=-=- >> >> >> -- >> Rudolf J Streif >> CEO/CTO ibeeto >> +1.855.442.3386 x700 >> > -- > Rudolf J Streif > CEO/CTO ibeeto > +1.855.442.3386 x700 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-06-14 0:09 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-06-07 18:59 Force binary package install Rudolf J Streif 2022-06-07 19:44 ` [yocto] " Alexander Kanavin 2022-06-07 19:57 ` Rudolf J Streif 2022-06-07 22:12 ` Alexander Kanavin 2022-06-07 22:48 ` Rudolf J Streif 2022-06-07 23:36 ` Chuck Wolber 2022-06-08 1:17 ` Rudolf J Streif 2022-06-08 15:54 ` Richard Purdie 2022-06-13 20:08 ` Rudolf J Streif 2022-06-13 21:32 ` Richard Purdie 2022-06-14 0:09 ` Rudolf J Streif 2022-06-08 9:59 ` Alexander Kanavin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.