Re: [yocto] Force binary package install
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] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Manipulating users/groups in helper class with fakeroot/pseudo
I wrote a class, call it MYCLASS, whose purpose is to migrate certain files
installed by standard recipes into a different directory and create symlinks to
those files.
The reason for this is to have a disk partition layout with a read-only,
replaceable rootfs partition and a persistent storage partition. The idea is to
move certain configuration files installed by a recipe into persistent storage
and replace the rootfs version with a symlink.
The user inherits this class in a .bbappend file in another layer and specifies
the list of files that should have this treatment inside a MYCLASS_CONFFILES
variable.
I implemented this logic in a Python function and added it as a task as
follows. I abstracted away some details and used "example.conf" as a hardcoded
example configuration file being moved to a partition mounted at "/persistent".
fakeroot python myclass_copy_and_symlink_conffiles() {
...
sysconfdir_absfile = os.path.join(d.getVar('D'), d.getVar('sysconfdir'),
'example.conf')
destdir_absfile = os.path.join(d.getVar('D', 'persistent/example.conf')
st = os.stat(sysconfdir_absfile)
shutil.copy(sysconfdir_absfile, destdir_absfile)
shutil.chown(destdir_absfile, user=st.st_uid, group=st.st_gid)
# omitted: replace original file with symlink to copied file
...
}
myclass_copy_and_symlink_conffiles[depends] +=
"virtual/fakeroot-native:do_populate_sysroot"
do_install[postfuncs] += "${MYCLASSINSTALLFUNCS}"
MYCLASSINSTALLFUNCS_class-target = "myclass_copy_and_symlink_conffiles"
MYCLASSINSTALLFUNCS = ""
The problem I'm having is that UID and GID don't seem to be available to the
shutil.chown function or they're not read correctly from the pseudo database
when os.stat is called. Using the function as shown above, MYCLASS doesn't
preserve the UID/GID of the original file (as known to fakeroot/pseudo) and
falls back to setting UID:GID=root:root on the copied file instead.
Any hints on how I can improve this approach? Is the problem that the system
calls made by shutil/os functions aren't handled by pseudo? Should I replace
this Python function with a shell function that can use fakeroot?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57328): https://lists.yoctoproject.org/g/yocto/message/57328
Mute This Topic: https://lists.yoctoproject.org/mt/91739241/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
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
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] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.17.rc2)
Hello Everyone, QA for yocto-3.1.17.rc2 is completed. This is the full report for this release: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults === Summary No high milestone defects. No new issue found. Thanks, Jay > -Original Message- > From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User > Sent: Wednesday, 8 June, 2022 12:58 AM > To: yocto@lists.yoctoproject.org > Cc: qa-build-notificat...@lists.yoctoproject.org > Subject: [qa-build-notification] QA notification for completed autobuilder > build (yocto-3.1.17.rc2) > > > A build flagged for QA (yocto-3.1.17.rc2) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.1.17.rc2 > > > Build hash information: > > bitbake: 0784db7dd0fef6f0621ad8d74372f44e87fef950 > meta-agl: 34309bc1e6b092e3af5c5d559ad17cee77e99eca > meta-arm: 5c09684863be8e803e3e987a5ce4940721c3f39a > meta-aws: de60da566a16b1af8d585ff7d4d48290169d8f46 > meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac > meta-intel: affda10724e5e3c7948200e888a91ffdb5d32a11 > meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 > meta-openembedded: deee226017877d51188e0a46f9e6b93c10ffbb34 > meta-virtualization: f6b88c1d2f515ffac90457c0d649d6c805fff736 > oecore: 4051d1a3aa5f70da96c381f9dea5f52cd9306939 > poky: 1e298a42223dd2628288b372caf66c52506a8081 > > > > This is an automated message from the Yocto Project Autobuilder > Git: git://git.yoctoproject.org/yocto-autobuilder2 > Email: richard.pur...@linuxfoundation.org > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57325): https://lists.yoctoproject.org/g/yocto/message/57325 Mute This Topic: https://lists.yoctoproject.org/mt/91723280/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
