**** BEGIN LOGGING AT Tue Mar 13 02:59:58 2012 Mar 13 03:12:18 * nerdboy tries backporting an oe-core recipe to arago old-style... Mar 13 06:25:31 wow, that actually worked... Mar 13 08:43:12 hiho Mar 13 08:43:30 good morning Mar 13 08:43:30 was there an SRC_URI option for only downloading but not unpacking? Mar 13 08:43:34 hi mckoan ;) Mar 13 08:43:49 hi woglinde ;-) Mar 13 08:49:06 unpack=false? Mar 13 09:25:41 mornin Mar 13 09:29:18 is it possible to filter out something from an inherit line using bbappend? for instance removing "systemd" from inherit in a recipe? **** BEGIN LOGGING AT Tue Mar 13 09:48:19 2012 Mar 13 09:58:29 Hello .... I m getting this error ..... vga.c:34:22: fatal error: sys/vm86.h: No such file or directory Mar 13 09:58:44 while using "bitbake svgalib" Mar 13 09:58:57 how to compile svgalib in OE Mar 13 10:08:49 snkt: check if that file is in the correct path. maybe is in another place. Mar 13 10:09:21 I think is not a bitbake's problem Mar 13 10:14:46 Spider-Pork, in which path it is looking for? Mar 13 10:15:04 check inside makefile in svgalib's src Mar 13 10:16:23 vga.c:34:22: fatal error: sys/vm86.h: No such file or directory --> gcc found an include and maybe can't find sys/vm86.h Mar 13 10:17:09 i expect to find at vga.c line 34 something like this: "#include "sys/vm86.h"" Mar 13 10:33:27 Spider-Pork, no it is like this ... #include Mar 13 10:33:35 still I m getting this error Mar 13 10:33:59 still it can't find that path Mar 13 10:34:03 is in src? Mar 13 10:34:36 look inside makefile. I'm newbie about these kind of problems Mar 13 10:34:37 Spider-Pork, in which src? that means in toolchain or the system src? Mar 13 10:34:55 no no inside svgalib src Mar 13 10:35:16 the sources of svgalib Mar 13 10:37:04 but i repeat that: i'm really a newbie :) Mar 13 10:37:06 there is no vm86.h file Mar 13 10:38:15 i think is glibc header Mar 13 10:38:16 Spider-Pork, it's OK Mar 13 10:42:30 snkt: are you crosscompiling? Mar 13 10:42:40 if yes, for what kind of target? Mar 13 10:43:18 Spider-Pork, I m using it for ARM mini2440 Mar 13 10:45:50 svgalib lol Mar 13 10:45:54 thats stoneage Mar 13 10:49:17 woglinde, I want to run a light weighted apps which require this dependencies..... will you plz help me Mar 13 11:15:23 hi ant_work Mar 13 11:15:29 morning all Mar 13 11:17:13 good morning Mar 13 11:27:06 hi pb hi ant Mar 13 11:27:30 snkt what lightway should that be? Mar 13 11:27:40 better make something usefull with directfb Mar 13 11:40:35 gm Mar 13 11:52:39 in test/fetch-test.c, why does testcases[] not contain a wide range of formats such as a1b5g5r5? Mar 13 11:52:53 sorry, wrong channel. Mar 13 12:05:48 has anyone here used AWS to do OE builds? Mar 13 12:16:02 Crofton|work: some other ppl did: http://gumstix.8.n6.nabble.com/Virtual-machines-for-Gumstix-OpenEmbedded-build-environment-td575679.html Mar 13 12:17:48 I'm trying to figure out how much it costs, and how much to keep the data around with the instance turned off Mar 13 12:19:55 likewise hello Mar 13 12:20:28 maybe find out / ping this user: http://www.openembedded.org/wiki/EC2CloudBuild Mar 13 12:20:39 erwt: hi Mar 13 12:21:19 erwt: where are you from? in Dutch, erwt means pea :) Mar 13 12:32:54 hello was anyone struggling with svgalib Mar 13 12:36:20 hm.. Mar 13 12:36:44 are build farm accounts actually frequently requested? Mar 13 12:37:03 if people are ready to pay something I can setup one :) Mar 13 12:41:57 Jay7: well, but will you compete against AWS on large scale? :) Mar 13 12:42:26 likewise: build service is very special ;) Mar 13 12:42:59 I would like to know if I can clone a AWS instance to/from someone else. I.e. I prepare a machine with a completed build and then throw it to another user. Mar 13 13:12:46 Is there any documentation that describes how exactly sstate is meant to work, by any chance? Mar 13 13:20:12 pb_: sstate.bbclass was a bit documented in Yocto 3.2.3 but there have been recent reworks Mar 13 13:20:26 http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html Mar 13 13:20:51 pb_: specifically: http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#shared-state-cache Mar 13 13:22:05 hi bluelightning Mar 13 13:32:58 Hello everyone, I am currently working on a omap l137 board which will use the DSP as a coprocessor Mar 13 13:33:41 it seems the latest recipe in OE for C6Run is ti-c6run_0.94.04.05.bb, wherease the latest version from TI is 0.98 Mar 13 13:34:08 is there anothere place where this kind of recipe are maintained? Mar 13 13:37:12 hi ant_work Mar 13 13:40:42 is there a way to list all packages in an image? Mar 13 13:52:07 jonasdn: OE-Classic or OE-Core? Mar 13 13:52:17 OE-core Mar 13 13:52:43 jonasdn: enable buildhistory (but without BUILDHISTORY_COMMIT): https://wiki.yoctoproject.org/wiki/Buildhistory Mar 13 13:52:54 thx Mar 13 13:52:57 this will produce not only package lists but also depgraphs Mar 13 13:53:04 great! Mar 13 13:53:34 bluelightning: thanks, I'll have a look Mar 13 13:53:48 np Mar 13 14:45:28 so, that sstate documentation helps a bit, though it doesn't quite go into the detail that I was hoping for. Mar 13 14:46:27 I guess the issue I have right now is that I can't quite see where/how the _setscene tasks get spliced into the dependency graph. for example, staging.bbclass does "addtask do_populate_sysroot_setscene", but nothing obviously mentions that task as being a dependency. Mar 13 14:55:33 pb_: setscene tasks get processed first in a separate runqueue Mar 13 14:55:54 oh, right, so there is some hard-wired knowledge in bitbake about them? Mar 13 14:56:03 how does it identify them, just by ending in "setscene"? Mar 13 14:56:49 yes and yes, I think so Mar 13 14:57:02 aha, right Mar 13 14:57:09 in that case I guess I should try getting a newer bitbake :-} Mar 13 14:57:30 which version were you trying with? Mar 13 14:57:41 somewhere around 1.14.0, I think Mar 13 14:58:08 AFAIK that had sstate support in it... Mar 13 14:58:16 yeah, it does, it just doesn't seem to work correctly Mar 13 14:58:27 for latest oe-core you definitely need 1.15.x though Mar 13 14:58:49 I had assumed it was a problem in the oe-core metadata somewhere, but if bitbake itself is meant to understand the setscene bits then maybe my problem is in there. Mar 13 14:59:11 unfortunately I'm not using the latest oe-core, and in particular I don't have all the quoting fixes that 1.15.x now seems to insist on. Mar 13 14:59:47 I don't really want to update oe-core at the moment, because it is always a nightmare merge and we are meant to be shipping on Friday. :-} Mar 13 15:01:15 pb_: master requires the quoting fixes, 1.15.1 does not Mar 13 15:01:38 ah, fair enough :) Mar 13 15:02:16 oh, right. what branch to I check out for 1.15.1? there doesn't seem to be a 1.15 branch in git. Mar 13 15:02:26 afaict, the choice is between 1.14, master, "master-poky", or "next" Mar 13 15:02:40 ah, I see, there is a 1.15.1 tag Mar 13 15:05:55 yes, the tag was what I was thinking of Mar 13 15:07:46 okay, I'll give that a go Mar 13 16:11:12 well, bitbake 1.15.1 does seem to work with my content, so that's a good start. Mar 13 16:11:28 now to try to figure out whether it solves my original problem... :-} Mar 13 18:06:57 pls don't shoot me for submitting the same patch 10 times ;) @tom rini: is it correct now? Mar 13 18:17:26 yay, i made a custom console-image without an actual kernel image in /boot Mar 13 18:19:37 RDEPENDS_kernel-base = "" Mar 13 18:26:40 obi Mar 13 18:26:49 any one seen obi ? Mar 13 18:30:01 denix, when i checked another image, it had kernel-image in the IMAGE_INSTALL list Mar 13 18:30:27 is the RDEPENDS the more "proper" way to do it? Mar 13 19:10:14 khem: ping Mar 13 19:11:00 i have this: https://gist.github.com/2030847 Mar 13 19:11:08 its not using sysroot to search for /usr/include/c++ Mar 13 19:11:27 i've tweaked my gcc patches Mar 13 19:11:32 maybe i missed one that yocto added to fix this Mar 13 19:12:25 there is a configuration setting for the cxx (or c++?) path.. Mar 13 19:12:33 if that isn't set, I believe it defaults back to /usr/include.. Mar 13 19:13:03 fray: wouldnt —sysroot to g++ override this? Mar 13 19:13:26 sysroot will override it for some things, but you need to the path known for the sysroot to override.. (or at least you used to) Mar 13 19:13:50 gcc (used to) check the local ones before the sysroot ones.. and local in this case would be the /usr/include/g++ Mar 13 19:14:08 it's been a few years since I played with this stuff directly, so I'm really not sure if what I'm saying is still correct though Mar 13 19:14:24 but I know the OE toolchains do set the C++ include path.. Mar 13 19:14:38 (I was just looking at that code) ;) Mar 13 19:15:56 fray: where do they set it? Mar 13 19:16:22 in the recipe Mar 13 19:16:36 fray: can you give an example one? =) Mar 13 19:16:46 --with-gxx-include-dir=${STAGING_DIR_TARGET}${target_includedir}/c++ Mar 13 19:16:54 gcc-configure-cross.inc Mar 13 19:17:32 ok - let me look at this Mar 13 19:17:43 we don't have this arg for sure, we must have killed it somewhere Mar 13 19:22:01 there is an argument, something like local-prefix that appears to be incorrect though.. Mar 13 19:22:08 I'm currently testing this for khem... Mar 13 19:30:52 hmmm Mar 13 19:31:06 fray: not sure what you might mean ;) Mar 13 19:32:29 the argument list in configure-cross.inc there is an argument that says something like --with-local-prefix=... thats wrong.. Mar 13 19:33:15 k - i'll see what mine says too for kicks - rebuilding gcc atm Mar 13 19:38:27 fray: my local-prefix is correct Mar 13 19:38:35 with-local-prefix=/local/home/mattsm/git/poky/build_p4080ds_release/tmp/sysroots/p4080ds/usr Mar 13 19:38:47 however, the first one we talked about is wrong Mar 13 19:38:47 with-gxx-include-dir=/usr/include/c++ Mar 13 19:38:54 the problem is that when you set with-local-prefix, it appears the toolchain is no longer relocatable.. Mar 13 19:39:11 that is the theory.. I should know soon if it's true... Mar 13 19:40:21 that does not seem likely Mar 13 19:40:32 since i do this often… i think Mar 13 19:40:38 when reusing sstate-cache Mar 13 19:40:53 the problem is that the original directory either needs to be readable, or it needs to not exist.. Mar 13 19:41:02 if you make it unreadable.. then you will get a failure.. Mar 13 19:41:16 see bugzilla 2074 Mar 13 19:41:51 the way khem explained it to me, the local-prefix option is old, and designed for systems where you won't be using a sysroot.. it's a hardcoded path that gcc looks into first.. Mar 13 19:42:01 then falls back to the sysroot..t hats not the behavior we want with the sstate-cache.. Mar 13 19:42:10 since the builder of the sstate-cache may have unreadable directories Mar 13 19:43:22 fray: ok i might not be doing this then Mar 13 19:43:46 follow the steps in 2082 -- that should show if you have the problem with your toolchain or not Mar 13 19:44:21 with edison, I couldn't even get far enough to try the toolchain though.. things like tar started to blow up on me.. Mar 13 19:44:28 with master though the toolchain is what fails.. Mar 13 19:45:59 hmm ok Mar 13 19:46:04 seems i need c7c70a3ea200fba23324d825046aee283c6747b1 in edison too Mar 13 19:46:14 which is fixing the problem im having Mar 13 19:46:27 (err rather i *think* it's a fix for the same issue) Mar 13 19:46:33 I was never able ot figure out (lack of time) why tar was failing for me in edison.. Mar 13 19:46:45 but the trick to cause the failure is to ensure the original user you built under was unreadable.. but existed.. Mar 13 19:47:13 if the directory was removed, the build succeeded most of the time because the components tried the directory and then fell back to the sysroot or some other mechanism automatically.. Mar 13 19:47:23 but if it existed and wasn't readable.. a completley different error path was hit Mar 13 19:47:30 (speculation based on behavior) Mar 13 19:47:53 oh - this is the issue where you can't use another users build Mar 13 19:47:57 intresting Mar 13 20:38:32 why does angstrom's directory structure vary so much from the openembedded one? Mar 13 20:38:42 I'm still a bit confused as to the relationship between them Mar 13 21:05:45 so what's the poper way to build a meta-toolchain package? Mar 13 21:06:59 i eother get "no provider" or an error if i try "bitbake -p path/to/meta-toolchain.bb -c build" Mar 13 21:07:10 *either Mar 13 21:07:18 what am i missing? Mar 13 21:29:03 okay, figured it out Mar 13 21:29:19 it didn't like on of my dep names **** BEGIN LOGGING AT Tue Mar 13 22:04:38 2012 Mar 13 22:11:06 so for the meta-toolchain RDEPENDS_${PN} += "foo" Mar 13 22:11:24 isn't "foo" the actual .ipk package name? Mar 13 22:31:15 mr_science: DEPENDS is a build time dependency and requires recipe name, RDEPENDS is a run-time dependency and requires package name, i.e. *.ipk Mar 13 23:09:40 gm Mar 13 23:12:54 hi likewise Mar 13 23:29:11 hi florian Mar 13 23:29:58 my SRC_URI is obviously wrong: fatal: Unable to look up bitbucket.org (port likewise) (Servname not supported for ai_socktype) Mar 13 23:30:00 LOL Mar 13 23:34:33 hey likewise :) Mar 13 23:35:04 hey Jin^eLD Mar 13 23:57:14 what's the SRC_URI for accessing a private GIT repo? git://host/repo.git;protocol=ssh;user=myname Mar 13 23:58:27 a wait ":" missing somewhere. Mar 13 23:58:30 a=ah **** BEGIN LOGGING AT Wed Mar 14 00:54:05 2012 **** ENDING LOGGING AT Wed Mar 14 02:59:58 2012