**** BEGIN LOGGING AT Fri Dec 09 03:00:01 2016 Dec 09 09:31:05 morning Dec 09 10:35:17 hmm, a question about external toolchains, this TCMODE thing, can it be used per package or is it always for everything? basically I have some old u-boot which needs to be compiled with an old toolchain, while the rest of the system can use whatever is provided by oe Dec 09 10:37:40 i think its global Dec 09 10:37:45 as it controls what toolchain goes into the sysroot Dec 09 10:38:21 ok.. had that impression too, but wanted to make sure I got it right Dec 09 10:38:40 so for per-recipe things I can only try to hack the recipe or its makefiles? Dec 09 10:38:46 there is no default mechanism? Dec 09 10:44:10 well i know we did a system which shipped uclibc in one place and glibc in another by abusing multilib Dec 09 11:08:36 can TARGET_PREFIX be used per recipe? Dec 09 17:57:04 hello everyone Dec 09 17:57:12 anyone could help me? https://paste.debian.net/901443/ Dec 09 17:57:20 im trying to compile cryptodev Dec 09 17:57:53 but there's no /lib/modules/3.10.17/build directory Dec 09 18:15:35 meta-networking patches are pending for almost a month now. Dec 09 18:16:09 is Joe here? Dec 09 18:26:13 Jin|away: you are better off using external process for compiling and use OE to just do packaging in such cases Dec 09 18:26:38 rburton1: I sent a list of patches where I fixed the gst bad plugins for multilib case Dec 09 18:27:12 real fix would be to populate 'all' packages into multilib sysroots as well. Dec 09 18:27:23 guess itd be possible to muck around with multiple toolchains with per-recipe sysroots, but things would blow up pretty fast in the rootfs :) Dec 09 18:27:26 but then we have per recipe sysroot work going on hopefully that will fix it Dec 09 18:27:34 :) Dec 09 18:27:39 * kergoth ponders Dec 09 18:27:40 hehe Dec 09 18:27:43 panacea Dec 09 18:28:01 Anyone know why u-boot-qoriq needs to be built 32 bit for e[56]00, by chance? Dec 09 18:30:20 damnit, who rebased sdk-v2.0.x in the freescale u-boot? ERROR: u-boot-qoriq-2016.01+fslgit-r0 do_fetch: Fetcher failure: Unable to find revision a9b437f50e2051f8d42ec9e1a6df52de4bc00e1e in branch sdk-v2.0.x even from upstream. it's only available via the tag now, breaking meta-fsl-ppc Dec 09 18:30:35 maybe it's time to migrate to meta-freescale Dec 09 18:36:12 meta-freescale isn't even in the layer index. what exactly is the state of this? Dec 09 18:36:14 otavio? Dec 09 18:36:26 kergoth: hello Dec 09 18:36:56 1. what's the status of meta-freescale in general, and relative to meta-fsl-arm and meta-fsl-ppc, and 2. do you folks know that u-boot-qoriq in meta-fsl-ppc fails to fetch now? Dec 09 18:39:16 kergoth: the meta-fsl-arm and meta-fsl-ppc are in maintenance mode. The meta-freescale is where the development is happening Dec 09 18:39:58 kergoth: the fetch problem is indeed a serious issue but they are not taking it so seriously. Please report it to the mailing list please so I can forward it Dec 09 18:40:20 if that's the case, why is meta-freescale not in the layer index? Dec 09 18:41:24 also, if the other layers are in maintenance mode, shouldn't the readme files and layer index summaries indicate this? Dec 09 18:41:35 afaict there's no way i could discover what you just said without asking you Dec 09 18:41:37 which isn't ideal Dec 09 19:22:17 kergoth: it should be added. I will do it on monday Dec 09 19:22:54 kergoth: indeed. If you are in the mood, please send a patch. Or we do it next week **** ENDING LOGGING AT Sat Dec 10 03:00:00 2016