**** BEGIN LOGGING AT Thu Jan 23 02:59:59 2014 Jan 23 08:34:24 good morning Jan 23 08:35:11 mckoan: morning-ish Jan 23 09:53:51 morning all Jan 23 10:49:28 hi, the SDK is not populated by default, right? Jan 23 10:51:06 a sdk isn't created by default, no Jan 23 10:51:17 thanks. Jan 23 10:57:30 rburton: is it possible to configure it as opposed to setting this argument all the time? Jan 23 10:57:44 so on my machine, it would /always/ get the sdk, too. Jan 23 10:58:51 you could use a special image that depended on both the normal image task and the populate_sdk task of the usual image Jan 23 10:59:09 ah, something like a core-sdk image. Jan 23 10:59:38 or just add a task dependency from do_build on do_populate_sdk Jan 23 11:00:10 but you probably would need to do that at an image level Jan 23 11:15:07 is it a long process to rebuild the sdk, or it will skip everything if nothing changed? Jan 23 12:09:04 foo-eglibc-x86_64-arm-toolchain-0.1.sh (1/389225, 1) Top -> wow? Jan 23 12:09:10 wow at _389225_ Jan 23 12:10:42 why is that long a script? :/ Jan 23 12:11:09 is the whole rootfs bundled into the script? Jan 23 12:11:24 it seems to be 93MB, so I cannot be sure. Jan 23 12:12:54 it is basically a selfextracting archive, yes. Jan 23 12:17:17 any reason why it generates x86_64? Jan 23 12:17:20 not x86? Jan 23 12:17:33 well what is your devhost Jan 23 12:17:37 I am using x86_64 host with an x86 chroot. Jan 23 12:17:39 nope Jan 23 12:17:46 the devhost is the chroot which is definitely x86. Jan 23 12:18:04 it is possible that Yocto gets confused and it is a bug. Jan 23 12:18:22 but I hope it can be already worked around. :) Jan 23 12:18:31 either that, or you need to take a longer look into local.conf. i think i remember the sdk arch being set there. Jan 23 12:18:39 ok, sec. Jan 23 12:19:03 SDKMACHINE Jan 23 12:27:14 ndec: yes, exactly, I have just found the same here, http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#sdk-generation-dev-environment Jan 23 12:35:23 ndec: LetoThe2nd well, what is surprising is that it is commented, so the default should be i686.... based on the documentation. Jan 23 12:36:12 what shall I do to figure out why it is not taking the default into consideration? Jan 23 12:37:58 bitbake -E or what was it? :) Jan 23 12:38:38 right, bitbake -e | grep SDKMACHINE does not provide anything comprehensive for me. Jan 23 12:39:36 here is the output of that, fwiw: http://pastebin.kde.org/pbmsey7o7 Jan 23 12:56:57 lpapp: hmm. my observations make me believe that it default to the current host machine. Jan 23 12:57:18 but i haven't looked into the details Jan 23 12:57:19 * LetoThe2nd would think the same. Jan 23 12:57:41 and if it pulls from uname, not from environment no chroot will save you. Jan 23 12:59:06 lpapp, SDKMACHINE is used to tell bitbake which of the meta/conf/machine-sdk/*.conf files to include Jan 23 12:59:51 those conf files only set SDK_ARCH which is actually used by the populate sdk task. Default value for SDK_ARCH = ${BUILD_ARCH} Jan 23 13:02:28 i don't find where SDKMACHINE is defined if local.conf does not set it. Jan 23 13:12:45 it's not defined anywhere Jan 23 13:13:14 it's used in conf/bitbake.conf to include conf/machine-sdk/${SDKMACHINE}.conf Jan 23 13:14:55 if it's not defined, no file is included and SDK_ARCH ends up being BUILD_ARCH, if it is, it will include that file which in turn will set the proper vars (including SDK_ARCH). Jan 23 13:39:03 ah. i se.. Jan 23 13:39:05 see Jan 23 15:00:54 blitz00: so the documentation is basically wrong. Jan 23 15:01:19 or I am reading it wrong... Jan 23 15:15:15 morning Jan 23 15:20:33 http://pastebin.kde.org/prrqjuknu -> why am I getting this warning when trying to use the i686 SDKMACHINE type? Jan 23 15:20:41 (can I ignore it?) Jan 23 15:20:50 I mean, shall I? Jan 23 15:22:36 lpapp: you probably should wipe the sysroot first. Jan 23 15:23:09 why ? Jan 23 15:23:22 what is wrong about generating two different SDKs without deleting one of them ? Jan 23 15:23:42 as the warning says, they both 'put' files at the same place. Jan 23 15:23:51 so what ? Jan 23 15:24:07 Sounds like an enchancement that should be made, right ? Jan 23 15:24:13 it is a valid use case AFAICT. Jan 23 15:25:26 well, i don't know in your case. each time i get that, i am responsible for such things. Jan 23 15:25:35 e.g. i am moving files withing my recipes. Jan 23 15:26:14 well, how to debug it? Jan 23 15:26:35 so how to clean up the sdk? Jan 23 15:26:43 without cleaning up the whole image build? Jan 23 15:26:50 is there some -c cleansdk? Jan 23 15:27:18 just wipe the sysroot. that's not an expensive thing. Jan 23 15:27:37 sounds the second enhancement request right in there. :) Jan 23 15:27:46 -c cleansdk for bitbake could aid this. Jan 23 15:28:16 well, a better way would be the warnings don't appear for different target machines Jan 23 15:28:34 that, too, but it is still a valid request Jan 23 15:28:40 to wipe away the SDK Jan 23 15:29:23 not sure i understand why you'd want to wipe away just the sdk Jan 23 15:30:22 err.. because i told him so.. ;-) maybe i was wrong then. Jan 23 15:30:39 oh, no. that's not what i said... Jan 23 15:32:04 rburton: because I do not need the built SDK anymore. Jan 23 15:32:21 and I would like to clean up it for space and cleanness. Jan 23 15:32:28 it up* Jan 23 15:33:10 building both sdks (i686, x86_64) in the same sysroot without warnings was fixed recently Jan 23 15:33:35 I don't know if it's in master yet, but the patch was sent a few days ago Jan 23 15:33:51 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5396 Jan 23 15:33:51 Bug 5396: normal, Medium, 1.5.1, laurentiu.palcu, RESOLVED FIXED, switching SDK hosts causes QA issues Jan 23 15:49:19 otavio: you around, want to check on 4510 Jan 23 15:50:40 sgw_: I am around but busy Jan 23 15:50:52 sgw_: does it need to be now? Jan 23 15:51:11 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4510 Jan 23 15:51:12 ? Jan 23 15:51:12 Bug 4510: critical, High, 1.6, otavio, WaitForUpstream , GLX load vivante_dri.so failed Jan 23 15:51:16 otavio: no we can talk about it later Jan 23 15:51:19 Ok Jan 23 15:51:50 jackmitchell: commented, thanks. Jan 23 16:05:13 lpapp: if you want a patch backported, the quickest way is to cherry-pick it to the branch, verify it works, and mail it to the list Jan 23 16:06:29 rburton: do not have time unfortunately. Jan 23 16:08:39 lpapp: at least cc robert then, otherwise you're not asking the stable release maintainer Jan 23 16:09:00 rburton: sorry, I do not know who robert is... Jan 23 16:09:20 he's the stable release maintainer Jan 23 16:09:35 feel free to add him Jan 23 16:09:39 currently, all my hands are dirty. Jan 23 16:12:06 Hi folks -- quick quesiton. In the process of building a system image, I need a recipe to use passwordless ssh to contact a remote server to do some signing activities. I've gotten all the necessary variables from my environment through to the recipe, but it looks like it's runing in the pseudo environment -- things like 'id' report that I am root; apparently the ssh client thinks so too. Is there a way to turn it off when I execute Jan 23 16:12:06 some command? I tried unsetting LD_PRELOAD, but that didn't seem to help. Jan 23 16:14:06 its pseudo, and pseudo has its own variables to control its behavior. i dont recall what they are offhand, though Jan 23 16:15:02 Garibaldi|work: just do PSEUDO_UNLOAD=1 command Jan 23 16:15:14 Garibaldi|work: within a shell function Jan 23 16:15:26 bluelightning: ah, ok -- I'll give that a shot Jan 23 16:15:51 I think that's correct, seebs will correct me if I'm wrong hopefully ;) Jan 23 16:16:43 nice -- worked like a charm :-) Jan 23 16:16:46 thanks Jan 23 16:17:18 kergoth: that also for the help some time ago w.r.t. the variable pass-through, that also is working well Jan 23 16:17:28 np Jan 23 16:19:20 np Jan 23 16:20:06 for reference, pseudo is only used within a task if the task is marked as fakeroot Jan 23 16:20:45 ah, that's good to know too Jan 23 16:20:47 but there are a few tasks that are marked fakeroot out of the box, of course, so it's unlikely you'd see it in a recipe Jan 23 16:20:54 e.g. do_install, do_rootfs, etc. Jan 23 16:33:33 so.. I find myself needing to remove update-alternatives from opkg-utils. If there's no way to remove it entirely, then you'er hosed if you use a different update-alternatives provider while still using ipk packaging. any objection to adding a packageconfig to control its inclusion in opkg-utils? Jan 23 16:33:48 that's cleaner than includinng based on PREFERRED_PROVIDER directly Jan 23 16:38:50 kergoth: sounds reasonable, but you'd probably want to ask Paul Barker Jan 23 16:39:32 k, thanks Jan 23 16:51:19 rburton: can I ignore the SDK warning? Jan 23 16:51:22 jackmitchell: ^ Jan 23 16:51:29 or I should start from scratch? Jan 23 16:54:23 lpapp: it's ignorable, just a warning that two packages wrote the same file Jan 23 16:54:28 in this case, two different builds of the sdk Jan 23 16:55:35 rburton: ok, so problems foreseen out of this. Jan 23 16:55:52 literally zero problems Jan 23 16:57:46 lpapp: safe to ignore from my experience Jan 23 17:02:00 thanks to both, then. :] Jan 23 17:36:29 rburton: do people chroot into the sdk sysroot, or what is the generic way of using the installed SDK? Jan 23 17:36:44 the installer comes as an installer that you execute Jan 23 17:36:45 or setting the include and library paths through environment variables, etc? Jan 23 17:36:54 yes, of course. Jan 23 17:36:55 and that comes with a script that sets env vars Jan 23 17:36:58 this is in the documentation Jan 23 17:38:40 rburton: where exactly? Jan 23 17:38:42 http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#sdk-dev-environment Jan 23 17:38:45 cannot find it in here Jan 23 17:44:28 rburton: the script could really write that out at the end of the installation.... Jan 23 17:45:06 perhaps I should file a bugreport for that one. Jan 23 17:45:52 rburton: because this is all I got, http://pastebin.kde.org/ Jan 23 17:51:57 anyone? :/ Jan 23 17:52:14 I've got questions about meta-qt5 if anyone could help out, specifically installing nativesdk-qtbase/qttools, I've added qt5 using CORE_IMAGE_EXTRA_INSTALL and it's working fine but qmake and the various headers are not getting populated on a bitbake -c populate_sdk core-image-minimal Jan 23 17:53:13 JaMa: ^ Jan 23 18:04:56 Good morning everyone! Does anyone know a good multitouch testing tool? Preferably with a visual feedback? Jan 23 18:05:50 b1gtuna: is this related to the Yocto project? Jan 23 18:06:44 lpapp: perhaps not, but i was hoping to find a recipe of such tool. My apologies if it was inappropriate. Jan 23 18:07:05 ah, you mean if something like that is integrated into Yocto. Jan 23 18:07:16 lpapp: that's right! Jan 23 18:07:41 well, first figure out what softwares provide that. :) Jan 23 18:08:12 then use the recipe finder webtool. Jan 23 18:08:48 lpapp: ahh i have a tool in mind - it's called mtview. I forgot about the recipe finder tool. I am heading over to it now. Thanks lpapp :) Jan 23 18:10:52 staylor: does you core-image-minimal include qt? Jan 23 18:11:32 JaMa: yes it does, and it works fine I've got the cinematic demo working as well as my own Qt5 applications. Jan 23 18:12:22 JaMa: but I'd like to be able to build applications using either the SDK or Toolchain modes (build out of Yocto) but I'm not 100% clear if that's fully implemented or not in meta-qt5 yet. Jan 23 18:12:53 JaMa: and for reference, my end goal is to get PyQt5 working with meta-qt5 so any insights towards this would be greatly appreciated as well. Jan 23 18:13:36 denix: ^ Jan 23 18:13:55 staylor: denix is the right person to ask questions about SDK, I don't use that Jan 23 18:14:18 staylor: last time I was working on PyQt4 and it was quite a mess often Jan 23 18:14:28 not sure if the things are better with PyQt5 Jan 23 18:14:41 lpapp: Found mtview in the recipe finder tool. Thanks :) Jan 23 18:15:05 JaMa: great thanks. Yeah PyQt5 seems a bit cleaner but I haven't dug that deep into it, X11 dependencies appear to be removed now though so that's a start! Jan 23 18:24:57 b1gtuna: :) Jan 23 19:44:20 And yes, Garibaldi|work and bluelightning, PSEUDO_UNLOAD is the right thing. pseudo is smart enough to re-add itself to LD_PRELOAD otherwise. :) Jan 23 19:45:22 noted -- thanks :-) Jan 23 22:18:40 hi behanw Jan 23 22:21:36 hmm, anyone seen autogen-native fail? Jan 23 22:21:54 hmm, maybe its the old host gcc on this machine Jan 23 22:22:06 though one would think centos6 would be new enough to build poky Jan 23 22:26:56 hi zenlinux_ Jan 23 22:27:10 kergoth: what is the failure message? Jan 23 22:27:28 /scratch/2014.05/sb-1903/build/tmp/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:40:error: expected ')' before '__attribute__' Jan 23 22:27:45 the __attribute__ being a noreturn Jan 23 22:27:59 SCM_API void scm_error (SCM key, const char *subr, const char *message, SCM args, SCM rest) SCM_NORETURN; Jan 23 22:30:31 Huh, that's odd. It'd be interesting to see the preprocessed results for that line. Jan 23 22:30:48 * kergoth hasn't had time to dig further Jan 23 22:31:04 indeed, that was my first thought as well. presumably something is hokey with those macros Jan 23 22:31:16 My intuition would be to guess that for some unexplained reason, one of the parameter names happens to have been #defined. Which is why prototypes often omit parameter names. Jan 23 22:31:18 * kergoth tests outside his centos-6 chroot Jan 23 22:31:31 Either that, or something on an earlier line lacks a trailing ). Jan 23 22:35:52 ah, good, fails for me regardless of host distro. wonder if it's been tested since the last guile update Jan 23 22:51:48 hi mranostay Jan 23 22:52:08 gotta love how wpasupplicant crashes 3-5x an hour when I'm on the office wifi here Jan 23 22:56:12 zenlinux_: better than the lab area Jan 23 22:57:32 zenlinux_: have a desk this week so woot Jan 23 22:57:52 mranostay, whoa, quite the step up! Jan 23 23:00:28 zenlinux_: hope to camp here when someone on the team takes their two monthes Jan 24 01:39:27 denix: JaMa mentioned you might be a good person to ask about meta-qt5? Jan 24 01:40:22 staylor: what's up? Jan 24 01:41:29 trying to setup nativesdk-qtbase (or just meta-toolchain) and it's not clear to me if it's supported in master right now or not. Jan 24 01:42:35 for example adding qt5 with working cinematic demo works fine in my image, but when doing a bitbake -c populate_sdk image I don't get the sdk installed. Jan 24 01:53:38 denix: any ideas? Jan 24 01:55:41 staylor: I don't do -c populate_sdk, I do meta-toolchain instead. I don't think there are recipes in meta-qt5 for that yet Jan 24 02:01:09 denix: which qmake do you use for cross compile the one in x86_64-linux/usr/bin/qt5? Jan 24 02:12:02 staylor: there's one that gets built as part of nativesdk-qtbase Jan 24 02:28:34 denix: did you have to do anything to get it to build? bitbake nativesdk-qtbase errors out on packaging saying all files are installed but not shipped. Jan 24 02:50:13 staylor: what are you using it with? **** ENDING LOGGING AT Fri Jan 24 02:59:59 2014