**** BEGIN LOGGING AT Thu Feb 05 02:59:59 2015 Feb 05 03:53:57 JaMa: fixed the issue Feb 05 03:56:00 khem: Just a FYI did a quick test of your RFT glibc 2.21/gcc 4.9 patch for ARM A9 and MicroBlaze, looks good :) Feb 05 04:05:10 Yeah, I've been running it for a bit. After the c99 issue was fixed all is well. I posted that on the list. Feb 05 05:07:31 nrossi thanks for confirming Feb 05 05:08:51 dankm_: what is your combo Feb 05 05:11:19 my box with these changes died Feb 05 05:11:47 but in this day and age with distributed SCMs no problems Feb 05 08:22:59 \o/ Feb 05 08:23:00 http://lwn.net/Articles/631332/ Feb 05 08:23:09 "A new release of CRDA has been released, this might be the last since Feb 05 08:23:09 we have some ideas of how to just shift this functionality directly Feb 05 08:23:10 into the kernel and in the future may not need any userspace tool" Feb 05 08:37:05 morning all Feb 05 08:37:17 morning bluelightning Feb 05 08:37:29 heh, just when we got around to updating the crda recipe :) Feb 05 08:40:25 bluelightning: exactly! Feb 05 09:06:31 what would be the best way to instruct bitbake *not* to include/provide sysroots/x86_64-linux when generating do_compile? Feb 05 09:19:54 pompomJuice: why do you want to do that? Feb 05 09:21:00 various android makefiles probe java though it's path. After adding java to my image, the dud java binaries now located in sysroots/x86_64 are causing the makefiles to fail. Even though the makefiles look at env variables like ANDROID_JAVA_HOME, that does not seem to help since most of the makefiles just look for java in the path and go from there. Feb 05 09:21:27 I'm not sure how to proceed. Feb 05 09:23:45 One way would be to manually hack all the makefiles and somehow point them to oracle-jdk6 installed on the box. Feb 05 09:23:53 but I was hoping for some other trick. Feb 05 09:26:25 Another way would be to unset PATH completely inside do_compile () and see what happens. If the rest of that recipy's tasks do not require anything inside the PATH set up by bitbake, it might work. Feb 05 09:27:01 or reset the PATH to the a users normal shell's path Feb 05 09:28:58 the recipy does not require anything inside sysroots/x86_64, so I thought completely disabling it (meaning it does not get inserted into the PATH) might also work. Feb 05 09:31:43 it would depend entirely on how the android makefiles are written I would think Feb 05 09:31:54 bbl Feb 05 09:32:12 its an old sdk, 4.03 and it cant be upgraded Feb 05 09:32:30 the makefiles are not unified in how they detect java Feb 05 09:34:55 quick poll: is anyone of you using systems where the installed glib is older than 2.26? Feb 05 09:39:12 running eglibc 2.19 on mine Feb 05 09:39:45 but I am still on 1.6 Feb 05 09:42:07 glib, not glibc :) Feb 05 09:42:30 oh I thought they would all be the same version, how do you check? Feb 05 09:43:06 ibglib-2.0-0 - 1:2.38.2-r0.5 Feb 05 09:43:33 right, that's good. not really current, but way newer than 2.26 Feb 05 09:43:49 aah ok so I have 2.38 Feb 05 09:44:16 I could possibly boot an image that contains an older version. WE have images saved from our yocto 1.5 days. Feb 05 09:45:37 Hi, I had an error with my nightly build, because the samba download server was not reachable. And the file needed is not hosted on one of the default poky mirror. So I wanted to ask, is there another mirror server? Feb 05 09:48:55 DatGizmo, you could locate cached file from a previous build and copy it into your current cache? Feb 05 09:53:23 For my builds yes, but we want to enshure, the downloads are more or less always working for our customers. Feb 05 17:50:40 bluelightning, you here? Feb 05 17:50:50 ka6sox: hi, yes Feb 05 17:51:43 are we talking release source tarball for oe-core "releases" Feb 05 17:52:23 (which track with Yocto releases) Feb 05 17:52:45 ka6sox: we are talking about the fetched source for each recipe Feb 05 17:53:05 so a full, not tar ball repo per release? Feb 05 17:53:07 ka6sox: excluding those in OE-Core (since those are already handled by the yoctoproject.org mirrors) Feb 05 17:53:17 okay... Feb 05 17:53:19 ka6sox: yes Feb 05 17:54:23 so things on the blacklist wouldn't have to be found and put in there? Feb 05 17:55:18 ka6sox: if it's explicitly blacklisted we wouldn't be able to pick these up using a -c fetchall Feb 05 17:55:54 I have builders, Bandwidth and I'll need to make some more space on the server but it can be done. Feb 05 17:55:59 but explicitly blacklisted recipes wouldn't be a priority for mirroring since the recipe has already been declared broken Feb 05 17:56:09 ok, sounds good Feb 05 17:56:32 we can make it a jenkins job that runs whenever a release happens. Feb 05 17:57:35 one reason I looped in Martin on that email is his builders run regularly already, so I wondered if we could piggy-back off that since that already does the fetching part Feb 05 17:57:51 bluelightning, same ones I'm talking about Feb 05 17:58:02 ok, good Feb 05 19:49:26 re Feb 05 22:23:24 Khem_: Sorry I missed you earler. I'm using oe-core, meta-fsl-arm, meta-fsl-arm-extra, a bunch of meta-openembedded, and a custom distro layer. Feb 05 22:23:34 The machines built were wandboard-quad and beaglebone. Feb 05 22:23:44 ok thx Feb 06 00:44:39 * nerdboy gets dizzy switching from rpi to beaglebone and on... **** ENDING LOGGING AT Fri Feb 06 02:59:59 2015