**** BEGIN LOGGING AT Mon Feb 16 02:59:58 2009 Feb 16 05:57:29 03Khem Raj  07org.openembedded.dev * r30662dd03c 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Feb 16 05:57:34 03Khem Raj  07org.openembedded.dev * rdc3295c043 10openembedded.git/ (conf/checksums.ini packages/avahi/avahi_0.6.24.bb): avahi_0.6.24.bb: New recipe Feb 16 06:18:07 * * OE Bug 5027 has been created by nytowl(AT)openmoko.org Feb 16 06:18:09 * * fso-monitord fails to link Feb 16 06:18:11 * * http://bugs.openembedded.net/show_bug.cgi?id=5027 Feb 16 06:42:16 03Sergey Lapin  07ieee80215 * r4ce0c4e92e 10openembedded.git/packages/wireshark/ (files/ieee80215.4.patch wireshark_1.0.5.bb): wireshark_1.0.5: patch for IEEE80215.4 to have 'nofcs' dissector by default Feb 16 06:42:24 03Sergey Lapin  07ieee80215 * r7a7492dd6a 10openembedded.git/packages/lowpan-utils/lowpan-utils_git.bb: lowpan-utils: updated packaging to suit source changes Feb 16 06:48:07 * * OE Bug 4531 has been RESOLVED (WONTFIX) by raj.khem(AT)gmail.com Feb 16 06:48:08 * * avahi-0.6.22 link fails - rpl_realloc undefined Feb 16 06:48:11 * * http://bugs.openembedded.net/show_bug.cgi?id=4531 Feb 16 06:48:42 03Sergey Lapin  07org.openembedded.dev * rddbc21e0be 10openembedded.git/packages/lowpan-utils/lowpan-utils_git.bb: Feb 16 06:48:42 lowpan-utils: added (IEEE802.15 userspace) Feb 16 06:48:42 Signed-off-by: Sergey Lapin Feb 16 06:48:44 03Sergey Lapin  07org.openembedded.dev * r2f26a0f124 10openembedded.git/packages/lowpan-utils/lowpan-utils_git.bb: lowpan-utils: updated packaging to suit source changes Feb 16 06:48:46 03Sergey Lapin  07org.openembedded.dev * rbb404b2584 10openembedded.git/packages/lowpan-utils/lowpan-utils_git.bb: Feb 16 06:48:48 lowpan-utils: fixed binaries locations Feb 16 06:48:50 Signed-off-by: Sergey Lapin Feb 16 06:55:34 03Sergey Lapin  07org.openembedded.dev * r70e451dfe4 10openembedded.git/packages/wireshark/wireshark_1.0.5.bb: Feb 16 06:55:34 wireshark: added 1.0.5 Feb 16 06:55:34 Now both tshark and wireshark frontends are build in the Feb 16 06:55:34 same run. Packaging is more fine-grained. Feb 16 06:55:42 03Sergey Lapin  07org.openembedded.dev * rf9838ab72d 10openembedded.git/conf/checksums.ini: checksums.ini: added wireshark-1.0.5 Feb 16 06:55:42 03Sergey Lapin  07org.openembedded.dev * rb7489abba4 10openembedded.git/packages/wireshark/ (files/ieee80215.4.patch wireshark_1.0.5.bb): wireshark_1.0.5: patch for IEEE80215.4 to have 'nofcs' dissector by default Feb 16 06:55:50 03Sergey Lapin  07org.openembedded.dev * r76d26299ee 10openembedded.git/packages/wireshark/wireshark_1.0.5.bb: Feb 16 06:55:50 wireshark: ARM_INSTRUCTION_SET = "arm" due to relocation truncated to fit Feb 16 06:55:50 Signed-off-by: Sergey Lapin Feb 16 07:12:10 03Sergey Lapin  07org.openembedded.dev * r41be4c514c 10openembedded.git/ (conf/checksums.ini packages/libsmi/libsmi_0.4.8.bb): checksums.ini: added checksum for libsmi Feb 16 07:12:12 03Sergey Lapin  07org.openembedded.dev * rd7422627df 10openembedded.git/packages/net-snmp/net-snmp_svn.bb: net-snmp: added _svn version, has proper staging to work with tshark Feb 16 07:12:13 03Sergey Lapin  07org.openembedded.dev * r01aa3f5d36 10openembedded.git/packages/wireshark/ (tshark_0.99.4.bb wireshark.inc wireshark_0.99.4.bb): wireshark/tshark: extracted common parts Feb 16 07:12:14 03Sergey Lapin  07org.openembedded.dev * r8b12893071 10openembedded.git/packages/net-snmp/ (4 files): net-snmp_svn, net-snmp_5.1.2, net-snmp_5.4.1: extracted common parts Feb 16 07:12:24 03Dmitry Eremin-Solenikov  07org.openembedded.dev * rf17d189646 10openembedded.git/packages/wireshark/ (4 files in 2 dirs): Feb 16 07:12:24 wireshare: fix building with current toolchain Feb 16 07:12:24 Signed-off-by: Dmitry Eremin-Solenikov Feb 16 07:21:57 03Tom Rini  07org.openembedded.dev * r05ae151bd5 10openembedded.git/packages/gcc/gcc-common.inc: Feb 16 07:21:57 gcc-common.inc: In get_gcc_fpu_setting make sure we only do soft float for targets. Feb 16 07:21:57 When we build canadian toolchains (ie mingw-gcc-cross) we run this function, Feb 16 07:21:57 but we don't want it really it to so add a check on TARGET_OS=linux. Feb 16 07:21:57 Fixes building for TARGET_FPU=soft mipsel for example. Feb 16 07:34:38 morning Feb 16 07:36:31 Tartarus: what does your gcc commit do Feb 16 07:37:52 right now it will fails for linux-uclibc and linux-gnueabi and linux-gnu etc. etc. Feb 16 07:40:40 03Khem Raj  07org.openembedded.dev * r70c7efd81f 10openembedded.git/ (4 files in 3 dirs): yasr_0.6.9.bb: New recipe Feb 16 07:46:39 03Khem Raj  07org.openembedded.dev * rb447cbb012 10openembedded.git/ (conf/checksums.ini packages/evtest/evtest_1.23.bb): evtest_1.23.bb: New recipe Feb 16 08:11:05 * * OE Bug 4660 has been RESOLVED (FIXED) by raj.khem(AT)gmail.com Feb 16 08:11:07 * * Yasr bitbake recipe Feb 16 08:11:09 * * http://bugs.openembedded.net/show_bug.cgi?id=4660 Feb 16 08:11:17 * * OE Bug 4595 has been RESOLVED (FIXED) by raj.khem(AT)gmail.com Feb 16 08:11:19 * * new recipe - evtest-1.23 Feb 16 08:11:21 * * http://bugs.openembedded.net/show_bug.cgi?id=4595 Feb 16 08:11:30 * * OE Bug 4501 has been RESOLVED (FIXED) by raj.khem(AT)gmail.com Feb 16 08:11:31 * * compiling linux kernel with gcc 4.3.x Feb 16 08:11:34 * * http://bugs.openembedded.net/show_bug.cgi?id=4501 Feb 16 08:22:06 * * OE Bug 4087 has been RESOLVED (WONTFIX) by raj.khem(AT)gmail.com Feb 16 08:22:08 * * bluez-gnome_0.24.bb fails to build Feb 16 08:22:11 * * http://bugs.openembedded.net/show_bug.cgi?id=4087 Feb 16 08:53:23 morning Feb 16 08:55:31 hey hrw Feb 16 08:58:57 morning Feb 16 09:14:16 03Graeme Gregory  07org.openembedded.dev * r777cf05b0f 10openembedded.git/packages/xorg-driver/xf86-video-glamo_git.bb: xf86-video-glamo_git.bb : add bb file for glamo xorg git Feb 16 09:14:18 03Graeme Gregory  07org.openembedded.dev * rbbe2a6e40a 10openembedded.git/ (2 files in 2 dirs): Feb 16 09:14:18 xf86-video-glamo_git.bb : add this file to build the Xorg glamo driver written Feb 16 09:14:18 by OM community people. Can't make default just yet as requires changes Feb 16 09:14:19 to core Xorg server stuff. Feb 16 09:30:28 good morning Feb 16 09:34:45 good morning Feb 16 09:35:58 hi methril Feb 16 09:36:01 and other Feb 16 09:36:02 s Feb 16 09:48:38 flroian: get coffee :-) Feb 16 09:49:08 good morning Feb 16 09:49:22 XorA: what did i break?! ;) Feb 16 09:55:10 args Feb 16 09:57:34 XorA: Someone mentioned that you are fighting against libertas driver bugs too... Feb 16 09:58:24 libertas once more? Feb 16 09:58:45 XorA: or is it that wifi card which I gave you? Feb 16 09:59:15 florian: yes, oopses on firmware load Feb 16 09:59:17 hrw: yes Feb 16 09:59:33 hrw: I have a Samsung one here... which basically works... sometimes... Feb 16 10:00:29 XorA: It seems to work with an image built from stable branch using the same kernel. Feb 16 10:00:42 florian: I guess gcc differences then Feb 16 10:00:47 Only if you do not try to suspend of course ;) Feb 16 10:01:18 XorA: gcc and udev are my candidates here. Feb 16 10:01:44 well I guess no matter what bollocks udev does, the module shouldnt oops :-) Feb 16 10:02:24 yes indeed... Feb 16 10:02:36 in any way it is a driver bug Feb 16 10:03:43 XorA: Do you use the driver from Linux upstream or soem different source? Feb 16 10:04:20 florian: the one in the kernel Feb 16 10:11:59 * florian too... time to check if it misses important fixes Feb 16 10:23:30 in depends.dot generated by bitbake -g I have "kernel" -> "0: linux-2.6.24..." Is this "kernel" differs from "virtual/kernel"? Feb 16 10:28:35 hi! has anyone experience with bluecove java api and angstrom linux / jamvm ? Feb 16 11:32:33 03Koen Kooi  07org.openembedded.dev * r62043dda10 10openembedded.git/conf/machine/overo.conf: overo: add ubifs support Feb 16 11:32:37 03Koen Kooi  07org.openembedded.dev * rd221212741 10openembedded.git/packages/linux/ (3 files in 2 dirs): linux-omap 2.6.28: improve overo support Feb 16 12:01:55 03Michael 'Mickey' Lauer  07org.openembedded.dev * r52ff3239cc 10openembedded.git/packages/popt/ (5 files in 2 dirs): popt: clean up 1.7 Feb 16 12:02:07 03Michael 'Mickey' Lauer  07org.openembedded.dev * rdb0f992c9f 10openembedded.git/conf/bitbake.conf: Feb 16 12:02:07 bitbake.conf: override XDG_DATA_DIRS to point into our staging area; Feb 16 12:02:07 this fixes programs using g_get_system_data_dirs() picking up paths Feb 16 12:02:07 outside our safe and cozy environment. NOTE: _If_ this breaks some Feb 16 12:02:08 packages that were previously working, then we are missing something Feb 16 12:02:10 in do_stage of our native packages and we'd rather see it bailing out Feb 16 12:02:12 than silently pick up the wrong files. Think 'fail-fast' for glib. Feb 16 12:25:53 hello, what's the reason of cp ${STAGING_DATADIR_NATIVE}/automake*/install-sh ${S}/ in bzip2-full-native_1.0.5.bb, I've | cp: will not overwrite just-created `/home/embedded/oetmp_openmoko/work/i686-linux/bzip2-full-native-1.0.5-r0/bzip2-1.0.5/install-sh' with `/home/embedded/oetmp_openmoko/staging/i686-linux/usr/share/automake-1.9/install-sh' if I rm install-sh before the copy is it ok? Feb 16 12:33:42 i'll do that Feb 16 12:35:07 re Feb 16 13:07:27 i'll remove it...but I don't know what's the use of it Feb 16 13:08:47 NOTE: package bzip2-full-native-1.0.5-r0: task do_install: completed => I wonder if I should commit it...because it must have been there for a reason Feb 16 13:16:38 ask on ml? Feb 16 13:16:47 ok thanks Feb 16 13:17:13 (I asked here cause it was faster) Feb 16 13:36:58 XorA: ok, which kernel do you use? Feb 16 13:37:06 florian: 2.6.24 Feb 16 13:38:08 XorA: Looks like there were quite some changes since 2.6.26 (the one I use) at least. I'll try the latest one. Feb 16 13:38:39 florian: good plan, tosa doesnt compile in 2.6.28 yet Feb 16 13:39:34 XorA: Looks like I'll have some work to do here too. Unluckily this stupid card fits in the POS only. Feb 16 13:42:27 ~curse OM kernel breakage Feb 16 13:42:28 May the fleas of a thousand camels infest your most sensitive regions, OM kernel breakage ! Feb 16 13:51:53 can anyone build neon package? Feb 16 13:52:03 for me it complains: configure: error: GNU TLS version 2.4.2 is not supported Feb 16 13:52:25 ...can anyone build popt? it does not build here with "install: cannot stat `libpopt.a': No such file or directory"... Feb 16 13:52:43 :-) Feb 16 13:52:57 booxter: just checking neon ;) Feb 16 14:01:29 * hrw building neon now... Feb 16 14:03:29 hm, seems that neon expects 1.x gnutls, not 2.x one Feb 16 14:03:31 * broonie needs to work out how to build OE without the kernel. Feb 16 14:03:52 booxter: so you need newer neon Feb 16 14:04:01 broonie: you mean image? Feb 16 14:04:05 broonie: edit task-boot and remove "kernel" deps (or create your own task based on task-boot) Feb 16 14:05:23 hrw: yes Feb 16 14:06:19 hrw: ok, I'll try to compile 0.28.3 and if it works I'll send a patch... Feb 16 14:11:01 booxter: neon build here... Feb 16 14:11:58 ? Feb 16 14:12:40 emdete: what do you mean? Feb 16 14:17:34 ow I see there was some activity regarding neon 0.25.x problem on ML... Anyway I sent bumped version already. It works for new gnutls flawlessly Feb 16 14:25:44 I think that we should move to 0.28.x Feb 16 14:26:07 0.25.5 does not built here Feb 16 14:27:24 hrw: i sent it to ML Feb 16 14:27:43 keeping packages fresh is a good thing anyway Feb 16 14:33:05 hrw: seems I sent neon-0.28.3 with -r2 with no good reason to do it... Should I resend the patch for such problem? Feb 16 14:34:09 without PR="r2"? would be good Feb 16 14:34:46 ok Feb 16 14:55:12 why does om still require version 8.4.11 in conf/distro/include/preferred-om-2008-versions.inc for tcl/tk which isnt found as bb says? Feb 16 14:58:07 because noone updated it? :) Feb 16 14:58:16 may i? :D Feb 16 15:01:37 i cant speak for team openmoko or their stuff :) Feb 16 15:08:03 who can? :) Feb 16 15:08:14 mail to openmoko devel ml? Feb 16 15:13:25 anybody has recently tried building x86 with xorg-image, it seems broken Feb 16 15:14:40 alternatively I might ask: does exist a reliable graphical system for a x86+VESA system in OE? Feb 16 15:33:56 can you get an x86 oe built/ Feb 16 15:34:14 mine is all dookie with these strange random error messages Feb 16 16:28:54 anyone done any work with SmartCards on an oe-built dist? Feb 16 16:40:21 hi all Feb 16 16:40:25 trying to bitbake php and get the following error in my log file Feb 16 16:40:37 checking if the location of ZLIB install directory is defined... /home/paul/oe Feb 16 16:40:49 tmp/staging/i686-linux/usr/lib Feb 16 16:41:06 configure: error: Cannot find libz Feb 16 16:41:21 FATAL: oe_runconf failed Feb 16 16:41:39 If I look in the recipe I can find this reference to zlib Feb 16 16:41:57 --with-zlib --with-zlib-dir=${STAGING_LIBDIR}/.. \ Feb 16 16:42:13 I can see that php has zlib as a dependency Feb 16 16:42:28 what I don't understand is why it cannot find zlib Feb 16 16:42:44 any ideas, what am I missing? Feb 16 16:43:01 psykes: what about bitbaking zlib ? Feb 16 16:44:28 mckoan: from what I remember zlib builds fine, I'm just rying it again though Feb 16 16:50:38 psykes: do you have any zlib in tmp/staging ? Feb 16 16:53:29 hi! im trying to compile shr image. compilation fails with gcc-cross-4.1.2, with message: checking for library containing strerror... /bin/sh: line 17: 22231 Segmentation fault Feb 16 16:54:03 Linux 2.6.25-hardened-r11 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux Feb 16 16:54:13 psykes: ls /home/paul/oe/tmp/staging/i686-linux/usr/lib/libz* Feb 16 16:54:54 psykes: which distro/machine are you using there? Feb 16 16:55:37 also, your --with-zlib-dir=${STAGING_LIBDIR}/.. is looking 1 directory below ${STAGING_LIBDIR} Feb 16 16:56:02 yes libz is there Feb 16 16:56:35 clarify libz* is in /home/paul/oe/tmp/staging/i686-linux/usr/lib/libz* Feb 16 16:57:01 I'm running jeosubuntu on virtualbox Feb 16 16:57:27 if ${STAGING_LIBDIR}=home/paul/oe/tmp/staging/i686-linux/usr/lib/ then you are looking for it in the wrong place Feb 16 16:58:29 mickeyl: good morning Feb 16 16:58:42 morning pb_ Feb 16 17:00:09 mattface: can you please clarify? Feb 16 17:00:49 psykes: show values of MACHINE and DISTRO vars Feb 16 17:01:09 do what hrw asks first, he probably has an idea what's up Feb 16 17:02:46 DISTRO = "angstrom-2008.1" Feb 16 17:03:16 MACHINE = "beagleboard" Feb 16 17:08:32 koen in #beagle said I should poke timtimred in #oe as he has a fix for this, is poke an official IRC term as I'm new to this? Feb 16 17:08:33 :) Feb 16 17:14:19 timtimred is not here now Feb 16 17:15:25 Okay, I'll try later then Feb 16 17:39:36 mickeyl: you changed tiff to default version 3.8 but that bb wont be found by bb here... did you check that? also that bb looks strange: its named _3.8... but downloads 4.0 Feb 16 17:41:09 the bb is fine Feb 16 17:41:12 see PV Feb 16 17:41:24 the only strange thing is that it doesn't find it even though we PREFER it Feb 16 17:41:34 mickeyl: exactly Feb 16 17:41:35 removing DEFAULT_PREFERENCE helps though Feb 16 17:41:38 will commit that in a second Feb 16 17:41:46 it should work nonetheless, but doesn't for some reason Feb 16 17:41:54 didnt you check the commit you made a minute ago? Feb 16 17:42:27 of course i did Feb 16 17:42:38 and it did work fine using bitbake -b Feb 16 17:43:48 harhar Feb 16 17:44:13 :D Feb 16 17:50:59 its still not working here. Feb 16 17:51:05 muh me fix wha? Feb 16 17:54:18 PREFERRED_VERSION_tiff ?= "3.8.2" Feb 16 17:54:23 PV = "3.8.2+4.0.0beta2" Feb 16 17:54:27 never gonna work Feb 16 17:54:58 XorA: thank you. ;) Feb 16 17:55:09 koen spotted it Feb 16 17:55:20 koen: thank YOU! :D Feb 16 17:56:27 hmm... is there an updated tutorial for building OE? Feb 16 17:56:53 'cause none of my build environments are working anymore Feb 16 17:57:12 and i'm not sure if it's my machine or the build environment Feb 16 17:57:19 you mean, other than the wiki? Feb 16 18:02:21 OT: anyone knowing offhand the indent option to toggle whether function results are written in an extra line before the actual function name? Feb 16 18:04:43 mickey, yeah Feb 16 18:05:42 http://wiki.openembedded.net/index.php/Getting_Started errors out on me Feb 16 18:05:59 either due to too many files being open, or random compile issues Feb 16 18:06:18 too many files sounds like a problem with your system Feb 16 18:06:24 that can lead to compile issues Feb 16 18:06:28 running under a virtualized env? Feb 16 18:06:28 ahh Feb 16 18:06:31 nope Feb 16 18:06:35 ubuntu 8.10 Feb 16 18:06:49 should work, try asking on the list Feb 16 18:07:47 hmm Feb 16 18:07:54 Soopaman, dash versus bash? Feb 16 18:07:55 Soopaman, sec... Feb 16 18:08:36 So no? Feb 16 18:08:37 ga Feb 16 18:09:53 croft, i thought i fixed that Feb 16 18:10:00 tartus, pardon? Feb 16 18:10:21 http://pastebin.com/m4dcfcc0f Feb 16 18:10:32 try running that script Feb 16 18:10:36 then building Feb 16 18:10:42 it makes sure you have all the pkgs required Feb 16 18:11:55 mickeyl: ping Feb 16 18:12:01 k Feb 16 18:12:01 yo? Feb 16 18:12:19 got a minute? Feb 16 18:12:40 mickeyl: have you seen python 2.6.1 fail do_install? Feb 16 18:13:06 mickeyl: like this: http://tinderbox.openembedded.net/packages/370935/ Feb 16 18:15:07 tartarus, the script is running now, should I nuke my cache and build clean? Feb 16 18:15:39 denix: never seen that, try stripping the command line down to find the argument it doesn't understand Feb 16 18:16:33 Soopaman, yeah, can't hurt Feb 16 18:20:26 mickeyl: doesn't seem to like '-O' Feb 16 18:22:56 mickeyl: looks like 04-default-is-optimized.patch removes the -O option... Feb 16 18:24:11 mickeyl: while 01-use-proper-tools-for-cross-build.patch uses -O in several places Feb 16 18:25:11 04 is different for python-native and python Feb 16 18:25:23 we are calling the native version during the build Feb 16 18:25:42 so either your build is picking up the wrong 04 patch Feb 16 18:25:55 tartarus, so deleting the cache, staging and work directories from /OE/openembedded (as per wiki) should allow me to build clean Feb 16 18:25:56 or something else is horribly wrong Feb 16 18:26:06 do you have an overlay or fiddled with FILESPATH? Feb 16 18:26:15 or is there a better solution like a "bitbake clean" or something Feb 16 18:27:41 mickeyl: a very basic overlay - just a local.conf and own machine conf Feb 16 18:29:12 check the build of python-native Feb 16 18:29:18 whether the correct 04 patch gets applied or not Feb 16 18:29:56 mickeyl: ok, thanks. running python -h shows no -O support... will check sources Feb 16 18:30:38 Soopaman, well, rm -rf your tmp dir Feb 16 18:30:40 That'll do it Feb 16 18:31:08 k Feb 16 18:36:49 mickeyl: got it Feb 16 18:37:34 what's up with ffmpeg, fails when trying to fetch? Feb 16 18:38:17 mickeyl: it calls the native python binary, but sets LD_LIBRARY_PATH to my target location. since in this case target==host it runs the target version which has no -O support :) Feb 16 18:40:04 mickeyl: btw, I'm building for i686 now, hence the problem Feb 16 18:44:03 otavio, ping Feb 16 18:45:49 denix: oh! i see Feb 16 18:46:08 denix: if that becomes a burden, we can change 04 patch Feb 16 18:46:11 to just ignore a -O Feb 16 18:46:17 for the native version Feb 16 18:47:56 mickeyl: let me try that Feb 16 18:48:46 s/native/target/ Feb 16 18:48:48 ok Feb 16 19:21:00 re Feb 16 19:28:08 how come the meta-toolchain recipe doesn't copy contents of ${STAGING_DIR} to the toolchain? wouldn't you need all the same includes to be supported? Feb 16 19:29:53 Because you're looking at the recipe the other "real" SDKs include Feb 16 19:30:21 Crofton|work: hi Feb 16 19:30:47 hey Feb 16 19:30:57 otavio, did you setup patchwork? Feb 16 19:31:18 right, so the 'meta-toolchain' is minimal - I'm just curious what the correct way to enhance it is - I see the other toolchains include libs they need - but why wouldn't you just copy over STAGING_DIR instead as that has all the libs that were needed to build your image Feb 16 19:31:21 wondering if someone can answer a simple version problem with bitbake/oe Feb 16 19:31:22 Crofton|work: no; I setup it in an experimental image just to test it. Feb 16 19:31:29 Crofton|work: who did it was koen Feb 16 19:31:35 well, you are an expert then Feb 16 19:31:36 Crofton|work: I sent my image for him to look at Feb 16 19:31:46 Crofton|work: me? you must be kidding Feb 16 19:31:51 do you know much abuot setting up permissions" Feb 16 19:32:04 otavio, it is easy to be an expert around here :) Feb 16 19:32:10 Crofton|work: permissions for what? Feb 16 19:32:24 so people with accounts can change states etc Feb 16 19:32:33 Crofton|work: oh, let me take a look Feb 16 19:32:51 It would be nice if we could create groups Feb 16 19:37:47 tar has some pathname length limitations - so wouldn't it be better to use other archive mechanism in meta-toolchain.bb such as cpio, rpm, deb? Feb 16 19:38:31 tharvey, huh? Feb 16 19:38:54 tharvey, you don't use staging dir as you want something reproducible :) Feb 16 19:39:14 also packages let you upgrade your installed SDK Feb 16 19:39:41 Crofton|work: I've taken a look and I didn't find any place to setup groups Feb 16 19:40:02 Crofton|work: it looks like you can set it by users base, but you don't have a group setting Feb 16 19:40:09 hmm Feb 16 19:40:15 Crofton|work: we might try to contact the patchwork's author and ask him about it Feb 16 19:40:15 Tartarus, I think I understand - because staging will get populated with whatever you happened to build vs following a specified recipe? Feb 16 19:40:19 there is a rgeyed out groups thing Feb 16 19:40:30 Crofton|work: whre? Feb 16 19:40:31 yeah, the docs are not so good Feb 16 19:40:37 right Feb 16 19:41:46 03Steffen Sledz  07org.openembedded.dev * r3c0696527c 10openembedded.git/packages/ (neon/files/gnutls-2.patch popt/popt_1.7.bb): popt_1.7: SRC_URI changed Feb 16 19:42:32 Crofton|work: hehe, docs? About patchwork is looks more like you've smoke something :P Feb 16 19:43:20 hello Feb 16 19:44:05 If i want to change my bitbakes kernel config should i change the one in my tmp folder or somewhere else ? Feb 16 19:44:36 re Feb 16 19:45:07 * * OE Bug 5027 has been RESOLVED (FIXED) by Feb 16 19:45:09 * * fso-monitord fails to link Feb 16 19:45:11 * * http://bugs.openembedded.net/show_bug.cgi?id=5027 Feb 16 19:45:23 i think you should change the one in the packages folder Feb 16 19:46:14 Crofton|work: serious now; I belive it needs to have a setting for it Feb 16 19:46:15 but then again, i'm new to oe so i'm not sure :/ Feb 16 19:46:25 Crofton|work: but I failed to find it over there Feb 16 19:46:32 Ojg: I usually do change in tmp and then copy it to packages Feb 16 19:46:39 Crofton|work: but I somewhat remember something about it, just fail to remember where Feb 16 19:46:44 heh Feb 16 19:46:46 Crofton|work: maybe it is a setting Feb 16 19:48:22 hrw ok, something odd though is that my system is using the 2.6.25 kernel with some patches but in the linux-2.6.25 folder there is only patches :S where should i drop the config ? Feb 16 19:50:32 doesn't tar have a pathlen limit of something like 256? if thats the case isn't it a poor archive format for a toolchain? Feb 16 19:50:47 tharvey, don't think so... Feb 16 19:51:47 Ojg: strange Feb 16 19:51:57 Ojg: OE recipe or own? Feb 16 19:52:16 OE Feb 16 19:53:04 where is the OE kernel config usually located ? Feb 16 19:54:02 Tartarus, there is no limit on pathnames in gnu tar? there used to be... not sure if its still an issue Feb 16 19:55:25 tharvey: it can be Feb 16 19:59:56 tharvey: old bsd tar and ustar have max filename = 100 chars, max pathname (dirname + filename) = 250 chars Feb 16 20:00:52 (according to man 1 pax) Feb 16 20:00:58 right, thats what I was reading Feb 16 20:01:51 hello, in the workdir i've automake-native-1.10-r1 but popt-1.7.0 says: | automake (GNU automake) 1.6.3 why? mabe it's the cause of the faillure(http://rafb.net/p/YXqkpW32.html) Feb 16 20:01:54 I'm supplying a toolchain and being told that tar is an unacceptable archive format for it - just wondering if thats something from the past that is no longer pertinent - if it was such an issue I would think that meta-toolchain.bb would use something else like cpio Feb 16 20:02:30 pax, cpio, 7z :) Feb 16 20:02:31 tharvey, that sounds weird Feb 16 20:03:11 tharvey: but gnu-tar can have other limits Feb 16 20:03:28 simplest way is to check this Feb 16 20:04:28 have a nice rest of day Feb 16 20:11:53 what arguments do i give bitbake to just rebuild the kernel ? Feb 16 20:14:56 nvm Feb 16 20:15:22 typically 'bitbake -crebuild virtual/kernel' Feb 16 20:20:32 hehe k thats not what i did told it to clean the .bb file then build it again :S Feb 16 20:22:45 well virtual/kernel is a virtual package which will evaluate to the kernel recipe for your setup Feb 16 20:23:09 if you want, you can operate directly on the bb if you specify 'bitbake -crebuild -b myspecifickernel.bb' Feb 16 20:26:10 ok, ty Feb 16 20:39:53 I think i'll do a which inside the scripts Feb 16 20:40:18 tharvey: tar did have a 256-character filename limit in olden days, but there is no limit in modern versions. Feb 16 20:40:36 the new format was standardised in POSIX.1-2001. Feb 16 20:41:33 (also, GNU tar has had its own extended format for a while, which also has no filename limit.) Feb 16 20:42:18 pb_, thanks for the info! do you know what versions of GNU tar started implementing that? Feb 16 20:44:35 tharvey: posix-2001 support was added in gnu tar 1.14 (released in 2004). I'm not sure when the original gnu extended format(s) were introduced but it was a long time ago. Feb 16 20:44:39 hm.. what license should be applied to source examples placed on wikipedia? Feb 16 20:45:27 thx... that should ease some minds Feb 16 20:45:48 I wan't take code example from there and use it in project under GPL Feb 16 20:47:32 fwiw, the manual suggests that the "new" gnu format was introduced somewhere around version 1.13, which was released in 1999. the "old" gnu format, which also supported unlimited filename lengths, was in older versions but the version history is a bit patchy before that point. Feb 16 20:47:51 the oldest version with any non-trivial mention in NEWS is 1.10 (July 1991) Feb 16 20:48:24 heh Feb 16 20:48:28 ancient Feb 16 20:49:03 yeah, it seems pretty unlikely anybody is still running a production system with those versions. Feb 16 20:49:56 I don't think I was even using linux in 1991. Feb 16 20:49:57 heh Feb 16 20:50:06 heh... I work with some unix oldies apparently Feb 16 20:50:22 it seems :-) Feb 16 20:50:46 someone probably got burnt on some old solaris or aix system and won't ever forget it... probably refuse to use tar since then :P Feb 16 20:51:17 yeah, very likely. Feb 16 20:51:40 I wouldn't be surprised if the standard tar that ships with solaris did have a 256-char limit until very recently, or maybe even still does Feb 16 20:52:17 a lot of the standard solaris utilities are quite spartan if you are used to the gnu versions. Feb 16 21:01:57 in 2000 I already found is spartan Feb 16 21:05:38 anyone know if qemu still needs patching to support framebuffer ? Feb 16 21:13:01 hello, there is configure.in --aclocal--->aclocal.m4 inside the autoreconf process...but it fails...mabe because aclocal that is part of automake is too old: Feb 16 21:13:42 there is : automake (GNU automake) 1.6.3 Feb 16 21:14:05 * * OE Bug 5028 has been created by nytowl(AT)openmoko.org Feb 16 21:14:07 * * fso-image fails on do_rootfs install gst-plugin-sid Feb 16 21:14:09 * * http://bugs.openembedded.net/show_bug.cgi?id=5028 Feb 16 21:15:18 so not the one that is in work(that is /home/embedded/oetmp/work/i686-linux/automake-native-1.10-r1) Feb 16 21:15:53 and automake lives inside: /usr/bin/automake which is strange....(I did a which inside the temp scripts) Feb 16 21:17:01 is there still someone in this channel? Feb 16 21:23:19 hmm who was talking to timtimwork earlier? i cant see from here. ahh well. Feb 16 21:23:41 10:08 koen in #beagle said I should poke timtimred in #oe as he has a fix for this, is Feb 16 21:23:42 poke an official IRC term as I'm new to this? Feb 16 21:23:48 * timtimred returns to digging an escape tunnel Feb 16 21:24:17 thx Tartarus... Feb 16 21:24:24 hmm hes not here :) Feb 16 21:25:04 poke is a facepoke thing. oops. book. Feb 16 21:25:06 facebook. Feb 16 21:25:12 :) Feb 16 21:25:43 hmm, who here is in the OE facebook group... Feb 16 21:25:46 * timtimred noses Feb 16 21:27:35 anyone have any good refs for a script that will setup a CF/SD card with linux suiteable for modifying to install an OE built dist - perhaps there is already something in OE somewhere Feb 16 21:28:02 I've written something in the past but its old, clunky, and narrowminded Feb 16 21:28:59 Er Feb 16 21:29:18 A CF/SD linux distro you can poke around with OE on? Feb 16 21:29:30 Anything that'll stick modern Ubuntu on one will do Feb 16 21:29:42 other distros too i bet, but i'm an ubuntu guy for doing OE stuff Feb 16 21:29:51 right... any suggestions? Feb 16 21:30:05 kbuntu? Feb 16 21:30:12 or whatever that is that fits on a cd, etc Feb 16 21:30:39 maybe a usb one would do... Feb 16 21:30:51 yeah, same idea Feb 16 21:30:52 if you can do that Feb 16 21:31:02 just a usb stick i mean Feb 16 21:31:05 yes, same concept Feb 16 21:31:07 mmm...libtool...i'll add the correct things that are in /usr/share/aclocal from the i686 staging dir inside the source dir Feb 16 21:31:22 s/source dir/correct m4 file Feb 16 21:32:20 ok. here goes with the stupid newby question of the day. If I had a device with very similar hardware to the simpad where/what would be the best things to do that would start me on the way to getting a kernel working on it. Happy to be pointed to any guides/faq's etc. and before asking I have been searching long and hard to see where to start. thanks Feb 16 21:32:27 i'll look if inheriting libtool can solve the problem Feb 16 21:37:04 what controls the install status of a package listed in usr/lib/ipkg/status? Feb 16 21:37:38 i.e. I have some scripts where the postinst doesn't get run on a new image install b/c status is installed, not unpacked Feb 16 21:38:13 the rc.d scripts are getting added, but not the other commands in the postinst... Feb 16 21:40:28 what people use besides standard "diff" to make patches outside of git tree? Feb 16 21:45:08 denix: is diff not enough? :) Feb 16 21:47:48 Jay7: and what tool produces the "Index:" line? Feb 16 21:49:04 denix: cvs, generally, but that line is just noise. Feb 16 21:49:16 neither patch nor any other diff-processing program I can think of actually needs it. Feb 16 21:49:37 really Feb 16 21:50:11 tstrat: see rootfs_deb.bbclass, search for 'unpacked' Feb 16 21:50:23 pb__: rcs too, maybe svn. but anything out of the tree? Feb 16 21:51:05 tstrat: oh, actually, for ipkg, better see rootfs_ipk.bbclass Feb 16 21:51:06 pb__: or rather what is the standard way to add a comment to the patch? Feb 16 21:51:07 same applies though Feb 16 21:51:34 denix: there's no real standard. generally you can just put comments as free-form text before the patch itself. Feb 16 21:51:45 pb__: thanks, that gives me a starting point I'll see what I can do Feb 16 21:51:53 "patch" will skip any leading garbage that it doesn't understand, i.e. anything prior to the --- line. Feb 16 21:52:05 Crofton: there? Feb 16 21:52:37 mr-mac: are you talking about building a kernel, or about installing your already-built kernel onto the device, or something else? Feb 16 21:52:59 pb__: I see, thanks Feb 16 21:53:21 yeah Feb 16 21:53:31 Crofton: It looks it has it into the code Feb 16 21:53:38 Crofton: but I fail to see it into admin page Feb 16 21:53:57 denix: look at org.openembedded.dev/packages/fvwm/files/oe-configure.ac.patch Feb 16 21:54:14 GRANT SELECT, UPDATE, INSERT, DELETE ON auth_group_permissions TO 'www-data'@localhost; Feb 16 21:54:17 GRANT SELECT, UPDATE, INSERT, DELETE ON auth_user TO 'www-data'@localhost; Feb 16 21:54:20 GRANT SELECT, UPDATE, INSERT, DELETE ON auth_user_groups TO 'www-data'@localhost; Feb 16 21:54:22 GRANT SELECT, UPDATE, INSERT, DELETE ON auth_group TO 'www-data'@localhost; Feb 16 21:54:23 denix: I just have added that comments at top of file by hands Feb 16 21:55:23 pb___ probs building a kernel. I am new to this but a lot of hardware is shared with simpad (which has builds in openembedded) but not sure what hardware specific stuff may be in there like memory and port addresses that I would need to find out to build a specific kernel for my device. Feb 16 21:55:40 hello, i've some breakage with libtool: popt doesn't look inside ~/oetmp/staging/i686-linux/usr/share/aclocal Feb 16 21:55:51 mr-mac: if your device is also sa1100 based then 90% of your memory addresses are constrained by the SoC architecture Feb 16 21:56:26 Crofton: I found it Feb 16 21:56:31 yeah it is SA1100 has MQ200 gpu Feb 16 21:56:58 mr-mac: the bigger issue is probably going to be gpio assignments. you need to audit what the code is doing with each pin to make sure you don't introduce any conflicts. Feb 16 21:57:41 for memory addresses and the like you can generally take a "suck it and see" approach, just boot the simpad kernel and fix things as you find they're broken, but for i/o pins that is not really advisable. Feb 16 21:57:43 Jay7: yeah, I know. I've seen different variants - some with "Index:" line added, some prefixing comments with "#"-sign etc. I was not sure which one is more standard and was looking for a tool... Feb 16 21:58:32 Crofton: wel;; somewhat Feb 16 21:58:51 I tried booting a simpad kernel and it detected MQ200 changed to colour framebuffer, set a cople of SA serial interfaces then stopped with a memory read timeout. Feb 16 21:58:52 Crofton: I found where to allow someone to add groups but not where to add the group Feb 16 21:59:21 though not sure if it was kernel or not as i was booting with haret Feb 16 22:00:30 I will maybe try and speak to mr_nice at some point as he did a lot of the simpad work. See if he wants a challenge as I have a spare device. Feb 16 22:00:54 Jay7: like one of mickey's patches at /packages/python/python-2.6.1/ for example... Feb 16 22:03:00 other issue as there doesn't seem to be many simpad kernels in bin format just jffs2 images so could only fine one to try but not sure if it is stable. LOL Feb 16 22:03:10 denix: well, just write text as you wish before first '---' line :) Feb 16 22:03:30 Jay7: yeah, I got it :) thanks Feb 16 22:04:04 ah ok it looks into the armv4 dir for the m4 macros: -I /home/embedded/oetmp_openmoko/work/armv4t-angstrom-linux-gnueabi/popt-1.7-r0/popt-1.7/m4/ -I/home/embedded/oetmp_openmoko/staging/armv4t-angstrom-linux-gnueabi/usr/share/aclocal-1.6 -I /home/embedded/oetmp_openmoko/staging/armv4t-angstrom-linux-gnueabi/usr/share/aclocal Feb 16 22:04:41 how do I install the right libtool m4 inside it? Feb 16 22:06:36 hello, does someone knows well libtool? Feb 16 22:12:02 from where ltmain.sh is copied? Feb 16 22:13:02 mickey|dinner: bon appetit, are you back? Feb 16 22:21:37 ~curse OM kernel for not working in Angstrom Feb 16 22:21:38 May you be reincarnated as a Windows XP administrator, OM kernel for not working in Angstrom ! Feb 16 22:22:55 mickey|dinner: the tree parsing is broken, since you forgot to commit the fso-image.inc Feb 16 22:28:16 pb__: thx that did it... the problem was in my bb... real help was image log.do_rootfs Feb 16 22:38:05 hello, I've theses files inside my staging native dir: argz.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4 but not in my staging armv4 dir...which package should I bitbake to get them? Feb 16 22:38:14 it's libtool related Feb 16 22:41:18 Gnutoo: why do you need them ? Feb 16 22:41:28 khem`, for popt Feb 16 22:42:24 khem, more precisely: http://rafb.net/p/B7PDGC32.html Feb 16 22:43:48 Gnutoo: you need gnulib Feb 16 22:43:57 khem`, thanks a lot Feb 16 22:45:40 morning Feb 16 22:46:07 Gnutoo: hmmm do you have m4 installed Feb 16 22:46:08 khem`, in which bb is it? Feb 16 22:46:10 rwhitby: gm Feb 16 22:46:18 Gnutoo: let me have a look Feb 16 22:46:30 rwhitby: you in oz ? Feb 16 22:47:11 khem`, thanks a lot Feb 16 22:48:10 khem`, by the way if I copy theses m4 files it passes this but fails after with a ltmain.sh version mismatch Feb 16 22:48:20 copied from i686 Feb 16 22:48:52 yeah I think you need these macros in the package Feb 16 22:50:30 khem`, ok so what bb gives me theses macros in the arm staging dir? Feb 16 22:53:09 Gnutoo: it should be done by libtool AFAICT Feb 16 22:53:49 khem, so i bitbake libtool-something and it will work? Feb 16 22:53:52 Gnutoo: what version of libtools do you have in both places Feb 16 22:54:00 or you mean libtoolize sohuld copy them? Feb 16 22:54:41 ideally it should but you might be having different version on native staging and armv4 staging Feb 16 22:55:07 Gnutoo: try to bitbake libtool_2.2.4.bb Feb 16 22:55:09 libtool-cross-2.2.4-r23 in arm workdir Feb 16 22:55:35 and libtool-native-2.2.4-r20 in i686 work Feb 16 22:55:43 ok thanks Feb 16 22:55:46 ok Feb 16 22:57:41 pb__: around ? Feb 16 22:59:00 pb__: I am able to build locale using cross localedef now I want to hook that into the recipe so that it can be packaged. If you could explain this process it would help me quickly Feb 16 22:59:14 finding the issues Feb 16 22:59:21 ~/oetmp/staging/armv4t-angstrom-linux-gnueabi/usr/share $ find ./aclocal* | grep lt => ./aclocal/ltdl.m4 Feb 16 23:00:24 Ok Feb 16 23:01:32 khem, I installed libtool and it gave me that ^^^^ Feb 16 23:01:48 Gnutoo: hmmm **** ENDING LOGGING AT Mon Feb 16 23:03:53 2009 **** BEGIN LOGGING AT Mon Feb 16 23:04:14 2009 **** ENDING LOGGING AT Mon Feb 16 23:05:49 2009 **** BEGIN LOGGING AT Mon Feb 16 23:06:11 2009 Feb 16 23:06:30 khem`, i'll modify the recipe to stage theses files because they are present in the package: http://rafb.net/p/sBwwT917.html Feb 16 23:06:51 they should be packaged Feb 16 23:06:59 err staged Feb 16 23:09:09 Crofton: I got a reply from the upstream and they provided the required information for us; I mailed it to ml; take a look at it later Feb 16 23:10:59 otavio, thanks. I'm juggling several things atm Feb 16 23:11:08 I hate the OMAP3 pinmux right now :) Feb 16 23:11:37 Crofton|work: hehe Feb 16 23:11:38 khem`, ok so I modify the libtool_2.2.4.bb (and not the libtool-cross-2.2.4-r23 version) to stage it...thanks a lot Feb 16 23:11:56 Crofton|work: Do you have time to look at LX video issues with me later this week? Feb 16 23:12:20 i'll commit that tomorrow thanks Feb 16 23:12:25 Crofton|work: oops it is not you; forget ;-) Feb 16 23:13:06 Gnutoo: get rid of do_stage function and rebitbake it Feb 16 23:14:22 ok it's easier like this thanks Feb 16 23:14:34 thats just for experiment Feb 16 23:14:41 It may not work Feb 16 23:16:20 khem`, doesn't work Feb 16 23:17:37 Gnutoo: then add the install commands Feb 16 23:17:42 ok Feb 16 23:17:47 to do_stage Feb 16 23:17:53 that 's what I was doing Feb 16 23:20:05 khem`, I bet for x in something isn't valid in a bb Feb 16 23:20:30 (without using python) Feb 16 23:24:17 khem`, if you don't mind i'll finish this tommorow as it is late here Feb 16 23:24:45 aarg Feb 16 23:25:02 is there a place I can paste my "too many open files" error? Feb 16 23:25:53 khem`, and thanks a lot Feb 16 23:27:27 Soopaman1: http://paste.lisp.org/new/oe Feb 16 23:28:46 ~paste Feb 16 23:28:47 extra, extra, read all about it, paste is http://rafb.net/paste/, or see also pb, or http://bin.cakephp.org/ Feb 16 23:47:34 Soopaman pasted "Ubuntu 8.10 + Open Embedded Build Errors" at http://paste.lisp.org/display/75610 Feb 16 23:50:10 any thoughts/ideas? Feb 16 23:55:03 Soopaman1: what does cat /proc/sys/fs/file-max Feb 16 23:55:09 say on your host Feb 16 23:55:37 digital@evolve:/OE$ cat /proc/sys/fs/file-max Feb 16 23:55:37 100294 Feb 16 23:56:58 set it to 200000 Feb 16 23:57:53 by doing "echo 200000 > ..." ? Feb 16 23:58:05 you can also edit /etc/sysctl.conf Feb 16 23:58:17 fs.file-max Feb 16 23:58:32 change it to 200000 Feb 16 23:59:41 k thanks, retrying now Feb 16 23:59:45 Soopaman1: what distro do you have on host Feb 16 23:59:56 ubuntu 8.10 Feb 17 00:00:16 hmmm I do not have such problem on same Feb 17 00:00:21 host Feb 17 00:00:38 is yours an upgrade, or a clean install? Feb 17 00:00:56 clean install Feb 17 00:01:05 strange, same here Feb 17 00:02:10 and your file-max value was 200000? Feb 17 00:02:33 its more than you Feb 17 00:02:49 its around ~200000 Feb 17 00:02:59 can you show your local.conf Feb 17 00:03:39 it could be that some tool is going into infinite loop Feb 17 00:03:51 and spawning too many handles Feb 17 00:04:12 anything in particular? Feb 17 00:04:27 could PARALLEL_MAKE = "-j4" be the issue? Feb 17 00:05:58 same issue Feb 17 00:06:06 even though max-file is 200k Feb 17 00:06:13 file-max* Feb 17 00:06:43 ASSUME_PROVIDED += " virtual/java-native" Feb 17 00:06:50 in ur local.conf Feb 17 00:07:16 add that? Feb 17 00:09:36 yeah but you should paste yours somewhere so I can take a look at it Feb 17 00:15:04 Soopaman annotated #75610 "local.conf" at http://paste.lisp.org/display/75610#1 Feb 17 00:15:11 pasted Feb 17 00:18:31 Soopaman1: Try with the line I suggested Feb 17 00:18:37 mine looks same as you Feb 17 01:23:16 03Michael 'Mickey' Lauer  07org.openembedded.dev * r2c476f827e 10openembedded.git/ (2 files in 2 dirs): libgsm0710: 1.0.0 -> 1.1.0 Feb 17 01:23:38 03Michael 'Mickey' Lauer  07org.openembedded.dev * r8ee631d48d 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs.inc: bump fso-abyss Feb 17 01:25:00 03John Willis  07org.openembedded.dev * r3448dfee01 10openembedded.git/packages/powervr-drivers/ (libgles-omap3/rc.pvr libgles-omap3_3.00.00.06.bb): Feb 17 01:25:00 libgles-omap3: make /dev/pvrsrvkm accessible by non ROOT users. Feb 17 01:25:00 * Tested by running several OGLES apps on the Pandora as a normal user, should Feb 17 01:25:02 also be fine on the Beagle/Overo/OMAP3EVM etc. Feb 17 01:25:04 Signed-off-by: David-John Willis Feb 17 01:25:30 mickey|dinner did you add fso-image.inc? Feb 17 01:30:09 03Michael 'Mickey' Lauer  07org.openembedded.dev * r8e15363840 10openembedded.git/packages/python/python-native-2.5.1/ (6 files): python-native-2.5.1: remove forgotten dir Feb 17 01:30:59 huh, 5 hours later? Feb 17 01:32:05 I guess mickey never got back from dinner... :) Feb 17 01:32:47 denix0: he sleeps for weeks & does sports for days... mickey|dinner is special in that kind of stuff - a little sticky to state i think Feb 17 01:33:14 03Michael 'Mickey' Lauer  07org.openembedded.dev * r0faeb36abf 10openembedded.git/conf/distro/include/preferred-om-2008-versions.inc: preferred-om-2008-versions.inc: bump vala and libtiff Feb 17 01:33:39 emdete: :) Feb 17 01:34:56 anyway someone that mentioned fso-image-light.bb seems to be right - mickey didn't add it... Feb 17 01:35:33 in oe nobody seems to test any commit ;) Feb 17 01:35:42 no, it was fso-image.inc Feb 17 01:36:01 okay than that is missing too Feb 17 01:36:29 ah, misread the error, you are right Feb 17 01:36:32 fso-image-light.bb is not missing Feb 17 01:36:42 yes, ... its too late Feb 17 01:36:48 just bunch of them require fso-image.inc, which is missing Feb 17 01:37:10 03Michael 'Mickey' Lauer  07org.openembedded.dev * r7a45ec8d68 10openembedded.git/packages/libtiff/tiff_3.8.2.bb: tiff 3.8.2: use autotools_stage, make default Feb 17 01:37:16 anyway, have to wait :) Feb 17 01:37:48 denix0: i wait since days to build again with oe... Feb 17 01:37:50 and commit bot is still going through checkins made several hours ago... :) Feb 17 01:38:18 denix0: commit-bot? whats that? Feb 17 01:38:39 do you see CIA-2 announcements? Feb 17 01:39:00 yes, so its just the anounce here, the commit is in git since hour...? Feb 17 01:39:07 s/hour/hours/ Feb 17 01:39:43 I meant commit bot - bot that announces commits :) Feb 17 01:40:01 03Michael 'Mickey' Lauer  07org.openembedded.dev * r2c54593ef9 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs.inc: bump fso-monitord Feb 17 01:40:03 yes, okay, so i have that stuff already but its not complete Feb 17 01:40:07 yes, actual commits happened hours ago - that's what I mean :) Feb 17 01:40:42 03Michael 'Mickey' Lauer  07org.openembedded.dev * rcfe81d5c2a 10openembedded.git/ (2 files in 2 dirs): fso-monitord: bump for 0.2.0 Feb 17 01:40:51 i'm quite unshure because i always can't believe that oe so often is broken and that people commit stuff without testing... Feb 17 01:41:45 03Michael 'Mickey' Lauer  07org.openembedded.dev * r9924d91be0 10openembedded.git/packages/images/ (7 files): fso-images: add fso-paroli-image; refactor fso-image into .inc; add fso-zhone-image Feb 17 01:42:08 and here we go - finally the commit which broke the tree... ;) Feb 17 01:42:25 refactor fso-image into .inc Feb 17 01:42:34 but no actual .inc Feb 17 01:43:17 denix0: who is fixing missing .inc then? Feb 17 01:43:17 wasnt a commit be ment as a maybe unstable but working & tested state in history? ...hm Feb 17 01:45:35 this kind of breakage doesn't happen very often. I guess mickey wasn't paying attention and forgot to commit that file... so it worked for him :) Feb 17 01:46:14 denix0: yes, /this/ kind, shure, but there are alot of other kinds. in fact oe is broken for me sionce weeks Feb 17 01:46:44 03Koen Kooi  07org.openembedded.dev * r57ef038f49 10openembedded.git/packages/boost/ (boost-36.inc boost_1.36.0.bb): boost 1.36: ARM_INSTRUCTION_SET = "arm" Feb 17 01:46:53 denix0: tiff does not build because a wrong version was refered - never tested when switched Feb 17 01:47:02 denix0: pck-config didnt build... Feb 17 01:47:03 usually some specific recipes may be broken, but not the parsing of the whole tree, like now Feb 17 01:47:06 denix0: and so on and on Feb 17 01:47:35 03Tim 'timtim' Ellis  07org.openembedded.dev * rb6771d35fa 10openembedded.git/ (conf/checksums.ini packages/amule/amule_2.1.3.bb): amule: Fix linking issue and add checksums Feb 17 01:47:36 denix0: okay, this is just a bigger problem but in the end: i cant build. Feb 17 01:47:52 Tartarus: did u look at my message from yesterday about your commit to gcc Feb 17 01:48:15 I think your patch is incomplete did you test it on arm and/or uclibc Feb 17 01:48:35 03Denys Dmytriyenko  07org.openembedded.dev * rab6ba81211 10openembedded.git/packages/python/ (2 files in 2 dirs): python-2.6.1: add back empty -O flag to fix weird host==target binary mixing Feb 17 01:48:41 khem`, hmm Feb 17 01:48:42 denix0: i think oe need more qa. reliability, testing, ... Feb 17 01:48:47 uclibc should be fine Feb 17 01:48:47 03Tom Rini  07org.openembedded.dev * r957e3d34d2 10openembedded.git/packages/gcc/ (gcc-canadian-sdk_4.2.4.bb gcc-configure-canadian-sdk.inc): Feb 17 01:48:47 gcc-canadian-sdk: Fix a problem where we were passing the wrong headers and such as the target ones. Feb 17 01:48:47 We were accidentially using (and shipping) mingw headers instead of the target ones. Feb 17 01:49:27 khem`, go ahead and take a stab at fixing it up tho :) Feb 17 01:50:10 emdete: there are many variables involved. some distros/packages are built nightly by autobuilders. I would guess tiff is part of Angstrom autobuild... Feb 17 01:50:47 denix0: at least the commiters should test their stuff better... Feb 17 01:52:04 03Khem Raj  07org.openembedded.dev * r60719a8b47 10openembedded.git/ (3 files in 2 dirs): Feb 17 01:52:04 gnuchess_5.021: New recipe Feb 17 01:52:04 fltk-chess_0.51.bb: New recipe Feb 17 01:52:33 emdete: as far as I can see, no problems with tiff - http://tinderbox.openembedded.net/packages/tiff/ Feb 17 01:53:03 emdete: which version of tiff you have problems with? Feb 17 01:54:46 denix0: see git log... Feb 17 01:55:10 khem`, I suppose we might need to put all the linux variants in the test Feb 17 01:55:18 Know if there's any easier way?? Feb 17 01:55:34 denix0: for om it was pinned to version 3.7. and moved to 3.8 which was no-existing. this was never tested Feb 17 01:55:46 denix0: same game with pkg-config last days Feb 17 01:56:21 denix0: and in result i cant build since a long time now because there is always a package in the chain that is not buildable Feb 17 01:58:26 Ah ha Feb 17 01:58:39 for om it was changed from 3.7.2 to 3.8.2. why is 3.8.2 non existing? Feb 17 01:59:36 denix0: i dont know - it doesnt ;) bb does not find it :D its version 3.8.2+4.0.0beta2 because PV is pinned in the .bb Feb 17 02:00:01 emdete: plus you can always fix it for yourself, at least temporarily. why not change preferred version back to 3.7.2 in your build? Feb 17 02:00:10 khem`, pushing an update soon Feb 17 02:00:12 testing now Feb 17 02:00:14 denix0: and especially ugly: it doesnt download 3.8 at all - its 4.0 beta Feb 17 02:00:32 denix0: bacuase that didn't build at all Feb 17 02:00:42 denix0: it broke with plg-config Feb 17 02:00:53 denix0: that was the cause for the switch to 3.8... Feb 17 02:01:15 denix0: shure i can start fixing all this but its lost work because nobody at oe will use it Feb 17 02:01:55 emdete: that's the way versioning works in oe - you cannot call it 4.0.0beta, as it will be greater than 4.0.0. it has to be 3.9.9+4.0.0beta2 or something Feb 17 02:01:56 denix0: do you have an idea to prevent problems like this? Feb 17 02:03:04 denix0: anyway, that wasnt the problem at that point. problem was the commit was non-wokring Feb 17 02:04:43 emdete: oe is very fragile, as it is very complex... :) all I can say at this point. I understand the frustration. Feb 17 02:05:28 emdete: it is what's called a "steep learning curve" :) Feb 17 02:05:31 03Tom Rini  07org.openembedded.dev * r759542d7c9 10openembedded.git/packages/gcc/gcc-common.inc: gcc-common.inc: Make my last change to fpu check catch all linux variants Feb 17 02:05:34 oe is poorly coordinated; it has grown too large and now has too many independent committers that do not/can not test the important interactions. Feb 17 02:05:54 denix0: i would like to help but the oe team seems to be not interested in the packages i like... ;) Feb 17 02:06:35 It also suffers from the fact that NOBODY builds from an empty tmpdir as a matter of course, so some problems remain latent for weeks until one of the core developers finds the problem, and fixes it. Meanwhile, the lesser gods and the mere mortals using OE suffer. Feb 17 02:06:48 denix0: so if i talk about a build problem, nobody takes it and is intested in fixing it or get hints from someone how to fix that... that is the really cause for frustration Feb 17 02:06:51 hey now, I build from empty tmpdirs all the time :) Feb 17 02:07:35 mwester-laptop: exactly - so its even more important to listen to people that just started with an empty dir.... right? Feb 17 02:07:37 Then you know about the libtool/pkgconfig conflict, I presume. Feb 17 02:07:39 emdete: well, its hard for others to share the same priorities you do. you'd probably get better results in trying to learn to fix them yourself :) Feb 17 02:07:50 I also do build from empty tmp dir Feb 17 02:08:00 mwester-laptop: yes, that was one of the pitfalls in the last time Feb 17 02:08:04 emdete: I think the autobuilders all need to clean out the tmpdir every other day. Feb 17 02:08:08 mwester-laptop, what versions? Feb 17 02:08:24 kergoth: shure - but: as i said obove Feb 17 02:08:24 Tartarus: I'm in a hotel room; lack my notes and access to my home systems for that info. Feb 17 02:08:33 k Feb 17 02:08:37 Hi , why it is always fail to use git pull --rebase to update oe tree? I'm under suse11 and with all firewall closed Feb 17 02:08:50 kergoth: i like to fix that but if its not going into oe its useless work. and thats what i hate most Feb 17 02:08:54 mwester-laptop, I'm locked down on 0.23/2.2.4 Feb 17 02:08:59 so maybe thats why i haven't seen it Feb 17 02:09:29 emdete: sounds like a process problem. if our tools aren't such that input like that is quickly reviewed and processed, there's a problem Feb 17 02:09:34 Tartarus: Someone bumped up from 1.5.10 to 2.2.4 for FSO/Openmoko, that triggered the problem. Feb 17 02:09:58 hmm, odd Feb 17 02:10:08 i haven't done heavy testing outside of MIPS yet, perhaps thats my problem Feb 17 02:10:20 kergoth: i have the feeling its a question of culture. oe seems to me as a quite closed group not interested much in hints from outside Feb 17 02:10:29 But specific versions aside (that may even have been fixed in teh past 24 hours, I do not know), emdete has a legitimate concern. Feb 17 02:10:45 not at all. there are many organizations using oe and pushing changes upstream Feb 17 02:11:02 emdete: not true. you have to push/babysit your fixes to get them commited Feb 17 02:11:05 And what is surprising is that emdete uses the One True Distro, and *still* encounters trouble. Feb 17 02:11:18 denix0: how Feb 17 02:11:38 emdete, bitch on the ML for a while until someone says hey, that person should have commit privs Feb 17 02:11:48 Tartarus: :) Feb 17 02:11:54 showing good work, of course :) Feb 17 02:12:03 emdete: or otherwise someone gives up and looks into your issue Feb 17 02:12:05 Tartarus: problem is, oe or build generally isnt my main concern :/ Feb 17 02:12:34 emdete, yeah, I know what you mean Feb 17 02:12:41 sometimes luck is just against you, repeatedly Feb 17 02:12:48 i think itd be nice to ship a chroot with OpenEmbedded in it, just in case there's any host machine issues influencing the build Feb 17 02:12:50 heh Feb 17 02:13:27 I've got bare ubuntu chroots that fit that bill :) Feb 17 02:13:36 * mwester-laptop thinks that's a good idea; he's pretty convinced that libtool/bluez is somehow dependent on host libs... Feb 17 02:13:39 mwester-laptop: what's a OTD? slackware? Feb 17 02:13:42 kergoth: yes, intltool-native is such a candidate that is influenced by host installed packages. i tried to discuss that here but with no echo Feb 17 02:13:44 a vmware image or a live cd would be good too Feb 17 02:13:49 denix0: Angstrom Feb 17 02:14:00 vmware appliances are quite popular nowadays Feb 17 02:14:12 that model sucks... Feb 17 02:14:44 mwester-laptop: unfortunately its hard to check for host build issues. you cant monitor every access outside of oe, because there are legitimate reasons to be poking at host stuff, to run the native compiler and all Feb 17 02:14:49 i worked with that with wtopia and its of no fun at all Feb 17 02:15:00 all you can do is force all the configure options that autoselect based on lib existence and pray Feb 17 02:15:29 currently oe is broken - is someone working on that? Feb 17 02:15:45 acting like that isnt going to get you anywhere. Feb 17 02:15:48 its broken -for you- Feb 17 02:15:55 not much can be done - either mickey commits a missing file, or someone reverts his commit Feb 17 02:16:11 kergoth: actually, not just for hime Feb 17 02:16:11 or you revert to a known good version, or use stable or something Feb 17 02:16:37 denix0: you mean, whatever package he's building is also built by every other OpenEmbedded user on the planet? Feb 17 02:16:50 kergoth: the problem NOW is there is a missing .inc file, required by several .bb files. that breaks bitbake parsing Feb 17 02:16:51 calling OpenEmbedded "broken" because one package has a problem is ridiculous Feb 17 02:17:00 kergoth: I know... but I think we can do better --- if someone were to be convinced that it was worth the effort. I think a host machine with a bare OS, and a compiler -- no -devel packages on the host at all beyond the minimum to build gcc-cross, and using "ASSUME_PROVIDED" for as many -native packages a possible would flush out a number of problems. Feb 17 02:17:31 mwester-laptop: the problem with ASSUME_PROVIDED is we dont track which native tools -require- our changes/patches and which can rely on the host machine's tools Feb 17 02:17:34 mwester-laptop: afaik anyway Feb 17 02:17:43 itd probably be a good idea to audit them Feb 17 02:17:59 kergoth: true. As I've noticed with git-native and one of my older Fedora systems ;) Feb 17 02:18:19 part of it is that we never wanted OpenEmbedded to be a test tool the way autoconf is Feb 17 02:18:21 but its hard to avoid that Feb 17 02:18:38 kergoth: bitbake parses all the recipes and chokes if some includes are missing, regardless if you use/build them or not Feb 17 02:18:50 then mask them out with BBMASK Feb 17 02:18:51 sry for beeing insisting but as far as i understand oe build is broken for everyone - is someone working on that Feb 17 02:18:57 But in the short term, there is a problem we need to sort here. Feb 17 02:19:05 something is missing? Feb 17 02:19:09 kergoth: BBMASK isn't working - I'm about to send an email to ml... Feb 17 02:19:53 i'd just revert his commit until he gets a chance to commit a fixed version, personally Feb 17 02:20:09 but again, you can just revert your repo to before his commit Feb 17 02:20:16 a quick git checkout and you're on your way.. Feb 17 02:21:04 Yes, but that doesn't fix all the other users out there, many of whom don't have the git "foo" to do that, or may not realize that's a good solution. Feb 17 02:21:49 the fact is, tracking the current branch and updating regularly is going to lead to occasional build problems. you're using the trunk, for gods sake. shit happens Feb 17 02:21:50 If the repo is unparseable, and there's a missing file, then we can either commit an empty file to let parsing proceed, and sort it later -- or revert the commit, and sort it later. Feb 17 02:21:55 heh Feb 17 02:22:00 aye Feb 17 02:22:07 kergoth: Yes, occasiional is true. Feb 17 02:22:16 or do nothing and ignore users complaining... Feb 17 02:22:31 emdete: if you're not going to be helpful, just at least stop your whining, please Feb 17 02:22:34 But it is the case that is very often does not build lately. It really has gotten MUCH worse int eh past several months Feb 17 02:22:35 it's not helping anything Feb 17 02:22:42 and its just going to piss people off Feb 17 02:23:16 kergoth: sry, but oe frustated me alot last times. so what could we do? would a empty file commit not a good idea Feb 17 02:23:20 ? Feb 17 02:24:43 * mwester-laptop is not in a position to help, at least unless he can get his VPN working through this stupid hotel firewall :( Feb 17 02:25:07 mwester-laptop: that's what I said - anybody is willing to revert mickey's commit? :) Feb 17 02:25:17 mwester-laptop: doesn a ssh tunnel over port 443 help most of the times? :D Feb 17 02:25:39 kergoth: I sent an email to ml describing a problem with BBMASK, if you are interested Feb 17 02:26:06 But my vpn/ssh tunnels are on very non-standard ports, and it looks like this firewall is blocking that range. Feb 17 02:26:16 denix0: i'll take a look. itd be a good excuse to get comfortable with the codebase again :P Feb 17 02:26:17 kergoth: my intention was to sensitive oe people that in the last weeks oe didn't work well at all... Feb 17 02:27:03 mwester-laptop: 443 for https is a good choice for ssh ;) Feb 17 02:27:20 mwester-laptop: does it need a proxy? Feb 17 02:27:21 All the script kiddies hack at that port; fills up my logs. Feb 17 02:28:14 mwester-laptop: do you want me to commit an empty .inc file then? Feb 17 02:28:17 mwester-laptop: so at least dns proxeing is left ;) Feb 17 02:28:38 mwester-laptop: it would fix the parsing issue for most, but be broken for fso people... Feb 17 02:29:00 denix0: but isnt fso broken without that file anyway? Feb 17 02:29:16 emdete: have absolutely no clue - never ever built one :) Feb 17 02:29:36 denix0: me too Feb 17 02:30:05 but from logic: its going better if oe is broken only for some... Feb 17 02:30:07 I can't say what's the right thing to do, I'm not a core developer. I would think that creating the empty file is a very minor change that would benefit a lot of people, although it would not help build anything based on FSO. Feb 17 02:30:17 So I would create that file. Feb 17 02:30:23 oh, you mean since the .inc file is missing. right, it is broken as it is. the point is mickey would need to fix it asap, otherwise the issue may be masked Feb 17 02:30:49 mwester-laptop: its just the final image build step so all packages should build fine... right? Feb 17 02:31:24 I can't see the repo from here (I guess I could check out gitweb or whatever that is) but if that is the case, then that is relatively minor. Feb 17 02:31:43 Create the empty file, and commit it... Feb 17 02:32:07 one sec Feb 17 02:34:26 03Denys Dmytriyenko  07org.openembedded.dev * rfaa823642b 10openembedded.git/packages/images/fso-image.inc: fso-images.inc: add an empty file to allow bitbake to parse the entire tree Feb 17 02:37:11 parsing should be working now Feb 17 02:37:48 okay, that works fine! thnks, denix0 Feb 17 02:43:12 emdete: basically, that's what it takes to push your fixes - complain about it until someone fixes it... :) Feb 17 02:43:42 denix0: :D hopefully kergoth isnt too much anoyed ;) Feb 17 02:44:00 heh, i've tamed in my old age, no worries :P Feb 17 02:44:14 kergoth: thnx :) Feb 17 02:45:10 hmm, ml bouncer is way too slow... Feb 17 02:47:13 finally! Feb 17 02:47:50 kergoth: http://thread.gmane.org/gmane.comp.handhelds.openembedded/21148 **** ENDING LOGGING AT Tue Feb 17 02:59:58 2009