**** BEGIN LOGGING AT Wed May 06 03:00:05 2020 May 06 07:30:47 seebs, hi Peter May 06 07:33:08 seebs, for the pseudo/gcc10 fix, do you plan to update pseudo upstream soon, or should we add a patch to oe-core ? I noticed there are a few pending patches that could be merged upstream and then removed from oe-core May 06 08:12:37 kroon, regarding gcc10's fno-common default: Did you already looked into cpio and binutils? For me they also fail building. If no: I've prepared a patch appending fcommon to CFLAGS, should I send it? May 06 08:15:33 g0hl1n, well I don't speak for the yocto project, but I'd personally prefer if we fix the sources instead of adjusting CFLAGS. I know binutils is fixed upstream, OE just need to upgrade or perhaps backport the patch. I haven't gotten bitten by cpio yet, so no comments from me on that May 06 08:16:47 kroon, thanks. ok. Makes sense. Then I'll take a deeper look into cpio & binutils to find an appropriate fix ;-) May 06 08:26:09 g0hl1n, https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0b398d69acde3377dfbbeb8a4cfe87ae8c8562fa May 06 08:36:43 kroon, thanks. Already found it ;-) May 06 08:58:19 kroon, fyi: patches for binutils & cpio are on the list: https://patchwork.openembedded.org/patch/172356/ & https://patchwork.openembedded.org/patch/172355/; thanks for your input! May 06 08:58:25 RP: still sporadic virgl sefltest failures. I note that both tests took very little, so the items probably came from cache and were built on some other distro, and there's some kind of non-determinism issue there. I'll try to reproduce with the AB cache. May 06 08:59:09 g0hl1n, oh, didn't know that nickname was you Richard :-D May 06 09:00:03 although that branch name should have been a pointer May 06 09:02:49 kroon, yeah, wasn't too much of a secret :D - nonetheless, now you know ;-) May 06 09:08:39 g0hl1n: ahnoch i got it too ;) May 06 09:09:09 *ah now May 06 09:15:15 :-D haven't thought my nick/realname wouldn't be such a secret :-D May 06 09:16:48 dont think people took it as a secret, its just not obvious and now we're pleasantly surprised :) May 06 09:17:43 by the way, have you ever thought about doing a livecoding session? meta-java is certainly a hot topic, and i'm not gonna cover it ever, probably. May 06 09:28:20 LetoThe2nd, damn I definitely missed the whole livecoding thing^^. That's a great idea. I've only took a quick look now but I definitely will watch them ;-) Nice work! May 06 09:31:15 LetoThe2nd, regarding a meta-java session: I'll definitely will think about it and come back to you ;-) May 06 09:31:57 g0hl1n: yeah please do so. its really simple. allocate two hours, grab a beer, talk about stuff you like and know anyways, mess up in front of the cam, and thats it, basically. May 06 09:45:41 kanavin_home: thanks. Not sure what is going on there, I've worried it might also be system load. Running in isolation to see May 06 09:46:28 RP: right, I haven't started reproducing yet, because the ubuntu host is currently running a build or two May 06 09:48:17 kanavin_home: I reran on the same workers to see what happened as a first step at trying to understand it May 06 09:48:45 kanavin_home: we did have two builds in parallel last night and one was particularly heavy (from scratch) May 06 09:51:22 RP: right - I'm now first doing the virgl test from scratch, then will plug the AB cache into it. I hope to get two sets of binaries, one working, the other broken. On ubuntu1804-1. May 06 10:14:10 kanavin_home: failed the second time too May 06 10:16:17 RP: is there a link? May 06 10:18:31 kanavin_home: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/914 https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/904 May 06 10:18:55 kanavin_home: so that rules out load. Its either something in -next or "corrupt" sstate May 06 10:19:45 RP: right - I am running -next now with empty cache. May 06 10:20:12 kanavin_home: on one of the workers? Thanks, I'll leave this with you for now... May 06 10:20:35 RP: on ubuntu1804-1, yes May 06 10:24:42 RP: concerning memres again, devtool doesn't seem to utilze a resident bitbake process, right? May 06 10:25:18 LetoThe2nd: that would just depend on configuration wouldn't it? May 06 10:25:50 LetoThe2nd: memres bitbake is normal bitbake with a non-zero keep alive time May 06 10:28:02 kanavin_home: should I pause that worker? May 06 10:29:01 kanavin_home: that machine already has a selftest running FWIW May 06 10:30:01 RP: thats what i suspected too, yet when i kick off a devtool command right after a bitbake command with nonzero keep alive time, it still starts out with loading cache and parsing recipes, or at least thats what it tells me. May 06 10:31:11 LetoThe2nd: Check what the bitbake-cookerdaemon.log file says happened May 06 10:31:28 LetoThe2nd: could be the configurtation is seen as different May 06 10:31:32 RP: yeah, it's not too loaded at the moment, so maybe pausing is unnecessary May 06 10:31:45 RP: ok, will do so. May 06 10:32:19 kanavin_home: ok May 06 10:49:21 RP: master-next with blank cache passed on ubuntu1804-1 May 06 10:49:30 RP: I'll try to plug the AB cache now. May 06 11:11:16 RP: reproduced \0/ May 06 11:11:45 RP: so it seems that one of the distros 'poisons' the cache somehow May 06 11:15:14 kanavin_home: that is progress at least! :) May 06 11:15:26 kanavin_home: going to try and narrow it down to some specific component subset? May 06 11:17:34 RP: yes May 06 11:21:28 kanavin_home: cool :) May 06 12:03:20 RP: a bit of progress. The broken item is libSDL2, which for some reason was built with opengl disabled. May 06 12:10:51 ooh May 06 12:11:02 kanavin_home: wasn't there a patch in mingw or something for that? May 06 12:11:10 swear i saw a patch for that recently May 06 12:11:51 rburton: that was for mingw nativesdk, unrelated May 06 12:20:33 RP: I think I found it - SDL checks for gl.h and glx.h, the former comes from mesa-native, the latter falls through to the host. If the host doesn't have it, opengl silently disables opengl. May 06 12:20:44 *sdl silently disables opengl May 06 12:22:44 kanavin_home: ah, that would explain it May 06 12:23:31 so the fix would be to enable glx in mesa-native I guess May 06 12:58:43 RP: patch sent May 06 13:21:57 is there a wic doc for creating an iso ? May 06 13:22:22 wic help isnt very useful May 06 13:23:51 OutBackDingo: pick your poison: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/canned-wks May 06 13:27:45 LetoThe2nd: thx May 06 13:28:23 kanavin_home: Did you notice the errors between the two machines were slightly different? May 06 13:28:33 kanavin_home: Trying to decide if that is significant or not May 06 13:32:43 ERROR: _exec_cmd: cd ./tmp.wic.hu69n4_v/INITRD && find . | cpio -o -H newc -R root:root >./tmp.wic.hu69n4_v/initrd.cpio returned '2' instead of 0 May 06 13:32:43 output: /bin/sh: 1: cannot create ./tmp.wic.hu69n4_v/initrd.cpio: Directory nonexistent May 06 13:32:50 ermmm crapp... whatd i miss May 06 13:32:59 other then that should be in a pastebin May 06 13:51:47 OutBackDingo: you changed directory into ./tmp.wic.hu69n4_v and then ./tmp.wic.hu69n4_v/initrd.cpio doesn't make sense as its now ./initrd.cpio ? May 06 13:55:07 RP: all i did was run wic create mkhybridiso -e core-image-minimal May 06 13:55:15 https://pastebin.com/DsGsgMVw May 06 14:05:20 OutBackDingo: not sure. I was just trying to explain why that might be failing like it is May 06 14:12:09 RP: I did, I'm not sure about that either. :-/ But both failures happen in the same spot, the SDL test - gtk passes fine. May 06 14:14:28 (in general, i have vague plans to try to get some time to merge changes into pseudo master "any day now" but things Keep Happening.) May 06 14:15:26 seebs: that would be awesome if you did have time, I'm all too familiar with the problem May 06 14:28:03 RP: i got it, fixed now May 06 14:29:08 OutBackDingo: what was it? May 06 15:05:24 o/ May 06 15:16:13 hello, I am using SAMA5D27-SOM1-EK1 embedded board from microchip. I built for it Linux distribution using Yocto. I want to connect my board with WIFI network instead of ETHERNET. How can I do that please ? May 06 15:44:33 RP a simple type in IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}" May 06 15:44:47 RP: a simple type in IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}" May 06 15:45:47 so wic images were not being properly genned for wic create to properly digest needed data May 06 15:47:14 next dumb question... any decent installers to go from the iso to disk ? May 06 15:51:24 RP: bah, I made a patch for mesa, but only tested that sdl builds correctly, and didn't bother with the ensuring the actual virgl test doesn't regress :) now it seems it fails everywhere - I'll look into this. May 06 15:51:45 but first, a walk outside and some takeaway coffee from a paper cup! May 06 15:52:37 kanavin_home: thanks, enjoy May 06 16:33:35 I need to sed a file that gets placed into the sysroot. hooking a SYSROOT_PREPROCESS_FUNC successfully changed what I needed of the file in ${DESTDIR} but the changes no longer exist after do_populate_sysroot finishes. pointers? May 06 16:46:47 I'm trying to create a recipe for a set of prebuilt shared libraries. My recipe is working correctly, simply installing the .so files into my RFS. But I can't figure out how to get the headers populated into the SDK. Has anyone done this? May 06 17:20:45 hello all members, I am trying to see if there is an existing recipe for 'daemon' usually installed to /bin/daemon, its homepage is at http://www.libslack.org/daemon/ May 06 17:21:06 the debian package is here https://packages.debian.org/sid/daemon May 06 17:28:34 rpcme: I can't find any recipe, however there is a recipe for daemonize, which appears to be similar: https://layers.openembedded.org/layerindex/recipe/1071/ May 06 17:32:52 I understand. Thank you. I am a consumer of a system that requires /bin/daemon - for reasons I haven't figured received an answer on yet. so, I will have to write the recipe i guess. May 06 17:33:27 be sure to get it upstream if it works :^) May 06 17:42:19 absolutely. I feel it likely belongs in oe. I maintain meta-aws where it's needed right now. May 06 18:10:14 rpcme: If it's needed in meta-aws probably best to keep the recipe there for now, maybe migrate it to meta-oe if other users appear. meta-aws is in the layer index so people will be able to find it if they need it May 06 18:28:50 Hey guys. Was wondering if anyone here has built images containing nodejs apps? I'm trying to figure how I'd handle fetching dependencies (i.e. yarn install / npm install). May 06 18:41:08 I knew we did something like that, but I didn't know how, so I went and looked. I wish I didn't. May 06 19:02:52 RP: I think I've arrived at a more robust virgl setup now, patches sent May 06 19:03:42 the downside is that dri.pc (from mesa-dev) needs to be installed on any host that runs the virgl oe-selftest - I checked that it's installed on ubuntu 18.04 worker, but not the others May 06 19:05:14 (did not check the other workersI mean) May 06 19:06:05 the previous mesa patch is still needed May 06 20:09:23 kanavin_home: thanks, I'll run it through the autobuilder May 06 20:22:52 RP: full green otherwise! May 06 20:41:16 kanavin_home: next question is whether this issue is in dunfell too :/ May 06 20:58:36 halstead: remember we talked about upgrading the graphical cards in the AB? How is that going? May 06 20:59:21 RP: I think so, one of the distros contaminates sdl-native, and the same issue is likely to happen in dunfell too, if it's tested against the same distro set May 06 20:59:56 sakoman: ^^^ May 06 21:00:18 kanavin_home: changing this in dunfell may be painful :( May 06 21:30:05 RP: there's mcdepends for multiconfig DEPENDS - I guess doing RDEPENDS for multiconfig is not that easy? May 06 21:34:48 denix: I'm not quite sure what RDEPEND for multiconfig would mean? May 06 21:37:24 JPEW: normally I would agree with you for target packages. but then I want to bring in multiconfig sdk components together... May 06 21:39:08 denix: Like putting the -dev packages from multiple multiconfigs together into the same SDK? May 06 21:39:47 presumably each multiconfig would be a distinctly targetable item in the SDK? May 06 21:39:56 JPEW: or puttin together cross tools for multiple multiconfigs May 06 21:41:15 vmeson: dreyna: the yocto devday is july 2, which is just after the holiday :-) i can't say the same for the last day of elc ;-) May 06 21:41:26 denix: interesting May 06 21:42:35 tlwoerner: so what is the July 1st holiday? I assume that it is Canada only? May 06 21:43:43 JPEW: I'm doing multiple cores of a complex SOC via multiconfig - everything builds and deploys for the target. next step is to bring all the corresponding toolchains into a single sdk May 06 21:45:15 denix: Ya, that makes perfect sense, and something that would be really useful May 06 21:45:38 denix: I wonder if there is a way to do it without multiconfig for RDEPENDS though May 06 21:47:22 denix: The "easy" solution would be to package all the various SDKs together into a single "super" SDK (it's probably not to hard to write a recipe that would do this today). The user could source the environment for the correct SDK to build what they wanted, but it wouldn't be "integrated" at all May 06 21:48:18 denix: I think part of the problem is that the environment setup the SDK generates is taylored toward the target hardware, so there would necessarily be some conflicts if you tried to smash them all together May 06 21:51:32 JPEW: well, cross packages already have necessary ARCH and MACHINE suffixes May 06 21:52:57 JPEW: https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb May 06 21:53:55 denix: Ya.... if that's all you wanted it wouldn't conflict. The harder part is that they are probably going to have other nativesdk dependencies that would conflict May 06 21:54:26 maybe May 06 21:56:23 maybe... I'll keep digging **** BEGIN LOGGING AT Wed May 06 22:40:13 2020 May 06 22:47:03 denix: you don't need RDEPENDS. You'd need to add the feeds together and then populate IMAGE_INSTALL with a list of the packages you want May 06 22:59:30 someday I'll have to google just how Kanuckistan got fetched up into cross compiling by name.... **** ENDING LOGGING AT Thu May 07 02:59:57 2020