**** BEGIN LOGGING AT Fri Jan 24 02:59:59 2014 Jan 24 03:11:05 denix: meta-qt5 and the freescale meta repo (pulls down oe/etc) all master, then bitbake nativesdk-qtbase errors out on having installed files not in a package (looks like all of it). Jan 24 03:14:14 whats the erorr ? Jan 24 03:26:07 staylor: there may be files not packaged, but is it a fatal error in your distro? Jan 24 03:30:26 poky marks them errors now Jan 24 03:32:11 khem: better poky harder :P Jan 24 03:32:31 mranostay: +1 :) Jan 24 03:34:27 yeh yeh Jan 24 04:53:59 denix: when will dora branch for meta-ti will be created Jan 24 04:56:06 denix: I can certainly have yocto ignore the files not packaged, but it's all of them (or nearly all) including qmake and related configurations. Jan 24 04:57:46 staylor: not according to this https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/nativesdk-qtbase.inc#L46 Jan 24 04:57:54 khem: what's the difference from master? Jan 24 05:00:22 denix: I've got that line too, but I see that the files are installing into /opt/poky/... which tells me it's ignoring the prefix for ~/yocto/build/tmp/... Jan 24 05:00:22 denix: not yet Jan 24 05:00:47 staylor: don't know what /opt/poky is Jan 24 05:01:07 khem: so, what's the point of a separate branch, if there are no differences :) Jan 24 05:01:22 it's where the sdk would install to, but I'm not sure why doing a bitbake nativesdk-qtbase would be installing into there Jan 24 05:02:17 are you getting files installed into /opt while bitbaking something? Jan 24 05:05:35 it's not actually installing there no, I guess I was interpreting it wrong but it's complaining about files in /opt/poky (which is where the nativesdk would install into) not being part of the package. Jan 24 05:06:11 I guess what I'm getting at is if it's working for others, curious if there's a step I'm missing I'm not changing anything just checking out meta-qt5 master and trying a bitbake nativesdk-qtbase Jan 24 05:08:58 staylor: qtbase has gazillion files, nativesdk-qtbase only picks up few tools and skips the rest. can you tell your config to not fail on unpackaged files? Jan 24 05:10:33 yeah that's no problem, is it just a case that it was tested against a version of yocto which doesn't error out on this condition? Jan 24 05:13:00 where should I expect the correct qmake to be located after this? It's not installed as part of the deploy/sdk script. Jan 24 05:14:23 staylor: do you have a meta-toolchain recipe that picks nativesdk-qtbase? Jan 24 05:15:10 staylor: and yes, it was tested against a different version of yocto :) Jan 24 05:15:31 no, that would be the missing link. I've been using my conf/local.conf to add qtbase and whatnot which works fine for my target installation but I've not created any special layers Jan 24 05:16:50 so when I do a meta-toolchain it's not building nativesdk-qtbase when I do meta-toolchain I've just been building it with a direct bitbake nativesdk-qtbase, I'm not clear on the connection to get that installed correctly so I can build packages out of yocto. Jan 24 05:22:58 staylor: when you bitbake nativesdk-qtbase, you get packages. you'd need a packagegroup that lists necessary nativesdk-qtbase-tools etc. packages to bundle into an sdk... Jan 24 05:23:50 so it Jan 24 05:24:09 so it's not a command you run but an actual configuration you need to create defining the package group? Jan 24 05:27:50 I wasn't familiar with packagegroups, thanks I'll look into that seems like it explains the missing piece to building/installing the correct host tools. Jan 24 05:29:59 well, I told you in the beginning, that corresponding meta-toolchain piece is not there yet... Jan 24 06:06:24 denix: yeah but when you say that you just mean what's missing is a packagegroup definition telling nativesdk-qtbase to install say nativesdk-qtbase-tools? Jan 24 08:01:41 Hi All, Jan 24 08:01:47 Sorry to bother with a simple and stupid question. Jan 24 08:01:52 I have added a library to the core-image-minimal (through IMAGE_INSTALL_append) *but* headers files aren't present in the sdk generated with meta-toolchain. Jan 24 08:02:20 How can I obtain a toolchain with necessary headers? Jan 24 08:02:25 Thanks in advance! Jan 24 08:04:29 abogani: How about using 'bitbake core-image-minimal -cpopulate_sdk' to generate the SDK? Jan 24 08:05:25 * abogani runs to try it... Jan 24 08:12:12 abogani: don't forget the space: -c populate_sdk Jan 24 08:14:17 ChenQi: It works, thanks! Jan 24 08:14:53 ndec: I haven't forgot the space. ;) Jan 24 08:15:01 cool ;-) Jan 24 08:26:29 good morning Jan 24 09:03:38 hi rburton and bluelightning Jan 24 09:03:49 the SDK will also contain the toolchain (i.e. compiler, linker, etc?) Jan 24 09:03:56 ? Jan 24 09:04:57 lpapp_: given that's almost the entire point of the SDK, yes Jan 24 09:05:48 well, not only. Jan 24 09:06:00 also the libraries and headers so that you do not need to grab the dependencies. Jan 24 09:06:11 getting the toolchain is simpler than grabbing all the dependencies. Jan 24 09:06:40 bluelightning: I am referring here to an external toolchain FWIW. Jan 24 09:07:16 bluelightning: rburton also, which variables does the intalled SDK set up? Jan 24 09:07:30 (cannot find it in the documentation after a quick search, and the SDK installation does not output them either...) Jan 24 09:09:48 lpapp_: I think the answer is no, out of the box Jan 24 09:10:37 bluelightning: answer to which question? Jan 24 09:10:55 to external toolchain? Jan 24 09:12:26 yes Jan 24 09:13:24 bluelightning: what about the SDK variables? Jan 24 09:13:40 lpapp_: I'd suggest checking the manual Jan 24 09:14:33 yeah, well, I did. Jan 24 09:14:35 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#sdk-dev-environment Jan 24 09:15:23 http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#sdk-dev-environment Jan 24 09:15:27 I only found that. Jan 24 09:15:33 but that is about the SDK build Jan 24 09:15:37 not the SDK usage itself. Jan 24 09:16:35 bluelightning: I do not see the relevance in there. Jan 24 09:16:53 bluelightning: what I am expecting is at the very least, the installation path put into a sysroot environment variable. Jan 24 09:17:49 lpapp_: if you mean the default installation path, the variable you want is SDKPATH Jan 24 09:18:18 well, in an ideal world, I would need an include path or library, at least. Jan 24 09:18:25 but the bare minimum is the sysroot path, yes. Jan 24 09:18:32 so that I can build the formers myself. Jan 24 09:19:36 provided the SDK is FHS compliant. Jan 24 09:20:41 bluelightning: what does it mean no out of the box ? Jan 24 09:20:53 is it easy to circumvent with setting some rule for the sdk generation? Jan 24 09:24:32 bluelightning: why is the SDKPATH hidden gem undocumented? Jan 24 09:25:02 it's like any undocumented variable in our system, we just haven't got to it Jan 24 09:25:06 I have to go, bbl Jan 24 09:28:06 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5755 Jan 24 09:28:07 Bug 5755: normal, Undecided, ---, david.c.stewart, NEW , Document the SDKPATH variable Jan 24 10:05:56 i just built chromium for ARM (imx6 cpu) with yocto on my PC, but i'm getting the following error: "chromium-32.0.1664.3-r2.cortexa9hf_vfp_neon.rpm is for architecture cortexa9hf_vfp_neon ; the package cannot be built on this system" Jan 24 10:06:47 that's when I use alien to install on debian. when I try with rpm -ivh it errors due to failed dependencies even though all the dependency packages are right there in the same directory. Clearly I'm doing something wrong :-) Jan 24 10:06:56 any ideas? Jan 24 10:48:59 dshankar: logic error? you built it but you can not build it? Jan 24 10:49:33 zecke: hm I see what you mean. Jan 24 10:50:22 to be clear, I ran bitbake chromium on my PC with some recipes, and the /tmp/deploy folder contains a uImage + folder full of RPMs (including the chromium rpm) Jan 24 10:50:43 I tried to install just the chromium rpm with rpm, yum, and alien on my ARM device (all of which failed) Jan 24 10:52:52 my goal was to cross compile chromium, and not to build a linux kernel. not sure how I ended up with a uImage in my /tmp/deploy Jan 24 10:54:15 dshankar: but the base distribution is not yocto built? Jan 24 10:54:30 ah debian Jan 24 10:54:46 well. the arch is simply not compatible Jan 24 10:54:50 yes I think it was by someone else before me Jan 24 10:55:08 zecke: in what sense? at an OS level? at a CPU level? Jan 24 10:56:05 dshankar: first by configuration/architecture. With ABI you might be lucky.. but the eglibc chromium was built against might not match Jan 24 10:58:48 I don't quite understand everything you said (I'm a noob at all this sorry!). by ABI do you mean armel vs armhf? I'm running deb jessie armhf and built chromium for armhf as well Jan 24 12:38:14 * JimBaxter returns (" " [11m 5s]) (total away time: 11m 5s) Jan 24 13:43:59 what is the name of step that creates .cpio.lzma image and copies to tmp/deploy/images? Jan 24 13:45:13 Xz: see image-types.bbclass Jan 24 14:45:58 is there still work being done on getting qemu working with wayland/weston? I have come across a lot of articles talking about egl/opengl es2 with qemu but most of them are from 2011 Jan 24 14:57:45 hi, i am trying to create a recipe that will build pg-journal(https://github.com/intgr/pg_journal) the problem is that it uses pgxs to build the postgresql module and when it runs do_compile make throws "make: *** No targets. Stpo.", could it be that because it uses pgxs to make this module that it cant finde any src? Jan 24 16:16:01 Has anyone tried creating an image you can boot with virtual box? I tried booting my qemu image but it seems to be failing somewhere in the kernel. Jan 24 16:20:30 gjohnson: see http://twoerner.blogspot.fr/2013/12/using-oeyocto-to-create-vms.html Jan 24 16:20:38 it is possible, and it works fine ;-0 Jan 24 16:20:58 nedec: thanks, I will take a look Jan 24 16:31:59 what does it mean to build distroless? Jan 24 16:34:21 it means what it says, build without a distro set, using all defaults for everything Jan 24 16:34:24 gjohnson: that there isn't a distro policy overriding the default policy in oe-core Jan 24 16:34:58 so in the local.conf just don't set a distro. I will try that. Jan 24 16:35:46 DISTRO = "" for older versions or DISTRO = "nodistro" for master Jan 24 17:09:34 guh, the tmux devshell seems awfully broken again Jan 24 17:44:01 Good morning everyone! Quick question (I hope), I built core-image-sato successfully on Dora. It boots fine but I'd like to disable the login manager (GDM?) entirely and go straight into the desktop. Is there an easy way of doing this? I played around with the /etc/gdm but I only broke the system. Jan 24 17:44:58 b1gtuna: core-image-sato doesnt have a login manager, so presumably you're building Angstrom and that's adding one for you Jan 24 17:45:22 moin Jan 24 17:45:48 rburton: ah.... i'm using Gumstix. Thanks for the pointer. Jan 24 17:46:25 b1gtuna: the poky core-image-sato should do exactly what you said Jan 24 17:46:47 ie, boot straight into the sato dsektop Jan 24 17:46:49 b1gtuna: changing the x init manager back to what oe-core has will probably do it Jan 24 17:47:10 or maybe gumstix have some other changes that add a login manager Jan 24 17:47:21 the simplest would be the mini-X-session thing Jan 24 17:47:25 fwiw, the bit of oe-core you want to use is xserver-nodm (no display manager) Jan 24 17:47:29 mr_science: rburton: yes it has to be something in the gumstix layer Jan 24 17:48:05 rburton: is xserver-nodm a feature that i can add? Jan 24 17:48:16 (is not a recipe i should list in my image recipe) Jan 24 17:48:38 i think it should default to that if you have no dm in your image/deps Jan 24 17:49:29 something is pulling in gnome/gdm but it shouldn't be required Jan 24 17:49:44 mr_science: hmm interesting. I thought i made sure i removed all gdm related stuff. Checking agian. Thanks again :) I will report back Jan 24 18:02:29 mr_science: rburton: ahh my local.conf contained a line for gdm. Thanks!! Jan 24 18:09:51 b1gtuna: hah :) Jan 24 18:10:12 curious for a clarification on nativesdk, is that meant to install development tools on the target? Jan 24 18:15:12 staylor: no. nativesdk builds tools that run on the machine the sdk runs on, afaik Jan 24 18:16:14 kergoth: okay that makes more sense, thanks. Jan 24 19:07:37 Hello everybody, am I not allowed to do 'inherit core-image-sato'? I get a parse error. Jan 24 21:26:33 I suddenly got an error: ERROR: fuse is listed in PACKAGES multiple times, this leads to packaging errors. I wrote fuse recipe file by myself, have a line like this: PACKAGES =+ "${PN} ". How to fix this error? Jan 24 21:29:15 can any expert help out? Jan 24 21:29:45 remove that line Jan 24 21:29:52 the default PACKAGES already has ${PN} Jan 24 21:29:56 addin git a second time doens't gain anything Jan 24 21:30:14 oh, i'm guessing you're trying to move it ahead of earlier packages? Jan 24 21:30:52 [kertoth], are you talking to me? You meant default "PACKAGES" already has "fuse"? Jan 24 21:31:40 yes, i'm talking to you Jan 24 21:32:12 ${PN} is already in PACKAGES, so there's no point in adding it again unless you're trying to move it earlier in the list, and there are better ways to do that Jan 24 21:32:18 it depends onw aht you're trying to accomplish Jan 24 21:32:58 [kergoth] I just want to add fuse into my image. If I remove that line, it means "PACKAGES" won't have "fuse", right? Jan 24 21:33:09 no Jan 24 21:33:11 you're wrong Jan 24 21:33:24 as i already said, the default value for PACKAGES already has that Jan 24 21:33:34 don't do things you don't need to do, don't add lines you don't need to add Jan 24 21:34:22 [kergoth] enh ... ok. So are you saying in recipe file, no need to add anything like "PACKAGES =+ ${PN}"? Jan 24 21:34:31 and it will be added automatically? Jan 24 21:34:48 i've said it like 3 times now Jan 24 21:34:49 yes Jan 24 21:35:07 thanks, I'll give it a try Jan 24 21:35:12 every variable in a config file also is set in the recipes Jan 24 21:35:25 and bitbake.conf defines a fully fleshed out set of default packages and associated files variables Jan 24 21:37:49 [kergoth] the strange thing is, I added that recipe long time ago, but it never shows error until now. That puzzles me, and my tree (dylan) has't moved at all Jan 24 21:38:11 well, something must have changed, the system doesn't change itself :) Jan 24 21:40:17 kergoth: heisenburg's build system :P Jan 24 21:41:15 kergoth: well, the only difference is that this build tree is a fresh check-out. Anyway, thanks Jan 24 22:17:07 hmm, busybox fails for genericx86-64 Jan 24 22:53:29 why does the autoconf recipe say RDEPENDS_${PN} = "m4 gnu-config"? As far as I can tell, it's gnu-config that should depend on autoconf, not the other way around. git-blame says that line of code is from 2007...maybe it's just a latent bug.... Jan 25 00:24:21 evanp: no its correct Jan 25 00:28:20 autoconf also have autoreconf and that will need services of config to run config.guess and so on Jan 25 00:53:06 Any objections to pursuing https://github.com/kergoth/meta-mentor/commit/ecfcc1c going upstream in some fashion? (likely a combo of terminal.bbclass and bitbake.conf) Jan 25 00:54:14 * kergoth tests some more Jan 25 00:54:38 I got sick of using fish as my shell breaking my builds Jan 25 00:54:57 at first i overrode SHELL, but that made devshell a lot less pleasant :) Jan 25 01:06:21 look ok to me **** ENDING LOGGING AT Sat Jan 25 02:59:59 2014