From: "Christian Thießen" <christian.thiessen@airbus.com>
To: openembedded-core@lists.openembedded.org
Subject: license manifest files effectively disappear when do_rootfs is not rerun
Date: Mon, 24 Oct 2022 01:36:41 -0700 [thread overview]
Message-ID: <XYMQ.1666600601427167951.xBaF@lists.openembedded.org> (raw)
(Cross-post: I first posted to https://lists.yoctoproject.org/g/yocto/message/58392, then realized that according to the poky readme this list is more appropriate. Sorry, beginner's mistake)
Dear list,
when building an image with a Yocto setup based on kirkstone, it seems I've come across an interesting corner case: The image built successfully, the build/tmp/deploy/licenses/${IMAGE}-${MACHINE} symlink got updated as expected, but that new directory contained only image_license.manifest. license.manifest and package.manifest were missing.
I've discovered that these latter files are generated by the image's do_rootfs task (ROOTFS_POSTPROCESS_COMMAND:prepend = "write_package_manifest; license_create_manifest; " in poky/meta/classes/license_image.bbclass). This task apparently did not need to be rerun in that particular build.
This behavior is at least a bit surprising to the user; bitbake claims to have run everything that needed to be run, completes successfully and then some files are just not there. It might be what happened here https://lists.yoctoproject.org/g/yocto/message/49600 too. For me, it broke a CI build that ran due to an environment change that didn't affect the image and then failed to deploy the manifest files. I could run bitbake with -C rootfs as a workaround, but that causes a warning and the problem could probably better be fixed within the oe-core classes. I'm not sure how though: Could the manifest generation be moved to a different point in the build, e.g. where image_license.manifest is generated? Or should build/tmp/deploy/licenses/${IMAGE}-${MACHINE} become a directory containing symlinks to files, instead of a symlink to a new directory, so that things that don't need to be updated can be retained? Maybe you have a completely different idea? I'll leave that up for discussion.
Thank you,
Christian Thießen
next reply other threads:[~2022-10-24 8:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 8:36 Christian Thießen [this message]
2022-10-24 8:41 ` [OE-core] license manifest files effectively disappear when do_rootfs is not rerun Alexander Kanavin
2022-10-24 8:58 ` Christian Thießen
2022-10-24 9:40 ` [OE-core] " Alexander Kanavin
2022-10-24 11:05 ` Christian Thießen
2022-10-24 11:31 ` [OE-core] " Quentin Schulz
2022-10-25 8:31 ` Christian Thießen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=XYMQ.1666600601427167951.xBaF@lists.openembedded.org \
--to=christian.thiessen@airbus.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox