allarch recipes leave behind pseudo directory even with rm_work It's not bug in rm_work.bbclass but PSEUDO_LOCALSTATEDIR points to wrong WORKDIR (sometimes), but when I tried to reproduce it I failed: bitbake.conf: PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/" allarch.bbclass: # Set these to a common set of values, we shouldn't be using them other that for WORKDIR directory # naming anyway d.setVar("TARGET_ARCH", "allarch") d.setVar("TARGET_OS", "linux") $ grep ^WORKDIR= packagegroup-core-ssh-dropbear.env WORKDIR="/OE/oe-core/tmp-eglibc/work/all-oe-linux/packagegroup-core-ssh-dropbear/1.0-r1" $ grep ^PSEUDO_LOCALSTATEDIR= packagegroup-core-ssh-dropbear.env PSEUDO_LOCALSTATEDIR="/OE/oe-core/tmp-eglibc/work/all-oe-linux/packagegroup-core-ssh-dropbear/1.0-r1/pseudo/" I was assuming that it happens only when setscene tasks are executed, but it doesn't look like it too: $ bitbake -c cleansstate packagegroup-core-ssh-dropbear $ rm -rf BUILD/work/*/packagegroup-core-ssh-dropbear $ bitbake -c build packagegroup-core-ssh-dropbear $ bitbake -c clean packagegroup-core-ssh-dropbear $ bitbake -c build packagegroup-core-ssh-dropbear $ ls tmp-eglibc/work/*/packagegroup-core-ssh-dropbear -d tmp-eglibc/work/all-oe-linux/packagegroup-core-ssh-dropbear And still when I build whole image, few pseudo directories are left in tmp-eglibc/work/all-oe-linux-gnueabi/<recipe>/pseudo and all other files of the same recipe are correctly in tmp-eglibc/work/all-oe-linux-gnueabi/<recipe>/pseudo Is anyone else seeing this?
Is there contents in those pseudo directories, when this issue occurs, if in which variation of TARGET_OS. Which Machine was this a build for?
Ok, this is getting interesting! I can reproduce this consistently now with a clean build. I am using oe-core not poky, and qemuarm to get the gnueabi set in the ABIEXTENSION. The all-oe-linux-gnueabi is showing up in more places than just the PSEUDO_LOCALSTATEDIR, it shows up in the PKGTRIPLETS which causes them to apear in the SHLIBDIRS and PKLGMLTRIPLETS, I think this is because of when these variables are finalized compared with when the recipe is read and allarch is inherited, since allarch is recipe specific. and these others are more global.
Just to clarify this bug, if you take oecore, or poky, and do "MACHINE=qemuarm bitbake update-rc.d" you will see two all* directories in workdir and the pseudo metadata ends up in the wrong place.
and the problem is from devshell.bbclass which is playing with the pseudo environment :/
from bitbake -e # $PSEUDO_LOCALSTATEDIR [2 operations] # set? conf/bitbake.conf:606 # "${WORKDIR}/pseudo/" # set __anon_27__media_build1_poky_meta_classes_devshell_bbclass:7 [__anon_27__media_build1_poky_meta_classes_devshell_bbclass] # "/media/build1/poky/build/tmp/work/all-poky-linux-gnueabi/update-rc.d/0.7-r5/pseudo/" # computed: # "/media/build1/poky/build/tmp/work/all-poky-linux-gnueabi/update-rc.d/0.7-r5/pseudo/" PSEUDO_LOCALSTATEDIR="/media/build1/poky/build/tmp/work/all-poky-linux-gnueabi/update-rc.d/0.7-r5/pseudo/"
Patch out for review fixing this.
Resolved in master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=5963d24ec5be437717c5ce6ecac291d2e3263a35