**** BEGIN LOGGING AT Wed May 12 02:59:56 2010 May 12 05:17:50 03Khem Raj  07org.openembedded.dev * rf040929a07 10openembedded.git/recipes/gcc/ (3 files): May 12 05:17:50 gcc-configure: Disable --enable-target-optspace for powerpc. May 12 05:17:50 * Use OPTSPACE to get the value in gcc-cross-initial and May 12 05:17:50 gcc-cross-intermediate inc files. May 12 05:17:50 Signed-off-by: Khem Raj May 12 05:17:56 03Khem Raj  07org.openembedded.dev * ra1b685073f 10openembedded.git/recipes/eglibc/ (eglibc_2.11.bb eglibc_svn.bb): May 12 05:17:56 eglibc: Bump SRCREV for 2.11 and trunk. May 12 05:17:56 Signed-off-by: Khem Raj May 12 05:17:56 03Khem Raj  07org.openembedded.dev * rd9264a5e56 10openembedded.git/recipes/u-boot/ (3 files in 2 dirs): (log message trimmed) May 12 05:17:57 u-boot-1.3.2: Fix compilation with gcc 4.4 for mpc8313e-rdb/ppc May 12 05:17:57 * Fix the linker script to allocate all .rodata section variants May 12 05:17:58 gcc-4.4 generated rodata sections with alignment 1 as .rodata1.1 May 12 05:17:59 and linker script did not allocate it as a result it got default May 12 05:17:59 adress and create a large hole. So when it came to objcopy converting May 12 05:18:00 to srec format it kept on filling the gap with 0xff and virtually May 12 05:18:00 03Khem Raj  07org.openembedded.dev * r192f7db5aa 10openembedded.git/recipes/gcc/ (21 files in 2 dirs): May 12 05:18:01 gcc-4.4.4: Move gcc 4.4.3 recipes to gcc 4.4.4 May 12 05:18:01 * Reset INC_PR and update checksums. May 12 05:18:02 Signed-off-by: Khem Raj May 12 05:18:02 03Khem Raj  07org.openembedded.dev * r2137220f4c 10openembedded.git/recipes/uclibc/uclibc_git.bb: May 12 05:18:03 uclibc_git: Bump SRCREV. May 12 05:45:12 my poor build PC May 12 06:13:58 03Martin Jansa  07org.openembedded.dev * ra17587d013 10openembedded.git/conf/distro/shr.conf: shr: prefer gcc-4.4.4 May 12 07:10:27 hi May 12 07:13:08 hi hrw-uds, do you feel better today? May 12 07:13:14 good morning May 12 07:18:16 hey guys May 12 07:21:33 hi XorA|UDS May 12 07:23:39 mckoan: less tired - yes May 12 07:56:34 03Koen Kooi  07org.openembedded.dev * r93323eb479 10openembedded.git/recipes/images/beagleboard-linuxtag2010-demo-image.bb: beagleboard-linuxtag2010-demo-image: add all kernel modules May 12 09:35:25 hi,I have some huge issues with ts_calibrator: DEBUG: Not adding click 1 (X=0, Y=0): within 7 pixels of previous click May 12 09:35:49 is there a way to solve that or should I use ts_calibrate instead? May 12 09:45:22 mmm according to JaMa it works only for evdev May 12 10:44:34 03Ken Gilmer  07org.openembedded.dev * r18993334c3 10openembedded.git/ (2 files in 2 dirs): bug20/xorg.conf: update to use tslib driver for touchscreen input device. May 12 11:27:26 is http://cgit.openembedded.net/ down? May 12 11:27:29 ah no May 12 11:27:34 finally came up May 12 11:34:27 hi May 12 11:34:44 I wonder where I should put the ts_calibrate script startup May 12 11:40:08 Hi! I want to add dbg package to my image, added "foorecipe-dbg" to IMAGE_INSTALL and get not only my program in .debug directory, but also 9 executables (gencat, getconf, getent, iconv etc). I couldn't get why all this files were added to image, could anybody explain it? May 12 11:41:32 pastebin image and log May 12 11:48:35 And when I add only "foorecipe" to my image, without "foorecipe-dbg", of course there is no .debug directory and none of this unwanted files May 12 11:52:27 I'll make an init script for the calibration issue May 12 11:53:00 GNUtoo: there is some in xserver-common as well as xserver-kdrive-common May 12 11:53:16 I want to use xorg May 12 11:53:36 and the script must be started before xorg May 12 11:53:41 because I use ts_calibrate May 12 11:53:56 gim, look at foorecipe's recipe May 12 12:00:11 GNUtoo: foorecipe is very simple, actually it's just helloworld recipe with inherited update-rc.d, there is no files like gencat or any other from those 9 unwanted. gencat for example is from eglibc recipe, but I added only foorecipe-dbg to IMAGE_INSTALL May 12 12:24:07 By the way, if I remote debug application on ARM target and x86 host, do I need specific gdb of host, or standard will be fine? May 12 12:35:19 gim, you need to bitbake a special gdb May 12 12:35:42 I'm working on improving the gdb tuttorial on elinux.org May 12 12:35:58 but I've also some other projects May 12 12:36:03 so progress is slow May 12 12:37:11 mmm Maybe I could still use xinput-calibrator May 12 12:37:22 there was an icon named calibrate touchscreen May 12 12:37:25 I pressed it May 12 12:37:27 and it worked May 12 12:37:51 GNUtoo: did you try it from running Xorg before? May 12 12:38:05 GNUtoo: or did you try it before starting it as ts_calibrate is used? May 12 12:38:36 no only Xorg & and DISPLAY=:0.0 xinput-calibrator May 12 12:38:42 or something like that May 12 12:39:10 GNUtoo: thanks, then I'll bitbake gdb from OE May 12 12:39:31 gim, bitbake gdb-cross May 12 12:39:43 JaMa, maybe I forgott DISPLAY=:0.0 May 12 12:39:46 because it works now May 12 12:40:22 GNUtoo: so sorry for confusion about evdev only (maybe you should poke tias to remove that remark about except tslib) May 12 12:40:35 yes I'll do that May 12 12:40:44 np May 12 13:02:15 hi all May 12 13:03:04 where wil i get the omaplfb.ko and pvrsrvkm.ko(SGX) for the kernel 2.6.32 May 12 13:08:37 GNUtoo: I've bitbaked gcc-cross-sdk, then took ipk package tmp/deploy/ipk/x86_64-armv5te-sdk/gdb-cross-sdk_7.0-r0_x86_64-armv5te-sdk.ipk and unpacked it. Now when I try to execute arm-oe-linux-gnueabi-gdb and get error "bash: cannot execute" May 12 13:09:46 gim, can you debug with your build machine May 12 13:09:47 ? May 12 13:10:29 oh, sorry, I ve builded on x86_64 and runned on x86, my bad May 12 13:15:03 mmm now it doesn't work anymore May 12 13:15:08 I must find what triggers it May 12 13:30:27 gim, I bet you need a canadian sdk or something like this May 12 14:07:52 hm, tcpdump causes x11 stuff to be built May 12 14:07:54 weird May 12 14:15:17 03Thomas B. Ruecker  07org.openembedded.dev * re9f5e8f54a 10openembedded.git/recipes/mozilla/ (3 files in 2 dirs): fennec: rediff the native bpp patch and update .desktop file May 12 14:15:28 o.O May 12 14:21:45 03Klaus Kurzmann  07org.openembedded.dev * r7601318979 10openembedded.git/recipes/shr/libphone-ui-shr_git.bb: May 12 14:21:45 libphone-ui-shr: add libfsoframework to DEPENDS May 12 14:21:45 Signed-off-by: Klaus Kurzmann May 12 14:21:48 03Klaus Kurzmann  07org.openembedded.dev * r7454f1ac97 10openembedded.git/recipes/shr/libphone-ui_git.bb: May 12 14:21:48 libphone-ui: add libfso-glib and libfsofamework to DEPENDS May 12 14:21:48 Signed-off-by: Klaus Kurzmann May 12 14:32:14 arrrg,can't ts_calibrate only accept one instance at the same time May 12 14:33:11 xinput_calibrator works only if it's already calibrated May 12 14:33:30 and finally xtscal only works with kdrive May 12 14:33:40 I use tslib May 12 14:33:51 xf86-input-tslib to be exact May 12 14:38:07 "accept one instance at the same time"? May 12 14:41:00 one configuration is used by default (/etc/pointercal) even if you have more then one TS May 12 14:41:03 GNUtoo: that? May 12 14:41:26 am i right that the -native suffix means "build the package for the host system"? May 12 14:41:33 vonami|work: yes May 12 14:41:54 hm, then I found a bug in krb5's recipe May 12 14:42:03 hrw, I know but bug 1.x has multiple screens and you don't know where the user will connect his screen May 12 14:42:16 hrw-uds, ^^^ May 12 14:43:13 GNUtoo: iirc tslib can has multiple files with configuration but xf86-input-tslib probably do not know it May 12 14:43:33 I know,the issue is not the configuration file May 12 14:43:37 it's how to generate it May 12 14:43:57 generate /etc/pointercal you mean? May 12 14:44:06 yes May 12 14:44:36 ts_calibrate with TSLIB_TSDEVICE and TSLIB_FBDEVICE iirc May 12 14:44:59 TSLIB_FBDEVICE=/dev/fb1 TSLIB_TSDEVICE=/dev/input/bmi_lcd_ts4 ts_calibrate May 12 14:45:10 yes that works if you have only 1 display May 12 14:45:25 if you have second then use fb2 and bmi_lcd_ts5 May 12 14:45:30 but trying to run : May 12 14:45:34 TSLIB_FBDEVICE=/dev/fb1 TSLIB_TSDEVICE=/dev/input/bmi_lcd_ts4 ts_calibrate May 12 14:45:36 and: May 12 14:45:42 but yes - you will get one /etc/pointercal that way May 12 14:45:42 TSLIB_FBDEVICE=/dev/fb2 TSLIB_TSDEVICE=/dev/input/bmi_lcd_ts5 ts_calibrate May 12 14:45:46 at the same time May 12 14:46:08 didn't make the second one appear on the second screen May 12 14:46:12 yes I know May 12 14:46:18 basically the use case is: May 12 14:46:25 user put display in slot 0 May 12 14:46:36 he sees ts_calibrate May 12 14:46:42 if he puts in it slot 1 May 12 14:46:45 he see nothing May 12 14:46:49 and wonder what's happening May 12 14:46:50 I know May 12 14:46:57 that is my problem May 12 14:47:27 they fixed this with bug20 - there is only one screen May 12 14:47:30 either need to not use tslib at all, hack around it, or start on a tslib 2.0 or something that can handle multiple touchscreens, multiple displays with multiple resolutions, and multitouch ideally May 12 14:47:31 heh May 12 14:47:40 I know but I've still bug 1.x for now May 12 14:47:48 GNUtoo: so do I May 12 14:47:59 ok May 12 14:48:20 I'll try something May 12 14:51:59 ioctl(4, VIDIOC_S_COMP or VT_WAITACTIVE May 12 14:52:55 wow May 12 14:52:57 it works now May 12 14:53:31 TSLIB_CONSOLEDEVICE=none May 12 14:53:37 thanks a lot hrw-uds May 12 15:48:04 Hi, I'm trying to build the kernel for the dm6446-evm machine and I'm getting a linker error: arm-none-linux-gnueabi-ld: no machine record defined and I subsequently get "undefined references to '__gnu_mcount_nc' has anyone seen this before? I've googled it but haven't come up with any solutions May 12 15:51:54 slaz: no machine record defined means the machine is not registered in the arm machine registry (or that the name used in MACHINE_START of your board file is not the same as in arch/arm/tools/mach-types May 12 15:55:47 Thanks ericben, I'll look into that May 12 16:07:05 hi, I've an init script that is machine specific,where should I add it in oe to ship it? May 12 16:10:07 mmm May 12 16:10:11 INITSCRIPT_PARAMS = "start 01 5 2 . stop 01 1 6 ." May 12 16:10:19 I'll look May 12 16:24:28 what's the best way to do it? May 12 16:34:27 hi, while building an image from scratch I had the following error in linux's staging_packager which made the build fail May 12 16:34:35 http://pastebin.org/226207 May 12 16:35:18 I have BB_NUMBER_THREADS=2 and PARALLEL_MAKE = "-j 2" May 12 16:35:40 any idea of why I get this error ? May 12 16:36:45 not much infos May 12 16:37:41 GNUtoo: for initscripts, what I do here is either integrating it in the package of the app the script launch or creating a custom package for several scripts, including some in init May 12 16:37:54 ok May 12 16:37:56 not sure this is the best way, but at least this works May 12 16:38:14 * GNUtoo is looking for something commitable May 12 16:38:31 the script is machine arch May 12 16:39:16 maybee in recipes/initscripts, there seems to be some machine scripts there May 12 16:39:24 ok I'll look May 12 16:39:25 thanks a lot May 12 16:39:49 is there any image which is smaller than base-image?? May 12 16:40:19 micro images are small May 12 16:40:58 i mean do they have any name like "bitbake micro-image" May 12 16:41:53 seems I'm not the only one with stange things in staging_packager : http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg03670.html May 12 16:42:45 ok May 12 16:43:00 Spyzer, cd recipes/images May 12 16:43:04 ls | grep micro May 12 16:43:42 ericben, thanks a lot May 12 16:44:12 (I didn't sleep well last night so I'm a bit hum...sleepy) May 12 16:45:20 thnx :) May 12 16:51:22 mmm May 12 16:51:22 RCONFLICTS_${PN} = "initscripts" May 12 16:51:30 lol May 12 16:51:36 I've only 1 script May 12 16:51:38 to include May 12 16:54:05 maybe I could require initscripts May 12 16:54:54 where do you have this RCONFLICTS ? May 12 17:10:32 I really hate myself for that, but I once again forgot which package provides "ldd" :( I should remember where I wrote that down, dammit... May 12 17:10:37 hint please? :) May 12 17:12:49 Jin^eLD: its glibc/eglibc/uclibc May 12 17:13:22 Jin^eLD: You will have to pay for getting answers for such questions :) May 12 17:13:31 I know :) especially since its not the first time May 12 17:13:45 I wrote that down, honestly, but well, after couple of months do nto even know where I wrote it down :) May 12 17:14:13 doh, its even already compiled as ldd ;) and I was searching in recipes.. May 12 17:14:21 Jin^eLD: yeah it happens to me too. unless I make notes in my ~/howto folder I dont remember anything May 12 17:14:42 too much data too less ram May 12 17:14:56 what is a cool site for writing blogs May 12 17:15:04 I was looking at wordpress May 12 17:15:09 * Jin^eLD is not much of a blogger May 12 17:15:20 huh, whats that? May 12 17:15:21 root@at91sam9g20ek:/usr/bin# ./ldd May 12 17:15:21 -sh: ./ldd: not found May 12 17:15:34 ooh ldd is a bash script May 12 17:15:47 thats odd... May 12 17:16:24 yep :) May 12 17:16:41 compiling bash then... May 12 17:16:42 well if you used eglibc you could use other shells too May 12 17:17:02 IIRC I have fixed eglibc for that but dont count on that May 12 17:17:06 I never tried it... I guess went with something I was used to May 12 17:17:17 which is most often uclibc or glibc May 12 17:17:23 if you know glibc then you already know eglibc May 12 17:17:38 because its glibc+embedded needs of a libc May 12 17:17:57 one day all distros in OE will use it I am sure May 12 17:18:11 instead of glibc May 12 17:18:54 I'll have to try it at some point May 12 17:19:15 so far I did not even have the time to sync with latest OE, still using an older snapshot May 12 17:19:43 Jin^eLD: oh its getting better everyday May 12 17:19:58 so update at earliest time you find May 12 17:20:01 I think I am a couple of months behind May 12 17:20:06 but you will have to do a lot of migration May 12 17:20:20 in what area? May 12 17:20:28 staging May 12 17:20:40 I only have a handful of self-made packages May 12 17:20:58 mostly taking the ones from OE and doing slight adaptions to my needs inside a collection May 12 17:21:09 so should not be too much work I guess May 12 17:21:14 too bad ericben has quit May 12 17:21:16 anyway May 12 17:21:28 I have to ship a machine specific init script May 12 17:21:55 how do I do that,I don't want to fork the init script recipe for 1 machine specific script May 12 17:22:11 the init script is for calibrating the 2 screens May 12 17:22:18 with ts_calibrate May 12 17:22:43 speaking of init scritps, I have, I think, a usable runit supervisor configuration / recipe May 12 17:22:56 supervisor? May 12 17:23:15 are you familiar with runit? it monitors the processes it starts May 12 17:23:22 so if some daemon dies, it will autorestart it May 12 17:23:23 ah no May 12 17:23:30 I'm not familiar with it May 12 17:23:34 but it sounds interesting May 12 17:23:43 motsly an init.d replacement which is however compatible and which can live along with init.d May 12 17:23:52 ok May 12 17:25:39 quite useful actually, if you have critical services that might crash but that have to be running May 12 17:25:43 ok May 12 17:44:33 hi, init scripts seem machine specific May 12 17:44:50 but I didn't find something defining it May 12 17:45:27 do_install_append_hipox () { May 12 17:45:57 should I machine arch only for hipox May 12 17:45:58 I think May 12 17:45:59 so May 12 17:46:11 also for bug 1.x because I'd like to ship an init script May 12 17:50:03 mmm no May 12 17:50:12 seem machine specific for a lot more than hipox May 12 17:50:25 a find in the dir gives a lot of overrides May 12 17:51:17 GNUtoo: do_install_append_hipox this will work May 12 17:51:26 as long as you have MACHINE in overrides May 12 17:51:35 and seems ok May 12 17:52:29 khem, the issue is that the resulting package is not machine arch May 12 17:52:40 there is no such thing: May 12 17:52:43 PACKAGE_ARCH = "${MACHINE_ARCH}" May 12 17:52:52 I'll add that then May 12 17:53:44 GNUtoo: why do you need PACKAGE_ARCH = "${MACHINE_ARCH}" May 12 17:54:09 because it ships different init script for different machines May 12 17:54:12 is MACHINE missing ? May 12 17:54:23 MACHINE ??? May 12 17:54:45 well do_install_append_hipox happens at build time May 12 17:54:56 yes,the other overrides too May 12 17:55:08 so if you built the distro for MACHINE=hipox your stuff in do_install_append_hipox will get added to do_install May 12 17:55:15 yes I know May 12 17:55:22 but what if May 12 17:55:36 you build MACHINE=hipox then build MACHINE=jornada May 12 17:56:16 or machine from same arm version May 12 17:56:28 then find the common between these machines May 12 17:56:49 or add _append funcs for each one you want May 12 17:56:59 http://pastebin.com/Ydn12kLT May 12 17:57:20 I think I don't explain well May 12 17:57:33 I'll try better May 12 17:58:01 MACHINE=om-gta02 bitbake foo-image May 12 17:58:08 it builds the init script package May 12 17:58:13 ok May 12 17:58:21 with overrides from om-gta02 May 12 17:58:23 this will not append do_install_append_hipox May 12 17:58:26 om-gta02 is armv4 May 12 17:58:34 yes right May 12 17:58:38 then May 12 17:58:47 let's say we build angstrom May 12 17:58:48 then May 12 17:58:55 s/first then// May 12 17:59:04 ok May 12 17:59:10 you build angstrom first May 12 17:59:11 MACHINE=friendly arm bitbake foo-image May 12 17:59:26 no I build angstrom for both machines May 12 17:59:35 both machines are armv4 May 12 17:59:59 with the second machine without PACKAGE_ARCH = "${MACHINE_ARCH}" it won't rebuild the package May 12 18:00:11 ah I got it you are building for two machines in same tmpdir May 12 18:00:25 and we'll get a om-gta02 init scripts in a friendly arm machine May 12 18:00:26 yes May 12 18:00:34 that's an issue for angstrom May 12 18:01:16 hmmm in that case yes you have to make this package machine specific May 12 18:01:25 ok May 12 18:01:27 thanks May 12 18:02:30 GNUtoo: I think sysvinit is already machine specific May 12 18:02:44 grep MACHINE didn't return something May 12 18:03:25 I'm at cca8167ae3a99c6a39a53bcd9d380de983843f3d which is fairly recent May 12 18:03:28 from yesterday May 12 18:03:46 or today I don't remember May 12 18:03:55 PACKAGE_ARCH_${PN}-inittab = "${MACHINE_ARCH}" May 12 18:04:14 thats how it does for sysvinit May 12 18:04:31 I'm talking about ~/oe/org.openembedded.dev/recipes/initscripts/initscripts_1.0.bb May 12 18:04:33 ok May 12 18:04:52 I know how to do it May 12 18:05:11 I meant do it like sysvinit does May 12 18:05:21 ok May 12 18:05:28 PACKAGE_ARCH = "${MACHINE_ARCH}" is sufficent I think May 12 18:05:54 PACKAGE_ARCH = "${MACHINE_ARCH}" May 12 18:05:55 I'll add that then May 12 18:06:10 hmmm May 12 18:06:21 in initscripts they seem to have specific recipes May 12 18:06:31 also May 12 18:07:36 but find finds lots of override in initscripts-1.0 May 12 18:09:06 I'll eat May 12 18:09:09 thanks May 12 18:10:31 bon appetit May 12 18:20:29 is there any "lightweight" and efficient web browser for embedded systems?? May 12 18:25:48 Spyzer: midori May 12 18:27:12 re May 12 18:28:04 Hi florian May 12 18:28:42 Spyzer: may be opera mini too May 12 18:30:10 Hi florian May 12 18:34:21 is midori not in the oe recipes?? May 12 18:36:06 There's arora too (no recipe, AFAIK) May 12 18:36:51 hmm so can i use for my_own_customized_image.bb ?? May 12 18:37:09 Spyzer: I dont think we have midori May 12 18:37:22 in OE May 12 18:37:50 khem: Well is there any other lightweight browser then in the May 12 18:37:52 OE May 12 18:38:33 03Stefan Schmidt  07org.openembedded.dev * r747aa9d890 10openembedded.git/recipes/xorg-xserver/xorg-xserver-common.inc: xorg-xserver-common.inc: Bump PR for the last change to the bug20 xorg conf May 12 18:40:46 Spyzer: dillo2 may be epiphanu May 12 18:40:51 epiphanu May 12 18:41:02 * khem cant type y May 12 19:22:43 khem, thanks May 12 19:53:14 Bitbake question: can a personal recipe inherit from a public recipe... May 12 19:54:03 and do so by placing the personal bb file in a directory completely unrelated to the public recipe. In the past no. May 12 19:54:21 dickelbeck: it seems you need OVERLAY May 12 19:54:28 I would like to try and fix this if it has not been fixed yet. May 12 19:55:25 khem: overlay yes. In the past there were limits as to what could be inherited from the public place. May 12 19:56:28 Wait sorry, here was the problem. You develop a replacement recipe and want it to use some of the same includes as the original. May 12 19:56:47 you could use amend.inc May 12 19:57:18 khem: don't know about amend.inc May 12 19:58:17 In my explanation, I am not inheriting from the original, but trying to replace a recipe by placing it in the overlay, but want to use the includes from the original place. May 12 19:58:57 In the past this was not possible. I assume this is still a problem? Is this the problem that amend.inc fixes? May 12 20:03:12 mmm initscripts seem for boot scripts May 12 20:03:15 not for x11 things May 12 20:03:21 I'll only fix machine arch May 12 20:04:29 I'll do it in ts_calibrate recipe May 12 20:04:39 dickelbeck: I think it does May 12 20:05:13 moreover there are machine arch bits May 12 20:08:45 khem: any ideas on the eet cross compile badness issue I am seeing? May 12 20:09:11 perhaps related to 64 bit ubuntu -- builds on my 32 bit ubuntu machines seem to complete normally May 12 20:09:39 kergoth - talking to Brad Dixon about Mentor. May 12 20:17:46 sakoman_: whats your gcc version May 12 20:18:31 sakoman_: show me log.do_configure of eet May 12 20:19:18 http://www.sakoman.com/test/log.do_configure.26195 May 12 20:19:44 gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 May 12 20:21:27 sakoman_: I mean cross gcc May 12 20:21:40 sakoman_: I dont see anything wrong in configure May 12 20:22:05 ok next it there is away to emit verbose info during compilation May 12 20:22:16 so I can see where the includes comes from May 12 20:23:44 gcc-cross-4.3.3-r11.1 May 12 20:24:01 hmm ok May 12 20:24:19 sakoman_: 4.3.3 has a bug where it does not treat isystem well May 12 20:24:34 but I am assuming you are not victim of that May 12 20:24:47 isn't 4.3.3 default for angstrom? May 12 20:24:51 so can you compile with some verbose options so I can see the full command which fails May 12 20:24:59 sakoman_: yes it is May 12 20:26:13 any suggestions on how to add the verbose options to the eet build? May 12 20:27:31 hmmm post the makefile somewhere May 12 20:28:47 khem: here is the top level makefile for eet: May 12 20:28:54 http://www.sakoman.com/test/Makefile May 12 20:29:47 looks like the issue is with EINA_FLAGS May 12 20:31:19 sakoman_: yes thats exactly the problem I guess May 12 20:31:20 yup -- on my 32 bit machines EINA_FLAGS are take from tmp/sysroots on the build machine May 12 20:31:34 I wonder why that is screwed up May 12 20:31:48 sakoman_: now post your config.log May 12 20:31:54 and configure script May 12 20:33:20 khem: http://www.sakoman.com/test/config.log May 12 20:34:19 http://www.sakoman.com/test/configure May 12 20:35:51 hmmmm pkgconfig May 12 20:36:06 I guess its not using right pkgconfig on failing build May 12 20:37:03 sakoman_: do you have pkgconfig-native building on both boxes May 12 20:37:13 I'll check May 12 20:37:24 I assume so . . . May 12 20:39:39 khem: yes, pkgconfig-native 0.23 on all machines May 12 20:41:22 sakoman_: did you do build from scratch May 12 20:41:35 no, it wasn't a clean build May 12 20:41:48 just a build after pulling May 12 20:41:56 ok here is a problem May 12 20:42:14 PKG_CONFIG_PATH should now point to correct path inside stagig May 12 20:42:41 I dont know how that acts with new staging stuff May 12 20:42:53 do you still have staging dir May 12 20:42:57 or sysroots May 12 20:43:51 khem: yes, both May 12 20:48:59 sakoman_: strange May 12 20:49:58 sakoman_: I have a x86_64 host May 12 20:50:02 so let me try May 12 20:50:09 bitbake eet May 12 20:51:44 khem: thanks for helping! May 12 20:53:46 robtow: cool May 12 20:54:25 sakoman_: checking for arm-angstrom-linux-gnueabi-pkg-config... /usr/bin/pkg-config May 12 20:54:33 thats could be problem too May 12 20:54:41 can you check how it is on successful build May 12 21:06:01 sakoman_: as expected my eet builds and if I check my configure logs then it has checking for pkg-config... /scratch/oe/qemuarm/sysroots/x86_64-linux/usr/bin/pkg-config May 12 21:06:06 so thats the primary problem May 12 21:06:47 sakoman_: I wonder what PATH is passed to eet via bitbake May 12 21:07:08 khem: sadly -- on a conference call right now May 12 21:07:14 willcheck when I get off May 12 21:07:59 sakoman_: no worries May 12 21:11:13 sakoman_: you can look for 'export PATH' string in run.do_configure.XXX script May 12 21:11:59 /home/steve/overo-oe/tmp/sysroots/x86_64-linux/usr/bin/ should appear before /usr/bin May 12 21:12:13 otherwise we have problem May 12 21:37:14 03Martin Jansa  07org.openembedded.dev * r12dcb2d09c 10openembedded.git/conf/distro/include/sane-srcrevs.inc: May 12 21:37:14 EFL: bump SRCREV for fixed focus and Efreet filter in illume2 Home May 12 21:37:14 Signed-off-by: Martin Jansa May 12 21:37:15 03Martin Jansa  07org.openembedded.dev * r1d968e0ee3 10openembedded.git/ (5 files in 5 dirs): May 12 21:37:15 xorg: add newer xserver 1.8.1, xdm, imake May 12 21:37:15 Signed-off-by: Martin Jansa May 12 22:08:06 jo May 12 22:10:58 hi woglinde May 12 22:12:00 khem: http://www.sakoman.com/test/run.do_configure.6080 May 12 22:12:23 the sysroots version does come first May 12 22:20:02 khem: interesting! I don't have a pkg-config in tmp/sysroots/x86_64-linux/usr/bin May 12 22:29:12 khem: I'm going to try a clean build May 12 23:11:19 sakoman_: wait May 12 23:11:46 sakoman_: just do bitbake -c clean pkgconfig-native;bitbake eet May 12 23:12:03 or rather bitbake -c clean pkgconfig-native eet; bitbake eet May 12 23:12:12 you dont need to nuke all **** ENDING LOGGING AT Thu May 13 02:59:56 2010