02:16 <khem> halstead:thanks for reviving errors.yp.org

02:16 <khem> https://errors.yoctoproject.org/Errors/Build/205554/

02:17 <khem> my reports are working again

02:40 <halstead> Glad to hear it khem

08:27 <qschulz> tlwoerner: https://git.embedded.cherry.de/yocto-layers/meta-cherry-es.git/

08:28 <qschulz> khem: i cannot use systemd-repart, the USB stick needs to be ready and full size of the 16GB without running on the target nor on any Linux system (manufacturing floor are very often running Windows still...)

08:36 <mcfrisk> systemd-repart is handy when building generic images and then real target devices have different size mmc/sdcards. I've used repart from initrd (systemd based) to create a TPM backed encrypted rootfs (/usr read-only dmverity). trying to publish an example to meta-security/meta-tpm...

09:06 <berton> Hello! I sent this https://patchwork.yoctoproject.org/project/oe-core/patch/20250407160206.2449867-1-fbberton@gmail.com/ to the mailing list and have not gotten a response. It was in master-next a few weeks ago but has been removed and not merged. Does anyone know if it has not been accepted or what the status is?

09:18 <qschulz> tlwoerner: though this is a code dump repo and you only get stuff published once we merge stuff in our local git repos, so you don't see "development" in the open sadly

13:42 <vmeson> berton: I don't recall anyone objecting to the change but there are lots of patches. If you re-send the patch to get the ball rolling again I'll let you know on Monday after a patch review meeting.

13:55 <tlwoerner> berton: sorry for not getting back to you on that one, i think i said i would respond

13:57 <tlwoerner> berton: the question i had was: we already have half a dozen (a dozen?) variables throughout the code that influence the size of an image, do we really need yet another?

13:58 <tlwoerner> berton: i can't help wonder if maybe the variable you need already exists? or maybe one of the existing ones isn't working correctly?

13:59 <tlwoerner> berton: for example we already have IMAGE_ROOTFS_SIZE, your patch wants to add IMAGE_ROOTFS_EXACT_SIZE, that already seems confusing

14:00 <sunkist> Using `bitbake' to build some non-openembedded recipes has been eye-opening.

14:01 <sunkist> For instance, I see that bitabake provides fetching capability. But patching came from oe-core.

14:02 <sunkist> With oe-core, no `devtool' either!

14:03 <sunkist> This exercise has certainly boosted my understanding of the yocto architecture

15:03 <jmd> When I try to set BB_NO_NETWORK I get an error: "bb.parse.ParseError: ParseError at /work/build/conf/local.conf:35: unparsed line: 'BB_NO_NETWORK'" is BB_NO_NETWORK no longer supported?

15:04 <jmd> Oh it needs ""

15:22 <berton> @tlwoerner The existing variables do not work, because the problem occurs when creating a small filesystem, say 20MB, with 1KB block size, and the content in the rootfs is 16MB. The way Yocto creates the image using the du command, the final rootfs will always be larger than 20MB. Maybe IMAGE_ROOTFS_EXACT_SIZE is not a good name, but setting IMAGE_ROOTFS_SIZE to 20MB and the final image being 24MB is also confusing and not obvious. We

15:22 <berton> can add IMAGE_ROOTFS_MAXSIZE, but in the case I described, the rootfs will always be larger than 20MB.

15:22 <berton> I could not find a way to solve this problem, and the solutions suggested above do not fit my case. I remember that it was proposed to use genimage, but I only need an ext4 file and I need to migrate all projects to use genimage.

15:40 <tlwoerner> berton: does this have any relevance: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8430 ?

15:40 <tlwoerner> berton: it *feels* to me like there's a bug that needs fixing, rather than adding a new variable (which i'm willing to take on)

15:41 <tlwoerner> this seems relevant too: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11279 (but more generic)

15:43 <tlwoerner> qschulz: thanks for the layer! i'm always interested in gathering the layers people are using

15:43 <tlwoerner> qschulz: i finally have my rockchip things building again (they were broken because of the gcs thing) so *now* i can take a look at your latest patches :-)

15:53 <qschulz> tlwoerner: yay!

15:54 <qschulz> tlwoerner: meta-cherry-es/meta-bsp should not have anything weird or odd or breaking other boards/layers in it

15:57 <qschulz> meta-extended, I'm more relaxed about it, it's essentially just to build some demo image tailored to our products, no one sane would use that as a base for their products (i hope!)

16:01 <berton> @tlwoerner Yes, it seems related. The problem is that it depends on the ext4 options enabled. Some options like block size can be changed based on the size of the rootfs and can also be modified using EXTRA_IMAGECMD. I don't know how to check all the options without creating the rootfs and using tools to check what options the .ext4 file is using. And there are other filesystems. I'll try to find another way to solve this issue.

16:05 <tlwoerner> berton: your patch clearly highlights a real problem with the code, i would like to take the time to try to fix this issue

16:05 <tlwoerner> berton: and it might be, at the end of the day, that your patch is the fix

16:06 <tlwoerner> berton: but i would like to come to that conclusion after looking at the code, rather than starting with adding a new variable :-)

16:10 <berton> @tlwoerner Ok, that makes sense. What I don't know is what corner cases should be addressed, whether it's just the block size or if there are other options that could impact the rootfs size calculation.

16:10 <tlwoerner> understood

16:10 <tlwoerner> thanks for raising the issue

16:11 <tlwoerner> and it *sounds* like the only real way to know is to first create it, then measure it

16:25 <tlwoerner> https://xkcd.com/927/

16:25 <tlwoerner> s/standards/image size variables/g