Fix Yocto BitBake PermissionError do_package EXTERNALSRC

The Yocto BitBake PermissionError in do_package with EXTERNALSRC symlinks happens because absolute symlinks from your CMake build point outside the package directory, tripping up oe.package.fixup_perms during os.lchown for root ownership on paths like /usr. You can fix it quickly by adding inherit relative_symlinks to your recipe—this converts those pesky absolute links to relative ones, letting packaging sail through without Pseudo choking. It’s a standard Yocto solution that keeps your source symlink setup intact.

Contents

• Understanding the Yocto BitBake PermissionError in do_package
• Root Cause: EXTERNALSRC Symlinks and oe.package.fixup_perms Failure
• Official Solution: Inherit relative_symlinks Class
• Step-by-Step Fix for Your CMake EXTERNALSRC Recipe
• Alternative Workarounds for BitBake Permission Denied Issues
• Best Practices for Yocto EXTERNALSRC and Symlink Handling
• Testing and Verification After Fixing PermissionError Yocto Builds
• Sources
• Conclusion

Understanding the Yocto BitBake PermissionError in do_package

Ever hit that frustrating wall where your Yocto build hums along through configure and compile, only to crash in do_package with a PermissionError: [Errno 1] Operation not permitted? You’re not alone—this crops up specifically with EXTERNALSRC recipes using symlinks to sources, like your CMake setup where the build folder links back to the root for that “infinite recursion” trick. The error pinpoints oe.package.fixup_perms failing on os.lchown(path, uid, gid) for root (0:0) perms on something innocuous like /usr in the package dir.

Your stack trace nails it: it’s trying to set mode 493 on /home/user/testBuild/build/.../tmp/work/.../appl/1.0/package/usr. Pseudo, Yocto’s fakeroot emulator, should handle ownership changes, but it balks here. Why? Your project structure—sources in applSourceDir, build in ${WORKDIR}/appl/${applPreset}, symlink looping back—works great for hashing and building since BitBake ignores symlinks outside ${S} during those tasks. But packaging scans ${D} deeply, and absolute symlinks escape the sandbox.

Picture this: CMake installs files with symlinks like /usr/bin/foo -> /absolute/path/to/sources/bar. When fixup_perms walks the tree, it hits paths Pseudo can’t touch outside the fake root. Result? Boom, permission denied. This isn’t a CMake bug or your do_install—it’s a classic clash between EXTERNALSRC flexibility and Yocto’s strict packaging.

Root Cause: EXTERNALSRC Symlinks and oe.package.fixup_perms Failure

Dig a bit deeper, and it’s all about how EXTERNALSRC plays with symlinks. By pointing ${S} to a symlink (${TOPDIR}/applSourceDir), you’re telling BitBake “build here, but sources live externally.” That’s fine for do_configure and do_compile—your overrides like cmake_do_configure and cmake_do_compile run smoothly inside ${B}. But do_install stages to ${D}, and do_package splits it into RPMs/debs with permission fixes.

The smoking gun is in the package class docs: fixup_perms uses os.lchown without following symlinks (l for logical), but Pseudo aborts on targets outside its control. Your CMake preset creates absolute symlinks during install, pointing to the symlinked sources. When packaging derefs them relative to ${D}/usr, paths resolve to host filesystem spots like /home/user/.../applSourceDir, which Pseudo can’t chown.

From community reports, this mirrors issues in this Stack Overflow thread—exact same error in do_package with EXTERNALSRC symlinks. Yocto’s EXTERNALSRC class warns about this: it skips symlink checks for fetches, but packaging doesn’t get the memo. Add your vardepsexclude and INSANE_SKIP, and it’s clear you’re fighting known quirks.

Short version? Symlinks escape ${D} boundaries. Pseudo says no. Crash.

Official Solution: Inherit relative_symlinks Class

Here’s the hero: Yocto provides the relative_symlinks class exactly for this. It recursively walks ${D}, finds absolute symlinks pointing outside the package tree, and rewrites them as relative paths. So /usr/bin/foo -> /sbin/bar becomes foo -> ../../sbin/bar. Packaging then stays self-contained—no more external path leaks.

Why does this fix BitBake permission denied in do_package? fixup_perms now only touches paths inside ${D}, where Pseudo rules supreme. No host filesystem meddling. It’s lightweight, runs post-install, and doesn’t touch your CMake logic or EXTERNALSRC.

Community threads like this Yocto list discussion confirm it resolves EXTERNALSRC symlink woes. Just one line in your recipe: inherit relative_symlinks. Boom—problem solved for most cases.

Step-by-Step Fix for Your CMake EXTERNALSRC Recipe

Ready to patch it? Grab your simplified recipe and tweak like this:

inherit cmake externalsrc relative_symlinks # <-- Add this!

applPreset ?= 'ARM-Yocto-release'
applFlavor ?= 'V3'

DEPENDS += "swupdate zlib"
EXTERNALSRC = "${TOPDIR}/applSourceDir"
EXTERNALSRC_BUILD = "${WORKDIR}/appl/${applPreset}"
vardepsexclude += "EXTERNALSRC EXTERNALSRC_BUILD"

FILES:${PN} += "usr"
INSANE_SKIP:${PN} += "already-stripped"

cmake_do_configure() {
 bbnote "Configuring preset ${applPreset} (${applFlavor})"
 cmake --preset ${applPreset} -DBUILD_FLAVOR=${applFlavor} -DUSE_ENV_CC=TRUE -B "${B}" ${S}
}

