**** BEGIN LOGGING AT Thu Dec 03 02:59:57 2020 Dec 03 03:35:15 absolutely! Dec 03 03:35:26 I'd get one for sure. Dec 03 03:59:41 jonmason: I was thinking about OE Cloisonné Hard Enamel Pins maybe? Dec 03 07:37:43 hi RP, we've been accumulating a handful of patches on the list for yocto-docs, I pushed a series to master-next, and it looks good to me (http://docs.yoctoproject.org/next/). feel free to merge. Dec 03 07:39:00 paulbarker: i locally fixed up your 1/3 patch (the occurrence you missed when removing the /wiki from links) Dec 03 07:43:38 yo dudX Dec 03 07:48:34 freezing morning LetoThe2nd, everybody Dec 03 07:49:17 hehe yeah mckoan Dec 03 07:49:24 * LetoThe2nd has hot coffee Dec 03 08:53:05 ndec: thanks, I've been a little distracted and that was on my todo list for today! :) Dec 03 08:58:40 First snow in Vienna \o/ Dec 03 09:00:01 as most social events are cancelled anyways this year, i think we should kind of like have a YP community party. Dec 03 09:03:47 is there some kind of switch statement I can use in a recipe? :) Dec 03 09:04:03 based on a variable Dec 03 09:07:50 Ad0: what do you want to do exactly? Dec 03 09:08:02 overrides should be able to give you this opportunity anyway Dec 03 09:08:11 hm Dec 03 09:08:26 I have one recipe right, and based on a variable I want to set different values in a file I install Dec 03 09:08:28 like server name Dec 03 09:08:32 CASE_machine1 = "a" CASE_machine2 = "b", etc... then use CASE directly Dec 03 09:08:48 really Dec 03 09:09:09 This applies to distros or machines but nothing else really IIRC Dec 03 09:09:16 so, depends who sets this variable? Dec 03 09:09:30 it's set as an environment varible Dec 03 09:10:01 Ad0: then use BB_HASH_WHITELIST or something like that Dec 03 09:10:14 then you can pass it as part of your bitbake build as an env Dec 03 09:10:41 yes I use export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE .... " Dec 03 09:11:06 so it becomes a "real" variable available globally Dec 03 09:11:23 https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_ENV_EXTRAWHITE Dec 03 09:11:35 Ad0: yeah then you already know about it :) Dec 03 09:11:38 what's the issue with it? Dec 03 09:11:40 yes thanks a lot Dec 03 09:12:23 to switch on it was the issue I didn't know there was a CASE_* Dec 03 09:13:36 does it only works on machine? Dec 03 09:15:00 maybe just use python directly... or different recipes Dec 03 09:15:17 Good morning, Sorry to bother you again. Are there anyone could give me a little suggestion about to proceed to include a third-party tools (closed-source compiler) in the SDK ( https://lists.yoctoproject.org/g/yocto/message/51593 ), please? Thanks! Dec 03 09:16:02 Ad0: Just read the value from a task directly and do your switch in it either in python or shell Dec 03 09:16:04 Ad0: not a full switch case but for simple if else I have used this "${@oe.utils.ifelse(d.getVar('DISTRO') == 'something','a','b')}" Dec 03 09:17:04 thanks Dec 03 09:19:03 https://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html#python-functions Dec 03 09:20:05 Ad0: s/2.3/current/g Dec 03 09:20:31 ye Dec 03 09:20:50 jonmason: alive ? Dec 03 09:21:37 I can use python () { as well Dec 03 09:21:49 OutBackDingo: probably not the next 4 or 5 hours. Dec 03 09:22:22 Anyone have any ideas ? seems meta-lx2k u-boot is broken, /var/home/dingo/overc/lx2k/tmp/hosttools/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here Dec 03 09:22:33 LetoThe2nd: thx Dec 03 09:33:18 is there a way to use PACKAGE_EXCLUDE only for images (do_rootfs) but not SDKs (do_populate_sdk)? I have a GPLv3 package that I may not include in my image but which I would like in my SDK Dec 03 09:36:25 bps2: out of the blue, I'd check if the class-nativesdk wouldn't allow something like that (provided it exists :) ) Dec 03 09:39:50 qschulz, I had a look at nativesdk.bbclass if that's what you mean? but I'm not really sure what to look for Dec 03 09:43:08 bps2: you can have VAR_class-target which overrides VAR when building the recipe for the target as opposed to native Dec 03 09:43:27 wondering if there isn't the same mechanism for nativesdk packages, if that's even relevant Dec 03 09:43:36 (not experience whatsoever in yocto sdks) Dec 03 09:44:59 I am pretty new to yocto and also unfamiliar with the sdks. but it seems like the error I have is when building the sdk for the target actually Dec 03 09:46:53 bps2: the easiest of the easiest is just to have two image recipes Dec 03 09:47:20 the production image recipe requiring the sdk image recipe and adding the PACKAGE_EXCLUDE Dec 03 09:48:08 ah, that makes a lot of sense Dec 03 11:47:12 hrmmm this feels like a GCC 10.x issue Dec 03 11:57:18 OutBackDingo: ask jonmason as he's been poking at that layer and might have a local fix. Dec 03 12:03:54 a local fix that can be remotely applied! Dec 03 12:04:35 ndec: thanks, those look good, I've merged! Dec 03 12:08:03 RP: cool! Dec 03 12:54:47 rburton: yupp, as usual ive filed issues with meta-lx2k ill poke him seems theres also a trusted-firmware issue trusted-firmware-a-1.5-r0 do_install: Unsupported TFA_INSTALL_TARGET target pbl Dec 03 13:51:01 OutBackDingo: I have a few patches queued that might help. One to fix tf-a, one to add gatesgarth, and more hacking to try to get other stuff working (like uefi). I thought I was the only one using it, so it's been idle cycles work Dec 03 14:10:56 jonmason: Hi, care to push them to me privately ? Dec 03 14:11:46 OutBackDingo: I'll clean them up and push the ones that work later today Dec 03 14:14:49 dpm Dec 03 14:15:03 wow. what was supposed to be "don't", not a new package manager Dec 03 14:15:53 I was going to advise @jonmason to not push too hard, or he'll blow an o-oring. but the moment is lost due to fat fingers. Dec 03 14:18:01 hello, guys Dec 03 14:18:41 Hi all Dec 03 14:20:14 * qschulz waves Dec 03 14:20:23 How can I copy my uEnv.txt file in ${DEPLOY_DIR_IMAGE} (so that wic picks it)? Dec 03 14:21:44 I'm trying this u-boot_%.bbappend recipe without success: http://ix.io/2Gn4 Dec 03 14:24:01 v0n: you should do that when you create the image, not the bootloader Dec 03 14:26:52 mckoan: where I append the IMAGE_BOOT_FILES variable in fact, I see. How do I copy my uEnv.txt file in ${DEPLOY_DIR_IMAGE} from the image recipe then? Dec 03 14:31:58 zeddii: want some music for the lost in time moment? Dec 03 14:32:12 most definitely Dec 03 14:33:52 mckoan: also, where is the proper place to store my file? same folder as the image recipe? Dec 03 14:33:58 zeddii: even better: https://youtu.be/o26SlmROH5Q Dec 03 14:34:05 (lost in space) Dec 03 14:35:20 This is why slack sold for 27 billion, their IRC wrapper has a "like button", I can just say "awesome" Dec 03 14:35:45 Who should upload a new license to OE? Dec 03 14:36:08 vermaete: anyone. just send a patch, and if it accepted, it is there. Dec 03 14:36:29 the meta-opendds layer on github failes on the 'yocto-check-layers' on the not know license. Dec 03 14:36:38 Dammed, you're fast. i'm not yet finished typing. Dec 03 14:36:44 :D Dec 03 14:36:53 Fine, I will do. Dec 03 14:37:06 Do you know which mainlinglist? Dec 03 14:37:15 layers can also carry their own license files, but I don't know if check layers considers that acceptable. Dec 03 14:37:26 if it is in meta/ it is the oe-core mailing list Dec 03 14:37:45 It's just for the beauty of having no warnings. Dec 03 14:38:02 openembedded-core@lists.openembedded.org is oe-core Dec 03 14:38:13 Ok, thanks. Dec 03 14:40:04 JPEW: are you watching the LiveEmbedded event? there's a talk in 1h20m on labgrid Dec 03 14:41:59 tlwoerner: No... is there a Link? Dec 03 14:42:54 wouldn't it be cleaner to override the u-boot recipe to include my custom uEnv.txt file in DEPLOY_DIR_IMAGE? Dec 03 14:44:56 v0n: you should add it to a do_deploy task and install it to DEPLOYDIR Dec 03 14:45:12 if you do not do exactly what I said, you'll break your sstate-cache Dec 03 14:45:22 so "it works" but not really ;) Dec 03 14:45:36 JPEW: it's being run through linkedin Dec 03 14:46:18 qschulz: ok chief, still learning, I'm new to Yocto Dec 03 14:49:28 rburton: your patch breaks a selftest: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1618/steps/14/logs/stdio :) Dec 03 14:49:50 rburton: trivial fix thankfully Dec 03 14:52:35 qschulz: I took the u-boot append example from meta-raspberrypi though. Why isn't it a problem for sstate-cache there? Dec 03 14:53:47 v0n: actually even simpler: UBOOT_ENV = "uEnv" and voila, nothing else :) Dec 03 14:56:10 v0n: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-bsp/u-boot/u-boot.inc?h=master#n52 Dec 03 14:56:56 well, and your FILESEXTRAPATHS and the SRC_URI += of course Dec 03 14:57:03 which version of yocto are you building? Dec 03 14:58:30 does not matter, it's supported for at least 5y already from my quick search :) Dec 03 14:59:02 v0n: FYI, your website is giving a lot of 500 HTTP error codes :) Dec 03 15:07:56 qschulz: ix.io? that's not my website, just a raw paste service. Dec 03 15:10:10 qschulz: I've seen that comment, but it's still unclear to me where and how to "include it in the SRC_URI and set the UBOOT_ENV parameter." Dec 03 15:10:26 qschulz: that's why I went with the u-boot append approach Dec 03 15:14:37 RP: did you fix or should i send an update? Dec 03 15:21:43 v0n: does U-Boot create a uEnv.txt by default by any chance? Dec 03 15:21:52 or is yours the only thing it'll get? Dec 03 15:22:26 no uEnv.txt by default if I'm not mistaken Dec 03 15:23:37 RP: i'm looking at the master-next failure in test_expected_files Dec 03 15:25:12 v0n: then, you need a bbvappend to U-Boot to provide it your uEnv.txt Dec 03 15:25:25 for that, you need FILESEXTRAPATHS and SRC_URI Dec 03 15:25:58 but that's not enough because obviously you need to tell Yocto to deploy the file Dec 03 15:26:42 for that, you can just set UBOOT_ENV to "uEnv" in your bbappend (probably with _beaglebone too, like you did for SRC_URI) Dec 03 15:26:53 because the uboot.bbclass provides the logic for this Dec 03 15:27:12 u-boot.inmc actually not bbclass Dec 03 15:29:14 qschulz: this will copy uEnv.txt to the image deploy dir I assume. I also need to set IMAGE_BOOT_FILES += "uEnv.txt" within the image recipe for wic to pick it up, right? (according to https://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-IMAGE_BOOT_FILES) Dec 03 15:30:06 v0n: are you really on yocto 2.1 (krogoth)? Dec 03 15:30:33 v0n: but yes, probably (I don't use wic :/) Dec 03 15:30:38 qschulz: no, dunfell Dec 03 15:31:19 qschulz: you don't prepare sdcard/flash images with wic? Dec 03 15:31:31 v0n: then take the documentation from dunfell :) https://docs.yoctoproject.org/3.1.3/index.html Dec 03 15:32:18 damnit Dec 03 15:32:42 v0n: no, we had nand before so ubi, and now for emmc we use ext4 in conjunction with our custom "image type" for swupdate :) Dec 03 15:33:28 rburton: i think your 783d654cbff012c8cb3362767f7e0d2c9cac46f8 patch in master-next is causing the oe-selftest to fail in test_expected_files for containerimage, :) Dec 03 15:33:37 yeah RP just told me :) Dec 03 15:33:57 rburton: cool Dec 03 15:34:04 the 3.1.3 doc says the same for IMAGE_BOOT_FILES though Dec 03 15:34:07 alimon: did you triage yesterday's builds? looked like net-tools remains broken Dec 03 15:34:28 rburton: i did it but not found any issue, can you point me? Dec 03 15:34:50 http://errors.yoctoproject.org/Errors/Details/539019/ Dec 03 15:35:20 v0n: I didn't say it wasn't the case, it's just that your doc would be missing a lot of information or even have erroneous explanations :) Dec 03 15:35:24 qschulz: I still have this error though: "output: install: cannot stat '/work/build/tmp/deploy/images/beaglebone/uEnv.txt': No such file or directory" Dec 03 15:35:32 alimon: failed on three different builds (multilib, iirc) Dec 03 15:35:56 v0n: are you actually building the correct u-boot or added your bbappend to the correct u-boot? Dec 03 15:36:32 v0n: bitbake virtual/bootloader -e | grep -e "^BPN=" Dec 03 15:36:36 this should probably help? Dec 03 15:38:28 actually no, that'll not work Dec 03 15:38:41 but find out which u0boot recipe you're actually using and bbappend to tht one Dec 03 15:39:12 (it's probably somewhere in the beaglebone machinfe configuration file, PREFERRED_PROVIDER_virtual/bootloader or PREFERRED_PROVIDER_u-boot) Dec 03 15:42:23 qschulz: I had to run with -f, and I got this: NOTE: Tainting hash to force rebuild of task /work/meta-ti/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb, do_build Dec 03 15:43:41 v0n: you rarely need to run with -f :) Dec 03 15:43:49 v0n: -c cleansstate on your recipe now Dec 03 15:43:56 there's no other way Dec 03 15:44:20 so, you want a bbappend named u-boot-ti-staging_2020.01.bbappend or u-boot-ti-staging_%.bbappend Dec 03 15:47:08 qschulz: without -f I didn't get the package name ;) Dec 03 15:47:51 qschulz: I thought that u-boot was enough :s Dec 03 15:50:36 v0n: no, it's an exact match on the recipe filename Dec 03 15:51:28 though you can do a "match all" with % but only for the version part (so after an underscore in the filename) and only with %.bbappend at the end, nothing else after Dec 03 15:51:52 qschulz: ok u-boot != u-boot-ti-staging in the context of beaglebone, good to know Dec 03 15:52:25 v0n: no, in the context of Yocto actually Dec 03 15:52:32 qschulz: do I need to run bitbake -c cleansstate virtual/bootloader every time I change the append file? Dec 03 15:52:41 v0n: no, only when you do a -f Dec 03 15:53:06 got it Dec 03 15:53:30 v0n: in Yocto, multiple recipes can provide the same "functionality" Dec 03 15:53:50 they're called virtual packages most of the time Dec 03 15:54:07 but since they provide the same functionality, it makes no sense to build them all Dec 03 15:54:19 so you pick (prefer) one Dec 03 15:54:27 all the others aren't built Dec 03 15:54:36 qschulz: yep, but I thought "u-boot" was kinda virtual for all u-boot variants somehow Dec 03 15:54:45 v0n: yup, can be too Dec 03 15:55:09 but it's a both the name of a "virtual" package and of the recipe of the upstream u-boot Dec 03 15:55:54 you should be able to find a PROVIDES = "u-boot" somehwere in one of the file used by u-boot-ti-staging, that explicits the "virtual" package to which it is "linked" Dec 03 15:56:16 and... you cannot apply bbappends to virtual packages Dec 03 15:57:01 ok Dec 03 16:04:10 qschulz: I now have uEnv.txt, uEnv-beaglebone-2020.01+gitAUTOINC+3c9ebdb87d-r23.txt and uEnv-beaglebone.txt in build/tmp/deploy/images/beaglebone/ with this recipes-bsp/u-boot-ti-staging/u-boot-ti-staging_%.bbappend file: https://pastebin.com/raw/p1jVCuvu Dec 03 16:06:43 uEnv-beaglebone.txt seems useless though (given that it's already in the machine-specific directory) Dec 03 16:06:59 v0n: it's just symlinks IIRC Dec 03 16:07:24 true Dec 03 16:07:25 if core-image-minimal.bb inherits from core-image ... where is located core-image.bb recipe? Dec 03 16:10:41 wyre: see poky/meta/classes/core_image.bbclass Dec 03 16:14:39 wyre: inherit = bbclass, so you need to look into some-layer/classes to find it Dec 03 16:31:12 qschulz: I think it worked, thank you! Dec 03 16:35:05 package list to run gles2 app (glmark2) on rpi with userland: https://pastebin.com/DcQE4ifH Dec 03 16:36:32 LetoThe2nd, if you think Rudolf J. Streif book is outdated which one do you recommend me? Dec 03 16:38:05 v0n: my pleasure :) Dec 03 16:41:03 wyre: right at the moment there is no book that is unconditionally recommendable, I'm sorry. Dec 03 16:44:02 wyre: there's anyway so much info to digest that I wouldn't recommend reading a book to get started on Yocto Dec 03 16:44:09 find a project and start working on it Dec 03 16:44:37 also, what helped me at one point was to read the official documentation, it's very time-consuming but you discover tons of things Dec 03 16:46:43 bootlin has some cc-by-sa training materials if you want some more reading Dec 03 16:53:33 I am looking for guidance for yocto build for vmware vmdk image Dec 03 16:58:44 Yes, the best go to material at the moment is probably bootlin, and YouTube Dec 03 16:59:18 Jerry07: IMAGE_FSTYPES += "wic.vmdk" Dec 03 16:59:29 Jerry07: this is just a guess, i haven't done vmdk images in a long time Dec 03 17:49:07 Hey my test devices freezes during boot. Everything looks fine at first. last line that I see arriving through serial is: `[ 1.695138] Run /bin/sh as init process` Dec 03 17:49:31 any hint where to look for the problem? Dec 03 18:22:06 emrius: your init system isn't setting up the getty properly (or at all) Dec 03 18:22:26 emrius: e.g. if you're using sysvinit then your /etc/inittab doesn't have a good entry Dec 03 18:22:54 emrius: e.g. S0:12345:respawn:/bin/start_getty 115200 ttyS0 vt102 Dec 03 18:51:41 RP: rburton i'm looking at this failure, https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1647/steps/23/logs/stdio, that means the artifacts needs to be downloaded first and copy to the yocto mirror? Dec 03 19:16:46 alimon: its there to test whether upstream fetching is working and the test is saying not :/ Dec 03 19:18:54 RP: i downloaded the links manually and works, so is the test made in a way pre-fetch and then enable only fetch from yocto mirrors? Dec 03 19:22:14 alimon: it disables all mirrors, yes Dec 03 19:23:11 alimon: I'm not sure if its some kind of DoS rate limiting which the autobuilder is provoking on the upstream servers Dec 03 19:53:18 tlworner: Thanks!!!!!! Dec 03 19:53:26 tlwoerner: Thanks!!!!!! Dec 03 20:19:40 JPEW: were you planning to push changes to github for battlestar? just curious to see what "works" from last night... Dec 03 21:02:46 RP: https://carlosbecker.com/posts/python-docker-limits/ hmm, wonder if we're affected by things like this Dec 03 21:05:02 kergoth: perhaps although bitbake's memory usage should be well below what is permitted by the larger build Dec 03 21:15:55 * armpit what about bitbake cloud ??? Dec 03 21:43:05 armpit: going to need bitbake edge as well Dec 03 21:58:37 moto-timo: Ya Dec 03 21:58:45 moto-timo: I'll try to do that tonight Dec 03 22:35:32 * armpit thinks kernel commits are hilarious : " You might want to have a barf bag Dec 03 22:35:32 handy when you do." Dec 04 00:18:49 JPEW: no pressure, just very curious ;) Dec 04 00:18:53 JPEW: thank you **** ENDING LOGGING AT Fri Dec 04 02:59:56 2020