| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 00:06 | |
| *** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 00:07 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 00:07 | |
| *** vineela <vineela!vtummala@nat/intel/x-jmtszwzsppipches> has joined #yocto | 00:08 | |
| *** vineela <vineela!vtummala@nat/intel/x-jmtszwzsppipches> has quit IRC | 00:15 | |
| *** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 00:40 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 00:41 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 01:38 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 01:39 | |
| *** camus1 is now known as kaspter | 01:39 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:40 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 02:53 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:53 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:16 | |
| kiwi_29 | Hello..I wanted to add a single loadable kernel module as part of rootfs . After the kernel boots the idea was to insmod this module. Initially I used IMAGE_INSTALL += kernel-modules. This brought all the available kernel modules along with the one I wanted. This added about 700MB space. So I removed kernel-modules to reduce space. How can I now add only this one loadable kernel module so that I appears inside /lib/module | 03:52 |
|---|---|---|
| kiwi_29 | s/ directory in rootfs | 03:52 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 03:59 | |
| *** jrdn <jrdn!~jrdn@S010668ff7b6b7383.ok.shawcable.net> has joined #yocto | 04:04 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 04:08 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 04:10 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 04:24 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 04:24 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 04:30 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-124.hsi5.kabel-badenwuerttemberg.de> has joined #yocto | 04:31 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 04:35 | |
| RobertBerger | @kiwi_29: I assume it's an in-tree kernel module. Check which packages were created. There is the top level monster kernel-modules packages, which contains all the kernel modules. But each kernel module is within it's own package. So just include this one package. | 04:47 |
| *** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 04:49 | |
| kiwi_29 | RobertBerger thanks.. let me check and will be right back | 04:49 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 04:50 | |
| kiwi_29 | btw... I used. MACHINE_EXTRA_RDEPENDS += "kernel-module-<MODULENAME>" and this did nothelp | 04:50 |
| RobertBerger | @kiwi_29: yes this does not help. | 04:52 |
| kiwi_29 | but all the docs say that will work. Or do they say that MACHINE_EXTRA_RDEPENDS will work for out-of-tree kernel modules? | 04:53 |
| kiwi_29 | mine is in-tree kernel module | 04:53 |
| RobertBerger | You should find packages like those: ./multi_v7_ml/kernel-module-exynos-rng-5.4.47-custom-ml-virt_5.4.47-custom-ml-virt+git0+fd8cd8ac94-r0.1_multi_v7_ml.ipk | 04:54 |
| kiwi_29 | mine is deb..so let me check | 04:55 |
| RobertBerger | yep | 04:55 |
| RobertBerger | MACHINE_EXTRA_RDEPENDS does not care about in tree or out of tree | 04:57 |
| RobertBerger | people just like to install all of them | 04:57 |
| RobertBerger | Hmm thinking about it again you should have kernel-module-<MODULENAME> | 04:58 |
| RobertBerger | Isn't this how your kernel module package is called? | 04:58 |
| kiwi_29 | yes it is | 05:00 |
| RobertBerger | so you say when you do something like this it's in your rootfs with all the others: MACHINE_ESSENTIAL_EXTRA_RDEPENDS += " kernel-modules" | 05:01 |
| kiwi_29 | I m not adding kernel-module-<MODULENAME> in IMAGE_INSTALL += | 05:02 |
| RobertBerger | and when you use kernel-module-<MODULENAME> it's not | 05:02 |
| kiwi_29 | yes when I use MACHINE_EXTRA_RDEPENDS += it does not appera in my rootfs | 05:02 |
| kiwi_29 | I use MACHINE_EXTRA_RDEPENDS += because it is not necessary for boot time | 05:02 |
| RobertBerger | can you try MACHINE_ESSENTIAL_EXTRA_RDEPENDS | 05:02 |
| kiwi_29 | I m *NOW* adding kernel-module-<MODULENAME> in IMAGE_INSTALL += | 05:03 |
| kiwi_29 | compiling now | 05:03 |
| RobertBerger | and also if you use kernel-modules that it ends up together with all the others | 05:03 |
| RobertBerger | in the rootfs | 05:04 |
| RobertBerger | what image do you build? A small one? | 05:04 |
| kiwi_29 | usine IMAGE_INSTALL += kernel-modules. will add all the modules in rootfs | 05:05 |
| RobertBerger | I think I know your problem ;) | 05:05 |
| RobertBerger | If you build a small image like e.g. core-image-minimal it will not work with your variable | 05:05 |
| RobertBerger | https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-MACHINE_EXTRA_RDEPENDS | 05:06 |
| RobertBerger | This variable affects all images based on packagegroup-base, which does not include the core-image-minimal or core-image-full-cmdline images. | 05:06 |
| RobertBerger | Is this the case? | 05:06 |
| kiwi_29 | oh boy ... my image derives from core-image-minimal | 05:06 |
| RobertBerger | hehe got it | 05:06 |
| kiwi_29 | wow! | 05:06 |
| RobertBerger | use MACHINE_ESSENTIAL_EXTRA_RDEPENDS as I suggested | 05:06 |
| kiwi_29 | I would have spent whole night trying to debug | 05:07 |
| kiwi_29 | thanks..let me check the IMAGE_INSTALL += kernel-module-<MODULENAME> first | 05:07 |
| RobertBerger | Sure | 05:07 |
| kiwi_29 | and then will try the MACHINE_ESSENTIAL_EXTRA_RDEPENDS | 05:07 |
| kiwi_29 | but many thanks RobertBerger | 05:07 |
| RobertBerger | No prob it's a classic ;) | 05:07 |
| kiwi_29 | I read that whole paragraph ..but my brain just filtered it :D | 05:09 |
| RobertBerger | Hehe - been there seen that | 05:11 |
| kiwi_29 | compiled..and works ! ..thanks again RobertBerger | 05:16 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 05:16 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 05:22 | |
| RobertBerger | @kiwi_29: You did everything right except for the magic variable ;) | 05:28 |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 05:35 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:39 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 05:43 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 05:55 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 05:59 | |
| *** pbergin <pbergin!~pbergin@h-79-136-99-68.NA.cust.bahnhof.se> has quit IRC | 06:03 | |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has joined #yocto | 06:23 | |
| ilkappe | RobertBerger it seems that i found the busillis | 06:23 |
| simonpe^^ | 3rd day into trying to manipulate NXP BSP:s to incorporate my own kernel configuration into the build. I've copied their linux-imx_5.4.bb file ito my own file, install the defconfig into ${B}/defconfig but when the recipe runs `make olddefconfig` all my stuff is overwritten. I can't find any documentation how make olddefconfig is supposed to work either | 06:29 |
| simonpe^^ | all my stuff is overwritten = it completely ignores my defconfig | 06:30 |
| RobertBerger | @ilkappe ? | 06:31 |
| ilkappe | try using: KBUILD_DEFCONFIG variable | 06:31 |
| ilkappe | RobertBerger the missing driver issue | 06:31 |
| ilkappe | after two days I got a lead | 06:31 |
| RobertBerger | Yep and how you fixed it? | 06:31 |
| ilkappe | there was a Missing line in the Makefile of the driver | 06:32 |
| RobertBerger | hehe ;) | 06:32 |
| ilkappe | the <driver-y> := | 06:32 |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 06:32 | |
| ilkappe | so the .c were compiled but the driver was not created | 06:32 |
| simonpe^^ | ilkappe: I actually tried that | 06:32 |
| simonpe^^ | ilkappe: it doesn't help | 06:32 |
| RobertBerger | If I hack on the kernel I just use the SDK created by the YP and once I get it to work I integrate it to the YP. | 06:33 |
| simonpe^^ | ilkappe: when I look at the Makefile only `make defconfig` seems to use the KBUILD_DEFCONFIG var | 06:33 |
| RobertBerger | Like this you can find such issues much easier, since YP is out of the equation. | 06:33 |
| simonpe^^ | and it seems to be relative to the arch/$ARCH dir | 06:33 |
| RobertBerger | @simonpe: Do are you on meta-freescale or you use all the funny NXP stuff? | 06:34 |
| RobertBerger | Are you on | 06:34 |
| simonpe^^ | RobertBerger: Im all in on NXP funny stuff | 06:34 |
| simonpe^^ | which I regret | 06:34 |
| ilkappe | RobertBerger yep, thanks fot hte hint | 06:34 |
| RobertBerger | And you don't want to use meta- freescale in order to reduce your necessary drug consumption? | 06:35 |
| simonpe^^ | RobertBerger: Well, I do like drugs | 06:35 |
| RobertBerger | Hehe but for other reasons ;) | 06:35 |
| simonpe^^ | but seriously, I would love to throw the NXP stuff out | 06:36 |
| ilkappe | just put your config in arch/$ARCH dir | 06:36 |
| RobertBerger | And not only to decrease your blood pressure ;') | 06:36 |
| RobertBerger | Please throw it out ! | 06:36 |
| ilkappe | and set KBUILD_DEFCONFIG | 06:36 |
| simonpe^^ | ilkappe: that was the last thing I tried, to overwrite all the defconfigs in there | 06:36 |
| simonpe^^ | it doesn't help | 06:36 |
| ilkappe | change the name eg to my_defconfig | 06:36 |
| simonpe^^ | oh | 06:36 |
| simonpe^^ | I'll try that out | 06:36 |
| simonpe^^ | RobertBerger: how would one use the meta-freescale stuff vanilla mode? | 06:37 |
| RobertBerger | Wow funny NXP stuff and changes on top of it. That's brave. | 06:37 |
| ilkappe | add it eg to arch/arm64/configs/ | 06:37 |
| RobertBerger | Like I posted it here: http://yoctoproject.blogspot.com/2020/09/how-to-build-core-image-minimal-with.html | 06:37 |
| simonpe^^ | I just followed the PDF from NXP telling me what to do, but then I had to back off one year due to their latest release not realising that their hardware team changed PMIC on the board I have | 06:38 |
| ilkappe | and set KBUILD_DEFCONFIG=my_defconfig in the recipe | 06:38 |
| RobertBerger | that's only poky/meta-freescale/meta-openembedded | 06:38 |
| simonpe^^ | So I'm on a 2019 zeus release | 06:38 |
| *** jrdn <jrdn!~jrdn@S010668ff7b6b7383.ok.shawcable.net> has quit IRC | 06:38 | |
| RobertBerger | With the other you are on dunfell | 06:38 |
| RobertBerger | And you have community support | 06:38 |
| RobertBerger | With the NXP stuff you have nothing like that | 06:38 |
| simonpe^^ | RobertBerger: how much work you'd expect for me to move over to that? | 06:39 |
| RobertBerger | To move your stuff over to it? | 06:39 |
| RobertBerger | No idea, since I don't know your stuff. | 06:39 |
| simonpe^^ | I mean, I have patches on top of u-boot-imx for example, but its noting too crazy | 06:39 |
| RobertBerger | So I guess that should be very similar/the same, since meta-freescale is also used by the funny NXP stuff | 06:40 |
| RobertBerger | Do you have some FSL eval board? | 06:40 |
| simonpe^^ | I have the imx8mnevk board | 06:40 |
| simonpe^^ | would that work? | 06:41 |
| RobertBerger | I think it's supported: https://github.com/Freescale/meta-freescale/tree/master/conf/machine | 06:41 |
| simonpe^^ | yep | 06:41 |
| simonpe^^ | ok so I'll tell my project manager that this is important because we want community support | 06:42 |
| RobertBerger | My instructions are for the mm, so it's trivial to change that. | 06:42 |
| simonpe^^ | thanks a lot boys and/or girls | 06:42 |
| RobertBerger | I would invest half a day to build it and give it a try. | 06:42 |
| simonpe^^ | morning meeting and then I'll watch your talk :) | 06:42 |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto | 06:42 | |
| RobertBerger | Well ask your manager who will support you with the official NXP stuff. | 06:43 |
| RobertBerger | Of course you can always find people to support you if you pay - on both ;) | 06:43 |
| simonpe^^ | That's what I mean, currently I am pretending to stil evaluate this CPU so they provide support | 06:43 |
| simonpe^^ | after the evaluation period we're out of luck | 06:43 |
| RobertBerger | NXP ? | 06:43 |
| RobertBerger | So why you need to ask here then? | 06:43 |
| simonpe^^ | because their support sucks | 06:44 |
| RobertBerger | If they would provide support? | 06:44 |
| RobertBerger | Thank you! | 06:44 |
| simonpe^^ | haha | 06:44 |
| RobertBerger | You get the point | 06:44 |
| RobertBerger | And please beat them up ;) | 06:44 |
| simonpe^^ | I've been waiting 2 months for a reply and the agreement is that they reply within 24 hours | 06:44 |
| RobertBerger | The more are complaining the more likely they will change. | 06:44 |
| *** mckoan|away is now known as mckoan | 06:44 | |
| RobertBerger | BTW it's not only NXP ;) | 06:44 |
| simonpe^^ | according to the distributor anyway | 06:45 |
| RobertBerger | I mean there are worse than NXP. | 06:45 |
| simonpe^^ | meeting now, thanks a lot for the help | 06:45 |
| RobertBerger | The distros are even worse than chip manufacturers since they don't know at all ;) | 06:45 |
| RobertBerger | The chip mfg at least know, just support is limited to "golden" customers. | 06:46 |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:49 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 07:10 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 07:13 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 07:16 | |
| mcfrisk | sigh, dunfell bitbake hangs on parse errors.. maybe related to NXP BSP.. | 07:17 |
| RP | mcfrisk: There is a patch on the bitbake list related to that. Not sure its right though, I'm about to run more experiments | 07:17 |
| simonpe^^ | RobertBerger: We have a requirement to have secure boot (HAB) and a collegue of mine was worried that if we don't use the funny NXP stuff it won't be supported. Do you have any insight into this? | 07:19 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 07:21 | |
| mcfrisk | RP: thanks, will check | 07:27 |
| mcfrisk | do wayland and weston belong to BSP layers? I think they should work from poky but looks like lots of things tie them to BSP and graphics driver specific. bit annoying | 07:28 |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 07:29 | |
| gsalazar | Hi, does anyone have experience with meta-swupdate? I manage to integrated in my build but cannot seem to use it to generate encrypted images. I read the documentation but I don't seem to grasp what needs to be defined | 07:32 |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 07:34 | |
| qschulz | Yatekii: well, it's simple. Do you want all your builds to be stopped/not automated because it wants credentials to fetch stuff? | 07:35 |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 07:37 | |
| mckoan | gsalazar: we use it regularly | 07:39 |
| gsalazar | mckoan: I cannot seem to automate the generation of the encrypted image. If I encrypt it manually everything works fine but I cannot automate it | 07:42 |
| *** stkw0 <stkw0!~quassel@ns3046126.ip-91-121-8.eu> has quit IRC | 07:43 | |
| gsalazar | I mostly get that the ".enc" FSTYPE is not provided | 07:43 |
| gsalazar | when adding IMAGE_FSTYPES += ".enc" to the image recipe | 07:44 |
| *** stkw0 <stkw0!~quassel@ns3046126.ip-91-121-8.eu> has joined #yocto | 07:44 | |
| qschulz | CONVERSION_CMD seems to be the one handling this | 07:45 |
| qschulz | probably CONVERSIONTYPES = "enc" is what you need | 07:46 |
| gsalazar | qschulz: Thank you for the input, I will try it | 07:47 |
| qschulz | you need to inherit swupdate and swupdate-enc classes | 07:47 |
| qschulz | but that's from a VERY quick read into meta-swupdate classes | 07:48 |
| gsalazar | I will try that approach and then figure out if I could add it to the documentation of the meta-swupdate. If this is the correct approach | 07:51 |
| gsalazar | qschulz: where would one specify the CONVERSIONTYPES? | 07:53 |
| RobertBerger | @simonpe^^: My understanding is, that whatever imx8 you use you need some funny boot container. | 07:55 |
| RobertBerger | @simonpe: I would even go so far (without checking) that official NXP stuff uses what's in meta-freescale for it. | 07:56 |
| RobertBerger | @zandrey any word on that? | 07:56 |
| qschulz | gsalazar: machine, distro or image recipe I guess? | 07:57 |
| RobertBerger | @simonpe: I took some patched u-boot from a board vendor into my layer, where I also put some kind of upstream kernel together with meta-freescale. | 07:58 |
| * derRichard reads imx8 an giggles | 08:00 | |
| RobertBerger | @simonpe: Also I am not sure if you could avoid secure boot on the imx8. | 08:00 |
| RobertBerger | @derRichard: Guten Morgen! | 08:00 |
| derRichard | :D | 08:00 |
| * derRichard works currently with an imx8 | 08:00 | |
| RobertBerger | Who doesn't ;) | 08:00 |
| derRichard | ^^ | 08:01 |
| derRichard | maybe i should note that i'm not using the nxp bsp :D | 08:01 |
| zandrey | simonpe^^: imx8mn machine is in meta-freescale, and it is operable | 08:02 |
| zandrey | you can use the instructions from RobertBerger to build NXP-free BSP. :) just replace MACHINE to imx8mnevk in his steps | 08:02 |
| zandrey | mcfrisk, RP: what is the issue you guys seeing with NXP dunfell? | 08:03 |
| RobertBerger | @zandrey - the question is if we loose "secure boot" by moving from official NXP to meta-freescale | 08:03 |
| RobertBerger | I highly doubt we loose anything ;) | 08:04 |
| fbre | yes, I can confirm the RobertBerger instructions tutorial works well (y) | 08:04 |
| gsalazar | qschulz: thanks | 08:04 |
| RobertBerger | We might find a few extra bits and pieces ;_ | 08:04 |
| qschulz | RobertBerger: we don't have meta-freescale and we have secureboot on imx8mm | 08:04 |
| qschulz | nor meta-imx or whatever | 08:04 |
| zandrey | RobertBerger: this i haven't tried so far... HAB is a functionality i usually tend to stay away from. | 08:04 |
| RobertBerger | @qschulz public git repo? | 08:05 |
| zandrey | imx-boot is supported though | 08:05 |
| qschulz | RobertBerger: of course not :D | 08:05 |
| RobertBerger | @qschulz I thought so. | 08:05 |
| derRichard | HAB on the imx8 is more or less the same as on the imx6 | 08:05 |
| RobertBerger | So maybe we should define a bit what we mean by secure boot ;) | 08:05 |
| qschulz | RobertBerger: all I know is that you need to take CST from their website and create a recipe out of it. | 08:06 |
| qschulz | or someone is kind and port imx8xx to usb-armory open-source implementation of CST | 08:06 |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has quit IRC | 08:07 | |
| zandrey | qschulz: patches and PRs to meta-freescale are welcomed! ;) | 08:07 |
| RobertBerger | As far as I understand you need some CST (code signing tool) and sign u-boot and kernel with it. | 08:08 |
| RobertBerger | And I have no idea if/how/where this is integrated with Yocto | 08:09 |
| fbre | zandrey: Now I use your recommended meta-freescale git clone, and now the .bin file for the initramfs is also in the boot partition beside the normal Image. (y) | 08:09 |
| RobertBerger | @simonpe: So it boils down to figuring out what exactly "secure boot" you need. | 08:10 |
| zandrey | fbre: glad to her! this is what i actually recommended to do right from the beginning of our conversation | 08:10 |
| zandrey | turning away from NXP BSP makes setup more clear and you progress faster | 08:11 |
| fbre | zandrey: RobertBerger explained very well the backgrounds. So I had a chance to understand what it is all about | 08:11 |
| qschulz | RobertBerger: technically, it can't be intergated because CST needs an EULA signing when downloading the tarball.. | 08:11 |
| RobertBerger | Well also NXP firmware needs an EULA | 08:11 |
| qschulz | RobertBerger: some do. the ddr training in our case IIRC | 08:12 |
| qschulz | some are available in linux-firmware (they can appear later) | 08:12 |
| zandrey | just to note here for the community: dunfell branch of meta-freescale has all modifications of NXP release zeus-5.4.3-1.0.0 integrated | 08:12 |
| qschulz | not ddr obviously, not an nxp component :) | 08:12 |
| fbre | (y) | 08:12 |
| zandrey | this is mainly for those who already started with NXP's meta-imx, and know only their terminology | 08:13 |
| RobertBerger | !qschulz I am confused - are we talking about the ddr firmware binaries? | 08:13 |
| qschulz | and don't forget that in order to boot from NAND, you need to flash with imx-kobs | 08:13 |
| zandrey | then one can really decided if he was already using zeus-5.4.3-1.0.0 - why not switch to pure dunfell? | 08:13 |
| RobertBerger | ddr firware binaries are definitly there - otherwise it won't create the boot container and not boot | 08:14 |
| zandrey | master-next has a zeus-5.4.24-2.1.0 release in pipe | 08:14 |
| qschulz | RobertBerger: I mixed things up (been talking about ddr training for a few days now :/). We still have sdma firmware that needs an EULA, other are available through other means with nicer licenses/no EULA | 08:15 |
| RobertBerger | sdma firmware is also there | 08:15 |
| fbre | zandrey: (y) | 08:15 |
| RobertBerger | If you read my instructions the last step is to agree to the NXP EULA in local.conf ;) | 08:15 |
| qschulz | RobertBerger: we never use vendor's BSP, we just cherry-pick some recipes from them and integrate it in our own layers ("easier" than BBMASK) | 08:16 |
| RobertBerger | ACCEPT_FSL_EULA = "1" | 08:16 |
| qschulz | RobertBerger: indeed | 08:17 |
| RobertBerger | Same for imx6 | 08:17 |
| *** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto | 08:17 | |
| RobertBerger | And now to something completely different: I am searching for a benchmark which would show a difference when I change compiler tunes between armv7-hf and cortex-a9-hf on an imx6q | 08:18 |
| qschulz | RobertBerger: if I'm not mistaken (it's been a long time), you don't need anything EULA-requiring for imx6 anymore | 08:19 |
| qschulz | heck.. I would even say every upstream version of SW should work just fine | 08:19 |
| RobertBerger | well this depends ;) | 08:19 |
| RobertBerger | You can use etnaviv for graphics, but for video you might still need the binary blobs | 08:20 |
| RobertBerger | and sdma as well (but this might be without EULA) | 08:20 |
| RobertBerger | I use upstream on i.mx6, but no multimedia | 08:20 |
| qschulz | RobertBerger: video = VPU? | 08:22 |
| RobertBerger | yep | 08:22 |
| qschulz | RobertBerger: interesting :) thx for the info | 08:22 |
| RobertBerger | But there might be some underground projects like etnaviv for mutimedia as well ;) | 08:23 |
| derRichard | RobertBerger: stress-ng has a floating point test | 08:25 |
| RobertBerger | I tried various other test already with floating point, but no difference | 08:25 |
| derRichard | well, did the change from armv7-hf to cortex-a9-hf actually generate different code? | 08:26 |
| *** yacar_ <yacar_!~yacar_@91-168-169-253.subs.proxad.net> has joined #yocto | 08:26 | |
| RobertBerger | this is scibench: https://openbenchmarking.org/result/2009043-HU-2009045HU05 | 08:26 |
| zandrey | qschulz: use the 'use-mainline-bsp' in meta-freescale - and you're free from EULA | 08:27 |
| RobertBerger | Yes different code, but performance wise? | 08:27 |
| RobertBerger | I don't see it | 08:27 |
| zandrey | https://github.com/Freescale/meta-freescale/blob/master/conf/machine/include/imx-base.inc#L12 | 08:27 |
| RobertBerger | aircrack runs faster on armv7-hf ;) https://openbenchmarking.org/result/2009045-HU-2009042HU19 | 08:28 |
| RobertBerger | @zandrey - well but I don't think you will boot anymore ;) | 08:28 |
| zandrey | RobertBerger: those derivatives that do not require imx-boot would go just fine ;) | 08:30 |
| RobertBerger | @zandrey - if you comment out this line like here https://gitlab.com/meta-layers/meta-phyboard-polis-imx8mm-bsp/-/blob/v5.8.x-upstream/conf/machine/phyboard-polis-imx8mm.conf#L25 | 08:30 |
| RobertBerger | imx-boot does not build anymore | 08:30 |
| RobertBerger | Ah yes ;) | 08:30 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:30 | |
| zandrey | that is what i just wrote | 08:30 |
| RobertBerger | https://github.com/Freescale/meta-freescale/issues/476 | 08:31 |
| qschulz | why does IMAGE_BASENAME need to be exported in the image recipe? | 08:32 |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 08:41 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 08:42 | |
| RobertBerger | @qschulz: just guessing here, but I think the image name needs it: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-IMAGE_NAME | 08:53 |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 08:54 | |
| qschulz | RobertBerger: many variables depend on other. Yet, they don't need to be exported and I never encountered the need to export it so it's probably something very specific? | 08:54 |
| qschulz | why I am asking is that we moved 99% of an image recipe into an .inc and moved the export IMAGE_BASENAME to the final image recipe after requiring the .inc and one of the ROOTFS_POSTPROCESS_COMMAND using it differs now | 08:57 |
| RobertBerger | Well variables are local, unless they are defined in configs | 08:57 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:01 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 09:04 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.30> has quit IRC | 09:18 | |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has joined #yocto | 09:23 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-124.hsi5.kabel-badenwuerttemberg.de> has quit IRC | 09:24 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 09:26 | |
| ilkappe | Hello guys, there is a way to change the KERNEL_DEVICETREE= in my_machine.conf without changin it directly ? | 09:31 |
| Yatekii | qschulz: ofc i want it to halt the build and ask for credentials! :) If I don't want that for CI I have to configure it differently. Now it just doesn't build at all. which is way worse than just not building when no interaction is here | 09:31 |
| Yatekii | also I believe most if not all companies use private repos. so this is a VERY common usecase | 09:32 |
| Yatekii | so with out gitlab setup we simply cannot build yocto unless we manually configure some keystores etc. which is nice. not ... | 09:33 |
| simonpe^^ | I'm just hoping it will boot since the Zeus 5.4.24 release refused to boot due to some PMIC issue | 09:33 |
| qschulz | Yatekii: patches welcome :) | 09:33 |
| simonpe^^ | so I'm going from NXP 5.4.3-2.0.0 to meta-freescale | 09:34 |
| simonpe^^ | RobertBerger: what do you mean it boils down to figuring out which secure boot I need? | 09:35 |
| simonpe^^ | I mean, HAB is what is built into the hardware - isn't that what I have to use? | 09:35 |
| zandrey_ | simonpe^^: please do *not* use 5.4.3-2.0.0! this was not a release release that could be productively used. see details in https://github.com/Freescale/meta-freescale/pull/337 | 09:37 |
| simonpe^^ | zandrey_: its ok, I don't use gstreamer or weston - this system is headless. Anyway, I'm moving over to the vanilla dunfell meta-freescale layer now instead | 09:39 |
| simonpe^^ | I got ok from my project manager to spend 2 days on getting it up and running with our distro | 09:40 |
| zandrey_ | simonpe^^: (y) | 09:40 |
| simonpe^^ | another thing, what is the need for the poky repository? To me it seems like you've taken openembedded-core and bitbake, and copy pasted it into a new repository called poky together with an example distro. Is that the case? | 09:42 |
| simonpe^^ | I was thinking of removing it and explicitly pointing to the bitbake and openembedded-core repos but it seems meta-freescale-distro requires the conf/distro/poky.inc from meta-poky | 09:43 |
| zandrey_ | simonpe^^: if you want to stay with Poky distro and do note require graphics - you can skip the meta-freescale-distro adding | 09:48 |
| zandrey_ | just follow instructions from RobertBerger and you would get the image in no time | 09:48 |
| zandrey_ | your planned setup should work, i also tried it and it is OK | 09:49 |
| simonpe^^ | its already cooking ;) | 09:49 |
| simonpe^^ | I have my own build tools that I use based on the nix package manager | 09:49 |
| simonpe^^ | its amazing | 09:49 |
| zandrey_ | simonpe^^: which PMIC change you meant? ROMH to PCA migration? | 09:50 |
| simonpe^^ | zandrey_: give me a moment and I'll check the issue i have open with NXP | 09:50 |
| zandrey_ | go for it :) | 09:50 |
| simonpe^^ | they said that for version L5.4.24 names were changed i.MX 8MN LPDDR4 -> i.MX 8MN EVK -> i.MX 8MN DDR4 EVK | 09:54 |
| simonpe^^ | then they want me to flash another bootloader | 09:54 |
| simonpe^^ | called i.MX 8MN DDR4 uboot | 09:54 |
| simonpe^^ | the problem I had was that uboot complained that it couldn't find the PMIC | 09:55 |
| simonpe^^ | and they wanted me to change the dtb file to point to imx8mn-ddr4-evk.dtb | 09:56 |
| simonpe^^ | in uboot | 09:56 |
| simonpe^^ | "This because DDR4 version uses different PMIC than the LPDDR4 one. | 09:57 |
| RobertBerger | @simonpe: imx-boot or HAB? | 10:00 |
| RobertBerger | simonpe: I asked on the meta-freescale git repo about it: https://github.com/Freescale/meta-freescale/issues/476 | 10:02 |
| RobertBerger | let's see if they answer ;) | 10:03 |
| RobertBerger | @simonpe how do you use HAB now? is it integrated in the yocto build or some magic scripts you run outside of it (which is what I would expect) | 10:03 |
| simonpe^^ | RobertBerger: I don't, but it is a requirement | 10:05 |
| zandrey_ | RobertBerger: HAB and imx-boot are not linked together ;) | 10:05 |
| simonpe^^ | so I'm dreading the day I will have to start working on it :P | 10:05 |
| RobertBerger | Well I did not use HAB, but I think you need to download some magic tool from NXP and run it over the boot container and kernel. | 10:06 |
| RobertBerger | But since I didn't use it, I can not tell you for sure. | 10:06 |
| zandrey_ | simonpe^^: so actually it is not about PMIC you have on your EVK, it's about the DTB. i tested the imx8mn with meta-freescale and it was fully operable. | 10:07 |
| RobertBerger | If that's the case I can be used with meta-freescale as well and you can integrate in manually yourself in the yocto build (which you would need to do as well with golden NX I thnk) | 10:07 |
| JaMa | another spam seemingly from RP on openembedded-commits ML, halstead please disable this ML if it isn't going to work anymore https://lists.openembedded.org/g/openembedded-commits/message/186011 | 10:07 |
| simonpe^^ | RobertBerger: ah ok, so I could just post process the yocto build with this magic tool then theoretically | 10:08 |
| simonpe^^ | I assumed I had to build some HAB support into u-boot itself | 10:08 |
| qschulz | simonpe^^: you do need it too if you want full secure boot | 10:09 |
| RobertBerger | The question is how the process is. | 10:09 |
| simonpe^^ | yeeeeeiiii, it booted | 10:09 |
| simonpe^^ | :D | 10:09 |
| RobertBerger | hey! | 10:09 |
| qschulz | https://elinux.org/images/e/e0/Josserand-schulz-secure-boot.pdf https://www.youtube.com/watch?v=jtLQ8SzfrDU | 10:09 |
| simonpe^^ | sweet | 10:10 |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has quit IRC | 10:10 | |
| RobertBerger | But this is imx6 | 10:10 |
| simonpe^^ | i see, it's probably similar enough | 10:11 |
| RobertBerger | Well I am not sure | 10:11 |
| zandrey_ | simonpe^^, RobertBerger: regarding the state of imx-boot - it was discusssed here: [https://github.com/Freescale/meta-freescale/pull/460]. it would require a clean-up, since the implementation is not that obvious. but you have to keep in mind, that conceptually imx-boot only builds boot container which bootrom code can chew up and start from | 10:11 |
| zandrey_ | HAB is different kind of beast | 10:11 |
| RobertBerger | I mean it does not have this crazy boot container, which all the 64 bit arm seem to have in some way or the other. | 10:11 |
| simonpe^^ | I think we've signed NDA on some docs describing how it all works but I haven't seen those yet | 10:13 |
| RobertBerger | The question is das golden NXP stuff do anything more than that with respect to HAB? | 10:13 |
| RobertBerger | does golden NXP | 10:13 |
| RobertBerger | Well one thing are docs, the other the implementation ;) | 10:13 |
| RobertBerger | With the docs you could write it yourself - maybe you need to anyways ;) | 10:14 |
| simonpe^^ | "Hi customer! Sorry for the late reply! It is unfortunate but there is a hardware bug in the i.MX8 that makes HAB dysfunctional, we'll update it sometime in the next 3 years. Br, NXP Support' | 10:15 |
| RobertBerger | "Hi customer! It's a know bug which will not be fixed ;)" | 10:15 |
| zandrey_ | RobertBerger: afaik there is nothing in NXP BSP regarding HAB. it is NDA, they provide some White papers on how to use it, but when you get to use it - you need to sign NDA and get more info. | 10:16 |
| zandrey_ | this was my latest state of understanding | 10:16 |
| simonpe^^ | I think we did step one of that then | 10:17 |
| zandrey_ | mcfrisk: are you around? what do you see in bitbake hanging from NXP BSP? | 10:18 |
| RobertBerger | @zandrey_: I really try hard to find a reason not to use meta-freescale ;) | 10:18 |
| zandrey_ | RobertBerger: ;) | 10:18 |
| RobertBerger | and NXP golden instead | 10:19 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 10:20 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 10:27 | |
| simonpe^^ | it seems meta-freescale doesn't have u-boot-imx-fw-utils | 10:31 |
| fbre | Hmmm.... I wonder why there is UBOOT_DTB_NAME = "fsl-imx8mm-evk.dtb" in sources\meta-freescale\conf\machine\imx8mmevk.conf | 10:31 |
| fbre | Shouldn't it be without "fsl-"? | 10:32 |
| zandrey_ | fbre: this is the U-Boot DTB name, they do differ from Kernel | 10:32 |
| zandrey_ | 2019.04 u-boot from 1.0.0 NXP release still had old names, 2020.04 changed them | 10:33 |
| zandrey_ | https://github.com/Freescale/meta-freescale/commit/d2af8f6b39ece9d7283c50c0c21bcb282ed45635 | 10:33 |
| *** newb_dev <newb_dev!bb14930d@187.20.147.13> has quit IRC | 10:35 | |
| fbre | hehehe changed 11 hours ago. My git clone is slightly older | 10:37 |
| zandrey_ | fbre: :) please be careful - this is master-next! ;) | 10:39 |
| RobertBerger | @fbre welcome to the community bsp - pull it often, try it often, ship patches ;_ | 10:39 |
| zandrey_ | you can take it as well - it is an integration of zeus-5.4.24-2.1.0 release | 10:39 |
| zandrey_ | fbre: disclaimer: it is not completed, so all bugs to fix are on you! :D | 10:40 |
| fbre | I did: git clone --branch dunfell git://github.com/Freescale/meta-freescale.git | 10:40 |
| fbre | Should I just do this?: git pull | 10:40 |
| zandrey_ | fbre: nope, please don't. meta-freescale dunfell is aligned with master, which is aligned with upstream dunfell. it is stable at the moment, but has only zeus-5.4.2-1.0.0 NXP release integrated. | 10:42 |
| zandrey_ | if you switch branches - you have to switch OE-core to master, otherwise you would get an interesting mismatch. | 10:42 |
| zandrey_ | or simply try it - then i would know if master-next of meta-freescale builds fine on top of OE-Core dunfell. | 10:43 |
| zandrey_ | this would be beneficial to know whether next upgrade is not broken for dunfell :D | 10:43 |
| fbre | so just 'git pull'? | 10:44 |
| *** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC | 10:44 | |
| fbre | I've done 'git pull' without your ACK | 10:51 |
| zandrey_ | fbre: unless you switch the branch - you're on the safe side. ;) | 10:51 |
| fbre | To use the initramfs stuff, you know, I have to change the kernel default configuration and switch "File systems"-->"Overlay filesystem support" from "<M>" to "<*>" | 10:53 |
| zandrey_ | actually, if you're adventurous enough and followed instructions of RobertBerger - you can checkout master branch in poky repository and master-next in meta-freescale, then build the image - it should also be operable | 10:53 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 10:54 | |
| fbre | I used --branch dunfell for all 3 git clones at the moment | 10:54 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 10:54 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 10:58 | |
| zandrey_ | fbre: then you can switch poky and meta-openembedded to master, and meta-freescale to master-next ;) but again - please do not base your future development on this setup! this is if you want to have a sneak peak on things to come | 11:01 |
| fbre | zandrey_: And what are the branch names for future development? | 11:03 |
| fbre | I mean to base our future development | 11:03 |
| zandrey_ | fbre: in meta-freescale it is master, and master-next for CI verifications of PRs | 11:04 |
| zandrey_ | meta-freescale is aligned on upstream branching, so you can choose whether you stay with LTS (dunfell) or move on to the next release from OE, in this case a new branch would pop-up in all repositories, including meta-freescale one | 11:05 |
| fbre | ok. So I rather stick to dunfell at the moment. I need it for production code | 11:07 |
| zandrey_ | fbre: good call ;) | 11:07 |
| fbre | zandrey_: If it helps you, it still works after that 'git pull' :-) | 11:11 |
| fbre | I did: bitbake --read=../my-stuff.conf virtual/kernel -c cleansstate and bitbake --read=../my-stuff.conf core-image-minimal -c cleansstate and 'git pull' of meta-freescale and bitbake --read=../my-stuff.conf core-image-minimal | 11:14 |
| fbre | The imx8mmevk comes up with the bundled initramfs and boots properly. Yeah!!!!! | 11:15 |
| fbre | Party on! \O/ Thank you very much to all you guys here | 11:16 |
| fbre | It says "Welcome to NXP i.MX Release Distro 5.4-zeus (dunfell)!" | 11:17 |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 11:17 | |
| zandrey_ | fbre: glad you made it! :) this is the benefit of using a community BSP - you get the stuff running in no time. | 11:17 |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 11:18 | |
| simonpe^^ | so after I've moved from meta-imx to meta-freescale for the single reason that I wasn't able to provide my own kernel configuration fragment I still can't | 11:38 |
| simonpe^^ | now if I try to bbappend the linux-imx recipe, even an empty bbappend, bitbake doesn't find any files related to the build | 11:38 |
| simonpe^^ | stuff like defconfig, cfg/virtio.scc etc. | 11:39 |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 11:40 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 11:44 | |
| simonpe^^ | ERROR. input file "cfg/virtio.scc" does not exist | 11:45 |
| fbre | simonpe^^: Did you cleansstate and did you a new call of 'soure oe-init-build-env build'? | 11:47 |
| qschulz | simonpe^^: so, no bbappend, it builds. an empty (really empty) bbappend and it does not? | 11:47 |
| simonpe^^ | yes indeed | 11:47 |
| zandrey_ | simonpe^^: linux-imx is the *original* kernel from NXP. if you want - you can switch the PREFERRED_PROVIDER to linux-fslc-imx, which is linux-imx + stable tree updates | 11:47 |
| simonpe^^ | zandrey_: is that what you'd do? | 11:48 |
| zandrey_ | simonpe^^: this is what i try to maintain ;) | 11:48 |
| qschulz | simonpe^^: that does not seem possible to me :/ | 11:49 |
| qschulz | (the "empty bbappend => build error) | 11:49 |
| zandrey_ | simonpe^^: as for .scc - you would need to add those to SRC_URI and place them in the layer in recipe folder | 11:49 |
| zandrey_ | linux-imx and linux-fslc-imx are inherited from kernel-yocto class (so they can use .scc files), but they do not have kernel-cache | 11:50 |
| zandrey_ | one would have to maintain those files locally | 11:50 |
| simonpe^^ | so if I bbappend I need to copy the files into my own layer? | 11:51 |
| zandrey_ | s/kernel-cache/kernel-yocto-cache/g | 11:51 |
| zandrey_ | simonpe^^: correct | 11:51 |
| simonpe^^ | ah I see | 11:51 |
| qschulz | zandrey_: what? it breaks SRC_URI or what? | 11:51 |
| simonpe^^ | hmm cfg/virtio.scc comes from meta-virtualization | 11:52 |
| zandrey_ | simonpe^^: https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#kernel-dev-advanced details the yocto-kernel-cache usage. you would have to clone it instead and get your feature files from it | 11:55 |
| zandrey_ | qschulz: no, what i meant is - if kernel recipe does not do require linux-yocto.inc, then yocto-kernel-cache is not available for it. in this case recipe developer should extract those .scc of interest himself, place it next to kernel recipe and add them to SRC_URI | 11:57 |
| zandrey_ | then they would be picked up by kernel-yocto bbclass and processed accordingly | 11:57 |
| simonpe^^ | well, at least theres documentation now that I ditched meta-imx | 11:59 |
| qschulz | zandrey_: basically, the difference when linux-yocto is not included/required is that you need to handle scc files yourself but you still need in any case to have them in SRC_URI in some wqay right? | 12:00 |
| qschulz | zandrey_: I've some more reading to do then I guess (yocto-kernel-cache is something I've never heard before) | 12:02 |
| RobertBerger | @zandrey I thought that meta-freescale includes the yocto kernel tooling ;) | 12:06 |
| simonpe^^ | I wanted to add a few configuration fragments to the kernel, now this is a 3 day deep rabbit hole lol | 12:07 |
| RobertBerger | ... I use my own kernel recipe, since I don't trust those other funny things and also I would like them the way I made it, so I know more or less what's happening ;) | 12:08 |
| RobertBerger | Anyways you just want to add kernel fragments to some meta-freescale kernel recipe - let's see | 12:09 |
| zandrey_ | qschulz: correct. you need to provide those along with your kernel recipe of some sort. section 4.3 of Linux Kernel Development Manual details it pretty good | 12:10 |
| RobertBerger | the bad news are, that there is not a single .cfg file in the meta-freescale kernel stuff ;) | 12:12 |
| zandrey_ | simonpe^^: you can skip .scc files and add fragments to your SRC_URI directly. fetcher and tooling is smart enough to chew them up and apply. ;) and - you can generate fragments via [bitbake <kernel recipe> -c diffconfig] | 12:12 |
| simonpe^^ | zandrey_: that's exactly what I was doing | 12:12 |
| simonpe^^ | FILESEXTRAPATHS_prepend := "${THISDIR}:" and SRC_URI += "fragment.cfg" | 12:13 |
| simonpe^^ | then it started complaining about not finding cfg/virtio.scc | 12:13 |
| zandrey_ | RobertBerger: meta-freescale does provide a base kernel, whatever feature somebody wants/needs should be taken care of in that BSP layer, isn't it? | 12:13 |
| simonpe^^ | now I switched to the linux-fslc-imx to see if that'll work better | 12:14 |
| zandrey_ | simonpe^^: standby for an example please... | 12:14 |
| RobertBerger | no require recipes-kernel/linux/linux-yocto.inc | 12:14 |
| RobertBerger | so one more reason I have my own kernel recipe ;) | 12:14 |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 12:14 | |
| zandrey_ | FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" | 12:14 |
| zandrey_ | SRC_URI += "file://rndis.cfg" | 12:14 |
| RobertBerger | Yep something like that | 12:15 |
| zandrey_ | provided you enabled RNDIS in your config via menuconfig and saved that fragment with diffconfig | 12:15 |
| simonpe^^ | zandrey_: aye, it finds my files but it seems to not be able to resolve the virtio.scc file added by meta-virtualization kernel feature | 12:16 |
| zandrey_ | then place it under recipes-kernel/linux/linux-fslc-imx/mx8 | 12:16 |
| simonpe^^ | this worked before with the nxp provided kernel recipe for some reason | 12:17 |
| RobertBerger | For the eval board it builds linux-fslc-imx whatever that is ;) | 12:17 |
| zandrey_ | simonpe^^: this is new... :| i do not have meta-virtualization in my setup, so i cannot tell why it has been pulled in | 12:17 |
| simonpe^^ | zandrey_: I'll remove the virtualization stuff for now to see if I can get it to build at all | 12:18 |
| simonpe^^ | I rly don't want to maintain copies of files from other repos :/ | 12:18 |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 12:19 | |
| zandrey_ | simonpe^^: ok, but this is indeed strange. if you did not include virtio.scc explicitly in your kernel recipe, then there has to be something that requires virtio.scc once meta-virtualization is plugged-in | 12:20 |
| RobertBerger | I added some ikconfig.cfg | 12:20 |
| RobertBerger | still baking | 12:20 |
| RobertBerger | At least this should work, not sure about the scc. | 12:21 |
| RobertBerger | I think it worked, since it compiles - so the fragment was merged somehow. | 12:21 |
| *** yangm <yangm!yanyetanot@gateway/shell/matrix.org/x-xqcacthdtlgbkdxo> has quit IRC | 12:21 | |
| *** hmw1 <hmw1!hmwmatrixo@gateway/shell/matrix.org/x-hjaomhxyegttpcom> has quit IRC | 12:21 | |
| *** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-sgmrkquphvtplfzx> has quit IRC | 12:21 | |
| *** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-uoxlbypwmeuyzhzc> has quit IRC | 12:21 | |
| *** clementp[m] <clementp[m]!cperonmatr@gateway/shell/matrix.org/x-dmjrnstgfyxvzast> has quit IRC | 12:21 | |
| *** GonZo2k <GonZo2k!gonzo2000m@gateway/shell/matrix.org/x-ubgagyrzgseupeoa> has quit IRC | 12:21 | |
| *** crazoes[m] <crazoes[m]!crazoesmat@gateway/shell/matrix.org/x-bxrmjqeuzznagwvk> has quit IRC | 12:21 | |
| *** kayterina <kayterina!kayterina-@gateway/shell/matrix.org/x-andgifryqmuthuuh> has quit IRC | 12:22 | |
| RobertBerger | Ahh I saw this virtio.scc also somewehre ;) | 12:22 |
| simonpe^^ | mass murder^^ | 12:22 |
| RobertBerger | Not sure what this reminds me of. | 12:22 |
| *** henriknj <henriknj!hnjematrix@gateway/shell/matrix.org/x-cyrirnfvcxagzzob> has quit IRC | 12:22 | |
| *** f0h[m] <f0h[m]!f0hmatrixo@gateway/shell/matrix.org/x-lnylcybvivtozuwd> has quit IRC | 12:22 | |
| simonpe^^ | maybe here? https://www.mail-archive.com/meta-virtualization@lists.yoctoproject.org/msg00692.html | 12:22 |
| fbre | Happy weekend to all. See you | 12:22 |
| RobertBerger | CU | 12:23 |
| simonpe^^ | fbre: happy weekend! | 12:23 |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 12:23 | |
| RobertBerger | virtio.scc is in meta-virt and also in some linux-yocto kernel recipes ;) | 12:24 |
| Yatekii | qschulz: I highly doubt that ever makes it into a release anytime soon ^^ other than that, that's not a proper reasoning ;) | 12:24 |
| RobertBerger | @simonpe which layers do you include? | 12:24 |
| qschulz | Yatekii: FWIW, it's been discussed numerous times on this channel and IIRC the thing was just to add everything to the keyring or the global git conf file or something. Nothing related to Yocto itself. | 12:25 |
| simonpe^^ | RobertBerger: "${sources.poky}/meta" | 12:26 |
| simonpe^^ | "${sources.poky}/meta-poky" | 12:26 |
| simonpe^^ | # Collection of layers for the OE-core universe | 12:26 |
| simonpe^^ | "${sources.meta-openembedded}/meta-oe" | 12:26 |
| simonpe^^ | "${sources.meta-openembedded}/meta-networking" | 12:26 |
| simonpe^^ | "${sources.meta-openembedded}/meta-filesystems" | 12:26 |
| simonpe^^ | "${sources.meta-openembedded}/meta-python" | 12:26 |
| simonpe^^ | "${sources.meta-openembedded}/meta-perl" | 12:26 |
| simonpe^^ | # Freescale (NXP) specific layers providing a base for our own | 12:26 |
| simonpe^^ | # machine configuration | 12:26 |
| simonpe^^ | "${sources.meta-freescale}" | 12:26 |
| simonpe^^ | # Firmware update support required by the system-x distro | 12:26 |
| simonpe^^ | "${sources.meta-rauc}" | 12:26 |
| simonpe^^ | # Container support required by the system-x distro | 12:26 |
| simonpe^^ | "${sources.meta-virtualization}" | 12:27 |
| simonpe^^ | uups | 12:27 |
| simonpe^^ | sry | 12:27 |
| zandrey_ | RobertBerger: please inspect your work-shared/<machine>/kernel-source/.kernel-meta/cfg/merge_config_build.log | 12:27 |
| RobertBerger | it's from meta-virtualization | 12:27 |
| Yatekii | qschulz: yeah I know that I can fix it with the global key store. The problem is that kas opens a chroot where the key store is missing. sure, we can blame kas for that. but they system yocto has in place for layer management - afaik it is non-existant - isn't better either ;) I think this would be fixable if using ssh (which I prefer over https anyways), not sure. anyways, having secrets in a build setup is not nice. but git with CIs and automated builds in | 12:27 |
| Yatekii | general works better with ssh :) | 12:27 |
| *** yangm <yangm!yanyetanot@gateway/shell/matrix.org/x-puiekragpvtnrrtq> has joined #yocto | 12:28 | |
| qschulz | Yatekii: IIRC, there was some discussion about merging/making official one of the layer management tool in the long term. Maybe I dreamt it, don't remember | 12:28 |
| Yatekii | qschulz: oh there is other ones than kas? I mean that's nice :) Sadly I need it now ... | 12:30 |
| qschulz | pyrex I think? from garmin | 12:32 |
| simonpe^^ | I use pyrex | 12:32 |
| simonpe^^ | its pretty neat | 12:32 |
| RP | hmm, the cooker logs are getting garbled :( | 12:32 |
| RobertBerger | @zandrey: looking good: https://pastebin.com/UVUsSLGt | 12:32 |
| simonpe^^ | RobertBerger: You'd want to check that the config generated actually is used for the kernel build too, that's the problem I had with the nxp kernel | 12:33 |
| simonpe^^ | It applied the patches but threw away the result and built with the pre-patched config | 12:33 |
| RobertBerger | It worked out of the box, just included a .cfg | 12:33 |
| simonpe^^ | RobertBerger: haha I think I know why you have vague memories of this virtio stuff: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13927 | 12:36 |
| RobertBerger | ah yes that as well ;) | 12:37 |
| Yatekii | qschulz simonpe^^ kas looks nicer tbh, but I am not sure how it really is :) I just wish I could run a custom script to populate the key store :/ | 12:38 |
| simonpe^^ | Yatekii: i liked it because the docker stuff is completely transparent | 12:40 |
| simonpe^^ | I hate having to live inside of a container without my vim configs etc | 12:40 |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has joined #yocto | 12:40 | |
| Yatekii | simonpe^^: I mean I lookt at the readme and it is like "to setup clone this, symlink this, symlink that, then run this bash script, etc" at this point I am already like "fuck off" | 12:41 |
| simonpe^^ | Yatekii: I use nix to manage all that crap so I don't really care anymore | 12:41 |
| shan1 | Guys quick question what is recipe name for the python package `cv2` I cannot find any recipe named `python3-opencv` or something similar? | 12:41 |
| RobertBerger | simonpe: you can add your vim configs to your container ;) | 12:41 |
| simonpe^^ | RobertBerger: I can, but I don't want to be messing around with that | 12:41 |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has left #yocto | 12:41 | |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has joined #yocto | 12:41 | |
| simonpe^^ | I just want my god damn environment that I've been polishing for the past 20 years lol | 12:42 |
| RobertBerger | and that would be your base container ;) | 12:42 |
| simonpe^^ | containers aren't VM:s, they are meant to run a single binary with dependencies in its own namespace/cgroup | 12:43 |
| simonpe^^ | you CAN use it as a VM but if reproducible environments is what I'm after I'd rather use nix | 12:44 |
| simonpe^^ | but yocto and nix doesn't play well yet so... | 12:44 |
| RobertBerger | @simonpe don't get me started ;) | 12:45 |
| simonpe^^ | :P | 12:45 |
| simonpe^^ | its good with diversity in thought, echo chambers are boring ;) | 12:45 |
| RobertBerger | You can build your container images with Yocto ;) | 12:46 |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has quit IRC | 12:46 | |
| RobertBerger | I am running some tests from the phoronic testsuite built with yocto natively as well as in a container. | 12:47 |
| RobertBerger | Now I would not call this a single binary ;) It contains a whole SDK ;) | 12:47 |
| RobertBerger | since phoronix wants to download sources and to build them before running the benchmark | 12:47 |
| *** crazoes[m] <crazoes[m]!crazoesmat@gateway/shell/matrix.org/x-oynemuzxdwztrsic> has joined #yocto | 12:48 | |
| *** kayterina <kayterina!kayterina-@gateway/shell/matrix.org/x-bqlpleeqpffpvzut> has joined #yocto | 12:48 | |
| *** henriknj <henriknj!hnjematrix@gateway/shell/matrix.org/x-agyqausyjxmrgfmp> has joined #yocto | 12:48 | |
| *** hmw1 <hmw1!hmwmatrixo@gateway/shell/matrix.org/x-zhzpenjzqjitjyqa> has joined #yocto | 12:48 | |
| *** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-ifjwucllxhrpbexn> has joined #yocto | 12:48 | |
| *** clementp[m] <clementp[m]!cperonmatr@gateway/shell/matrix.org/x-ipiidvsxcabwslum> has joined #yocto | 12:48 | |
| *** GonZo2k <GonZo2k!gonzo2000m@gateway/shell/matrix.org/x-eggbjkbdcbzhfred> has joined #yocto | 12:48 | |
| *** wak-work <wak-work!wak-workma@gateway/shell/matrix.org/x-esinmnqprvvgqsmg> has joined #yocto | 12:48 | |
| *** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-qmtnihvhcucnijlv> has joined #yocto | 12:48 | |
| *** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-rezopgpgvqlykool> has joined #yocto | 12:48 | |
| *** f0h[m] <f0h[m]!f0hmatrixo@gateway/shell/matrix.org/x-bspvxkhypnbfdsdo> has joined #yocto | 12:48 | |
| *** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/matrix.org/x-lzboudtkbcgcoory> has joined #yocto | 12:48 | |
| simonpe^^ | RobertBerger: yes I know, people do that everywhere and I just disagree with containers being the right tool for that job | 12:48 |
| RobertBerger | The next thing to look into are kubernetes - k8s and k3s | 12:49 |
| simonpe^^ | so I can build the kernel if I disable KERNEL_FEATURES_append = " virtualization" | 12:49 |
| RobertBerger | And otherwise it does not build because it does not find the file? | 12:50 |
| simonpe^^ | RobertBerger: I use k8s for cloud stuff, its pretty neat | 12:50 |
| RobertBerger | I have a fix for this ;) | 12:50 |
| simonpe^^ | is it the thing in your bug report? | 12:50 |
| RobertBerger | i want mixed x86pc/arm ... | 12:50 |
| simonpe^^ | SRC_URI += "file://features/cfg/virtio.scc"? | 12:50 |
| RobertBerger | Yes it's hidden somwhere in the bug report. | 12:50 |
| simonpe^^ | Did you try the dockerx stuff to run containers with qemu? | 12:51 |
| RobertBerger | Do thanks | 12:51 |
| RobertBerger | I build my containers with yocto ;) - at least those I want for my embedded stuff. | 12:51 |
| RobertBerger | No thanks ;) | 12:52 |
| RobertBerger | I looked into it, but don't get the point. Why would I want to run containers with qemu? | 12:52 |
| RobertBerger | To slow them down? | 12:52 |
| simonpe^^ | To run aarch64 on x86 | 12:52 |
| RobertBerger | Why would you want to do that? | 12:53 |
| simonpe^^ | to run integration tests without hardware | 12:53 |
| RobertBerger | You use the Yocto project right? | 12:53 |
| RobertBerger | cross - compilation ;) | 12:53 |
| RobertBerger | So you would build some random image for aarch64 based on, say debian for your yocto integration test? | 12:54 |
| RobertBerger | Either run some yocto built qemu image or a yocto build container if you run yocto on your hardware. | 12:55 |
| simonpe^^ | Well I only use yocto to build a container enabled OS. Toolchain and app deployment and stuff I use other tools to do, the containers don't care about the host OS anyway | 12:55 |
| RobertBerger | I can run basically the same "image" on native arm32 and in a container on arm32. aarch64 hopefully also soon. | 12:56 |
| RobertBerger | Well rootfs minus kernel in container | 12:57 |
| RobertBerger | The nice thing I saw is that the performance of stuff you run in a container and native is pretty much the same. | 12:57 |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has quit IRC | 12:58 | |
| simonpe^^ | RobertBerger: it is, it's just different namespaces and cgrouped | 12:58 |
| RobertBerger | it's just cgroups/namespaces - kernel stuff | 12:58 |
| RobertBerger | yep | 12:58 |
| RobertBerger | I made a little experiment today. | 12:58 |
| RobertBerger | imx6q with a soft floating point rootfs and docker. | 12:59 |
| RobertBerger | In the docker container hard floating point. | 12:59 |
| RobertBerger | Works nicely | 12:59 |
| simonpe^^ | heh | 12:59 |
| RobertBerger | ;) | 12:59 |
| simonpe^^ | I actually use podman instead of docker on the embedded machines | 13:00 |
| RobertBerger | I prefer docker, but it does not really matter. | 13:00 |
| RobertBerger | It's oci containers so they should work with podman as well. | 13:00 |
| simonpe^^ | yep | 13:01 |
| RobertBerger | Eventually with kubernetes all this will go away I hope. | 13:01 |
| RobertBerger | Anyways I am getting hungry - see you later | 13:01 |
| derRichard | when i load a yocto sdk and try to run "make menuconfig" on a external kernel, menuconfig fails badly because the sdk sets PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH. is this known? | 13:04 |
| derRichard | unsetting these vars makes menuconfig work | 13:04 |
| derRichard | see http://paste.debian.net/plainh/cad054c5 | 13:04 |
| *** thierryE <thierryE!sid286446@gateway/web/irccloud.com/x-wdsohxghiiqjimeh> has quit IRC | 13:32 | |
| *** thierryE <thierryE!sid286446@gateway/web/irccloud.com/x-oumraksouqftzjaz> has joined #yocto | 13:33 | |
| JPEW | RP: As an exercise, I converted the cooker to use a python multiprocess pool: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/cooker-worker-pool&id=324d0e0717598dc04a0e323c8aa134057e7eb326 | 13:38 |
| JPEW | It lead to some interesting insights that I think explain some of the problems we've been seeing | 13:38 |
| RobertBerger | @derRichard: What SDK is this? Classic or extensible? | 13:41 |
| derRichard | classic | 13:41 |
| RobertBerger | @derRichard: This always worked for me so far. | 13:41 |
| RobertBerger | dunfell or master? | 13:42 |
| derRichard | zeus | 13:42 |
| *** Sandrita <Sandrita!b8a36cf4@gateway/web/cgi-irc/kiwiirc.com/ip.184.163.108.244> has joined #yocto | 13:42 | |
| RobertBerger | When zeus was up to date this definitely worked as well ;) | 13:42 |
| RobertBerger | That's the way I play with kernels. | 13:43 |
| RobertBerger | So you installed the SDK, ran the environment script and need to do stuff to run menuconfig? | 13:43 |
| derRichard | yes | 13:44 |
| RobertBerger | Are you sure you ran this on a fresh shell - not one where you did a build before? | 13:44 |
| derRichard | fresh shell | 13:44 |
| derRichard | as you see i'm on suse and the library PKG_CONFIG_SYSROOT_DIR points to is plain wrong | 13:45 |
| derRichard | this is the bug | 13:45 |
| derRichard | maybe it worked by chance on your host because you build the sdk on the same distro as you used it later.. | 13:45 |
| RobertBerger | Yep - no idea where this comes from. | 13:45 |
| derRichard | my sdk is build on ubuntu and runs $anywhere | 13:45 |
| RobertBerger | I use a build container to build it | 13:46 |
| derRichard | same here | 13:46 |
| derRichard | the container runs ubuntu | 13:46 |
| derRichard | :) | 13:46 |
| RobertBerger | And menuconfig without the SDK environment works? | 13:46 |
| RobertBerger | are those libs installed on your host? sudo apt-get -y install libncursesw5-dev flex bison libssl-dev ncurses-dev | 13:47 |
| RobertBerger | Let me see on my current setup where PKG_CONFIG_SYSROOT_DIR point to ;) | 13:48 |
| derRichard | sure works menuconfig without the sdk | 13:48 |
| derRichard | this is my workstation where i work all day with kernels | 13:49 |
| derRichard | and no, no apt-get there. i run suse | 13:49 |
| derRichard | :) | 13:49 |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 13:49 | |
| RobertBerger | looking good to me ;) export | grep PKG_CONFIG_SYSROOT_DIR | 13:50 |
| RobertBerger | declare -x PKG_CONFIG_SYSROOT_DIR="/opt/resy/3.1/multi-v7-ml/imx6q-phytec-mira-rdk-nand/sysroots/armv7a-neon-resy-linux-gnueabi" | 13:50 |
| RobertBerger | you also didn't mv you installed sdk ;) | 13:51 |
| derRichard | of course not | 13:51 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:51 | |
| RobertBerger | it's a bug not a feature I would say ;) | 13:51 |
| * derRichard agrees | 13:51 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 13:51 | |
| derRichard | now i just need someone to blame ;-) | 13:51 |
| RobertBerger | Well which version you said? | 13:52 |
| RobertBerger | "Bring out the dead. I am not dead I feel fine" | 13:52 |
| RP | JPEW: what are those insights? | 13:53 |
| RobertBerger | zeus - hmm still community support so you might even try bugzilla. Do you really want me to dig out some ancient zeus SDK. I am 100% sure this works ;) | 13:53 |
| derRichard | RobertBerger: zeus is not that old :P | 13:53 |
| RobertBerger | It will be soon EOL | 13:54 |
| derRichard | the vast majority of my customers are on sumo or worse | 13:54 |
| RP | JPEW: I've been able to partly explain why we see hangs with cancel_thread_join() | 13:54 |
| derRichard | zeus is "new hot shite" for them ;) | 13:54 |
| RobertBerger | did you ever see this page? https://wiki.yoctoproject.org/wiki/Releases | 13:54 |
| derRichard | of course | 13:54 |
| derRichard | but you are in embedded too and should know how much customers like upgrades... | 13:55 |
| RobertBerger | so you know ;) | 13:55 |
| RobertBerger | Sure they can pay me for maintaining their old crap as well ;) | 13:55 |
| RobertBerger | I don't like it, but money talks. | 13:55 |
| * derRichard fixed lately an issue in 2.6.18 for a unnamed customer :P | 13:56 | |
| RobertBerger | zeus it actually not that old ;) | 13:56 |
| RobertBerger | hehe - insert coin | 13:56 |
| derRichard | *linux 2.6.18 | 13:56 |
| derRichard | the upgrade from 3.10-nxp to 4.12 took more or less a full man year.... | 13:57 |
| RobertBerger | You do this totally wrong. If someone asks you for this you ask for a multi million budget to update to 5.4. If they pay good, if not also ;) | 13:57 |
| derRichard | ;-) | 13:58 |
| RobertBerger | That's what I am saying. Insert many coins and everything is possible. | 13:58 |
| *** havok101 <havok101!~havok101@2601:241:8a00:46e0:3512:b88a:7c9e:abfa> has joined #yocto | 13:59 | |
| RobertBerger | Is it useful/long term forward thinking/helping anyone else but you having a lenghtly miserable job - not sure | 13:59 |
| derRichard | i get enough coins, no worries. | 13:59 |
| RobertBerger | Then it's OK | 13:59 |
| JPEW | RP: The first was that we are relying on the worker processes forking and keeping all the state from the parent to get the bb_cache data into the worker processes; I had to add the weird "global bb_caches" stuff to get that to work properly | 13:59 |
| RobertBerger | "Schmerzensgeld" | 13:59 |
| JPEW | RP: The thing about that is that it causes a lot of state problems when you mix it with thread (threads and forking don't mix well in general) | 14:00 |
| RP | JPEW: we're using threads in the cache code? | 14:00 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 14:01 | |
| derRichard | RobertBerger: well, i like my job and never have pain. most of the time i *cause* pain because i keep asking questions ;) | 14:01 |
| JPEW | RP: That was what I didn't know; are there any threads in the server process when it forks off the workers? | 14:01 |
| derRichard | "can you please explain me why your in-house driver is smp safe?" ;-) | 14:01 |
| RP | JPEW: I don't think so, I think hashserve and prserv are separate processes and there shouldn't be much else | 14:02 |
| RP | JPEW: I know threading and multiprocess do not mix well so we try and only use mp here | 14:03 |
| RobertBerger | I found some 3.0.1 SDK lurking around here ;) | 14:03 |
| qschulz | I'm writing some internal presentation about debugging sw with Yocto and i'm trying to understand what's the advantage of devshell compared to devtool? | 14:03 |
| RP | JPEW: I did file https://bugs.python.org/issue41714 | 14:03 |
| RobertBerger | hehe - yes I also would like to know what makes you think your in house driver is smp safe ;) | 14:04 |
| derRichard | $ grep Version ~/sdks/s2x86/version-i586-poky-linux | 14:04 |
| derRichard | Distro Version: 1.4.3 | 14:04 |
| RobertBerger | @qschulz: totally different things | 14:04 |
| derRichard | anymore questions? ;-) | 14:04 |
| JPEW | RP: OK. The reason I found it was because pool.apply_async() refuses to serialize Lock objects, and there are some (somewhere?) in the bb_caches (my guess is in logging handlers) | 14:04 |
| kergoth | RP, JPEW may need to verify that we're using multiprocessing.Queue, not queue.Queue everywhere, i *think* queue.Queue may use threads behind the scenes (not 100% certain, though) | 14:05 |
| RobertBerger | and also i586 and not x86_64 ;) | 14:05 |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has joined #yocto | 14:05 | |
| kergoth | that is ,we need to watch for use of threads by the modules we use, not just direct | 14:05 |
| *** yann <yann!~yann@88.120.44.86> has quit IRC | 14:05 | |
| * kergoth yawns | 14:05 | |
| JPEW | Anyway, it's academic because you wouldn't want to serialize the bb_caches for each async_apply() anyway; providing them in init() is way more efficient | 14:05 |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 14:06 | |
| qschulz | RobertBerger: that's very helpful thank you :) | 14:06 |
| RobertBerger | @qschulz: devtool is the beginner's drug for developers to drag them into yocto via the extensible SDK | 14:06 |
| RP | JPEW, kergoth: I think we do use threads *after* we shut down the multiprocessing pool | 14:06 |
| qschulz | RobertBerger: no eSDK nor SDK for me :shrug: | 14:07 |
| RP | kergoth: I'm fairly sure you're right that queue.Queue uses threads and yes, we should double check | 14:07 |
| RobertBerger | I am just answering your question ;) | 14:07 |
| RP | JPEW: I have logging from some of the overnight bitbake server issues and it makes depressing reading | 14:07 |
| kergoth | yeah, i know our workers use a queue. what about memory resident behavior on file change spotted by the fs watching? do we ever reparse after we've run workers? hmm | 14:08 |
| RobertBerger | real Bitbake hackers use vim and not devtool ! | 14:08 |
| RP | Some many things are screwed up but I can't tell the root cause | 14:08 |
| RobertBerger | And yes accidentally you can also use it when you are in cooker mode. | 14:08 |
| * kergoth shrugs, worth a check, now for coffee, wanders off | 14:08 | |
| RP | kergoth: It may explain some of the memres bugs but things are still running in one shot mode. I guess unless something gets the timing right | 14:08 |
| RobertBerger | try: bitbake busybox -c devshell | 14:08 |
| JPEW | RP: The second insight was that whatever the pool does to terminate made the worker threads hang on SIGTERM, which in turn made the cooker process hang whenever you CTRL+C | 14:09 |
| RobertBerger | This brings you in a shell with the code already there and cross tools setup | 14:09 |
| JPEW | Which I resolved with the signal handler (call os._exit(1) on signals instead of trying to cleanup) | 14:09 |
| RobertBerger | I use it sometimes to debug things when build break. But if you make changes there, they are gone with the next bitbake. | 14:10 |
| RobertBerger | So if e.g. you make a patch you need to save it somewhere not to be overwitten by the next bitbake run. | 14:10 |
| RobertBerger | Anways try it out. | 14:10 |
| qschulz | devtool modify? | 14:10 |
| derRichard | hmm. "devtool modify virtual/kernel" works but "devtool update-recipe virtual/kernel" not. for update-recipe it wants the real name :( | 14:10 |
| RobertBerger | devshell | 14:10 |
| qschulz | the use case you're suggesting is the same as devtool modify | 14:11 |
| RobertBerger | devtool is something which can even, if the weather is good create recipes for you ;) | 14:11 |
| JPEW | RP, kergoth: I'm wondering if there is some weird combination of cleanup code inherited from the main process in the worker processes that causes them to go weird when terminated | 14:11 |
| RobertBerger | As I said 2 totally different things. | 14:11 |
| RobertBerger | devshell more likely for debugging things | 14:11 |
| RP | JPEW: that is interesting to know. Does that improve if you get rid of cooker's SIGTERM/SIGHUP handler? | 14:12 |
| JPEW | I can try that | 14:12 |
| RP | JPEW: I think this hanging issue is why we didn't use the pool | 14:12 |
| RobertBerger | devtool to create recipes, modify, upload to target,... more a developer tool. | 14:12 |
| qschulz | RobertBerger: I've only ever used devtool for debugging recipes/sw from Yocto, hence the question | 14:12 |
| RobertBerger | How you debug recipes with devtool ? | 14:12 |
| RobertBerger | I usually debug recipes produced by devtool ;) | 14:12 |
| qschulz | nah not recipes actually, don't know why I put that there, sw from Yocot is what I wanted to say | 14:13 |
| RobertBerger | So I have a recipe which does not work, how would you debug it with devtool? | 14:13 |
| JPEW | RP: Right, but I'm not sure if the workers should even be doing a graceful cleanup on SIGTERM (pool or not) | 14:14 |
| qschulz | RobertBerger: depends... if it's just a compilation issue, devtool for patching the source code | 14:14 |
| RP | JPEW: you mean parsers right? | 14:14 |
| qschulz | RobertBerger: if recipe, I apply my best Yocto-fu knowledge and use vim :) | 14:14 |
| RobertBerger | I see. So we have a different opinion about what debugging means ;) | 14:15 |
| RP | JPEW: we do need to be robust against people hitting Ctrl+C while bitbake is running | 14:15 |
| RP | JPEW: this is where many of our changes and fixes in this code started from | 14:15 |
| RobertBerger | So you see devtool is more for the developer who uses an eSDK and wants to do some things with Yocto although no Yocto-fu | 14:15 |
| RobertBerger | Actually if you are lucky it indeed can generate from a git repo out there in the wild a working recipe. | 14:16 |
| qschulz | RobertBerger: I know devtool :D devshell, I don't :) | 14:17 |
| RobertBerger | So run devshell | 14:17 |
| JPEW | RP: Ya, if I remove the cookers signal handler the workers exit on CTRL+C without installing their own signal handler | 14:17 |
| RobertBerger | bitbake busybox -c devshell | 14:17 |
| JPEW | ... which makes sense looking at the cookers handler :) | 14:17 |
| RP | JPEW: right, cooker's handler is horrible from a forked off process perspective | 14:18 |
| JPEW | What does "robust against CTRL+C" mean? | 14:18 |
| RP | JPEW: when the user hits Ctrl+C, bitbake exits "nicely" | 14:18 |
| RP | no trashed cache files, doesn't hang, spew tracebacks | 14:19 |
| RP | some of this code dates to when the UI wasn't a separate process | 14:20 |
| JPEW | RP: Ok, doing `signal.signal(signal.SIGTERM, signal.SIG_DFL)` in the worker init makes it behave properly when the cooker is handling SIGTERM | 14:23 |
| RobertBerger | @qschulz: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#platdev-appdev-devshell | 14:24 |
| RobertBerger | not a lot, but at least a little bit ;) | 14:24 |
| RP | JPEW: ok, that helps. I wonder what multiprocessing relies on that uses SIGTERM | 14:25 |
| JPEW | pool.terminate() sends SIGTERM to all the workers | 14:25 |
| qschulz | RobertBerger: I've read all of that already. I was asking for real life usecases that people have had before that required devshell. I understand what it does, I'm just like "when would this be useful?" | 14:26 |
| RP | JPEW: ok, that would definitely break :) | 14:26 |
| RobertBerger | The use case for me is what you mentioned for the devtool. | 14:26 |
| RobertBerger | A compilation breaks | 14:26 |
| RobertBerger | And i want to manually redo the steps | 14:26 |
| RobertBerger | It places you in $S with the cross compiler operational | 14:27 |
| RobertBerger | similar, but not the same as if you would use an SDK to build stuff | 14:28 |
| qschulz | RobertBerger: are you executing run.do_task then or really doing step by step? | 14:28 |
| RobertBerger | Yep something like that. | 14:29 |
| qschulz | RobertBerger: (e)SDK is completely foreign to me still :/ so can't relate unfortunately | 14:29 |
| RobertBerger | I would e.g. on autotool project configure/make and so on | 14:29 |
| RobertBerger | Imagine a world without Yocto - I know it's hard. | 14:29 |
| qschulz | RobertBerger: /join #buildroot | 14:29 |
| qschulz | :'D | 14:29 |
| RobertBerger | And without buildroot. | 14:30 |
| RobertBerger | You are just a "normal" developer and someone gives you something called SDK. | 14:30 |
| qschulz | RobertBerger: I've been blessed to be born "late" in the 1900 century and I didn't have to care much about building my system by hand ;) | 14:30 |
| RobertBerger | A cross toolchain with a so called sysroot ;) | 14:30 |
| RobertBerger | You are not blessed - you missed lots of fun! | 14:31 |
| qschulz | fun I don't know, but knowledge, for sure | 14:31 |
| RobertBerger | I remember building with a team our own Linux distro including the toolchain. | 14:31 |
| RobertBerger | You can't imagine how much you learn along the way ;) | 14:31 |
| qschulz | yeah.. Kids got it too easy today don't they :D | 14:32 |
| RobertBerger | roughly one year later developers could take the pre release alpha version and develop their stuff. | 14:32 |
| RobertBerger | Of course - they were never in any war. Neither the first nor the second ;) | 14:33 |
| RP | JPEW: I'm tempted to merge your cleanup... | 14:34 |
| RP | JPEW: I think there are other issues too though :( | 14:34 |
| JPEW | RP: Ya, I actually think it could be a lot better... I have a few cleanups | 14:35 |
| JPEW | Like what? | 14:35 |
| RobertBerger | @qschulz but you still can try Linux from Scratch today ;) | 14:35 |
| RP | JPEW: we're still seeing leftover threads when we exit and I don't think they're from the parsing code | 14:40 |
| qschulz | RobertBerger: one day... one day :D | 14:40 |
| RP | JPEW: I think my patch removes the problems we had there but there is still some set of other issues somewhere | 14:40 |
| JPEW | Is there a bug entry for the threads? I don't remember that one | 14:41 |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 14:42 | |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has joined #yocto | 14:43 | |
| JPEW | RP: Sorry, I'm trying to switch between too many context :) Were the leftover threads related to the cancel_join_thread() ? | 14:44 |
| shan1 | hi all any reference layer or recipe to cross-compile golang code from x86 to armv7? | 14:44 |
| RP | JPEW: I simply don't know :( | 14:44 |
| RP | JPEW: I've just sent four patches which try and beat the logging in server/process.py into some kind of shape to be semi usable | 14:44 |
| RobertBerger | @qschulz: you will get older and will need to tell your grand children that you never built a Linux from scratch ;) | 14:45 |
| RP | JPEW: you'll hate the serverlog() one but its a workaround for now | 14:45 |
| JPEW | RP: Heh, I added pretty much the same function in my patch :) | 14:46 |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-193.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 14:47 | |
| qschulz | RobertBerger: /me notes "do not reproduce before you have built Linux from scratch" | 14:47 |
| RobertBerger | hehe ;) | 14:49 |
| RobertBerger | Now I know where I saw this the last time "WARNING: /workdir/sources/poky/../meta-freescale/recipes-kernel/linux/linux-imx-mfgtool_5.4.3.bb: Unable to get checksum for linux-imx-mfgtool SRC_URI entry virtio.scc: file could not be found | 14:50 |
| RobertBerger | " | 14:50 |
| RobertBerger | But my kernel recipe does not care about it and keeps on going ;) | 14:51 |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has quit IRC | 14:54 | |
| RP | JPEW: sent a couple more tweaks for cooker which may aid debugging | 14:55 |
| RP | JPEW: heh, yes, I didn't spot that! | 14:56 |
| RP | JPEW: I guess I should wait until after maint on the autobuilder, then run -next and see how things look with that | 14:57 |
| JPEW | RP: Why does every worker process dump parser and fetcher cache? | 15:04 |
| JaMa | RobertBerger: meta-virtualization adds that and e.g. rpi doesn't have it as well | 15:05 |
| JaMa | RobertBerger: https://github.com/shr-project/meta-webosose/commit/491bea743b4f5bc1782edd048dacd21748bff54c#diff-6ccf8bc05c2664ecd3a7a651c585b947R12 | 15:06 |
| JPEW | RP: Ah, looks like it's for debugging, since it's per PID? | 15:09 |
| RobertBerger | @JaMa I know ;) | 15:09 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 15:10 | |
| JPEW | Oh, they are merged later.... I can read code today :) | 15:10 |
| RobertBerger | @JaMa this is also an option, or I could add it. But anyways nothing breaks - it's just not enabled | 15:10 |
| RobertBerger | WARNING not ERROR | 15:11 |
| RobertBerger | I will have a look at it as well when I feel like massaging my raspi 4 64 bit | 15:11 |
| JaMa | looks like my error was slightly different, because it was missing feature, for you it's just missing in SRC_URI | 15:11 |
| RobertBerger | Yep | 15:12 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 15:12 | |
| RobertBerger | I have my own kernel recipe | 15:12 |
| RobertBerger | Anyways it can be added as well ;) | 15:12 |
| RobertBerger | It just does not seem to find the one in the meta-virtualization layer. | 15:13 |
| RobertBerger | @JaMa I have some preliminary - close to upstream 5.8.x kernel raspi 4 64 bit here up and running ;) | 15:14 |
| *** wak-work <wak-work!wak-workma@gateway/shell/matrix.org/x-esinmnqprvvgqsmg> has left #yocto | 15:32 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 15:40 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 15:43 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 15:44 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 15:45 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto | 15:48 | |
| *** yacar_ <yacar_!~yacar_@91-168-169-253.subs.proxad.net> has quit IRC | 15:53 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 16:09 | |
| *** abhiarora44 <abhiarora44!uid396576@gateway/web/irccloud.com/x-brdbisdyobbogwof> has joined #yocto | 16:18 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 16:23 | |
| *** Hadi <Hadi!488c1abd@CPE0c473d757833-CM0c473d757830.cpe.net.fido.ca> has joined #yocto | 16:29 | |
| *** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-qmtnihvhcucnijlv> has quit IRC | 16:31 | |
| Hadi | I have a group of framework recipes that needs to compiled with bunch application recipes. Both framework and application shares a single include file which changes with every application recipe/. | 16:32 |
| Hadi | So I need to rebuild the framework recipes every time with each of the application recipes. | 16:33 |
| qschulz | Hadi: in framework recipe: DEPENDS = "application-recipe" | 16:35 |
| Hadi | application recipe does a DEPEND to framework recipe | 16:35 |
| Hadi | But app1, app2 app2 has different configuration for the framework recipe | 16:36 |
| Hadi | So framework recipes needs to be rebuild every time for each of the application recipes | 16:37 |
| Hadi | We are using the famework recipes a tool that needs to compiled for every application recipes | 16:38 |
| Hadi | Yocto only build a recipe once. That means the framework recipes are build only once. | 16:40 |
| Hadi | I am looking for a instance of a group of framework recipes for my application recipe. Hope I am able to explain this | 16:41 |
| *** mckoan is now known as mckoan|away | 16:42 | |
| mattsm | Hadi: can you describe the framework recipe in more detail? | 16:49 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 16:49 | |
| Hadi | Our framework recipes and application recipes are all separate git repositories. They all shared a common header file that is "application-specific". The dependency is reversed. Each application has it's own header file that it wants to use compile a set of framework library(reciepes). Eg app1, app2 has header_1.h and header_2.h . App1 wants | 17:01 |
| Hadi | to build frame1.bb frame2.bb with header_1.h . App2 want to build frame1.bb and frame2.bb with header_2.h | 17:01 |
| *** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 17:03 | |
| Hadi | In other word, application recipes are trying to use a tool library(framework recipes) that needs to build every time. Thus the complication | 17:05 |
| Hadi | Does it make sense? | 17:06 |
| erbo | Hadi: doesn't sound like an ideal situation :) If you can't somehow break that dependency by rethinking you're design, I guess you'll have to ship one version of the framework per application. | 17:22 |
| erbo | err, "your design" | 17:23 |
| RP | JPEW: you mean the codeparser cache? | 17:26 |
| khem | RP: I have sent a v2 for go patch, happy that in v2 I dropped the musl patch along with fix | 17:29 |
| Hadi | The framework recipes produce static libraries that the application recipe consumes it. If you think about it, gcc tool works on the same principle, all applications can pass in its own set of parameters to the gcc tool . The only difference is, we don't build gcc tool every time. gcc is a binary tool. In other words, I am trying to build gcc | 17:33 |
| Hadi | tool prior to using it in every application recipe. | 17:33 |
| RP | khem: just queued it, thanks | 17:34 |
| erbo | Hadi: if each build of the framework is so tightly coupled with the app, and also linked statically, just build it as part of the application? | 17:35 |
| *** osullivan99 <osullivan99!~osullivan@host-82-135-4-50.static.customer.m-online.net> has quit IRC | 17:37 | |
| erbo | If one build of the framework is shared with multiple apps, and you want to just build it once, create multiple recipes of framework which builds with a certain header file and the apps that want that version just depend on that | 17:37 |
| Hadi | That is one option, But we got ~100 applications . It will be hard to maintain multiple instance of framework recipes. I was considering BBclassextend | 17:40 |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has quit IRC | 17:41 | |
| RP | Hadi: BBCLASSEXTEND could work well for that FWIW | 17:42 |
| RP | Hadi: or just fetch the framework and the application in the same SRC_URI together | 17:43 |
| Hadi | If I could pull in all framework git repos and application repo in a single recipe. That would be ideal. But the problem is I need manage the compile of all framework receipes | 17:43 |
| Hadi | RP: Thanks. I tried that. | 17:44 |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 17:44 | |
| JPEW | RP: Ya | 17:44 |
| RP | JPEW: coreparser is generated per process but we need to combine it all together and save it as one cache | 17:44 |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 17:45 | |
| JPEW | RP: Ya, I see thats what the code is doing now :) | 17:45 |
| RP | we can do that "out of band" of the ongoing other bitbake things | 17:45 |
| Hadi | I need to manage the build of all framework git repositories inside a single application recipe | 17:45 |
| Hadi | RP: | 17:45 |
| Hadi | RP: what is FWIW | 17:46 |
| RP | Hadi: For what its worth | 17:47 |
| Hadi | lol | 17:47 |
| Hadi | I was searching for yocto class | 17:47 |
| RP | Hadi: I'm afraid I don't understand enough about what you're trying to do. I'd imagine a set of framework and application recipes, all BBCLASSEXTENDing off a common list of things to build could work but I don't really know anything about your use case | 17:47 |
| * RP also needs to head afk, its turned into an insane day :( | 17:48 | |
| Hadi | Thanks RP | 17:48 |
| khem | break the dependency by creating framework-headers recipe or some such | 17:49 |
| khem | I guess header is app specific is it ? | 17:50 |
| khem | I would take a harder look at your SW architecture | 17:50 |
| khem | and perhaps build issue is only showing the symptom of larger problem | 17:51 |
| Hadi | in the framework recipe i would have BBCLASSEXTEN="app1, app2 app3" . In the application recipe(app1.bb) I would use DEPEDS="frame1-app1" in app2 recipe I would have DEPENDS="frame1-app2" | 17:51 |
| RobertBerger | Maybe I understand DEPENDS in the wrong way, but doesn't this mean that I BitBake should first build firmware-imx-8m and then do the do_compile_prepend in this recipe? https://gitlab.com/meta-layers/meta-phyboard-polis-imx8mm-bsp/-/blob/master/recipes-bsp/u-boot/u-boot-phytec-imx_2019.04.bb#L17 | 17:52 |
| RobertBerger | What's happening here is that I would like to use some binaries which come form another recipe ;) | 17:53 |
| RobertBerger | In my recipe. | 17:53 |
| RobertBerger | And it does not quit work. Once I manually build the dependency all is good, but it's not triggered automatically. | 17:54 |
| RobertBerger | That's the other recipe this depends on: https://github.com/RobertBerger/meta-freescale/blob/2020-08-28-dunfell/recipes-bsp/firmware-imx/firmware-imx-8m_8.5.bb | 17:55 |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 18:05 | |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 18:20 | |
| *** rcoote <rcoote!~rcoote@5.146.198.159> has joined #yocto | 18:32 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 18:42 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 18:45 | |
| *** nslu2-log_ is now known as nslu2-log | 18:45 | |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC | 18:54 | |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto | 18:59 | |
| *** abhiarora44 <abhiarora44!uid396576@gateway/web/irccloud.com/x-brdbisdyobbogwof> has quit IRC | 19:06 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 19:23 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 19:37 | |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 19:48 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:55 | |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has joined #yocto | 20:01 | |
| RobertBerger | So looking at it again I think I found what was the problems. DEPENDS was not enough. xxx[depends] was needed as well ;) | 20:02 |
| *** vineela <vineela!~vtummala@134.134.139.74> has joined #yocto | 20:11 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 20:17 | |
| *** Hadi <Hadi!488c1abd@CPE0c473d757833-CM0c473d757830.cpe.net.fido.ca> has left #yocto | 20:22 | |
| *** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto | 20:38 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 20:39 | |
| *** aidanh_ is now known as aidanh | 20:39 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-193.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 20:41 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 20:47 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 20:53 | |
| khem | yes in such cases you can set specific task level dependency on another task from different recipe | 20:58 |
| kergoth | RobertBerger: DEPENDS means the other recipe's files were installed and populated into the recipe sysroot before do_configure is run in this recipe, but only a specific list of directories is allowed into staging/sysroot, see staging.bbclass | 21:01 |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 21:05 | |
| bantu | Hi. Does INCOMPATIBLE_LICENSE apply to build time dependencies as well as runtime dependencies? | 21:06 |
| zandrey | RP, khem: i know you guys are probably busy with M3, but can you please comment on allarch and -dev packages case that I posted the other day? or should I simply create an entry in bugzilla for that? | 21:10 |
| *** Sandrita <Sandrita!b8a36cf4@gateway/web/cgi-irc/kiwiirc.com/ip.184.163.108.244> has quit IRC | 21:12 | |
| *** sno <sno!~sno@p5b25b0d4.dip0.t-ipconnect.de> has quit IRC | 21:17 | |
| *** sno <sno!~sno@p5b25b0d4.dip0.t-ipconnect.de> has joined #yocto | 21:20 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 21:47 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 21:49 | |
| *** nslu2-log_ is now known as nslu2-log | 21:49 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC | 22:10 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 22:16 | |
| *** havok101 <havok101!~havok101@2601:241:8a00:46e0:3512:b88a:7c9e:abfa> has quit IRC | 22:17 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 22:18 | |
| RP | zandrey: I really don't see the issue with allarch -dev packages | 22:25 |
| RP | zandrey: not creating them means adding lots of special case code but things will still depend on them since we can't know if a given dependency is allarch or not | 22:25 |
| RP | I can imagine an allarch recipe which did install dev only stuff like a -config script too | 22:26 |
| *** dev1990 <dev1990!~dev@dynamic-62-87-247-41.ssp.dialog.net.pl> has quit IRC | 22:27 | |
| JaMa | anyone seeing random harfbuzz build failures with dunfell? harfbuzz-2.7.2/src/hb-common.cc:625:1: error: no previous declaration for 'void hb_version(unsigned int*, unsigned int*, unsigned int*)' | 22:58 |
| RP | JaMa: we've started seeing them in master :/ | 22:59 |
| RP | JaMa: 14038 14036 | 23:00 |
| RP | bugs #14028 and #14036 | 23:00 |
| JaMa | ah Ross is on it already it seems https://github.com/harfbuzz/harfbuzz/pull/2668 | 23:02 |
| JaMa | and my failed build I was just looking at was also based on master, not dunfell, will check if dunfell is also affected | 23:04 |
| RP | JaMa: cool, I know rburton said he'd take a look | 23:07 |
| *** rcw <rcw!~rcw@45.72.241.84> has quit IRC | 23:09 | |
| *** Sara <Sara!3cf32003@60.243.32.3> has joined #yocto | 23:23 | |
| Sara | Dear all, I am new to Yocto - I need to build a custom Image for RaspberryPi to fast boot into a QT application. Kindly suggest the right step - I was trying to learn yocto for past few weeks, but quite overwhelming. Please guide | 23:25 |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 23:27 | |
| Sara | SHould i start with OpenEmbedded or with Yocto? | 23:27 |
| RP | Sara: OE is the build environment used by the Yocto Project so its all related | 23:29 |
| RP | Sara: personally I'd try a poky checkout with the addition of the meta-raspberrypi layer, see if you can get basic images booting on your pi | 23:30 |
| RP | once you have the basics, then start on the QT application | 23:30 |
| Sara | RP thanks for the note, so poky is the sample project that can be used to build the image | 23:31 |
| Sara | RP thanks for the note, so poky is the sample project that can be used to build the image ? | 23:31 |
| Sara | Which book do you recommend or link thats meant for Beginners like me (im good at linux but couldnt get hold of yocto last few days) | 23:32 |
| Sara | I have been trying to get this working, but this has been failing many times (last 7 times ) | 23:33 |
| RP | Sara: did you try the Quick build document? | 23:38 |
| RP | Sara: the best way forward is probably to try and build up to what you need in stages - get a basic qemu build working ok, then get an image for the raspberrypi, then add QT | 23:39 |
| RP | Sara: https://www.yoctoproject.org/docs/3.1.2/brief-yoctoprojectqs/brief-yoctoprojectqs.html | 23:39 |
| *** Sara <Sara!3cf32003@60.243.32.3> has quit IRC | 23:43 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!