**** BEGIN LOGGING AT Fri Jul 10 02:59:58 2015 Jul 10 08:05:46 is it really correct behaviour for a bsp layer to use a cortexa8t2hf-vfp architecture? shouldn't it be armv7a-vfp? Jul 10 08:06:23 cause with this arch, there will be no sharing with other armv7a-based MACHINEs i suppose. everything has to be rebuilt Jul 10 08:08:41 mago__ if it does special tuning for the soc why not? Jul 10 08:10:30 okay, just checking Jul 10 08:17:04 good morning Jul 10 08:17:22 morning Jul 10 09:02:13 morning all Jul 10 09:02:24 hi bluelightning Jul 10 09:02:36 hi mckoan Jul 10 09:05:35 hi all Jul 10 09:06:30 is mixing of 64 bit and 32 bit apps supported for aarch64 (arm 64 bit) working like described here ? (https://github.com/openembedded/oe-core/blob/master/meta-skeleton/conf/multilib-example.conf) Jul 10 12:18:12 bluelightning, anyone have any luck with atlas/scipy there? Jul 10 12:31:28 Crofton|work: oh yeah I meant to ask about that, will do so today if the guy is in Jul 10 12:36:43 thanks Jul 10 12:36:48 I had someone ask Jul 10 12:37:14 I suspect he is beating his head against the wall :) Jul 10 13:12:55 mago__: koen feels strongly that it should be armv7a-vfp (see e.g. https://github.com/Angstrom-distribution/meta-fsl-arm/commit/2db4807df84ba516aa2617df23bc8cd4eff02646), but i guess not everyone agrees or it wouldn't be used Jul 10 13:12:58 * kergoth shrugs Jul 10 13:20:48 kergoth: i see Jul 10 13:21:05 i agree that it should not be a MACHINE choice at least Jul 10 13:26:39 * kergoth nods Jul 10 13:28:41 kergoth: I suspect most people have given up on package management Jul 10 13:29:05 seeing how OE-core tries very hard to break upgrade paths in every way possible Jul 10 13:29:08 moving files Jul 10 13:29:12 changing arch Jul 10 13:29:13 etc Jul 10 13:30:09 kergoth: my beef with meta-fsl-arm is that it uses MACHINE to select DISTRO policy for the floating point format Jul 10 13:30:39 and doing wrong by choosing the cortex tune instead of the armv7ahf one Jul 10 13:31:22 but as otavio points out, since there are no sanctions, there are no rules Jul 10 13:31:42 koen: I know you'd rather we never changed anything, but there has to be a balance between being able to move forward and actually fix underlying issues and providing a measure of backwards compatibility Jul 10 13:32:10 koen: to an extent there has to be some responsibility on the part of the distro maintainer for maintaining package feeds, it's not all up to OE-Core Jul 10 13:32:43 for some changes the breakage was worth it Jul 10 13:32:50 but a lot is just failure to plan Jul 10 13:33:00 I mean, x86 has changed archs twice now Jul 10 13:33:13 or 3 times Jul 10 13:33:15 I forget Jul 10 13:34:00 * Crofton|work is annoyed at meta-fsl also Jul 10 13:34:32 BSP's must respect distro decisions Jul 10 13:35:36 khem writes magic DISTRO python methods to unbreak most things Jul 10 13:36:16 I know, but we shouldn't have to Jul 10 13:36:25 not that it absolves BSPs from doing things they shouldn't, but most things that a BSP might set including this can easily be overridden by the distro, considering the distro conf is parsed after the machine conf Jul 10 13:36:31 if you want to have fun, look at the ARM MALI BSP Jul 10 13:36:37 heh Jul 10 13:36:44 i tried to talk sense into arm ltd, but the reply was "OMG optimized!!!" Jul 10 13:36:45 yes, I actually want to loo at that one Jul 10 13:37:30 the BSP suppliers need to understand there are people people for multiple machines and their BSP's must sit along side others Jul 10 13:37:50 Crofton|work: "We do yocto, what are you talking about?" Jul 10 13:38:06 im curious, is there a set of guidelines/documentation on what BSPs should limit their modifications to (at the machine level)? Jul 10 13:38:06 * Crofton|work is not falling for that line Jul 10 13:38:17 that's they reply I get from half the BSP maintainers Jul 10 13:38:38 nrossi: select a tune include, a kernel and a bootloader Jul 10 13:38:38 nrossi, no, that is part of theproblem Jul 10 13:39:01 if your MACHINE.conf has more, it's probably doing something wrong Jul 10 13:39:27 every time this discussion comes up I suggest that someone write such documentation, and every time nothing is done... Jul 10 13:39:40 heh Jul 10 13:39:49 too many writing tasks Jul 10 13:39:58 if people won't listen to reason now, what would yocto centric docs accomplish? Jul 10 13:40:09 doesn't have to be yocto-centric Jul 10 13:40:15 btw, I need someone to help write a bit about OpenEmbedded for a YP brochure Jul 10 13:40:20 I'm on vacatoin next week Jul 10 13:40:35 its probably worth doing then, i remember having some troubles knowing what not to do when i first started making the meta-xilinx layer. Jul 10 13:40:37 write OE documentation about this if you want, but actually write *some* documentation... Jul 10 13:41:10 * koen gets back to figuring out which plant in the back yard is causing the terrible itching rash Jul 10 13:41:20 koen, bitching solves nothing and makes people stop paying attention to you Jul 10 13:41:23 rofl Jul 10 13:41:33 besides which if you're complaining on one side about people saying "we do yocto" then putting such recommendations in yocto project documentation would be the sensible thing to do surely? Jul 10 13:41:39 Crofton|work: I contact the maintainer first, try to explain it Jul 10 13:41:40 * Crofton|work mails koen some poison ivy :) Jul 10 13:41:49 after that fails, I bitch Jul 10 13:49:47 hmmm just an idea, might help make it easy to "document". In the same way variables are "foo[doc] = ...", would adding some info like "foo[config-source] = "machine"". Which would allow for the parser to warn/error if variables are modified/set from a non-recommended source (e.g. machine configs/etc.) Jul 10 13:57:26 these DISTRO volatility issues has me worried... we are rolling out our arm-fsl device in a week's time and the distro keeps changing almost with every build. Should I be nervous? This breaks my package feeds every time :( Jul 10 13:58:30 nm, I am going to symlink them from now on Jul 10 16:04:38 pompomJuice: how is it breaking the feeds? Jul 10 16:20:15 koen: fsl arm has this fixed now see https://github.com/Freescale/meta-fsl-arm/commit/56b3ff40a94d6304fdbe387d312c55cec3a6e7e6 Jul 10 20:24:39 lovely: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=zmq Jul 10 20:27:17 jeez, commit message doesn't even mention he copied it from meta-oe Jul 10 20:30:08 pretty sure it is a direct copy by inspecting the zmqcpp repo :) Jul 10 20:34:30 is https://www.yoctoproject.org/tools-resources/projects/openembedded-core the true picture? Jul 10 20:34:49 * paulsherwood is trying to understand the interaction between yocto and oe still Jul 10 20:35:56 the picture seems to make bsp sit on top of meta-yocto, which sits on meta-oe.... but then i'm not clear what meta-yocto actually is and its wiki page seems empty? Jul 10 20:37:08 meta-yocto should be meta-poky Jul 10 20:37:30 it is the poky distribution config file Jul 10 20:37:48 ah, ok. and meta-poky is in effect enough to be a 'distro' when combined with meta-oe? Jul 10 20:37:49 I'm not sure I like the view as stacking layers Jul 10 20:37:53 (and a bsp?) Jul 10 20:37:55 maybe side by side :) Jul 10 20:38:11 Board support package Jul 10 20:38:50 sorry... i was unclear. i know what a bsp is. i meant, meta-poky + meta-oe + bsp = a minimal distro Jul 10 20:39:17 minimal is just build oe-core Jul 10 20:39:26 but that only has support for qemu machines Jul 10 20:39:52 http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp/conf/machine Jul 10 20:40:02 m-y-bsp adds some boards Jul 10 20:40:26 * paulsherwood goes to find out what meta-poky contains Jul 10 20:40:36 I do build with oe-core/meta-or/other layers with no distro conf Jul 10 20:40:51 meta-poky == meta-yocto :) Jul 10 20:41:03 I can talk about this for ages, but need to pack Jul 10 20:41:16 except that https://wiki.yoctoproject.org/wiki/Meta-Yocto is empty. Jul 10 20:41:48 ack Jul 10 20:44:51 http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/ Jul 10 20:45:20 like psplash has abbppend to add a poky specific image Jul 10 20:47:37 so http://git.yoctoproject.org/git/poky is not meta-poky? sorry, i appreciate these may be dumb questions Jul 10 20:48:32 I think that is a git repo that has oe-core/bitbake/meta-yocto as sub modules Jul 10 20:48:44 * Crofton|work has never actually build poky Jul 10 20:48:54 not dumb questions at all Jul 10 20:49:02 we have done a very poor job explaining this Jul 10 20:49:13 i'm aiming to get my head round this stuff for automotive grade linux. there's discussion about organising a new distro... i'm hoping to help ensure they use as much as possible that already exists Jul 10 20:49:36 meta-agl #ftw Jul 10 20:49:38 and to do that, i need to understand what exists :) Jul 10 20:50:25 i expect so. but there's already meta-ivi in genivi etc, and i'm hoping that we could *decrease* confusion rather than increase over the coming months :) Jul 10 20:50:38 that would be great Jul 10 20:51:06 I haven't looked at meta-ivi, but woul dguess it has applications? Jul 10 20:51:24 * Crofton|work goes to pack for vacation Jul 10 20:51:29 it's the main integration of middleware for genivi Jul 10 20:51:40 When I'm on, I'd be glad to try and help reduce cofusion Jul 10 20:51:41 Crofton|work: please, head for vacation. enjoy Jul 10 20:52:17 i'll still be here, hopefully better prepared by then :) Jul 10 20:52:26 I suck at vacation, but might be tethered :) Jul 10 20:52:33 lol. me too Jul 10 20:52:43 i find alcohol helps Jul 10 20:54:45 rofl Jul 10 20:55:40 imediate decision, do I take scuba gear Jul 10 21:20:23 ask the magic 8 ball ? Jul 10 21:23:47 http://www.2dive.com/btm.htm **** ENDING LOGGING AT Sat Jul 11 02:59:59 2015