**** BEGIN LOGGING AT Thu Dec 18 02:59:58 2014 Dec 18 08:29:10 good morning Dec 18 09:42:04 morning all Dec 18 09:42:19 hi bluelightning Dec 18 09:53:47 hi mckoan Dec 18 11:50:54 Crofton|work: ping Dec 18 11:51:08 JaMa, pong Dec 18 11:51:15 * Crofton|work is hoping for good news Dec 18 11:52:46 yes, replied on ML already Dec 18 11:52:56 it is bypassing sstate when staging sip.h Dec 18 11:53:04 that's why it sometimes fails Dec 18 11:54:01 great. I'll see if I can figure this out Dec 18 11:54:10 I need to understand this sstate better anyway Dec 18 11:54:16 thanks for working this out Dec 18 11:54:35 just make sure that sip.h gets installed in "image" and sysroot_destdir directories Dec 18 11:54:48 instead of Makefile storing it in sysroot directly Dec 18 11:56:13 do_install is overridden Dec 18 11:56:24 with oe_runmake install Dec 18 11:56:43 I think because whatever the standdrad one is didn't install Dec 18 11:57:16 I suspect that only installs to sysroot Dec 18 11:58:06 it could be installed even in configure or compile task, I usually run them one by one while watching sysroot when the file appears Dec 18 11:58:19 that narrows the search a bit Dec 18 12:37:09 and problem duped here, sip.h goes into sysroot in do_install Dec 18 13:55:05 what populates sstate? Dec 18 13:57:50 Crofton|work: sstate.bbclass :) it just creates tarballs from directories like sysroot-destdir for do_populate_sysroot task which is defined in staging.bbclass Dec 18 13:58:04 and applies some replacement maging on top of it Dec 18 14:10:52 hi gyus. how can i add lua static library to toolchain ? Dec 18 14:11:13 adding "lua" to TOOLCHAIN_TASK doesn't add the static library to toolchain rootfs Dec 18 16:16:14 Why would the python files get staged, but not the sip.h file Dec 18 16:16:29 this is what I see in the work sysrot space Dec 18 16:26:34 Crofton|work: where is it installing it? Dec 18 16:27:00 Crofton|work: (I mean during do_install) Dec 18 16:29:33 huntiung now Dec 18 16:29:52 it is interesting because it gets into the sysroot, but not the image dir Dec 18 16:29:56 and not the ipks Dec 18 16:34:52 ah Dec 18 16:34:54 I get it Dec 18 16:35:23 I tols it to put it in the sysroot :) Dec 18 16:35:29 ok, need to re-think Dec 18 16:35:29 yes, don't do that ;) Dec 18 16:35:35 install it in do_install Dec 18 16:35:41 under ${D} Dec 18 16:37:20 a pox on people that make their own build systems Dec 18 16:42:17 "it can't be that hard, right?" ... Dec 18 17:19:14 hmm, how do I get Python.h into the sysroot, after wiping tmp? Dec 18 17:19:40 by building python? Dec 18 17:20:01 which will unpack populate-sysroot archive from sstate-cache Dec 18 17:20:18 inheriting python-dir doesn't do that? Dec 18 17:20:49 nope Dec 18 17:20:55 ned pythong as a depned I guess Dec 18 17:22:14 gar Dec 18 17:22:19 my typing is going downhill Dec 18 17:29:13 RP, sighting at about 50 seconds. Behind the BMW https://www.youtube.com/watch?v=11VGDAOVEag Dec 18 17:45:25 JaMa, I'll resend the set Dec 18 17:45:34 also found a missing python DEPENDS Dec 18 17:45:59 cool, thanks Dec 18 18:25:12 rofl Dec 18 18:25:27 gnuradio guy using the layer index as a way to collect stuff :) Dec 18 18:31:42 Crofton|work: did you forgot to send the patches? I've seen the reply but not the patches Dec 18 18:34:27 not yet Dec 18 18:34:31 in a telecon Dec 18 18:34:44 ah ok Dec 18 18:37:35 I'll do this next Dec 18 18:41:01 ok, hopefully I didn't mess it up doing it quickly Dec 18 19:12:54 Crofton|work: this looks weird (but maybe it's what you wanted python-native for sip-native) Dec 18 19:12:57 DEPENDS_class-target = "qt4-x11-free" Dec 18 19:13:00 Dec 18 19:13:02 +DEPENDS = "python" Dec 18 19:13:37 So pythonnatove inherit get python for that case Dec 18 19:13:45 you are tight, I wasn't looking closely Dec 18 19:14:00 gar Dec 18 19:14:11 sip.h includes Python.h Dec 18 19:14:32 and the python wasn't explicit Dec 18 19:15:39 it's weird because it's ignored for target recipe (because of the override above it) Dec 18 19:15:50 yeah Dec 18 19:16:31 I suspect I also fixed the issue by adding python to the pyqt depends Dec 18 19:16:40 which should stage the Python.h file Dec 18 19:17:07 but you are correct, I should force it staged by sip for he target Dec 18 19:17:27 do you want v4? Dec 18 19:18:19 I want to move python into the earlier line Dec 18 19:18:26 native is OK from the inherit Dec 18 19:21:36 you mean to add python in DEPENDS_class-target? Dec 18 19:21:38 I can do that Dec 18 19:26:31 ok Dec 18 19:26:39 sorry, I was hacking around Dec 18 22:08:53 What's wrong with this line: SRC_URI = "https://github.com/cisco/openh264.git;protocol=git" ??? Dec 18 22:43:09 yo denix Dec 18 22:59:05 awozniak: use git://github.com/cisco/openh264.git;protocol=https Dec 18 22:59:30 does it not give you a warning suggesting that? I thought I added one... Dec 18 23:00:09 bluelightning: maintaining an old oe-classic system. Dec 18 23:00:28 ah right, I see Dec 18 23:00:32 nerdboy: what's up? Dec 18 23:00:37 it gives me a "fetch failed" Dec 18 23:01:02 it would yes, I didn't add the warning until well into the OE-Core times Dec 18 23:01:15 even your suggested url gives me a fetch failed Dec 18 23:01:27 bumped beaglebone to build 3.17-yocto Dec 18 23:01:47 awozniak: hmm, OE-Classic - try proto= rather that protocol= Dec 18 23:02:13 boots cleaner than 3.14 but needs a uEnv.txt to make it find root, etc Dec 18 23:02:34 no blinky LEDs tho... ;/ Dec 18 23:06:34 Linux beaglebone 3.17.1-yocto-standard #1 PREEMPT Thu Dec 18 02:20:17 armv7l GNU/Linux Dec 18 23:07:44 black rev a6a Dec 18 23:08:28 just poky stuff Dec 18 23:15:42 bluelightning: looking through existing recipes, I see "protocol", although the only values I see are "git" and "http", no "https" Dec 18 23:17:49 bluelightning: still errors with http: task Fetch failed: Unable to fetch URL git://github.com/cisco/openh264.git;protocol=http from any source. Dec 18 23:19:44 denix: plan on bumping beaglebone kernel any time soon? Dec 18 23:20:52 nerdboy: that's controlled by linux-yocto version Dec 18 23:21:32 awozniak: I have no idea why because I just cloned that exact URL successfully here Dec 18 23:21:40 it doesn't like 3.17 without forcing compatible_machine to beaglebone Dec 18 23:21:46 nerdboy: ping zeddii on #yocto Dec 18 23:22:17 bluelightning: ok thx Dec 18 23:22:17 didn't bump .bbappend either (which i think there is one, right?) Dec 18 23:22:23 nerdboy: as of uEnv - is it related to zImage vs. uImage? Dec 18 23:22:34 not sure Dec 18 23:22:59 all i got without it was Starting kernel ... Dec 18 23:23:05 then nothing Dec 18 23:24:28 adding my old beaglebone boot.scr made it not find the dtb file (it was looking for /boot/foo.dtb) so i made a uEnv and hardcoded everything i wanted Dec 18 23:24:59 bluelightning: think I found the problem, I was missing SRCREV Dec 18 23:25:21 I assumed it would use HEAD if I didn't specify Dec 18 23:25:59 awozniak: right... one more reason to move off OE-Classic - somewhat less useful error reporting Dec 18 23:26:09 http://paste2.org/aJLfz4Zm Dec 18 23:26:25 you're preaching to the choir; my corporate overlords are very risk averse. Dec 18 23:26:49 awozniak: the risk is not moving sooner... Dec 18 23:27:05 same thing at my old work and they're still stuck Dec 18 23:27:19 new projects are on oe-core, but nothing in maintenance mode is moving forward. Dec 18 23:27:27 bandaids taking away all the time... Dec 18 23:27:32 awozniak: I've been through that in previous jobs... it just gets more and more expensive as time goes on Dec 18 23:27:43 awozniak: but then, if the customer's paying... :) Dec 18 23:27:57 not in this case... Dec 18 23:27:58 there's food on my table. *shrug* Dec 18 23:29:15 * nerdboy is done with taking direction from wanker managers Dec 18 23:37:01 denix: it still builds uImage for beaglebone (not zImage) Dec 18 23:49:49 nerdboy: I know, but new u-boot expects zImage by default - there are few changes pending... **** ENDING LOGGING AT Fri Dec 19 02:59:59 2014