**** BEGIN LOGGING AT Fri Sep 23 02:59:58 2016 Sep 23 09:12:01 Hello there, I have baked meta-toolchain-qt5, and extracted sdk, then set up my qt creator. But I get error that says : :-1: error: skipping incompatible /opt/fsl-imx-fb/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Quick.so when searching for -lQt5Quick Sep 23 13:34:31 ere Sep 23 13:34:47 woy puki Sep 23 13:34:50 pada dimana Sep 23 13:35:34 WHOIS Sep 23 15:58:49 Hmmm, would anyone be opposed to removing reliance upon the target path variables being exported? we explicitly pass them into autoconfsconfigure scripts, and for non-autotools, we should probably be more explicit with our variable passing anyway Sep 23 16:03:37 there are some random easy ones, like use of '$libdir' in do_install for no apparent reason, i think those would go in easy, but some of them involve passing 8 vars in EXTRA_OEMAKE Sep 23 16:03:43 i think its worthwhile to make it explicit, though Sep 23 16:13:36 kergoth: dont have strong opinions but what would it help us with Sep 23 16:15:22 khem: I'm looking to pare down our global exports, which would help make signatures a bit less brittle, since any global export has an effect on all task checksums, whether they're used or not. the intention is first to switch to using task level exports so the main vars are only exported for configure/compile/install/etc, then drop the pointless export of TARGET_ vars like TARGET_CC, which aren't used, then unexport BUILD_*, as that's not consistent and Sep 23 16:15:22 most use *_FOR_BUILD, and then unexport the target path vars Sep 23 16:15:30 but need to open an RFC thread about it Sep 23 16:17:09 I think that makes sense. I was about to say that passing it explicitly can hold up more memory since every submake will have to be passed this info Sep 23 16:17:26 but I guess we can gain from signature calculations Sep 23 16:23:14 i think steps 1 and 2 are obvious, the unexport of BUILD_ and the target path vars are more open to debate, since they require recipe changes, though not as many as one might think. i've completed world builds with those changes applied Sep 23 20:17:35 khem: is it possible for you to help me to find the invalid instruction? if so we can try to fix it Sep 23 21:00:45 Epic: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=pyyaml Sep 23 21:02:19 Crofton|work: lol Sep 23 21:02:33 seems popular Sep 23 21:02:59 well. looks like it finally made it into meta-python so probably likely solved Sep 23 21:03:10 problem* Sep 23 21:04:38 and has current version Sep 23 22:53:11 moto-timo: maybe answering over here is better... Sep 23 22:54:01 pyyaml +1 Sep 23 22:57:16 https://layers.openembedded.org/layerindex/recipe/44317/ Sep 23 22:57:32 re-reading email... Sep 23 22:58:54 somebody should publish meta-printing to layers.oe.org Sep 23 23:02:42 nerdboy: URL for meta-printing? Sep 23 23:11:31 * vmeson only finds: https://github.com/rossburton/meta-printing Sep 23 23:13:49 odd that it's not in one of nerdboy's repos: https://github.com/sarnold?tab=repositories Sep 23 23:17:38 it's under VCTLabs and pushes to the original in ross' github Sep 23 23:18:01 https://github.com/VCTLabs/meta-printing Sep 23 23:18:15 wth did he go... Sep 23 23:32:47 https://github.com/VCTLabs/meta-printing <= moto-timo Sep 23 23:33:11 synced up with rossburton/meta-printing Sep 23 23:33:33 ah Sep 23 23:34:32 grr. stupid debian mirrors are so flaky Sep 23 23:35:20 want me to move it back to my area? Sep 23 23:35:31 unrelated comment Sep 23 23:35:46 I'm rebuilding all our docker containers and debian 8 failed Sep 23 23:36:55 nerbody: you might want to try the pypi.bbclass from meta-python Sep 23 23:37:18 (or just copy it) Sep 23 23:37:24 mine can go away if you fix krogoth... Sep 23 23:37:31 heh Sep 23 23:38:01 it was based on the broken one Sep 23 23:38:44 there are also a couple that need newer versions than pypi has Sep 23 23:39:10 it's the maintenance branch dilemma... Sep 23 23:39:21 but broken is broken Sep 23 23:39:21 but if pypi is up-to-date we can use it Sep 23 23:39:36 it doesn't break the build Sep 23 23:39:50 but it doesn't do anything Sep 23 23:40:05 no packages, just a silent fail Sep 23 23:40:15 my favorite kind :/ Sep 23 23:41:07 just switch yours to the tarball and update hashes Sep 23 23:43:10 zipfile is probably filled with the wrong line-endings or worse... Sep 23 23:43:57 * nerdboy goes back to the funky firmware Sep 24 00:20:25 nerdboy: grrrr. it was a github archive. we should never have accepted that Sep 24 00:20:37 ephemeral as all get out Sep 24 00:23:15 /whois moto-timo Sep 24 00:23:20 heh. Sep 24 00:25:32 so who is moto-time ? I'm https://www.linkedin.com/in/randy-macleod-01a6211 Sep 24 00:26:16 moto-timo is co-maintainer of meta-python layer :) Sep 24 00:26:58 https://layers.openembedded.org/layerindex/branch/master/layer/meta-python/ Sep 24 00:29:06 ok, so Tim Orling I'd guess. Sep 24 00:29:11 might be Sep 24 00:29:20 ;) Sep 24 00:29:25 Hi Randy Sep 24 00:29:26 ah, right, I didn't have to dig into the git logs... Sep 24 00:29:38 Hi Tim Sep 24 00:54:44 is pkgconfig broken on krogoth-next or is it just me Sep 24 00:58:26 it's just me gah **** ENDING LOGGING AT Sat Sep 24 02:59:58 2016