Built an SDK with opkg, installed and relocated it. When trying to use it to update a copy of rootfs at /tmp/sdk/rootfs (e.g. opkg -o /tmp/sdk/rootfs list), it silently fails. And strace shows that it tries to access following files/dirs: /tmp/sdk/rootfs///opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/etc/opkg /tmp/sdk/rootfs///opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/var/cache/opkg /tmp/sdk/rootfs////opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/var/lib/opkg/info /tmp/sdk/rootfs////opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/var/lib/opkg /tmp/sdk/rootfs////opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/var/lib/opkg/status When it works, it should be: /tmp/sdk/rootfs/etc/opkg /tmp/sdk/rootfs/var/cache/opkg /tmp/sdk/rootfs/var/lib/opkg/info /tmp/sdk/rootfs/var/lib/opkg /tmp/sdk/rootfs/var/lib/opkg/status
Chen, are you able to reproduce this problem? Moved to M3 and note that the deadline/goal is before the end of February.
To make the SDK relocatable, the call that installs the SDK at /opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/ should use an offline root (-o /opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/) to have the opkg housekeeping files register files relative to /opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux.
(In reply to comment #2) > To make the SDK relocatable, the call that installs the SDK at > /opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/ should use an offline > root (-o /opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/) to have the > opkg housekeeping files register files relative to > /opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux. I don't want to install/relocate SDK to /opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/, but that path gets hardcoded to nativesdk-opkg binary.
My comment was meant to be a hint for Chen: to make the SDK relocatable, the code that creates the SDK should use an offline root.
Any updates?
Robert nor Qi are able to work on this now. :(
I've looked into this and it really looks like a hard limit on path length in the sqlite code. I guess we can do 2 things about this : - Setup an explicit error when this path length is used (saying we don't support this, sadly) - Trying to push an improvement to sqlite to remove this limitation
(In reply to comment #7) > I've looked into this and it really looks like a hard limit on path length > in the sqlite code. I guess we can do 2 things about this : > - Setup an explicit error when this path length is used (saying we don't > support this, sadly) > - Trying to push an improvement to sqlite to remove this limitation Oh I this comment did not end up in the good bug... Sorry, please ignore.
Bulk move of 64 bugs to 4.3 M3 after a quick review. If a bug is actually fixed, please add a commit link and resolve it. -- Randy for YP bug team.
Moved to M4.
Bulk move to 5.0 M1. -- Randy
Bulk move of 52 5.0-M1 bugs to M2.
Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3.
Bulk move of bugs from 5.0-M3 to 5.99. The bugs in this list are all unassigned and are ones that I consider to be nice to do some time but not essential track from milestone to milestone in 5.0 or 5.1. We agreed on this bug handling approach in the YP bug review on Feb 22, 2024. If you disagree, please move back to a 5.[012...]-M* milestone.
I'm not sure if this is still a problem but after 6.0 is in good shape, we should check.
With latest master this issue is currently not occurring.
Verification Steps: Test on current oe-core/master: Added the following to local.conf: TOOLCHAIN_TARGET_TASK:append = " opkg" TOOLCHAIN_HOST_TASK:append = " nativesdk-opkg" PACKAGE_CLASSES = "package_ipk" SDKIMAGE_FEATURES:append = " package-management" Built and installed the SDK, then relocated it. Copied the target sysroot to /tmp/sdk/rootfs and ran: opkg -o /tmp/sdk/rootfs list This completed successfully. Sample output: acl-dbg - 2.4.0-r0 acl-dev - 2.4.0-r0 acl-src - 2.4.0-r0 base-files - 3.0.14-r0 ... To confirm which paths opkg was accessing, I traced the command: strace -f -e trace=file -o /tmp/opkg_strace.log opkg -o /tmp/sdk/rootfs list The strace log showed it correctly accessing: /tmp/sdk/rootfs/etc/opkg /tmp/sdk/rootfs/etc/opkg/arch.conf /tmp/sdk/rootfs/etc/opkg/opkg.conf /tmp/sdk/rootfs/var/lib/opkg/info /tmp/sdk/rootfs/var/lib/opkg /tmp/sdk/rootfs/var/lib/opkg/status Test on Dunfell (same steps): Repeating the identical procedure on Dunfell, the command failed silently, no output and no error. Tracing this with strace showed opkg instead accessing paths under the hardcoded SDK build path, rather than the relocated rootfs I specified: /tmp/sdk1/rootfs/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/etc/opkg /tmp/sdk1/rootfs/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/var/cache/opkg /tmp/sdk1/rootfs/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/var/lib/opkg/info /tmp/sdk1/rootfs/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/var/lib/opkg /tmp/sdk1/rootfs/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/var/lib/opkg/status
Closing this issue as Resolved, Since this issue is not anymore occurring on oe-core/master.
Thank you for your due diligence.