**** BEGIN LOGGING AT Wed Jul 19 03:00:03 2017 Jul 19 08:02:09 RP: I'm on SWAT and see a lot of failures on your bitbake server rework. Need me to do anything with that? Jul 19 08:03:40 joshuagl: no. Were there any eSDK changes though to the autobuilder? Jul 19 08:03:54 joshuagl: I'm a little puzzled why so many testsdkext failed Jul 19 08:06:01 RP: the RunESDKSanityTests buildstep hasn't been changed for some time (February) Jul 19 08:07:44 RP: hmm, complaining the toolchain isn't built. Let me review recent changes Jul 19 08:10:17 there doesn't appear to be an tmp/deploy/sdk :-/ Jul 19 08:11:53 RP: all of the toolchain builds don't seem to be doing anything. They only take ~5s to run Jul 19 08:12:05 https://autobuilder.yocto.io/builders/nightly-x86-64/builds/372/steps/BuildImages_2/logs/stdio Jul 19 08:25:44 joshuagl: ouch, right. That does not look good Jul 19 08:25:51 and likely my fault Jul 19 08:28:22 sorry :-/ Jul 19 08:31:34 joshuagl: its ok, its just going to be another of those days :) Jul 19 08:35:50 one of those ending in y? :-) Jul 19 08:41:22 Hi... I'm fairly new to Yocto and am building for the intel-edison board. I have a meta-java layer thats not compiling because it wants a libxt dependency. I see that its present in meta-open0embedded/meta-oe layer. this is included in the bblayers.conf. However, I still get a compile failure... Can someone point where I'm missing a link? Jul 19 08:42:36 cruisemaniac: does the recipe list libxt in its DEPENDS? Jul 19 08:42:47 (assuming libxt is the name of the recipe) Jul 19 08:43:12 @bluelightning should I check for this inside the meta-java/folder tree??? Jul 19 08:43:26 cruisemaniac: yes Jul 19 08:43:46 cruisemaniac: bitbake will have reported the full path to the failing recipe as part of the error Jul 19 08:46:15 let me put the error on pastebin and share the link here... Jul 19 08:46:16 2 mins Jul 19 08:47:29 https://pastebin.com/cnNqmKNQ @bluelightning Jul 19 08:48:41 rburton: have you seen the kut failure? http://autobuilder.yoctoproject.org/main/builders/nightly-qa-extras/builds/1168/steps/BuildImages_3/logs/stdio Jul 19 08:49:51 * joshuagl wonders if that's because we folded all of the nightly-qa-* into one buildset Jul 19 08:50:36 cruisemaniac: the key part is ERROR: libxt was skipped: missing required distro feature 'x11' (not in DISTRO_FEATURES) Jul 19 08:51:03 how should this be fixed? Jul 19 08:51:50 cruisemaniac: short answer, DISTRO_FEATURES_append = " x11" in your local.conf (note the leading space) Jul 19 08:54:35 @bluelightning let me check that… Jul 19 08:56:03 logically openjdk ought to be able to build without x11, I don't know if anyone's properly sorted that out yet Jul 19 08:56:40 I’ve been pulling my hair out getting this to even compile… there’s always something broken Jul 19 08:58:54 i dont know if its just me but the default edison poky setup from the intel website has meta-java but doesnt include it Jul 19 08:59:03 took me a bit to figure _that_ out Jul 19 08:59:26 sigh... yeah the edison build is not without issues :( Jul 19 08:59:39 okay, the DISTRO_FEATURES_append directive seems to be working… i have a build in progress! Jul 19 09:00:03 great Jul 19 09:02:28 so DISTRO_FEATURES_append directive is telling yocto to add x11 library as part of the final image that we’re packing… is this correct? Jul 19 09:03:02 cruisemaniac: not quite - it's saying that for anything that could build with the x11 feature enabled, enable it Jul 19 09:12:15 i’m not sure i get that… can you detail it please @bluelightning Jul 19 09:13:11 so there are various pieces of software we build that can optionally build with x11 support; the x11 DISTRO_FEATURES item controls whether or not that support is enabled globally Jul 19 09:15:37 okay… so this is at the build level where DISTRO_FEATURES says I will give you the lib you need to compile and link against... Jul 19 09:15:38 correct? Jul 19 09:21:53 cruisemaniac: well kind of... it's more that say a particular recipe with said optional x11 functionality will look to see if x11 is in DISTRO_FEATURES, and if it is it will not only enable that functionality but also add libx11 to its own DEPENDS dynamically, thus libx11 will get built Jul 19 09:22:46 that makes it clear… thanks a ton @bluelightning Jul 19 09:22:54 no problem Jul 19 09:23:06 what happens in the packaging phase? I presume x11 as a lib needs to be packaged as well for use during runtime right? Jul 19 09:31:42 @bluelightning if you’re around, i’m stuck at the next error: I have a checksum failure for meta-java’s icedtea7 package… Jul 19 09:31:48 this is what i have in the build: icedtea7-forest-2.5 Jul 19 09:31:57 it says the checksums mismatched and halted the build... Jul 19 09:32:26 where can I find the valid checksums? googling is returning a lot of forum results but nothing which says “THIS IS THE md5 you need to hash against” Jul 19 09:32:34 cruisemaniac: that's not a good sign, that says that the file being downloaded has changed on the server Jul 19 09:32:50 that could be for innocuous reasons, or it could have been tampered with Jul 19 09:32:55 hmmm Jul 19 09:33:50 let me check the url this guy is trying to do_fetch from... Jul 19 09:34:55 this is where he’s pulling from Jul 19 09:34:56 http://icedtea.classpath.org/hg/release/icedtea7-forest-2.5/archive/6cf2880aab5e.tar.bz2;name=openjdk;unpack=false Jul 19 09:35:41 lol, it 404’s! Jul 19 09:55:31 switched to the latest master available for meta-java and I’m getting a relative-symlinks.bbclass missing in a classes folder... Jul 19 09:56:00 where should I start the hunt for it? find ./ -name relative-symlinks.bbclass returns zilch Jul 19 09:56:39 ran that search from the poky root! Jul 19 10:06:26 cruisemaniac: using a master layer with a non-master oe-core will generally break as the layer will use classes you don't have Jul 19 10:06:46 @rburton was slowly coming to that understanding myself... Jul 19 10:07:12 given i revert back to what was packed WITH poky, how do I get ahead of the icedtea7 checksum issue I highlighted above? Jul 19 10:07:23 also, it looks like the icedtea7 urls dont exist anymore - they 404 Jul 19 10:07:56 look at the recipe in master and copy the right URLs/checksums? Jul 19 10:10:05 but it also looks like the version has changed! Jul 19 10:10:29 i guess you want to find the right url on the download site for the version you want Jul 19 10:13:16 the URL it actually downloads, http://icedtea.classpath.org/hg/release/icedtea7-forest-2.5/archive/6cf2880aab5e.tar.bz2, isn't a 404 Jul 19 10:13:34 but it is a generated tarball, so will change over time Jul 19 10:13:45 the error log will tell you the new checksums, just update the recipe Jul 19 11:21:42 @rburton so I just keep it as is where is and update the checksums ? Jul 19 12:07:36 I have a recipe, A, that ends up creating a few different packages like -dev for headers and such, and another recipe B which DEPENDS on a-dev. When I try to build B however, populate sysroot never seems to fully occur: I see some files from the a-dev package (I opened and inspected the ipk) but not all of them. Does anyone know of a starting point to figure out why it's partially being unpacked? Jul 19 12:13:36 tgoodwin: you DEPEND on a recipe not a package Jul 19 12:16:04 rburton: either way, it's still only partially unpacking (I added the a-dev to B's DEPENDS and A's PROVIDES last night trying to figure out why populate sysroot wasn't fully installing the recipe) Jul 19 12:16:11 er, package. Jul 19 12:16:42 tgoodwin: sysroot does prune the list of files slightly, what paths are you missing? Jul 19 12:18:57 it's way up in /usr/local. It's missing an aclocal directory, among others. (Just tore out the entire workdir to start from scratch. Cleaning the sstate, etc. seemed to have no effect, so I started over this morning on the build and won't be able to get a full list until later.) Jul 19 12:20:31 (basically /usr/local/.../share) Jul 19 12:24:01 filesystem standards say don't put stuff in packages in /usr/local Jul 19 12:24:25 in yocto-land anything in there won't be staged, because we never install in there :) Jul 19 12:24:52 Where would you recommend then? Jul 19 12:24:57 /usr Jul 19 12:25:00 along with everything else Jul 19 12:25:35 you're building a custom system, there's no difference between glibc and qt and your own library Jul 19 12:25:39 they're all in /usr Jul 19 12:25:46 well, $prefix, but that's /usr by default Jul 19 12:26:15 I get your point, however I would like to keep all over our related packages into a subdir. If we picked /usr/our-package would we still be running into this same stating issue? Jul 19 12:26:16 staging* Jul 19 12:26:23 yes Jul 19 12:26:42 if you insist on putting the stuff in a non-standard place then you'll need to stage yourself Jul 19 12:26:54 We've taken care of that bit. Jul 19 12:27:02 no you haven't, thats what is breaking Jul 19 12:27:19 you've installed to packages, but that's not staging. staging is putting stuff in the sysroot Jul 19 12:27:29 We've been using SYSROOT_PREPROCES_FUNCS to tshift things to our stagedir. Jul 19 12:27:40 *PREPROCESS* Jul 19 12:27:47 can't type today... Jul 19 12:27:52 you might find that just setting prefix to /usr/local will just make the staging work out of the box Jul 19 12:27:58 as that's what you're actually doing Jul 19 12:28:06 (in the recipe) Jul 19 12:29:04 son of a gun. That class include got deleted (that pulls in the sdrroot preprocess functions). Jul 19 12:29:14 sysroot* Jul 19 12:29:24 Thanks... Jul 19 13:05:33 joshuagl: no need to do anything with the last -next build either. I'm trying again Jul 19 13:05:45 RP: thanks for the notice! Jul 19 13:05:48 rburton: Thanks again for walking me back into the goof-up. That class having been accidentally cleaned out was the problem. Jul 19 13:05:48 * joshuagl will update wiki soon Jul 19 14:35:45 WARNING: poco-1.7.8-r0 do_package: poco-1.7.8 was registered as shlib provider for libCppUnit.so.1, changing it to poco-cppunit-1.7.8 because it was built later Jul 19 14:36:06 Is it really intended that poco provides its own libCppUnit.so.1? Jul 19 14:36:35 Won't that conflict with the normal cppunit? Jul 19 14:44:36 pohly: it sounds bad Jul 19 14:45:22 RP: I'm a bit worried that warnings like these tend to go unnoticed, at least in the refkit CI. Jul 19 14:46:08 They don't break the build and only appear when the recipe really gets built, so one can get "clean" builds from sstate without ever seeing these warnings. Jul 19 14:49:41 pohly: they are also order specific even without sstate if I understand it correctly :( Jul 19 14:50:04 pohly: its very hard to ensure something is unique systemwide without something like buildhistory in action the whole time Jul 19 14:50:17 pohly: we could promote those to errors now I suspect Jul 19 14:52:06 joshuagl: https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/361/steps/BuildImages_14/logs/stdio looks like some kind of race unrelated to the patches in test :/ Jul 19 14:52:56 JosePerez: thanks for the update re: the rootfs test timings, looks like some investigation needed on that machine... Jul 19 14:53:01 RP: a race in OE-Core, you mean? Jul 19 14:53:05 JosePerez: curious to understand what changed Jul 19 14:53:19 joshuagl: yes, in the xcb recipes Jul 19 14:53:28 RP: thanks, I'll file a bug Jul 19 14:53:51 joshuagl: thanks Jul 19 14:57:18 RP: no problem I'm currently checking on the machine as soon as I have any information will let you know. Jul 19 15:14:05 RP: rather tempted to capture warnings/errors from tasks and save and restore them in sstate at some point, it really is easy to miss warnings that only show up when building from scratch Jul 19 15:30:27 kergoth: yes, that could be interesting Jul 19 16:10:04 seebs: you happen to know offhand what 'No real function for syncfs, but dlerror NULL' means? Jul 19 16:10:12 JosePerez: can we ensure https://bugzilla.yoctoproject.org/show_bug.cgi?id=10832 is updated quickly with an idea of which esdk failed please? Jul 19 16:10:13 Bug 10832: normal, High, 2.3 M1, eduard.bartosh, REOPENED , eSDK install script failed with "tasks executed unexpectedly" messages Jul 19 16:10:30 JosePerez: moving this to a new bug might also make more sense Jul 19 16:11:11 kergoth: it means we tried to dlsym() something called "syncfs", but the error reported was NULL, meaning we didn't get a diagnostic indicating anything went wrong. Jul 19 16:11:25 i'm guessing syncfs isn't universally available and we need a workaround for the case where it doesn't exist. Jul 19 16:11:32 hmm, okay, thanks Jul 19 16:12:04 e = dlerror(); Jul 19 16:12:04 if (e != NULL) { Jul 19 16:12:04 pseudo_diag("No real function for %s: %s\n", func->name, e); Jul 19 16:12:04 } else { Jul 19 16:12:04 pseudo_diag("No real function for %s, but dlerror NULL.\n", func->name); Jul 19 16:12:05 } Jul 19 16:12:53 and it turns out that may mean "the symbol is defined but its value is null". Jul 19 16:13:45 syncfs is a good example of "it's probably safe-ish to just never call the real function". Jul 19 16:13:54 rp: will work on that Jul 19 16:14:30 JosePerez: thanks, its hard to tell how important this issue is right now :( Jul 19 16:14:37 huh. so there's a separate port for that already; ports/unix/syncfs, controlled by ports/unix/subports which tries to compile a test program that calls syncfs. Jul 19 16:16:11 libby1: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10832 are you able to check the comments and work with David on the creation of a new bug Jul 19 16:16:12 Bug 10832: normal, High, 2.3 M1, eduard.bartosh, REOPENED , eSDK install script failed with "tasks executed unexpectedly" messages Jul 19 16:16:23 meh. probably want to have some kind of indicator for "this function is probably a bad idea so if we can't call it that's fine" Jul 19 17:09:31 PR: I am preparing a new class to submit as an RFC, it adds links to the bb and bbappend files for a recipe in WORKDIR Jul 19 17:10:23 this first iteration I am proposing folks add it via USER_CLASSES in their local.conf Jul 19 17:11:10 but I am having a hell of a time getting the task setup such that it will run before do_fetch but not change the sigs and cause everything to rebuild Jul 19 17:12:19 I want ppl to be able to add this class to USER_CLASSES for an existing build and not have it cause everything to rebuild Jul 19 17:12:36 any elegant solutions you or others might have that I can attempt to make use of? Jul 19 17:21:23 sorry. RP, any thoughts on the above^^^^^^ ? Jul 19 17:29:22 marka: could try adding it to prefuncs, but then exclude it with vardepsexclude? Jul 19 17:29:23 * kergoth shrugs Jul 19 17:30:44 I found the act of adding it to vardepsexclude caused the sigs to change Jul 19 17:31:26 I was wanting to do offer it as a task instead of a function added via prefuncs to allow it to be rerun manually Jul 19 17:33:47 I suppose I could do use addtask without a before or after and use it via pre or postfuncs to accomplish this, though from what I have seen this would be unusual Jul 19 17:51:06 hi guys, just intalled an eSDK from http://downloads.yoctoproject.org/releases/yocto/yocto-2.3/toolchain/x86_64/ Jul 19 17:51:13 it created a tmp directory with 592 MB of stuff inside Jul 19 17:51:17 what is the tmp dir for? Jul 19 17:51:27 can I blow it away? Jul 19 18:04:07 thiago: what does this dir have Jul 19 18:05:02 well, almost everything useful Jul 19 18:05:05 compilers, sysroots, etc. Jul 19 18:05:29 $ ls tmp Jul 19 18:05:29 abi_version cache log sstate-control sysroots sysroots-uninative Jul 19 18:05:32 buildstats hosttools saved_tmpdir stamps sysroots-components work Jul 19 18:06:11 * thiago finds temporary files inside tmp/work/qemuarm64-poky-linux/build-sysroots/1.0-r0/temp Jul 19 18:06:17 four levels of temporary? Jul 19 18:08:28 yeah do you have sstate dir somewhere ? Jul 19 18:08:49 there's an sstate-cache outside of tmp Jul 19 18:18:30 thiago: i'm struggling to remember how an eSDK works but i *think* that's basically the actual SDK Jul 19 18:50:21 thiago: (as an eSDK is basically a self-contained build system) Jul 19 18:51:11 * thiago just wants the compiler and sysroot Jul 19 18:51:30 the sysroot it installed doesn't contain most useful libraries, like X Jul 19 18:51:46 a traditional SDK is more, well, traditional Jul 19 18:51:51 the eSDK lets you install stuff after the event Jul 19 18:51:58 thiago: meta-toolchain is what you are looking for it seems Jul 19 18:52:02 how do I do that? Jul 19 18:52:06 no not meta toolchain! :) Jul 19 18:52:30 thiago: bitbake core-image-minimal -c populate_sdk should do Jul 19 18:52:39 rburton: no meta-toolchain? why? Jul 19 18:53:25 will that build or will it just download? Jul 19 18:54:26 thiago: well, first question. what target machine and what do you expect in the sdk? Jul 19 18:54:29 or do you just want a compiler Jul 19 18:54:57 I want what I used to get up until 2.3: a simple sysroot and a compiler I can use to test that Qt cross-compiles with Jul 19 18:55:04 I don't plan on installing anything. Or even running. Jul 19 18:55:11 if it compiles, it's good enough for me. Jul 19 18:55:17 what you used to get should still exist Jul 19 18:55:24 do you know where? Jul 19 18:56:32 i'd have said https://downloads.yoctoproject.org/releases/yocto/yocto-2.3/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-armv5e-toolchain-ext-2.3.sh but that's an eSDK not a "traditional" SDK. i guess that's what you downloaded already? Jul 19 18:56:33 * thiago tries the sato files Jul 19 18:56:47 should just work out of the box, unless we're shipping minimal eSDKs Jul 19 18:56:50 no, I downloaded the top ones Jul 19 18:57:10 the core-image-minimal ones don't have X, or almost anything else Jul 19 18:57:14 minimal means minimal :) Jul 19 18:57:25 right Jul 19 18:58:01 installing aarch64 Jul 19 18:58:32 i'll admit i've never tried the SDKs that we publish so not sure how they're configured Jul 19 18:59:01 ah, this looks a lot more like what I'd been used to Jul 19 19:00:32 you've probably been grabbing the core-image-sato toolchains, and accidentally fetched the core-image-minimal one this time Jul 19 19:00:52 yup Jul 19 19:00:55 looks like it Jul 19 19:01:03 installing now the other archs Jul 19 19:01:18 still, why is all the interesting stuff in the eSDK inside the "tmp" dir? Jul 19 19:01:45 because a eSDK is a self-contained build system, and that's how they work Jul 19 19:01:53 historical reasons for it being called tmp/ :) Jul 19 19:02:24 rationale being everything in there is generated and can be regenerated by building it again, or restoring prebuilt pieces from sstate. Jul 19 19:02:26 yeah, just surprised me because I installed everything, blew up the tmp, then couldn't find the compiler Jul 19 19:03:08 if you did a bitbake after blowing the tmp it will just restore it all from the sstate-cache for you, theoretially Jul 19 19:03:18 here my tmp/ is a tmpfs for speed Jul 19 19:03:37 nice that "lets do a clean build" is just a remount away Jul 19 19:04:12 thiago: my impression you want a barebone toolchain Jul 19 19:04:20 yup Jul 19 19:04:23 that's right Jul 19 19:04:23 thiago: so the minimal is what you are looking for Jul 19 19:04:27 no Jul 19 19:04:30 I want the X libs inside Jul 19 19:04:32 minimal doesn't have libx11 in :) Jul 19 19:04:41 so not a barebones toolchain Jul 19 19:04:47 thiago: ahhh so not a toolchain Jul 19 19:04:48 a x11 based environment and toolchain Jul 19 19:04:54 don't need pulseaudio libs inside, but it won't hurt Jul 19 19:05:02 what we call a toolchain is *just* the compilers Jul 19 19:05:04 thiago: so it is indeed a sdk, not a toolchain Jul 19 19:05:10 right Jul 19 19:05:30 thiago: a core-image-x11 based sdk would be the perfect match Jul 19 19:05:55 some of the other libs are actually useful Jul 19 19:06:27 zlib, png, sqlite, jpeg, etc. Jul 19 19:06:46 ICU, dbus, ... Jul 19 19:06:59 actually, this gives me almost all "yes" in Qt's configure Jul 19 19:07:19 i wonder if sato ships the wayland libs... Jul 19 19:08:05 doesn't explicitly but i bet the core libs sneak in via deps Jul 19 19:08:28 $ ls /opt/poky/2.3/sysroots/aarch64-poky-linux/usr/lib/*wayland* | wc -l Jul 19 19:08:29 15 Jul 19 19:08:38 \o/ Jul 19 19:09:20 the only thing mising to make this perfect would be automatic --sysroot Jul 19 19:09:53 the environment should have an env var that does that for you, ie calls configure with the right flags Jul 19 19:10:03 right Jul 19 19:10:15 but most of my work is actually just running the compiler manually and looking at the assembly it generates Jul 19 19:10:28 lol fair enough Jul 19 19:10:54 the old cygnus toolchains I used to get when working at Nokia did this atuomtically. I think those poky images did too at some time Jul 19 19:11:00 now they refer to /not/exist/usr/include Jul 19 19:12:23 thanks, everything installed Jul 19 19:12:37 a long time ago they embedded a possible sdk path in as the sysroot but if you relocated the sdk to somewhere else the paths were wrong Jul 19 19:12:53 so now they insist on a sysroot to avoid mysterious problems Jul 19 19:12:59 that's why I have a bind-mount in /opt/poky to wherever it really gets installed Jul 19 19:13:07 haha Jul 19 19:13:14 i'll pretend i didn't read that Jul 19 19:13:42 the real dir is in /dev/system/stuff, not /dev/system/root Jul 19 19:14:21 200 GB ext4, instead of a 30 GB btrfs with snapshotting enabled Jul 19 19:15:35 (system is an LVM VG) Jul 19 19:16:27 rburton: did you see the mesa bump? Jul 19 19:16:34 rburton: also u-boot is pending Jul 19 20:04:07 we really need to rename "tmp" Jul 19 20:22:21 yes, yes we do Jul 19 20:41:37 kergoth: what to? Jul 19 21:38:49 RP: i always thought 'build' would be good, but we already use that for our build directories, unless we want to shift bits up from TMPDIR to TOPDIR.. I have no idea Jul 19 21:41:08 kergoth: that is the hardest part with this. I quite like the idea of work Jul 19 21:41:18 kergoth: perhaps we rename that too Jul 19 21:42:30 would be nice to shift DEPLOY_DIR up to TOPDIR while we're reorganizing, if we can Jul 19 21:44:38 otavio: both in current mut Jul 19 21:46:47 kergoth: yes, it would Jul 19 21:51:59 RP: i broke your server code :) Jul 19 21:53:16 RP: https://pastebin.com/ZkjHwKiD started a build in one terminal, another terminal oe-init-build-env'd the same directory and did bitbake -e Jul 19 21:53:38 after the -e failed to connect a few times i control-c'd the second bitbake, and then shortly afterwards the original one crashed Jul 19 21:54:25 kergoth, RP: just because i'm curious, doing a build now with this: Jul 19 21:54:26 TMPDIR = "/data/poky-tmp/master/build" Jul 19 21:54:27 DEPLOY_DIR = "/data/poky-tmp/master/deploy" Jul 19 21:54:46 we're 100% sure this won't fail at all right Jul 19 21:57:11 rburton: 100%, totally Jul 19 21:57:44 Has anyone tried putting /usr/share/locale/locale.alias in an image from the glibc package? Jul 19 21:57:44 rburton: hmm, you shouldn't be able to do that Jul 19 21:57:58 rburton: have you the cookerdaemon log from doing that? Jul 19 21:58:00 RP: second bitbake tried and failed to connect Jul 19 21:58:10 $ bitbake m4 -e Jul 19 21:58:11 Reconnecting to bitbake server... Jul 19 21:58:11 Retrying server connection... Jul 19 21:58:12 etc Jul 19 21:58:12 (bitbake-cookerdaemon.log) Jul 19 21:58:26 erm, no, i've already remounted the tmpfs, sorry Jul 19 21:59:01 rburton: shame Jul 19 21:59:09 one sec will try again Jul 19 22:21:46 :q Jul 19 22:21:52 oops Jul 19 22:22:19 * RP has a fix thanks to rburton (at least to stop the server crashing) Jul 19 22:22:54 and a brain that doesn't work. opened a new browser tab and immediately forgot why i opened it Jul 19 22:22:58 oh yes Jul 19 22:36:37 khem: going to bed now but i just got this from a build Jul 19 22:36:38 WARNING: binutils-2.28-r0 do_package: binutils: NOT adding alternative provide /usr/bin/ld.gold: /usr/bin/x86_64-poky-linux-ld.gold does not exist Jul 19 22:36:39 WARNING: binutils-2.28-r0 do_package: binutils: NOT adding alternative provide /usr/bin/dwp: /usr/bin/x86_64-poky-linux-dwp does not exist Jul 20 02:40:23 Hi **** ENDING LOGGING AT Thu Jul 20 03:00:01 2017