**** BEGIN LOGGING AT Thu Dec 20 03:00:01 2018 Dec 20 05:29:46 I saw a mention in the Yocto Ref Manual that rm_work could actually speed up builds. It seems a bit unintuitive to me, but I guess disk caching benefits might be tricky to grasp. Anyone know of benchmarks or so that can show some results? Dec 20 09:09:25 khem: ah, it was site/conf? Dec 20 09:15:48 I have a few git autoinc recipes, but our internal git server is momentarily down. Why is it a fatal error if it can't check for updates? It has all the code. Dec 20 09:16:30 RP: want to pull my ranlib thing into next too? Dec 20 09:16:43 best give it a nice message Dec 20 09:20:19 arg.. I can't even build any other recipe, because all the git ones give fatal errors, while they should be up to date. Dec 20 09:24:44 I found some reference to BB_SKIP_NETTESTS=yes, but this does nothing at all. Dec 20 09:27:53 rburton_: that should be in the next round, yes Dec 20 09:33:32 Is there any way to skip fetching these recipes? Dec 20 09:53:17 pepijndevos: set srcrev to the current sha you have? Dec 20 09:56:41 That would be annoying but workable if the git server stays down for long enough. Dec 20 09:57:09 Different and odd issue: /bin/systemctl does not have execute permission. Dec 20 09:57:32 -rw-r--r-- Dec 20 10:29:58 so what happens if there are several .bbappend files to the same recipe? Dec 20 10:30:10 all of them are applied in some uncertain order? Dec 20 10:30:56 varjag: layer priority should apply Dec 20 10:34:41 so, in order of decreasing PV? Dec 20 10:34:50 or, wait, should it be increasing Dec 20 11:10:02 Stupid question that I can't seem to find in the "user" manual with a ton of "user" configuration is how to actually add a custom user, other than passwordless roos Dec 20 11:10:05 *root Dec 20 11:15:15 pepijndevos: there is an example in meta-skeleton Dec 20 11:17:26 thanks Dec 20 11:19:22 rburton: going to rerun -next with a couple of small tweaks like mingw fix, see if we can get a clean pass before we test more patches Dec 20 11:19:31 cool Dec 20 11:56:51 rburton: what would be a good GL thing to run that provides better eye candy than glxgears? (preferably available in oe-core) Dec 20 12:00:53 kanavin: as a test or what? Dec 20 12:01:19 i've been meaning to knock up a recipe for https://benchmark.unigine.com/valley but that's quite a lot larger than glxgears Dec 20 12:01:31 pretty though Dec 20 12:01:38 rburton: both test and demo Dec 20 12:01:58 valley then, it's not open source but free to use Dec 20 12:02:21 well, not commercialy Dec 20 12:02:29 would have to read the terms Dec 20 12:03:18 they also have a couple other benchmarks Dec 20 12:04:46 tropics is a lot smaller and doesn't say non-commercial Dec 20 12:06:34 if i have an autotools based recipe, can i still use do_install there? Dec 20 12:06:43 to install some binary blobs to certain paths Dec 20 12:10:53 rburton: can you look at the last oe-selftest failure. We have a problem in the connection code :( Dec 20 12:12:15 rburton: hmm, triggered by the patch from robert Dec 20 12:12:37 varjag: do_install_append to do your custom bits Dec 20 12:13:00 rburton: oh, they're all racing each other Dec 20 12:13:21 rburton: thanks. the recipe is mine, i.e. it's not an append file Dec 20 12:13:34 should i use do_install_append vs do_install still? Dec 20 12:13:51 varjag: didn't say it was. yes. you write a do_install_append to append to do_install, which is provided by autotools.bbclass Dec 20 12:13:56 there are other ways, that's the easiest Dec 20 12:14:10 i see, thanks Dec 20 12:14:19 you could write do_install() and inside it call autotools_do_install and then your stuff Dec 20 12:17:06 ah, so that's how it works Dec 20 12:39:20 rburton: I was wondering why cmake is so slow :) Dec 20 12:39:40 with autoconf had a parallell button! Dec 20 12:39:45 s/with/wish/ Dec 20 12:40:58 New news from stackoverflow: Update the Yocto recipe with devtool Dec 20 12:47:40 rburton: there are more recipes that we can (and should) convert to meson Dec 20 12:47:42 e.g. mesa, glib Dec 20 12:48:01 koen has a patch for mesa in progress Dec 20 12:51:19 I wonder if there's anything interesting in mesa-demos Dec 20 13:20:01 rburton, heh, when I poked you about mipsel site endianness I did not imagine it would lead to the complete removal of siteconfig :) Dec 20 13:20:22 DIE DIE DIE Dec 20 13:20:35 pull a thread and look what happens Dec 20 13:20:53 variety of pieces came together Dec 20 13:21:11 i benchmarked it a few weeks ago and knew it was not as useful as assumed Dec 20 13:21:21 then RP discovered that the only thing keeping glibc-initial around with siteconfig Dec 20 13:25:16 I'm firing a build to test that Dec 20 13:27:35 with musl actually Dec 20 13:28:11 mipsel ;) Dec 20 13:38:50 and then I started looking at why we needed gcc-initial :) Dec 20 13:39:27 rburton: merge the non gcc pieces of -next? Dec 20 13:39:41 btw I read today in one forum that OE suxx because cross-localedef is built with the buildhost headers Dec 20 13:39:54 the -native ofc Dec 20 13:40:26 what was the problem? they have olg glibc < 2.28 Dec 20 13:41:05 ant_home: it should probably use target headers Dec 20 13:41:35 ant_home: well, hmm. glibc did mess the locale formats around recently :( Dec 20 13:41:51 ah Dec 20 13:42:07 ant_home: or do you mean they were using an old target glibc with a modern cross-localedef ? Dec 20 13:42:23 https://github.com/OpenPLi/openpli-oe-core/commit/257d59839ab82787a80d68355ced551c075e8f2a Dec 20 13:42:43 they are moving to sumo now, I am helping toward thud Dec 20 13:43:56 ant_home: if the OE developers are unaware there is a problem its less likely to get fixed Dec 20 13:44:20 heh Dec 20 13:44:33 doesn't uninative help right here? Dec 20 13:44:45 ant_home: uninative doesn't have headers, so no Dec 20 13:44:53 ok Dec 20 13:45:28 so it looks like host-contamination afais Dec 20 13:46:37 RP: last time I had problems was when gentoo had a strange glibc, years ago. Just once. Dec 20 13:46:53 ant_home: https://github.com/kraj/localedef - talk to khem but I think we may have sorted this Dec 20 13:47:07 remember they lag years behind :/ Dec 20 13:47:36 ant_home: yes, I think it could have been fixed Dec 20 13:48:37 I have just told them only minor changes are needed between sumo and thud. Did I lie? Dec 20 13:48:45 ;) Dec 20 13:50:47 ant_home: khem's localedef has been around for a long time looking at the history, so no Dec 20 13:56:18 rburton: glxgears FPS jumps ten-fold in qemu \0/ Dec 20 13:56:27 from 15ish to 160 or more Dec 20 13:57:04 rburton: shouldn't meson be provided with the toolchain, if an image's recipe `inherit meson`?. Dec 20 13:57:20 oh, and: X rendering is done via glamor, and looks fine Dec 20 13:58:04 T_UNIX: meson class is for building software, similar to autotools or cmake classes Dec 20 13:58:28 i.e. `foo.bb` contains `include meson`. `foo` is part of `bar-image`. Then `bitbake bar-image -c populate_sdk` should populate the generated sdk with meson, shouldn't it? Dec 20 13:59:45 kanavin: so I'd need to write another recipe that would `inherit crosssdk` Dec 20 14:00:58 T_UNIX: no :/ Dec 20 14:01:25 T_UNIX: "inherit meson" means this recipe uses meson to build, it doesn't have any affect on the sdk Dec 20 14:01:33 I got that Dec 20 14:02:03 T_UNIX: you'd want to include nativesdk-meson in the SDK through the normal sdk package inclusion mechanism Dec 20 14:02:18 assuming nativesdk-meson exists Dec 20 14:02:36 if it doesn't you'd then need to BBCLASSEXTEND meson to nativesdk Dec 20 14:02:57 RP afaics it does not exist yet Dec 20 14:03:26 T_UNIX: I see a nativesdk-meson .bb file here Dec 20 14:04:11 RP: where's is that? Dec 20 14:04:22 damn. likely sumo or even newer? Dec 20 14:04:29 T_UNIX: master Dec 20 14:05:27 thud has it too Dec 20 14:05:47 if you're using an old release, you'll be best to just copy/paste the recipes and classes from thud Dec 20 14:06:21 huh we don't have a meson test for the sdk yet Dec 20 14:06:38 RP: permission to add nativesdk-meson to core-image-sato's sdk task sir Dec 20 14:06:58 rburton: if you mean the packagegroup for tools, yes Dec 20 14:07:22 that's the debate: all toolchains? Dec 20 14:08:38 rburton: looking at the other stuff in it and the fact it has minimal depends, nativesdk-packagegroup-sdk-host should be ok? Dec 20 14:08:46 yeah just done that Dec 20 14:09:20 rburton: cmake, opkg, unfs3 Dec 20 14:09:36 that darwin override looks a bit sad Dec 20 14:10:05 rburton: RP: thanks :) Dec 20 14:10:19 RP: awwww lonely Dec 20 14:38:34 i have matchbox/sato running in a session, and i've updated a desktop file but matchbox/sato doesn't appear to be picking up the mod. is there a way i can get matchbox/sato to update (reload) the .desktop files from the command line? Dec 20 15:07:54 Hi,I am using yocto 2.5, and I get an error when I do "import json" with python3, as if the module was missing, shouldn't it be part of python's standard lib? Dec 20 15:40:08 RP: yes now its working Dec 20 15:40:16 RP: i am seeing http://errors.yoctoproject.org/Errors/Details/212931/ Dec 20 15:49:31 joseppc: you probaby failed to install all of python. install python3 explicitly and you'll get the full runtime Dec 20 15:52:30 rburton: ok, thanks Dec 20 16:13:59 hi! Dec 20 16:20:18 the "logging" module isn't installed for python 2.7.15 Dec 20 16:20:54 did you install all of python? install 'python' (or python-modules if you're using an old release) Dec 20 16:21:26 kergoth: dude i can't pm you Dec 20 16:23:55 I see all the python tasks in the packages lists for "bitbake -g -u taskexp " Dec 20 16:24:00 python.do_build Dec 20 16:24:02 khem: interesting. My aarch64 tests passed. What is different about that build? Dec 20 16:24:06 python.do_compile Dec 20 16:24:08 etc. Dec 20 16:24:36 its using glibc 2.29 Dec 20 16:25:00 In my recipe I've "python-simplejson", "python-subprocess" and "python-psutil" as RDEPENDS packages Dec 20 16:29:11 didile: so you're getting those (and the bits of the core library that they use) Dec 20 16:29:30 zeddii, h Dec 20 16:29:32 i Dec 20 16:29:34 didile: easy fix: just rdepend on python-modules, and you'll get the whole standard library Dec 20 16:29:35 something wrong with the kernel scripts using musl Dec 20 16:29:42 didile: (added to the ones you already have) Dec 20 16:29:59 zeddii, any hint? https://imagebin.ca/v/4QfWPH8sYB3S Dec 20 16:30:30 should I add "python" as RDEPENDS in my python recipes? Dec 20 16:32:00 I already use "inherit setuptools" Dec 20 16:32:10 hi Dec 20 16:32:38 "logging" is part of the standard python library Dec 20 16:32:39 I upgraded to Sumo and a new version of u-boot 4.9 Dec 20 16:32:52 and i seem to be running into a build issue Dec 20 16:33:41 says "cc1: warning unknown register name :x18 Dec 20 16:33:49 ant_home. which kernel version is that ? I've never hit that with my musl build here. i might just not be building the same kernel versions. Dec 20 16:34:15 it's an old mipsel 3.13.5 Dec 20 16:34:22 holy lag from me typing that to it coming through Dec 20 16:34:34 * zeddii clearly needs to debug Dec 20 16:34:38 strangely build fails with musl tc Dec 20 16:34:48 maybe it's the initial scripting Dec 20 16:35:01 with musl, the assemble thinks it's a mips3 Dec 20 16:35:12 maybe bad-cut mips32 ? Dec 20 16:35:52 83: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f0,272+0 Dec 20 16:35:52 ($4)' Dec 20 16:36:14 hmm. interesting. Dec 20 16:36:30 both gcc's clearly pass -mel -mabi=32 -mhard-float -march=mips32 Dec 20 16:39:56 khem: ah, so its failing with 2.29? Not good Dec 20 16:44:31 how can I mute this 'your distro is not supported blablabla warning'? Dec 20 16:44:59 apteryx: SANITY_TESTED_DISTROS = "" Dec 20 16:45:05 thanks Dec 20 16:45:31 RP: so new tc w/out *initial is failing with glibc 2.29? Dec 20 16:45:43 I tested both separately... Dec 20 16:45:59 ant_home: for aarch64 for khem Dec 20 16:46:16 I see Dec 20 16:47:59 RP: am I supposed to just export this env var? Or is it a config to be written to a specific file? Dec 20 16:55:47 RP: its working on my local box though which uses gcc9+glibc2.29 so maybe glibc 2.29+gcc8+latest-toolchain-changes is the problem Dec 20 16:55:52 zeddii, the Makefiles are equal Dec 20 16:56:10 100% Dec 20 16:56:14 RP: I know glibc 2.29 worked across all arches few days ago Dec 20 16:59:13 hmmm Dec 20 17:03:22 why have so many YP Engineering Sync meetings been canceled? (e.g. Feb 5, Mar 5, Apr 2) Dec 20 17:04:14 are the technical team meetings for those days also canceled? Dec 20 17:05:35 khem: very odd :( Dec 20 17:12:31 tlwoerner: I suspect Stephen is trying to cancel the one next week Dec 20 17:13:00 RP: with a shotgun, apparently ;-) Dec 20 17:13:28 tlwoerner: you dont support automatic weapons :) Dec 20 17:13:48 zeddii: did you pickup aarch64 fixes for kernel, Dec 20 17:15:10 RP: I am testing a lot of combinations, I guess once the toolchain sequence changes settle in and we look to upgrade glibc to 2.29 we might see it or if you have AB cycles throw 2.29 in and see if you can reproduce it too Dec 20 17:17:50 khem. I have them queued, was it just the 3 patch series you pointed me at yesterday ? Dec 20 17:18:09 yes, that will make my musl builds on aarch64 lot greener Dec 20 17:19:36 ok. I'll finish up my testing and send them out ASAP. Dec 20 17:21:09 ty zeddii Dec 20 17:22:16 Hi, I am seeing this as a build error when i try to build my image Dec 20 17:22:21 u-boot-controltech/2017.03-r0/git/scripts/Makefile.build:316: recipe for target 'arch/arm/cpu/armv8/exceptions.o' failed make[2]: *** [arch/arm/cpu/armv8/exceptions.o] Error 1 Dec 20 17:22:52 NeilS: the error should be up in logs as to what compiler is saying Dec 20 17:23:24 let me check Dec 20 17:25:33 starts here i guess Error: bad instruction `stp x29,x30,[sp,#-16]!' Dec 20 17:26:01 there are a bunch of cc1: warning: unknown register name: x18 before that Dec 20 17:26:49 are you using 32bit compiler by any chance ? Dec 20 17:27:12 or passing -mabi flag which turns on 32bit Dec 20 17:29:15 I just changed it so instead of using the 2015 uboot it build the 2017.. So i haven't really changed any flags just branches and revisions Dec 20 17:29:42 hmm then it must be in the Makefiles etc. of uboot Dec 20 17:29:42 can i force the right flags in the recipe or environment variables? Dec 20 17:29:59 that instr is a valid for 64bit arm Dec 20 17:33:46 ok.. this uboot is from variscite. They might know something or have a patch Dec 20 17:57:06 khem: FWIW MACHINE=qemuarm64 bitbake glibc with 2.29 worked here Dec 20 18:00:30 JPEW: I put a patch for mingw in master-next for the gcc-initial changes Dec 20 18:00:46 JPEW: it passed testing Dec 20 18:11:21 RP: thats a good news Dec 20 18:11:49 RP: that only means its self-inflicted pain somewhere for me :) I will figure it Dec 20 18:12:18 RP: can I get a full test run with glibc 2.29 when ABs can Dec 20 18:14:44 RP: this will make it smooth slip in for glibc 2.29, since gcc 9 will come out around in April so its good to settle the big boulders early Dec 20 18:16:44 Support for the Armv5 and Armv5E architectures (which have no known implementations) has been removed. Note that Armv5T, Armv5TE and Armv5TEJ architectures remain supported. Dec 20 18:16:55 so we are on the edge now for qemuarm Dec 20 18:32:46 ok figured out the issue with the u-boot build. A few options were not defined in the defconfig since we have our own defconfig. It's similar to the mx6 with a couple of options changed. I'm guessing the newer version of u-boot needed them. Additioanlly I had to add my new custome config options to the KConfig. Those two steps fixed the u-boot build issue. Dec 20 18:34:53 good Dec 20 18:36:42 Can anyone point me at a reference that explains the (git) workflow yocto uses? Im trying to get my head round the relationship between master / master-next / / -next ... Dec 20 19:06:10 RP: it seems it fails sometimes http://errors.yoctoproject.org/Errors/Build/74043/ Dec 20 19:07:37 no_such_user: you submit the patch to mailing list and that ends up in master-next or release-next as a staging for maintainers to do some CI and validation, if all goes well it gets into master or release branch whereever its destined for Dec 20 19:08:49 review also happens on mailing list and if someone has feedback + the results of CI it either goes back to submitter to prepare a new version which addresses the problems or gets accepted if all is ok Dec 20 19:08:56 HTH Dec 20 19:10:39 khem: Thanks! Specifically what Im trying to work out, is that I understand that my workflow in my layers should match the yocto workflow, especially to leverage stable release layers. However is (upstream) development just in master/master-next and named release layers *just* bugfixes? Dec 20 19:11:16 and if something is new development, should it be in master and then backported down? Dec 20 19:14:56 yes main development happens on master and we follow a time based release model, where we release on roughly 6months cadence that becomes the release, we branch out and call it some obscure name and move master ahead Dec 20 19:15:34 from thereon, release branches only get bug fixes + security fixes and occasionally package upgrades but that is an exception and rarely done Dec 20 19:16:19 usually other layers integrate with release branches and call their branches with same branch name to keep it simple for users Dec 20 19:17:09 and some layers lay ground rules on how far back they support different releases and ensure that single branch keeps working across all those releases Dec 20 19:17:59 some layers just stick to older releases and skip few releases to sync with later release Dec 20 19:18:14 so there are different release strategies in place that I have seen Dec 20 19:56:35 khem: Ah great that makes sense, thanks Dec 20 19:57:59 khem: So if my BSP is based on external layers with stable branches e.g. "rocko" I should develop locally with "rocko-next" branch in my layer, keeping my own "rocko" for stable code? i.e. Im basically ignoring master Dec 20 20:12:29 New news from stackoverflow: devtool upgrade ERROR: recipe is already in your workspace Dec 20 20:36:22 no_such_user: call your branches whatever you want, that's the policy for the oe branches. don't follow a next branch though because they'll change and broken stuff might be in there. Dec 20 20:38:28 rburton: Ah, ok thanks. I got the impression from the yocto bsp guide that I should be following the same branching scheme...! Dec 20 20:38:45 (although I think it probably makes sense to do so anyway as reduces complications) Dec 20 20:40:09 no_such_user: god no, do what you want Dec 20 20:40:44 if you're working on a BSP that is designed to be used with OE the following the naming is pretty obviously the right thing to do Dec 20 20:40:51 ie call the branch that works with thud "thud" Dec 20 20:43:48 (do consider tracking master too though, so you're not always a release behind) Dec 20 20:46:23 Thanks! (Ive really so far just been looking at what NXP do in their layers and trying to use copying their methodology as a starting point) Dec 20 20:47:41 Can't emphasise the "do consider tracking master" enough. Upgrades are a lot smoother when all the work doesn't have to be done at once. Dec 20 20:50:19 neverpanic: Id love to do that - trouble is ive a whole heap of historic layers Ive inherited that are nowhere near master! Dec 20 21:37:04 Hey i'm trying to use poppler with my qt5 app and it keeps saying poppler-qt5.h not found when I do the bitbake build of my app Dec 20 21:38:27 poppler built.. I have libpoppler-dev installed Dec 20 21:52:10 NeilS: maybe you need to turn on qt5 support in the poppler recipe? Dec 20 22:42:45 if you add meta-qt5 layer to your layermix then it should automatically enable qt5 support in poppler atleast on the version in master Dec 20 22:44:35 i do have meta-qt5 Dec 20 22:44:45 infact i'm building with meta-boot2qt Dec 20 22:45:12 again something that built with krogoth, builds with sumo but my qt5 app doesn't build Dec 20 22:46:56 i add this to the .bbappend to try it. Dec 20 22:46:59 EXTRA_OECONF += "-DENABLE_QT5=ON" DEPENDS += "qtbase qttools-native" Dec 20 22:47:15 would this be correct to enable qt5 support ? Dec 20 22:54:25 yes Dec 20 22:56:11 so maybe the path is wrong if the lib or header are now in a different place where should I look for them Dec 20 22:56:14 in the work dir? Dec 20 22:56:27 yeah find them in recipe-sysroot Dec 20 22:59:47 thanks for your help.. will poke more at this tmrw Dec 20 23:26:01 khem: more likely a race somewhere :/ Dec 20 23:26:38 khem: I ran glibc 2.29 through the AB pre the toolchain changes and we were fine. I can run it again with them at some point over the next few days Dec 21 00:44:58 RP: I think thats what seems to me Dec 21 02:22:01 RP: OK, so I think I am able to find the cause of the glibc failure, its when we add DISTRO_FEATURES_append = " ld-is-gold" Dec 21 02:22:19 RP: bitbake glibc and you see the problem **** ENDING LOGGING AT Fri Dec 21 03:00:02 2018