cmake_do_compile() {
 bbnote "Building ${applPreset} (${applFlavor})"
 cd ${S}
 cmake --build "${B}" --target clean || exit 1
 cmake --build "${B}" || exit 1
}

do_install() {
 cmake --install "${B}" --prefix "${D}" || exit 1
}

That’s it—no other changes. The class auto-fixes symlinks before packaging. Your do_install prefix to ${D} ensures installs land correctly, and relative_symlinks cleans up the rest.

If your CMakeLists.txt spits out more absolute links (check with find ${D} -type l -exec ls -l {} \;), this handles them all. Test on a clean slate: it should breeze through do_package.

Alternative Workarounds for BitBake Permission Denied Issues

Not sold on inheriting a class? You’ve got options, though they’re patchier.

1. Restructuring symlinks: Ditch the build-to-sources loop. Copy sources to ${WORKDIR}/sources sans symlink, set S = "${WORKDIR}/sources". Messy for large trees, kills your “SRC_URI-like” flow.

2. Global inherit: Add INHERIT += "relative_symlinks" to local.conf. Fixes site-wide but might over-process other recipes. Yocto mailing lists suggest cleaning dangling links too.

3. INSANE_SKIP expansion: Beef up INSANE_SKIP:${PN} += "perms symlink-issues". Skips checks but doesn’t fix underlying packaging—risky for deploys.

4. Custom do_package_prepend: Script symlink fixes manually:

do_package_prepend() {
find ${D} -type l -exec readlink {} \; | grep -v "^/" | xargs -r rm {}
# Then recreate relative
}

Brittle; prefer the class.

5. Switch to non-CMake: Use autotools or pure BitBake, but that’s a rewrite.

For similar PermissionError in fixup_perms, these work, but relative_symlinks wins for cleanliness.

Best Practices for Yocto EXTERNALSRC and Symlink Handling

EXTERNALSRC is powerful for in-tree dev, but tame it:

• Always pair with vardepsexclude += "EXTERNALSRC EXTERNALSRC_BUILD" to dodge stamp issues.
• Use ${B} explicitly for out-of-source builds—your CMake does this right.
• Audit symlinks post-install: bitbake -c devshell your-recipe; find ${D} -type l.
• For CMake, set -DCMAKE_INSTALL_PREFIX=${D} in presets, though your override handles it.
• Avoid host paths: CMake flags like -DCMAKE_SYSROOT=${STAGING_DIR_HOST} help.

Recent threads like this Reddit post echo it’s a persistent gotcha in Yocto 4.x+. Stick to relative_symlinks, and you’re golden.

And hey, if symlinks multiply (e.g., /usr deep), bump QA_SHRINKWRAP skips sparingly.

Testing and Verification After Fixing PermissionError Yocto Builds

Fixed? Prove it.

1. Clean: bitbake -c cleanall appl
2. Build: bitbake appl
3. Check logs: grep -i "permission\|chown\|symlink" tmp/work/.../appl/*/temp/log.do_package
4. Inspect package: find tmp/work/.../appl/*/packages-split/ -type l -ls—all relative?
5. Runtime test: Install image, verify binaries run sans broken links.

If it flakes, bitbake -v appl for verbose. Pseudo logs via bitbake -c cleansstate pseudo help debug.

Success means no more do_package crashes. Scale to your full Bedienteil recipes.

Sources

1. PermissionError during do_package with EXTERNALSRC symlink — Exact recipe match and error reproduction: https://stackoverflow.com/questions/79864313/permission-error-during-do-package-with-externalsrc-symlink-to-actual-sources
2. EXTERNALSRC Class — Official docs on EXTERNALSRC symlink handling limitations: https://docs.yoctoproject.org/ref-manual/classes.html#externalsrc-class
3. Package Class — Details on oe.package.fixup_perms and os.lchown failures: https://docs.yoctoproject.org/ref-manual/classes.html#package-class
4. relative_symlinks Class — Documentation for converting absolute symlinks in packaging: https://docs.yoctoproject.org/ref-manual/classes.html#relative-symlinks-class
5. Failing EXTERNALSRC and dangling symlinks — Community discussion on symlink cleanup in EXTERNALSRC: https://yocto.yoctoproject.narkive.com/OdjNDU5b/failing-externalsrc-and-dangling-symlinks
6. BitBake Error PermissionError errno 1 — Similar fixup_perms permission issues: https://stackoverflow.com/questions/61748678/bitbake-error-permissionerror-errno-1-operation-not-permitted-when-changin
7. Yocto Mailing List Thread — References relative_symlinks as standard fix: https://lists.yoctoproject.org/g/yocto/topic/106192359#msg63138
8. Embedded Linux Yocto Error Discussion — Recent confirmation of symlink packaging bugs: https://www.reddit.com/r/embedded/comments/1cx0csa/embedded_linux_ubuntu_2404_lts_with_yocto_error/

Conclusion

Wrapping up, the Yocto BitBake PermissionError do_package with EXTERNALSRC symlinks boils down to absolute paths evading Pseudo—nail it by inheriting relative_symlinks in your recipe for a clean, official win. Your CMake setup stays elegant, no major rewrites needed. Test thoroughly, and you’ll ship reliable packages. If quirks linger, Yocto’s docs and lists have your back—happy building!