**** BEGIN LOGGING AT Wed Dec 19 03:00:02 2018 Dec 19 04:05:45 * paulg would not want to be stampeded by all the riscv64 yocto users... Dec 19 04:15:48 their user base supports membership count as as a "float", right? Dec 19 08:54:37 khem: Do I remember something odd about ifunc support on mips? I'm hoping that was a mips only hack Dec 19 08:55:02 khem: that test appeared to be "no" on an existing mips build Dec 19 09:35:40 New news from stackoverflow: Not able to compile code which uses cjson library functions on Yocto Linux OS || Add changes to systemd-udevd.service Dec 19 10:22:05 heh why would anyone still use cjson.. Dec 19 10:35:51 New news from stackoverflow: Not able to compile code which uses json-c library functions on Yocto Linux OS [duplicate] || Get description of packages in yocto image Dec 19 11:03:59 JaMa, hi Dec 19 11:04:23 have you played with VideoCore IV? Dec 19 11:04:42 do you think these vc4 drivers can be used on bcm7425 mipsel? Dec 19 11:05:27 (I am totally unaware of the DRM situation, seems possible for mips) Dec 19 11:09:18 ant_home: only on rpi3 Dec 19 11:22:45 ant_home: check Eric's blog https://anholt.github.io/twivc4/ Dec 19 12:36:13 New news from stackoverflow: Why would a yocto patch fail under devtool but not during a normal build? Dec 19 13:32:42 I'm a bit confused by how to make a python package. I've seen some examples, but they all use a bb that inherits setuptools and then an include that inherits pypi, why this two-step approach? Dec 19 13:43:14 Because you could install a setuptools-based software that doesn't come from pypi? Dec 19 13:43:46 I think it used to be the case that 'inherit pypi' implied 'inherit setuptools', but that has changed a while ago. Dec 19 13:46:01 pepijndevos: that's because what you're seeing is a common include file that uses pypi to fetch, and then a py2 recipe that inherit setuptool and a py3 recipe that inherits setuptools3 Dec 19 13:46:20 if for example the recipe doesn' support py2 there's no point in the split and it should just be in a single file Dec 19 13:47:20 so basically if the package is on pypi then inherit that and you get the src_uri done for you. if it uses setuptools inherit setuptools3 to build. Dec 19 14:42:43 is it intended, that `https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/files/toolchain-shar-relocate.sh` uses bash extensions (variable substitutions), yet neither has a `bash` suffix nor a `/usr/bin/env bash`-shebang? Dec 19 14:50:47 T_UNIX: It's invoked in another script (toolchain-shar-extract.sh), which is why it doesn't have a shebang Dec 19 14:52:08 IIRC, the contents of toolchain-shar-relocate.sh are simply pasted into toolchain-shar-extract.sh at a specific location Dec 19 14:57:59 JPEW: If the default interpreter isn't bash (i.e. Docker uses `/bin/sh`), it appears that the variable substitution isn't executed as intended and the surrounding command (perl substitution) bails. Dec 19 15:05:11 T_UNIX: Quite possibly.... is there a specific bashism thats causing trouble? Dec 19 15:09:09 I think the line `grep -Ev "$target_sdk_dir/(environment-setup-*|relocate_sdk*|${0##*/})"` is causing problems Dec 19 15:09:50 more specifically `${0##*/}` Dec 19 15:11:04 Sure. It might be worth either mandating bash or making sure there are no bashisms in the script. Dec 19 15:11:19 so, let's say i have a project built my own recipe, and i want it to build with -g -O0 flags when i make a dev image Dec 19 15:11:25 is there an easy way to achieve that? Dec 19 15:12:20 T_UNIX: Bonus points if you write a QA check to make sure no more bashisms end up in the SDK ;) Dec 19 15:12:54 ${0##*/} is POSIX, not bash Dec 19 15:13:06 see the single unix specification for details Dec 19 15:13:11 kergoth: my bad. Dec 19 15:13:34 http://pubs.opengroup.org/onlinepubs/9699919799/ -> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 Dec 19 15:13:37 kergoth: Hmm, interesting. Should have checked Dec 19 15:14:09 https://www.shellcheck.net/ :-D Dec 19 15:14:20 i agree we should avoid bashisms if not necessary. actually the shar relocation bits need reworking *badly*, that's some really badly written shell, and relocation technically isn't part of the compression / installer format, so should really be independent Dec 19 15:14:37 in this case: ${parameter##[word]} Dec 19 15:14:37 Remove Largest Prefix Pattern. The word shall be expanded to produce a pattern. The parameter expansion shall then result in parameter, with the largest portion of the prefix matched by the pattern deleted. Dec 19 15:14:38 :) Dec 19 15:14:46 <3 that opengroup site, really helpful resource Dec 19 15:16:01 that reminds me, i never did do enough benchmarks to get https://github.com/openembedded/bitbake/compare/master...kergoth:yocto-12987 merged.. Dec 19 15:17:17 kergoth: I played around with rewriting the SDK to be a self extracting Python file instead of a shell script (see poky-contrib/jpew/pyz-sdk) Dec 19 15:17:55 interesting. at mentor we hvae a completely different installer mechanism for it entirely, so needed the relocation bits in a standalone script that installer could call Dec 19 15:18:16 * kergoth adds a note to look at that branch Dec 19 15:19:19 kergoth: Ya, we end up redoing the SDK as a Python script for MinGW here which was some of the drive to try this out. Dec 19 15:19:34 oh right, that makes perfect sense Dec 19 15:36:01 dafuuuq! I have a working yocto image, and then I add some innocent Python package, and I now I have an image that gives weird errors in the SD card driver or something. I remove Python and everything is fine agaon. Dec 19 15:43:26 JPEW: there was no specific good reason for shell Dec 19 15:44:18 Well, the "drop gcc initial" patch kind of works, images boot and runtime test. Only one sdk test fails. Dec 19 15:45:13 RP: I was wondering. I figured Python wad required for relocation *anyway* so it should be OK. Dec 19 15:45:22 RP: But I also figured I shou;dn Dec 19 15:45:46 shouldn't get too distracted until I finish the hash equivalence stuff :) Dec 19 15:47:18 JPEW: thanks for the updated series, I think its close :) Dec 19 15:47:33 JPEW: my gcc rearrangement breaks mingw btw :/ Dec 19 15:47:43 * RP hasn't gotten to that part yet Dec 19 15:47:52 RP: Oh? Is there a log? Dec 19 15:49:18 JPEW: bbappend to a file which no longer exists for starters :) Patch series isn't up to that bit yet, need to investigate this sdk failure Dec 19 15:49:31 Ok Dec 19 15:53:58 anyone had experience in adding go packages in a Yocto layer? More explicitely how to describe dependencies between packages? Using DEPENDS ends up in a situation where additional packages are installed next to standard packages (GOROOT) when they should be in GOPATH Dec 19 16:01:16 yep, confirmed, dependencies are installed in ${WORKDIR}/recipe-sysroot/usr/lib/go/src when they should go to ${WORKDIR}/build/src/ Dec 19 16:03:36 any idea on how to fix the issue? Dec 19 16:48:27 where does the xargs' `file` argument in https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/files/toolchain-shar-relocate.sh#n57 come from? Dec 19 16:57:33 $ which file Dec 19 16:57:35 $ dpkg -S /usr/bin/file Dec 19 16:57:35 file: /usr/bin/file Dec 19 16:58:18 missing a line as it started with / Dec 19 17:03:43 *facepalm* Dec 19 17:03:49 need to go home -.-' Dec 19 17:08:39 does yocto use gitlab or github for patches yet? Dec 19 17:11:49 not yet Dec 19 17:22:19 rburton: yet? ;-) Dec 19 18:07:14 New news from stackoverflow: How to configure the Yocto devtool to update repo revision Dec 19 18:11:18 RP: YET :) Dec 19 18:12:33 :) Dec 19 18:13:35 RP:sent few patches cleaning after you :) Dec 19 18:14:07 musl was broken with the toolchain shuffle which is fixed now Dec 19 18:16:15 khem: thanks - I'd not got to fixing that yet! I just put the patches as they were onto the autobuilder for a test run, see how well it worked Dec 19 18:16:33 khem: basically there seems to be something wrong with the SDK (assimp fails) Dec 19 18:17:15 khem: not fixed mingw yet either Dec 19 18:17:26 no worries Dec 19 18:17:43 khem: ifunc seems broken on mips, not sure why I have to special case that :/ Dec 19 18:18:17 khem: the configure test fails before my patch, it passes after it, then throws those assertions Dec 19 18:18:30 RP: how does assimp fails ? Dec 19 18:18:42 khem: I assume you're in ok in principle with getting rid of these -initial bits? Dec 19 18:18:45 link Dec 19 18:18:52 totally Dec 19 18:18:59 /media/build1/poky/build/tmp/work/qemumips-poky-linux/core-image-sato/1.0-r0/testimage-sdk/assimptl80uuyi/assimp-4.1.0/test/../contrib/gtest/src/gtest-filepath.cc:58:26: error: ‘_POSIX_PATH_MAX’ was not declared in this scope Dec 19 18:18:59 # define GTEST_PATH_MAX_ _POSIX_PATH_MAX Dec 19 18:19:13 khem: there are failures on the AB like that too Dec 19 18:19:14 thats limits.h proble Dec 19 18:19:16 m Dec 19 18:19:30 khem: more like posix related Dec 19 18:19:42 khem: but yes, that area Dec 19 18:20:09 yes #ifndef _POSIX_PATH_MAX Dec 19 18:20:18 define _POSIX_PATH_MAX 255 Dec 19 18:20:22 #endif Dec 19 18:20:25 and move on :) Dec 19 18:20:55 khem: I think we need to understand how/why this broke ;-) Dec 19 18:21:02 sadly my test build built the wrong thing so waiting on the right one Dec 19 18:21:04 RP: btw. is it missing posix1_lim.h now ? Dec 19 18:21:15 khem: no, its there Dec 19 18:21:31 and it does not define this ? Dec 19 18:21:33 khem: I want to get two sdks and just diff them Dec 19 18:21:38 waiting on a build Dec 19 18:22:02 if that header is installed in sysroot then it should define _POSIX_PATH_MAX Dec 19 18:22:44 and then packages should get it via including limits.h Dec 19 18:28:09 RP: is that assimp problem only seen on mips ? Dec 19 18:30:52 RP: with new toolchain sequence I am now able to build musl systems too, so let me try qemumips build for assimp Dec 19 18:31:00 if that works then we know its glibc Dec 19 18:31:39 I think dropiing those config cache files can now be resulting in some configure failures silently disabling stuff in glibc Dec 19 18:33:39 khem: that was what I wanted to test on the AB and the answer is no, its on all archs Dec 19 18:34:03 RP: OK, it built ok here on x86/musl Dec 19 18:34:22 so its probably glibc Dec 19 18:34:31 is acting up during configure Dec 19 18:35:44 khem: quite likely. When I get this other build we'll see :) Dec 19 18:41:18 RP: it built ok for mips/musl combo Dec 19 18:41:41 khem: definitely a glibc issue then... Dec 19 18:42:09 RP: trying MACHINE=raspberrypi3-64 Dec 19 18:42:23 these are some hot cached builds lying around here Dec 19 18:44:17 hmmm its building here for raspberrypi3-64/glibc Dec 19 18:44:42 but I am using glibc 2.29+gcc-9.0 on top Dec 19 18:51:40 let see what I see on mips/glibc Dec 19 19:14:09 mips/glibc works too Dec 19 19:14:22 RP: so you might want to try with glibc 2.29 Dec 19 19:14:35 and see if that helps Dec 19 19:24:04 khem: I think limits headers in the SDK may be bust but I have a theory on why too Dec 19 19:27:03 can a screenshot be taken using sato/matchbox? Dec 19 19:52:50 khem: its a problem with gcc-cross-canadian Dec 19 19:53:15 khem: gcc is being a bit insane here but there is an easy fix Dec 19 20:04:34 khem: tests pass now, fixed it Dec 19 20:05:07 khem: will clean it up and try another AB run with your patches + mine Dec 19 20:11:24 RP: sounds good. If you push it to master-next I will give it a whirl here too Dec 19 20:12:17 yates: sato-screenshot should be in the image. Dec 19 20:38:36 rburton: I am seeing this issue with eSDK build https://github.com/YoeDistro/yoe-distro/issues/85 Dec 19 20:39:06 rburton: I see that the local.conf.bak is in /mnt/a/yoe/build/tmp/work/raspberrypi3_64-yoe-linux/yoe-simple-image/1.0-r0/sdk-ext/image/tmp-renamed-sdk/conf Dec 19 20:39:31 but its looking in /mnt/a/yoe/build/tmp/work/raspberrypi3_64-yoe-linux/yoe-simple-image/1.0-r0/sdk-ext/image//usr/local/oecore-x86_64/conf Dec 19 20:40:20 i see two errors in that bug Dec 19 20:40:39 would definitely want to fix the uni one first Dec 19 20:40:48 do you just get the conf one? Dec 19 20:41:05 the usr/local is worrying/odd Dec 19 20:41:10 pretty sure nothing in oe sets that Dec 19 20:41:54 so i suggest maybe this yoe whatever that is, has changed a path and is exposing an assumption in the esdk code Dec 19 20:41:59 at which point i point to bluelightning :) Dec 19 20:42:12 who me? Dec 19 20:44:00 hmm Dec 19 20:44:10 not sure off hand what might have led to that... Dec 19 20:44:38 unfortunately I'm in the middle of something so I can't dig into it myself Dec 19 20:49:41 rburton: yoe is derived from oe-core nodistro and does not set custom paths for SDK like poky does and I have a hunch thats the problem so if someone built sdk with oe-core nodistro will run into same error Dec 19 20:50:06 easily tested! Dec 19 20:51:50 yes, I am trying to mimic same with poky and lets see, it just means whole nativesdk components recompile Dec 19 20:52:06 if we change SDKPATH so will be a while Dec 19 20:52:32 can't wait to see the initial removal stuff land Dec 19 20:59:45 yes its panning out ok so far Dec 19 20:59:55 rburton: vercmp_string seems to ignore None strings Dec 19 20:59:59 thats one issue Dec 19 21:00:11 I guess we never test without uninative Dec 19 21:02:21 maybe split_version() should do parameter check before operating on it Dec 19 21:52:38 RP: I think there is problem related to uninative where anon python function in "meta/classes/uninative.bbclass" is not able to find the variables defined in meta/conf/distro/include/yocto-uninative.inc Dec 19 21:53:10 RP: I printed the variables and they come out to be unset Dec 19 21:53:35 when building -cpopulate_sdk_ext Dec 19 22:07:41 So, there really appears to be a bug in a overridden do_fetch not getting passed the SSH_AUTH_SOCK and SSH_AGENT_PID variables. Dec 19 22:08:39 I tried to force them available by doing 'export SSH_AGENT_PID' and 'export SSH_AUTH_SOCK' but this leaves them undefined as well in my overriden do_fetch method. Dec 19 22:09:13 Should I report this upsstream to this list: https://bugzilla.yoctoproject.org/buglist.cgi?product=BitBake&component=bitbake&resolution=---? Dec 19 23:07:01 khem: I've updated -next with revised patches Dec 19 23:07:24 khem: how are you including yocto-uninative? Dec 19 23:26:03 RP: OK I started few builds here with master-next + my goop Dec 19 23:26:26 RP: yocto-uninative is added exactly like its done in poky.conf Dec 19 23:26:54 khem: to your own distro.conf ? Dec 19 23:27:20 khem: ordering is important in this case Dec 19 23:27:51 yes first include the .inc and then inherit class Dec 19 23:28:39 see https://github.com/YoeDistro/meta-yoe/blob/master/conf/distro/yoe.conf#L73-L77 Dec 19 23:30:07 khem: does bitbake -e show the variables as set? Dec 19 23:30:40 yes it does however during do_populate_sdk_ext its unset Dec 19 23:30:59 if I include the content from .inc file into bbclass itself then it works Dec 19 23:31:20 so it seems there are two places where the variable it needed Dec 19 23:31:28 normal images build ok Dec 19 23:31:36 problem is when doing sdk_ext builds Dec 19 23:32:03 on same machine poky build works for core-image-minimal sdk Dec 19 23:33:58 khem: it sounds as if the copy_buildsystem piece doesn't understand your layer/distro :/ Dec 19 23:34:40 what does it need to know ? Dec 19 23:34:54 khem: it tries to copy the config into this new "build" environment and it sounds a bit like it messes it up somehow Dec 19 23:35:09 khem: corebase, sdkbblayers = buildsystem.copy_bitbake_and_layers(baseoutpath + '/layers', workspace_name) Dec 19 23:35:31 khem: probably need to look at what it created and see what is wrong with it Dec 19 23:36:03 is it problem how the layers are placed ? Dec 19 23:36:13 khem: could be Dec 19 23:36:33 we really need a setup tool and to standardise more Dec 19 23:37:41 so it is creating content under /mnt/a/yoe/build/tmp/work/raspberrypi3_64-yoe-linux/yoe-simple-image/1.0-r0/sdk-ext/image/tmp-renamed-sdk Dec 19 23:37:48 which seems to have found the layers etc. Dec 19 23:42:19 RP: have you used other layers along with core layer in some test cases Dec 19 23:43:33 khem: not as well as we should, no Dec 19 23:44:06 so whats the assumptions it makes Dec 19 23:44:11 about workspace ? Dec 19 23:44:31 how/where are layers expected ? under poky/openembedded Dec 19 23:44:38 top level layer ? Dec 19 23:44:48 that is parallel to meta/ ? Dec 19 23:47:00 I added a layer outside that to poky lets see if it fails in same way Dec 19 23:49:11 RP: here is error I see https://8n1.org/14223/32e3 Dec 19 23:51:50 khem: that last bit is error handling failing :( Dec 19 23:52:00 khem: the real problem is further back Dec 19 23:52:39 khem: I don't remember the assumptions unfortunately, this was done by bluelightning but I don't think any of us liked the end result, its fragile :( Dec 19 23:52:48 here is full log https://gist.github.com/9ee0302407d29fdf17e7db098256f71e Dec 19 23:54:25 khem: is something in workspace which would change the signatures? Dec 19 23:54:35 so when its excluded you hit failures? Dec 19 23:55:25 so let me undo my change to copy content of yocto-uninative.inc into uninative.bbclass Dec 19 23:56:05 RP: this is full real error https://github.com/YoeDistro/yoe-distro/issues/85 Dec 19 23:57:54 khem: it looks to me like its not copying the layers/setup correctly somehow Dec 20 00:13:35 khem: if you can't spot the issue, send me a note of the config and I can try and reproduce and investigate tomorrow Dec 20 00:13:58 RP: ok Dec 20 00:14:00 thx Dec 20 00:14:16 RP: reproduced with poky Dec 20 00:14:41 khem: we test esdk heavily with poky, what did you change? Dec 20 00:14:44 RP: clone another layer parallel to poky and then add that layer to bblayers.conf in normal poky build Dec 20 00:15:04 I cloned meta-openembedded parallel to poky Dec 20 00:15:15 then added meta-openembedded/meta-oe to bblayers.conf Dec 20 00:15:30 bitbake -cpopulate_sdk_ext core-image-minimal Dec 20 00:15:42 ended in same error as I am seing Dec 20 00:16:15 BBLAYERS ?= " \ Dec 20 00:16:17 /mnt/a/yoe/sources/meta-openembedded/meta-oe \ Dec 20 00:16:19 /home/kraj/work/poky/meta \ Dec 20 00:16:21 /home/kraj/work/poky/meta-poky \ Dec 20 00:16:22 khem: the uninative checksum going missing? Dec 20 00:16:23 /home/kraj/work/poky/meta-yocto-bsp \ Dec 20 00:16:25 " Dec 20 00:17:14 the second error is a comparatively well known issue which is a config difference somewhere. The first one is much more unusual Dec 20 00:17:29 RP: not that one but the second error https://gist.github.com/aaef616cc8788be2571ed5aa2d11e86c Dec 20 00:17:43 I see Dec 20 00:18:44 khem: the second one means it didn't replicate the config enough to get matching task hashes Dec 20 00:21:54 and I think its trying to add layers relative to its own location see ERROR: Layer directory '/home/kraj/work/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/../../../mnt/a/yoe/sources/meta-openembedded/meta-oe' does not exist! Please check BBLAYERS in Dec 20 00:21:56 /home/kraj/work/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/conf/bblayers.conf Dec 20 00:27:02 RP: my distro does not use oe-init-build-env script at all Dec 20 00:27:13 I wonder if that is a difference **** ENDING LOGGING AT Thu Dec 20 03:00:01 2018