Re: [yocto] Force binary package install

[Rudolf J Streif]

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



OpenPGP_0x8D8CA82927339B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57329): https://lists.yoctoproject.org/g/yocto/message/57329
Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Force binary package install

[Richard Purdie]

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57327): https://lists.yoctoproject.org/g/yocto/message/57327
Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Force binary package install

[Rudolf J Streif]

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



OpenPGP_0x8D8CA82927339B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57326): https://lists.yoctoproject.org/g/yocto/message/57326
Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57306): https://lists.yoctoproject.org/g/yocto/message/57306
Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] 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  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  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  
>> > 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
>> >> - 

Re: [yocto] 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



OpenPGP_0x8D8CA82927339B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57302): https://lists.yoctoproject.org/g/yocto/message/57302
Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] 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*

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57301): https://lists.yoctoproject.org/g/yocto/message/57301
Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] 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 > 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
mailto:rudolf.str...@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
>> 

Re: [yocto] 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 
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 
> 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
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57299): https://lists.yoctoproject.org/g/yocto/message/57299
Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] 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  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



OpenPGP_0x8D8CA82927339B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57298): https://lists.yoctoproject.org/g/yocto/message/57298
Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Force binary package install

[Alexander Kanavin]

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

Alex

On Tue, 7 Jun 2022 at 20:59, Rudolf J 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
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57297): https://lists.yoctoproject.org/g/yocto/message/57297
Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-