**** BEGIN LOGGING AT Thu Apr 08 02:59:57 2021 Apr 08 07:57:45 yo dudX Apr 08 07:59:16 morning LetoThe2nd Apr 08 09:34:31 mornin folks Apr 08 10:16:58 by the way, everybody: https://pretalx.com/yocto-project-summit-2021/cfp Apr 08 10:40:30 is it live or recorded talks as it was for ELC/ELCE IIRC? Don't like the Zoom part of the conference :| except if Zoom is working ok directly from the browser? Don't know the current status of the tool Apr 08 10:44:21 AFAIK it will be live via zoom (interactive) and youtube (non-interactive) again, but it is not yet set in stone. Apr 08 10:44:48 LetoThe2nd: is always difficult to find a subject really useful Apr 08 10:46:36 mckoan: i don't really think so. sure, if the POV is "i want something cool for all the experienced ones who already were at the last 10 ypdds" then its rather hard. but i don't think that this is the majority of the audience. Apr 08 10:49:55 LetoThe2nd: basically, my question is from the PoV of a speaker, do I need to use Zoom :p Apr 08 10:51:22 qschulz: "probably yes". but if you've got a good topic and are willing to prerecord to avoid, then i think that can be negotiated. Apr 08 10:56:22 i mean... YPS is not fosdem, we don't have to manage hundreds of speakers. i think we can care for personal needs and wishes on a case by case basis if it helps the overall event. Apr 08 10:57:59 I'll try to find something to say. I probably will talk about the override (OVERRIDES, _append and all) mechanism from user perspective since it seems to be a recurring topic on #yocto and at my work Apr 08 10:58:14 +1 Apr 08 10:59:03 and maybe the debugging techniques with Yocto but that took me almost 3h when I presented it in my company.... oopsies Apr 08 11:00:25 LetoThe2nd: basically, harass me until I prospose a talk :D Apr 08 11:02:02 qschulz: i hereby define that you owe me a beer for each day until i see a submission by you! Apr 08 11:04:06 qschulz: zoom works fine from the browser. Apr 08 11:04:33 LetoThe2nd: that's... brutal Apr 08 11:05:07 ndec: 👍 thx Apr 08 11:06:09 and we are aware that zoom is not ideal, and we don't like it much neither... we are going to try to find an alternative.. but it's not like we have a lot of 'free' time to work on these things.. Apr 08 11:06:36 qschulz: well you said "harass"! Apr 08 11:06:38 the reason why we've picked zoom so far, is that because it has worked well for the last 2 events.. Apr 08 11:09:50 ndec: the LF was using proprietary SW for ELC/ELCE too, I would have expected them to figure this one out (e.g. Jitsi or similar) and do some load testing etc... I obviously don't expect YP to try this on their own ;) Apr 08 11:10:37 ndec: anyway, I guess in a year or so it'll be history and nobody will care about finding a video conferencing SW since I guess most conferences will be in-person again Apr 08 11:10:57 i'm not soo convinced there. Apr 08 11:11:29 qschulz: I would love to see an OSS video conf platform provided by LF.. ;) Apr 08 11:12:41 i have a secret plan for video conference world domination: now that MS is platinum member, we just have to get them to host YPS on teams. Apr 08 11:12:44 muahahahaha Apr 08 11:12:59 LetoThe2nd: I'm genuinely surprised they didn't use it for ELC/ELCE Apr 08 11:13:52 but I guess they didn't want to start again the whole "Microsoft is buying the LF to destroy Linux/FOSS" narrative Apr 08 11:13:58 VERY wild guess :p Apr 08 11:14:53 joke aside. my experience with teams is not perfect, but pretty good. i don't see it fit too well for a one-off thing, but more for ongoing training sessions. politics and narratives aside too, i like working on it. Apr 08 11:17:40 and once i get access to twitter spaces, i'll babble the s**tz out of it, hopefully :P Apr 08 11:21:04 well Teams works in the browser too :) Apr 08 11:22:26 yup. Apr 08 11:27:30 For building an image for compute module 4, what should the MACHINE variable be in local.conf Apr 08 11:28:47 prajvalsh: are you sure it's already supported? Apr 08 11:29:35 prajvalsh: pick your poison: http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/conf/machine Apr 08 11:29:36 prajvalsh: ok, it seems it is. raspberrypi4-64 should be used IIUC Apr 08 11:29:57 prajvalsh: c.f. https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/conf/machine?id=0c85f0150629e1f5eaf86289f2542744e38b5413 Apr 08 11:43:26 LetoThe2nd:qschulz:Thank you. I have built the image using MACHINE variable as raspberrypi4-64 using core-image-base. I have not been able to get the usb ports working on the cm4 after using ENABLE_DW2_HOST="1" in local.conf file. I am using the dunfell branch. Apr 08 12:45:14 prajvalsh: what do you get running -> # dmesg | grep -i usb Apr 08 12:59:34 mckoan:I have to ssh to the device and see the message as I am not able to use the usb ports on cm4. Apr 08 13:01:22 prajvalsh: don't you have access to the console via, e.g. the microUSB port? Apr 08 13:01:34 or one of the exposed pins? Apr 08 13:01:53 well, two of the exposed pins since you need at least RX/TX Apr 08 13:33:37 one thing i think the project could really use, is to have more people who understand "the guts" of the system Apr 08 13:34:15 for YPS i'm hoping that some of the people who have worked on internals might be persuaded to give talks, or better yet, hands-on classes on "internals" things Apr 08 13:35:18 my preference is for live talks, and interaction. otherwise we're just curating a list of youtube videos. but in the end *content* is the most important thing Apr 08 13:36:01 so if we get good content from pre-recorded talks, then so be it :-) Apr 08 13:37:03 yeah thats what i mean. it shouldn't be the preference, but if somebody with a good proposal says "i can only do it prerecorded and am there for discussion", then i would go with that. Apr 08 13:37:46 the best feedback we get is often from the hands-on classes, they have a lot of impact. getting someone to interact and actually do something during the conference really helps Apr 08 13:38:24 (i.e. getting the audience to interact and do things during a presentation helps them understand things better, i think) Apr 08 13:39:48 yeah. that should be certainly mandatory. if a (hypothetical) presenter is only up for throwing a video over the wall, then YT is a better place for it directly. Apr 08 14:28:17 when yocto is building other tools, e.g., running a configure script, does it prebuild its own programs (e.g., bison)? if so, where in tmp are these kept? Apr 08 14:29:26 i assume it does not use the host's install of such tools Apr 08 14:35:21 recipe-sysroot-native Apr 08 14:39:05 yates: you add the tools needed at build time which run on the host to DEPENDS in their native variant (recipe name + "-native") Apr 08 14:44:41 how can I debug a problem with gitsm fetcher? I've tried bitbake -v -DD but it's not giving me any clues as to what is wrong. I presume it runs 'git', how can I get it to dump out the actual command? Apr 08 14:45:37 rfs613: https://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/gitsm.py ? Apr 08 14:49:24 qschulz: yep, the "runfetchcmd" seems like a candidate to log. But my python-foo is weak... Apr 08 14:56:37 qschulz: looking at definition of runfetchcmd() in poky/bitbake/lib/bb/fetch2/__init__.py, it would seem that the 'cmd' already gets recorded by logger.debug() line 865. But I do not seem to see this in my output. Apr 08 15:00:58 rfs613: I think it goes up to three D for debug level in bitbake? don't know honestly Apr 08 15:02:13 qschulz: looks like I am becoming a python developer today... I think I've determined that it isn't calling runfetchcmd() at all. I added an earlier logger.debug(1, "test") and that showed up in the output. Apr 08 15:41:29 so, this is strange... it seems to be calling Git.unpack(), which is failing, because it has not actually cloned yet. In the downloads/git2 folder, there is a reponame.git.lock file, but no actual repo. Likewise the clonedir location does not exist yet. Apr 08 15:42:18 i've tried doing bitbake -c do_fetch -b recipe.bb, this gives no error, but doesn't seem to download anything. Apr 08 15:54:52 -c do_fetch -f Apr 08 15:55:04 or -C do_fetch IIRC should be the same Apr 08 15:59:23 ok, that got it to do git clone of the repo. Now it's failing with similar error on the submodule repos. Apr 08 16:06:20 Hey folks, has anyone tried `bitbake-selftest` on master today? Apr 08 16:06:34 I'm getting an error in the npm fetcher tests Apr 08 16:07:32 `test_npm_registry_alternate` tries to pull from registry.freajs.org which looks to be a parked domain rather than anything active Apr 08 16:18:30 I was interested in using yocto to build myself just a compiler (gcc x86_64, no cross compiling.) I thought about just getting poky set up, then adding a layer to override the default gcc SRC_URI, then bitbaking just the gcc-native recipe. Is this a waste of time compared to just downloading bitbake and maybe trying to copy out the open-embedded gcc recipe? Apr 08 16:25:39 JPEW: my diffoscope of a 300mb rootfs has been doing for the entire duration of the triage call Apr 08 16:26:49 I was going to rebuild a debian kernel package on a not-debian machine. So I don't need bitbake to actually build the kernel itself, the debian scripts will do that--except they depend on gcc and yacc and binutils etc -- I figured since there are already OE recipes for this stuff, it would be a good starting point, rather than me manually putting together some wget-and-build scripts. Apr 08 16:27:19 ecdhe: why can't you just use the not-debian compilers Apr 08 16:27:58 rburton: want a reproducible build so want the same exact gcc that debian is using Apr 08 16:28:41 but you're building a yocto gcc not debian gcc Apr 08 16:30:46 if you want to use the exact gcc that debian has, use a debian container Apr 08 16:31:07 rburton: It's the recipe I'm after. I can update the SRC_URI of the compiler to make that match. I can update the SRC_URI for compiler dependencies such as libc as well. Apr 08 16:31:27 what about all the patches, and all the options Apr 08 16:31:38 i just fail to see the point Apr 08 16:31:48 rburton: patches == more SRC_URIs Apr 08 16:32:37 rburton: the point is to build in a dissimilar environment for a verification of the output Apr 08 16:34:04 ecdhe: if you want to build something on debian from non-debian, why not just build it in docker or so? Apr 08 16:34:15 also there is no gcc-native recipe Apr 08 16:34:49 i dont' see what you gain by painfully writing a recipe to build debian's compiler/libc with all their options and patches Apr 08 16:37:28 you could also just install dpkg on eg RHEL and rebuild the debian gcc package Apr 08 16:38:19 kergoth: the goal is a dissimilar environment to verify a reproducible build. Same source to both dissimilar systems should produce the same output. A single difference in the output represents a failure in configuration management of the build system. Apr 08 16:43:22 rburton: thanks for pointing out that there's no gcc-native recipe. I may just forget yocto and make my own bitbake recipe directly then. Apr 08 16:43:56 if you want the debian compiler then just reuse the debian compiler Apr 08 16:45:41 rburton, I'm looking to build the linnux kernel in a not-linux system+environment Apr 08 16:45:54 hence the need to build gcc Apr 08 16:46:04 Just looking to leverage existing recipes for that Apr 08 17:25:46 fray seebs RP and anyone else interested: pseudo patch on the list. comes with a test case! Apr 08 17:26:24 which list? Apr 08 17:26:56 oe-core as instructed in the readme :) Apr 08 17:27:16 you can't just do things correctly Apr 08 17:27:18 it confuses us Apr 08 17:27:46 haha Apr 08 17:27:54 right i'm outta here now Apr 08 17:28:12 a vague thought: if i were gonna do an overhaul in pseudo, i think, at this point, the candidate would be "length-counted string implementation" Apr 08 17:28:18 because we have so much strlen Apr 08 17:28:27 lets just rewrite it in rust Apr 08 17:28:45 i think in the mid term pseudo may be doomed because, e.g., Go programs don't use libc Apr 08 17:29:08 and a thing that was going to intercept syscalls in some other way would have to look quite a bit different. Apr 08 17:29:10 seebs: FWIW I did look through this with rburton and I think it was a bug I introduced with the ignore path stuff Apr 08 17:55:36 Is beaglebone(-yocto) known to work with GPT? Apr 08 18:18:30 hi, I want to debug the kernel with kgdb. But I cannot find the kernel with debug symbols within the yocto FS (No debugging symbols found in vmlinux-5.4.72-v7) Apr 08 18:27:12 argonautx: the kernel is typically not included in the rootfs, because kernel has to get loaded into memory first before rootfs is mounted. Apr 08 18:28:44 try looking in your build directory for "vmlinux", you should find an kernel there with symbols. Apr 08 18:31:00 by FS I mean the filesystem behind the build directory, particulary unter build/tmp Apr 08 18:33:02 argonautx: yup, somewhere under there will be the directory where kernel got compiled. And in that directory should be vmlinux ELF format with symbols Apr 08 18:35:42 I tried it under build/tmp/work/raspberrypi3-poky-linux-gnueabi/linux-raspberrypi/1_5.4.72+git.../image/boot Apr 08 18:36:06 and all the other vmlinux* files which are ELF binaries Apr 08 18:36:29 I used the gdb from poky toolchain Apr 08 18:36:44 . /opt/poky/3.1.6/environment-setup-cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi Apr 08 18:36:54 $GDB vmlinux-5.4.72-v7 Apr 08 18:37:47 I can load the kernel into gdb but non of them have debugging symbols Apr 08 18:37:58 seems reasonable, though I don't have experience with the rpi kernel myself. Apr 08 18:38:26 have you tried "file vmlinux-5.4.72-v7" to see what it says? Apr 08 18:38:48 rburton: Hmm Apr 08 18:39:11 sure find with -exec file to sort out the actual kernel binaries Apr 08 18:39:28 rburton: Ya, it's probably pretty intensive to diffoscope a rootfs image Apr 08 18:40:47 rburton: Although, it might be a lot faster if we limit the depth to 1 or 2; I don't think there is any reason to have diffoscope recurse into archive formats inside the rootfs; those *should* all be found when we diffoscope the packages Apr 08 18:40:56 argonautx: it should say something like: vmlinux: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped Apr 08 18:42:03 vdl: I've only booted that SoC with MBR Apr 08 18:43:45 rfs613: correct and I found 3 places where I found a kernel with exact this description, there is no stripped kernel at all Apr 08 18:45:37 JPEW: ok. I'll look into the SoC "raw" boot mode. Apr 08 18:46:10 vdl: OK. FWIW, I've never used that either; only MBR + FAT boot Apr 08 18:46:29 argonautx: do you have CONFIG_DEBUG_INFO enabled? Apr 08 18:48:18 rfs613 in local.conf? No.... Ahhhaa Apr 08 18:48:22 JPEW: I know bbb can boot "raw" at offset 0x20000 and 0x60000 but I don't know if the (barebox or u-boot) MLO needs particular tweaks for that. Apr 08 18:48:30 argonautx: in your kernel config, yes Apr 08 18:54:17 i'm getting the following toaster error: http://paste.ubuntu.com/p/DYxWnG2Kn4/ Apr 08 18:54:27 is this a known problem? Apr 08 18:54:56 is my python version (3.6.9) too old? Apr 08 18:56:15 rfs613: where is this file? there is a tmp/work-shared/raspberrypi3/kernel-source/arch/Kconfig but no .config Apr 08 18:57:14 argonautx: there will be a .config in the kernel build directory (same places as the vmlinux file) where you can check the setting Apr 08 18:58:11 argonautx: of course this is no the master copy, unfortunatley. IN yocto recipe you may specify a kernel config and possibly additional fragments that all get blended together. Apr 08 19:02:15 this occurred after attempting to create a new project by importing from an existing command line project. Apr 08 19:10:35 there was only one .config in tmp/work/raspberrypi3-poky-linux-gnueabi/linux-raspberrypi/1_5.4.72+gitAUTOINC+5d52d9eea9_154de7bbd5-r0/linux-raspberrypi3-standard-build Apr 08 19:11:46 and it has CONFIG_DEBUG_INFO disabled Apr 08 19:14:43 argonautx: okay, so the setting you need is off ;-) Now .config is a generated file, so you get to track down how it has been generated, in your configuration Apr 08 19:15:41 well I did bibake -c menuconfig virtual/kernel and switched it on Apr 08 19:16:11 oh cool, so hopefully that should toggle it in the .config file Apr 08 19:53:23 rfs613: thank you Apr 08 20:10:05 argonautx: welcome Apr 08 22:08:14 is there any reason core-image-tiny-initramfs does not list arm* in COMPATIBLE_HOST? Apr 08 22:52:18 i'm doing a "bitbake -c populate_sysroot example" with buildhistory enabled and get this: http://paste.ubuntu.com/p/4FwnFrzSx8/ Apr 08 22:52:31 what is the difference between glibc and libgcc Apr 08 23:09:43 how can i find the url's of the packages my recipe is fetching? i do not see them in the build history "packages" Apr 08 23:09:48 .. folder Apr 08 23:10:06 and as my build errored out, there aren't any other folders Apr 08 23:11:06 well, that's not true - there is buildhistory/metadata-revs file, but it does not contain urils Apr 08 23:28:15 yates: so many questions :-) Apr 08 23:28:35 glibc is the runtime for C code - functions like read() write() printf() Apr 08 23:29:32 libgcc is an extra library provided by compiler to backfill some functions that not all CPUs have, such as 64-bit math routines (on 32-bit hardware) Apr 08 23:29:47 soft float Apr 08 23:30:12 rootbeer float Apr 08 23:30:12 yeah that too I guess Apr 08 23:30:27 moto-timo: with ice cream, I'll take two :) Apr 08 23:30:35 :) Apr 08 23:41:03 rfs613: ok, thanks. Apr 08 23:41:20 what about getting the fetched url's ? Apr 08 23:42:31 allow me to provide my top-level issue: i am trying to build the toolchain for a new architecture (csky) and "bitbake -c populate_sysroot example" is crapping out in the libgcc do_configure. i'm trying to determine why Apr 08 23:44:03 i mean, i know it's in the creation of some largefile-blah.h target, but exactly which libgcc is this, and how does it relate to the csky binutils or other foundational components for csky. Apr 08 23:55:20 and which Makefile is giving the error? Apr 08 23:56:19 dunno sorry....if nobody has done this yet for yocto, it may be a tough slog. Have you looked at crosstool-ng ? Apr 08 23:56:51 what is crosstool-ng? a irc channel? a project? a new rootbeer? Apr 08 23:57:29 lmgtfy: ... Apr 08 23:57:47 oh yeah... Apr 08 23:58:03 i actually used that some 5 years ago. it was horrible back then. Apr 09 00:02:40 there is a buildroot project for it, but i thought, if i want this to work under yocto i had to get the yocto toolchain version of it to build.. Apr 09 00:06:14 buildroot has the option of using crosstool. Apr 09 00:06:35 Crosstool is for building a toolchain. Apr 09 00:07:57 Yocto and buildroot also do that, and use the toolchain to compile lots of other stuff, producing a root filesystem, kernel, bootloader, etc. Apr 09 00:08:00 yes, but that gives you the binary. how would you "graft" that toolchain binary into yocto? i thought it needed to build it for the sdk Apr 09 00:09:36 don't know yocto well enough to answer... I was thinking more that you could look at crosstool-ng (if it supports you csky arch) and use that to build up yocto support. Apr 09 00:10:09 yeah, not a bad idea. but i enjoy beating my head against the wall first. Apr 09 00:10:16 In other words use it for inspiration... Apr 09 00:10:20 til i'm sufficiently bloody Apr 09 00:10:54 Oh with you're guaranteed some bashing when working in this area... Apr 09 00:38:50 vmeson, I got suricata 6 building with rust. code in master **** ENDING LOGGING AT Fri Apr 09 03:00:09 2021