**** BEGIN LOGGING AT Thu Nov 06 03:00:00 2014 Nov 06 10:04:39 i'm trying to compile alsa-utils outside of OE and I've found that alsa-dev isn't in the SDK, is this expected or should it be included? Nov 06 10:05:03 morning all Nov 06 10:05:12 hi jackmitchell Nov 06 10:05:29 bluelightning: morning Nov 06 10:05:49 morning Nov 06 10:06:21 jackmitchell: well, -dev packages are only in the SDK if a corresponding package is in the image from which the SDK is created (in the case of -c populate_sdk) Nov 06 10:06:36 jackmitchell: or alternatively if you explicitly add them to TOOLCHAIN_TARGET_TASK Nov 06 10:06:47 hi mago_ Nov 06 10:07:28 bluelightning: so I do have alsa in my image, but the alsa-dev package is manually specified in the bb so I'm wondering if the logic is a bit wonky Nov 06 10:08:25 well the logic boils down to a direct name mapping; if there is no package called "alsa" then "alsa-dev" won't be included Nov 06 10:08:45 we could perhaps change the package naming so that that does happen Nov 06 10:09:44 does host distro matter for sstate cache, or is it just arch? my dev machine is running 64-bit Ubuntu, while our build servers are running some Redhat dist (also 64-bit x86). I seems like none of the native tasks are setscene'd, would this be related to the distro difference? I was under the impression that OE is distro agnostic and builds all things from scratch, except for a few basic tools mentioned in Nov 06 10:09:47 ASSUME_PROVIDED? Nov 06 10:10:35 mago_: so, it is mostly distro-agnostic in that it is intended to be able to build on various different host distros Nov 06 10:10:59 mago_: the catch with sstate is that we do keep the native parts separate per distro even if the hashes do not change Nov 06 10:11:50 the reason for that is whilst you can usually re-use native artifacts containing binaries linked to an older libc on a system with a newer libc, you can't do it in the reverse Nov 06 10:13:07 if you know the artifacts are safe to re-use (i.e. the host distro where the artifacts were built has an older libc than the one(s) where you want to re-use them) then you can symlink the native dir(s) within the sstate cache directory Nov 06 10:13:24 I'm sure we don't document that well right now... Nov 06 10:15:26 so as long as our dev machines run a newer version of libc than the build servers, we should be safe to use the build server native cache even on our dev machines? Nov 06 10:17:04 newer or the same upstream release of libc, yes Nov 06 10:17:40 but probably the best idea would be to switch distro on the build server, i guess Nov 06 10:38:31 mago_: depends if that's practical in your situation Nov 06 10:39:01 mago_: I guess I would say try it on one machine, you're going to find out pretty early whether it's going to work or not Nov 06 10:39:11 (for sure that is) Nov 06 10:59:22 damn, transient build fail in python-lxml Nov 06 11:01:34 jackmitchell: actually looking at master it looks like alsa-dev has been replaced by alsa-lib-dev already in the 1.7 development cycle Nov 06 11:07:33 bluelightning: ah, that's what I was going to propse it change too; someone beat me to it :) Nov 06 15:28:14 Hi, could someone give me some hints on how to add qmake (meta-qt5) to my image sdk? Nov 06 15:29:28 I'm trying to add it by using nativesdk-qtbase to TOOLCHAIN_HOST_TASK, and then running bitbake -c populate_sdk, but it seems it's not enough Nov 06 15:29:48 qml stuff is getting into the sdk bin path, but no qmake Nov 06 15:30:50 pespin hm Nov 06 15:31:09 there was some discussion on the oe ml I think Nov 06 15:31:16 please search the archiv Nov 06 15:31:41 woglinde: Ok I will. I've beeng tring to find related stuff but I haven't been able to find a solution yet Nov 06 15:40:39 woglinde: I think the problem is actually qmake is not being built inside qtbase when you run nativesdk-qtbase (which requires qtbase.inc) Nov 06 15:40:55 then of course it's not set into the sdk destination dir I guess Nov 06 15:43:10 pespin hm qmake is coverd by dev or tools recipe or so Nov 06 15:43:27 that you need in your task or image Nov 06 15:43:49 woglinde: well I see a qmake folder with some sources when qtbase is downloaded, so I guess it should be built there, isn't it? Nov 06 15:44:59 pespin sorry I am not so deep in the qt build, but as I said try to search the package recipe where qmake is include Nov 06 15:45:02 d Nov 06 15:46:57 woglinde: Ok thanks Nov 06 19:20:18 Using oe-core, I'm trying to build meta-toolchain with a native cmake. I've tried both TOOLCHAIN_HOST_TASK_append = " cmake " and TOOLCHAIN_HOST_TASK_append = " cmake-native " and bothe give me errors. What's the right way to do this? Nov 06 19:22:06 you want nativesdk-cmake Nov 06 19:22:17 awesome, thanks kergoth! Nov 06 19:22:20 np Nov 06 21:58:52 Hmm, why does gcc-cross-canadian depend on virtual/${TARGET_PREFIX}gcc? That's not making a great deal of sense to me. **** ENDING LOGGING AT Fri Nov 07 03:00:00 2014