**** BEGIN LOGGING AT Tue Oct 20 10:59:57 2020 Oct 20 11:19:58 * RP wonders if we'r ready for rc1 Oct 20 11:30:26 * RP fires a build Oct 20 11:31:54 RP: may all the lights turn green Oct 20 11:34:54 qschulz: lets hope so :) Oct 20 12:02:51 * RP thinks the buildbot server may have just died Oct 20 12:04:58 looks like most of the data centre machines and access gateway :/ Oct 20 12:06:47 * qschulz calling the fire dpt, we shouldn't have fired a build in the first place Oct 20 12:07:27 qschulz: firing builds is so much more satisfying that starting them ;-) Oct 20 12:08:26 cue Bloodhound Gang? Oct 20 12:38:39 is there some ad-hoc means to build tools-profile when linux-dummy provides the kernel? it borks out because being unable to build kernel-source Oct 20 13:04:54 Hi folks. When having a git archive with submodules in the download folder. Is their a way for the modules link, to be relative instead of full path on the filesystem Oct 20 13:05:51 E.g. in the downloads/git2//modules/ folder is a link to the module Oct 20 13:08:31 This has a symbolic link to the module, but instead of having it like ../../ it is created like /file/system/root/path/very/long/path/downloads/git2/ Oct 20 13:09:08 When using it in a docker setup, it can be an issue. Oct 20 13:09:33 Where the downloads and sstate is mounted in as a volume Oct 20 13:10:37 Something like "docker container run -t -i --rm -v /path/to/storage/yocto/:/opt/yocto/ ..." Oct 20 13:11:35 hmm, all came back... Oct 20 13:13:47 hello, I have linux manjaro at work and I want to start yocto again. So I am thinking of creating a debian filesystem for chroot with qemu static and work yocto in there, does it sound like a bad idea? Oct 20 13:14:27 kayterina: you could use one of the container images there exists though (pyrex or crops IIRC) Oct 20 13:14:45 definitely just use crops or pyrex Oct 20 13:20:49 zeddii: already awake? could need a pointer. Oct 20 14:25:27 * RP hands LetoThe2nd a * Oct 20 14:36:07 I'm trying to reuse sstate for building an eSDK, and just discovered that binutils-crosssdk:do_configure depends on DISTRO_VERSION - that sounds like a bad idea, right ? Oct 20 14:37:28 we surely don't want to rebuild a new binutils (and I guess all the nativesdk) for every dot-release of a distro, right ? Oct 20 14:39:01 where is that referenced? Oct 20 14:39:54 I guess that would be meta/classes/toolchain-scripts-base.bbclass: echo 'Distro Version: ${DISTRO_VERSION}' >> $versionfile Oct 20 14:41:10 not sure though Oct 20 14:49:24 target_exec_prefix and such use ${SDKPATHNATIVE} -> ${SDKPATH} -> ${SDK_VERSION} -> ${DISTRO_VERSION}, that sounds better like a do_configure influence Oct 20 14:50:10 RP: hrhrhr Oct 20 15:00:51 shouldn't this be neutralized, since the SDK are relocatable anyway ? Shouldn't we drop SDK_VERSION from SDKPATH, and only have SDK_VERSION added at SDK relocation time ? Oct 20 15:01:17 sounds sensible Oct 20 15:01:50 Hello all, is it dirty to put PREFERRED_VERSION inside an image recipe ? Oct 20 15:02:14 Ninic0c0: it won't work Oct 20 15:02:46 ok that's confirm test. Thx Oct 20 15:03:01 Ninic0c0: https://www.instagram.com/p/CBgEgS_jXTD/?utm_source=ig_web_copy_link Oct 20 15:03:03 Ninic0c0 sing with me recipe data is local, conf data is global Oct 20 15:03:12 LetoThe2nd: damn, too slow Oct 20 15:03:36 Nice guys thx for support :) Oct 20 15:04:06 Hi Oct 20 15:04:21 Does anybody know we we need a host gcc installed to install the extensible SDK? I thought we avoid host gcc dependencies with uninative. Oct 20 15:04:38 why we need Oct 20 15:06:33 RobertBerger: uninative doesn't avoid gcc, buildtools does Oct 20 15:06:50 RobertBerger: eSDK could avoid host gcc if buildtools is installed Oct 20 15:08:03 RP: you mean when I install the SDK. Oct 20 15:09:32 RP: Wait so what you say is, that I need to install x86_64-buildtools-nativesdk-standalone-3.1+snapshot-20201020.sh manually? Oct 20 15:11:23 RP: My point is that we use the uninative tarball to avoid host gcc dependencies while building. But when installing the SDK we need a host gcc. Oct 20 15:12:14 uninative abstracts the host *glibc* Oct 20 15:13:49 @rburton, so it's not really about getting rid of the host gcc in the build process. Oct 20 15:14:40 grep show, that both the extensible SDK and the "classic" SDK do something with buildtools. Oct 20 15:15:26 RobertBerger: correct, uninative allows the same binaries to run on systems with a different OS, its a glibc abstraction Oct 20 15:15:46 RobertBerger: for gcc, you need buildtools Oct 20 15:15:49 @RP OK - understood Oct 20 15:16:10 I do have buildtools Oct 20 15:16:32 ls *.sh Oct 20 15:16:32 poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-3.1+snapshot.sh x86_64-buildtools-nativesdk-standalone-3.1+snapshot-20201020.sh Oct 20 15:16:32 poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-ext-3.1+snapshot.sh Oct 20 15:18:54 This is what the extensible SDK needs: for util in diffstat bzip2 gzip gawk cpio perl file which gcc g++ Oct 20 15:19:51 RobertBerger: eSDK should be no different to the main build Oct 20 15:20:50 Well it could be that it has similar host requirements than oe/poky/bitbake in order to use the devtool. Oct 20 15:21:21 Most likely it does not bring everything needed with it. Oct 20 15:22:04 RobertBerger: Its not designed to bring everything Oct 20 15:23:13 So all this slowly starts to make sense then to me - kind of. Oct 20 15:24:18 I just this is nasty thing and it starts to install: sudo touch /usr/bin/gcc Oct 20 15:24:29 but not for long ;) Oct 20 15:25:16 RobertBerger: note that "buildtools" contains some tools, you need "buildtools-extended" to contain gcc Oct 20 15:26:07 hmm OK Oct 20 15:30:00 So if I really wanted to I could hack things to use buildtools-extended instead of buildtools for the extensible SDK in order to avoid more host dependencies. Oct 20 15:33:20 shouldn't it be enough to throw the native tools into nativesdk-packagegroup-sdk-host.bbappend to end up in the SDK? But then it might be a chicken and egg problem. Oct 20 15:40:57 I'll built the buildtools-extended tarball and see what happens if I try to install this ;) Oct 20 15:43:39 RobertBerger: I think extended should do what you're looking fod Oct 20 15:43:43 for Oct 20 15:50:21 we'll be live in 10 minutes on https://www.twitch.tv/theyoctojester - time to get confy and find a drink! Oct 20 15:50:43 LetoThe2nd: hurray! Oct 20 15:51:37 fray: did you find a minute to have a peek at the spdx patches for crosslink, so we can get some feedback out? Oct 20 15:52:03 I've been swamped with work and some other (non-work) stuff.. I hope I'll be freed up soon. Oct 20 15:52:20 I've got that patch and one from Mentor that need to get reviewed/merged. Oct 20 15:54:11 fray: i think it would also be ok if you can just drop a line saying "i'm the maintainer, i received it, will take some time". this came through the outreachy stuff and it would be awesome if we could keep the motivation up! Oct 20 16:00:31 YPTM: trevor is on Oct 20 16:04:52 JPEW: Trying to get gdb-cross-canadian on mingw to use a prebuilt python tarball, and the gdb executable immediately exits with no output. Any insight? I'm assuming it's failing to import it at runtime, but without any output or response to --help or anything, it's tough to diagnose. Do you happen to know if there's something like strace for windows executables or somethign? Oct 20 16:05:39 kergoth: Are you running on actual Windows or on Wine? Oct 20 16:05:49 actual windows, but i could use wine if that provides anything useful Oct 20 16:06:06 kergoth, I had reports of that on a baremetal toolchain, but also reports of python (nativeSDK) working on mingw [the bundled one] with Linux Oct 20 16:06:20 kergoth: No. A few things don't work on wine for some reason, so I always check Oct 20 16:06:25 ah Oct 20 16:08:12 kergoth: It's been a while since I did any debugging... I know there are tools, but I can't recall what theya re Oct 20 16:08:25 the python binary itself works fine, and can import its standard library modules, just gdb fails to run Oct 20 16:08:27 khem: can't replicate the optee problem with musl. was that musl+gcc or +clang? Oct 20 16:08:30 np, just thought i'd check Oct 20 16:09:29 rewitt: will you push the arm64 crops images to the official repo? Oct 20 16:15:07 Are there tools or scripts that people have used to read the bitbake event log? Oct 20 16:15:31 Ideally, something that already filters the event types and depickles the event data. Oct 20 16:27:59 @RP I didn't get it work Oct 20 16:30:43 @RP what i tried was to install x86_64-buildtools-extended-nativesdk-standalone-3.1+snapshot-20201020.sh and source it Oct 20 16:31:02 and I tried to install the extensible SDK afterwards Oct 20 16:31:06 could not find gcc Oct 20 16:33:10 Sorry - my bad seems to install Oct 20 16:36:53 @RP: Wow this is nice, need to play a bit more, but this means less host dependencies for the developer! Oct 20 16:40:28 smurray: https://jaycarlson.net/embedded-linux/ Oct 20 16:49:31 tlwoerner: nice Oct 20 16:55:22 rburton: this is gcc+musl Oct 20 16:57:35 zeddii: w00t! more BSP layers converting! Oct 20 16:58:01 zeddii: your hard work is paying off :-D Oct 20 16:58:34 git merge monkey! Oct 20 16:58:49 zeddii: can you setup a cron to pull linus's commits/tags and push them to linux-yocto so it's always fresh? Oct 20 16:59:37 I have one that runs on my -dev machine. I check it weekly, but I could make master and */base automatic. Oct 20 17:00:02 rburton: i think there's more involved than just updating hashes, there are other things (perf) that need to come along with every update too Oct 20 17:01:17 I have a radioactive decay on old releases. weekly for current, bi-weekly for previous release, monthly for older and 6 monthly for really old stuff. (or when asked). Oct 20 17:02:32 tlwoerner: not recipe updates, just the git repo itself Oct 20 17:03:02 tlwoerner: eg at least once i've had to ask zeddii nicely to push linux-yocto because a platform team wants to use a release that is a day old :) Oct 20 17:04:11 hah. and I think that particular kernel is now EOL, or at least it didn't have updates when I did my last cycle last week. Oct 20 17:04:21 * zeddii will check again today. Oct 20 17:07:58 wow, a pohly Oct 20 17:08:27 zeddii: Unfortunately I have some pain-in-the-ass client and vendor requirements. If we can find a way to meet them with what's in oe-core I'd be very happy to help out as much as needed to make it happen Oct 20 17:10:41 rburton: I'll need to turn it on in travis, but my plan is to do it Oct 20 17:13:13 rewitt: thanks Oct 20 17:13:26 rewitt: ping when its done and i'll update my custom image Oct 20 17:34:43 rburton: another machine with qemuarm64/gcc/musl http://errors.yoctoproject.org/Errors/Build/111285/ Oct 20 17:35:04 khem: turns out the build i tested was n1sdp which doesn't build optee :) Oct 20 17:35:08 new build running now Oct 20 17:39:00 rburton: ok, if you want to avoid my eyes test on qemuarm64/musl :) Oct 20 17:44:37 Is there any way to build linux-yocto with an in-tree defconfig (I'm thinking ARM multi_v7_defconfig) and ensure no config fragments are used? Oct 20 17:45:02 KBUILD_DEFCONFIG = "multi_v7_defconfig" Oct 20 17:45:16 I also had to set: KCONFIG_MODE = "alldefconfig" Oct 20 17:46:15 KCONFIG_MODE needs adding to the kernel-dev manual for sure Oct 20 17:47:28 We need to replicate the behaviour of "make multi_v7_defconfig" Oct 20 17:47:42 The closest I've got is `KERNEL_CONFIG_COMMAND = "oe_runmake -C ${S} CC="${KERNEL_CC}" LD="${KERNEL_LD}" O=${B} multi_v7_defconfig"` but that's unweidly Oct 20 17:50:07 paulbarker: Don't those 2 lines do that? Oct 20 17:50:31 what JPEW said is what we have in meta-arm for one or two kernels Oct 20 17:50:40 JPEW: I'd have to check it out and diff the resulting .config files Oct 20 18:04:06 paulbarker, zeddii: I sent a patch to the docs ML with an FAQ for how to use a vanilla kernel. Oct 20 18:04:36 Comments welcome.... also making sure I'm not telling lies would be great! Oct 20 18:04:51 JPEW: Thanks. I'm hacking around now to see how close I can get to what I need with a linux-yocto bbappend Oct 20 18:07:15 JPEW: `v5.8/standard/base` is a merge commit, I guess we'd want `v5.8/base` for purely vanilla upstream Oct 20 18:09:58 And by the looks of it we'd still need a place to carry bbappend files or recipes which set KBRANCH, SRCREV, etc. That doesn't belong in a BSP layer Oct 20 18:17:20 Yay, green build for rc1 :) Oct 20 18:28:40 congrats Oct 20 18:29:05 \o/ Oct 20 18:29:09 celebrate! Oct 20 19:07:54 paulbarker: You may want to reference linux-yocto-custom in meta-skeleton Oct 20 19:10:34 paulbarker: Ya, you're correct. v5.8/standard/base isn't *quite* upstream... but it's really close and it's by far the easiest to use Oct 20 19:46:11 * zeddii reads Oct 20 19:46:36 yah. /base is clean. /standard/base has only enough to work around boot / OE build issues (like perf). Nasty stuff is on BSP branches. Oct 20 20:03:26 khem: 2020-10-20 15:51:33 - INFO - NOTE: recipe optee-os-3.11.0-r0: task do_compile: Succeeded Oct 20 20:03:40 khem: qemuarm64-secureboot with musl Oct 20 20:03:51 can you replicate? what else might be causing that? Oct 20 20:04:06 (-secureboot is basically qemuarm64 with tweaks) Oct 20 20:04:39 oh optee-test, not optee-os Oct 20 20:04:43 * rburton expands test matrix Oct 20 20:42:20 rewitt: While youre at it Randy, I noticed the default crops/poky-container is still 18.04, so 20.04 hasnt been pushed Oct 20 20:42:45 rewitt: nvm I just basically hit refresh and its there now Oct 20 20:42:54 :D Oct 20 20:45:13 zeddii, paulbarker: Hmm, that's a tricky one... it seems like telling users to use /base is unwise since it isn't tested and has at lease some known issues (at least I assume zeddii wouldn't be patching it otherwise) Oct 20 20:45:48 OOTH, it's hard to explain that Oct 20 20:47:33 JPEW: /base is the mainline or stable release from kernel.org though so any known issues must be very yocto specific if they're not causing more general issues for other users Oct 20 20:47:46 I know we carry a patch for menuconfig Oct 20 20:47:52 Not sure what else Oct 20 20:49:14 FYI linux-yocto is still stuck in do_fetch here after 2h so I've made no progress on this, moved on to other things. I'll look at it tomorrow Oct 20 20:54:35 rburton: perhaps ptest ? Oct 20 21:05:19 khem: good news! the optee-test thing happens with glibc too :) Oct 20 21:05:47 i'm guessing its trying to statically link but we don't build libstdc++ with static libs? Oct 20 21:07:56 no, there's a libstdc++.a Oct 20 21:10:15 yes I am seeing it on glibc too see http://errors.yoctoproject.org/Errors/Details/510155/ Oct 20 21:12:34 we do have static libs but I am seeing it call bare linker and use full names on linker cmdline like libstdc++.a Oct 20 21:12:54 instead of -lstdc++ etc. Oct 20 21:13:16 -static -lstdc++ should have same effect infact Oct 20 21:15:32 rburton: it works with clang :) Oct 20 21:18:30 rburton: look at recipe-sysroot/usr/include/optee/export-user_ta/mk/gcc.mk Oct 20 21:19:00 its not respectng CC and friends from bitbake env thats the problem Oct 20 21:29:49 really getting frustrated with projects just reinventing build systems from the ground up Oct 20 21:30:16 what the deuce Oct 20 21:30:24 libstdc++$(sm) := $(shell $(CXX$(sm)) $(CXXFLAGS$(arch-bits-$(sm))) $(comp-cxxflags$(sm)) -print-file-name=libstdc++.a 2> /dev/null) Oct 20 21:30:46 what the ** is wrong with -lstdc++ Oct 20 21:34:39 khem: our intern has been kicking this stuff a fair bit, i'll get him to have a look Oct 20 21:37:04 ah looks like an easy fix Oct 20 22:37:07 alejandrohs: 20.04 exists, but it isn't the default. i.e. If you pull crops/poky-container it would still pull crops/poky-container:ubuntu-18.04. We can change the default though. Oct 20 22:37:58 s/poky-container/poky Oct 20 23:30:36 rburton: http://sprunge.us/pdnoqU takes you a step further, but then it fails with LSE stuff, libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval' Oct 20 23:31:49 __getauxval is expected to come from libc which in optee-os case is not standard libc perhaps I tried to build it using -mno-outline-atomics but it did not work either Oct 20 23:38:20 rburton: this is the offending commit in optee-test https://github.com/OP-TEE/optee_test/commit/1a205ae33440f603e0579155505ce48215169e58 Oct 21 03:21:29 Hello...I get this error when trying to start toaster using "source toaster start" Oct 21 03:21:39 Failure while trying to setup toaster: Problem installing fixtures: no such table: orm_build__old Oct 21 03:21:55 More details here --> https://pastebin.com/qfMusX7V Any ideas? Oct 21 03:22:42 All toaster dependencies are installed inside python virtual env ie. I am using python virtualenv for this Oct 21 07:35:43 yo dudX Oct 21 07:39:48 morning Oct 21 07:52:36 good morning Oct 21 08:53:57 hello there. I'm on dunfell and whenever I do "devtool modify virtual/kernel", do_preconfigure fails due to missing "defconfig" in devtooltmp-XYZ directory. any clues? Oct 21 09:10:14 cengiz_io: What kernel recipe are you using? Oct 21 09:10:37 paulbarker hello. linux-fslc from meta-freescale Oct 21 09:12:02 That could easily be an issue with the linux-fslc recipe. I'd recommend testing this with linux-yocto for a qemu machine, if that works then the issue is in meta-freescale, if not the issue is in poky/oe-core Oct 21 09:15:34 it probably is. Oct 21 09:17:01 I don't know devtool internals but there's "file://defconfig" in SRC_URI of linux-fslc's recipe. and it obviously doesn't ship with the recipe. Oct 21 09:18:04 cengiz_io: then scream at nxp for such a bad layer :D Oct 21 09:18:05 I have my own defconfig in a matching directory of my own layer. but somehow it doesn't get copied Oct 21 09:18:26 cengiz_io: do you have FILESEXTRAPATHS_prepend := in your bbappend? Oct 21 09:18:27 qschulz can't do because this is totally community effort. their layer is even worse Oct 21 09:18:38 (you need a bbappend) Oct 21 09:18:38 yes Oct 21 09:18:56 indeed Oct 21 09:19:23 cengiz_io: triple check that there are no typos, that you're using prepend and not append, that you are using := and not another operator and that the path you have set it to exists and is where you have your defconfig Oct 21 09:19:48 you can check the oath is correct by using bitbake virtual/kernel -e | grep -e "^FILESPATH=" Oct 21 09:19:51 qschulz interesting thing is, kernel compiles fine Oct 21 09:29:45 cengiz_io: even not all recipes in poky are tested against devtool so it's not surprise really a recipe from a non-core layer isn't working either Oct 21 09:31:12 ndec: RP: just a reminder that one needs to remove the build directory entirely (or at least the static dir, can't remember) when css changes have been made (which is the case for my css fix from a few weeks ago). Not urgent, but needs to be remembered :) Oct 21 09:31:28 (I'm talking about the docs) Oct 21 10:18:29 qschulz do you know a way to keep devtooltmp directory whenever an error occurs? Oct 21 10:24:13 cengiz_io: I do not, I'm not really a devtool power-user :/ Oct 21 10:38:16 qschulz: thanks for the reminder! Oct 21 10:49:53 RP: I'll try to think of some hacks so we don't need manual intervention, but the couple hours I looked for something nice from within Sphinx, nothing turned out that great :/ Oct 21 10:50:41 well, let's say it's a known issue and couldn't find someone with a nice work-around :) Oct 21 10:52:35 qschulz: it would definitely be good to try and fix it, I've not looked into it rally Oct 21 10:52:38 really **** ENDING LOGGING AT Wed Oct 21 10:59:57 2020