**** BEGIN LOGGING AT Mon Sep 16 02:59:59 2013
Sep 16 07:25:37 <mckoan> good morning
Sep 16 09:05:10 <bluelightning> morning all
Sep 16 09:47:22 <mckoan> gm bluelightning, all
Sep 16 09:48:20 <melonipoika> morning all
Sep 16 09:48:57 <melonipoika> could anyone pelase point me to some tutorial or example how to create recipes for qt5 abse applications in yocto?
Sep 16 10:10:21 <Stygia> melonipoika, Not quite sure any exist. But I think you'll just need the proper DEPENDS for things you need at compile-time and RDEPENDS for things you need at runtime.
Sep 16 10:12:22 <melonipoika> thx Stygia, I am looking into the pro file of the qt app I am trying to integrate in my layer. It might be that the problem i am seing is there...
Sep 16 10:21:41 <melonipoika> it seems that qmake is not expanding a wildcast correctly...
Sep 16 10:22:01 <melonipoika> "make[1]: *** No rule to make target `network/*.cc', needed by `debug/*.o'.  Stop."
Sep 16 10:23:10 <melonipoika> i think that this line in my .pro file should be ok... "SOURCES += network/*.cc"
Sep 16 10:27:00 <melonipoika> if i do cd ${S} in qmake5_base_do_configure, it builds...
Sep 16 10:27:21 <melonipoika> in my case, DESTDIR = $(PWD)
Sep 16 10:27:23 <melonipoika> ups
Sep 16 10:27:34 <melonipoika> S = "${WORKDIR}/git"
Sep 16 10:29:13 <Stygia> melonipoika, Your S looks correct, immediately. Could you pastebin the recipe + relevant bits of the error output/
Sep 16 10:29:32 <melonipoika> sure
Sep 16 10:30:11 <melonipoika> this is the project I am trying to build
Sep 16 10:30:14 <melonipoika> https://github.com/topiolli/into
Sep 16 10:31:11 <eren> anyone remembers? http://catchwords.co/quote/146/
Sep 16 10:31:24 <melonipoika> http://pastebin.com/8ZzLzqvq
Sep 16 10:31:43 <melonipoika> the recipe
Sep 16 10:32:27 <Stygia> melonipoika, And what you pasted is the full error message?
Sep 16 10:32:41 <Stygia> melonipoika, Do you know if the qmake5 metaclass is all you need? No autotools?
Sep 16 10:32:42 <melonipoika> no, one sec
Sep 16 10:33:12 <Stygia> melonipoika, If all else fails, try creating the various sections manually, and then reduce the recipe - If you can do it manually, you can create do_configure, do_install etc, too.
Sep 16 10:33:43 <melonipoika> this is the error: http://pastebin.com/cVXRY24z
Sep 16 10:34:34 <melonipoika> yes, i tried modifying the do_compile to change to the soruce dir before building
Sep 16 10:34:43 <melonipoika> that solves the wildcast error
Sep 16 10:34:51 <melonipoika> but then i ahve troubles with the install...
Sep 16 10:35:04 <melonipoika> my recpie started to look way toohacky :-)
Sep 16 11:04:02 <otavio> sgw_: Hello
Sep 16 11:04:26 <otavio> sgw_: I got your e-mail about perf and I am looking at it
Sep 16 12:48:36 <BjornArnelid> Hi, I need to point at the target kernel sourcecode directory from within a bitbake recipie, is it possible to do that?
Sep 16 12:49:42 <zeddii> BjornArnelid, ${STAGING_KERNEL_DIR}, and make sure your recipe depends on virtual/kernel
Sep 16 12:51:04 <ant_work> zeddii: hi, early at kb today
Sep 16 12:51:12 <BjornArnelid> Amazing, thank you zeddii!
Sep 16 12:51:49 <zeddii> ant_work, it's fall now. my routine has to start earlier in the morning :P and I'm checking out your email right now.
Sep 16 13:26:24 <ant_work> zeddii: I'm going to patch kernel.bbclass and repeat jwessel two-step build
Sep 16 13:26:57 <ant_work> zeddii: I'll do that in a couple of hours, bbl
Sep 16 13:27:25 <n01> hi. I modified qemuarm.conf with KMACHINE_qemuarm = "qemuarma9". The problem is that compilation gives an error during do_kernel_configme
Sep 16 13:28:48 <n01> the error is here http://pastebin.com/K7FdGRQ0
Sep 16 13:41:46 <zeddii> n01: this is on master ? can you try the 3.10 kernel. I can have a look at it later, but I'm already chasing two other issues at the moment (perf and initramfs)
Sep 16 13:43:21 <n01> zeddii: it's not master, it's on dylan
Sep 16 13:44:12 <zeddii> ah yes, that could be the reason. no one was using a9 at all back then, I was just sort of carrying it around. I'll still try configuring it up later and see what I can see.
Sep 16 13:44:46 <n01> zeddii: I'll wait, thank you
Sep 16 13:45:50 <Crofton|work> that's a new one, use deb's to build an image ...
Sep 16 13:45:51 <n01> zeddii: so if I would use qemu with cortex-a9 kernel what do you suggest?
Sep 16 14:18:21 <scottrif> halstead: ping
Sep 16 14:32:31 <wfailla> hi @ all
Sep 16 14:33:06 <wfailla> i have a question to the "bitbake package-index"
Sep 16 14:34:23 <wfailla> is it possible to exclude pkges from that process without deleting them or is it possible to execute this command on an external host for the repos ?
Sep 16 14:49:25 <scottrif> halstead: ping
Sep 16 15:03:00 <kergoth> RP: I find myself needing to dump the vardeps and/or overall sigdata for a function that isn't a task. I think -S won't help there, any ideas on the quickest route?
Sep 16 15:04:46 <RP> kergoth: real world use or debug?
Sep 16 15:06:12 <kergoth> debugging, though its intermittant, so I might need to add it to our production builds until it explodes again
Sep 16 15:06:22 <kergoth> its the issue i ran into last week with the function being called not getting emitted
Sep 16 15:06:32 <RP> kergoth: you could just reference the function in some task. All the data should then get emitted
Sep 16 15:07:21 <kergoth> ha, right, good idea, that'd be an easy way. add a task that references it and fire off a -S before the actual build in our automated builds
Sep 16 15:07:25 <kergoth> i'll give that a shot, thanks
Sep 16 15:07:54 <RP> kergoth: or hack the dependency generation code with the specific function names so it always adds them into the sigdata
Sep 16 15:36:00 <gjohnson> I have a binary that isn't being relocated correctly.  How can I get the output of ldd to go from /lib/ld-linux.so.2 (0xb77cf000) to /opt/company/0.1/sysroots/i686-agleader-linux/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7792000) ?
Sep 16 15:49:24 <n01> zeddii: wtf, also with plain qemuarm I get error on do_kernel_configme
Sep 16 15:50:52 <zeddii> hmm. that makes no sense, since it is obviously QA'd nightly. when my perf build is completed, I'll switch to dylan and have a go.
Sep 16 15:52:00 <halstead> scottrif, I'm available on IRC now.
Sep 16 15:56:07 <scottrif> halstead: Hi - do I use my srifenbark@gmail.com email when generating a key or my intel email?
Sep 16 15:56:57 <halstead> scottrif, You don't need a new key.
Sep 16 15:57:26 <scottrif> halstead: ok - that was the first step on the site you gave me so I thought I needed to generate a new one
Sep 16 15:57:47 <halstead> scottrif, I was trying to link directly to the configuration block.
Sep 16 15:58:00 <halstead> scottrif, But I think it is just a simple typo.
Sep 16 15:58:09 <halstead> ProxyCommand ssh access.yoctoproject.or should be ProxyCommand ssh access.yoctoproject.org
Sep 16 15:58:46 <scottrif> halstead: ahh.. yes.  ok - I will fix that in the config file
Sep 16 15:58:56 <halstead> scottrif, Let me know if that works.
Sep 16 15:59:49 <scottrif> halstead: same error - do I need a new shell?
Sep 16 16:00:18 <halstead> scottrif, When you run "ssh access.yoctoproject.org" do you get the same error?
Sep 16 16:00:19 <scottrif> going privatre
Sep 16 17:39:24 <mr_science> moin
Sep 16 17:43:32 <dvhart> jwessel, ping
Sep 16 17:43:49 <dvhart> jwessel, I'm still having trouble with the grub-efi.bbclass console changes
Sep 16 17:44:05 <dvhart> jwessel, thought it might be easier to discuss here as I think I'm missing something
Sep 16 18:15:27 <ant_home> zeddii: using my BSP I seem unable to embed core-image-base in linux-yocto :/
Sep 16 18:16:08 <ant_home> zeddii: and adding INITRAMFS_TASK explicitly -> dependency loops
Sep 16 18:16:33 <ant_home> maybe I'm misinterpreting jwessel comments
Sep 16 18:17:03 <zeddii> ant_home, maybe. we need to raise jwessel to ask.
Sep 16 18:17:05 * zeddii looks
Sep 16 18:17:43 * ant_home removes kernel.bbclass patch
Sep 16 18:21:47 <ant_home> http://paste.debian.net/41298/
Sep 16 18:21:56 <ant_home> zeddii, fwiw ^^
Sep 16 18:34:19 <zeddii> ant_home, yep. that'll definitely work. I only want to get with jwessel and see if we can debug why the existing change broke your use case. if you can, send a summary email again, with the board and layers and we can run with it from there.
Sep 16 18:44:53 <ant_home> zeddii: what's strange is that with or w/out this last patch core-image-minimal isn't even created, not talking about embedded ;)
Sep 16 18:45:25 <ant_home> INITRAMFS_IMAGE = "core-image-minimal"
Sep 16 18:45:26 <ant_home> #INITRAMFS_TASK = "core-image-minimal:do_rootfs"
Sep 16 18:45:26 <ant_home> INITRAMFS_IMAGE_BUNDLE = "1"
Sep 16 18:45:46 <ant_home> in my linux-yocto_3.10.bbappend
Sep 16 18:46:23 <ant_home> I think I miss one step...
Sep 16 18:47:06 <ant_home> ...or I am doing smthg wrong ofc :p
Sep 16 18:51:38 <zeddii> ant_home, hmm.
Sep 16 18:51:40 * zeddii thinks
Sep 16 18:52:16 <Crofton|work> thinking is dangerous
Sep 16 18:55:21 <ant_home> I still think that is a bit pervert forcing a cpio this way into the virtual/kernel
Sep 16 19:14:58 <n01> zeddii: I deleted all in build and started from scratch for qemuarm but I still get the do_kernel_configme error
Sep 16 19:16:14 <n01> it seems something like http://comments.gmane.org/gmane.linux.embedded.yocto.general/4067
Sep 16 19:17:11 <zeddii> if you've mismatched the tools and meta, that could happen. I'll switch to dylan and start a build.
Sep 16 19:17:51 <n01> thanks
Sep 16 19:32:01 <zeddii> n01, hmm. dylan and qemuarm configs and builds fine out of the box for me. :(
Sep 16 19:33:32 <n01> zeddii: :(( ok ... thanks for trying :(
Sep 16 20:55:42 <fenrig> Hi i'm having troubles with "linux-firmware-iwlwifi-license", I probably have to do something to include it?
Sep 16 20:55:51 <fenrig> or accept the license
Sep 16 21:43:35 <fenrig> So I tried adding a license whiteflag for propietary
Sep 16 21:43:56 <fenrig> licenses, but that doesn't fix the problem -.-
Sep 16 22:18:53 <fenrig> Hi i'm having troubles with "linux-firmware-iwlwifi-license", I probably have to do something to include it? to accept the license?
Sep 16 22:22:51 <evanp_> fenrig: LICENSE_FLAGS_WHITELIST is case-sensitive; did you take that into account?
Sep 16 22:23:38 <fenrig> evanp_: not yet I'll retry :/ but I do think the problem lies somewhere else
Sep 16 22:29:23 <fenrig> evanp: Okay I'm retrying, I'll let you know the result. I already tried googling linux-firmware-iwlwifi-license and tried to find some yocto/OE references, but I haven't found mucht
Sep 16 22:29:26 <fenrig> *much
Sep 16 22:32:12 <evanp> fenrig: just look for which .bb file contains the bits you want, and look at its LICENSE
Sep 16 22:35:13 <fenrig> evanp: well I can't find "linux-firmware-iwlwifi-license"
Sep 16 22:35:30 <evanp> fenrig: grep for just iwlwifi
Sep 16 22:35:32 <fenrig> but linux-firmware.bb has got Proprietary as license
Sep 16 22:35:39 <fenrig> evanp: I did that :D
Sep 16 22:35:53 <fenrig> evanp: find | grep iwlwifi
Sep 16 22:36:03 <fenrig> did not find a .bb file
Sep 16 22:38:19 <evanp> fenrig: unless one of the sub-packages towards the bottom of linux-firmware_git.bb contains the file you want and has a LICENSE_${PN}-whatever override, then LICENSE_FLAGS_WHITELIST = "Proprietary" will probably do the trick
Sep 16 22:39:04 <fenrig> evanp: I just tried it with Proprietary and proprietary :/
Sep 16 22:39:15 <fenrig> evanp: so I think there is something else I have to do
Sep 16 22:39:31 <fenrig> evanp: also I have to note that linux-firmware is a mess concerning licenses
Sep 16 22:39:50 <fenrig> evanp: and iwlwifi is the current gen intel wifi drivers :/ so why that part particular?
Sep 16 22:41:00 <evanp> fenrig: because you referred to it.
Sep 16 22:41:39 <kergoth> i hate waiting for qt to compile
Sep 16 22:41:59 <seebs> Okay, that was an awesome problem.
Sep 16 22:42:02 <fenrig> evanp: I don't understand what you're trying to point out :D
Sep 16 22:42:08 <seebs> And I still don't know the fix, but I bet this will someday bite someone else.
Sep 16 22:42:25 <seebs> Imagine a recipe doing EXTRA_OECONF += "--extra-cflags='${CFLAGS}'"
Sep 16 22:43:08 <seebs> And another recipe doing EXTRA_OECONF := '${@oe_filter_out("some-string, "$PEXTRA
Sep 16 22:43:13 <seebs> argh typing
Sep 16 22:43:34 <seebs> ${@oe_filter_out("some-string", "${EXTRA_OECONF}", d)}
Sep 16 22:43:57 <seebs> So, what happens? What happens is, pkg-native gets built with --extra-cflags="${TARGET_CFLAGS}"
Sep 16 22:44:21 <seebs> Because the := forces an evaluation that hits at a time when bitbake doesn't yet know it plans to use BUILD_CFLAGS for CFLAGS.
Sep 16 22:44:53 <kergoth> yep, makes sense. that's always the danger of :=. which is, of course, why you'd want to use _remove now that we ahv eit :)
Sep 16 22:44:59 <seebs> I think I've seen talk about a _remove feature, but if anyone was wondering why := and filter-out aren't good enough, that's why.
Sep 16 22:45:12 <evanp> fenrig: I'm now a little confused too. Is your problem that you need the iwlwifi firmware blob in your image/initrd, but it isn't there, and you're not sure how to arrange for it to show up?
Sep 16 22:45:43 <seebs> I wonder whether _remove is in the branch I am working with.
Sep 16 22:46:07 <seebs> It is!
Sep 16 22:46:30 <fenrig> evanp: No, I just need linux-firmware for another dongle (with another chipset, I'm not using iwlwifi)
Sep 16 22:46:56 <seebs> Although the variable tracker is slightly wrong, because the finalize at line 415 of data_smart.py is pre-remove, I think.
Sep 16 22:47:46 <evanp> fenrig: your original question was <<Hi i'm having troubles with "linux-firmware-iwlwifi-license">>
Sep 16 22:47:54 <fenrig> yep
Sep 16 22:48:05 <fenrig> evanp: https://gist.github.com/fenrig/6587631
Sep 16 22:49:35 <seebs> Oh, I see. remove is processed WAY later, which is why it can't be shown in the finalize output.
Sep 16 22:51:15 <evanp> fenrig: what version of Poky are you using?
Sep 16 22:51:43 <fenrig> 1.4
Sep 16 22:51:50 <fenrig> but I'm using the angstrom version of it
Sep 16 22:51:53 <fenrig> v2013.06
Sep 16 22:52:04 <fenrig> and it's yocto 1.4 compatible
Sep 16 22:54:12 <evanp> fenrig: well, I guess the question is where that RDEPENDS on linux-firmware-iwlwifi-license is coming from. I don't see anything in Yocto 1.4 that produces such a package or a dependency on it--so perhaps there is a bug in angstrom?
Sep 16 22:55:14 <fenrig> evanp: angstrom uses official git repo's of oe :)
Sep 16 22:55:30 <fenrig> so I don't think it's an angstrom bug :)
Sep 16 22:55:31 <rburton> RDEPENDS_${PN}-iwlwifi-6000g2a-5 = "${PN}-iwlwifi-license"
Sep 16 22:55:31 <rburton> RDEPENDS_${PN}-iwlwifi-6000g2b-6 = "${PN}-iwlwifi-license"
Sep 16 22:55:31 <rburton> RDEPENDS_${PN}-iwlwifi-7260-7 = "${PN}-iwlwifi-license"
Sep 16 22:55:31 <rburton> (in linux-firmware)
Sep 16 22:55:31 <rburton> that's where the depends come from
Sep 16 22:55:52 <rburton> hm, there was a typo in that file
Sep 16 22:56:34 <fenrig> rburton: I'll take a look :)
Sep 16 22:56:42 <evanp> rburton: what are you looking at? "git grep iwlwifi dylan-9.0.1" doesn't produce those matches....
Sep 16 22:57:10 <rburton> evanp: its probably not in dylan
Sep 16 22:57:39 <rburton> but its either in your linux-firmware, or a bbappend a layer is adding
Sep 16 22:57:47 <rburton> meta-intel used to bbappend that and do iwlwifi stuff
Sep 16 22:57:48 <evanp> I thought dylan == 1.4
Sep 16 22:58:01 <rburton> yep, i was looking at master.
Sep 16 22:58:09 <rburton> sorry, should have said
Sep 16 22:58:19 <fenrig> "FILES_${PN}-iwlwifi-license =   "/lib/firmware/LICENCE.iwlwifi_firmware" "
Sep 16 22:58:25 <fenrig> is this the typo we are looking at?
**** ENDING LOGGING AT Tue Sep 17 02:59:58 2013