| *** Tokamak <Tokamak!~Tokamak@107.117.203.209> has quit IRC (Ping timeout: 240 seconds) | 00:02 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.209> has joined #yocto | 00:04 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 00:07 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 00:07 | |
| *** camus1 is now known as camus | 00:07 | |
| *** Guest26 <Guest26!~Guest26@64.222.164.134> has quit IRC (Quit: Client closed) | 00:10 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 00:13 | |
| override | hey, I'm trying to make sense of a build dependcy that reads like virtual/dtb | 00:28 |
|---|---|---|
| override | what might that mean? arent build dependencies suppose to me recipes (DEPENDS +=) | 00:28 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 00:58 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Client Quit) | 00:59 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 01:25 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 02:01 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 02:48 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 03:00 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 245 seconds) | 03:01 | |
| *** camus1 is now known as camus | 03:01 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 03:16 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 03:17 | |
| *** camus1 is now known as camus | 03:17 | |
| zeddii | JaMa: I was out for the evening here. ping me again on friday. I'll poke and see if a problem shows in my local builds. | 03:24 |
| *** amitk <amitk!~amit@103.208.69.73> has joined #yocto | 03:49 | |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 245 seconds) | 04:21 | |
| *** override <override!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 250 seconds) | 04:22 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Ping timeout: 255 seconds) | 04:26 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 04:30 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 04:52 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 04:52 | |
| *** camus1 is now known as camus | 04:55 | |
| *** Vonter <Vonter!~Vonter@2406:7400:73:8f06:ba27:ebff:fe40:73d2> has quit IRC (Ping timeout: 255 seconds) | 04:59 | |
| *** Guest9 <Guest9!~Guest9@2402:e280:2117:297:bcc8:41f:8b96:eaea> has joined #yocto | 05:12 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 05:14 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.209> has quit IRC (Ping timeout: 252 seconds) | 05:29 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Ping timeout: 252 seconds) | 05:52 | |
| *** wing0 <wing0!~wing0@177.76.163.14> has joined #yocto | 05:54 | |
| *** wing0 <wing0!~wing0@177.76.163.14> has quit IRC (Quit: WeeChat 3.1) | 06:17 | |
| *** Guest9 <Guest9!~Guest9@2402:e280:2117:297:bcc8:41f:8b96:eaea> has quit IRC (Quit: Client closed) | 06:23 | |
| *** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer) | 06:40 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 06:40 | |
| *** sbach <sbach!~sbach@user/sbach> has joined #yocto | 06:40 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 07:01 | |
| LetoThe2nd | yo dudX | 07:03 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 07:08 | |
| *** mckoan|away is now known as mckoan | 07:09 | |
| mckoan | good morning | 07:09 |
| *** argonautx <argonautx!~argonautx@i59F77F5C.versanet.de> has joined #yocto | 07:25 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 07:28 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 07:28 | |
| wyre | hi everyone, according this manual https://www.engicam.com/get_attachment.html/rem/custom/files/114421/ct10000_id101223_t100003/GEAM6ULSW_manual_Yocto_2.0.5.pdf (pages 9 and 10) when I set UBOOT_CONFIG="nand" I should have an image with extension .ubifs but I can't see this in the images folder https://bpa.st/VZIA | 07:38 |
| wyre | I just can see the usual .wic.gz | 07:38 |
| wyre | could I use this also to flash in the nand? | 07:39 |
| LetoThe2nd | wyre: you're totally reading things into that document that are not there. | 07:40 |
| wyre | what do you mean? things that aren't currently in that way? | 07:41 |
| LetoThe2nd | wyre: the config you stated does not affect the generated image type, it just configures uboot for a certain boot strategy. and one paragraph um, there is a link to a section that should tell you how to flash to nand. | 07:41 |
| LetoThe2nd | wyre: "when I set UBOOT_CONFIG="nand" I should have an image with extension .ubifs" is what you wrote. and thats just not written there, AFAICS | 07:42 |
| wyre | oh, sure, that's right, I was just doing the assumption | 07:43 |
| wyre | but then I'm not sure what have I to do to generate that .ubifs file 🤔 | 07:43 |
| LetoThe2nd | wyre: probably set a different IMAGE_FSTYPE+ | 07:44 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 268 seconds) | 07:53 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 07:53 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 07:55 | |
| wyre | hmm... I've set IMAGE_FSTYPES += "ubifs" in conf/local.conf but it cannot produce the ubifs file because I'm having "Error: min. I/O unit was not specified (use -h for help)" should I do something more? | 07:58 |
| LetoThe2nd | yep, you should read up on how ubifs works, and what you actually need to configure in order to use it for your specific board. if you don't know or are missing relevant information, please consult engicam. | 08:01 |
| wyre | yep, the point is that I can't see anything about ubifs in the manual I linked 😞 | 08:03 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:03 | |
| qschulz | you need some ubinize parameters specific to the NAND chip you | 08:04 |
| qschulz | re using | 08:04 |
| wyre | qschulz, ubinize parameters? 🤔 | 08:04 |
| qschulz | ubifs image type requires MKUBIFS_ARGS | 08:05 |
| qschulz | http://www.linux-mtd.infradead.org/faq/ubifs.html | 08:06 |
| qschulz | https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types.bbclass#n202 | 08:07 |
| qschulz | this is for ubifs | 08:07 |
| qschulz | you need arguments specific to your NAND IIRC | 08:07 |
| qschulz | and if you want to create a ubi image, you need ubinize parameters too | 08:07 |
| *** mc__ <mc__!~mccc@c-73-239-24-228.hsd1.wa.comcast.net> has joined #yocto | 08:18 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 08:18 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 08:19 | |
| *** mcc_ <mcc_!~mccc@c-73-239-24-228.hsd1.wa.comcast.net> has quit IRC (Ping timeout: 265 seconds) | 08:21 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 08:22 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 08:23 | |
| *** camus1 is now known as camus | 08:23 | |
| *** hpsy <hpsy!~hpsy@85.203.15.24> has joined #yocto | 08:29 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:35 | |
| wyre | qschulz, I don't get the point of ubinize parameters, is not enough by setting the MKUBIFS_ARGS? | 08:37 |
| qschulz | ubinize and kmfs.ubifs are different tools, therefore different purposes and different parameters | 08:44 |
| qschulz | it's all explained in the first link I sent | 08:44 |
| mcfrisk | hi, is anyone else seeing negative build performance from hashequiv? In our case a full build without sstate cache or mirrors takes 4½ hours but a large dunfell update with sstate mirror and local cache and hashequiv takes 6½ to 7 hours. Difference seems to be the delayed tasks and hash checks | 08:59 |
| *** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto | 10:00 | |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has joined #yocto | 10:06 | |
| *** hpsy <hpsy!~hpsy@85.203.15.24> has quit IRC (Quit: Leaving.) | 10:20 | |
| *** hpsy <hpsy!~hpsy@85.203.15.24> has joined #yocto | 10:20 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 10:23 | |
| *** jmiehe1 <jmiehe1!~Thunderbi@user/jmiehe> has joined #yocto | 10:28 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 268 seconds) | 10:29 | |
| *** jmiehe1 is now known as jmiehe | 10:29 | |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has quit IRC (Remote host closed the connection) | 10:29 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 10:32 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 10:33 | |
| *** camus1 is now known as camus | 10:33 | |
| JaMa | zeddii: ping for friday :) I can send a fix for that do_patch, I'm just wondering what might trigger it just now (possibly by suddenly including it in "bitbake world") | 10:58 |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has quit IRC (Ping timeout: 240 seconds) | 11:00 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Quit: Leaving) | 11:04 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 11:17 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 11:57 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 11:59 | |
| *** camus1 is now known as camus | 11:59 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has joined #yocto | 12:14 | |
| *** override <override!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has joined #yocto | 12:17 | |
| override | hey, lets say I have two machine.conf files with the same name under different meta layers, how can I specify whcih one to use in local.conf can I give explict path for MACHINE ?= "" in local.conf? | 12:19 |
| override | I'm sure MACHINE ?="" cant take exlicit paths | 12:19 |
| override | so what might be a solution here? | 12:19 |
| qschulz | override: don't have two machines with the same name | 12:20 |
| override | qschulz: got some scripts using the MACHINE variable which would break if I changed the name | 12:21 |
| qschulz | The order in which your layers appear in bblayers.conf will be the order in which your conflicting bbclasses and conf files will be "resolved" (first found is first taken) | 12:21 |
| override | and I dont have control over some of the meta-layers | 12:21 |
| qschulz | (well, technically it's because of BBPATH variable default "value" in conf/layer.conf that makes it rely on order in bbalyers.conf) | 12:22 |
| override | oh, so I can just maybe use the order in bblayers.conf. thanks | 12:22 |
| qschulz | override: which is a terrible idea | 12:22 |
| qschulz | you should never rely on layer order for something to work | 12:22 |
| JaMa | not sure, but maybe BBMASK would work as well | 12:22 |
| rburton | override: virtual/foo are virtual recipe names, multiple recipes may PROVIDE that name and your machine/distro/soemthing uses PREFERRED_PROVIDER to pick one | 12:22 |
| qschulz | JaMa: that's an option for bb/bbappends but I'm not sure this works with conf files? | 12:22 |
| qschulz | JaMa: but I'm curious now :) | 12:23 |
| JaMa | doesn't seem to work | 12:24 |
| override | rburton: are u saying I can possibly use the PREFERRED_PROVIDER name to let local.conf select what layer to get the machine.conf from? | 12:25 |
| rburton | no | 12:25 |
| rburton | you were asking about virtual/dtb earlier | 12:25 |
| override | oh, ok I figured. thanks | 12:25 |
| override | I got over those troubles somehow last night | 12:25 |
| override | now im hitting this same machine different meta-layers crap | 12:26 |
| qschulz | override: also, depending how MACHINE is used, you could use overrides instead and set MACHINEOVERRIDES correctly in your machine configuration file | 12:26 |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 12:26 | |
| override | ill lookup MACHONEOVERRIDES and overrides quick, unless someone just wants to beat me to it and explain | 12:29 |
| override | ive used MACHINE)VERRIDES =. "user-head-next" before , cant remeber what that was doing tho | 12:30 |
| qschulz | https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html | 12:31 |
| JaMa | RP: would it make sense to extend BBMASK (or some new variable) to filter BBPATH as well (I don't want to give any bad ideas, but evil BSP with nasty package.bbclass would be difficult to work with) | 12:31 |
| qschulz | override: https://pretalx.com/media/yocto-project-summit-2021/submissions/WTT3UV/resources/Demystifying_the_OVERRIDES_mechan_no6J6fb.pdf context specific operator section | 12:33 |
| override | cool, thanks guys - guess I'd have to do something better than use the bblayes ordering now | 12:34 |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has quit IRC (Ping timeout: 265 seconds) | 12:38 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has joined #yocto | 12:40 | |
| override | qschulz: I get the content specific bit, but my issue here is that the MAchine names are the same, I some how want local.cong to fetch them machine from a particualr meta-layer.. | 12:48 |
| JaMa | zeddii: I've sent a fix for recipes-extended/uxen/uxen-guest-tools_4.1.7.bb, it was triggered in my world builds for first time, just because of missing "export MACHINE" :) and this was first qemux86-64 build which included meta-virtualization (normally I test this only with qemux86 and qemux86-64 world builds on the other hand don't include meta-virtualization) | 12:50 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 12:52 | |
| JaMa | and now with do_patch fixed it fails in do_compile a bit later (so it probably wasn't building well before if ever): | 12:52 |
| JaMa | | /OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/uxen-guest-tools/4.1.7-r0/uxen-vmsupport-linux-4.1.7/uxenhc/hypercall.c:127:24: error: too many arguments to function '__vmalloc' | 12:52 |
| JaMa | | 127 | uxen_hcbase = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_EXEC); | 12:52 |
| JaMa | | | ^~~~~~~~~ | 12:52 |
| JaMa | | /OE/build/oe-core/tmp-glibc/work-shared/qemux86-64/kernel-source/include/linux/module.h:182:43: error: expected ',' or ';' before 'KBUILD_MODFILE' | 12:52 |
| JaMa | | 182 | #define MODULE_FILE MODULE_INFO(file, KBUILD_MODFILE); | 12:52 |
| JaMa | | | ^~~~~~~~~~~~~~ | 12:52 |
| *** tortoisedoc <tortoisedoc!~tortoised@80-248-240-194.cust.suomicom.net> has joined #yocto | 12:58 | |
| override | qschulz: all these different methods let you assign values to a varaible - I dont see how I can use them to select what meta-layer to get the machine from (when the name of the machine is the same in both the meta-layers) | 12:59 |
| tortoisedoc | excuse the intrusion; would someone be able to forward me to the right channel? I have questions pertaining RDK | 12:59 |
| qschulz | override: you're not supposed to have two machine conf files with the same name | 12:59 |
| qschulz | and you didn't want to change the name because recipes were using MACHINE, I gave you a way to not make them depend on that | 13:00 |
| qschulz | by using MACHINEOVERRIDES | 13:00 |
| override | oh, think I see what you mean now. | 13:02 |
| qschulz | just create your own machine conf file which has a different name. The content can even be the same if you want | 13:02 |
| override | but like my recipes with be able to use something for the MACHINE varaible, different from what the actual machine is called | 13:03 |
| override | using MACHINEOVERRIDES or something ok | 13:03 |
| zeddii | JaMa: ack'd I see the patch. I'll ping Christopher on #meta-virt to see if he can fix the build issue .. since he's the Xen expert. Otherwise, I'll have a look later today. | 13:06 |
| *** jwillikers <jwillikers!~jwilliker@algn-1-173-215-118-62.dsl.netins.net> has joined #yocto | 13:07 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 13:16 | |
| JaMa | never leave your IT dep people near your build servers without supervision! they are capable of anything and unfortunately even have permissions to do so.... sigh | 13:17 |
| tortoisedoc | JaMa isnt devops meant to keep it & sw dev close? | 13:20 |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has joined #yocto | 13:20 | |
| * tortoisedoc ducks | 13:20 | |
| JaMa | 9400 km between me and it is still too close for what they are doing recently :) | 13:22 |
| tortoisedoc | few more km and theyll come in from the backdoor :D | 13:23 |
| JaMa | yeah, need to beg Musk for free ticket soon | 13:24 |
| *** hpsy <hpsy!~hpsy@85.203.15.24> has quit IRC (Quit: Leaving.) | 13:26 | |
| *** hpsy1 <hpsy1!~hpsy@85.203.15.24> has joined #yocto | 13:26 | |
| JaMa | zeddii: it builds ok with 5.4 in dunfell now, only gatesgarth 5.8 and newer with 5.10 kernel are broken | 13:28 |
| * zeddii nods. | 13:31 | |
| zeddii | I'll just try a version update on it. My build just broke the same way. clearly not built all that often :) | 13:31 |
| *** jwillikers <jwillikers!~jwilliker@algn-1-173-215-118-62.dsl.netins.net> has quit IRC (Read error: Connection reset by peer) | 13:33 | |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 13:36 | |
| *** jwillikers <jwillikers!~jwilliker@algn-1-173-215-118-62.dsl.netins.net> has joined #yocto | 13:38 | |
| *** hpsy1 <hpsy1!~hpsy@85.203.15.24> has quit IRC (Ping timeout: 240 seconds) | 13:44 | |
| *** Guest9810 <Guest9810!~Guest98@159-210-178-143.ftth.glasoperator.nl> has joined #yocto | 13:56 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 14:08 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 14:08 | |
| *** camus1 is now known as camus | 14:08 | |
| Guest9810 | I was making a build when I ran into a uninative fetcher failure, which surprised me as I have the BB_GENERATE_MIRROR_TARBALLS set, however it seems this doesn't apply to uninative. I've tried to search for a solution, but I haven't found anything so far. So I'm hoping someone can help me or at least point me in the right direction. Any help would | 14:16 |
| Guest9810 | be appreciated | 14:16 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:26 | |
| *** Guest4 <Guest4!~Guest4@84.198.214.27> has joined #yocto | 14:32 | |
| *** Guest4 <Guest4!~Guest4@84.198.214.27> has quit IRC (Client Quit) | 14:32 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 14:35 | |
| linums | Hi | 14:41 |
| linums | I've found mage-mklibs.bbclass in the hardknott branch, but not in master or dunfell | 14:42 |
| linums | I guess it is dropped, but not just everywhere right? | 14:43 |
| rburton | https://git.openembedded.org/openembedded-core/commit/?id=908df863b419d1cad7317153101fc827e7e3a354 | 14:43 |
| qschulz | https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes?id=e897e02d21e5dc042ac3265d4ab2777c7688e1bb | 14:43 |
| rburton | it wasn't dropped from the old branches in case someone had someone made it work for them | 14:44 |
| qschulz | rburton: too fast. famn | 14:44 |
| qschulz | damn* | 14:44 |
| qschulz | linums: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image-mklibs.bbclass?h=dunfell seems to be here on dunfell | 14:44 |
| linums | right | 14:45 |
| *** ncaidin_lf <ncaidin_lf!~ncaidin_l@2605:380:53:794::85> has joined #yocto | 14:46 | |
| linums | it was just weird to find it on a newer branch than dunfell, but not on dunfell | 14:46 |
| smurray | it's still in dunfell | 14:47 |
| override | so i think my bsp is setting me up for failure by using ${MACHINE} in multiple bbclasses. I dont want to bring them all into my own meta-layer. is this something I just have to live with, or what should be my plan of action here? | 14:47 |
| linums | smurray wow, how did I miss that :D | 14:49 |
| override | bsp pulls the device tree etc from git and appends the ${MACHINE} to uri's in a couple of bbclasses and then theres a few other places too. So when I define my own MACHINE, things dont build very well.. | 14:49 |
| qschulz | override: https://youtu.be/DSnOfF6-xZI?t=326 | 14:50 |
| qschulz | take what you need from the BSP layer and ditch it :) | 14:51 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 14:52 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.1> has joined #yocto | 15:00 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 15:01 | |
| *** Xagen <Xagen!~textual@2600:1700:211:7e60:a0de:d28f:eac4:36af> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 15:02 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 15:04 | |
| *** mckoan is now known as mckoan|away | 15:07 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 15:10 | |
| *** ncaidin_lf <ncaidin_lf!~ncaidin_l@2605:380:53:794::85> has quit IRC (Quit: Client closed) | 15:17 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 15:21 | |
| *** dev1990 <dev1990!~dev@dynamic-62-87-242-228.ssp.dialog.net.pl> has joined #yocto | 15:40 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.1> has quit IRC (Ping timeout: 255 seconds) | 15:48 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.1> has joined #yocto | 15:52 | |
| *** bps <bps!~bps@user/bps> has quit IRC (Remote host closed the connection) | 15:58 | |
| *** Guest9810 <Guest9810!~Guest98@159-210-178-143.ftth.glasoperator.nl> has quit IRC (Quit: Client closed) | 15:58 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 15:58 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:03 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 16:04 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 16:05 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 255 seconds) | 16:08 | |
| vd | hi all -- If I need to build independent variants of images, what are the pros and cons for multiconfig vs local.conf? (Cc: JPEW) | 16:09 |
| vd | I currently use kas which supports both (multiconfig files in the repo or one kas yml file per build), but there's also whisk which is designed over multiconfig. I cannot decide between both. | 16:11 |
| vd | Where I'm heading is having vanilla image recipes for my product, that I bbappend or customize in a build config file (local or multiconfig) for each customer variants. | 16:13 |
| vd | I guess if one day a customer provides its own application layer, then a kas yml file would be more appropriate. | 16:16 |
| vd | damn, whisk supports layer customization, back to square 1... | 16:19 |
| vd | I'd love rburton and JPEW input on this <3 | 16:20 |
| *** argonautx <argonautx!~argonautx@i59F77F5C.versanet.de> has quit IRC (Quit: Leaving) | 16:21 | |
| JPEW | multiconfig is useful if you need to build different configs at the same time | 16:24 |
| JPEW | Also, one of many ways to check product config into git in an easy to consume manner | 16:25 |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has quit IRC (Remote host closed the connection) | 16:32 | |
| vd | JPEW with whisk, does each product or variant have its own file or should a single file be edited to include the variant? | 16:35 |
| JPEW | vd: Each gets it's own config fragment in the `conf` key. You can make that `require` whatever you want | 16:38 |
| JPEW | e.g. all of our `conf` keys are a single line that `requires` another file (as opposed to doing the config inline in the YAML file | 16:39 |
| vd | JPEW I can unfortunately have a very complex set of variants, so ideally long term I would like to write an external graphical tool for non-technical people to click-click in a form to generate a new firmware (in my scenario a given firmware version usually fixes versions for in-house packages) | 16:45 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds) | 16:46 | |
| vd | JPEW would whisk make this easy? (I'd imaging the tool pushing a PR to a CI/CD whisk project to override or add a single file, validated with the `validate` whisk command before triggering builds) | 16:49 |
| JPEW | You could probably do that with whisk.... I don't know exactly what you need to customize, but we have a similar usecase where we have a "standard" image that each product customizes | 16:50 |
| vd | exactly this | 16:51 |
| JPEW | vd: Ya, we do IMAGE_INSTALL_pn-main-image = "..." in each product's multiconfig | 16:52 |
| vd | JPEW mainly different variants in my case would be minor image customization for the customer (changing title variables), including or excluding a package, or fixing packages versions. | 16:52 |
| JPEW | Yep | 16:52 |
| vd | JPEW this is what I'm heading to, regardless the tool. SUMMARY_pn-vanilla-image = "Customer image" ;-) | 16:53 |
| vd | the best would be the `require` key to allow a glob or pattern so that I don't need to edit the main whisk config, but that might not be big of a deal anyway. | 16:54 |
| * vd discovered whisk *after* working around all his issues with kas.. | 16:56 | |
| vd | JPEW your CI/CD compile all-targets every time? | 16:57 |
| *** linums <linums!~linums@84.198.214.27> has quit IRC (Ping timeout: 246 seconds) | 16:57 | |
| JPEW | Ya, usually for CI we compile each in it's own instance in parallel | 16:58 |
| JPEW | But for releases, we can build multiple products at the same time (since they e.g. need to be packaged together in the same software updates) | 16:58 |
| JPEW | Which is where using multiconfig is really helpful | 16:58 |
| *** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 16:58 | |
| vd | like co-processor products | 16:59 |
| JPEW | Exactly | 16:59 |
| JPEW | Except at a higher level | 17:00 |
| *** florian <florian!~florian@dynamic-093-132-134-059.93.132.pool.telefonica.de> has joined #yocto | 17:00 | |
| vd | yeah I guess if your high-end products is composed of multiple embedded devices paired together, it's neat to package all their firmwares together, hence building in the same instance with multiconfig | 17:01 |
| JPEW | Yep. Most our products are network together and we don't support mixed versions | 17:02 |
| vd | we actually might have this in the future, so better have a setup supporting this use case | 17:02 |
| vd | actually what I have is microcontroller versions not built by yocto, but potato-potato mostly. version-1.2 must have micro controller version x, while version-1.3 must have micro controller version y, etc. | 17:03 |
| vd | this kind of boring mapping that I want non-technical persons to manage and be able to trigger such builds themselves | 17:04 |
| vd | in fact, the external click-click tool I'm describing would simply be a front-end for the main yaml file | 17:12 |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::f245> has quit IRC (Remote host closed the connection) | 17:15 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::f245> has joined #yocto | 17:18 | |
| *** TundraMan <TundraMan!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 17:20 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 255 seconds) | 17:20 | |
| *** ncaidin_lf <ncaidin_lf!~ncaidin_l@2605:380:53:794::100> has joined #yocto | 17:22 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 17:23 | |
| *** ncaidin_lf <ncaidin_lf!~ncaidin_l@2605:380:53:794::100> has quit IRC (Quit: Client closed) | 17:28 | |
| *** TundraMan is now known as marka | 17:30 | |
| *** linums <linums!~linums@d51a4822f.access.telenet.be> has joined #yocto | 17:36 | |
| vd | JPEW does whisk handle layer patches? | 17:36 |
| JPEW | Not currently. It's on my TODO list; we deal with them by having internal mirrors of the layers (although I realize this may not be for everyone) | 17:37 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Ping timeout: 240 seconds) | 17:37 | |
| vd | indeed, hosting a fork for a single patch in a layer is a bit overkill. | 17:38 |
| JPEW | vd: Ya. We have a strict policy to only backport existing upstream fixes, which helps | 17:38 |
| vd | Can the `commands` section include an additional `git am` command after the fetch maybe? | 17:38 |
| JPEW | Yes, you can do that | 17:38 |
| vd | perfect then, I can handle the patch on my own, might be cleaner | 17:39 |
| JPEW | But that does mean all your users would need to fetch using whisk, which may or may not be what you want | 17:39 |
| vd | kas do it for you which is kinda nice, but can be confusing. | 17:39 |
| JPEW | The other thing we do a lot is have parallel "fixes" layers for each upstream later where we can bbappend things | 17:40 |
| JPEW | which reduces the need to fork | 17:40 |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 17:41 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 17:43 | |
| *** linums <linums!~linums@d51a4822f.access.telenet.be> has quit IRC (Quit: Ping timeout (120 seconds)) | 17:46 | |
| *** jwillikers <jwillikers!~jwilliker@algn-1-173-215-118-62.dsl.netins.net> has quit IRC (Remote host closed the connection) | 17:50 | |
| *** linums <linums!~linums@d51a4822f.access.telenet.be> has joined #yocto | 17:52 | |
| *** Sansveni <Sansveni!~Sansveni@167.89.254.27> has joined #yocto | 18:17 | |
| *** linums <linums!~linums@d51a4822f.access.telenet.be> has quit IRC (Quit: Client closed) | 18:23 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 18:24 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 18:38 | |
| *** jsandman <jsandman!~jsandman@95.179.203.88> has quit IRC (Quit: Ping timeout (120 seconds)) | 18:41 | |
| *** jsandman <jsandman!~jsandman@95.179.203.88> has joined #yocto | 18:41 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has quit IRC (Ping timeout: 265 seconds) | 18:50 | |
| *** davidinux <davidinux!~davidinux@217.138.219.150> has joined #yocto | 18:54 | |
| *** mranostaj <mranostaj!~mranostaj@185.193.126.133> has quit IRC (Ping timeout: 252 seconds) | 19:02 | |
| *** mranostaj <mranostaj!~mranostaj@185.193.126.133> has joined #yocto | 19:02 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 252 seconds) | 19:02 | |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds) | 19:02 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 19:02 | |
| *** zyga__ <zyga__!~zyga@31.0.173.147> has joined #yocto | 19:07 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has joined #yocto | 19:12 | |
| *** yates_home <yates_home!~user@fv-nc-f7af8b91e1-234237-1.tingfiber.com> has joined #yocto | 19:24 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.1> has quit IRC (Read error: Connection reset by peer) | 19:25 | |
| yates_home | if i understand the message correctly, there is a dependency named 'u-boot' in the dependency chain for core-image-minimal: http://paste.ubuntu.com/p/4NKyQPFbyq/ | 19:25 |
| yates_home | how do i change that to 'u-boot-csky'? | 19:25 |
| vd | yates_home maybe set the preferred u-boot provider with PREFERRED_PROVIDER_u-boot = "u-boot-csky" | 19:28 |
| yates_home | doh! | 19:29 |
| yates_home | that makes sense | 19:29 |
| *** zyga__ is now known as zyg | 19:30 | |
| *** zyg is now known as zyga | 19:30 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.17> has joined #yocto | 19:32 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 20:11 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:d171:bc7d:edcd:c987> has joined #yocto | 20:23 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:d171:bc7d:edcd:c987> has quit IRC (Quit: Client closed) | 20:31 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 256 seconds) | 20:33 | |
| *** zyga <zyga!~zyga@31.0.173.147> has quit IRC (Ping timeout: 276 seconds) | 20:34 | |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has joined #yocto | 20:37 | |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has quit IRC (Quit: Leaving) | 20:41 | |
| *** amitk_ <amitk_!~amit@103.208.69.1> has joined #yocto | 20:55 | |
| *** amitk <amitk!~amit@103.208.69.73> has quit IRC (Ping timeout: 250 seconds) | 20:58 | |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has joined #yocto | 21:03 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 252 seconds) | 21:08 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.17> has quit IRC (Ping timeout: 255 seconds) | 21:21 | |
| *** mc__ <mc__!~mccc@c-73-239-24-228.hsd1.wa.comcast.net> has quit IRC (Quit: Leaving) | 21:34 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 21:35 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 21:50 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 21:58 | |
| yates_home | vd: that worked. thank you. | 22:09 |
| yates_home | when buildling an image, what defines the top-level steps? my immediate issue os that, sometime after virtual/bootloader is build (which completes successfully), i am getting a ERROR: Task (/mnt/hdd/EDG/dachuan-research/gs500/poky/meta-csky/recipes-kernel/linux/linux-csky_5.12.bb:do_uboot_mkimage) failed with exit code '1' | 22:11 |
| yates_home | there must be some mkimage task in the top-level steps? | 22:12 |
| yates_home | ok i get it: this is part of the kernel build | 22:15 |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 22:19 | |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has quit IRC (Quit: Leaving) | 22:20 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 22:37 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 22:51 | |
| *** florian <florian!~florian@dynamic-093-132-134-059.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 22:59 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 23:14 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 23:56 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!