**** BEGIN LOGGING AT Thu Sep 17 02:59:59 2015 Sep 17 07:22:48 good morning Sep 17 13:55:10 ok Sep 17 13:55:15 oops wrong indow Sep 17 14:31:33 any tips on resoloving this issue for a 64 bit build? Sep 17 14:31:34 WARNING: QA Issue: uhd: Files/directories were installed but not shipped in any package: Sep 17 14:31:34 /usr/lib64 Sep 17 14:31:47 add more /usr/lib64 liines :) Sep 17 14:33:31 ...just add that dir to FILES? :) Sep 17 14:33:41 Crofton|work: something needs to be using $libdir? Sep 17 14:33:58 FILES_${PN}-examples = "${libdir}/uhd/examples/*" Sep 17 14:34:08 I looked Sep 17 14:34:18 what is libdir on your configuration? Sep 17 14:34:23 dunno Sep 17 14:34:32 this is qemux86-64 build Sep 17 14:34:46 check with -e, it might be something else Sep 17 14:34:53 that would explain the errors Sep 17 14:35:22 what is weird is I only see message for uhd Sep 17 14:35:26 something dumb is happening Sep 17 14:35:37 maybe the upstream is being 'clever' and using lib64 even though your distro has libdir=/usr/lib Sep 17 14:35:48 so check what libdir is set to Sep 17 14:36:03 hmm Sep 17 14:36:43 what could be the reason why ipk's arch was created as arm5e instead of arm5te? tune features do list thumb.. TUNE_FEATURES = "arm armv5 thumb dsp" Sep 17 14:36:47 yeah libdir is /usr/lib Sep 17 14:36:49 trying to update from poky 1.7 to 2.0 Sep 17 14:36:50 need to beat upstream Sep 17 14:38:24 Crofton|work: never underestimate how stupid upstreams can be in the pursuit of being clever Sep 17 14:40:51 yep Sep 17 14:47:36 bug reported Sep 17 15:36:30 what defines the package architecture? I can't figure out why my poky master build produced armv5e instead of armv5te which was the case with yocto 1.5 and 1.7? Sep 17 15:36:50 Crofton|work: uhd... argh Sep 17 15:38:50 what else makes you angry? I can complain to devs Sep 17 15:39:41 both builds have the same TUNE_FEATURES, what am I missing? Sep 17 15:39:52 Jin^eLD: you need to enable thumb in your distro Sep 17 15:40:25 JaMa: it should be... TUNE_FEATURES = "arm armv5 thumb dsp" Sep 17 15:41:12 armv5e vs armv5te depends on ARM_INSTRUCTION_SET now, iirc. Sep 17 15:41:14 Crofton|work: neon and aarch64. but thats easy - just say that aarch64 lacks neon and it builds Sep 17 15:41:18 should be enabled that is, at least I did no disable it knowingly and the build summary at the beginning shows its there.. Sep 17 15:41:35 hrw, I think that is what master does now Sep 17 15:41:42 kergoth: thank you Sep 17 15:41:48 pretty sure they took your fedora patch verbatim Sep 17 15:42:41 Crofton|work: maybe. would have to dig where they have code stored ;D Sep 17 15:43:09 I actually don't know squat about thumb, but we ran into this supporting the sourcery g++ toolchains, they aren't patched to support armv5e at all, so i had to override the logic that changes it based on the value of ARM_M_OPT Sep 17 15:43:19 https://github.com/EttusResearch/uhd/commit/b1605957f46cb5c8d4b9d77b29acaa6e9604a164 Sep 17 15:43:21 +IF(HAVE_ARM_NEON_H AND (${CMAKE_SIZEOF_VOID_P} EQUAL 4)) Sep 17 15:43:38 kergoth: what's a good place for it, my machine conf? Sep 17 15:43:47 maybe one day cmake will get arch macros Sep 17 15:44:32 or rather the "correct" place from OE point of view Sep 17 15:44:47 Jin^eLD: that's what MACHINE supports, what DISTRO is using is orthogonal to it Sep 17 15:45:05 Jin^eLD: and it always was, just the PACKAGE_ARCH didn't reflect that Sep 17 15:46:11 I see, so either a distro or a local conf setting I guess Sep 17 15:46:19 yes Sep 17 15:46:23 not sure where ARM_INSTRUCTION_SET = "thumb" would belong, offhand. probably distro. though imx-base.inc sets it, which probably isn't kosher Sep 17 15:46:42 yes, it's meant to be in distro Sep 17 15:47:03 ok, thanks guys! Sep 17 15:47:06 and recipes can change it where needed (e.g. to switch back to "arm" when "thumb" is known to be broken) Sep 17 15:47:32 for reference, see conf/machine/include/arm/feature-arm-thumb.inc, specifically ARMPKGSFX_THUMB Sep 17 15:48:10 MACHINE (or some .inc) shouldn't set it, because if some DISTRO wants to share binary feed, then the distro should decide if _all_ MACHINEs will use arm or thumb (assuming that all supported MACHINEs support thumb) Sep 17 15:48:29 I think I get the idea, makes sense Sep 17 15:49:10 MACHINE already has TUNE_FEATURES to say if it supports thumb, it shouldn't dictate if it gets enabled or not Sep 17 15:51:01 ok, rebuild time then, that'll take a while :) Sep 17 15:51:05 thanks again! l8r Sep 17 19:35:12 Can someone explain the difference between master, master-next and master-next-1.9 in openembedded-core and meta-openembedded? I'm trying to figure out which branch is target which release. Sep 17 19:35:29 targeting* Sep 17 19:42:55 use fido Sep 17 19:43:09 master is master, master-next is gnerally about to get merged into master Sep 17 19:49:51 Crofton|work: I started with fido and have most of my layers working against that but I'm working on something that isn't target for release for quite a while so wanting to work with something a bit more bleeding edge to test against what will probably eventually be shipped (next release). Sep 17 19:51:08 so I'll guess Ill use master for that purpose except it one case I found a problem that's fixed in master-next so I guess I'll use that for oe-core on this build. Sep 17 20:02:43 master-next does get rebased and may well be broken Sep 17 20:02:53 so unless you're really keen, use a stable branch Sep 17 20:02:55 (fido) Sep 17 20:03:32 that said we just hit M3 for oe-core which means in theory it's stabilisation only from now Sep 17 20:36:31 georgem: *if* you don't want to use a stable branch, you'd be better off using master and cherry-picking just what you require off of master-next, not using master-next directly Sep 17 20:36:32 * kergoth yawns Sep 17 20:37:28 kergoth: ok, thanks for the tip **** ENDING LOGGING AT Fri Sep 18 02:59:58 2015