**** BEGIN LOGGING AT Mon Oct 05 02:59:57 2020 Oct 05 03:27:56 RP: https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/642 Oct 05 03:28:18 this is with master-next, I wonder if something in core is causing these failures Oct 05 05:04:58 WARNING: Failed to fetch URL http://downloads.sourceforge.net/project/libpng/libpng16/1.6.16/libpng-1.6.16.tar.xz, attempting MIRRORS if availableDo I need to fix it? How to fix it ? Thanks! Oct 05 05:05:27 Do I need to fix it? How to fix it ? Thanks! Oct 05 05:25:37 RPI-IMX6, if wget of that url does not work, you may need to find a alt SRC_URI. Oct 05 05:27:17 khem, I think \ Oct 05 05:27:47 miss fire.. it could be caused by the host os Oct 05 05:32:26 armpit,Thanks! Oct 05 06:45:31 armpit: | abort()ing by server requestmake[1]: *** [Makefile:35: install] Aborted (core dumped) Oct 05 06:45:47 those error look foreign to me Oct 05 06:46:48 abort()ing by server requestmake[1]: *** [GNUmakefile.ACE:531: install] Aborted (core dumped) Oct 05 07:28:09 khem: those aborts are the pseudo issues I've been asking for help with Oct 05 07:38:34 howdy dudes Oct 05 07:44:50 Howdy Josef! How is it going? Ich bin der Manuel von Viewpointsystem :) Wir hatten Kontakt wegen private jestering Oct 05 07:45:59 good morning Oct 05 07:48:19 Non-yocto-related question: Which tool do you guys use for timekeeping? I'm working on a private project, and it would be interesting to track how much time I'm investing in there. I don't need many features besides a fat start/stopp button. The moment I have to type the time into a field I won't use it anymore. Oct 05 07:49:24 manuel1985: \m/ Oct 05 07:50:06 i don't have time, hence no need to keep it :) Oct 05 08:09:06 LetoThe2nd: I see :D Oct 05 08:33:21 hi Oct 05 08:43:49 greetings Oct 05 08:46:49 psycorama: o/ Oct 05 09:08:38 ndec: do you we have anything planned to improve the search in the new docs website? It's horrendous :/ Caddy webserver is using https://docsearch.algolia.com/, maybe there are alternatives (self-hosted evben?) that would greatly improve the search? Oct 05 09:10:05 qschulz: can i have less/vim regex support, pretty please? Oct 05 09:13:50 qschulz: i know it doesn't work quite well.. i am aware of docsearch, and even saw it integrated with sphinx (http://docs.coala.io/en/latest/) Oct 05 09:14:42 this is probably the right thing to do.. though we need to understand how it will behave with how we integrated YP and Bitbake docs, and how we deal with multiple versions. Oct 05 09:15:19 ndec: yeah, guessed it wasn't a straightforward process :) Oct 05 09:16:01 stupid question. just added the YP thing to my ELCE registration. now do i need to sign up for YPDD additionally? Oct 05 09:16:30 LetoThe2nd: nope. Oct 05 09:16:36 ndec: k Oct 05 09:16:47 you will receive information about how to join, etc.. from LF. Oct 05 09:17:13 hooray, more ways to annoy you all! :) Oct 05 09:22:18 Hi! I'm unsure if this is the correct channel to ask, but I recently added Boost to my ARM zeus build, and seem to be unable to build an application using boost with the SDK I built. When I looked at the release notes for Boost_1.71, it states that it has been tested with gcc up to 8.0.1. But I'm having a hard time thinking this is a general problem, it must be me that does something wrong. Does someone here have expecience with boost using zeus for arm? Oct 05 09:22:50 Zeus comes with gcc 9.2 Oct 05 09:24:52 frwi: yes, boost works on zeus and also in SDK. used in several projects with different ARM SoC's and BSPs.. Oct 05 09:25:22 frwi: but do check that BSP layers are not messing with boost via bbappends or .bb's Oct 05 09:26:50 mcfrisk: that is great news, started feeling a little demoralized. I'm using meta-ti, it's a TI Sitara am5718 I'm building for. I should investigate any boost messing in their layer... Oct 05 09:54:19 I've got a question about qemuboot, specifically QB_KERNEL_CMDLINE_APPEND. Currently I'm adding to it through local.conf, but at a later point it is overwritten by pokys meta/conf/machine/include/qemuboot-x86.inc so my changes will be thrown away. Is there a canonical place to append something to QB_KERNEL_CMDLINE_APPEND? Oct 05 09:58:03 psycorama: usually this would go into your own machine conf Oct 05 10:03:36 sounds about right. let me dig a bit deeper into my setup here. thanks :) Oct 05 11:22:56 LetoThe2nd: in all your fun have you ever encountered anyone using docker to build a container *inside a recipe* Oct 05 11:34:32 rburton: not yet, are you volunteering? Oct 05 11:34:38 haha no Oct 05 11:36:40 i am pretty sure that somebody somewhere does this already. Oct 05 11:37:04 building an arm64 docker image inside a bitbake task on an x86-64 host Oct 05 11:37:09 doesn't sound like fun Oct 05 11:37:23 oh, why not? Oct 05 11:37:41 too early to drink Oct 05 11:37:44 just another form of hidden host dependencies. Oct 05 11:38:04 apparently docker-cross can do that by using the host qemu Oct 05 11:40:38 my latest fun+scary thoughts actually are mostly around dotnet core and such Oct 05 12:12:13 12yo is bad. make it at least 16yo. beer ftw. Oct 05 12:23:50 meh. -ECHAN Oct 05 12:26:48 lol Oct 05 12:28:43 context is everything Oct 05 12:30:06 trying to use devtool, but I get an error ERROR: Command Error: 'git rev-parse --show-toplevel' exited with 0 Output: Oct 05 12:30:06 Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). Oct 05 12:31:12 I guess the reason is that my build area is not on the same filesystem as my metadata Oct 05 12:31:59 that is by intention. the meta-data has backup, is too small for build. The build area has no backup Oct 05 12:32:36 rburton: If I'm reading that correctly, this is something I'm covering in my ELCe talk in a few weeks! We've talked about it at past summits and normally just point out all the problems with even starting to try it :D Oct 05 12:32:59 neverpanic: yep. the original context was somebody saying "hey i'm still a 12yo, so i gotta make a poop joke" Oct 05 12:33:27 zeddii: the goal was x86-64 build host, arm64 target, running on target a container that is built with a dockerfile from an alpine image during the bitbake build Oct 05 12:33:47 something docker-cross something qemu something Oct 05 12:33:59 doesn't sound like the sort of thing I'd encourage Oct 05 12:34:06 any idea how to avoid the problem? Just setting GIT_DISCOVERY_ACROSS_FILESYSTEM obviously doesn't work, because bitbake cleans the environment before doing anying Oct 05 12:34:57 rburton: yah. that's not a good idea. What's the goal of that running container ? is it the target image ? Oct 05 12:35:07 a container to run on the target Oct 05 12:35:16 I'm creating an angry slide for suggestions like that. Oct 05 12:35:36 I think I'm presentation #1 for the yocto days, so I can set the tone. Oct 05 12:35:43 :D Oct 05 12:35:51 looking forward to it Oct 05 12:36:28 but I am working on an OCI container that is actually *built* by bitake that is installed and ready to run on the image, by docker/runc/whatever. Oct 05 12:36:51 the craziness comes when people want to use docker or one of the other horribly complex tools as -native to compose the container. Oct 05 12:37:08 .. that's what bitbake/oe does, why would you circumvent that, if actually using OE. Oct 05 12:37:42 right Oct 05 12:38:04 because "Dockerfiles are easy" Oct 05 12:38:14 * LetoThe2nd prepares for some epic trolling. Oct 05 12:38:15 if you *needed* to do that I was wondering if docker has a nice way to populate a sysroot, effectively Oct 05 12:38:35 hey docker-native, install foo:latest into /build/tmp/rootfs/... Oct 05 12:38:41 now, I totally see outputs of OE, as in OE binary outputs, on dockerhub, etc, using *those* in a docker compose way is a good idea. Oct 05 12:39:25 rburton: I've actually been poking into something like that, but I'm more going through the plumbing of docker, versus trying to use docker. it has so many permissions ideas and location ideas, etc, that it is hard. Oct 05 12:39:46 and it all falls apart when docker comes into play if you care about licensing, reproducibility, etc. Oct 05 12:39:56 which is hopefully why someone is using OE anyway :D Oct 05 12:40:35 well, yeah Oct 05 12:41:03 run random root-loving tool, with whatever uid map it has, and yank down artifacts and install them into my image/build. Oct 05 12:41:07 "good idea". Oct 05 12:41:22 Ship that an let me know! Oct 05 12:41:33 but for debug/prototyping, I see the argument. Oct 05 12:41:58 I have my bugzilla features that would do that with OCI containers, but those are built with OE, not pulled down from an artifact rep. Oct 05 12:42:03 s/rep/repo/ Oct 05 12:42:05 slightly better argument if you own the container registry Oct 05 12:42:34 yep. and we've had demos where we actually populate and run one (a regeistry) on target. Oct 05 12:42:43 and yank from it locally to start things up. Oct 05 12:42:53 but I'm looking at the plumbing instead of doing that now. Oct 05 12:44:35 but if your registry is local, surely it must be easier to compose the containers with OE, unless there's something super compelling about bitbake task scheduling and dependencies you just can't live without. Oct 05 12:59:02 only two oe-core messages in my queue this morning. Makes me wonder if I got unsubscribed! Oct 05 13:02:58 zeddii: subscribe to docs and you'll get messages from me :D Oct 05 13:03:30 :D I'm seeing those! i have no filter defined for them, so they land right in my inbox Oct 05 13:09:20 i seriously wonder if i should try and build a dotnet-core from source layer/recipe. everything i can see at the moment seems to use prebaked binaries. Oct 05 13:14:21 absolutely worth a go Oct 05 13:22:41 rburton: before, during, or after drinking? Oct 05 13:22:52 during Oct 05 13:23:04 thanks for your input. Oct 05 14:46:32 does anybody here happen to have a pretty standard run of the mill x86_64 rootfs handy and could share? something like core-image-full-cmdline or such. just the rootfs, no kernel. Oct 05 14:47:59 (tarballed :) ) Oct 05 15:33:19 LetoThe2nd: you could use the last project release? Oct 05 15:33:42 RP: is there a pre-build tarball? Oct 05 15:34:41 LetoThe2nd: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.2_M3/machines/qemu/qemux86-64/ Oct 05 15:35:29 RP: ah nice, thanks. Oct 05 15:55:43 it doesn't look like the MACHINE_EXTRA_RRECOMMENDS that are specified in conf/machine/raspberrypi3-64.conf are making it into the image when i build for raspberrypi3-64? Oct 05 15:56:23 (i'm on master, just meta-raspberrypi and openembedded-core, nodistro) Oct 05 15:56:34 maybe it's a poky thing? Oct 05 15:59:16 tlwoerner: which image/distro are you using? Oct 05 15:59:40 core-image-full-cmdline, nodistro (just openembedded-core) Oct 05 15:59:48 …and the BSP layer Oct 05 16:00:37 i can add them RRECOMMENDS to CORE_IMAGE_EXTRA_INSTALL and they show up, but something is fishy that the conf/machine/…conf file is specifying them, but they're not ending up in the final image Oct 05 16:02:00 (unless i explicitly add them) Oct 05 16:02:02 tlwoerner: MACHINE_EXTRA_RRECOMMENDS is added into RRECOMMENDS of packagegroup-basic and packagegroup-machine-base Oct 05 16:02:15 tlwoerner: someone reported the other day that that image was missing packagegroup-base. not sure if that's true? Oct 05 16:03:53 huh! looks that way! Oct 05 16:04:21 kergoth: ok I'm super confused... why is there a packagegroup-basic recipe that does not seem to be used anywhere? (simple grep, didn't go far into searching) Oct 05 16:04:35 core-image-full-cmdline include packagegroup-core-boot and packagegroup-core-full-cmdline Oct 05 16:07:19 okay, in any case it looks like i can figure it out from here, thanks! Oct 05 16:45:36 bluelightning: ping? Oct 05 17:13:49 tlwoerner: hi Oct 05 17:14:41 bluelightning: hey. last night i was trying to get devtool to create a recipe for a python library, but the setup.py file wasn't in the top-level, it was was in the "library" subdirectory Oct 05 17:15:03 bluelightning: the externalsrc messed it up because it overwrites the S variable (understandable) Oct 05 17:15:17 hmm, I thought there was an option to specify a subdir, one sec Oct 05 17:15:45 oh! Oct 05 17:15:48 src-subdir? Oct 05 17:16:03 --src-subdir yes Oct 05 17:16:13 perfect! thanks :-D Oct 05 17:16:22 let me know if it still doesn't behave properly Oct 05 17:16:49 ve have vays to make zit work! (lol) Oct 05 17:44:47 bluelightning: oh yea! much better :-) Oct 05 17:49:30 how can I add qemu runtime to an image? Tried IMAGE_INSTALL += qemu-native, but that does not work. Oct 05 17:50:00 lxc: You want to run the image under qemu, or run qemu on some target hardware? Oct 05 17:51:14 JPEW run the image in qemu. So maybe don't need qemu installed in rootfs, but need way to hold of qemu binaries, Oct 05 17:53:23 lxc: Assuming your MACHINE is set to a qemu machine (e.g. qemux86-64, qemuarm, etc), I think all you need to do is run `runqemu` Oct 05 17:54:01 @JPEW correct. but want to add the rootfs and the qemu runtime to a docker. Oct 05 17:55:15 Ah... in that case you might be better off building an SDK with qemu in it and installing that in the docker container (just a guess....)? Oct 05 17:55:52 JPEW but SDK would include the toolchain. don't need that. only rootfs and qemu runtime needed. Oct 05 17:57:08 lxc: I *think* you could wrangle an SDK that only included qemu and it's dependencies. The problem with trying to use qemu-native is that it's not designed to be a standalone thing you can run or copy around like that (I think) Oct 05 17:58:50 lxc: For example, uninative-tarball.bb doesn't include the entire cross compiler Oct 05 18:09:59 lxc: buildtools-tarball is also an sdk that doesn't include a compiler. actually it also includes qemu, along with other host deps Oct 05 18:29:28 bluelightning: oh interesting, --src-subdir doesn't play well with the -r option of "devtool reset"; it only removes the library subdirectory. that's understandable though Oct 05 18:30:37 lxc: you could just use whatever package manager is used in the docker, like apt, to install qemu Oct 05 18:30:54 there's nothing special about our qemu vs eg debian's qemu Oct 05 18:36:23 rburton don't have a package manager inside my docker. the docker is simply just the yocto rootfs w/o package manage.r Oct 05 18:37:45 just install qemu then Oct 05 18:38:00 you wouldn't install qemu-native as that's the native one Oct 05 18:38:07 you want qemu, the target qemu Oct 05 18:38:15 IMAGE_INSTALL += qemu Oct 05 18:38:44 bit confused as to what is running in qemu though now Oct 05 18:39:08 rburton: += works with IMAGE_INSTALL now? IMAGE_INSTALL_append is baked into my brain for some reason Oct 05 18:39:29 rewitt: most of the time it doesn't do what you want :) Oct 05 18:39:52 rburton: A strong maybe, understood :) Oct 05 18:40:21 rewitt: i felt so devops on friday, i used gitlab CI to build and host a derivative of crops for my CI Oct 05 18:40:52 glorious future etc etc Oct 05 18:42:12 rburton: The amount of things that are light years easier than they used to be is crazy Oct 05 18:43:33 rburton: I setup a jenkins instance(never ran a jenkins instance before) in an afternoon in docker just to be able to reproduce something someone is doing in crops. Oct 05 18:43:47 rburton tried that but ended up in "Nothing RPROVIDES 'qemu'".... incompatible with host i686-poky-linux-musl (not in COMPATIBLE_HOST) Oct 05 18:44:15 lxc: that would be because qemu fails to build against musl Oct 05 18:44:35 lxc: you can try removing the COMPATIBLE_HOST_libc-musl assignment and hope that its been fixed recently Oct 05 18:44:47 or, fixing qemu so it builds with musl Oct 05 18:45:13 khem probably already knows if it works with musl or not Oct 05 18:45:54 rburton ok, will try. thanks! Oct 05 18:45:56 I got the following error message: "ERROR: When reparsing /data/new/poky/build-bora-qemuarm/../meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_package, the basehash value changed from to . The metadata is not deterministic and this needs to be fixed." Oct 05 18:45:56 I used 'SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/3.1.2/PATH;downloadfilename=PATH', but that should be alright, because poky is pinned to that version as well. I used this tag: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tag/?h=yocto-3.1.2 Oct 05 18:45:56 Does someone know what's going on here? Oct 05 18:48:59 manuel1985: Are you saying without having SSTATE_MIRRORS set you don't get that error? Oct 05 18:51:00 rewitt: Don't think so. I'm just trying again to make sure. Oct 05 18:56:34 I takes the build some time to reach that point... :/ Oct 05 19:00:34 manuel1985: Hmm I would have expected it to fail relatively quickly since it says it's due to reparsing, which is the first thing bitbake does Oct 05 19:01:00 don't get your hopes up that I'll be able to help :-D Oct 05 19:02:49 manuel1985: *usually* you get that error if you edit a file while building Oct 05 19:11:05 Just building again, no errors so far. We'll see. I don't think I edited something during the build, but who knows... Oct 05 19:15:50 When I use SSTATE_MIRRORS, does it copy the stuff it found into my SSTATE_DIR? Or does it just populate my SSTATE_DIR with things it didn't find in one on the SSTATE_MIRRORS? Oct 05 19:24:45 manuel1985: it's either downloadd to SSTATE_DIR or symlinked there if it's from a local mirror Oct 05 19:28:32 kergoth: I see, thank you Oct 05 19:32:44 rewitt: it does not compile with musl targets perhaps is fixable I never needed that Oct 05 20:30:13 khem: if i wanted to test a build that uses the mips16e override, what machine/tune fiddling would be easiest? Oct 05 22:48:25 JPEW: if I forget, remind me to talk about crazy parsing speed improvement ideas tomorrow... Oct 05 22:54:44 Hello Yocto people! I have either a quick question or a tricky one depending on whether anyone has done this before. I have a project that is mostly complete for a custom third party SoM which requires custom bootstrap/bootloaders, currently I am building them in a meta-bsp layer recipe which works alright however they are build in the Oct 05 22:54:45 aarch64-poky-linux build directory. We have multiple SoM models from this manufacturer that each require different bootloader configs and I'd like them to be built in a machine specific non-linux directory if possible like aarch64--none or something. Is this possible? Oct 05 22:55:33 Using dunfell btw Oct 05 23:41:48 bluelightning: a testament to your brilliant tool!!!! Oct 05 23:41:53 bluelightning: https://twoerner.blogspot.com/2020/10/pimoroni-automation-hat-meets.html Oct 06 00:58:40 tlwoerner: thanks! nice article! Oct 06 01:24:38 rburton: set DEFAULTTUNE = "mips32r2-24kec-m16" Oct 06 01:25:20 rburton: you might have to change qemumips to include include/mips/tune-mips-24k.inc Oct 06 01:26:28 sealdogfish: set PACKAGE_ARCH = "${MACHINE_ARCH}" in the concerned recipe Oct 06 01:31:18 Thank you!! I'll try it out now Oct 06 01:41:08 Worked perfectly thanks Oct 06 01:51:27 RP: rewitt: chasing new failure mode in toaster-container, but this replicates locally. Oct 06 01:54:02 RP: rewitt: toaster_ui.log https://travis-ci.org/github/moto-timo/toaster-container/jobs/733137106#L880 Oct 06 01:54:40 RP: rewitt: seems strange to me that XMLRPC exits after such a short amount of time (in cooker log) but that might be a red herring? Oct 06 02:44:28 moto-timo: RP: I got the same error. I actually ran it the day Richard added his patch, but wasn't sure if I was missing something. **** ENDING LOGGING AT Tue Oct 06 02:59:56 2020