**** BEGIN LOGGING AT Thu Oct 06 02:59:56 2011 Oct 06 12:53:54 msm: "runqemu qemuppc" would probably be a good start Oct 06 12:54:04 * RP__ suspects the quickstart should mention this Oct 06 13:31:18 ERROR: Please set the 'PERSISTENT_DIR' or 'CACHE' variable Oct 06 13:31:26 anyone encounter this issue Oct 06 13:31:35 wat could be wrong with this error Oct 06 13:31:40 please help Oct 06 13:38:47 loo, your setup is wrong Oct 06 13:43:37 yeah ... i suspect that already Oct 06 13:43:41 but i got no clue how to solve Oct 06 13:43:48 can u direct me Oct 06 13:43:55 cause i'm very very new to this Oct 06 13:44:00 but wish to learn Oct 06 13:44:20 i actually followed the steps in http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html Oct 06 13:44:50 can u guide me... i've wandering round and round in this without help Oct 06 13:50:24 u still here? Oct 06 13:50:33 GNUtoo|laptop: u still here? Oct 06 13:51:33 yes Oct 06 13:51:35 I was busy Oct 06 13:51:48 I've no fancy kde4 with split screen Oct 06 13:51:56 so I only see a message when you enlighten me Oct 06 13:52:42 we don't have enough details.... Oct 06 13:52:57 and we are not in front of your computer Oct 06 13:53:16 so it's an error in the setup Oct 06 13:53:22 for instance if you use angstrom Oct 06 13:53:33 you should be in the correct dir for bitbaking Oct 06 13:53:34 check that Oct 06 13:54:42 and I don't know the poky method Oct 06 13:55:20 tar xjf poky-bernard-5.0.1.tar.bz2 and source poky-bernard-5.0.1/poky-init-build-env poky-5.0.1-build should be easy enough Oct 06 13:55:35 angstrom is what i should use instead of poky? Oct 06 14:09:54 loo, what do you want to do exactly? Oct 06 14:10:28 to build a poky-image-sato Oct 06 14:10:48 i encounter the please set the persistent_dir ...error Oct 06 14:11:16 i downloaded the poky-bernard-5.0.1.tar... Oct 06 14:11:17 untar Oct 06 14:11:47 source directly from the env which is available from the .tar file downloaded Oct 06 14:11:59 then bitbake poky-image-sato Oct 06 14:12:07 that's how the error came up Oct 06 14:12:14 by source you mean source command or "." command, right? Oct 06 14:12:40 yeah source .env build Oct 06 14:12:51 the command in the steps given Oct 06 14:13:14 then after source command we will then be in the build directory right Oct 06 14:13:37 and what does "which bitbake" say? Oct 06 14:13:55 u mean after running bitbake poky-image-sato Oct 06 14:13:56 ? Oct 06 14:14:14 no after runing source poky-bernard-5.0.1/poky-init-build-env Oct 06 14:14:35 then it says run bitbake Oct 06 14:15:20 '/usr/bin/which bitbake' says that? Oct 06 14:16:18 says /usr/bin/which bitbake Oct 06 14:17:29 do u think actually i should download the openembedded ... whatever files from there first before following the yocto project steps? Oct 06 14:17:44 hmm, do you know what which command does? Oct 06 14:17:59 not really sure Oct 06 14:18:21 then execute what I wrote in ' Oct 06 14:18:25 ok Oct 06 14:20:53 JaMa: are you writing anything yet? Oct 06 14:22:27 16:10:49 < JaMa> and what does "which bitbake" say? Oct 06 14:23:29 Hello, where should I send patches to update recipes? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta Oct 06 14:24:04 it says Oct 06 14:24:21 where is the .bb format described? Oct 06 14:24:34 it says /usr/bin/bitbake Oct 06 14:25:52 ok, found https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide Oct 06 14:27:43 loo: in shell where you called "source poky-bernard-5.0.1/poky-init-build-env poky-5.0.1-build"? Oct 06 14:28:17 mmm, no gnome component here: http://bugzilla.yoctoproject.org/describecomponents.cgi?product=Meta%20Recipes Oct 06 14:28:26 loo: it should be path to scripts directory IMHO (but I'm not using poky) Oct 06 14:29:29 JaMa Oct 06 14:29:36 slowly yeah Oct 06 14:29:59 about where i source the .env Oct 06 14:30:31 i actually mkdir a yocto after / Oct 06 14:31:13 then the poky-bernard.5.0.1.tar is actually put in /yocto Oct 06 14:31:28 then i untar it there as well Oct 06 14:31:38 jjardon, what are you up to here? =) Oct 06 14:31:39 then source under /yocto Oct 06 14:32:41 walters: :) just reading your presentation in DesktopSummit and curious about Yocto ;) Oct 06 14:33:01 jjardon, cool Oct 06 14:33:46 JaMa|Off: what is IMHO yeah Oct 06 14:34:08 walters: It would be cool if we can have a chat in Montreal Oct 06 14:35:54 jjardon, yep, i just added it to the agenda Oct 06 14:37:46 jjardon and walters: do u guys have any idea wat 's the prob that i encountered Oct 06 14:37:53 and hwo should i solve it? Oct 06 14:39:20 loo: sorry, completely new to yocto Oct 06 14:39:35 i c Oct 06 14:39:43 me too Oct 06 14:39:49 that's y having such prob Oct 06 14:40:13 the steps so brief... and yet leads me to prob Oct 06 14:46:12 walters: cool, do you know what is the status of the gnome recipes in yocto? the directory seems to miss lot of things Oct 06 14:46:42 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-gnome Oct 06 14:48:48 jjardon, i only looked at them briefly, but note the big blocker bug for actually using OE proper is https://bugzilla.gnome.org/show_bug.cgi?id=592311 Oct 06 14:49:14 jjardon, as far as this cycle though i am thinking about getting jhbuild to read a subset of the .bb file syntax instead of the XML Oct 06 14:49:47 jjardon, the Poky guys actually have a hackish script somewhere to go the other way (moduleset XML to .bb) Oct 06 17:57:33 if I have a recipe with a do_deploy step, that's failing when running from sstate-cache.... Oct 06 17:58:36 im assuming some files did not get packaged in the sstate-cache Oct 06 18:06:20 msm, yeah, sstate-cache can complicate this a bit. Take a look at the openjade recipe for an example of manipulating files that cannot be handled during do_install Oct 06 18:07:16 zenlinux_laptop: k Oct 06 18:09:25 SSTATEPOSTINSTFUNCS is what you'll want to point to a function that performs your do_deploy steps Oct 06 18:20:20 zenlinux_laptop: seems like my files I need to deploy are not included in sstate cache though Oct 06 18:20:38 seems like I need to add these files to a package? Oct 06 18:20:46 then use sstate_postinst? Oct 06 18:21:11 in this case im deplying stuff in tmp/deploy/images/ Oct 06 18:21:33 msm, oh, forget what I said then Oct 06 18:21:56 This is a problem we've had when rebuilding the kernel, I think Oct 06 18:22:09 the do_deploy step would have to be run seprately to copy the kernel into tmp/deploy/images Oct 06 18:22:24 right, my do_deply step is getting run Oct 06 18:22:29 its just not finding the files =) Oct 06 18:22:36 how do I say, hey package these files in sstate-cache Oct 06 18:22:56 msm: inherit deploy Oct 06 18:23:28 ahh, does that also take care of addtask Oct 06 18:23:31 …. let me look Oct 06 18:23:47 adds the task and sets up the sstate for the task, iirc Oct 06 18:25:10 thanks Oct 06 18:30:14 fray: ping Oct 06 19:14:57 has anyone done any work or given any thought to make proxy's w/ authentication work w/o requiring any host tools? Oct 06 19:15:19 like just setting proxy server, port, username, password in some site.config and going from there? Oct 06 19:44:39 msm, if you can get that to work, we'd be quite excited to try to use it Oct 06 19:45:08 I wrote a blog post about the challenges proxies pose us here: http://www.yoctoproject.org/blogs/sgarman/2011/proxy-problem Oct 06 19:47:46 zenlinux_laptop: our work proxy has been the bane of my existance Oct 06 19:48:37 yeah, they're no fun Oct 06 19:49:22 i think we could include a default GIT_PROXY_COMMAND script and use http_proxy env vars to configure that thing up Oct 06 19:49:35 and GIT_PROXY_IGNORE=$no_proxy Oct 06 19:49:37 etc Oct 06 19:50:47 looks like there is already something Oct 06 19:51:11 oe-git-proxy-socks-command Oct 06 19:56:34 hehe, I read that as "oe-git-proxy-sucks-command" Oct 06 19:56:42 guess my opinion of proxies is showing Oct 06 19:56:51 heh Oct 06 21:07:56 msm: I did have that working at some point... Oct 06 21:11:18 msm: native sscache? Oct 06 21:11:22 w/ multilib Oct 06 21:11:48 RP__: i was saying it's working again w/ your one liner Oct 06 21:25:46 I'm writing a recipe for some software that builds up quite a long CFLAGS variable, but when I use oe_runmake, it clobbers the settings in the project's Makefiles. Is there a canonical way to deal with that? Oct 06 21:27:45 zenlinux_laptop: CFLAGS[unexport] = "1" Oct 06 21:28:04 RP__, thanks! Oct 06 21:29:12 zenlinux_laptop: Please do make sure it adds our CFLAGS somehow too though Oct 06 21:29:41 right, since it needs to point to our sysroot and the like Oct 06 21:31:53 RP__, is that the same thing as making sure the Makefile uses := instead of = ? Oct 06 21:37:56 dvhart: no, we use make -e and override from the environment Oct 06 21:38:07 Its deliberate as there are too many broken makefiles out there Oct 06 21:38:11 is there something that prevents an sstate-cache from being built? Oct 06 21:38:25 hrm, gnuefi uses CC = "..." Oct 06 21:38:32 I patched it to use := Oct 06 21:38:37 should I be doing something different? Oct 06 21:38:39 sstate-mkfontdir-native is not built, however bitbake attempts to look for what it during the build however Oct 06 21:38:47 dvhart: we should override it Oct 06 21:39:20 RP__, I do override it - but I do it by using the := patch and passing CC= in the OE_EXTRA_ or whatever Oct 06 21:39:40 dvhart: I'm just surprised you needed to Oct 06 21:40:12 seems it was using /usr/bin/gcc otherwise Oct 06 21:41:19 dvhart: I'm going from memory, I could be wrong or there may have ben something different you were doing Oct 06 21:42:20 or maybe its not really being built, but its still checking for presence Oct 06 21:45:39 hrm.... I am seeing something weird. I should be able to add files (patches,cfg,etc) using SRC_URI_append ="for_all_bsps.patch" and then with SRC_URI_append_qemux86 = "qemux86_only.patch" right? Oct 06 21:48:35 dvhart: yes Oct 06 21:48:41 hrm.... Oct 06 21:48:48 seems this was working before too Oct 06 21:49:00 now only the qemux86 cfgs are showing up.... hrm Oct 06 21:49:12 oh hang on Oct 06 21:49:29 do you want that for_all_bsps.patch should not apply for qemux86 Oct 06 21:50:50 just use SRC_URI += "for_all_bsps.patch" Oct 06 21:52:06 yeah, I want them to be additive Oct 06 21:52:38 and I am using SRC_URI += now, thought I had the same issue Oct 06 21:52:45 will retry clean and see Oct 06 21:52:48 ok then after above do SRC_URI_append_qemux86 = " qemux86_only.patch" Oct 06 21:54:14 OK, so this *should* work then: Oct 06 21:54:15 http://pastebin.com/nHJ0Gzrx Oct 06 21:58:02 huh, it doesn't, only the qemux86 options get pulled in Oct 06 22:08:08 dvhart: the whole SRC_URI is overwritten ? Oct 06 22:10:33 nope, the original recipe SRC_URI is there and the qemu patch is there Oct 06 22:10:34 but the _append files don't appear Oct 06 22:10:38 * dvhart checks for spelling errors again Oct 06 22:15:48 what if you do SRC_URI_append_qemux86 += " qemux86_only.patch" Oct 06 22:18:49 nope, same Oct 06 22:19:02 something is whacky here Oct 06 22:20:48 all you want is that if its x86 then add one more patch Oct 06 22:20:49 right ? Oct 06 22:21:07 Do this Oct 06 22:22:15 QEMUX86ONLY = "" QEMUX86ONLY_qemux86 = "the patch" and then SRC_URI += "${QEMUX86ONLY}' Oct 06 22:22:28 that name can be better Oct 06 22:23:56 heh Oct 06 22:24:20 I am doing this for several BSPs in the end Oct 06 22:24:26 so I'd like to discover what I'm doing wrong Oct 06 22:24:35 I'll keep digging Oct 06 22:24:37 thanks though Oct 06 22:25:14 sanity check, use bitbake -e to verify your OVERRIDES contains what you think it does :) Oct 06 22:25:16 I think append evaluate at very end Oct 06 22:25:45 kergoth: problem is that override is there but it overrides SRCURI += Oct 06 22:25:49 which I dont get Oct 06 22:28:11 is there already an override version of SRC_URI in use? Oct 06 22:28:29 i'd advise double checking the original recipe Oct 06 22:29:20 actually, this is a self contained recipe Oct 06 22:29:31 was thinking it was a bbappend, but it is not Oct 06 22:30:46 we don't have enough context to say what's going wrong. there's nothing inherently wrong with what's in the pastebin, so it must be something else :) Oct 06 22:35:20 ok, the problem isn't that _append_qemux86 overrides +=, but rather than += never gets applied at all (even if the append_qemux86 is removed) **** ENDING LOGGING AT Fri Oct 07 02:59:58 2011