**** 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