**** BEGIN LOGGING AT Mon Jun 15 02:59:58 2015
Jun 15 07:09:51 <mckoan> Good morning
Jun 15 07:24:02 <woglinde> hi mckoan
Jun 15 08:18:10 <bluelightning> morning all
Jun 15 08:28:44 <mckoan> hi bluelightning, woglinde 
Jun 15 08:29:57 <woglinde> hi bl
Jun 15 09:00:28 <bluelightning> hi mckoan, woglinde
Jun 15 11:49:54 <Crofton|work> bluelightning, any idea how the guys working on scipy are getting along
Jun 15 12:31:11 <bluelightning> Crofton|work: not sure but I will ask later when they are online
Jun 15 12:31:36 <Crofton|work> thanks, I am interested
Jun 15 12:31:41 <Crofton|work> I got angry at atlas
Jun 15 13:45:43 <adelcast> I am looking at my distro /etc/lsb-release file...the DISTRIB_ID is equal to the value of the DISTRO variable. On the documentation it mentions that "The value for DISTRO must not contain spaces, and is typically all lower-case"
Jun 15 13:46:25 <adelcast> which is kind of odd, as other distros usually have DISTRIB_ID like LinuxMint, Arch, etc
Jun 15 13:47:20 <adelcast> I wonder why did OE restricts (suggests) to lower case? I mean, I get that you will have to create a distro file with the name of DISTRO, but sounds desirable to have a distro name that wouldn't be tied to the distro file
Jun 15 13:50:38 <bluelightning> adelcast: DISTRO points to a configuration file, and the convention for those is lower case
Jun 15 13:50:53 <bluelightning> adelcast: similarly it goes into OVERRIDES which are also typically lower case
Jun 15 13:51:44 <bluelightning> I'm sure DISTRIB_ID  could be set to something else that didn't have the same restrictions as DISTRO, I guess we put DISTRO in there because that is what we have
Jun 15 13:52:55 <adelcast> I think so, yeah (the original commit only mentions that id populates distro values on lsb-release)
Jun 15 13:54:12 <adelcast> is not a big deal for me, as we will expose the distro name via Salt (system configuration management), which has a layer that can translate from lsb-release name to the name that will be exposed to users
Jun 15 14:27:21 <kergoth> iirc we do have DISTRO_NAME or so, don't know if all major distros set it, however
Jun 15 14:27:21 <kergoth> morning
Jun 15 14:49:46 <adelcast> kergoth: we use DISTRO_NAME for DISTIB_DESCRIPTION already
Jun 15 14:51:39 <kergoth> ahh, right
Jun 15 15:10:06 <Crofton|work> bluelightning, I'll bug Jefro
Jun 15 15:10:18 <Crofton|work> really need to get him to hand that off to the peopl ereally interested
Jun 15 15:10:27 <bluelightning> Crofton|work: right yes
Jun 15 15:10:29 <bluelightning> thx
Jun 15 15:10:50 <Crofton|work> people hate sato :)
Jun 15 15:13:42 <Crofton|work> people hate sato :)
Jun 15 15:13:44 <Crofton|work> heh
Jun 15 15:15:01 * rburton sulk-quits
Jun 15 15:15:05 <Crofton|work> heh
Jun 15 15:15:12 <Crofton|work> this comes up all the time
Jun 15 15:15:17 <Crofton|work> mainly it is dated
Jun 15 15:15:34 <rburton> i totally have a branch to make it use gtk3
Jun 15 15:15:42 <rburton> so at least the toolkit is modern, and its not green
Jun 15 15:16:00 <rburton> sure, that's not GL-accelerated html-powered
Jun 15 15:16:07 <Crofton|work> Well, we neeed to get the people that talked about improving the graphical demo siutation talking
Jun 15 15:16:12 <rburton> indeed
Jun 15 15:16:19 * Crofton|work will beat Jefro
Jun 15 15:16:58 <Crofton|work> this comes up every year at OEDAM
Jun 15 15:17:15 <Crofton|work> this year, we should select it to be the item not to talk about next year
Jun 15 15:19:24 <rburton> so then i said, don't hire josh, he's a liability.
Jun 15 15:19:29 <joshuagl> hehe
Jun 15 15:24:15 <Crofton|work> rburton, deleting the xf86 modesetting entry from my image made an image that works
Jun 15 15:24:21 <Crofton|work> so I am happy
Jun 15 15:24:27 <Crofton|work> not sure why I added it :)
Jun 15 15:24:45 <rburton> not sure why that broke, the package name should have been the same
Jun 15 15:25:07 <Crofton|work> yeah, maybe something stuck in tmp
Jun 15 16:01:00 <bluelightning> memory issues with the layer index update script should be fixed now btw, so updates should now be working properly again for all layers
Jun 15 16:03:18 <georgem> haha, my ptxdist and oe builds both failed on native ncurses after upgrading to gcc to 5.1. looks like ptxdist has a fix, time to go look if there is one for oe.
Jun 15 16:10:17 <rburton> georgem: oe master has a fix
Jun 15 16:10:28 <georgem> rburton: thanks
Jun 15 16:10:30 <rburton> georgem: and there's a patch on the list for fido, not sure if joshuagl has merged it yet
Jun 15 16:10:36 <rburton> (basically, pass -P to cpp)
Jun 15 16:13:15 <joshuagl> rburton: which patch, sorry?
Jun 15 16:13:25 <rburton> tsk
Jun 15 16:13:33 <Crofton|work> native ncurses
Jun 15 16:13:43 <rburton> [OE-core] [PATCH] ncurses: fix native builds when host has gcc5
Jun 15 16:13:52 <rburton> to be fair i said "you should propose this for fido" and nobody did
Jun 15 16:14:03 <rburton> but basically its now your call as to what fido does about gcc5
Jun 15 16:14:18 <rburton> ie people who want to build fido on fedora22 are hit by a barrage of build failures :)
Jun 15 16:14:33 <Crofton|work> yeah, I should make a vm and agitate for fido
Jun 15 16:14:53 <rburton> Crofton|work: i think you agitate enough as it is
Jun 15 16:14:59 * Crofton|work laughs
Jun 15 16:15:15 <Crofton|work> I suspect I will care about people building on F22 at some point
Jun 15 16:15:31 <joshuagl> I would like to support f22 for fido
Jun 15 16:15:36 <joshuagl> I guess I should look at that patch
Jun 15 16:15:44 <rburton> there's a few dotted around
Jun 15 16:15:46 <Crofton|work> +1
Jun 15 16:16:25 <rburton> but i'd endorse setting up a vm, or running a quick eg nightly-x86 run on the fedora22 autobuilder machine
Jun 15 16:16:47 <joshuagl> building in a vm? not a chance
Jun 15 16:17:02 <joshuagl> I have f22 on my laptop, I'll generate some heat for my hands some time this week
Jun 15 16:17:03 <Crofton|work> I do to test lots of configs
Jun 15 16:33:09 <abelloni> I usually set up containers instead of vms
Jun 15 16:33:50 <rburton> i do have a shiny debian unstable chroot i can systemd-nspawn into now
Jun 15 16:33:54 <rburton> which is useful
Jun 15 16:34:34 <Crofton|work> many tools
Jun 15 17:01:44 <otavio> rburton: why you didn't upgrade piglit to latest?
Jun 15 17:02:42 <rburton> otavio: because it gained build dependencies and a step in the right direction was better than nothing
Jun 15 17:03:14 <otavio> rburton: the current version is failing on mx53
Jun 15 17:03:52 <rburton> failing how?
Jun 15 17:04:19 <rburton> (the way to run the tests has changed)
Jun 15 17:04:37 <otavio> rburton: build; hold on
Jun 15 17:04:43 <otavio> rburton: I am getting the log
Jun 15 17:27:21 <otavio> rburton: the error can be seen at: https://www.dropbox.com/s/fa3piiuamtg4vy7/log.do_compile.5179.gz?dl=0
Jun 15 17:36:06 <otavio> rburton: any hint?
Jun 15 19:29:23 <otavio> rburton: I sent piglit a fix
Jun 15 21:05:41 <ntl> hmm I think the oe-core patchwork missed a patch I sent ~2.5 hours ago, did I do something wrong?
Jun 15 21:05:45 <ntl> http://lists.openembedded.org/pipermail/openembedded-core/2015-June/106095.html
Jun 15 21:36:59 <georgem> Add grub-efi_2.00.bb in fido to the list of recipes broken by gcc 5.1 warnings
**** ENDING LOGGING AT Tue Jun 16 02:59:59 2015