**** BEGIN LOGGING AT Thu Apr 22 02:59:57 2021 Apr 22 03:00:15 can you set hostname_pn-base-files = "" from an image recipe, or is it from a (machine, distro, multiconfig) configuration file only? Apr 22 08:07:10 Hello guys Apr 22 08:07:51 How can I prevent the kernel-image-fitimage package being installed in the image rfs ? Apr 22 08:08:03 yo dudX Apr 22 08:08:08 I'm really struggling, I always end up with both Image and fitImage in /boot Apr 22 08:08:20 thekappe: 1) find out what pulls it in 2) change that :) Apr 22 08:08:21 but I need only one of the two Apr 22 08:08:44 LetoThe2nd, is there a way to do that ? Apr 22 08:09:04 sure, for example looking at the dependency graphs. Apr 22 08:09:17 bitbake -g your image, then go wild. Apr 22 08:10:02 as well as simply inspecting IMAGE_INSTALL of your image, and oe-pkgdata-util to find the very packages in question Apr 22 08:10:39 whoa Apr 22 08:10:54 going through it Apr 22 08:11:10 thanks for the hints dudY ! Apr 22 08:11:18 have fun Apr 22 08:11:23 I always do Apr 22 08:11:43 '=D Apr 22 08:37:25 vdl: configuration only. As for the root thing, there may be something else you can set, I'm not sure offhand, I only remember the debug-tweaks option. You could see how that is doing it behind the scenes though Apr 22 09:19:15 oe-pkgdata-util -p tmp/pkgdata/ list-pkg-files kernel-image-fitimage Apr 22 09:19:25 kernel-image-fitimage: Apr 22 09:19:41  /boot/fitImage Apr 22 09:19:42  /boot/fitImage-4.19.0-xilinx-v2019.1 Apr 22 09:19:56 Running: bitbake -e multiconfig:: | grep ^IMAGE_INSTALL Apr 22 09:20:17 doesn't show anything related to that package. maybe is it include in packagegroup-core-boot ? Apr 22 09:20:30 I need a way to don't have it installed Apr 22 09:22:47 it's a dynamic package defined here: https://github.com/Xilinx/poky/blob/master/meta/classes/kernel.bbclass Apr 22 09:26:40 thekappe: LetoThe2nd suggested to use bitbake -g, not bitbake -e ;) Apr 22 09:28:11 actually i suggested both :) Apr 22 09:29:46 i've gone trhoug -g Apr 22 09:30:14 but didn't find anything related to kernel-image-fitimage in recipe-depends.dot Apr 22 09:31:41 also, adding FILES_kernel-image-fitimage = "" Apr 22 09:31:41  in a .bbappend doesn't works Apr 22 09:31:59 thekappe: obviously? because kernel-image-fitimage is not a recipe but a package? Apr 22 09:32:42 or is the name of the file wrong? don't remember much Apr 22 09:32:45 thought that since it's FILES_ is set in the kernel recipe I would be able to override it Apr 22 09:32:57 I would look into task-depends.dot, in that case you would have the package name I guess Apr 22 09:33:33 thekappe: except that it is a dynamic package as you said, so your variable has no impact. Apr 22 09:33:42 cat task-depends.dot | grep kernel-image Apr 22 09:33:53 doesn't return anything Apr 22 09:34:06 thekappe: you did -g on what? Apr 22 09:34:25 on the kernel recipe Apr 22 09:34:43 try on the image recipe Apr 22 09:35:06 ok Apr 22 09:37:59 still no results Apr 22 09:38:08 cat task-depends.dot | grep kernel-image Apr 22 09:38:12 and also Apr 22 09:38:19 cat recipe-depends.dot | grep kernel-image Apr 22 09:54:53 Hi, I've got dunfell. Here, /tmp is a ramdisk but I can't see an entry in /etc/fstab for mounting /tmp. Do you know where /tmp is configured in the yocto framework? Apr 22 09:59:38 fbre: wild guess: its a systemd unit that does the magic Apr 22 10:01:03 thekappe: just remembered: RDEPENDS_${KERNEL_PACKAGE_NAME}-base = "" Apr 22 10:02:26 thekappe: https://docs.yoctoproject.org/kernel-dev/faq.html?highlight=rdepends_%20kernel_package_name%20base#how-do-i-install-not-install-the-kernel-image-on-the-rootfs Apr 22 10:02:35 LetoThe2nd: thanx! I'll have a look into this direction Apr 22 10:03:24  RDEPENDS_${KERNEL_PACKAGE_NAME}-base = "" Apr 22 10:04:13 won't install any image in KERNEL_IMAGEDEST Apr 22 10:05:09 in this case I'll have to add kernel-image-image to  IMAGE_INSTALL_APPEND ? Apr 22 10:09:37 got disconnected Apr 22 10:10:27 thekappe: bitbake -e and check what's the current content of RDEPENDS_${KERNEL_PACKAGE_NAME}-base (replace KERNEL_PACKAGE_NAME :)), I don't know what it's supposed to be Apr 22 10:10:38 maybe you have to set it to kernel-image-fitimage in your case? Apr 22 10:15:19 I think that it gets both image and fitimage since the installed images are Image and fitImage shipped by kernel-image-image and kernel-image-fitimage Apr 22 10:18:00 in my .conf I've set: Apr 22 10:18:01 KERNEL_IMAGETYPES = "fitImage" Apr 22 10:18:19 KERNEL_CLASSES = "mycustom-fitimage" Apr 22 10:18:53 so I expected only the fitImage file in /boot Apr 22 10:19:04 but also Image is in there Apr 22 10:25:38 BTW, adding RDEPENDS_${KERNEL_PACKAGE_NAME}-base= "kernel-image-fitimage" will add only the fit to the rootfs and I'm ok with it Apr 22 10:31:17 is it correct that if I build for qemuarm it doesn't make sense to add the rpi layer since it won't be used anyways right? Apr 22 10:40:25 since it won't build rpi right? Apr 22 10:44:11 right Apr 22 10:49:08 Hi all, Apr 22 10:49:08 i have built my own image but after booting its aking me password even i haven't set any password. How to remove it ? Apr 22 10:50:09 cool Apr 22 10:52:20 ya, i have not set any variable related to the password Apr 22 10:52:51 pankaj347: the YP default is root user with no password, but depends on your settings Apr 22 10:54:31 pankaj347: set the 'empty-root-password' (or debug-tweaks, which sets that and others) IMAGE_FEATURE and you have no password, just hit return. Apr 22 10:54:46 pankaj347: if you didn't do that, and didn't set the password, then the password is unset and you can't login Apr 22 10:55:55 ok..thanks Apr 22 10:59:06 rburton variable i need to set with 'empty-root-password' ? Apr 22 11:01:01 its an IMAGE_FEATURE Apr 22 11:09:15 ok Apr 22 12:34:03 https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/devicetree.bbclass - how do I append do_install here? in a bbclass . What calls this bbclass? I need to rename a couple of files. or do a rename after the fact? Apr 22 12:34:44 afaik there's no way to override a bbclass directly so Apr 22 12:35:57 poky/meta/classes/kernel.bbclass:inherit kernel-devicetree Apr 22 12:38:09 is it as easy as override with do_install_append() in kernel.bbappend and mv ${D}/boot/devicetree/a.dtb ${D}/boot/devicetree/b.dtb ? Apr 22 12:48:07 Ad0: yup Apr 22 13:16:18 I want to add e2fsprogs-mke2fs (provided by e2fsprogs) to a .bbappend ad DEPENDS += "e2fsprogs-mke2fs" because the program installed by the .bbappend requires mkfs.ext4 Apr 22 13:16:46 doing so, bitbake complains that Apr 22 13:16:47 Nothing PROVIDES 'e2fsprogs-mke2fs' Apr 22 13:17:03 .. Apr 22 13:17:04 .. Apr 22 13:17:04 .. Apr 22 13:17:06 Close matches: Apr 22 13:17:06   e2fsprogs Apr 22 13:17:07   e2fsprogs RPROVIDES e2fsprogs-mke2fs Apr 22 13:17:33 Hence I am a little unsure on how to proceed. Apr 22 13:18:16 adding DEPENDS += "e2fsprogs" will add all the packages shipped by e2fsprogs.bb ? How can I select just the one that I need Apr 22 13:19:38 DEPENDS is buildtime dep, RDEPENDS is runtime dep. so you probably want RDEPENDS_${PN} = "e2fsprogs-mke2fs" Apr 22 13:25:27 Currently the 5.4 kernel is built, what should I change in order to build the 5.10 release with dunfell? Apr 22 13:26:21 LetoThe2nd, thanks Apr 22 13:26:52 mister: find a BSP layer matching your needs that provides 5.10. or create one yourself. dunfell upstream is locked on 5.4 Apr 22 13:36:37 thekappe: DEPENDS has recipe name in it, RDEPENDS, package names. If your program builds fine but fails on the target, it's RDEPENDS you need Apr 22 13:39:34 qschulz, now it's definitely clear Apr 22 13:46:21 awesome irc channel, thanks! Apr 22 13:59:08 thanks qschulz Apr 22 14:00:03 I also see this IMAGE_INSTALL_append = " kernel-devicetree kernel-image-zimage" Apr 22 14:35:48 RP: thank you. allow-root-login was indeed the feature. Apr 22 15:27:14 to include the source to build inside the recipe, is it better to add an archive, or the source files directly? Apr 22 15:28:50 commiting a tarball seems convenient but not very git friendly (in terms of file tracking) Apr 22 15:31:43 vdl: best practise is to just not bundle those two things. ;-) Apr 22 15:32:54 vdl: create a git repo for those sources, or upload them to a webserver, or whatever is supported by SRC_URI fetchers Apr 22 15:33:40 why? because SW sources shouldn't be associated with a build system. What if you decide you want to use buildroot in a few years? or whatever buildsystem you can think of... Apr 22 15:46:52 I know guys... I need to package a sample app for which the build system doesn't have access to the private repo yet, all I have at the moment are the python files. Apr 22 15:48:31 so the quick and dirty path at the moment is to place the source of the sample app in the recipe, hence my question. Apr 22 15:48:55 RP: rburton seeing do_packagedata_setscene: No suitable staging package found with master in few packages on aarch64 host Apr 22 15:49:13 https://pipelines.actions.githubusercontent.com/T7bAoRSN7t6rVkO50kATTzQqoaxucNyLSAl42rdFMDAmENSaG8/_apis/pipelines/1/runs/286/signedlogcontent/3?urlExpires=2021-04-22T14%3A46%3A49.1056934Z&urlSigningMethod=HMACV1&urlSignature=UVGyTwBQ9qonSMjF36cpExGnOt4pRqj9GuTzvPbzNyw%3D Apr 22 15:49:19 any ideas ? Apr 22 15:49:39 vdl: solution is to take the git archive from downloads directory (DL_DIR) and install it on your server til you fix your private repo access Apr 22 15:49:52 (DL_DIR from your PC where you have access) Apr 22 15:53:10 qschulz: would bitbake skip the download if I put the source archive manually in DL_DIR? Apr 22 15:53:27 vdl: sources with the recipe are kind of a last resort. tar balls, no way IMHO. manual injection should work, yes. Apr 22 15:54:27 LetoThe2nd: so I can write my recipe as expected and manually put my archive in DL_DIR as a temporary workaround Apr 22 16:00:08 still unclear to me how "overlays" directory is created in yocto with uboot and raspberrypi and kernel Apr 22 16:00:27 vdl: i think it should be possible, yes. Apr 22 16:00:52 meta-raspberrypi/classes/sdcard_image-rpi.bbclass Apr 22 16:03:39 meta-raspberrypi/conf/machine/include/rpi-default-settings.inc:IMAGE_CLASSES += "sdcard_image-rpi" Apr 22 16:55:35 khem: i've seen that on x86 host and have no idea why Apr 22 17:08:49 LetoThe2nd: because of the .done stamp file, I don't think I can skip the download step that easily Apr 22 17:19:11 is there a mechanism which specifies which recipe or .bbappend under /recipes-kernel/linux is used for virtual/kernel? Apr 22 17:20:05 yates: PREFERRED_PROVIDER Apr 22 17:20:12 i.e., if i ran "bitbake virtual/kernel" Apr 22 17:20:23 JaMa: ok thanks. that's in the build/local.conf? Apr 22 17:20:54 yes if you want to change it locally, or MACHINE.conf sets that Apr 22 17:21:09 when BSP provides own kernel recipes Apr 22 17:23:14 thanks very much, JaMa Apr 22 18:03:26 Is there a way to use runqemu with a full disk instead of just rootfs? e.g. if I want to test multiple partitions/overlayfs etc? Apr 22 18:05:02 alex88: you can pass arguments to qemu if you want, I guess that's how you would be able to expose another filesystem to it? Apr 22 18:05:48 oh ok, maybe there's a way to create a full disk image instead of just the root ext4 file and use that as the disk, I'll look more into that Apr 22 18:23:15 alex88: You can generate a bootable .wic file Apr 22 18:25:50 JPEW, oh ok I can use wic, thank you! Apr 22 18:28:19 alex88: Ya, I think you need to add QB_DEFAULT_FSTYPE = "wic.qcow2"... I'm not _exactly_ sure how to specify the kernel, we are booting up u-boot as the BIOS and it loads the kernel Apr 22 18:30:08 ok and I need to make sure that the qcow2 image is generated, that should be easy (right now I only have wic.bmap which I use for the rpi4 but I wanted to test things with qemu to not having to deploy it continuously) Apr 22 18:30:24 isn't QB_DEFAULT_KERNEL to specify that? Apr 22 18:30:29 (the kernel) **** BEGIN LOGGING AT Thu Apr 22 18:39:32 2021 Apr 22 18:47:04 alex88: Ya. I'm not sure if qemu treats a disk image differently than a rootfs image Apr 22 19:10:38 RP: w.r.t. https://bugzilla.yoctoproject.org/show_bug.cgi?id=13980, did we ever simplify the email to a summary + link? Wondering if I should close it or not Apr 22 20:23:54 tgamblin: the emails still have charts in so I think we got this working again Apr 22 20:24:10 tgamblin: the performance workers don't change much so I guess once it was working... Apr 22 20:51:21 RP: more strangeness: https://autobuilder.yoctoproject.org/typhoon/#/builders/56 cenot8-ty-2 now works and centos8-ty-1 fails Apr 22 20:56:05 sgw1: very strange :( Apr 22 20:59:34 Yeah, I am going to try a full centos selftest on ty-2 again, I honestly am not sure what to do next to debug this with out a consistent reproducer Apr 22 21:08:42 sgw1: may be you need the latency of a running build on the machine too Apr 22 21:30:30 so I've tried to go with both qcow2 and vmdk images however qemu is stuck at boot with "Booting frorm hard disk...", is there any way to get more info on why is it failing? Trying to run the ext4 file works just fine Apr 22 21:48:21 alex88: Ya, so I think the reason for that _might_ be that qemu is looking for the kernel (or a bootloader) on the disk instead of using the one your provides Apr 22 21:50:57 JPEW, just saw that following https://wiki.yoctoproject.org/wiki/Virtualization_with_KVM ussing virt-manager at least shows some logs by selecting the direct kernel boot and selecting bzImage Apr 22 21:51:03 I get a kernel panic but at least something Apr 22 21:51:47 excuse my ignorance, but when you create a wic image and you flash the bmap to an sd, doesn't the disk contain the kernel/bootloader? but the vmdk doesn't? Apr 22 21:52:09 I think it depends on the machine Apr 22 21:52:45 Look for WKS_FILE_DEPENDS Apr 22 21:53:09 Sorry, IMAGE_BOOT_FILES Apr 22 21:53:24 thanks for the advice! I'll look for that Apr 22 21:54:17 I had to set that in my image otherwise it would've thrown an error, but it was probably better not to :) at least I know what to look at Apr 22 22:00:21 smurray: are the layers in meta-agl meant to pass yocto-check-layer? Apr 22 22:01:09 RP: I believe so, but I think only meta-agl-core is wired up in the autobuilder Apr 22 22:02:10 smurray: none of the layers are currently wired into the check-layer tests and if I try and add them I'm seeing some interesting failures :/ Apr 22 22:02:31 smurray: I'm not sure if this is the setup, the autobuilder, me missing something or something else :/ Apr 22 22:03:08 RP: I believe it's only meta-agl-core that should be getting tested, but that's more of a dl9pf question Apr 22 22:03:34 smurray: that is the one we're doing build testing on, not sure about YP compat status Apr 22 22:04:32 RP: AFAIK he was doing testing with yocto-check-layer, but I'm not sure the other layers in meta-agl are all 100% Apr 22 22:05:43 smurray: I'll experiment a bit more, thanks. I just wondered if you happened to know the status so I'd know if it was meant to work! :) Apr 22 22:08:05 RP: is it a requirement that every layer in that repo pass yocto-check-layer? We might need to rip some stuff out to make that workable Apr 22 22:09:09 RP: iirc, dl9pf will be back from vacation next week Apr 22 22:11:48 smurray: it isn't a requirement at the moment, I'm just acutely aware we need better testing as we don't even know the current state Apr 22 22:12:14 smurray: right, I'll try and ask him what the situation is next week. Meanwhile I think yocto-check-layer has issues too Apr 22 22:12:51 RP: I suspect meta-agl-core and meta-app-framework would pass, but not some of the other ones Apr 22 22:16:13 smurray: I think meta-agl-core fails atm as AGL_EXTRA_IMAGE_FSTYPES is unset causing str() + None to trigger an error Apr 22 22:16:36 smurray: but I also think yocto-check-layer is broken Apr 22 22:16:38 RP: right, that's a problem we need to fix Apr 22 22:17:33 * RP wonders if anyone here understand python argparser better than him Apr 22 22:17:33 RP: I thought dl9pf had told me it passed yocto-check-layer, but I know he sets that variable in the local.conf for the autobuilder Apr 22 22:18:29 I've been mulling over having each of my layers include a layer-specific selftest module/case that runs various sanity tests, starting with yocto-check-layer, then extracting the list of appended and added recipes to figure out what to build test and ptest. haven't tried it yet though.. Apr 22 22:21:01 adding WKS_FILE = "qemux86-directdisk.wks" that adds a bootloader row to the wic file it at least moves forward with https://gist.github.com/alex88/b08f70cedf2e8383e8cd2b230e8970cf but then blank screen :) little steps... Apr 22 22:26:15 well, there's no kernel output, but after a bit I get to the terminal! Apr 22 22:28:17 kergoth: there are lots of ways we could do this, too many choices in some ways! Apr 22 22:29:40 smurray: I'm pretty sure we'd need a default value for AGL_EXTRA_IMAGE_FSTYPES to make yocto-check-layer work. The layer doesn't parse as things stand Apr 22 22:30:43 RP: right. I'll work up a change to that logic, it's bit me using that layer outside of the AGL tree elsewhere Apr 22 22:30:59 RP: it's one of those "seemed like a good idea at the time" things Apr 22 22:32:12 smurray: I have worked out what I'm not doing correctly with the scripts too. Now I can try and make this all run on the autobuilder Apr 22 22:34:49 Good day! Apr 22 22:44:24 smurray: FWIW, adding AGL_EXTRA_IMAGE_FSTYPES ??= "" to agl-core's layer.conf makes that sublayer pass Apr 22 22:44:45 smurray: agl-core-test breaks with signature changes and a missing readme Apr 22 22:48:58 RP: okay Apr 22 22:53:17 RP: heh, I think he moved stuff to that test layer to make it easier to get core to pass Apr 22 22:53:28 RP: I've done a log of argparse Apr 22 22:53:54 RP: bunch of stuff in the test layers needs meta-oe, I think Apr 22 22:54:44 smurray: meta-oe isn't an issue here Apr 22 22:55:38 RP: okay. I think the plan was to avoid a lot of dependencies for core Apr 22 22:55:55 JPEW: I was trying to figure out if positional nargs='+' could work ok with flag nargs='+' options. I think the answer is yes, as long as you do the opposite ordering to the help text Apr 22 22:56:28 smurray: right, build testing is quite different from what I'm looking at here Apr 22 22:57:15 RP: gotcha Apr 22 22:57:22 smurray: I think we can make "yocto-check-layer ../meta-agl/meta-agl-core ../meta-agl/meta-agl-bsp ../meta-agl/meta-netboot ../meta-agl/meta-pipewire --dependency ../meta-openembedded/meta-oe ../meta-openembedded/meta-networking ../meta-openembedded/meta-python" work as the AGL layer compat testing Apr 22 22:57:32 Ya... I can't say I've done that before. I've always used `append` to allow the flag to be specified multiple times, e.g. --foo A --foo B --foo C Apr 22 22:57:49 -> [A, B, C] Apr 22 22:58:13 JPEW: yocto-check-layer does this, see the above command :) Apr 22 22:58:28 the help text confused me Apr 22 22:58:31 Ya Apr 22 23:01:00 RP: heh, that's definitely a question for Jan-Simon. It looks like he's done a lot of conditional includes in the bbappends that should allow that to work Apr 22 23:02:47 smurray: the above working assumes we have a weak default for the variable. I'm going to run with the above and talk to him next week Apr 22 23:03:21 the app framework needs meta-security which the autobuilder doesn't know about (yet?) Apr 22 23:04:19 RP: the app framework layer might be a low priority, the plan had been to move it out altogether but there wasn't time to do so before the last release Apr 22 23:05:03 smurray: https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/3 if you want to see this failing live :) Apr 22 23:05:22 smurray: I think making the above work is a good place to start Apr 22 23:06:09 RP: re the variable, I'd been thinking I'd just rework that anon pythin logic to check if the vars are set Apr 22 23:06:34 smurray: annoyingly its detecting meta-rcar-gen3-adas inside the meta-agl-bsp layer :/ Apr 22 23:06:43 smurray: that would fix it Apr 22 23:07:32 RP: I've had to test with a different distro config for a customer, so it's been on my todo list, I'll poke at it tomorrow Apr 22 23:07:36 Hi I have some recipes and I've added BBCLASSEXTEND += "native", but is a whole chain of libraries tthat end up in an application. So multiple recipes with this classextend. now the first library that depends on a root library, doesnt get the the header files in the recipe sysroot native, can someone point me out why that is? Apr 22 23:08:16 RP: you probably don't want to look super close at the meta-rcar-gen3-adas stuff ;) Apr 22 23:09:40 smurray: the errors from the script were enough to make me ignore it ;-) Apr 22 23:10:01 smurray: I think I'll have to drop the bsp layer though as the check layer script can't have one without the other :( Apr 22 23:11:46 RP: I'm a bit surprised it'd see that, there's some dynamic layer stuff in meta-agl-bsp that I'd have thought would make that not visible w/o rcar3 Apr 22 23:12:19 smurray: I mean that the script takes a path and pulls in any layer.conf files it finds there Apr 22 23:12:29 RP: ah Apr 22 23:12:30 smurray: so I can't exclude one without the other Apr 22 23:13:20 BBCLASSEXTEND += "native" doesnt include the header file in -native ? Apr 22 23:22:18 So far, meta-intel is the only one that has passed the tests :/ Apr 22 23:22:58 JaMa, khem: you'll be "pleased" meta-oe did break with the known licensing error from meta-multimedia Apr 22 23:53:15 Is there a way to have the disk come up at /dev/sda instead of /dev/vda in qemu? Apr 22 23:55:29 alex88: probably by not using virtio Apr 22 23:56:36 ok thanks RP Apr 23 00:25:16 ended up just customizing the wic file for qemu changing ondisfk from sda to vda and it worked Apr 23 01:49:38 I'm on dunfell and I need python3-protobuf 3.14. What do you guys suggest? Apr 23 01:56:58 move to something newer then dunfell... or port your own version of protobuf and any associated depednencies.. (starting with the existing version) Apr 23 02:13:01 fray: I backported the 3 necessary patches to bump protobuf to 3.14 but it's more complicated than that. Do you think it'll be safe to move to Gatesgarth or am I shooting myself in the foot? Apr 23 02:36:21 * paulg smells a PI trap Apr 23 02:39:19 I'm not using a Raspberry3.14 btw. **** ENDING LOGGING AT Fri Apr 23 02:59:56 2021