**** BEGIN LOGGING AT Mon Nov 21 02:59:57 2022 Nov 22 11:24:08 hi there. during build of meta-riscv (https://github.com/riscv/meta-riscv) I faced an issue with gcc: https://pastebin.com/PzJWf3GT . All mentioed libs I have already install on my host: dnf install gmp-devel mpfr-devel libmpc-devel. What can be an issue? Nov 22 12:04:22 khem: meta-riscv ^^^ Nov 22 13:40:08 I recieved the following error when addded meta-virtualization layer - Layer 'virtualization-layer' depends on layer 'filesystems-layer', but this layer is not enabled in your configuration in meta-openembedded core meta-filesystems is present so all should be fine Nov 22 13:40:14 what can be wrong here? Nov 22 13:43:45 ok. i missed it in bblayers.conf Nov 22 16:58:10 rburton: what’s the context ? Nov 22 17:01:26 khem: "ok: hi there. during build of meta-riscv (https://github.com/riscv/meta-riscv) I faced an issue with gcc: https://pastebin.com/PzJWf3GT . All mentioed libs I have already install on my host: dnf install gmp-devel mpfr-devel libmpc-devel. What can be an issue" Nov 23 00:29:00 this might be a trivial thing, but I'm still learning a lot of the nuances in Yocto -- I'm looking to grab a patch and apply it. Specifically, this patch seems to be addressing the problem I'm experiencing: Nov 23 00:29:01 https://www.yoctoproject.org/pipermail/yocto/2018-July/041841.html Nov 23 00:29:31 where do I actually find the *.patch file that is referenced in this mail exchange Nov 23 00:41:51 psj: isn't the patch literally in that mail? Nov 23 00:42:55 or rather, one message up in the thread, since the one you posted is a reply to it, so the patch is a bit postprocessed by the mailer Nov 23 03:31:36 yeah the body of the patch is in that mail -- so it'd be good enough to literally copy the content and just paste into a local *.patch file? I'm used to grabbing patches from the likes of patchworks with mbox. Didn't know if there's an equivalent or something -- I'd just use wget to fetch the patch from the mbox url. Nov 23 07:49:02 good morning Nov 23 10:10:49 psj: we have a patchworks, but lore works better: https://lore.kernel.org/yocto/1531348961-38317-2-git-send-email-juro.bystricky@intel.com/ Nov 23 10:11:47 psj: https://patchwork.yoctoproject.org/project/yocto/list/ is the patchwork if you prefer that Nov 23 10:27:59 the old guy in me loves the 1990s simplicity of lore. No fancy front page, no graphics, basic font. It just does what it needs to do. Nov 23 17:58:06 rburton: what is the difference between patchworks vs lore in terms of why it works better? On the outset, looks like lore is nice and simple and its search bar works well. Nov 23 18:30:38 I have here a device based on thud and the internal flash is too small to fit everything I need. I'm thinking about something like either transparent compression for read/write (maybe btrfs or dm+ext4) or squashfs + maybe overlayfs if there needs to be some writing (not sure yet). Unfortunately, I can't find anything on this on the webs... Maybe somebody has any links/recommendations/thoughts on this issue?? Nov 23 19:54:30 psj: patchwork is old, lore is newer. lore has nicer tooling to fetch patches. Nov 23 20:20:50 cb5r: there was a presentation on overlayfs at OSS/ELCE in dublin, that comes to my mind Nov 23 21:03:10 LetoThe2nd: thanks! I'll check it out 👌 Nov 23 21:19:52 psj: yes, the patch is just text with some special formatting, you can grab it from the original mail where it was not yet mangled by reply quotes and such Nov 24 10:24:42 is there a good kernel development workflow? Nov 24 10:25:38 currently, I edit the files I want to edit, then run a command which creates a patch file and copies it into my kernel recipe's files/ folder, then I run `bitbake virtual/kernel -c deploy`, then generate a new system image with the new kernel Nov 24 10:27:32 there's some time in that process which is unavoidable, but it should be possible to avoid unpacking and patching a fresh kernel source, compiling the whole kernel from source, recompiling kernel modules, and generating an ipk Nov 24 10:30:50 heck, an option to start from do_compile (skipping re-unpacking and patching, and doing an incremental build) and setting the gzip compression to -3 instead of -9 for the package would go a long way Nov 24 14:07:05 it should be possible to build a .wic image for the qemux86-64 machine, use dd to flash that image on a USB stick, and boot that image on a real PC, shouldnt it? Nov 24 14:16:40 dv_: not sure if the qemu one works, the images from meta-intels generic machines should do the trick AFAIK Nov 24 14:18:49 ah good idea Nov 24 14:44:04 dv_: AGL has some tweaks to make the qemu images generate a bootable wic, to avoid doing an extra build. I’m travelling atm, so don’t have a pointer handy. dl9pf might be able to point you at it Nov 24 14:49:33 dv_: here is the config fragment we use on-top of plain qemux86-64 ... Nov 24 14:49:36 dv_: https://git.automotivelinux.org/AGL/meta-agl/tree/meta-agl-bsp/conf/include/agl_qemux86-64.inc Nov 24 14:59:06 cool, thx **** ENDING LOGGING AT Fri Nov 25 02:59:57 2022