Sysroot bug in bitbake or wrong configuration?

Sysroot bug in bitbake or wrong configuration?

[Svein Seldal]

I have the spu-image.bb recipe below, and running on Pyro, the recipe 
behaves differently if the recipe is run on a fresh system with no 
sstate elements, compared to a system that has a sstate cache present.

The failure is that the spu-image required the host tool "uuidgen", and 
thus has DEPENDS on "util-linux-native". When the -c cleanall spu-image 
is run prior to building spu-image, the recipe sysroot is properly 
initialized with util-linux-native and uuidgen is available in the task 
functions.

If -c clean is run prior to build, or simply by deleting tmp, the 
sysroot will not be properly initialized and uuidgen is not available 
and the recipe fails

Is this a bug in bitbake or am I missing something in my recipe?


Best regards,
Svein Seldal


# spu-image.bb
DESCRIPTION = "Upgrade Image"

LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"

DEPENDS = "util-linux-native"
INHIBIT_DEFAULT_DEPS = "1"

fakeroot do_spu_rootfs() {
	uuidgen
}
addtask do_spu_rootfs before do_build

fakeroot do_spu_image () {
	uuidgen
}
addtask do_spu_image after do_spu_rootfs before do_build

# It does not matter if these are noexec-ed or not
#do_fetch[noexec] = "1"
#do_unpack[noexec] = "1"
#do_patch[noexec] = "1"
#do_configure[noexec] = "1"
#do_compile[noexec] = "1"
#do_install[noexec] = "1"
#do_package[noexec] = "1"
#do_package_qa[noexec] = "1"
#do_packagedata[noexec] = "1"
#do_package_write_ipk[noexec] = "1"
#do_package_write_deb[noexec] = "1"
#do_package_write_rpm[noexec] = "1"


# 1) Running works fine
#   		bitbake -v spu-image |tee log1.txt
#   		cat log1.txt | grep -2 uuidgen
#
# 2) Cleaning
#   		bitbake -c clean spu-image
#
# 3) Rebuilding -- now fails
#   		bitbake -v spu-image |tee log2.txt
#   		cat log2.txt | grep -2 uuidgen
#
# 4) Sstate cleaning
#   		bitbake -c cleanall spu-image
#
# 5) Works again:
#   		bitbake -v spu-image |tee log3.txt
#   		cat log3.txt | grep -2 uuidgen

Re: Sysroot bug in bitbake or wrong configuration?

[Andre McCurdy]

On Tue, Sep 19, 2017 at 11:43 PM, Svein Seldal <sveinse@seldal.com> wrote:
>
> I have the spu-image.bb recipe below, and running on Pyro, the recipe
> behaves differently if the recipe is run on a fresh system with no sstate
> elements, compared to a system that has a sstate cache present.
>
> The failure is that the spu-image required the host tool "uuidgen", and thus
> has DEPENDS on "util-linux-native".

DEPENDS is basically a shorthand for saying that the
do_populate_sysroot task for the recipe(s) listed in DEPENDS should be
run before the do_configure task of the current recipe.

Since image recipes don't have a do_configure task (or at least, they
do their work in tasks such as do_rootfs which don't depend on
do_configure), using the DEPENDS shorthand for setting dependencies
for the do_configure task doesn't work.

If an image recipe's do_rootfs or do_image tasks have dependencies
then they need to be expressed using the "longhand" format, for
example:

  do_rootfs[depends] += "util-linux-native:do_populate_sysroot"

Unfortunately trying to use DEPENDS in an image recipe seems to be
quite a common mistake. Maybe we should try to make things a little
more user friendly by adding a sanity test to catch the problem? Or
perhaps do_rootfs should depend on a dummy do_configure task (and so
ensure that do_rootfs effectively sees dependencies expressed via
DEPENDS) ?

> When the -c cleanall spu-image is run
> prior to building spu-image, the recipe sysroot is properly initialized with
> util-linux-native and uuidgen is available in the task functions.
>
> If -c clean is run prior to build, or simply by deleting tmp, the sysroot
> will not be properly initialized and uuidgen is not available and the recipe
> fails
>
> Is this a bug in bitbake or am I missing something in my recipe?
>
> Best regards,
> Svein Seldal
>

Re: Sysroot bug in bitbake or wrong configuration?

[Svein Seldal]

Perfect, that worked.

On 21. sep. 2017 03:45, Andre McCurdy wrote:
 > Since image recipes don't have a do_configure task (or at least, they
 > do their work in tasks such as do_rootfs which don't depend on
 > do_configure), using the DEPENDS shorthand for setting dependencies
 > for the do_configure task doesn't work.

Technically, this isn't a Yocto image recipe per se, but a general 
recipe for processing some file which happens to have the name "image" 
in it. The naming was perhaps a little misleading.

Notice that this recipe does not disable the default tasks, so all of 
them run, including do_configure. What I learned after some 
experimentation is that DEPENDS seems to works fine if you place your 
custom tasks after the do_configure tasks:

     addtask do_spu_rootfs before do_build after do_compile

This construct seems to work even if you disable the confiugre task with 
do_configure[noexec]="1"

But agreed, this works because of the implicit dependency on 
do_populate_* by do_compile. Setting the dep explicitly with the 
"longhand" format is more robust.


Best regards,
Svein