**** BEGIN LOGGING AT Wed Nov 04 02:59:57 2020 Nov 04 04:57:01 I was wondering if this is the style of code you are using inside bitbake python: https://pastebin.com/6z2438FY instead of `return fn in self.clean` ? Nov 04 07:53:30 Hey! yocto 3.2 gatesgarth is out, well done everyone! Nov 04 08:20:07 yo dudX Nov 04 09:45:50 Once the parse is done on a build Bitbake has already put everything in its cache and changing a recipe has no effect for that build? Nov 04 10:29:57 can I augment a machine configuration? E.g. say I want to append some values to machine qemux86.conf without defining a new machine. Nov 04 10:35:49 lxc: new machine that pulls in the original file, and only "augments" :) Nov 04 10:36:35 lxc: technically you can inject stuff through local.conf for debugging/development, but ... well, its meant to go into a machine config. Nov 04 10:36:48 yes, but then I would have to create a new machine type, say qemux86-extra.conf. Nov 04 10:37:22 but I want to keep the same machine name. recipes supports this with bbappend, but not conf files? Nov 04 10:38:06 lxc: nope, it doesn't work like that with conf files. Nov 04 10:40:11 can I set PREFERRED_PROVIDER per machine type? Nov 04 10:40:32 e.g. PREFERRED_PROVIDER_qemux86_virtual/kernel ? Nov 04 10:47:00 of course, thats one of the primary usecases of a machine config Nov 04 10:47:44 ah you mean, set somewhere OTHER than the machine confi? it depends. you can not in a recipe, affecting another recipe. Nov 04 12:43:47 @LetoThe2nd: maybe @lxc means machine overrides? Nov 04 12:45:01 @RobertBerger maybe. but those do just affect the current recipe, hence as usual: it depends(TM) Nov 04 12:45:45 RobertBerger LetoThe2nd I think I found a way, I created a new machine file and inside the file set MACHINE= Nov 04 12:45:53 Does that seems like a correct approach? Nov 04 12:46:54 halfways. it will work probably, but confuse others that use the metadata, hence i did not mention that way. i would probably file it under "hack" Nov 04 13:02:27 Hi, I am using bitbake in a CI pipeline with a failing task, but bitbake does not seem to return a standard error output, any idea how I could make that happen? Nov 04 13:25:48 Hi guys! thanks to your help i'm now able to have useful CI workflow. Question regarding a shared SSTATE_CACHE shared between to Docker images running Yocto. If the 1st containers makes some changes on a package, the second one is able to detect changes ? Thx :) Nov 04 13:30:34 Ninic0c0: please rephrase, i don't think the sentence makes sense as is. Nov 04 13:33:29 Ok sorry my english is not really Goog. I have 2 Docker images sharing same SSTATE_CACHE. If the first one make some changes inside this package (means change recipe contains, SRCREV, add patch...) the second Docker image will be able to see differences ? Nov 04 13:33:39 I hope to be clear ... Nov 04 13:33:54 assuming the second docker has the same recipe changes, it will find the sstate-cache files for those yes Nov 04 13:34:09 it won't magically use the files from sstate without the corresponding recipe changes Nov 04 13:41:00 Ninic0c0: i guess you're thinking backwards. its like this: if the build process in one container encounters a recipe, then it looks at the sstate if there is somethign that matches the exact state of the recipe. if it finds something, then it is used. if not, it is being (re)built Nov 04 13:41:57 rburton and LetoThe2nd Thank you guys it's clear now Nov 04 13:42:16 Ninic0c0: so if both (dockerized) builders share the same modified recipe sources, then the build will reuse the sstate. if their recipes are different, then not. it is always "build looks at sstate, then uses." never "sstate says 'hey ive' got something newer for you'" Nov 04 13:55:24 hello all! Nov 04 14:04:19 Hello! Nov 04 14:04:54 Say that a distro is defined in layer A, is it possible to append to that distro from Layer B? Nov 04 14:05:05 something like confappend :P Nov 04 14:05:08 nope Nov 04 14:05:16 at least not in a somewhat clean way Nov 04 14:18:16 And some form of inclusion from a distro file from B in the A distro? Nov 04 14:21:39 you can happily include other distros, and add/modify their content. look at poky-bleeding.conf for an example. Nov 04 14:26:56 okay thanks Nov 04 14:30:40 hi using .bbappend file, how can i replace the images with my own ? https://github.com/STMicroelectronics/meta-st-openstlinux/tree/dunfell/recipes-core/psplash Nov 04 14:31:38 or is the easiest way just to copy everything, make my own receipe and edit the Makefile and replace the images with my own ? Nov 04 14:33:12 nohit: in the given example a stupid copy'n'patch does the trick probably. Nov 04 14:35:56 LetoThe2nd: ok thanks Nov 04 14:36:26 i found this but its for the poky psplash https://stackoverflow.com/questions/47769154/yocto-change-psplash-image-without-rebuild-the-system Nov 04 14:36:41 i was hoping for similar easy solution Nov 04 14:44:17 nohit: i can neither confirm nor deny that this works, never used that way. Nov 04 14:51:27 I'm lost... Nov 04 14:51:48 I have a Petalinux project. Doesn't matter, it's yocto after all. Nov 04 14:51:58 I have a bbappend that add patches. Nov 04 14:52:07 And I can see them applied in the do.log_patch file. Nov 04 14:52:46 When I go to the linux-xlnx code checked out with devtool modify linux-xlnx, I can see the patches applied to the git repo. Nov 04 14:53:01 But I'm just behind the commits of these patches. Nov 04 14:53:19 So: who is forcing me to say behind the applied patches? Nov 04 14:53:55 First, it thought it was a do_patch[noexec] = "1'. Nov 04 14:54:00 But I can't find it. Nov 04 14:54:09 and unsetting it didn't help. Nov 04 16:06:12 Are the presentations from the Yocto Project Summit last week online somewhere? Nov 04 16:40:24 manuel1985: AFAIK not yet Nov 04 16:43:39 manuel1985: the slides are available via the schedule if that helps: https://pretalx.com/yocto-project-summit-2020/schedule/ Nov 04 16:55:02 manuel1985: I though presentations=videos, sorry Nov 04 16:55:07 t Nov 04 16:57:37 some videos are available here for those who might not be aware: https://elinux.org/ELC_Europe_2020_Presentations Nov 04 16:58:18 eduardas: ELCE!=YPSummit though Nov 04 16:59:37 mckoan: but as far as I understand there is quite a bit of overlap? Nov 04 17:03:13 for example, Robert Bergers meta-virtualization video is listed on the elinux page Nov 04 17:17:09 hi, if i need to build a few packages with a newer version of gcc, how practical is that going to be? i saw the "secondary toolchain" wiki page but the blacklist is tripping me up for quilt-native (which should presumably use the native tools and not be affected?) Nov 04 17:23:28 Is there a way to have yocto build a toolchain for -native packages? Nov 04 17:29:57 no Nov 04 17:30:04 how would you build it? :) Nov 04 17:30:32 Build it with the hosttools gcc :) Nov 04 17:30:53 so if you trust the host gcc to build a compiler, why don't you trust it for the other -native packages? Nov 04 17:36:42 if the hosttools gcc is old (as is my case) it might be nice :) but i can appreciate how that is an edge case Nov 04 17:44:44 If you can't trust your host, that's when it's time to do your builds in docker or another container Nov 04 17:44:59 you can do so almost entirely transparently, you don't have to move your dev tooling into the thing Nov 04 17:45:01 i.e. pyrex Nov 04 17:45:26 opello: containers, or use the buildtools tarball which does in fact contain a native gcc built by yocto Nov 04 17:45:43 good point, buildtools-tarball is handy Nov 04 17:47:11 is it practical to use buildtools-tarball and maybe even a future version esdk as a secondary toolchain for some subset of recipes? Nov 04 17:48:17 why wouldn't you use it for everything? Nov 04 17:48:23 a subset seems like just adding needless complexity Nov 04 17:50:56 to avoid rebuilding libc and everything so that ongoing updates via the package feed don't reinstall the entire system Nov 04 17:53:06 (i'm trying to figure out just how practical of a goal that is to satisfy, if it's not practical, the solution is probably going to be reimage to a newer distribution, which is nicer for me anyway, but presents a more complex ongoing environment to support) Nov 04 17:55:06 i can't imagine sourcing the buildtools tarball would result in rebuilds of target packages. bitbake doesn't track the host's toolchain Nov 04 17:56:01 sorry, i thought you were addressing the 'future version esdk as a secondary toolchain for some subset of recipes' Nov 04 19:19:37 Hello, I have a question about PARALLEL_MAKE. I'm experiencing some strange "hanging" of bitbake tasks when building on a virtual server instance in the cloud (N1 on Google Cloud Platform, I blieve). The instance has 32 vCPUs, and bitbake automatically uses 32 for BB_NUMBER_THREADS and PARALLEL_MAKE. I noticed in the ref manual that the recommended setting for PARALLEL_MAKE on large systems with Nov 04 19:19:40 many CPUs is "-j 20". Why 20? I'm going to try this setting shortly, but I wanted to see if people knew the reason behind this. Thanks in advance! Nov 04 19:22:30 robbawebba: AIUI the issue is you effectively can end up with BB_NUMBER_THREADS * PARALLEL_MAKE processes, as PARALLEL_MAKE currently isn't global across tasks Nov 04 19:23:02 robbawebba: lowering one or the other some can keep load within what the machine can handle Nov 04 20:06:15 opello: Nov 04 20:06:29 use containers is an option Nov 04 20:07:00 as part of the build process of a single recipe? or you mean for the over-all build? Nov 04 20:07:45 smurray: thanks! this makes sense. I'll try lowering one or both of these parameters. Nov 04 20:18:01 hi, is the hello-world example from meta-xilinx-standalone known to be broken ? cortexr5fhf-vfpv3d16-xilinx-eabi/xilstandalone/v2020.1+gitAUTOINC+338150ab36-r0/git//scripts/generate_libdata.py': [Errno 2] No such file or directory Nov 04 20:18:17 its as if this generate_libdata.py script was just missing form the embeddedsw repo altogether Nov 04 21:15:46 marex: suspect you need to flag fray on that, see he's listed as one of the maintainers now Nov 04 21:16:46 * smurray refrains from making any meta-amd jokes Nov 04 21:27:53 smurray: fray == mark ? Nov 04 21:28:05 marex: yep Nov 04 21:28:11 ah, thanks Nov 04 21:28:21 smurray: it fails to build on native hardware too btw Nov 04 21:28:32 heh Nov 04 21:54:31 fray: hi, what's the state of meta-xilinx-standalone ? (see above) Nov 04 21:55:48 * zeddii pops some popcorn Nov 04 22:25:42 Anyone familiar with compiling golang directly on a Yocto target? I have it working up until I include a MySQL driver, at which point it tries to use cgo and fails with this error: https://pastebin.com/jq3WTJYv Clearly the sysroot directory is wrong here, but I'm unsure what to do about it. Nov 04 22:30:52 zeddii: did I miss something ? Nov 04 22:31:07 zeddii: seems like here is a good place to discuss downstream vendor layer problems, no ? Nov 04 22:32:37 Androo: one suggestion I'd recommend is to re-assign the CC env variable to remove the --sysroot flag. My assumption is that all of the libraries/headers/dependencies should be on the target, and the sysroot flag would no longer be needed. Nov 04 22:37:40 robbawebba: whoa, "env CC=arm-poky-linux-gnueabi-gcc go run .." mayyy have worked! Nov 04 22:38:06 this is what I get for not really knowing C Nov 04 22:39:41 haha don't worry I'm in the same boat. I Nov 04 22:39:50 I'm still learning all of this one day at a time Nov 04 22:41:00 Androo: can you file a bug please. the sysroot shouldn't be used on target obviously. Nov 04 22:41:14 robbawebba: I was thrown headfirst into Yocto by my employer and finding I need some serious cross-compilation skills at times. Nov 04 22:41:30 Androo: bugzilla.yoctoproject.org, build system - oe-core -> devtools Nov 04 22:43:24 rburton: will do. This is something related to the packaging of go? Nov 04 22:44:58 haha we'll you're in for a wild ride! I started using yocto about 2 years ago for the same reason, and I've learned a lot since then. There's still a lot I don't know about Yocto and embedded development, but we just have to take it one day / one problem at a time. Your debugging skills will definitely increase if you stick with development! Yocto luckily makes most of it very easy :) Nov 04 22:45:36 Androo: Nov 04 22:45:51 are you compiling go itself on target ? Nov 04 22:46:19 Guest9816: Yes. Sort of helpful to do my development straight on my target, as there's hardware there I can't replicate elsewhere. Nov 04 22:46:25 Androo: or using the go compiler on target to compile other go app which has cgo pieces Nov 04 22:46:41 do you have CC set in your shell ? Nov 04 22:47:39 Guest9816: do now Nov 04 22:48:34 so the sysroot is being added by go compiler itself ? Nov 04 22:48:43 Guest9816: yes Nov 04 22:49:17 I guess it will be good to run strings program on go compiler and search for sysroot perhaps its being added during cross building of go compiler Nov 04 22:49:47 since we use cross-compiler to build the go compiler for target, its not a normal setup for bootstrapping go Nov 04 22:53:47 Guest9816: cross compiling works fine, but I need to be able to work on my target as my application ties together custom hardware (an RF serial modem), buttons, LEDs, a cell modem, etc ... not sure how I would work effectively otherwise. Nov 04 22:53:51 I'm pretty sure the go toolchain respects the CC and CXX env variables from the shell https://golang.org/cmd/cgo/. I doubt that CC was set within the go toolchain itself. Would CC be set in some other environment location on the target? Nov 04 22:54:45 robbawebba: no CC environment variable was set when this error occurred, so I'll have to dig to find the source Nov 04 22:59:51 Androo: its ok, I understand your dev env is fine, I would do same especially if I am writing things in go or rust Nov 04 23:00:33 yeah cgo is a bridge to bring all C/C++ devs over to go :) Nov 04 23:19:28 Androo: gotcha. Well best of luck! It sounds like it'll be sorted out with the bug report on bugzilla Nov 04 23:20:27 I use a mix of Go and C apps on the product I work on, and I've been spending quite a lot of time on C apps lately. I miss Go! Nov 04 23:38:16 Guest9816: looks like sysroot is compiles straight into Go somehow, getting binary matches in /usr/lib/go/bin/go and /usr/lib/go/pkg/tool/linux_arm/cgo Nov 04 23:41:19 Guest9816: I'm wondering if it's related to https://github.com/golang/go/issues/8161 Nov 04 23:45:52 Androo: Nov 04 23:46:00 yes see `C{C,XX}_FOR_TARGET Nov 04 23:46:01 are embedded during the make.bash process because they have to provided by Nov 04 23:46:01 the user.` Nov 04 23:46:42 so naturally it is going to embed the cross compiler since that is what is setting these vars during build of go compiler for target Nov 05 00:04:03 Androo: what does `go env` say ? Nov 05 00:05:01 CC and CXX both have that invalid sysroot in 'go env' Nov 05 00:05:38 right so that is the problem in building go compiler Nov 05 00:15:34 I guess setting CC/CXX in your env is a workaround you can use but we need to fix it by setting CC_FOR_TARGET in recipe to use target compiler as it will be duting runtime not buildtime Nov 05 01:52:23 thanks for the assistance everyone, I believe I'm running smoothly with Go on the target machine now and will file a bug report once I dig into the problem a bit more and better understand it **** ENDING LOGGING AT Thu Nov 05 02:59:57 2020