**** BEGIN LOGGING AT Fri May 14 02:59:56 2010 May 14 03:47:43 kergoth: do I have to have them in order to run X11 application? May 14 03:50:41 IgorK, if ldd shows them, then you're going to have trouble running the binary without them May 14 03:59:35 well its just adiiference between x86 and arm platforms in "ldd.. " output. So that means I need to install libxi and libxrandr, right? May 14 04:00:01 what about linux-gate? is it x86 specific? May 14 04:00:51 meaning they are present in x86 but not on arm... May 14 04:01:23 linux-gate is a glibc/kernel wankery thing May 14 04:01:33 x86 specific i beleive May 14 04:02:42 if you try to run the binary the dynamic loader will look for each of the entries that you saw in your ldd output. If it can't resolve one of them, it will complain and the binary will not execute May 14 04:22:01 well my problem is that it executes but as a console application, and not the GUI one May 14 04:22:16 im just trying to look for all possibilities.... May 14 04:22:35 and it is running fine on x86 May 14 04:59:45 anyone know off the top of the head what constant to add to in recipes to run some commands before the final image is built? May 14 04:59:57 I want to copy in some of my own files before the image is tar'ed up May 14 05:04:59 aditya_111: in openaos we have this line in the image recipe: May 14 05:05:21 ROOTFS_POSTPROCESS_COMMAND += "${IMAGE_ROOTFS}/../../openaos/recipes/images/extended-gpe-image-postprocess.sh ${IMAGE_ROOTFS}; " May 14 06:36:14 good morning May 14 06:45:16 khem: ping May 14 06:46:30 khem: eglibc_2.11 doesn't have SVN_REV as part of PV, do you mind me bumping PR to get updated rev you pushed now? May 14 09:44:22 good morning May 14 11:36:06 hi,the toolchain seem broken May 14 11:39:02 why? May 14 11:39:16 seems fine here May 14 11:44:16 ok May 14 11:44:34 2 recipes didn't want to build May 14 11:45:10 intone and zhone2 May 14 11:45:18 I'll pastebin the logs May 14 11:45:26 but the first : missing headers May 14 11:45:45 because of toolchain? I guess because new theme API May 14 11:45:46 the second says something abbout broken cross-cmopiler May 14 11:45:52 ah ok May 14 11:46:12 GNUtoo|oeee: see my last commit to libphone-ui-shr May 14 11:46:19 for EFL theme API change May 14 11:47:02 ok May 14 11:47:07 thanks a lot May 14 11:50:31 cbrake, ping May 14 11:51:32 GNUtoo|oeee: yw May 14 11:52:08 the failure was | Error: Cannot find header either inttypes.h or bitypes.h. There is no chance for compilation to succeed. May 14 12:04:52 JaMa,^^^ that sounds like broken toolchain becuause inttypes.h is from libc May 14 12:06:49 GNUtoo|oeee: this is from intone? here it finished fine and also on SHR buildhost May 14 12:06:59 OK May 14 12:07:03 *ok May 14 12:07:07 only failing is e-tasks (because of that api) May 14 12:07:26 ah no May 14 12:07:27 mplayer May 14 12:08:09 I'll pull to see May 14 12:08:15 branch is oe.dev May 14 12:08:37 already up to date May 14 12:08:38 mmm May 14 12:38:39 also: May 14 12:38:41 | configure: error: C compiler cannot create executables May 14 12:38:48 for agg and zhone2 May 14 12:38:58 see config.log there May 14 12:39:02 so definitely broken compiler May 14 12:39:05 probably also some missing .h May 14 12:39:09 I know I'll look May 14 12:39:17 but broken only in your sysroots probably May 14 12:39:23 after rebuild from scratch it works fine May 14 12:40:55 /home/embedded/oetmp_htcdream/cross/armv6-novfp/lib/gcc/arm-oe-linux-gnueabi/4.4.4/../../../../arm-oe-linux-gnueabi/bin/ld: cannot find libgcc_s.so.1 May 14 12:41:06 I use packaged staging May 14 12:41:47 Crofton|work: hello May 14 12:44:56 cbrake, did you see my email about patchwork? May 14 12:48:05 http://lists.ozlabs.org/pipermail/patchwork/2010-March/000244.html May 14 12:48:09 Good tip here :) May 14 13:08:51 Crofton|work: no, I did not see that May 14 13:11:43 Crofton|work: yeah, we need to get some things sorted with the server May 14 13:25:41 pb_: ping May 14 13:25:48 mrmoku: hi May 14 13:25:51 hey :) May 14 13:26:04 how's ARM_INSTRUCTION_SET supposed to work? May 14 13:26:14 or more specific... why does it build EFL in thumb mode? May 14 13:26:39 having ARM_INSTRUCTION_SET = 'arm' in e.bbclass May 14 13:26:42 do you have A_I_S="arm" in your recipe? May 14 13:26:46 ah, hm May 14 13:26:58 it'd be worth checking with bitbake -e to make sure that it isn't being overridden somewhere May 14 13:27:03 grepping for A_I_S I don't find where it is actually used May 14 13:27:04 ok May 14 13:27:52 i.e. "bitbake -e efl |grep ^ARM_INSTRUCTION_SET" May 14 13:28:12 it's used by tune-thumb.inc I think May 14 13:28:15 running May 14 13:28:31 yeah, here we are: May 14 13:28:33 ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}" May 14 13:28:48 so, if A_I_S=="thumb", you should get -mthumb. if it isn't, you should get -mno-thumb May 14 13:29:20 ${ARM_THUMB_M_OPT} is spliced into TARGET_CC_ARCH in that same file. May 14 13:29:43 checking for arm-oe-linux-gnueabi-gcc... ccache arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mno-thumb May 14 13:29:51 is what I have in log.do_config May 14 13:29:56 right, that's fine May 14 13:30:00 what makes you think it is trying to build as thumb? May 14 13:30:29 we get logs of alignment traps May 14 13:30:32 lots May 14 13:30:37 and I posted on in #e May 14 13:30:42 alignment traps aren't usually caused by thumb May 14 13:30:49 and somebody told me that it is thumb May 14 13:30:55 ah, I think you were given bad information there May 14 13:31:02 heh May 14 13:31:03 ok May 14 13:31:22 13:31 < mrmoku> [21474625.130000] Alignment trap: enlightenment (718) PC=0x40287306 Instr=0x6027 Address=0xbeb78887 FSR 0x813 May 14 13:31:37 if you want to check, you can determine fairly quickly if the binary really is thumb or not by using "arm-linux-objdump -d" to disassemble it May 14 13:31:55 if the instructions are 16 bits long (i.e. 4 hex digits) then it's thumb. if they are 32 bits long (8 digits) then it's arm May 14 13:32:33 that alignment trap is in a shared library. can you check which library it is? May 14 13:32:42 i.e. which lib contains the address 0x40287306 May 14 13:33:03 how? May 14 13:33:04 it might not even be trapping inside efl itself, could be glibc or anything May 14 13:33:11 check /proc/NNN/maps while the program is running May 14 13:33:19 ok May 14 13:36:40 pb_: 40271000-40291000 r-xp 00000000 b3:01 17757 /usr/lib/libdbus-1.so.3.5.0 May 14 13:36:44 ah, dbus May 14 13:36:49 so, that's where you should focus your attentions May 14 13:37:04 mrmoku, I've this too with ifup or similar things May 14 13:37:10 ok, thanks May 14 13:46:47 hi all May 14 14:01:18 hi recalcati May 14 14:03:13 hi mckoan May 14 14:05:39 recalcati: still (wind)surfing ? May 14 14:06:50 * mckoan is removing dust from one of his SheevaPlug :-D May 14 14:07:58 um windsurfing May 14 14:12:58 yes... I hope saturday and sunday some northwind ! May 14 14:14:10 I'm looking at a good example of subpackage.. May 14 14:27:47 does anyone have ideas on the meta-toolchain issue? May 14 14:31:16 http://thread.gmane.org/gmane.comp.handhelds.openembedded/32434 May 14 14:55:47 hi, http://patchwork.openembedded.org/patch/2012/ fix for modules what http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=35e7b34d3b5b96ed11bc7ed6b2a5d08e6183d8a3 fixed for kernel : may anyone have a look at it ? May 14 14:59:08 is Koen Kooi on IRC ? I was told he is the person to contact about MACHINE_KERNEL_PR May 14 14:59:20 ericben: I think he hangs out in some other channels, but not this one May 14 15:00:15 cbrake: what happens if you try to build gdb-cross-sdk directly? May 14 15:00:23 pb_: ok, thanks so I will try again by mail to get a review for this patch May 14 15:00:38 ok, good idea May 14 15:08:07 pb_: gdb-cross-sdk seems to be building May 14 15:08:55 hm, so I wonder why bitbake thinks it is unbuildable as part of meta-toolchain May 14 15:08:58 that is rather weird May 14 15:09:03 pb_: yes it is May 14 15:09:31 sounds like a bitbake bug; maybe kergoth has some idea May 14 15:09:48 even if there is an underlying metadata bug as well, I think bitbake should be issuing a better diagnostic in this case May 14 15:29:18 03Eric BENARD  07org.openembedded.dev * rdd333a3090 10openembedded.git/classes/module_strip.bbclass: May 14 15:29:18 module_strip.bbclass: set KERNEL_MAJOR_VERSION May 14 15:29:18 KERNEL_MAJOR_VERSION may not be set (for example when building a module) May 14 15:29:18 and this was preventing modules from being stripped. May 14 15:29:18 Signed-off-by: Eric Benard May 14 15:29:19 Signed-off-by: Tom Rini May 14 15:37:10 jo hrw May 14 15:37:16 still in .be? May 14 15:43:52 cbrake: what is strange is that adding RPROVIDES = "gdb-cross-sdk" in gdb-cross-sdk_7.1.bb seems to make bitbake happy May 14 15:45:40 shouldn't bitbake find gdb-cross-sdk_7.1 by itself ? May 14 15:47:21 oh, heh. I wonder if the sdk class is stomping on PACKAGES or something. May 14 15:47:32 that was one of the things that I changed in toolchain-desuck, I think May 14 15:58:44 I need a Parsing for Dummies, I think May 14 15:58:55 * kergoth tries to dig up the dragon book in electronic form May 14 15:59:32 * kergoth can't seem to get 'case' statement support working in pysh May 14 16:01:53 *g* May 14 16:26:39 hmm May 14 16:27:01 the rules in pyshyacc for PLY are taken verbatim from the BNF in POSIX 1003.1 May 14 16:27:09 yet it fails on a case statement May 14 16:27:11 * kergoth scratches head May 14 16:35:37 03Koen Kooi  07org.openembedded.dev * r0be9067bfe 10openembedded.git/recipes/linux/ (2 files in 2 dirs): linux-omap-psp 2.6.32: add ram timing for second bank as well May 14 16:35:38 03Koen Kooi  07org.openembedded.dev * ra7756ec75b 10openembedded.git/recipes/usb-gadget-mode/ (files/beagleboard/usb-gadget.conf usb-gadget-mode.bb): usb-gadget-mode: switch beagle to g_ether to make MS Windows work May 14 16:35:41 03Koen Kooi  07org.openembedded.dev * r5267ad977d 10openembedded.git/recipes/jikes/jikes-initial.bb: jikes-initial: make it build with new style staging May 14 16:35:41 03Koen Kooi  07org.openembedded.dev * r041fe58428 10openembedded.git/recipes/gstreamer/gst-plugins.inc: gst-plugins: enable gst-plugin-x264 May 14 16:35:43 03Koen Kooi  07org.openembedded.dev * r4a5fdf9357 10openembedded.git/recipes/linux/linux.inc: linux.inc: add protptype for 'kernel-headers' package May 14 17:15:36 03Tom Rini  07org.openembedded.dev * r40c5906ebe 10openembedded.git/recipes/busybox/busybox.inc: May 14 17:15:36 busybox: Fix the -dbg package, bump INC_PR May 14 17:15:36 busybox will link to busybox_unstripped then strip to produce busybox, May 14 17:15:36 giving us an empty -dbg package. At the end of do_compile, copy May 14 17:15:36 busybox_unstripped to busybox, so our striping happens as expected. May 14 17:15:37 Signed-off-by: Tom Rini May 14 17:17:08 hi all May 14 17:19:51 zecke - good morning. May 14 17:33:20 The kernel script/ contents are only used during kernel builds, yes? If so I'm suggesting we don't stage them anymore. May 14 17:33:46 s/script/scripts/ May 14 17:36:26 re May 14 17:37:38 pb_: commenting out PACKAGES = "" in class/cross.bbclass seems to fix the thing : what is the purpose to clearing PACKAGES in this bbclass ? May 14 17:37:58 blah bitbake nano stil fails May 14 17:38:05 it sux;/ May 14 17:38:23 I want to build qemu-native when a qemu machine is selected. How could I do it May 14 17:38:37 soltys: all suxx May 14 17:38:48 hrw-uds: why so ? May 14 17:38:55 hrw-uds: hey May 14 17:40:24 soltys: you told that bitbake suxx so I generalized it May 14 17:40:47 mhm May 14 17:40:57 khem: MACHINE_EXTRA_DEPENDS += "qemu-native"? May 14 17:41:08 hrw-uds: but it fails only while building nano on avr32... May 14 17:41:25 soltys: for avr32 you mean May 14 17:41:26 witch some gettext error while do_configure. May 14 17:41:32 soltys: ngw100 does not run OE May 14 17:41:40 soltys: bitbake gettext;bitbake nano May 14 17:41:59 hrw-uds: it will fail, as libiconv fails with the same error May 14 17:42:00 soltys: or better add 'inherit gettext' into nano recipes, prepare patch and send for OE May 14 17:42:18 hrw-uds: there is that inherit. May 14 17:42:26 ops then May 14 17:42:27 thats the problem May 14 17:42:45 hrw-uds: tried did not work May 14 17:42:55 khem: IMAGE_DEPENDS? May 14 17:43:56 hrw-uds: I can try that but I thought it would be something not part of image May 14 17:44:18 let me try though May 14 17:44:29 khem: check how we force u-boot to be built for some machines May 14 18:38:46 03Antonio Ospite  07org.openembedded.dev * r8f70c54795 10openembedded.git/recipes/tzdata/tzdata_2010i.bb: May 14 18:38:47 tzdata: update to 2010j May 14 18:38:47 Signed-off-by: Antonio Ospite May 14 18:38:57 03Antonio Ospite  07org.openembedded.dev * r0715d00535 10openembedded.git/recipes/tzcode/ (tzcode-native_2010f.bb tzcode-native_2010j.bb): May 14 18:38:57 tzcode-native: update to 2010j May 14 18:38:57 Update checksums; tzdata version bumps to 2010j as well. May 14 18:38:57 Signed-off-by: Antonio Ospite May 14 18:42:20 re May 14 18:46:12 oh zecke May 14 18:56:29 WOOT May 14 18:56:36 shell parser finally handles case statements :) May 14 18:57:20 now to add a variable flag to list explicit variable dependencies, so we can handle references to programmatically generated variable names May 14 18:57:30 have a nice weekend May 14 19:09:59 kergoth without the dragonbook? May 14 19:10:04 indeed May 14 19:10:09 the problem wasn't the parser at all May 14 19:10:12 it was the lexer May 14 19:10:35 'in' is handled specially, because when used in 'case $foo in' or 'for foo in ...' its its own token, a reserved word May 14 19:10:42 but elsewhere its just a word May 14 19:10:50 that logic was only handling the 'for' case, not the 'case' case May 14 19:10:57 hm I will put now NATIVE_INSTALL_WORKS = "1" into java-native.bbclass to silience to legcy stuff May 14 19:11:04 nice May 14 19:12:53 * kergoth tests the shell parser against every shell function in the OE metadata May 14 19:22:53 03Henning Heinold  07org.openembedded.dev * r2234c91528 10openembedded.git/classes/java-native.bbclass: java-native.bbclass: silence the legacy staging msg May 14 19:33:54 hm what was INHIBIT_NATIVE_STAGE_INSTALL = "1" doing? May 14 19:37:16 03Koen Kooi  07org.openembedded.dev * reac38ab695 10openembedded.git/recipes/ti/ti-devshell.bb: ti-devshell: TI version of devshell that has all the 'DVSDK' environment vars set May 14 19:37:17 03Koen Kooi  07org.openembedded.dev * r158d613614 10openembedded.git/recipes/x-load/signgp-native.bb: signgp-native: convert to new-style staging May 14 19:39:03 re zecke May 14 19:50:56 re May 14 19:55:10 hi florian May 14 20:14:29 ping rp May 14 20:15:48 hms when I use BBCLASSEXTEND = "native", export LD = "${CC} ${LDFLAGS}" May 14 20:15:54 dont works May 14 20:18:54 i think you'll need to be more specific than 'dont works' :) May 14 20:19:12 export LD = "${CC} ${LDFLAGS}" May 14 20:19:19 I try to simplify unzip May 14 20:19:21 what about it? May 14 20:19:39 in native case LD is still ld May 14 20:19:46 not ${CC} May 14 20:21:05 hm I think I will workaround with HOST_LD May 14 20:22:38 BUILD_LD I meant May 14 20:22:41 native.bbclass sets LD May 14 20:22:48 and bbclassextend loads the class after the recipe May 14 20:22:51 so that's not too surprising May 14 20:24:05 hmm May 14 20:24:31 hm May 14 20:24:34 dont works May 14 20:28:51 hm for BUILD_LD is set correctly May 14 20:34:01 hm its native-class May 14 20:34:06 which ovverides it May 14 20:35:52 woglinde_, I think RP is in the midst of traveling atm May 14 20:36:03 zenlinuxPDX okay May 14 20:40:49 damnit, an exception in a python task is swallowed by bitbake master, doesn't show the traceback, even in the log May 14 20:42:06 hm May 14 20:42:24 why it works when require inherit native is used May 14 20:42:55 as i'm pretty sure i already said, with bbclassextend, i think native is parsed *after* the recipe May 14 20:42:59 ah May 14 20:43:03 yes May 14 20:43:05 since the native LD = runs after yours, it blows it away May 14 20:43:07 unless you use an override May 14 20:43:42 original recipe has inherit before require May 14 20:44:08 * kergoth was just thinking it might be better to change it to load the extendclasses before the recipe, but there'd be difficulties there due to native not being able to override functions in the recipe May 14 20:46:20 I have ROOTFS_POSTPROCESS_COMMAND += "zap_root_password; " in my bb file but I still get a root password, can anyone tell me where I'm going wrong? May 14 20:46:48 kergoth hm so what should I do May 14 20:48:01 patch the Makefile? May 14 20:49:55 hm ah May 14 20:51:25 maybee LD="${CC} ${LDFLAGS}" oe_runmake -f unix/Makefile generic worjs May 14 20:53:29 hehe May 14 20:53:31 better May 14 20:53:36 could do EXTRA_OEMAKE += "'LD=${CCLD} ${LDFLAGS}'" May 14 20:53:59 kergoth no it worked in do_compile May 14 20:54:03 all is fine May 14 20:54:34 EXTRA_OEMAKE is cleaner, imo May 14 20:54:50 hms May 14 20:55:33 okay May 14 20:56:15 and thanks for the hint May 14 20:57:46 03Eric BENARD  07org.openembedded.dev * r380b38b1af 10openembedded.git/recipes/nano/nano.inc: May 14 20:57:46 nano: add gettext dependency May 14 20:57:46 bitbake nano fails without this if gettext is not built May 14 20:57:46 Signed-off-by: Eric Benard May 14 20:57:46 Signed-off-by: Tom Rini May 14 20:58:03 What's the procedure for recommending someone for rw access? Just post to the ML asking for more acks? May 14 20:58:19 Tartarus yes May 14 20:58:34 kk May 14 20:58:59 recipe glibc_2.6.11.bb do_package failed on ubuntu 10.04 saying "mmap: Operation not permittied" May 14 20:59:11 do I need to be root to build it? May 14 20:59:17 xxiao no May 14 20:59:36 glibc 2.6.11? May 14 20:59:40 this is odd then, i used angstrom's 2009/stable, and it failed in the middle May 14 21:00:02 hm May 14 21:00:03 yeah 2.6.11 May 14 21:00:11 2.6.1 you mean May 14 21:00:17 there is no 2.6.11 recipe May 14 21:00:33 hm May 14 21:00:46 seems no one yet tested stable on lucid May 14 21:00:53 tried both LANG=C and en_US.UTF-8 May 14 21:00:55 cannt you use dev? May 14 21:01:09 well that also failed on gettext May 14 21:02:51 i could not get dev on lucid compiled then return to angstrom/beagleboard/2009/stable May 14 21:03:51 hm??? May 14 21:03:58 what was wrong May 14 21:04:07 at least gcc-cross build for me on lucid today May 14 21:05:29 gcc-cross seems fine here as well May 14 21:05:42 on dev, bitbake nano failed : cp: cannot stat `/home/xxiao/devel/oe/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/gettext/config.rpath': No such file or directory May 14 21:05:52 hm ah May 14 21:06:10 why didnt you reported May 14 21:06:26 going to actually May 14 21:06:37 xxiao: Just fixed May 14 21:06:46 about 9 min ago May 14 21:06:51 Tartarus, the gettext one? May 14 21:06:55 yeah May 14 21:06:59 pb: concerning gdb problem with sdk, you told me there may be something with PACKAGES in sdk class May 14 21:07:06 ok wait...will try now May 14 21:07:15 thanks Tartarus May 14 21:07:15 pb_: I found that commenting out PACKAGES = "" in class/cross.bbclass seems to solve the problem (I'll confirm later as I'm rebuilding froom scratch) May 14 21:07:23 pb_: do you know what is the purpose on PACKAGES = "" in cross.bbclass ? May 14 21:07:44 wogline: It was ericben over there that did it, I just pw-am.sh'd it :) May 14 21:07:54 ah right May 14 21:07:56 sorry May 14 21:08:08 ericben hm let see May 14 21:08:19 yeah, it's to prevent packages being built for cross recipes. I think this is a mistake and, as I said earlier, it is something that I removed in the toolchain-desuck branch. May 14 21:08:39 re pb May 14 21:08:44 hi woglinde May 14 21:08:53 ericben delete it and post the patch to ml May 14 21:08:57 with ack from pb May 14 21:08:59 *g* May 14 21:09:08 btw : it seems doing a bitbake meta-toolchain from scratch doesn't work, that's how I found bitbake nano also failed ;-) May 14 21:09:40 03Henning Heinold  07org.openembedded.dev * re0da0c67aa 10openembedded.git/recipes/unzip/ (unzip-native_552.bb unzip_552.bb): May 14 21:09:40 unzip: use BBCLASSEXTEND now May 14 21:09:40 * kudos to kergoth for the EXTRA_OEMAKE hint May 14 21:09:40 * no functional change so no PR bump May 14 21:09:55 one recipe fewer to parse May 14 21:10:59 pb I will send the strip-components now to the ml May 14 21:11:06 ups + patch May 14 21:12:39 hms what was the stupid git command for it May 14 21:12:58 very good May 14 21:13:48 format-patch May 14 21:13:49 args May 14 21:15:11 pb_: OK, so if I understand well sdk.bbclass content in you branch is now found in cross.bbclass in dev ? May 14 21:16:37 ericben: no, that is probably just me mixing up the two classes May 14 21:16:52 sdk.bbclass is somewhat obsolescent in any case May 14 21:17:44 ok, I let my build finish and I'll send the patch if that works (at least bitbake was happy with this fix) May 14 21:22:45 Tartarus: around ? May 14 21:23:45 hoi khem May 14 21:23:58 is udev needed on ppc systems which have like openbios May 14 21:24:02 woglinde: hello May 14 21:25:20 woglinde: I have almost booted ppc on qemu :) it goes all the way and when trying to launch login INIT: Id "1" respawning too fast: disabled for 5 minutes May 14 21:25:38 hehe May 14 21:25:41 this was due to udev gotcha's May 14 21:25:44 libc error May 14 21:25:46 in past May 14 21:25:49 udev? May 14 21:26:03 hm May 14 21:26:04 yeah device not being there for getty May 14 21:26:05 ah okay May 14 21:26:08 init is working May 14 21:26:49 yes seems so May 14 21:27:05 its at the end when it should give me the prompt May 14 21:27:20 use static dev May 14 21:27:22 *g* May 14 21:27:38 INIT: Entering runlevel: 5 May 14 21:31:53 hm llvm develops its own c++ lib May 14 21:31:59 yes May 14 21:32:19 they prolly will have a replacement for libgcc too May 14 21:33:04 hm May 14 21:33:09 didnt read that May 14 21:33:21 but now I know why they sticked woth gcc-4.2 May 14 21:33:27 because of gpl May 14 21:33:28 GPL May 14 21:33:30 3 May 14 21:34:35 khem: don't know on ppc, but on ARM & x86 I mount /sys, then a tmpfs on /dev and then mdev -s creates the devices (and is faster than udev) May 14 21:37:36 ericben: I could try that May 14 21:37:44 but I need to find this problem May 14 21:37:51 ericben are you using oe only private or for the job too? May 14 21:38:06 woglinde: both May 14 21:38:13 fine May 14 21:38:38 job : arm, private projects : arm & x86 May 14 21:38:45 03Henning Heinold  07org.openembedded.dev * r20287a5b1e 10openembedded.git/recipes/unzip/unzip_552.bb: unzip: do_stage is not needed with NATIVE_INSTALL_WORKS = "1" May 14 21:39:29 ericben args I forgot to ack your rw access May 14 21:41:02 done May 14 21:42:12 woglinde: thanks May 14 21:44:05 hm who can edit main wiki page? May 14 21:47:45 ok for cross.bbclass : the sdk was properly built and a helloworld for arm runs under qemu-arm May 14 21:49:19 ericben: do you have your startup scripts somewhere May 14 21:49:23 to use mdev May 14 21:58:55 khem: http://git.buildroot.net/buildroot/tree/target/generic/target_busybox_skeleton/etc/inittab May 14 21:59:42 khem: this was on a handmade rootfs so it's using busybox's inittab May 14 22:00:41 (even if I sent the builroot git !). Btw, OE has it in recipes/busybox/files/mdev May 14 22:01:00 yeah May 14 22:03:45 nice May 14 22:11:03 khem: I think IMAGE_DEV_MANAGER = "busybox-mdev" in you image setup this automagicaly May 14 22:11:22 ericben: yeah May 14 22:14:23 well the gettext build error is gone however for bitbake nano there is: NOTE: Unpacking ../dl/expat-2.0.1.tar.gz to tmp/work/armv7a-angstrom-linux-gnueabi/expat-2.0.1-r3/ May 14 22:14:40 gzip: stdin: invalid compressed data--crc error May 14 22:15:17 expat_2.0.1.bb do_unpack failed May 14 22:16:37 rm expat tar from archive May 14 22:16:42 .md5 file too May 14 22:27:50 Hi, ALL May 14 22:28:39 khem: I just finished rebuilding everything with the bitbake-dev. I still receive a SIGSEGV from my program May 14 22:29:18 What I found is that the link dependencies are different on x86 and ARM. could this be a problem? May 14 22:29:42 the program starts as a console application and not as a GUI one... May 14 22:35:09 is there a way to remove a single package from an image? May 14 22:35:58 something like IMAGE_INSTALL -= "pkgname" would be cool May 14 22:36:37 IgorK how is it linked on x86 and how on arm? May 14 22:44:48 zenlinuxPDX: not without creating your own image recipe, or using an anonymous python function to remove it. -= doesn't yet exist.. its more complex than you'd think May 14 22:44:54 woglinde: I'm building using bitbake for an arm (mini2440)? Is it possible to display the build commands from the bitbake? May 14 22:45:06 IgorK its all in the logs May 14 22:45:18 look at the /temp dirs May 14 22:45:20 Looks like EXCLUDE_FROM_WORLD_pn should do the trick? May 14 22:45:35 ok, let me post it to the pastebin, hang on.... May 14 22:45:49 EXCLUDE_FROM_WORLD means a 'bitbake world' doesn't build it May 14 22:45:51 that's all May 14 22:45:58 has zero effect on things pulled in via dependencies May 14 22:46:04 ok May 14 22:52:34 I git sent a patch and got this from the list : http://pastebin.org/237264 any idea what "Message may contain administrivia" means ? May 14 22:53:54 found : one line starts with who ! May 14 23:01:00 woglinde: here it is: http://pastebin.com/iADD3N45 May 14 23:01:08 thank u for looking onto this May 14 23:02:49 IgorK so you are using wx May 14 23:05:04 IgorK I can only guess May 14 23:05:17 maybee wx cannt be run with thumb support May 14 23:05:38 so rebuild wx without thumb support May 14 23:06:50 putting ARM_INSTRUCTION_SET = "arm" inside the wx .bb May 14 23:15:56 ok, let me try this. this line can be put anywhere in recipe, right? May 14 23:16:19 yes May 14 23:17:53 woglinde: should I use "arm" or "armv4t"? May 14 23:21:09 ??? May 14 23:21:15 armv4t is okay May 14 23:21:24 -thumb is getting removed May 14 23:22:29 ok I will use "armv4t" since I think its an armv4t device May 14 23:22:48 let me recompile evrything,I will be back with the results May 14 23:23:51 sure but I will be at sleep May 14 23:43:23 ericben: your email might have something thats getting into ADMIN filter May 14 23:43:47 ericben: some keywords May 14 23:44:03 khem: yes it had one line starting with who May 14 23:44:52 there you go May 14 23:45:09 if it has who followed by nothing May 14 23:45:15 then you are filtered May 14 23:45:48 yes I fixed the comment and the mail is now on the list ;-) May 14 23:55:59 ericben: I see May 14 23:58:08 ericben: I will look into your patches this weekend May 14 23:58:26 ericben: do you have a list of ones that are pending May 14 23:58:47 I can grok the ml too May 14 23:59:45 woglinde: that's OK, hopefully someone here will be able to help further... ;-) May 15 00:00:09 IgorK: you should try to capture backtraces etc. May 15 00:00:18 so that the reason for crash can be figured out May 15 00:01:05 otherwise its hard to find out we dont have magical crystal ball May 15 00:08:26 khem: patchworks is working again so all the patches are there, I think you can give a look to the first 3 ones. I'll rework compat-wireless asap. May 15 00:08:57 ~lart hotspot buildsystem May 15 00:08:58 * ibot pours gasoline all over hotspot buildsystem, ignites the fire, and then enjoys some toasty marshmallows with the glorious blaze May 15 00:13:46 khem: I may be online on saturday night (GMT+1 time) or sunday if any change is needed May 15 01:21:15 ericben: ok, where do u live geography wise May 15 01:24:07 so umm May 15 01:24:15 I added opencv to my x11-image recipe May 15 01:24:21 and also added opencv-samples May 15 01:24:32 except for the samples, it just downloaded thes sources May 15 01:24:44 it didn't actually compile the samples :/ May 15 01:31:11 aditya_111: what commands did u execute May 15 01:31:54 I just changed my x11-image.bb recipe to http://pastebin.com/Z6RFAyr1 May 15 01:32:24 so it installs opencv and opencv-samples May 15 01:32:35 aditya_111: and I assume your distro is angstrom May 15 01:32:42 yes May 15 01:32:42 oh May 15 01:32:43 sorry May 15 01:32:46 yeah angstrom May 15 01:33:04 hmm... I guess you are going to say go ask in #angstrom.. May 15 01:33:09 no May 15 01:34:24 and you dont override ANGSTROM_EXTRA_INSTALL in local.conf May 15 01:35:15 I didn't? May 15 01:35:22 or are oyu saying I should have May 15 01:35:51 no I am just trying to find out what oyou have May 15 01:36:08 oh May 15 01:36:12 yeah I didn't touch local.conf May 15 01:36:27 I just changed x11-image May 15 01:37:59 did u also opencv-apps May 15 01:38:03 where do u get it from May 15 01:38:42 where do I get what? May 15 01:38:52 I basically saw some stuff related to opencv in the opkg list May 15 01:39:01 and tried to isntall stuff that seemed relevant May 15 01:39:15 remove opencv-apps May 15 01:39:28 and you can also add that stuff in local.conf May 15 01:39:35 if u want May 15 01:39:47 whats wrong wtin opencv-apps? May 15 01:39:54 also, how would that let smaples compile? May 15 01:39:56 ( curious ) May 15 01:41:07 I dont see anything that provides it May 15 01:41:15 it may not let samples compile May 15 01:41:31 ah May 15 01:42:12 shall try then May 15 01:44:11 I dont see any reason it should not have pulled opencv-samples May 15 01:56:43 well it downloaded em May 15 01:56:50 it made a samples folder in /usr/share/opencv May 15 01:56:54 except nohting in there is built May 15 01:57:01 it just has a bunch of sources and a buildall.sh May 15 01:57:13 except I dont really want to compile those things on the beagleboard May 15 01:57:28 I was hoping they would come compiled so I could just run them May 15 01:57:33 am I wrong to assume that? May 15 01:58:24 ( erm... that wasn't meant to be bitchy, just wondering ) May 15 02:17:16 meh May 15 02:17:24 same story May 15 02:17:32 I guess these dont come compiled May 15 02:22:38 been an openwrt user, new to oe, kind of disappointed that could not get dev compiled May 15 02:23:13 angstrom's 'stable 2009' also fails on lucid, sigh May 15 02:30:59 are you doing this in a VM? May 15 02:32:50 aditya_111, no, on a core2duo May 15 02:33:07 it seems lucid's gzip has issues May 15 02:53:09 xxiao: yes, on i386 see launchpad May 15 02:53:41 it was also discussed here few days back **** ENDING LOGGING AT Sat May 15 02:59:56 2010