public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
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


             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