**** BEGIN LOGGING AT Tue Dec 01 03:00:02 2020 Dec 01 08:59:16 yo dudX! first snow! Dec 01 09:02:52 LetoThe2nd: hi, same forecast here \o/ Dec 01 09:04:34 \o/ Dec 01 09:06:04 First negative temperatures here o/ Dec 01 09:06:31 negative here since about a week, but way too much sun :( Dec 01 09:07:35 LetoThe2nd: YOU COMPLAIN ABOUT SUN IN THE END OF NOVEMBER? Dec 01 09:07:48 LetoThe2nd: It's pitch dark at 4:15pm here :( Dec 01 09:08:12 * LetoThe2nd likes dark. Dec 01 09:08:23 plus, vienna is a couple of 100km east. Dec 01 09:28:52 LetoThe2nd: I like darkness too... but I start working late so having half my day of work in complete darkness is quite depressing :) Dec 01 09:29:09 qschulz: have kids, get up early. Dec 01 09:30:25 LetoThe2nd: my sleep is sacred, can't have kids Dec 01 09:31:00 hehe Dec 01 09:42:17 looking for guidance in extending the Wget: our primary need is to be able to download files served by private gitlab.com (from npm package repository) using an "Authorization: Bearer XXXX" header. My initial PoC just adds an authz_bearer parameter to the wget URI, but that may be too specific, and I'd also like to specify it outside of the URI but I'm not sure on the best way to go Dec 01 09:44:43 basically what I'd like is modifying FETCHCMD_wget, that way any --header option can be used, but I did not go that route in the PoC because the token is for a single URI and I don't want it to be sent to other servers Dec 01 09:47:05 now we have the "name" URI parameter - would it be correct to allow something like FETCHCMD_wget_append[$name] for such a usage ? Dec 01 09:50:58 what's foremost annoying there is that the FETCHCMD_$method default is hardcoded in bitbake so we just can't use _append Dec 01 09:53:27 wouldn't it be useful to have the fetch method do a setVar in their ctor and remove the "or $hardcodedcmd" ? Dec 01 10:10:09 And then there is the idea of using the "name" parameter for this: it seems safe as Wget URIs can only ever have one name specified this way, but does that make it a good idea ? Dec 01 10:16:38 LetoThe2nd: it also snows pretty heavy on the west side of Austria here. ski resort owners are getting happy! ;) Dec 01 10:18:12 zandrey: let's wait to see if the ski resorts can re-open ;) Dec 01 10:19:03 qschulz: Swiss and Austrians would not give up on this! :D Dec 01 10:22:14 zandrey: France already decided they would open the ski resorts but not the chairlifts hehehehe Dec 01 10:22:33 and i heard Germany is pushing hard for no ski season in Europe Dec 01 10:23:53 qschulz: no chairs??? that would be chaos! :O and Germans really went pretty extreme, heard that on the news the other day. one day skiing - 10 day home with no wages! :O Dec 01 10:26:06 this year would be mad in the mountains... i didn't even waxed the board, not even talking about season pass... :( Dec 01 10:54:22 hi Dec 01 10:55:32 Z Dec 01 10:56:08 active low Dec 01 10:57:27 I'm trying to put git, make and python into a sdk generated via `bitbake -c populate_sdk my_image`. I've created a `nativesdk-my_app.bb` companion recipe that adds `nativesdk-git`, etc. to `RDEPENDS_${PND}`. Dec 01 10:57:37 but those never end up in the generated sdk Dec 01 10:57:59 are they somehow filtered by `ASSUME_INSTALLED`(?) ? Dec 01 11:00:13 I tried to go with DEPENDS+="git-native", etc. in `my_app.bb`, but that wouldn't work out either :-/ Dec 01 11:17:52 Hi all, long time lurker. I have recently got into Yocto to meet my professional requirements. I am wondering if I can get some opinions and previous experience from people on this chat. I am in my early stages of prototyping and software requirements haven't been nailed down yet but I know I will need some form of recovery. I am trying to cover the potential situation of corruption to the systems and restore to a known good image, this would ideally be Dec 01 11:17:52 automatic for corruption situations but user intervention is still possible if the automatic approach isn't possible. Dec 01 11:17:52 I am thinking of going down the read only rootfs but haven't experimented with this yet and I would ideally have a duplicated partition I could boot to for recovery purposes. I am thinking of having two images (system and recovery) and a custom kickstart file to partition the final image appropriately. Then can modify the something low down in the boot partition of the board to choose appropriate partition, not sure how I'll do this at the moment. I was Dec 01 11:17:56 wondering is anyone has wanted to cover this situation before and what they decided? Dec 01 11:19:52 TPRoberts: Seen two solutions so far, obviously depends on what your board supports. One was a separate kernel with a minimal initramfs that gets booted by the bootloader if it can't successfully boot the real thing. Dec 01 11:20:32 The other is a bootloader that accepts a sideloaded image during boot (if its signature checks, of course). Dec 01 11:21:11 TPRoberts: swupdate, RAUC or probably other upgrade mechanisms should supportthis more or less Dec 01 11:22:00 you're probably looking for A/B partitioning mechanism that you can find on Android/ChromeOS for example Dec 01 11:23:49 A/B doesn't necessarily help you recover a sample where both partitions are broken, though. Dec 01 11:24:00 But yes, A/B is a good idea regardless, if you have the space. Dec 01 11:26:20 FWIW, we use swupdate with one fitimage with an initramfs (with swupdate in it) and from production image we ask to boot into this fitimage at reboot Dec 01 11:26:41 it also does reboot into the "recovery image" if you can't reach production usersapce for too many times Dec 01 11:27:15 neverpanic: there's always a scenario you won't be able to cover. If you have corrupted your boot partitions, you're fucked too anyway Dec 01 11:27:38 hi Z ... amp user spotted.. Dec 01 11:30:28 PaowZ: hm? Dec 01 11:53:14 neverpanic & qschulz thanks for your input, wasn't expecting a replies so quickly. I am working with Raspberry Pi4, it wouldn't of been my choice but I came to the project too late. The Pi 4 doesn't have the traditional bootloader on other Pis uses EEPROM for initial booting, however I could possibly use this bootloader to boot to a side loaded image or intercept in some way using the recovery.bin. I think this involves more reading and experimenting Dec 01 11:53:14 from. Appreciate the input, I didn't think about side loading a image, I think it might help. Dec 01 12:44:07 khem: have you recently looked at merging the ldconfig-native hacks upstream? was there any traction there? Dec 01 13:05:44 TPRoberts: RPi supports U-Boot too. But obviously, you're bound to whatever the bootrom is giving you. DOn't know much about RPi specific boot process though (before the "sw" bootloader, e.g. u-boot) Dec 01 13:09:24 the rpi bootloader is very complicated Dec 01 13:10:46 Ad0: starts from the GPU IIRC. Anyway, it was more like, if you need redundancy onyour bootloader, it depends on the actual "hardcoded" bootloader (in bootrom or other things, before you can boot a more common bootloader such as u-boot) Dec 01 13:11:09 ye Dec 01 13:11:16 #raspberrypi-internals is good for that Dec 01 13:32:18 qschulz: are you on the 2020.10 u-boot? was just wondering because the fit requires proper "bootm_size" to be set and "initrd_high" with "fdt_high" removed. Dec 01 13:33:41 hm I am still in doubt how I should name image recipes. I would really like to have separate names per machine I build for or whether it's production or development. just to have different image names. can image names have a suffix or something generated based on machine or something? or should there just be separate image recipe names which inherit from the same one ? Dec 01 13:34:59 TPRoberts: if you boot from eMMC - then you might look into PARTITION_CONFIG, which would allow you to store dual copies of boot sector and swap in between almost "atomic". Dec 01 13:37:26 Ad0: sure, why not? an image depends on the machine (yocto wise at least), so I don't see why not (famous last words) Dec 01 13:37:56 why not to a) have separate image files, b) generate suffix (if possible) ? :) Dec 01 13:38:08 Ad0: separate image files? Dec 01 13:38:13 k Dec 01 13:38:24 thanks man Dec 01 13:38:30 b) just add the ${MACHINE} to the IMAGE_BASE_NAME or something like that? Dec 01 13:38:50 no, t'was a question :) didn't understand what you meant wioth separate image files Dec 01 13:39:15 ah ok LOL . I mean having separate recipe files for each type of image. like machine-a-dev.bb Dec 01 13:39:27 but that will be too clunky Dec 01 13:42:09 IMAGE_BASENAME Dec 01 13:42:56 zandrey: no, (way too) old u-boot for us Dec 01 13:44:32 I don't have either of the mentioned variables in u-boot env Dec 01 13:45:03 qschulz: 2020.10 is too old? :D i can only say wow in this case! Dec 01 13:45:17 zandrey: no, the one we use obviously :) Dec 01 13:46:28 as for vars: they do depend on board config include, so you might be lucky it has been adapted already. ;) Dec 01 13:47:14 I remember we needed loadaddr and entrypoint to be set correctly Dec 01 13:47:25 qschulz: ah ok! :) then it is definitely the board you use was cleaned-up. Dec 01 13:47:27 in the its Dec 01 13:47:41 zandrey: it's a custom board so don't know really :p Dec 01 13:47:56 always starting more or less from scratch Dec 01 13:48:01 don't like BSP stuff Dec 01 13:48:13 vendor BSP stuff* Dec 01 13:50:26 ok, got it. actually, for the bootm to work - it is needed that the proper size should be added into bootm_size. this is for aarch64 though. Dec 01 13:52:36 tell me, variable flag names cannot start with an underscore ? I can set such a flag with VAR[_flag]="foo", but then getVarFlag() does not see that :) Dec 01 13:55:27 zandrey: check if bootm_size does not exist it's not taken from filesize by any chance Dec 01 14:00:17 qschulz thanks. I wasn't actually aware of that, I must be blind as I missed that in the BSP layer. I thought u-boot was never adopted for the RPi. I'm so out of the loop. Dec 01 14:00:29 qschulz: for us it was a lack of bootm_size and presence of both fdt_high and initrd_high, which caused overlap when fit was loaded. Dec 01 14:00:57 zandrey: but you had loadadd and entrypoint set in your its? Dec 01 14:01:57 zandrey thanks as well, I was playing around with different partitions and changing the desired rootfs partition in the cmdline. Dec 01 14:04:26 zandrey: I remember there's a magic value for fdt_high and initrd_high, (0xffffffff?) to tell to not reloacte IIRC? Dec 01 14:05:12 qschulz: for loadaddr and entrypoint - iirc kernel-fitimage does set it correctly. Dec 01 14:05:37 zandrey: we manually craft our fitimage so can't say :/ Dec 01 14:05:52 I set IMAGE_BASENAME , but tar fails of image , "Cannot stat: No such file or directory" - should I clean something to make it rebuild or is there something that doesn't quite handle it ? Dec 01 14:06:12 fdt_high and initrd_high are exactly where the issue was - it was not relocating, but instead - uncompressing in place. ;) Dec 01 14:06:26 which ended up is a overwritten image Dec 01 14:07:08 "dd: unrecognized operand my-image-dev.ext4" Dec 01 14:08:29 bitbake my-image -c cleansstate ? Dec 01 14:09:07 kernel-uboot.bbclass does compression on aarch64 kernels, hence during execution of bootm it was nuked Dec 01 14:11:19 nevertheless, this is fixed in 2020.10, so i was wondering if you also hit this case with your fit image. but it actually depends on several setup factors like ARM architecture, board config, kernel compression defined in ITS... Dec 01 14:12:45 yeah, gzipped here on arm and aarch64 Dec 01 14:13:03 the issue either never happened or was handled before I joined the company Dec 01 14:13:05 qschulz, the variable should be IMAGE_NAME Dec 01 14:13:16 then it doesn't break things lol Dec 01 14:14:33 qschulz: lucky you! :D Dec 01 14:17:00 zandrey: currently upgrading from 4.14 to 5.4, not painless ;) Dec 01 14:23:31 hey everyone. can somebody please help me to understand how does EXTRA_OECMAKE_append_xxx variables in bitbake recipes work? i.e. what is the 'xxx' part. example: http://git.yoctoproject.org/cgit/cgit.cgi/meta-zephyr/tree/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc#n18 Dec 01 14:26:03 wz: _xxx means do whatever is before the _xxx only when the build is marked for xxx Dec 01 14:26:05 wz: xxx is MACHINEOVERRIDES Dec 01 14:26:08 I'm trying to add support for building more BSP with meta-zephyr, as for now it supports only arduinos and qemu. my first target is 96boards nitrogen and I've already identified I have to clone missing Nordic HAL sources and point cmake to it. I'm trying to mimic how it's done with cmsis, but HAL can't be included in non-nrf boards builds, hence I guess a similar trick with EXTRA_OECMAKE_append_ is Dec 01 14:26:10 needed, but with something different than 'arm'. Dec 01 14:26:19 https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-MACHINEOVERRIDES Dec 01 14:26:26 xxx can come from OVERRIDES or class-target, or things like that Dec 01 14:26:40 mckoan: actually more variables than MACHINEOVERRIDES but yeah :) Dec 01 14:27:01 ok, that sounds like a missing piece in the puzzle, thanks! Dec 01 14:27:09 qschulz: yes, my fault, actually is OVERRIDES that usually includes MACHINEOVERRIDES Dec 01 14:27:32 wz: you're entring the rabbit hole Dec 01 14:29:33 @mckoan can't wait to see more funny stuff Dec 01 14:31:00 wz: you are starting with tough stuff Dec 01 14:32:21 https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-OVERRIDES Dec 01 14:38:13 not quite my own choice, but I can handle it :) Dec 01 14:39:56 wz: you'll thank me later but if you ever modify MACHINEOVERRIDES, TRIPLE check the value of MACHINEOVERRIDES with bitbake -e because I can almost guarantee you it's in the wrong order ;) Dec 01 14:40:28 (sometimes it can be ignored, because... context. Sometimes it makes you pull your hair for hours ;) ) Dec 01 14:44:41 if i issue: `opkg install ./local_file.ipk` , can i make opkg resolve deps from a specified dir where many packages reside? Dec 01 14:45:01 (possibly not yet installed packages) Dec 01 14:53:50 qschulz: thanks for the bitbake -e tip, I can see that there are some values in my MACHINEOVERRIDES and they seem to make sense. adding them to EXTRA_OECMAKE_append_ does not have any effect, but now at least I have something to debug. thanks! Dec 01 15:12:04 paulbarker: i'm attending the osfc conference and won't be at today's project call Dec 01 15:12:36 tlwoerner: No problem, I'll load up on some coffee and take some notes Dec 01 15:13:47 add yaml as an input to your project they said .. sure that'd be easy. until you have to dump it again and the python yaml dumper/representer stuff is the most complex thing I've ever seen. Dec 01 15:13:57 * zeddii shakes his fist and wanders away Dec 01 15:15:49 zeddii: are you using ruamel's? or the official python lib? Dec 01 15:16:09 zeddii: should have used json :) Dec 01 15:16:35 * RP hides behind the flameproof shield Dec 01 15:16:37 just the official lib. I can't bring in dependencies very easily. Dec 01 15:16:38 hahaha Dec 01 15:16:55 zeddii: it's super outdated IIRC, does not support YAML1.2 right? Dec 01 15:16:57 the ruamel dude is super prolific hawking his wares on all the forums though Dec 01 15:17:12 I don't have any need for 1.2, but yes, it only has partial support. Dec 01 15:17:28 YAML is the best of a lot of sub-par options.... I don't know if expressing structure configuration will ever be "easy" Dec 01 15:17:49 try device trees, and then complete subsystem representations in yaml Dec 01 15:17:58 At least, it's the best when it has to be both machine and human readable (with emphasis on the latter) Dec 01 15:17:59 and then having to go back and forth between device trees and yaml Dec 01 15:18:16 JPEW: indeed, that's why they landed on yaml. Dec 01 15:18:24 toml isn't bad. lacks some of the flexibility of yaml, but that's not necessarily a bad thing. not a fan of yaml's references myself Dec 01 15:18:25 * kergoth yawns Dec 01 15:18:30 zeddii: What is it for? Dec 01 15:18:44 Lopper my other open source hacking for Xilinx. Dec 01 15:18:51 Device Tree evolution project. Dec 01 15:19:01 zeddii: Ah Dec 01 15:19:47 kergoth: references are one of those things that you need to use sparingly, but when *must* use them, they are pretty good Dec 01 15:20:00 kergoth: They are easy to abuse though Dec 01 15:20:11 * kergoth nods Dec 01 15:21:13 * zeddii makes the executive decision to say "your sequences will be expanded if you write the yaml back out", and someday will poke at ruamel since it may help. Dec 01 15:21:33 * zeddii has patches to merge .... and will do that instead Dec 01 15:22:55 related: https://github.com/tomwright/dasel is awesome when doing quick scripts Dec 01 15:29:23 fancy! Dec 01 15:38:09 kergoth: https://xkcd.com/927/ Dec 01 15:39:02 "Say good bye to learning new tools..." [...] "This means that once you learn how to use dasel" :shrug: Dec 01 15:39:41 paulbarker: awesome, thanks! Dec 01 15:43:47 eh, dasel doesn't implement a new configuration standard, it fills in a gap. jq is invaluable, but only for json. yq works, but that's just for yaml. and both of those are less easy to use to update rather than query. if i want something to query and update toml files, there isn't anything else that i've found Dec 01 15:44:07 now there's an argument to be made that if your script is complex enough to need to futz with those it's time to rewrite it in python, but that's not always workable :) Dec 01 15:45:33 kergoth: was just scratching an itch of mine, I don't even know what's the use case for that :p Dec 01 16:05:17 zeddii: any luck with k3s? Dec 01 16:10:22 no. I've done a round of updates on all the components, still nothing. I'm going to focus on the log failure today/tomorrow (hopefully it won't be that long), since without those logs the debug is super random. Dec 01 16:11:06 zeddii: the log symlink issue? Dec 01 16:11:45 yah. unless you figured out another way to query those busted containers for what is really going on. journalctl is worthless. Dec 01 16:12:10 zeddii: k9s showed some events, but not anything that really helped Dec 01 16:12:48 zeddii: which would be the same that kubectl events foo shows (I forget the syntax) Dec 01 16:13:39 JPEW: did you get keadm working? Curious why all of that is commented out on kube-battlestar-cluster Dec 01 16:14:18 moto-timo: I juts got it working last night Dec 01 16:14:29 It's.... unforgiving Dec 01 16:16:26 JPEW: I set up a rpi4 as labgrid-controller... but I want to ansible the setup. This on top of the raspbian 64-bit beta Dec 01 16:21:29 moto-timo: Ah cool. I was going to try using kubeedge to orchestrate the labgrid containers on raspbian Dec 01 16:21:49 ... of course, there are no ARM labgrid containers :( Dec 01 16:24:03 JPEW: are you using rpi4 or rpi3 for the edge nodes? Dec 01 16:24:10 rpi4 Dec 01 16:24:19 cool Dec 01 16:24:36 sadly pi0 is no longer supported by k8s (armv6) Dec 01 16:25:08 I would only have tried to run k3s on it, but pi0 cluster would be super inexpensive Dec 01 16:25:20 unlike the rpi4 cluster I just ordered (8 rpi4 8gb) Dec 01 16:26:17 moto-timo: the 512M on the pi0 doesn't become an issue? Dec 01 16:26:33 smurray: it would for etcd most likely Dec 01 16:26:54 smurray: but you can't even build for armv6 anymore, so academic... unless you want to revert to k8s 1.6 Dec 01 16:27:01 * moto-timo does not ;) Dec 01 16:28:36 moto-timo: heh Dec 01 16:33:53 moto-timo: on k3s, I admit to feeling a bit abandoned by the submitter on getting the final issues worked out. If I wasn't already working on the support myself, I would have chucked it all in the bin by now. Dec 01 16:34:37 RP: like new kernel and libc headers :D Dec 01 16:35:22 zeddii: k3s troubleshooting was not fun at all... and I don't think I got anywhere (other than a semi-ok recipe for k9s) Dec 01 16:45:48 Hey, I switched to using kas and reconfigured a couple of things. Unfortunately, dnf complains about not finding a `repomd.xml` file when I try to upgrade packages on my target device. I tried running the 'package-index' command but that didn't generate that file either. Which flag do I miss setting here? Dec 01 16:47:30 rburton: not really, glibc patch upstreaming is in my long list of things to do Dec 01 16:47:43 Ah I think I found the mistake. I ran the `package-index` command on the wrong project *blush* Dec 01 16:51:03 ... hmm... no that was not the issue Dec 01 16:58:23 from wiki: The Year 2038 problem (also called Y2038, Epochalypse ... -- ugh, the Epoch-alypse! Dec 01 16:59:38 * paulbarker facepalms Dec 01 17:01:36 man, when time hits, steven nukes us hard! Dec 01 17:19:20 no soup for you! Dec 01 20:45:32 Hello all, what's the best way to assign permissions on files in /dev in Yocto? I'm integrating pulseaudio and I want to change the ownership of /dev/snd/* to root:audio before the system starts up. I tried to run chown root:audio /dev/snd/* at boot via an initscript, but that's not reliable. Dec 01 21:44:59 rob_gries: I think probably udev scripts would be the best way to achieve that (not Yocto specific) Dec 01 21:45:22 or rather udev rules Dec 01 21:47:08 once you have a rules file you'd just need to create a recipe to install it into the appropriate location (i.e. ${D}${sysconfdir}/udev/rules.d in do_install) Dec 01 22:02:05 bluelightning: Thanks that makes more sense. Dec 01 22:34:43 are you kidding me? the one time I don't attend the weekly yocto call and bluelightning shows up?! Dec 01 22:34:45 (lol) Dec 01 22:35:10 tlwoerner: heh... I have been in the last couple also I think Dec 01 22:35:24 time changes made it possible Dec 01 23:13:27 agh, knew i was forgetting something Dec 01 23:34:46 is this the right channel for bitbake support? I'm doing a yocto build that requires a credentials-protected docker image. In other words, bitbake needs to perform a docker login before a docker pull Dec 01 23:35:11 does anyone have an example for this? What about credentials exposure? Dec 01 23:48:02 I'm not sure how that would work.. Dec 01 23:48:17 other things that require credential support have alterantive methods, but those are SCM, https, etc connections Dec 01 23:50:56 you could whitelist an environment variable and pass it into the build that way Dec 01 23:51:35 environment is the bestway to handle this, if the code supports it Dec 02 00:16:56 so I wrapped everything in withCredentials( [[ ]] ) inside my jenkinsfile. should work Dec 02 00:17:07 thanks for the hints guys :-) Dec 02 01:49:49 moto-timo: Ah, I *finally* got it working! I'm using KubeEdge to attach a raspberrypi 4 as a edge node to my Kubernetes cluster, and then deploying the labgrid + pdudaemon containers on it **** ENDING LOGGING AT Wed Dec 02 02:59:57 2020