**** BEGIN LOGGING AT Tue Aug 01 03:00:00 2017 Aug 01 06:42:01 good morning Aug 01 12:14:47 hi. i am overlaying glmark2 recipe in my own layer, and somehow oe picks the 'old' version, instead of the new one. not sure why. Aug 01 12:14:47 glmark2: Aug 01 12:14:47 meta-oe 2014.03+AUTOINC+fa71af2dfa Aug 01 12:14:47 meta-backports 2017.07+AUTOINC+182dcbffe5 Aug 01 12:15:06 could be it because PV is set 'in' the recipe, and the recipe file is glmark2_git.bb? Aug 01 12:47:03 can I get access to compiler toolchain on bitbake host without having to populate an SDK, install it and source the environment? something like devshell but not specific to a recipe? Aug 01 12:53:37 how is BBMULTICONFIG to be used? Is it expected that with 'BBMULTICONFIG="debug release"' a 'bitbake foo' is be a synonym of 'bitbake multiconfig:debug:foo multiconfig:release:foo'? here (oe + bitbake master), it seems that both BBMULTICONFIG and the 'multiconfig:...' target must be set which looks redundant to me Aug 01 13:13:40 ndec: that won't make a difference, but meta-oe has a high priority and tends to override other layers. i noticed bitbake preferring the old re2c in meta-oe over the upgrade in oe-core last night. Aug 01 13:22:07 ensc|w: 'bitbake foo' is not a synonym of 'bitbake multiconfig:debug:foo multiconfig:release:foo' Aug 01 13:32:22 RP: for what is BBMULTICONFIG required then? it seems to be completely redundant with the 'multiconfig:...' target Aug 01 13:34:59 rburton, we should figure out some reasonable ways to set payer priorities Aug 01 13:35:31 meta-oe should be the same as core Aug 01 13:35:48 what is it now? Aug 01 13:36:10 also, how woould other layers relate Aug 01 13:36:24 oe-core is 5, meta-oe is 6 Aug 01 13:36:35 i'd say all "load of recipes" layers should be the same as core Aug 01 13:36:37 and other layers are higher Aug 01 13:36:55 meta-gnome for some reason is 7 Aug 01 13:36:57 maybe we should rename name meta-oe to core-extended :) Aug 01 13:36:59 its like they're just making up numbers Aug 01 13:36:59 ensc|w: it states which multiconfigs to parse Aug 01 13:37:14 rburton, that is what I suspect also Aug 01 13:39:03 RP: but why does bitbake need to parse all (or any) multiconfig when I just say 'bitbake foo'? Aug 01 13:39:28 multiconfigs seem to be implied by the actual 'multiconfig:...' target Aug 01 14:09:40 bluelightning, awake? Aug 01 14:10:24 Crofton|work: I am yes Aug 01 14:10:44 ensc|w: I guess that from an implementation perspective, setting BBMULTICONFIG was easier and it also made it easier to think about inter-multiconfig dependencies later Aug 01 14:11:00 do you mind if I submit a patch to not run the stripped QA thing for qwt in meta-qt4? Aug 01 14:11:08 is now an error in poky Aug 01 14:11:14 ensc|w: You're right you could theoretically figure out the multlibs but it wouldn't be easy with the current code structure Aug 01 14:11:17 and not really worth fixing with qt5 Aug 01 14:11:27 ensc|w: also, we do support bitbake mutliconfig:*:xxx Aug 01 14:11:28 qt5 version doesn't have the issue Aug 01 14:11:41 Crofton|work: yep that should be fine Aug 01 14:11:50 ok Aug 01 14:12:02 wanted to check before submitting it Aug 01 14:12:22 Crofton|work: if it were somewhere we maintain then I'd prefer fixing it, but that layer is on life support so it's different Aug 01 14:12:24 we also have a sip mismatch in pyro, which is breaking pyqt Aug 01 14:12:29 right Aug 01 14:12:39 I did check if fix was needed in qt5 Aug 01 14:12:45 different issues there :) Aug 01 14:18:31 rburton: Just sent mesa/llvm updates Aug 01 14:56:08 rburton: thanks. that was the layer priority , indeed. easy to fix since our layer should have high priority.. Aug 01 14:56:17 khem: they work \o/ Aug 01 14:57:14 rburton: you have to tell me . They built ok for me, Aug 01 14:57:58 layer priorities I realy dont like them, it just creates confusion Aug 01 14:58:27 and semantics doesnt cover all types of metadata Aug 01 14:59:18 khem: i mean, mesa built with llvm Aug 01 14:59:37 ah you were asserting Aug 01 14:59:41 cool Aug 01 16:05:58 A topic for OEDEM: https://lwn.net/SubscriberLink/729366/7ee376c75461c395/ Aug 01 16:06:09 and layer priority guidance Aug 01 16:09:25 oh i wonder what fedora is saying Aug 01 16:10:11 not sure i'd want to redirect /usr/bin/python to py3 Aug 01 16:10:18 seems like that will just break things Aug 01 16:11:35 rburton: archlinux is using py3 as py for many years Aug 01 16:12:04 so we need to see if we can get OE to not demand py2 Aug 01 16:12:12 or atleast not as py Aug 01 16:12:23 khem: yes we can blame arch for this problem in the first place Aug 01 16:12:34 a target doesn't contain py2 anymore Aug 01 16:12:39 we could always provide 'python' as python2 ourselves, i.e. add a little wrapper script under scripts/ the way we've done for so many other things Aug 01 16:12:43 but a few pieces still expect py2 on the host Aug 01 16:12:47 we know our buildsystems will expect that Aug 01 16:13:18 kanavin can probably remember what bits demanded py2 on the host, he patched several out Aug 01 16:13:22 though most won'te even need that, what with python-native Aug 01 16:13:33 well pretty sure we don't even build that for eg sato Aug 01 16:13:38 well Fedora just extended their time scale to get rid of python3 requirements.. Aug 01 16:13:50 I think it's reasonable as long as a full transition 'off' before 2020.. (python2 EOL) Aug 01 16:14:08 yeah raise the danger bar and suddenly you are not in flood zone Aug 01 16:14:11 (and IMHO redirecting /usr/bin/python to python3 is insane.. even after 2020) Aug 01 16:14:28 what fray said Aug 01 16:14:32 still, adding a script seems trivial. just make 'python' run 'python2' if it exists, 'python' otherwise, and adjust our sanity check to do that too Aug 01 16:14:33 agreed Aug 01 16:15:18 at WR we provide both python2 and python3 with our product. We can't rely on the host having a functioning version.. (RHEL 7 is pretty bad, and 6 is nearly unusuable by today's standards) Aug 01 16:15:19 thanks to arch being arch, very little actually calls /usr/bin/python in oe Aug 01 16:15:20 fray: while I agree its crude way to force people to move forward, it is getting right results i.e. port to py3 Aug 01 16:15:47 and ensure that no new py code is written for py2 Aug 01 16:15:49 for a smaller distro like 'arch', they can get away with it.. but I don't expect Debian/Ubuntu or Fedora/RH/CentOS to do so Aug 01 16:15:58 no new code for py2 is a valid goal... Aug 01 16:16:16 but I'd prefer no /usr/bin/python -at all-, vs having it map to python3 Aug 01 16:16:28 before you fix leaks you need to shut the valve Aug 01 16:16:57 remove python2.. stop /usr/bin/python from existing.. that is how I'd handle it Aug 01 16:16:58 | ../../diffutils-3.6/lib/getopt1.c:50:55: error: expected ';', ',' or ')' before '*' token Aug 01 16:16:58 | getopt_long_only (int argc, char *__getopt_argv_const *argv, Aug 01 16:17:02 fray: agreed Aug 01 16:17:04 ... huh. anyone seen this one before? Aug 01 16:17:33 * fray hasn't seen that before Aug 01 16:17:43 fray: remove py2 from test machine, make oe work. then remove from autobuilders so it can't sneak back in. Aug 01 16:17:53 rburton yup Aug 01 16:18:00 if you want to be really sure, remove it from hosttools Aug 01 16:18:15 yeah remove it from hosttools Aug 01 16:18:21 is good Aug 01 16:18:21 that is what we've been trying to do for some of the products we building using the YP.. the build side, we don't care as much Aug 01 16:18:47 we have our how hosttools-tarball.. since the (morty) version didn't have everything needed to run toaster (and some other things) Aug 01 16:18:54 our -own- Aug 01 16:20:34 from a glance at oe-core we only build python-native if we need to use python-scons-native or python-setuptools-native Aug 01 16:21:12 scons only comes in if you build subversion-native Aug 01 16:21:39 rburton: http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=e5697ed41f3cf23b897e2ca9e55e994a386d8e64 Aug 01 16:21:44 not sure what you mean by that, considering distutils-base inherits pythonnative, last i checked Aug 01 16:21:47 did that change? Aug 01 16:21:57 hm Aug 01 16:21:59 its final glibc 2.26 if you have cycles please throw it in Aug 01 16:22:07 might be a place to add a deprecated warning 'pythonnative'? Aug 01 16:22:09 pretty sure anything remotely python related sucks in python-native Aug 01 16:22:11 damns Aug 01 16:22:14 before it releases tomorrow we still have a day to report problems Aug 01 16:22:16 it's in nearly every build i do, one way or another Aug 01 16:22:21 well, luckily almost nothing needs py2 ;) Aug 01 16:22:27 yeah, true, not as much anymore Aug 01 16:22:51 * kergoth is still mostly on morty at work, need to catch up with master Aug 01 16:23:14 kergoth: that error seems to me that its mixing getopt from libc and gnulib Aug 01 16:23:28 ah, thanks, will check the configure tests Aug 01 16:24:17 kergoth - day to day I'm using morty.. but I'm working on master (luckily) Aug 01 16:25:20 nice. i've gotten maybe 4-8 hours a week to do basic build sanity testing with master :\ Aug 01 16:25:25 need to work on the patch submission queue Aug 01 16:28:08 lol, I never said I get to build master ;) just working on master integration (bitbake mostly right now) :) Aug 01 16:28:15 luckily bitbake-selftest works.. ;) Aug 01 16:28:40 ah Aug 01 16:28:50 i need to take a look at that layer fetching series, haven't had time yet Aug 01 16:29:49 work so far was centered around basic infrastructure and making bitbake-layers work.. Aug 01 16:30:02 it's possible to define multiple layer indexes. (but not easily -- yet.. I've done it in testing) Aug 01 16:30:29 rburton: last time you reported locale issues with glibc patch, hoping this is addressed with this glibc patch Aug 01 16:30:35 (not easily is intentional until I get time to work on the toaster piece.. I'm trying to unify the interface between toaster and bitbake-layers layerindex-* Aug 01 16:30:41 khem: fingers crossed Aug 01 16:30:51 rburton: did you pick the glibc ? Aug 01 16:31:01 RP: bitbake server broke -g Aug 01 16:31:55 oh no it didn't Aug 01 16:32:29 that reminds me, the NOTE about the server starting when running bitbake-layers add-layer or remove-layer is a bit silly, especially since there's no such note about shutting it down Aug 01 16:32:36 ...once the itnerfaces are unified.. then it should be pretty easy to implement the setup tool.. so you can just start with bitbake and pull down and entire project.. Aug 01 16:32:36 khem: didnt see an update to the broken one? Aug 01 16:33:14 awww we build python-native for quite a few bit Aug 01 16:33:26 kergoth I never worked in that section... Paul did add a small change to stop parsing when using the bitbake-layers layerindex-* commands.. really sped things up a lot Aug 01 16:33:35 nice Aug 01 16:33:39 rburton: I will send to ml Aug 01 16:33:51 i still need to submit the bits to let bitbake-layers only parse bblayers, not bitbake.conf, for the bblayers manipulation commands Aug 01 16:34:17 I don't think that is bitbake-layers, that digs into tinfoild oesn't it? Aug 01 16:34:26 not jsut tinfoil, even cooker Aug 01 16:34:31 which is why i haven't submitted it yet, it's a mess Aug 01 16:34:33 the load of the bitbake.conf through bblayers is pretty 'simple' Aug 01 16:34:38 cooker paress it in the constructor, iirc Aug 01 16:34:42 (speed wise).. it's the recipe parse that takes bloody forever Aug 01 16:34:43 okay too late to chase py2 deps Aug 01 16:34:49 yeah, true Aug 01 16:35:02 the bitbake-layers already has a switch to disable the recipe parse piece.. Aug 01 16:35:25 I started hacking on a 'bitbake-setup' (just to test the other components) and ended up not being able to use tinfoil because of all of that.. Aug 01 16:35:45 I'm not too concerned cause I don't really need the cooker or UI backends.. and the data piece works fine without the others Aug 01 16:35:59 (and if data is initialized, then bb.fetch works) Aug 01 16:36:35 * kergoth nods Aug 01 16:37:28 in the bitbake-contrib mgh/bitbake-setup layer the top commit is the little test bitbake-setup I have.. it only implements a query function right now.. calling it require the last parameter to be a .conf file to load.. the only required bit in the file is the reference to one or more upstream repository.. Aug 01 16:38:00 BBLAYERINDEX_URI = "http://layers.openembedded.org/layerindex/api/;type=restapi;branch=morty" Aug 01 16:38:15 put that in a new file, pass that in as the .conf and you can play with the basic query pieces Aug 01 16:38:29 += more layer indexes and you can verify multiple indexes load.. Aug 01 16:38:35 (pretty simple) Aug 01 16:39:25 I should add a dependency resolution query to the test functionaly.. (bitbake-selftest DOES do that kind of verification .. this is more for visual demo/debug) Aug 01 17:37:58 grumble, bb whatdepends doesn't work with new bitbake Aug 01 17:38:16 yeah.. the tinfoil changes.. that command heavily used a bunch of internal stuff Aug 01 17:38:22 i think paul has added enough to tinfoil recnetly to fix it, though Aug 01 17:38:26 just never got around to it Aug 01 19:55:56 I'm seeing a build failure in glibc 2.25 building the i586 version in multilib on pyro, that ring bells for anyone? Aug 01 19:56:56 https://www.irccloud.com/pastebin/MNB9r1Y2/ Aug 01 19:58:39 s/i586/i686/ Aug 01 21:56:03 khem, nice touch, thx. Would never imagined klibc builds with clang so easily Aug 01 22:05:15 khem, please send upstream. People are depressed: they are receiving only spam on the ML Aug 01 22:14:16 ant_home: it doesnt yet Aug 01 22:14:28 there is a header issue Aug 01 22:14:34 probably a minor one Aug 01 22:14:58 it wraps stdarg.h and clang does not like it Aug 01 22:16:46 can you fix it with reordering? Aug 01 22:22:44 khem, buildroot of today has gcc 7.x Aug 01 22:23:01 they defaults to arm code, not thumb Aug 01 22:23:15 I switched to thumb to reproduce the kernel issue Aug 01 22:23:33 let see Aug 01 22:24:03 gcc options defaults to empty? Aug 01 22:24:09 bah Aug 01 22:32:24 ok Aug 01 22:40:01 buiulding with LTO Aug 01 22:40:23 I see there is OpenMP for LLVM Aug 01 22:40:31 did you try it? Aug 01 22:40:46 for linux-kernel >4.x? Aug 01 22:56:15 good night **** ENDING LOGGING AT Wed Aug 02 03:00:01 2017