Friday, 2020-09-04

*** kiwi_29 <kiwi_29!> has joined #yocto00:06
*** kiwi_29_ <kiwi_29_!> has joined #yocto00:07
*** kiwi_29 <kiwi_29!> has quit IRC00:07
*** vineela <vineela!vtummala@nat/intel/x-jmtszwzsppipches> has joined #yocto00:08
*** vineela <vineela!vtummala@nat/intel/x-jmtszwzsppipches> has quit IRC00:15
*** kiwi_29_ <kiwi_29_!> has quit IRC00:40
*** kiwi_29 <kiwi_29!> has joined #yocto00:41
*** camus1 <camus1!~Instantbi@> has joined #yocto01:38
*** kaspter <kaspter!~Instantbi@> has quit IRC01:39
*** camus1 is now known as kaspter01:39
*** kiwi_29 <kiwi_29!> has quit IRC02:40
*** stephano <stephano!> has quit IRC02:53
*** kiwi_29 <kiwi_29!> has joined #yocto02:53
*** sakoman <sakoman!> has quit IRC03:16
kiwi_29Hello..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/module03:52
kiwi_29s/ directory in rootfs03:52
*** kiwi_29 <kiwi_29!> has quit IRC03:59
*** jrdn <jrdn!> has joined #yocto04:04
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC04:08
*** kiwi_29 <kiwi_29!> has joined #yocto04:10
*** kiwi_29 <kiwi_29!> has quit IRC04:24
*** kiwi_29 <kiwi_29!> has joined #yocto04:24
*** kiwi_29 <kiwi_29!> has quit IRC04:30
*** feddischson <feddischson!> has joined #yocto04:31
*** kiwi_29 <kiwi_29!> has joined #yocto04: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 IRC04:49
kiwi_29RobertBerger thanks.. let me check and will be right back04:49
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto04:50
kiwi_29btw... I used. MACHINE_EXTRA_RDEPENDS += "kernel-module-<MODULENAME>" and this did nothelp04:50
RobertBerger@kiwi_29: yes this does not help.04:52
kiwi_29but 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_29mine is in-tree kernel module04:53
RobertBergerYou 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.ipk04:54
kiwi_29mine is let me check04:55
RobertBergerMACHINE_EXTRA_RDEPENDS does not care about in tree or out of tree04:57
RobertBergerpeople just like to install all of them04:57
RobertBergerHmm 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_29yes it is05:00
RobertBergerso 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_29I m not adding kernel-module-<MODULENAME> in IMAGE_INSTALL +=05:02
RobertBergerand when you use kernel-module-<MODULENAME> it's not05:02
kiwi_29yes when I use MACHINE_EXTRA_RDEPENDS += it does not appera in my rootfs05:02
kiwi_29I use MACHINE_EXTRA_RDEPENDS += because it is not necessary for boot time05:02
kiwi_29I m *NOW* adding kernel-module-<MODULENAME> in IMAGE_INSTALL +=05:03
kiwi_29compiling now05:03
RobertBergerand also if you use kernel-modules that it ends up together with all the others05:03
RobertBergerin the rootfs05:04
RobertBergerwhat image do you build? A small one?05:04
kiwi_29usine IMAGE_INSTALL += kernel-modules. will add all the modules in rootfs05:05
RobertBergerI think I know your problem ;)05:05
RobertBergerIf you build a small image like e.g. core-image-minimal it will not work with your variable05:05
RobertBergerThis variable affects all images based on packagegroup-base, which does not include the core-image-minimal or core-image-full-cmdline images.05:06
RobertBergerIs this the case?05:06
kiwi_29oh boy ... my image derives from core-image-minimal05:06
RobertBergerhehe got it05:06
RobertBergeruse MACHINE_ESSENTIAL_EXTRA_RDEPENDS as I suggested05:06
kiwi_29I would have spent whole night trying to debug05:07
kiwi_29thanks..let me check the IMAGE_INSTALL += kernel-module-<MODULENAME> first05:07
kiwi_29and then will try the MACHINE_ESSENTIAL_EXTRA_RDEPENDS05:07
kiwi_29but many thanks RobertBerger05:07
RobertBergerNo prob it's a classic ;)05:07
kiwi_29I read that whole paragraph ..but my brain just filtered it :D05:09
RobertBergerHehe - been there seen that05:11
kiwi_29compiled..and works !  ..thanks again RobertBerger05:16
*** kiwi_29 <kiwi_29!> has quit IRC05:16
*** kiwi_29 <kiwi_29!> has joined #yocto05:22
RobertBerger@kiwi_29: You did everything right except for the magic variable ;)05:28
*** beneth <beneth!> has joined #yocto05:35
*** AndersD <AndersD!> has joined #yocto05:39
*** kiwi_29 <kiwi_29!> has quit IRC05:43
*** AndersD <AndersD!> has quit IRC05:55
*** pohly <pohly!> has joined #yocto05:59
*** pbergin <pbergin!> has quit IRC06:03
*** ilkappe <ilkappe!c65a42b1@> has joined #yocto06:23
ilkappeRobertBerger it seems that i found the busillis06:23
simonpe^^3rd day into trying to manipulate NXP BSP:s to incorporate my own kernel configuration into the build. I've copied their 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 either06:29
simonpe^^all my stuff is overwritten = it completely ignores my defconfig06:30
RobertBerger@ilkappe ?06:31
ilkappetry using: KBUILD_DEFCONFIG variable06:31
ilkappeRobertBerger the missing driver issue06:31
ilkappeafter two days I got a lead06:31
RobertBergerYep  and how you fixed it?06:31
ilkappethere was a Missing line in the Makefile of the driver06:32
RobertBergerhehe ;)06:32
ilkappethe <driver-y> :=06:32
*** zandrey <zandrey!> has quit IRC06:32
ilkappeso the .c were compiled but the driver was not created06:32
simonpe^^ilkappe: I actually tried that06:32
simonpe^^ilkappe: it doesn't help06:32
RobertBergerIf 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 var06:33
RobertBergerLike 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 dir06:33
RobertBerger@simonpe: Do are you on meta-freescale or you use all the funny NXP stuff?06:34
RobertBergerAre you on06:34
simonpe^^RobertBerger: Im all in on NXP funny stuff06:34
simonpe^^which I regret06:34
ilkappeRobertBerger yep, thanks fot hte hint06:34
RobertBergerAnd you don't want to use meta- freescale in order to reduce your necessary drug consumption?06:35
simonpe^^RobertBerger: Well, I do like drugs06:35
RobertBergerHehe but for other reasons ;)06:35
simonpe^^but seriously, I would love to throw the NXP stuff out06:36
ilkappejust put your config in  arch/$ARCH dir06:36
RobertBergerAnd not only to decrease your blood pressure ;')06:36
RobertBergerPlease throw it out !06:36
ilkappeand set KBUILD_DEFCONFIG06:36
simonpe^^ilkappe: that was the last thing I tried, to overwrite all the defconfigs in there06:36
simonpe^^it doesn't help06:36
ilkappechange the name eg to my_defconfig06:36
simonpe^^I'll try that out06:36
simonpe^^RobertBerger: how would one use the meta-freescale stuff vanilla mode?06:37
RobertBergerWow funny NXP stuff and changes on top of it. That's brave.06:37
ilkappeadd it eg to arch/arm64/configs/06:37
RobertBergerLike I posted it here:
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 have06:38
ilkappeand set KBUILD_DEFCONFIG=my_defconfig in the recipe06:38
RobertBergerthat's only poky/meta-freescale/meta-openembedded06:38
simonpe^^So I'm on a 2019 zeus release06:38
*** jrdn <jrdn!> has quit IRC06:38
RobertBergerWith the other you are on dunfell06:38
RobertBergerAnd you have community support06:38
RobertBergerWith the NXP stuff you have nothing like that06:38
simonpe^^RobertBerger: how much work you'd expect for me to move over to that?06:39
RobertBergerTo move your stuff over to it?06:39
RobertBergerNo 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 crazy06:39
RobertBergerSo I guess that should be very similar/the same, since meta-freescale is also used by the funny NXP stuff06:40
RobertBergerDo you have some FSL eval board?06:40
simonpe^^I have the imx8mnevk board06:40
simonpe^^would that work?06:41
RobertBergerI think it's supported:
simonpe^^ok so I'll tell my project manager that this is important because we want community support06:42
RobertBergerMy instructions are for the mm, so it's trivial to change that.06:42
simonpe^^thanks a lot boys and/or girls06:42
RobertBergerI 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/> has joined #yocto06:42
RobertBergerWell ask your manager who will support you with the official NXP stuff.06:43
RobertBergerOf 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 support06:43
simonpe^^after the evaluation period we're out of luck06:43
RobertBergerNXP ?06:43
RobertBergerSo why you need to ask here then?06:43
simonpe^^because their support sucks06:44
RobertBergerIf they would provide support?06:44
RobertBergerThank you!06:44
RobertBergerYou get the point06:44
RobertBergerAnd 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 hours06:44
RobertBergerThe more are complaining the more likely they will change.06:44
*** mckoan|away is now known as mckoan06:44
RobertBergerBTW it's not only NXP ;)06:44
simonpe^^according to the distributor anyway06:45
RobertBergerI mean there are worse than NXP.06:45
simonpe^^meeting now, thanks a lot for the help06:45
RobertBergerThe distros are even worse than chip manufacturers since they don't know at all ;)06:45
RobertBergerThe 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 #yocto06:49
*** agust <agust!> has joined #yocto07:10
*** yann <yann!> has joined #yocto07:13
*** kiwi_29 <kiwi_29!> has joined #yocto07:16
mcfrisksigh, dunfell bitbake hangs on parse errors.. maybe related to NXP BSP..07:17
RPmcfrisk: There is a patch on the bitbake list related to that. Not sure its right though, I'm about to run more experiments07: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!> has quit IRC07:21
mcfriskRP: thanks, will check07:27
mcfriskdo 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 annoying07:28
*** comptroller <comptroller!> has quit IRC07:29
gsalazarHi, 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 defined07:32
*** fbre <fbre!91fdde45@> has joined #yocto07:34
qschulzYatekii: 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@> has joined #yocto07:37
mckoangsalazar: we use it regularly07:39
gsalazarmckoan: I cannot seem to automate the generation of the encrypted image. If I encrypt it manually everything works fine but I cannot automate it07:42
*** stkw0 <stkw0!> has quit IRC07:43
gsalazarI mostly get that the ".enc" FSTYPE is not provided07:43
gsalazarwhen adding IMAGE_FSTYPES += ".enc" to the image recipe07:44
*** stkw0 <stkw0!> has joined #yocto07:44
qschulzCONVERSION_CMD seems to be the one handling this07:45
qschulzprobably CONVERSIONTYPES = "enc" is what you need07:46
gsalazarqschulz: Thank you for the input, I will try it07:47
qschulzyou need to inherit swupdate and swupdate-enc classes07:47
qschulzbut that's from a VERY quick read into meta-swupdate classes07:48
gsalazarI 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 approach07:51
gsalazarqschulz: 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
qschulzgsalazar: 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 giggles08: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 works currently with an imx808:00
RobertBergerWho doesn't ;)08:00
derRichardmaybe i should note that i'm not using the nxp bsp :D08:01
zandreysimonpe^^: imx8mn machine is in meta-freescale, and it is operable08:02
zandreyyou can use the instructions from RobertBerger to build NXP-free BSP. :) just replace MACHINE to imx8mnevk in his steps08:02
zandreymcfrisk, 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-freescale08:03
RobertBergerI highly doubt we loose anything ;)08:04
fbreyes, I can confirm the RobertBerger instructions tutorial works well (y)08:04
gsalazarqschulz: thanks08:04
RobertBergerWe might find a few extra bits and pieces ;_08:04
qschulzRobertBerger: we don't have meta-freescale and we have secureboot on imx8mm08:04
qschulznor meta-imx or whatever08:04
zandreyRobertBerger: 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
zandreyimx-boot is supported though08:05
qschulzRobertBerger: of course not :D08:05
RobertBerger@qschulz I thought so.08:05
derRichardHAB on the imx8 is more or less the same as on the imx608:05
RobertBergerSo maybe we should define a bit what we mean by secure boot ;)08:05
qschulzRobertBerger: all I know is that you need to take CST from their website and create a recipe out of it.08:06
qschulzor someone is kind and port imx8xx to usb-armory open-source implementation of CST08:06
*** PaowZ_ <PaowZ_!~Vince@> has quit IRC08:07
zandreyqschulz: patches and PRs to meta-freescale are welcomed! ;)08:07
RobertBergerAs far as I understand you need some CST (code signing tool) and sign u-boot and kernel with it.08:08
RobertBergerAnd I have no idea if/how/where this is integrated with Yocto08:09
fbrezandrey: 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
zandreyfbre: glad to her! this is what i actually recommended to do right from the beginning of our conversation08:10
zandreyturning away from NXP BSP makes setup more clear and you progress faster08:11
fbrezandrey: RobertBerger explained very well the backgrounds. So I had a chance to understand what it is all about08:11
qschulzRobertBerger: technically, it can't be intergated because CST needs an EULA signing when downloading the tarball..08:11
RobertBergerWell also NXP firmware needs an EULA08:11
qschulzRobertBerger: some do. the ddr training in our case IIRC08:12
qschulzsome are available in linux-firmware (they can appear later)08:12
zandreyjust to note here for the community: dunfell branch of meta-freescale has all modifications of NXP release zeus-5.4.3-1.0.0 integrated08:12
qschulznot ddr obviously, not an nxp component :)08:12
zandreythis is mainly for those who already started with NXP's meta-imx, and know only their terminology08:13
RobertBerger!qschulz I am confused - are we talking about the ddr firmware binaries?08:13
qschulzand don't forget that in order to boot from NAND, you need to flash with imx-kobs08:13
zandreythen one can really decided if he was already using zeus-5.4.3-1.0.0 - why not switch to pure dunfell?08:13
RobertBergerddr firware binaries are definitly there - otherwise it won't create the boot container and not boot08:14
zandreymaster-next has a zeus-5.4.24-2.1.0 release in pipe08:14
qschulzRobertBerger: 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 EULA08:15
RobertBergersdma firmware is also there08:15
fbrezandrey: (y)08:15
RobertBergerIf you read my instructions the last step is to agree to the NXP EULA in local.conf ;)08:15
qschulzRobertBerger: 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
RobertBergerACCEPT_FSL_EULA = "1"08:16
qschulzRobertBerger: indeed08:17
RobertBergerSame for imx608:17
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto08:17
RobertBergerAnd 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 imx6q08:18
qschulzRobertBerger: if I'm not mistaken (it's been a long time), you don't need anything EULA-requiring for imx6 anymore08:19
qschulzheck.. I would even say every upstream version of SW should work just fine08:19
RobertBergerwell this depends ;)08:19
RobertBergerYou can use etnaviv for graphics, but for video you might still need the binary blobs08:20
RobertBergerand sdma as well (but this might be without EULA)08:20
RobertBergerI use upstream on i.mx6, but no multimedia08:20
qschulzRobertBerger: video = VPU?08:22
qschulzRobertBerger: interesting :) thx for the info08:22
RobertBergerBut there might be some underground projects like etnaviv for mutimedia as well ;)08:23
derRichardRobertBerger: stress-ng has a floating point test08:25
RobertBergerI tried various other test already with floating point, but no difference08:25
derRichardwell, did the change from armv7-hf to cortex-a9-hf actually generate different code?08:26
*** yacar_ <yacar_!> has joined #yocto08:26
RobertBergerthis is scibench:
zandreyqschulz: use the 'use-mainline-bsp' in meta-freescale - and you're free from EULA08:27
RobertBergerYes different code, but performance wise?08:27
RobertBergerI don't see it08:27
RobertBergeraircrack runs faster on armv7-hf ;)
RobertBerger@zandrey - well but I don't think you will boot anymore ;)08:28
zandreyRobertBerger: those derivatives that do not require imx-boot would go just fine ;)08:30
RobertBerger@zandrey - if you comment out this line like here
RobertBergerimx-boot does not build anymore08:30
RobertBergerAh yes ;)08:30
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:30
zandreythat is what i just wrote08:30
qschulzwhy does IMAGE_BASENAME need to be exported in the image recipe?08:32
*** fbre <fbre!91fdde45@> has quit IRC08:41
*** fbre <fbre!91fdde45@> has joined #yocto08:42
RobertBerger @qschulz: just guessing here, but I think the image name needs it:
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC08:54
qschulzRobertBerger: 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
qschulzwhy 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 now08:57
RobertBergerWell variables are local, unless they are defined in configs08:57
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:01
*** chris_ber <chris_ber!~quassel@> has joined #yocto09:04
*** NiksDev <NiksDev!~NiksDev@> has quit IRC09:18
*** zandrey_ <zandrey_!~zandrey@> has joined #yocto09:23
*** feddischson <feddischson!> has quit IRC09:24
*** zandrey <zandrey!~zandrey@> has quit IRC09:26
ilkappeHello guys, there is a way to change the KERNEL_DEVICETREE= in my_machine.conf without changin it directly ?09:31
Yatekiiqschulz: 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 here09:31
Yatekiialso I believe most if not all companies use private repos. so this is a VERY common usecase09:32
Yatekiiso 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 issue09:33
qschulzYatekii: patches welcome :)09:33
simonpe^^so I'm going from NXP 5.4.3-2.0.0 to meta-freescale09: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
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 instead09:39
simonpe^^I got ok from my project manager to spend 2 days on getting it up and running with our distro09: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/ from meta-poky09:43
zandrey_simonpe^^: if you want to stay with Poky distro and do note require graphics - you can skip the meta-freescale-distro adding09:48
zandrey_just follow instructions from RobertBerger and you would get the image in no time09:48
zandrey_your planned setup should work, i also tried it and it is OK09:49
simonpe^^its already cooking ;)09:49
simonpe^^I have my own build tools that I use based on the nix package manager09:49
simonpe^^its amazing09: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 NXP09: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 EVK09:54
simonpe^^then they want me to flash another bootloader09:54
simonpe^^called i.MX 8MN DDR4 uboot09:54
simonpe^^the problem I had was that uboot complained that it couldn't find the PMIC09:55
simonpe^^and they wanted me to change the dtb file to point to imx8mn-ddr4-evk.dtb09:56
simonpe^^in uboot09:56
simonpe^^"This because DDR4 version uses different PMIC than the LPDDR4 one.09:57
RobertBerger@simonpe: imx-boot or HAB?10:00
RobertBergersimonpe: I asked on the meta-freescale git repo about it:
RobertBergerlet'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 requirement10: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 :P10:05
RobertBergerWell 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
RobertBergerBut 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
RobertBergerIf 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
JaMaanother spam seemingly from RP on openembedded-commits ML, halstead please disable this ML if it isn't going to work anymore
simonpe^^RobertBerger: ah ok, so I could just post process the yocto build with this magic tool then theoretically10:08
simonpe^^I assumed I had to build some HAB support into u-boot itself10:08
qschulzsimonpe^^: you do need it too if you want full secure boot10:09
RobertBergerThe question is how the process is.10:09
simonpe^^yeeeeeiiii, it booted10:09
*** ilkappe <ilkappe!c65a42b1@> has quit IRC10:10
RobertBergerBut this is imx610:10
simonpe^^i see, it's probably similar enough10:11
RobertBergerWell I am not sure10:11
zandrey_simonpe^^, RobertBerger: regarding the state of imx-boot - it was discusssed here: []. 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 from10:11
zandrey_HAB is  different kind of beast10:11
RobertBergerI 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 yet10:13
RobertBergerThe question is das golden NXP stuff do anything more than that with respect to HAB?10:13
RobertBergerdoes golden NXP10:13
RobertBergerWell one thing are docs, the other the implementation ;)10:13
RobertBergerWith 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 understanding10:16
simonpe^^I think we did step one of that then10: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
RobertBergerand NXP golden instead10:19
*** kpo_ <kpo_!> has quit IRC10:20
*** kpo_ <kpo_!> has joined #yocto10:27
simonpe^^it seems meta-freescale doesn't have u-boot-imx-fw-utils10:31
fbreHmmm.... I wonder why there is UBOOT_DTB_NAME = "fsl-imx8mm-evk.dtb" in sources\meta-freescale\conf\machine\imx8mmevk.conf10:31
fbreShouldn't it be without "fsl-"?10:32
zandrey_fbre: this is the U-Boot DTB name, they do differ from Kernel10:32
zandrey_2019.04 u-boot from 1.0.0 NXP release still had old names, 2020.04 changed them10:33
*** newb_dev <newb_dev!bb14930d@> has quit IRC10:35
fbrehehehe changed 11 hours ago. My git clone is slightly older10: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 release10:39
zandrey_fbre: disclaimer: it is not completed, so all bugs to fix are on you! :D10:40
fbreI did: git clone --branch dunfell git://
fbreShould I just do this?:   git pull10: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 :D10:43
fbreso just 'git pull'?10:44
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC10:44
fbreI've done 'git pull' without your ACK10:51
zandrey_fbre: unless you switch the branch - you're on the safe side. ;)10:51
fbreTo 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 operable10:53
*** kaspter <kaspter!~Instantbi@> has quit IRC10:54
fbreI used --branch dunfell for all 3 git clones at the moment10:54
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:54
*** goliath <goliath!> has joined #yocto10: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 come11:01
fbrezandrey_: And what are the branch names for future development?11:03
fbreI mean to base our future development11:03
zandrey_fbre: in meta-freescale it is master, and master-next for CI verifications of PRs11: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 one11:05
fbreok. So I rather stick to dunfell at the moment. I need it for production code11:07
zandrey_fbre: good call ;)11:07
fbrezandrey_: If it helps you, it still works after that 'git pull' :-)11:11
fbreI 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-minimal11:14
fbreThe imx8mmevk comes up with the bundled initramfs and boots properly. Yeah!!!!!11:15
fbreParty on! \O/  Thank you very much to all you guys here11:16
fbreIt says "Welcome to NXP i.MX Release Distro 5.4-zeus (dunfell)!"11:17
*** fbre <fbre!91fdde45@> has quit IRC11: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@> has joined #yocto11: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't11: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 build11:38
simonpe^^stuff like defconfig, cfg/virtio.scc etc.11:39
*** berton <berton!~berton@> has joined #yocto11:40
*** Bunio_FH <Bunio_FH!> has joined #yocto11:44
simonpe^^ERROR. input file "cfg/virtio.scc" does not exist11:45
fbresimonpe^^: Did you cleansstate and did you a new call of 'soure oe-init-build-env build'?11:47
qschulzsimonpe^^: so, no bbappend, it builds. an empty (really empty) bbappend and it does not?11:47
simonpe^^yes indeed11: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 updates11:47
simonpe^^zandrey_: is that what you'd do?11:48
zandrey_simonpe^^: this is what i try to maintain ;)11:48
qschulzsimonpe^^: 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 folder11: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-cache11:50
zandrey_one would have to maintain those files locally11:50
simonpe^^so if I bbappend I need to copy the files into my own layer?11:51
zandrey_simonpe^^: correct11:51
simonpe^^ah I see11:51
qschulzzandrey_: what? it breaks SRC_URI or what?11:51
simonpe^^hmm cfg/virtio.scc  comes from meta-virtualization11:52
zandrey_simonpe^^: details the yocto-kernel-cache usage. you would have to clone it instead and get your feature files from it11:55
zandrey_qschulz: no, what i meant is - if kernel recipe does not do require, 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_URI11:57
zandrey_then they would be picked up by kernel-yocto bbclass and processed accordingly11:57
simonpe^^well, at least theres documentation now that I ditched meta-imx11:59
qschulzzandrey_: 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
qschulzzandrey_: 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 lol12: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
RobertBergerAnyways you just want to add kernel fragments to some meta-freescale kernel recipe - let's see12: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 good12:10
RobertBergerthe 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 doing12:12
simonpe^^FILESEXTRAPATHS_prepend := "${THISDIR}:" and SRC_URI += "fragment.cfg"12:13
simonpe^^then it started complaining about not finding cfg/virtio.scc12: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 better12:14
zandrey_simonpe^^: standby for an example please...12:14
RobertBergerno require recipes-kernel/linux/linux-yocto.inc12:14
RobertBergerso one more reason I have my own kernel recipe ;)12:14
*** yann <yann!> has quit IRC12:14
zandrey_FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"12:14
zandrey_SRC_URI += "file://rndis.cfg"12:14
RobertBergerYep something like that12:15
zandrey_provided you enabled RNDIS in your config via menuconfig and saved that fragment with diffconfig12: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 feature12:16
zandrey_then place it under recipes-kernel/linux/linux-fslc-imx/mx812:16
simonpe^^this worked before with the nxp provided kernel recipe for some reason12:17
RobertBergerFor 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 in12:17
simonpe^^zandrey_: I'll remove the virtualization stuff for now to see if I can get it to build at all12:18
simonpe^^I rly don't want to maintain copies of files from other repos :/12:18
*** yann <yann!~yann@> has joined #yocto12: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-in12:20
RobertBergerI added some ikconfig.cfg12:20
RobertBergerstill baking12:20
RobertBergerAt least this should work, not sure about the scc.12:21
RobertBergerI think it worked, since it compiles - so the fragment was merged somehow.12:21
*** yangm <yangm!yanyetanot@gateway/shell/> has quit IRC12:21
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has quit IRC12:21
*** silviof <silviof!silv-iomat@gateway/shell/> has quit IRC12:21
*** nrossi <nrossi!nrossimatr@gateway/shell/> has quit IRC12:21
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has quit IRC12:21
*** GonZo2k <GonZo2k!gonzo2000m@gateway/shell/> has quit IRC12:21
*** crazoes[m] <crazoes[m]!crazoesmat@gateway/shell/> has quit IRC12:21
*** kayterina <kayterina!kayterina-@gateway/shell/> has quit IRC12:22
RobertBergerAhh I saw this virtio.scc also somewehre ;)12:22
simonpe^^mass murder^^12:22
RobertBergerNot sure what this reminds me of.12:22
*** henriknj <henriknj!hnjematrix@gateway/shell/> has quit IRC12:22
*** f0h[m] <f0h[m]!f0hmatrixo@gateway/shell/> has quit IRC12:22
simonpe^^maybe here?
fbreHappy weekend to all. See you12:22
simonpe^^fbre: happy weekend!12:23
*** fbre <fbre!91fdde45@> has quit IRC12:23
RobertBergervirtio.scc is in meta-virt and also in some linux-yocto kernel recipes ;)12:24
Yatekiiqschulz: 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
qschulzYatekii: 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 universe12: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 own12:26
simonpe^^  # machine configuration12:26
simonpe^^  "${sources.meta-freescale}"12:26
simonpe^^  # Firmware update support required by the system-x distro12:26
simonpe^^  "${sources.meta-rauc}"12:26
simonpe^^  # Container support required by the system-x distro12:26
simonpe^^  "${sources.meta-virtualization}"12:27
zandrey_RobertBerger: please inspect your work-shared/<machine>/kernel-source/.kernel-meta/cfg/merge_config_build.log12:27
RobertBergerit's from meta-virtualization12:27
Yatekiiqschulz: 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 in12:27
Yatekiigeneral works better with ssh :)12:27
*** yangm <yangm!yanyetanot@gateway/shell/> has joined #yocto12:28
qschulzYatekii: 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 remember12:28
Yatekiiqschulz: oh there is other ones than kas? I mean that's nice :) Sadly I need it now ...12:30
qschulzpyrex I think? from garmin12:32
simonpe^^I use pyrex12:32
simonpe^^its pretty neat12:32
RPhmm, the cooker logs are getting garbled :(12:32
RobertBerger@zandrey: looking good:
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 kernel12:33
simonpe^^It applied the patches but threw away the result and built with the pre-patched config12:33
RobertBergerIt worked out of the box, just included a .cfg12:33
simonpe^^RobertBerger: haha I think I know why you have vague memories of this virtio stuff:
RobertBergerah yes that as well ;)12:37
Yatekiiqschulz 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 transparent12:40
simonpe^^I hate having to live inside of a container without my vim configs etc12:40
*** shan1 <shan1!> has joined #yocto12:40
Yatekiisimonpe^^: 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 anymore12:41
shan1Guys quick question what is recipe name for the python package `cv2` I cannot find any recipe named `python3-opencv` or something similar?12:41
RobertBergersimonpe: 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 that12:41
*** shan1 <shan1!> has left #yocto12:41
*** shan1 <shan1!> has joined #yocto12:41
simonpe^^I just want my god damn environment that I've been polishing for the past 20 years lol12:42
RobertBergerand 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/cgroup12:43
simonpe^^you CAN use it as a VM but if reproducible environments is what I'm after I'd rather use nix12:44
simonpe^^but yocto and nix doesn't play well yet so...12:44
RobertBerger@simonpe don't get me started ;)12:45
simonpe^^its good with diversity in thought, echo chambers are boring ;)12:45
RobertBergerYou can build your container images with Yocto ;)12:46
*** zandrey_ <zandrey_!~zandrey@> has quit IRC12:46
RobertBergerI am running some tests from the phoronic testsuite built with yocto natively as well as in a container.12:47
RobertBergerNow I would not call this a single binary ;) It contains a whole SDK ;)12:47
RobertBergersince phoronix wants to download sources and to build them before running the benchmark12:47
*** crazoes[m] <crazoes[m]!crazoesmat@gateway/shell/> has joined #yocto12:48
*** kayterina <kayterina!kayterina-@gateway/shell/> has joined #yocto12:48
*** henriknj <henriknj!hnjematrix@gateway/shell/> has joined #yocto12:48
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has joined #yocto12:48
*** nrossi <nrossi!nrossimatr@gateway/shell/> has joined #yocto12:48
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has joined #yocto12:48
*** GonZo2k <GonZo2k!gonzo2000m@gateway/shell/> has joined #yocto12:48
*** wak-work <wak-work!wak-workma@gateway/shell/> has joined #yocto12:48
*** bachp <bachp!bachpmatri@gateway/shell/> has joined #yocto12:48
*** silviof <silviof!silv-iomat@gateway/shell/> has joined #yocto12:48
*** f0h[m] <f0h[m]!f0hmatrixo@gateway/shell/> has joined #yocto12:48
*** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/> has joined #yocto12:48
simonpe^^RobertBerger: yes I know, people do that everywhere and I just disagree with containers being the right tool for that job12:48
RobertBergerThe next thing to look into are kubernetes - k8s and k3s12:49
simonpe^^so I can build the kernel if I disable KERNEL_FEATURES_append = " virtualization"12:49
RobertBergerAnd otherwise it does not build because it does not find the file?12:50
simonpe^^RobertBerger: I use k8s for cloud stuff, its pretty neat12:50
RobertBergerI have a fix for this ;)12:50
simonpe^^is it the thing in your bug report?12:50
RobertBergeri want mixed x86pc/arm ...12:50
simonpe^^SRC_URI += "file://features/cfg/virtio.scc"?12:50
RobertBergerYes it's hidden somwhere in the bug report.12:50
simonpe^^Did you try the dockerx stuff to run containers with qemu?12:51
RobertBergerDo thanks12:51
RobertBergerI build my containers with yocto ;) - at least those I want for my embedded stuff.12:51
RobertBergerNo thanks ;)12:52
RobertBergerI looked into it, but don't get the point. Why would I want to run containers with qemu?12:52
RobertBergerTo slow them down?12:52
simonpe^^To run aarch64 on x8612:52
RobertBergerWhy would you want to do that?12:53
simonpe^^to run integration tests without hardware12:53
RobertBergerYou use the Yocto project right?12:53
RobertBergercross - compilation ;)12:53
RobertBergerSo you would build some random image for aarch64 based on, say debian for your yocto integration test?12:54
RobertBergerEither 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 anyway12:55
RobertBergerI can run basically the same "image" on native arm32 and in a container on arm32. aarch64 hopefully also soon.12:56
RobertBergerWell rootfs minus kernel in container12:57
RobertBergerThe 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!> has quit IRC12:58
simonpe^^RobertBerger: it is, it's just different namespaces and cgrouped12:58
RobertBergerit's just cgroups/namespaces - kernel stuff12:58
RobertBergerI made a little experiment today.12:58
RobertBergerimx6q with a soft floating point rootfs and docker.12:59
RobertBergerIn the docker container hard floating point.12:59
RobertBergerWorks nicely12:59
simonpe^^I actually use podman instead of docker on the embedded machines13:00
RobertBergerI prefer docker, but it does not really matter.13:00
RobertBergerIt's oci containers so they should work with podman as well.13:00
RobertBergerEventually with kubernetes all this will go away I hope.13:01
RobertBergerAnyways I am getting hungry - see you later13:01
derRichardwhen 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
derRichardunsetting these vars makes menuconfig work13:04
*** thierryE <thierryE!sid286446@gateway/web/> has quit IRC13:32
*** thierryE <thierryE!sid286446@gateway/web/> has joined #yocto13:33
JPEWRP: As an exercise, I converted the cooker to use a python multiprocess pool:
JPEWIt lead to some interesting insights that I think explain some of the problems we've been seeing13:38
RobertBerger@derRichard: What SDK is this? Classic or extensible?13:41
RobertBerger@derRichard: This always worked for me so far.13:41
RobertBergerdunfell or master?13:42
*** Sandrita <Sandrita!b8a36cf4@gateway/web/cgi-irc/> has joined #yocto13:42
RobertBergerWhen zeus was up to date this definitely worked as well ;)13:42
RobertBergerThat's the way I play with kernels.13:43
RobertBergerSo you installed the SDK, ran the environment script and need to do stuff to run menuconfig?13:43
RobertBergerAre you sure you ran this on a fresh shell - not one where you did a build before?13:44
derRichardfresh shell13:44
derRichardas you see i'm on suse and the library PKG_CONFIG_SYSROOT_DIR points to is plain wrong13:45
derRichardthis is the bug13:45
derRichardmaybe it worked by chance on your host because you build the sdk on the same distro as you used it later..13:45
RobertBergerYep - no idea where this comes from.13:45
derRichardmy sdk is build on ubuntu and runs $anywhere13:45
RobertBergerI use a build container to build it13:46
derRichardsame here13:46
derRichardthe container runs ubuntu13:46
RobertBergerAnd menuconfig without the SDK environment works?13:46
RobertBergerare those libs installed on your host? sudo apt-get -y install libncursesw5-dev flex bison libssl-dev ncurses-dev13:47
RobertBergerLet me see on my current setup where PKG_CONFIG_SYSROOT_DIR point to ;)13:48
derRichardsure works menuconfig without the sdk13:48
derRichardthis is my workstation where i work all day with kernels13:49
derRichardand no, no apt-get there. i run suse13:49
*** Bunio_FH <Bunio_FH!> has quit IRC13:49
RobertBergerlooking good to me ;) export | grep PKG_CONFIG_SYSROOT_DIR13:50
RobertBergerdeclare -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
RobertBergeryou also didn't mv you installed sdk ;)13:51
derRichardof course not13:51
*** sakoman <sakoman!> has joined #yocto13:51
RobertBergerit's a bug not a feature I would say ;)13:51
* derRichard agrees13:51
*** Bunio_FH <Bunio_FH!> has joined #yocto13:51
derRichardnow i just need someone to blame ;-)13:51
RobertBergerWell which version you said?13:52
RobertBerger"Bring out the dead. I am not dead I feel fine"13:52
RPJPEW: what are those insights?13:53
RobertBergerzeus - 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
derRichardRobertBerger: zeus is not that old :P13:53
RobertBergerIt will be soon EOL13:54
derRichardthe vast majority of my customers are on sumo or worse13:54
RPJPEW: I've been able to partly explain why we see hangs with cancel_thread_join()13:54
derRichardzeus is "new hot shite" for them ;)13:54
RobertBergerdid you ever see this page?
derRichardof course13:54
derRichardbut you are in embedded too and should know how much customers like upgrades...13:55
RobertBergerso you know ;)13:55
RobertBergerSure they can pay me for maintaining their old crap as well ;)13:55
RobertBergerI don't like it, but money talks.13:55
* derRichard fixed lately an issue in 2.6.18 for a unnamed customer :P13:56
RobertBergerzeus it actually not that old ;)13:56
RobertBergerhehe - insert coin13:56
derRichard*linux 2.6.1813:56
derRichardthe upgrade from 3.10-nxp to 4.12 took more or less a full man year....13:57
RobertBergerYou 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
RobertBergerThat'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 #yocto13:59
RobertBergerIs it useful/long term forward thinking/helping anyone else but you having a lenghtly miserable job - not sure13:59
derRichardi get enough coins, no worries.13:59
RobertBergerThen it's OK13:59
JPEWRP: 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 properly13:59
JPEWRP: 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
RPJPEW: we're using threads in the cache code?14:00
*** goliath <goliath!> has quit IRC14:01
derRichardRobertBerger: well, i like my job and never have pain. most of the time i *cause* pain because i keep asking questions ;)14:01
JPEWRP: 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
RPJPEW: I don't think so, I think hashserve and prserv are separate processes and there shouldn't be much else14:02
RPJPEW: I know threading and multiprocess do not mix well so we try and only use mp here14:03
RobertBergerI found some 3.0.1 SDK lurking around here ;)14:03
qschulzI'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
RPJPEW: I did file
RobertBergerhehe - 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-linux14:04
derRichardDistro Version: 1.4.314:04
RobertBerger@qschulz: totally different things14:04
derRichardanymore questions? ;-)14:04
JPEWRP: 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
kergothRP, 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
RobertBergerand also i586 and not x86_64 ;)14:05
*** PaowZ_ <PaowZ_!~Vince@> has joined #yocto14:05
kergoththat is ,we need to watch for use of threads by the modules we use, not just direct14:05
*** yann <yann!~yann@> has quit IRC14:05
* kergoth yawns14:05
JPEWAnyway, 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 efficient14:05
*** yann <yann!~yann@> has joined #yocto14:06
qschulzRobertBerger: 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 SDK14:06
RPJPEW, kergoth: I think we do use threads *after* we shut down the multiprocessing pool14:06
qschulzRobertBerger: no eSDK nor SDK for me :shrug:14:07
RPkergoth: I'm fairly sure you're right that queue.Queue uses threads and yes, we should double check14:07
RobertBergerI am just answering your question ;)14:07
RPJPEW: I have logging from some of the overnight bitbake server issues and it makes depressing reading14:07
kergothyeah, 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? hmm14:08
RobertBergerreal Bitbake hackers use vim and not devtool !14:08
RPSome many things are screwed up but I can't tell the root cause14:08
RobertBergerAnd yes accidentally you can also use it when you are in cooker mode.14:08
* kergoth shrugs, worth a check, now for coffee, wanders off14:08
RPkergoth: It may explain some of the memres bugs but things are still running in one shot mode. I guess unless something gets the timing right14:08
RobertBergertry: bitbake busybox -c devshell14:08
JPEWRP: 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+C14:09
RobertBergerThis brings you in a shell with the code already there and cross tools setup14:09
JPEWWhich I resolved with the signal handler (call os._exit(1) on signals instead of trying to cleanup)14:09
RobertBergerI use it sometimes to debug things when build break. But if you make changes there, they are gone with the next bitbake.14:10
RobertBergerSo if e.g. you make a patch you need to save it somewhere not to be overwitten by the next bitbake run.14:10
RobertBergerAnways try it out.14:10
qschulzdevtool modify?14:10
derRichardhmm. "devtool modify virtual/kernel" works but "devtool update-recipe virtual/kernel" not. for update-recipe it wants the real name :(14:10
qschulzthe use case you're suggesting is the same as devtool modify14:11
RobertBergerdevtool is something which can even, if the weather is good create recipes for you ;)14:11
JPEWRP, 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 terminated14:11
RobertBergerAs I said 2 totally different things.14:11
RobertBergerdevshell more likely for debugging things14:11
RPJPEW: that is interesting to know. Does that improve if you get rid of cooker's SIGTERM/SIGHUP handler?14:12
JPEWI can try that14:12
RPJPEW: I think this hanging issue is why we didn't use the pool14:12
RobertBergerdevtool to create recipes, modify, upload to target,... more a developer tool.14:12
qschulzRobertBerger: I've only ever used devtool for debugging recipes/sw from Yocto, hence the question14:12
RobertBergerHow you debug recipes with devtool ?14:12
RobertBergerI usually debug recipes produced by devtool ;)14:12
qschulznah not recipes actually, don't know why I put that there, sw from Yocot is what I wanted to say14:13
RobertBergerSo I have a recipe which does not work, how would you debug it with devtool?14:13
JPEWRP: Right, but I'm not sure if the workers should even be doing a graceful cleanup on SIGTERM (pool or not)14:14
qschulzRobertBerger: depends... if it's just a compilation issue, devtool for patching the source code14:14
RPJPEW: you mean parsers right?14:14
qschulzRobertBerger: if recipe, I apply my best Yocto-fu knowledge and use vim :)14:14
RobertBergerI see. So we have a different opinion about what debugging means ;)14:15
RPJPEW: we do need to be robust against people hitting Ctrl+C while bitbake is running14:15
RPJPEW: this is where many of our changes and fixes in this code started from14:15
RobertBergerSo you see devtool is more for the developer who uses an eSDK and wants to do some things with Yocto although no Yocto-fu14:15
RobertBergerActually if you are lucky it indeed can generate from a git repo out there in the wild a working recipe.14:16
qschulzRobertBerger: I know devtool :D devshell, I don't :)14:17
RobertBergerSo run devshell14:17
JPEWRP: Ya, if I remove the cookers signal handler the workers exit on CTRL+C without installing their own signal handler14:17
RobertBergerbitbake busybox -c devshell14:17
JPEW... which makes sense looking at the cookers handler :)14:17
RPJPEW: right, cooker's handler is horrible from a forked off process perspective14:18
JPEWWhat does "robust against CTRL+C" mean?14:18
RPJPEW: when the user hits Ctrl+C, bitbake exits "nicely"14:18
RPno trashed cache files, doesn't hang, spew tracebacks14:19
RPsome of this code dates to when the UI wasn't a separate process14:20
JPEWRP: Ok, doing `signal.signal(signal.SIGTERM, signal.SIG_DFL)` in the worker init makes it behave properly when the cooker is handling SIGTERM14:23
RobertBergernot a lot, but at least a little bit ;)14:24
RPJPEW: ok, that helps. I wonder what multiprocessing relies on that uses SIGTERM14:25
JPEWpool.terminate() sends SIGTERM to all the workers14:25
qschulzRobertBerger: 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
RPJPEW: ok, that would definitely break :)14:26
RobertBergerThe use case for me is what you mentioned for the devtool.14:26
RobertBergerA compilation breaks14:26
RobertBergerAnd i want to manually redo the steps14:26
RobertBergerIt places you in $S with the cross compiler operational14:27
RobertBergersimilar, but not the same as if you would use an SDK to build stuff14:28
qschulzRobertBerger: are you executing run.do_task then or really doing step by step?14:28
RobertBergerYep something like that.14:29
qschulzRobertBerger: (e)SDK is completely foreign to me still :/ so can't relate unfortunately14:29
RobertBergerI would e.g. on autotool project configure/make and so on14:29
RobertBergerImagine a world without Yocto - I know it's hard.14:29
qschulzRobertBerger: /join #buildroot14:29
RobertBergerAnd without buildroot.14:30
RobertBergerYou are just a "normal" developer and someone gives you something called SDK.14:30
qschulzRobertBerger: 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
RobertBergerA cross toolchain with a so called sysroot ;)14:30
RobertBergerYou are not blessed - you missed lots of fun!14:31
qschulzfun I don't know, but knowledge, for sure14:31
RobertBergerI remember building with a team our own Linux distro including the toolchain.14:31
RobertBergerYou can't imagine how much you learn along the way ;)14:31
qschulzyeah.. Kids got it too easy today don't they :D14:32
RobertBergerroughly one year later developers could take the pre release alpha version and develop their stuff.14:32
RobertBergerOf course - they were never in any war. Neither the first nor the second ;)14:33
RPJPEW: I'm tempted to merge your cleanup...14:34
RPJPEW: I think there are other issues too though :(14:34
JPEWRP: Ya, I actually think it could be a lot better... I have a few cleanups14:35
JPEWLike what?14:35
RobertBerger@qschulz but you still can try Linux from Scratch today ;)14:35
RPJPEW: we're still seeing leftover threads when we exit and I don't think they're from the parsing code14:40
qschulzRobertBerger: one day... one day :D14:40
RPJPEW: I think my patch removes the problems we had there but there is still some set of other issues somewhere14:40
JPEWIs there a bug entry for the threads? I don't remember that one14:41
*** ericch <ericch!> has joined #yocto14:42
*** shan1 <shan1!> has joined #yocto14:43
JPEWRP: Sorry, I'm trying to switch between too many context :) Were the leftover threads related to the cancel_join_thread() ?14:44
shan1hi all any reference layer or recipe to cross-compile golang code from x86 to armv7?14:44
RPJPEW: I simply don't know :(14:44
RPJPEW: I've just sent four patches which try and beat the logging in server/ into some kind of shape to be semi usable14: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
RPJPEW: you'll hate the serverlog() one but its a workaround for now14:45
JPEWRP: Heh, I added pretty much the same function in my patch :)14:46
*** feddischson <feddischson!> has joined #yocto14:47
qschulzRobertBerger: /me notes "do not reproduce before you have built Linux from scratch"14:47
RobertBergerhehe ;)14:49
RobertBergerNow I know where I saw this the last time "WARNING: /workdir/sources/poky/../meta-freescale/recipes-kernel/linux/ Unable to get checksum for linux-imx-mfgtool SRC_URI entry virtio.scc: file could not be found14:50
RobertBergerBut my kernel recipe does not care about it and keeps on going ;)14:51
*** shan1 <shan1!> has quit IRC14:54
RPJPEW: sent a couple more tweaks for cooker which may aid debugging14:55
RPJPEW: heh, yes, I didn't spot that!14:56
RPJPEW: I guess I should wait until after maint on the autobuilder, then run -next and see how things look with that14:57
JPEWRP: Why does every worker process dump parser and fetcher cache?15:04
JaMaRobertBerger: meta-virtualization adds that and e.g. rpi doesn't have it as well15:05
JPEWRP: Ah, looks like it's for debugging, since it's per PID?15:09
RobertBerger@JaMa I know ;)15:09
*** kaspter <kaspter!~Instantbi@> has quit IRC15:10
JPEWOh, 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 enabled15:10
RobertBergerWARNING not ERROR15:11
RobertBergerI will have a look at it as well when I feel like massaging my raspi 4 64 bit15:11
JaMalooks like my error was slightly different, because it was missing feature, for you it's just missing in SRC_URI15:11
*** goliath <goliath!> has joined #yocto15:12
RobertBergerI have my own kernel recipe15:12
RobertBergerAnyways it can be added as well ;)15:12
RobertBergerIt 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/> has left #yocto15:32
*** kiwi_29 <kiwi_29!> has joined #yocto15:40
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:43
*** beneth <beneth!> has left #yocto15:44
*** beneth <beneth!> has joined #yocto15:45
*** nslu2-log <nslu2-log!> has joined #yocto15:48
*** yacar_ <yacar_!> has quit IRC15:53
*** chris_ber <chris_ber!~quassel@> has quit IRC16:09
*** abhiarora44 <abhiarora44!uid396576@gateway/web/> has joined #yocto16:18
*** leon-anavi <leon-anavi!~Leon@> has quit IRC16:23
*** Hadi <Hadi!> has joined #yocto16:29
*** bachp <bachp!bachpmatri@gateway/shell/> has quit IRC16:31
HadiI 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
HadiSo I need to rebuild the framework recipes every time with each of the application recipes.16:33
qschulzHadi: in framework recipe: DEPENDS = "application-recipe"16:35
Hadiapplication recipe does a DEPEND to framework recipe16:35
HadiBut app1, app2 app2 has different configuration for the framework recipe16:36
HadiSo framework recipes needs to be rebuild every time for each of the application  recipes16:37
HadiWe are using the famework recipes a tool that needs to compiled for every application recipes16:38
HadiYocto only build a recipe once.  That means the framework recipes are  build only once.16:40
HadiI am looking for a instance of a group of framework recipes for my application recipe.   Hope I am able to explain this16:41
*** mckoan is now known as mckoan|away16:42
mattsmHadi: can you describe the framework recipe in more detail?16:49
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:49
HadiOur 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 wants17:01
Hadito build with header_1.h .  App2 want to build and with header_2.h17:01
*** vineela <vineela!~vtummala@> has joined #yocto17:03
HadiIn other word, application recipes are trying to use a tool library(framework recipes)  that needs to build every time.  Thus the complication17:05
HadiDoes it make sense?17:06
erboHadi: 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
erboerr, "your design"17:23
RPJPEW: you mean the codeparser cache?17:26
khemRP: I have sent a v2 for go patch, happy that in v2 I dropped the musl patch along with fix17:29
HadiThe 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 gcc17:33
Haditool prior to using it in every application recipe.17:33
RPkhem: just queued it, thanks17:34
erboHadi: 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!> has quit IRC17:37
erboIf 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 that17:37
HadiThat is one option, But we got ~100 applications .  It will be hard to maintain multiple instance of framework recipes. I was considering BBclassextend17:40
*** JaMa <JaMa!> has quit IRC17:41
RPHadi: BBCLASSEXTEND could work well for that FWIW17:42
RPHadi: or just fetch the framework and the application in the same SRC_URI together17:43
HadiIf 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 receipes17:43
HadiRP: Thanks. I tried that.17:44
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC17:44
JPEWRP: Ya17:44
RPJPEW: coreparser is generated per process but we need to combine it all together and save it as one cache17:44
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto17:45
JPEWRP: Ya, I see thats what the code is doing now :)17:45
RPwe can do that "out of band" of the ongoing other bitbake things17:45
Hadi I need to manage the build of all framework git repositories inside a single application recipe17:45
HadiRP: what is FWIW17:46
RPHadi: For what its worth17:47
HadiI was searching for yocto class17:47
RPHadi: 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 case17:47
* RP also needs to head afk, its turned into an insane day :(17:48
HadiThanks RP17:48
khembreak the dependency by creating framework-headers recipe or some such17:49
khemI guess header is app specific is it ?17:50
khemI would take a harder look at your SW architecture17:50
khemand perhaps build issue is only showing the symptom of larger problem17:51
Hadiin the framework recipe i would have BBCLASSEXTEN="app1, app2 app3" .  In the application recipe( I would use DEPEDS="frame1-app1"  in app2 recipe I would have DEPENDS="frame1-app2"17:51
RobertBergerMaybe 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?
RobertBergerWhat's happening here is that I would like to use some binaries which come form another recipe ;)17:53
RobertBergerIn my recipe.17:53
RobertBergerAnd it does not quit work. Once I manually build the dependency all is good, but it's not triggered automatically.17:54
RobertBergerThat's the other recipe this depends on:
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has quit IRC18:05
*** Konsgnx <Konsgnx!> has joined #yocto18:20
*** rcoote <rcoote!~rcoote@> has joined #yocto18:32
*** nslu2-log_ <nslu2-log_!> has joined #yocto18:42
*** nslu2-log <nslu2-log!> has quit IRC18:45
*** nslu2-log_ is now known as nslu2-log18:45
*** thaytan <thaytan!> has quit IRC18:54
*** thaytan <thaytan!> has joined #yocto18:59
*** abhiarora44 <abhiarora44!uid396576@gateway/web/> has quit IRC19:06
*** beneth <beneth!> has left #yocto19:23
*** vineela <vineela!~vtummala@> has quit IRC19:37
*** berton <berton!~berton@> has quit IRC19:48
*** kiwi_29 <kiwi_29!> has quit IRC19:55
*** JaMa <JaMa!> has joined #yocto20:01
RobertBergerSo 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@> has joined #yocto20:11
*** kiwi_29 <kiwi_29!> has joined #yocto20:17
*** Hadi <Hadi!> has left #yocto20:22
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto20:38
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC20:39
*** aidanh_ is now known as aidanh20:39
*** feddischson <feddischson!> has quit IRC20:41
*** pohly <pohly!> has quit IRC20:47
*** zandrey <zandrey!> has joined #yocto20:53
khemyes in such cases you can set specific task level dependency on another task from different recipe20:58
kergothRobertBerger: 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.bbclass21:01
*** Konsgnx <Konsgnx!> has quit IRC21:05
bantuHi. Does INCOMPATIBLE_LICENSE apply to build time dependencies as well as runtime dependencies?21:06
zandreyRP, 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/> has quit IRC21:12
*** sno <sno!> has quit IRC21:17
*** sno <sno!> has joined #yocto21:20
*** nslu2-log_ <nslu2-log_!> has joined #yocto21:47
*** nslu2-log <nslu2-log!> has quit IRC21:49
*** nslu2-log_ is now known as nslu2-log21:49
*** stacktrust <stacktrust!> has quit IRC22:10
*** kpo_ <kpo_!> has quit IRC22:16
*** havok101 <havok101!~havok101@2601:241:8a00:46e0:3512:b88a:7c9e:abfa> has quit IRC22:17
*** kpo_ <kpo_!> has joined #yocto22:18
RPzandrey: I really don't see the issue with allarch -dev packages22:25
RPzandrey: 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 not22:25
RPI can imagine an allarch recipe which did install dev only stuff like a -config script too22:26
*** dev1990 <dev1990!> has quit IRC22:27
JaMaanyone seeing random harfbuzz build failures with dunfell? harfbuzz-2.7.2/src/ error: no previous declaration for 'void hb_version(unsigned int*, unsigned int*, unsigned int*)'22:58
RPJaMa: we've started seeing them in master :/22:59
RPJaMa: 14038 1403623:00
RPbugs #14028 and #1403623:00
JaMaah Ross is on it already it seems
JaMaand my failed build I was just looking at was also based on master, not dunfell, will check if dunfell is also affected23:04
RPJaMa: cool, I know rburton said he'd take a look23:07
*** rcw <rcw!~rcw@> has quit IRC23:09
*** Sara <Sara!3cf32003@> has joined #yocto23:23
SaraDear 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 guide23:25
*** agust <agust!> has quit IRC23:27
SaraSHould i start with OpenEmbedded or with Yocto?23:27
RPSara: OE is the build environment used by the Yocto Project so its all related23:29
RPSara: 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 pi23:30
RPonce you have the basics, then start on the QT application23:30
SaraRP thanks for the note, so poky is the sample project that can be used to build the image23:31
SaraRP thanks for the note, so poky is the sample project that can be used to build the image ?23:31
SaraWhich 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
SaraI have been trying to get this working, but this has been failing many times (last 7 times )23:33
RPSara: did you try the Quick build document?23:38
RPSara: 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 QT23:39
*** Sara <Sara!3cf32003@> has quit IRC23:43

Generated by 2.17.2 by Marius Gedminas - find it at!