**** BEGIN LOGGING AT Tue Jan 05 02:59:56 2010 Jan 05 03:17:22 hi ,does anyone know it **** ENDING LOGGING AT Tue Jan 05 05:57:21 2010 **** BEGIN LOGGING AT Tue Jan 05 05:58:14 2010 Jan 05 07:59:09 re Jan 05 08:33:53 Hi Jan 05 08:34:40 What would be the best way to make header files and libraries available from one recipe to another ? Jan 05 08:49:03 03Martin Jansa  07org.openembedded.dev * re7a640aa3d 10openembedded.git/conf/machine/om-gta02.conf: Jan 05 08:49:03 om-gta02: updated UBI params Jan 05 08:49:03 Signed-off-by: Martin Jansa Jan 05 08:49:14 03Martin Jansa  07org.openembedded.dev * r590b54897f 10openembedded.git/recipes/linux/ (8 files in 5 dirs): Jan 05 08:49:14 linux-openmoko: lower debug level for UBI in defconfigs Jan 05 08:49:14 * requested by max_posedon, UBI works for him, but was too slow because Jan 05 08:49:14 of debug Jan 05 08:49:16 * applied to all ubi-enabled versions shr-devel, shr-drm-devel, 2.6.31, 2.6.32 Jan 05 08:49:18 Signed-off-by: Martin Jansa Jan 05 09:08:05 03Martin Jansa  07org.openembedded.dev * r1029524234 10openembedded.git/conf/machine/om-gta02.conf: Jan 05 09:08:05 om-gta02: remove ubifs IMAGE_FSTYPES as ubi creates ubifs too Jan 05 09:08:05 * mkfs.ubifs is called by bitbake the same but: Jan 05 09:08:05 shr-full-eglibc-ipk--20100103-om-gta02.rootfs.ubifs Jan 05 09:08:05 shr-full-eglibc-ipk--20100103-om-gta02.ubifs.img Jan 05 09:08:07 are a bit different, probably only some timestamp of ubifs build? Jan 05 09:08:11 Signed-off-by: Martin Jansa Jan 05 09:08:27 sgh: that is done by staging; you also want a DEPENDS in your recipe specifying the packages you depend on Jan 05 09:13:18 03Koen Kooi  07org.openembedded.dev * r4a3a725cc5 10openembedded.git/recipes/qt4/ (33 files in 2 dirs): qt 4.6.0: backport a few patches from git, mainly QGL related Jan 05 09:13:29 03Koen Kooi  07org.openembedded.dev * r198daf972e 10openembedded.git/conf/checksums.ini: checksums: add new xmonobut location Jan 05 09:13:29 03Koen Kooi  07org.openembedded.dev * rb9ea00841b 10openembedded.git/recipes/gnome-mplayer/gnome-mplayer.inc: gnome-mplayer: add missing DEPENDS on curl Jan 05 09:22:05 good morning Jan 05 09:22:23 03Martin Jansa  07org.openembedded.dev * re6b2eae952 10openembedded.git/recipes/tasks/task-shr-feed.bb: Jan 05 09:22:23 task-shr-feed: add bonnie++ for ubifs benchmark Jan 05 09:22:23 Signed-off-by: Martin Jansa Jan 05 09:35:48 florian: good morning Jan 05 10:03:37 eFfeM: thank ... I'm more thinking of which variables contain the path to the kernel headers and such. ? Jan 05 10:07:00 Quick (and stupid) question, what is the 'correct' OE way to mark a package as 'do not include me in the image no matter what'? BADREC...? I really don't want to ship QT4 Demos and Examples as they are massive but want Qt support so just figured I would check the correct way to do it. Jan 05 10:07:36 DJWillis: just dont put those packages in the image Jan 05 10:07:59 qt4 shouldnt be recomending demos and examples, thats just stupid Jan 05 10:08:37 XorA: but there seem to be pulled in by qt4-x11-free or qt4-x11-free-gles. Unless I am going mad ;-). Jan 05 10:08:49 why though? Jan 05 10:09:07 something must RDEPEND on them Jan 05 10:09:18 That's why I want to badrec them as I cant spare 20meg for cruft like that, no idea why, not my recipe, seems daft. Jan 05 10:09:39 DJWillis: there is a bad recomend, but it would be better to fix the bug :-D Jan 05 10:10:36 XorA: Well I am not sure if it is a 'bug', I thought about it and figured that whoever packaged Qt4 considered the demos worth shipping. Jan 05 10:11:11 DJWillis: that makes zero sense to me Jan 05 10:11:16 03Henning Heinold  07org.openembedded.dev * r7e8d3b8bb1 10openembedded.git/recipes/vdr/vdr_1.7.10.bb: vdr: fix dependency for libintl Jan 05 10:11:40 Hmmm, the RRECOMMENDS_${PN} = "${LIB_PACKAGES} ${OTHER_PACKAGES}" in qt4.inc seems to do that as demos and examples are in ${OTHER_PACKAGES} Jan 05 10:12:21 seems to be zecke and koen that mess with those packages Jan 05 10:12:28 but git log always tells the truth :-) Jan 05 10:13:14 XorA: I will mention it to Koen but bad recomend seemed to be a lot less pain for me ;-) Jan 05 10:21:49 Hi! Why is STAGING_KERNEL_DIR different in a normal recipe compared to what it is normally ? Jan 05 10:52:01 Hi, I successfully compiled qt-embedded for my target and need help deploying it Jan 05 10:52:08 ???? Jan 05 10:52:15 opkg install Jan 05 10:52:17 I see a lot of files under deploy/ipk Jan 05 10:52:40 or write your image-recipe Jan 05 10:52:46 with qt included Jan 05 10:52:54 woglinde: ah ok Jan 05 10:53:17 when I built helloworld recipe i didn't have to.. Jan 05 10:53:23 or provide depoly dir via a webserver Jan 05 10:53:38 and adjust the opkg repositories Jan 05 10:53:56 or copy the ipk over and install them via opkg install directly Jan 05 10:53:56 woglinde: but there is no base image with which I can boot the target Jan 05 10:53:58 or use nfs Jan 05 10:54:06 ?????? Jan 05 10:54:13 transferring is not a problem.. i will manage somehow Jan 05 10:54:39 but there isnt a rootfs image to boot the stuff. Jan 05 10:54:56 I dont see opkg either. Jan 05 10:55:12 Do I need to bitbake a particular recipe to get this? Jan 05 10:55:13 what are you doing what machine you have? Jan 05 10:55:31 i am targetting a 486 on a VirtualBox Jan 05 10:59:09 nevermind, I will try to write an image recipe (just heard about it from u) Jan 05 11:19:15 hi folks is it resonable for open embedded to perform 1000+ tasks when I want a simple boot image for verdex board Jan 05 11:19:22 is the toolchain that heavy ? Jan 05 11:19:39 * whatnick is running out of space of ubuntu VM disk Jan 05 11:19:47 jupp Jan 05 11:20:01 git compiles for angstroem needs 6 gigs Jan 05 11:20:19 because of the compile flags Jan 05 11:20:20 bong !! Jan 05 11:20:36 this will difinitely run out of room Jan 05 11:20:50 but koen states that compiletime and space is cheap Jan 05 11:20:54 * whatnick looks at disk resizing for virtualbox Jan 05 11:21:16 lol not when i am on primary windows and its compiling in a vm Jan 05 11:21:27 but compiling in virtualbox shouldnt be fun Jan 05 11:21:43 whatnick 15-20 gig should be okay Jan 05 11:22:09 10-15 should work too Jan 05 11:22:23 if you only compiles for one distribution an one target Jan 05 11:23:02 ya just need it for this verdex gumstix Jan 05 11:23:08 03Henning Heinold  07org.openembedded.dev * r59e22a032e 10openembedded.git/recipes/vdr/vdr_1.7.10.bb: vdr: package /etc stuff too and bumped PR Jan 05 11:23:52 lets make a second disk and dump stuff there Jan 05 11:25:45 10gb should be fine for 1 target ? Jan 05 11:26:03 what image you will build? Jan 05 11:26:51 gumstix standard Jan 05 11:27:04 -> bitbake gumstix-basic-image Jan 05 11:27:11 http://gumstix.net/wiki/index.php?title=Build_Environment_Ubuntu_8.10 Jan 05 11:27:46 * whatnick boots up vm with 2nd disk Jan 05 11:27:54 hm better use 15 Jan 05 12:17:09 morning Jan 05 12:20:33 hrw, hi Jan 05 12:59:01 whatnick: if space is a constraint then you might consider using minimal rather than angstrom. Jan 05 13:09:43 pb_, can you show me any real size diff between the two? Jan 05 13:10:12 minimal will be entirely unmaintained against the gusmtix repo also Jan 05 13:10:18 Crofton|work: angstrom builds with -ggdb3 and minimal doesn't; I haven't made any scientific tests for myself but there seems to be a consensus that -ggdb3 causes a significant increase in build tree size Jan 05 13:10:30 but not image size Jan 05 13:10:48 right, but we are talking about build trees not images Jan 05 13:10:56 building minimal for gumstix would be foolish, since all the gumstix testing is done with Angstrom Jan 05 13:11:23 pb_: yes, it creates a lot more DWARF2 information Jan 05 13:11:37 also, I see he is building for verdex Jan 05 13:12:08 but then again, rm_work can do wonders too Jan 05 13:12:12 verdex gumstix build is old copy of OE Jan 05 13:12:30 it will not have minimal Jan 05 13:12:55 zecke: rm_work did wonders in past. now we have multithread and it does not do magic as good as in past Jan 05 13:13:25 pb_ angstrom is nearly done Jan 05 13:14:00 whatnick: INHERIT += "rm_work", then "bitbake gcc-cross;bitbake task-base;bitbake console-image;bitbake gumstix-basic-image" (can skip console image if it is bigger then gumstix one) Jan 05 13:14:03 whatnick: ah, very good Jan 05 13:14:23 Crofton|work: -ggdb3 made build tree of Angstrom a good 5-10G bigger than it used to be Jan 05 13:14:39 as the source is all inside the binaries Jan 05 13:15:20 but, the problem here is that people in this channel make the jump that minimal solves problems at the drop of a hat Jan 05 13:15:23 and nearly no one uses *-dbg packages Jan 05 13:15:27 when in this case, it is not even an option Jan 05 13:15:58 hrw: how do you know? Jan 05 13:17:01 zecke: I think that -ggdb3 should be user switchable in simple way (disabled by default) Jan 05 13:17:34 hrw: maybe, at least it would not harm Jan 05 13:21:23 I hate encouraging users to fiddle with build flags Jan 05 13:21:36 but in this case, it might be useful Jan 05 13:22:12 also need to invest some time encouraging gumstix to switch verdex builds to recent OE :) Jan 05 13:24:50 they will not do it in a jiffy Jan 05 13:24:54 verdex is eol Jan 05 13:25:01 they are switching processors Jan 05 13:25:43 yeah Jan 05 13:26:01 all of verdex is eol now? Jan 05 13:26:20 I have a verdex set, but the mounting is so fiddly Jan 05 13:27:23 http://www.gumstix.net/Hardware/view/Product-Line-EOL-Phasing-Out-Notices/Phasing-out-PXA270-based-Verdex-product-line/112.html Jan 05 13:28:14 i broke the miniusb on mine :) Jan 05 13:29:31 bummer Jan 05 13:29:39 ok, but the pro line is still ok Jan 05 13:29:41 i can solder it back Jan 05 13:29:57 looks like the eol was driven by parts going eol Jan 05 13:29:59 it is currently held together with masking tape and a crocodile clip Jan 05 13:30:04 :) Jan 05 13:30:07 awesome Jan 05 13:30:09 get an overo :) Jan 05 13:30:17 though should be gaffa tape for a real hack Jan 05 13:32:50 whatnick, you are using the gumstix OE they keep in svn? Jan 05 13:32:57 * whatnick is making a quadcopter with the gumstix Jan 05 13:33:13 following instructions -> http://gumstix.net/wiki/index.php?title=Build_Environment_Ubuntu_8.10 Jan 05 13:33:40 yeah Jan 05 13:33:47 that is an old OE fork :) Jan 05 13:33:49 kernel is compiling woot .. Jan 05 13:33:56 but it should work :) Jan 05 13:34:11 well i want something newer than what is default on my board Jan 05 13:34:13 http://quadcopter.org/index.php5?title=Quadcopter_Home Jan 05 13:34:14 ? Jan 05 13:34:21 long story on how i came by the board Jan 05 13:34:29 heh Jan 05 13:35:43 http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A19367 Jan 05 13:36:00 http://api.ning.com/files/EIbaHKb2tvhe5et-lbpZG8dgwvlSvfNqNRVXh*OguCmgKkV1ng2G4ewzHM6-AviG74Tzjs*AG6cXpgU4Rn408M2veH4eqcW5/quad_wind.jpg Jan 05 13:40:04 i operate on windows and i have a serial console to the gumstix via putty Jan 05 13:40:24 what would be the safest way to push the oe image on ? Jan 05 13:41:55 03Koen Kooi  07org.openembedded.dev * rfdaf5c66ad 10openembedded.git/ (3 files in 3 dirs): hawkboard, da850-omapl138-evm: fix SATA Jan 05 13:44:50 you need to do it via serial? Jan 05 13:44:58 I used kermit from linux Jan 05 13:47:12 whatnick: which quadcopter base design? Jan 05 13:57:28 just our own .. its simple enough Jan 05 13:57:50 we have a 3dm-gx2 gyro/acceletometer Jan 05 13:57:57 and gps bits on gumstix Jan 05 13:58:08 + a couple of avr uC's Jan 05 14:00:21 i got 4 bl motors off hongkong Jan 05 14:35:17 03Martin Jansa  07org.openembedded.dev * reb935b9ae4 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Jan 05 14:35:17 remoko: bump revision in sane-srcrevs for bluez4 support Jan 05 14:35:17 Signed-off-by: Martin Jansa Jan 05 14:35:19 03Tim Abell  07org.openembedded.dev * r1683f24966 10openembedded.git/ (3 files in 3 dirs): Jan 05 14:35:19 podpooch: new recipe for podcast downloading app for e17 Jan 05 14:35:22 Signed-off-by: Martin Jansa Jan 05 14:35:24 03Martin Jansa  07org.openembedded.dev * r86735426ec 10openembedded.git/ (3 files in 3 dirs): Jan 05 14:35:27 qi: bump revision for sane-toolchain compatibility Jan 05 14:35:29 Signed-off-by: Martin Jansa Jan 05 14:35:31 03Martin Jansa  07org.openembedded.dev * r60674da887 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Jan 05 14:35:36 sane-srcrevs-fso: add fsotdld Jan 05 14:35:38 Signed-off-by: Martin Jansa Jan 05 14:41:13 Laibsch: thanks a lot! and happy new year Jan 05 14:41:26 Hi Jan 05 14:41:33 Happy new Year to everyone Jan 05 14:45:17 and to you Jan 05 15:06:36 morning Jan 05 15:09:05 hi kergoth Jan 05 15:12:09 hey pb_ Jan 05 15:16:01 gm Jan 05 15:24:27 03Koen Kooi  07org.openembedded.dev * rf60bce0c24 10openembedded.git/recipes/ushare/ushare_hg.bb: ushare: add ushare hg Jan 05 15:24:37 03Koen Kooi  07org.openembedded.dev * ra2e8b07f62 10openembedded.git/recipes/upnp/ (libdlna/dlna.diff libdlna_0.2.3.bb): libdla: add 0.2.3 Jan 05 15:52:15 steliosk: welcome back and happy new year. good to see you again. Jan 05 16:11:51 03Martin Jansa  07org.openembedded.dev * r58766d5f46 10openembedded.git/recipes/tasks/task-shr-feed.bb: task-shr-feed: remove fsotimed, because it was removed from OE tree Jan 05 16:25:30 like2wise: are you will working on Jan 05 16:25:34 !oebug 4370 Jan 05 16:25:35 * * Bug 4370, Status: CONFIRMED, Created: 2008-06-09 21:29 Jan 05 16:25:36 * * gwossum(AT)acm.org: Eliminate need for gettext Jan 05 16:25:37 * * http://bugs.openembedded.org/show_bug.cgi?id=4370 Jan 05 16:25:38 ? Jan 05 16:25:52 one moment will look at it Jan 05 16:25:59 i a minute... Jan 05 16:37:41 "ERROR: SRCREV was used yet no valid SCM was found in SRC_URI" for newly added ushare? Jan 05 16:38:10 hg is used there.. do I need something special for that/ Jan 05 16:42:31 Laibsch : Hi ! Happy New Year also. Jan 05 16:42:55 JaMa|Wrk: the bb file was recently added by koen Jan 05 16:43:16 I just removed the file for now so I can move on Jan 05 16:43:19 maybe svn hg fetcher is further ahead then release bitbake version Jan 05 16:43:28 could be Jan 05 16:43:30 if so that recipe cannot be in OE yet Jan 05 16:43:31 Laibsch: I've seen but I expect he tested it before, so just asking here before pinging him Jan 05 16:43:49 Well, I ran into the same issue Jan 05 16:44:01 check the git log for bitbake and see if it mentions hg improvements since 1.8.18 was tagged Jan 05 16:44:04 please ping him so he has a chance to fix it Jan 05 16:44:09 XorA: I just run build with bitbake master and it fails the same :/ Jan 05 16:44:37 odd, Ill kick him Jan 05 16:44:48 XorA: better :) Jan 05 16:45:41 XorA: ah .. that error with bitbake master is not confirmed.. Jan 05 16:46:03 XorA: I have seen similar error and its a bit diffferent and from other recipe.. still parsing Jan 05 16:46:49 I cant check, I left build machine powerdowned Jan 05 16:47:23 * XorA needs to save $$$ Jan 05 16:48:27 ah ushare_hg parsed with bitbake master (only few ERROR: global name 'repodir' is not defined while parsing /home/projects/OE/dev/recipes/uclibc/uclibc_git.bb) Jan 05 16:49:19 have poked koen, but he is currently afk Jan 05 16:49:26 XorA: but still please kick him gently.. Jan 05 16:49:29 ok good Jan 05 16:49:52 you both work in buglabs? Jan 05 16:50:11 no Jan 05 16:50:19 Im a few hundred miles away Jan 05 16:51:03 * XorA works IT for one company (where I am today) and Embedded Linux for Slimlogic Jan 05 16:51:48 * JaMa|Wrk confused.. then hrw works for buglabs? Jan 05 16:51:53 yes Jan 05 16:51:59 koen works for TI Jan 05 16:52:06 koen works for TI? huh Jan 05 16:52:18 don't know ...maybe he does things for the touchbook Jan 05 16:52:42 kergoth: yeah, in the UK Jan 05 16:52:46 but for hrw he does things for buglabs...I think he work for them indirectly Jan 05 16:53:04 hmm, what division is he in? Jan 05 16:53:21 the one that does beagle that I cant remeber the name of Jan 05 16:53:22 christ, parsing 7634 recipes makes me want to eat a bullet Jan 05 16:53:31 * pb_ shoots kergoth Jan 05 16:53:34 happy to help Jan 05 16:54:07 what can i use on windows to do kermit binary transfer ? Jan 05 16:54:20 whatnick: kermit, I guess Jan 05 16:54:26 btw FSO powered down my display....how can I power it on back with sysfs? Jan 05 16:54:37 hehe kermit binary is at ? Jan 05 16:54:50 anyway time for me to sign out, bye Jan 05 16:54:58 i usually use putty for serial having a hard time tracking down a kermit .. Jan 05 16:55:01 pb_: thanks! Jan 05 16:55:41 whatnick: http://lmgtfy.com/?q=kermit+windows Jan 05 16:57:53 haha that got done a few times :) Jan 05 16:58:01 hey kergoth, do you guys have any outstanding changes for reusing gcc/etc from packaged-staging? Jan 05 16:58:19 * whatnick really need to get a linux box to get this development done Jan 05 16:58:49 Tartarus: seemed to work fine for us, but we don't prebuild those anymore, because they're all external anyway, its cheap to pull binaries out of an installed toolchain, which is all our recipes do for those Jan 05 16:58:59 wonder if a vm can get to my usbserial hmm Jan 05 16:59:18 Hmm, ok Jan 05 16:59:40 Tartarus: for mvl6, the user runs a toolchain installer, and the IP installer, and then uses the IP tools to pull down the collections and set up projects. no crosscompiler builds Jan 05 16:59:43 why, are you hitting issues? Jan 05 16:59:57 jo kergoth Jan 05 16:59:58 Yeah, but i'm on a mid dec snapshot Jan 05 17:00:20 ah Jan 05 17:00:26 change tmpdir name and then stuff tries to use a native /lib/libc and fails Jan 05 17:00:27 heh Jan 05 17:00:42 I'm *updating* mvl6 to mid dec, and that was a shitload of work Jan 05 17:00:55 I can only imagine :) Jan 05 17:01:06 we've been running recipes from June or so Jan 05 17:02:18 i'll have to publish the process I'm using to sync up, might be useful for others.. or at least so people can say I'm insane, which is always entertaining Jan 05 17:02:53 heh Jan 05 17:03:13 So do you guys build the toolchain with OE and export it or is it totally outside? Jan 05 17:03:38 mickeyl: good afternoon Jan 05 17:03:42 he pb Jan 05 17:03:48 totally outside, it's from codesourcery Jan 05 17:04:04 my how things have changed Jan 05 17:04:14 good afternoon pb_ Jan 05 17:07:43 florian: it finally occurred to me to give my daughter an old broken laptop of her own. now she is happy to sit next to me and "work" on her own computer without unplugging mine all the time. Jan 05 17:07:55 hehe Jan 05 17:08:17 luckily she doesn't appear to have noticed that the screen on hers doesn't do anything. Jan 05 17:08:35 pb_ Wait till next week... Jan 05 17:17:01 pb_: hehe, good strategy Jan 05 17:17:28 i might try that with my wife some day Jan 05 17:17:30 * mickeyl chuckles Jan 05 17:18:01 (I'm sure Sabine will be thrilled by this suggestion :-p) Jan 05 17:18:16 Ainulindale *g* Jan 05 17:18:31 hehehe Jan 05 17:18:38 Ainulindale mickeyl should buy here an mac book air Jan 05 17:18:42 args her Jan 05 17:18:46 she'd love to have one Jan 05 17:18:48 Nah Jan 05 17:18:52 Buy her a proper computer Jan 05 17:19:05 but she doesn't agree with spending money on more electronic devices :/ Jan 05 17:19:06 Not an expensive crap copy of one Jan 05 17:19:18 That's sensible Jan 05 17:19:21 mickeyl thats the math gene Jan 05 17:19:27 probably. Jan 05 17:19:37 I'm sure you don't even use a third of your gadgets Jan 05 17:20:02 hmm Jan 05 17:20:10 that's probably true Jan 05 17:20:22 i don't like selling stuff Jan 05 17:20:23 mickeyl: by the way as it's been a while, was rubbing the statue in Père Lachaise any useful? =) Jan 05 17:20:31 hahaha Jan 05 17:20:35 i'm afraid not yet Jan 05 17:20:41 Damn! :-) Jan 05 17:20:48 still working and hoping ;) Jan 05 17:20:56 Would make a new shiny gadget to play with though Jan 05 17:21:02 Although it'd be more time consuming I suppose Jan 05 17:21:04 one that costs a ton of mony Jan 05 17:21:05 money Jan 05 17:21:08 and time, ya Jan 05 17:21:13 thanks for the little push guys .. loading pl2303 lets virtualbox access windows usb-serial cable Jan 05 17:21:14 heh :-) Jan 05 17:21:21 awsome for downloading code Jan 05 17:21:38 Anyway, off I go, see you guys Jan 05 17:21:47 all the best, cu Jan 05 17:22:02 hmm Jan 05 17:22:08 ~lart libnl and libnl2 Jan 05 17:22:08 * ibot shoves a crumpet down libnl and libnl2's throat, happy now?! Huh? Want some JAM with that? Jan 05 17:22:14 stepping on their toes somehow Jan 05 17:24:16 mickeyl hm whats wrong? Jan 05 17:24:21 with the libs Jan 05 17:24:37 hmm, i never pushed newcollection.bbclass.. i should really do that Jan 05 17:24:40 dunno, but libnl1 stops to build after libnl2 has been built Jan 05 17:25:08 kergoth hehe yes Jan 05 17:25:09 perhaps i can uplevel connman to libnl2, it seems to be the only one using it Jan 05 17:25:19 mickeyl jupp Jan 05 17:25:21 good idea Jan 05 17:27:59 hi like2wise Jan 05 17:31:36 hi Jan 05 17:33:29 OK, has anyone else seen an error w/ parsing ushare_hg.bb? Jan 05 17:34:45 is qemu _still_ requiring gcc3 these days? Jan 05 17:34:56 mickeyl nope Jan 05 17:34:58 only older Jan 05 17:35:02 11 not Jan 05 17:35:05 ah, awesome Jan 05 17:35:10 can we remove it from the sanity check then? Jan 05 17:35:26 and versions > 10.6 or something Jan 05 17:36:17 Tartarus: yes, check the backlog Jan 05 17:36:22 for now, just remove the bb file Jan 05 17:36:50 okay, http://dl.dropbox.com/u/112715/Documents/Sync%20from%20OE%20-%20Public.html/index.html Jan 05 17:37:00 thoughts? Jan 05 17:38:07 will read it later Jan 05 17:38:12 to much text for now Jan 05 17:38:42 hehe Jan 05 17:38:44 fair enough Jan 05 17:40:23 Laibsch: no I'm no longer working on Jan 05 17:40:24 !oebug 4370 Jan 05 17:40:25 * * Bug 4370, Status: CONFIRMED, Created: 2008-06-09 21:29 Jan 05 17:40:26 * * gwossum(AT)acm.org: Eliminate need for gettext Jan 05 17:40:27 * * http://bugs.openembedded.org/show_bug.cgi?id=4370 Jan 05 17:40:41 Laibsch: I'm unaware of the current status Jan 05 17:47:16 anyone run into a missing dep of pango-locale trying to install gtk+ into an image, before? Jan 05 17:48:38 pango-locale* or just plain pango-locale? Jan 05 17:48:58 I can't think of anything that should be generating the latter. Jan 05 17:49:21 the pango-locale* dep will be getting added by package.bbclass, though if it's showing up unresolved then that would suggest you have a package manager bug. Jan 05 17:50:08 the latter Jan 05 17:50:24 that is weird. I wonder where that could be coming from. Jan 05 17:50:37 but the pango-locale-whatever RPROVIDES pango-locale, i think Jan 05 17:51:06 yeah, but it's meant to only ever be referenced as pango-locale* Jan 05 17:51:56 looks like the pango-module-foo is rdep'ing on pango-locale Jan 05 17:52:04 * kergoth compares current oe pango to mvl6 pango Jan 05 17:53:05 that sounds like a bug Jan 05 17:53:40 the only place that should be adding deps on locale packages is this line in package_ipk.bbclass: Jan 05 17:53:45 if not '-locale-' and not '-dbg' and not '-dev' in pkgname: Jan 05 17:53:45 rdepends.append('%s-locale*' % pkgname) Jan 05 17:53:47 well, those two lines Jan 05 17:54:26 huh. weird. Jan 05 17:54:39 hrm, bitbake just died while parsing a recipe that uses 'hg' Jan 05 17:54:52 should i update bitbake? is this a new thing? Jan 05 17:55:06 ERROR: while parsing /home/matt/devel/zipit/openembedded/openembedded/recipes/ushare/ushare_hg.bb Jan 05 17:56:03 though it's doing rev=${SRCREV} rather than specifying the actual revision Jan 05 17:59:26 m4t, a few of us are hitting that now Jan 05 18:00:32 Tartarus okay, thanks Jan 05 18:00:36 i just rm'd it for now Jan 05 18:01:29 cd Jan 05 18:01:46 http://www.linuxfordevices.com/c/a/News/Marvell-Plug-Computer-30-and-Armada-300-and-610/ - 2GHz sheevaplug replacement with wifi/bt and internal hdd space Jan 05 18:05:55 Hello Jan 05 18:06:01 I'm back from VAC :-) Jan 05 18:06:07 * otavio reading mail :-) Jan 05 18:06:14 hey otavio Jan 05 18:12:57 is anybody still looking at patchwork? Jan 05 18:13:39 not me, in fact i never looked at patchwork since i did not think sending patches to the list was a significantly well choice Jan 05 18:16:23 03Michael 'Mickey' Lauer  07org.openembedded.dev * rfc2765595a 10openembedded.git/recipes/dbus/ (7 files in 2 dirs): dbus-1.3.0: add performance optimization patches from https://bugs.freedesktop.org/show_bug.cgi?id=23117 Jan 05 18:16:37 i never do, either Jan 05 18:17:07 not me either; I find it's just as easy to search for patches in my mail folder using evolution Jan 05 18:19:44 just seems like unnecessary overhead. not that hard to save a mail from my mail client and apply it with git-am Jan 05 18:19:57 yeah, exactly Jan 05 18:20:41 kergoth: the difference is that it keeps track of who applied and also adds the acks and signed-off entries Jan 05 18:21:03 kergoth: besides makes easier (if used) to know which ones has been already revised and applied/rejected Jan 05 18:21:11 yes Jan 05 18:21:23 the tool has some benefits, no doubt Jan 05 18:21:32 but it looks like it's not working as it should right now Jan 05 18:21:33 kergoth: it is easier to you to use your email client, but it is a selfish option Jan 05 18:21:38 I'm sure it does, but those things aren't that hard to keep track of either Jan 05 18:21:48 and that seems to have gone on for such a period of time as to suggest nobody is using it anymore Jan 05 18:21:50 just wastes more time, yet another site to be checking Jan 05 18:21:58 patches from non committers gets collected on patchwork nicely so when someone finds time they can be looked up quickly Jan 05 18:22:21 I surf thru patchwork once in a while and take other people patches test then apply Jan 05 18:22:24 khem: I find it's much slower to look them up on patchwork than just to look in my email. Jan 05 18:22:51 but, if patchwork works for you, that's great. Jan 05 18:22:56 pb_: I like the fact that its just filtered mail which only has patches Jan 05 18:22:58 khem: the problem is that it gets boring since commiters are not marking the patches they commit as done in PW and then the backlog is much bigger then it really is Jan 05 18:23:11 it doesn't change the main problem though that people are voluntarily working on that. i find the concept of adding categories to the bugzilla which i scan whenever i'm in the mood to much more efficient than being pestered by mails on the list Jan 05 18:23:17 khem: afaict, that's just the same effect as you get by filtering on "Subject: [oe] [PATCH" Jan 05 18:23:18 yes I noticed Jan 05 18:23:20 introducing more tools doesn't make things more efficient Jan 05 18:23:28 pb_ yes I could Jan 05 18:23:32 not necessarily at least Jan 05 18:23:42 yeah, agreed Jan 05 18:23:58 I could see patchwork having some value if it was coupled to git so that patches that had been applied were automatically flagged as such. Jan 05 18:24:04 If all (or most) people do not use it, indeed. It just makes thing worse Jan 05 18:24:05 but what I do is make a branch and then use the ontrib/patchwork/pw-am.sh Jan 05 18:24:24 its much faster and I dont have to worry about sign offs Jan 05 18:24:29 and history looks better Jan 05 18:24:30 btw: for shr patchwork works quite good Jan 05 18:25:07 I want to try some changes out with "-c devshell", but when I do it seems my path isn't set correctly. I get things like "/bin/sh: line 1: arm-none-linux-gnueabi-ld: command not found". Is there any way to invoke -c devshell and have my environment completely set up properly? Jan 05 18:25:17 I'm a big fan of pull approuch for OE. Jan 05 18:25:27 It would solve PatchWork and review issues Jan 05 18:25:28 question: how much people uses matchbox based X11 images? Jan 05 18:25:31 I notice interesting patch in list and later when I'm in mood for checking patches from others I check the site and use contrib/patchwork/pw-am.sh for all interesting IDs Jan 05 18:26:01 JaMa: the only problem is that PW backlog gets bigger and bigger Jan 05 18:26:21 JaMa: people ought to have the habit of mark the commited patches Jan 05 18:26:23 otavio: someone will have to become a pull master Jan 05 18:26:27 JaMa: but people don't do that Jan 05 18:26:33 whose job is just to pull and merge others changes Jan 05 18:26:45 khem: it doesn't need to be a single person Jan 05 18:26:54 khem: but a small group of people works too Jan 05 18:27:02 otavio: yes that's true for OE one.. but SHR patchwork is quite clean.. all bad patches refused and applied marked as applied Jan 05 18:27:13 otavio: so we have only few items all on first page Jan 05 18:27:17 otavio: If we have enough inclination and people ready to do that its ok Jan 05 18:27:28 JaMa: yes; this is where PW shows its beauthy Jan 05 18:28:11 JaMa: it does make life easier but people ought to avoid commiting stuff without looking at PW Jan 05 18:28:19 JaMa: but OE doesn't follow it, so it fails Jan 05 18:28:31 invoking devshell with the correct path? anyone know how to do this? Jan 05 18:28:34 right Jan 05 18:28:43 awozniak: afaik, it should be automatic. I don't know why that isn't working for you. Jan 05 18:29:04 pb_: kthx Jan 05 18:29:25 awozniak: I guess you should check the run.do_devshell script in temp/ to see what's up. Jan 05 18:29:38 khem: pb_: the way you (in plural) works we end doing doubled work all the time Jan 05 18:30:07 Not follow PW and use it, IMO is wrong. Jan 05 18:30:21 otavio: I've never noticed myself doing any doubled work. Jan 05 18:30:23 We end up doing a fix that has been done before Jan 05 18:30:40 pb_: you didn't look well then :P Jan 05 18:30:48 For myself, indirecting everything through patchwork would cause me to do more work, not less. Jan 05 18:30:59 pb_: you can look a patch and thing. Oh, this is need. Let me apply it. Ohh... someone did it already Jan 05 18:31:04 pb_: you lose time Jan 05 18:31:12 clearly, patchwork doesn't meet our needs. if it did, we wouldn't have half the developers not using it Jan 05 18:31:20 so quit blaming people and rework the process Jan 05 18:31:24 otavio: right, but my point is that this virtually never happens to me. Jan 05 18:31:32 pb_: or ... Jan 05 18:31:41 pb_: oh, this is broken ... you fix Jan 05 18:31:51 and, when it does, it only takes a couple of seconds to find out that it has done, which is probably less time than I would have spent fiddling around with patchwork. Jan 05 18:32:00 pb_: next day you see that two weeks ago someone sent this same thing and noone has looked at it Jan 05 18:32:16 otavio: right, but that latter case is nothing to do with patchwork. Jan 05 18:32:23 pb_: at current PW status, indeed Jan 05 18:32:29 pb_: if PW were used well, no Jan 05 18:32:56 well, as I say, I think it is patchwork's responsibility to keep itself up to date by tracking the git commits and marking patches as applied when they have been. Jan 05 18:32:57 otavio: i really don't see what you hope to accomplish by blaming a subset of the developers. you aren't going to convince them, so stop wasting your time and throwing blame around. Jan 05 18:33:18 if it did that, then I think your main complaint would go away, and the rest of us would not need to change our workflows. Jan 05 18:33:18 kergoth: I'm not blaming. I'm discussing Jan 05 18:33:36 pb_: maybe that contrib script could do that too.. Jan 05 18:34:07 JaMa: dunno. It would need to be integrated with the commit mailing list Jan 05 18:34:15 JaMa: well, no, that only works for patches that have been applied from patchwork itself. I think otavio's complaint is that, when people apply patches directly from email without touching patchwork at all, they are never marked as such in git. Jan 05 18:34:20 s/in git/in patchwork/ Jan 05 18:34:22 pb_: but it will mark some patches applied maybe too soon (when first dev use PW to git am it and then refuse to work on it..) Jan 05 18:34:47 I think the right way to do it is just to link patchwork to one of the git hooks. Jan 05 18:34:56 JaMa: it would need to be automatically done using commit hook at server side Jan 05 18:35:02 presumably, the same one that generates the CIA messages Jan 05 18:35:04 JaMa: dunno if it is supported Jan 05 18:35:10 Ah I see.. it would be nice.. Jan 05 18:35:11 03Koen Kooi  07org.openembedded.dev * ra9831bfdea 10openembedded.git/recipes/upnp/libdlna_0.2.3.bb: libdlna: disable parallel make Jan 05 18:35:19 03Koen Kooi  07org.openembedded.dev * ra3374cb8b7 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Jan 05 18:35:29 JaMa: that would solve most of problems Jan 05 18:35:37 otavio: i think you need to find a dictionary and learn what blame means. it means placing responsibility for, which is what you've been doing, repeatedly Jan 05 18:36:16 kergoth: when we miss use a tool, we're responsable for the tool to not work. Jan 05 18:36:31 kergoth: but I'm not saying that PW is the perfect tool. Jan 05 18:36:34 kergoth: it has flaws Jan 05 18:36:48 kergoth: but it could help a lot if properly used Jan 05 18:37:15 the point is, blaming people accomplishes nothing. the people not using aren't going to switch unless it changes, so quit whining about it Jan 05 18:38:07 and check that git hook support :) Jan 05 18:38:11 right Jan 05 18:38:39 look into solutions, determine *why* the problem exists, rather than repeatedly saying people are responsible for the problem and should do this or that Jan 05 18:38:43 the former is productive, the latter is not Jan 05 18:39:04 I need to figure out how I'll move from our stable/2009 to dev ... Jan 05 18:39:37 PW will not help it so it will be left for later Jan 05 18:39:43 kergoth: I think we could do a better job of looking into non developer patches I think for people like me who do not filter their emails neatly PW helps a bit Jan 05 18:40:01 time to time I also try to change states of patches that get applied by others Jan 05 18:40:10 so there is some double work that happens Jan 05 18:40:38 but that is becuase we do not streamline PW Jan 05 18:40:44 in commit process Jan 05 18:41:14 khem: +1 Jan 05 18:41:45 khem: this is not a developer thing, but a non developer thing. devels can commit directly and usually doesn't even send the patches to ML Jan 05 18:41:57 right. Jan 05 18:41:57 pb_: it's not setting CROSS_COMPILE. The makefiles I'm working on see it onset, and guess (incorrectly). The run.do_devshell has it in some export EXTRA_OEMAKE="CROSS_COMPILE=arm-commonos-linux-gnueabi-", but I'm not sure if/how that's supposed to be used. Jan 05 18:42:23 I think it encouranges non committers if their patches receive due attention Jan 05 18:42:30 awozniak: oh, right. CROSS_COMPILE is not a standard oe variable, it must be something specific to your recipe. Jan 05 18:42:35 and probably grow the community and contribution Jan 05 18:42:38 I think you probably just need to export that variable by hand inside your devshell Jan 05 18:42:42 * pb_ go home now Jan 05 18:42:43 later all Jan 05 18:43:13 cu pb_ Jan 05 18:43:34 * JaMa is going to mark all PW entries sent by him.. Jan 05 18:43:48 JaMa: cool. Jan 05 18:44:13 either we use the tool or we should decommission it thats my perspective Jan 05 18:44:54 If somebody knowledgeable enough were to closer integrate patchwork with what's committed in git that would be great Jan 05 18:45:00 and make everybody happy Jan 05 18:45:15 can I "-c devshell", make some changes, then "-c oe_runmake" ?? Or is there some better way? Jan 05 18:45:39 i don't think it's feasable to try to get everyone to use it, its just not realistic, so integrating with the commit process or dropping PW entirely are the only real options Jan 05 18:45:55 I just want to make one little change and try it out without going through the whole process of creating a patch file and adding the patchfile to the recipe. Jan 05 18:46:28 kergoth: thats fine by me too if we decide on another process to handle patches on ml Jan 05 18:46:43 and follow it. Jan 05 18:47:41 awozniak: I'd suggest making your changes in the devshell, then just re-running the run scripts in ../temp, rather than running make yourself. Jan 05 18:49:04 bitbake virtual/kernel doesnt put the kernel binary in deploy Jan 05 18:49:37 khem: which kernel recipe? Jan 05 18:49:45 2.6.31 Jan 05 18:49:56 I'm uncertain about order of operations. I make my change, then I've got run.do_compile (obviously) but then I've also got do_deploy, do_install, do_package_write, do_stage. What order do those happen in? Jan 05 18:50:06 I deleted the binaries manually Jan 05 18:50:17 hmm I think it does not notice it Jan 05 18:50:28 do prolly rerun deploy may be Jan 05 18:53:53 can I get permission to mark PW entries sent by others? Jan 05 18:55:12 if you see the patch applied you could Jan 05 18:55:43 khem: how? Jan 05 18:56:28 it does not allow you ? Jan 05 18:56:30 in shr PW I had to ask for moving my account to some group of project maintainers from PW POV Jan 05 18:56:41 khem: no.. only for my patches.. Jan 05 18:56:56 yeah Jan 05 18:57:04 Maintainer of SHR. Contributor to SHR. Jan 05 18:57:28 and in OE PW I have only Contributor in "profile" Jan 05 19:01:00 you could ask crofton to change your status Jan 05 19:03:39 Crofton|work: could you assing my PW account (account name: jama) Maintainer to mark patches from others as applied? Jan 05 19:04:14 anyone planning on doing a recipe for the latest version of jamvm jvm? if not i will. Jan 05 19:04:25 1.5.4 Jan 05 19:07:23 I hope it will work Jan 05 19:07:30 * kgilmer knocks on wood Jan 05 19:07:42 as trunk uses jamvm by default Jan 05 19:08:08 s/trunk/buglabs trunk/ Jan 05 19:08:19 * hrw is on too many channels Jan 05 19:09:19 oh ic what you mean hrw Jan 05 19:09:30 if i submit the recipe and it doesn't build then that breaks the buglabs prod build. Jan 05 19:09:42 then that's 2x incentive to get it right! Jan 05 19:10:52 kgilmer: if you will submit it to trunk/meta-{bug,oe}/ Jan 05 19:12:31 is that a question hrw or a request? Jan 05 19:12:42 question Jan 05 19:12:53 or even statement. Jan 05 19:13:44 kgilmer: as: if it will land in OE.dev then buglabs/trunk will not be affected. if you will request it for OE/stable/2009 then buglabs can be affected but it will first be checked with buglabs/trunk before will get my Ack for being included Jan 05 19:14:15 it would be for oe.dev Jan 05 19:14:25 at least that was what i was working on Jan 05 19:14:42 yeah that makes sense hrw Jan 05 19:23:31 03Martin Jansa  07org.openembedded.dev * r330c80d419 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Jan 05 19:23:31 sane-srcrevs-fso: bump rev for fsotdld, what I pushed today as HEAD was too old Jan 05 19:23:31 Signed-off-by: Martin Jansa Jan 05 19:31:25 Anyone successfully built Java using OE? (And, yea, I actually read the wiki page!) Jan 05 19:31:43 re Jan 05 19:33:02 what do you mean by Java SDuensin ? Jan 05 19:33:14 The JRE. Jan 05 19:33:20 openjdk? Jan 05 19:33:28 Yea, that's fine. Jan 05 19:33:38 yes, it's been done SDuensin Jan 05 19:34:14 imho cacaojvm+openjdk classpath offers the best stability/performance at the moment. Jan 05 19:34:20 but that situation is changing rapidly Jan 05 19:35:22 I get a warning that multiple .bb files provide classpath and then it blows up later down the line. Looks like during do_compile for rxtx. Jan 05 19:36:14 what recipe are you trying to build with bitbake? Jan 05 19:36:31 task-java Jan 05 19:37:20 hi kgilmer Jan 05 19:37:25 hi woglinde Jan 05 19:37:46 SDuensin yes you have to decide which classpath you want Jan 05 19:38:09 set it in local.conf Jan 05 19:38:15 I set: PREFERRED_PROVIDER_classpath = "classpath-minimal" Jan 05 19:38:57 SDuensin hm Jan 05 19:39:03 that should be okay Jan 05 19:40:09 Not sure it matters, but my target is x86 and angstrom-2008.1. Jan 05 19:40:38 hm ah okay Jan 05 19:40:47 target x86 isnt so tested well Jan 05 19:41:03 OE usually used against ARM? Jan 05 19:41:21 nope Jan 05 19:41:25 but the java stuff Jan 05 19:41:27 Or is there a better x86 target to use? Jan 05 19:41:30 istnt tested so well Jan 05 19:41:35 for other archs Jan 05 19:42:08 man.. we need to find a good way to unit test some of the aspects of OE, somehow. the classes and the like.. Jan 05 19:42:30 kergoth qa branch? Jan 05 19:43:19 i dunno what's best.. in this particular case, I'm making some changes to one of the classes in INHERIT, and need to ensure that the changes i make don't break the functionality, somehow. manual works, for now.. Jan 05 19:43:20 heh Jan 05 19:43:21 kergoth: why that remark? found something ugly? Jan 05 19:43:25 I'm amazed it works at all. OE is voodoo. :-) Jan 05 19:43:35 oe is no voodoo Jan 05 19:43:42 It is to me! Jan 05 19:43:44 voedoe Jan 05 19:43:54 you will learn behind the vodoo Jan 05 19:44:03 the complexity can be overwhelming SDuensin Jan 05 19:44:16 I'll learn it or it'll kill me. :-D Jan 05 19:44:28 SDuensin try with normal classpath Jan 05 19:44:31 the python learning and programming manuals are 2400 pages alone. Jan 05 19:44:33 :-) Jan 05 19:44:46 I think we will remove -miminal in the next time Jan 05 19:44:56 woglinde: Trying Jan 05 19:44:58 building classpath on a fast machine is under 5 minutes Jan 05 19:44:58 dont' be afraid to dig into the bitbake code. it's not bad at all to understand. Jan 05 19:45:08 kgilmer: really? Jan 05 19:45:32 kgilmer: Everytime I dive in, I swim back to the shore as fast as possible. Jan 05 19:45:41 i found the client/server stuff to be pretty straightforward Jan 05 19:45:43 like2wise only they much os.system("cp somestuff") suckz Jan 05 19:46:24 SDuensin, if you use eclipse you may want to try the eclipse plugin Jan 05 19:46:32 Jan 05 19:46:43 kgilmer he its okay Jan 05 19:46:47 you invented it Jan 05 19:46:55 and its worth the try Jan 05 19:47:01 Oh yea? Didn't know there was such a thing! Jan 05 19:47:26 thx woglinde. SDuensin: http://wiki.openembedded.net/index.php/OTE Jan 05 19:48:04 Ooo - pictures, too. :-) Jan 05 19:49:48 for me the hardest part of learning oe was figuring out all the conventions for variables, and debugging failures. Jan 05 19:50:11 The OTE plugin is intended mainly for recipe writers. Jan 05 19:50:19 but, most recipe writers do not use eclipse. Jan 05 19:50:30 I think a big part of the confusion is just seeing how all the pieces fit together. So much is scattered across all these files, bits and pieces of metadata coming from all over to form a cohesive whole, easy to get lost in the maze Jan 05 19:50:36 in any case i think it might be useful when you are just getting started Jan 05 19:50:44 true kergoth Jan 05 19:52:08 It's still mad about rxtx. I'm going to do a clean on the whole thing and try again. This may take a bit. Jan 05 19:52:12 if you do try the plugin SDuensin i strongly suggest you move TMPDIR outside of your oeroot. eclipse tries to index TMPDIR and it fails. Jan 05 19:57:04 03Koen Kooi  07org.openembedded.dev * r9485f91eaf 10openembedded.git/conf/checksums.ini: checksums: add missing libdlna checksum Jan 05 19:57:07 03Koen Kooi  07org.openembedded.dev * r4d99d97bae 10openembedded.git/ (3 files in 2 dirs): Jan 05 19:57:07 e17: bump SRCREV, enable fixed-point mode in edje according to target fpu setting Jan 05 19:57:07 * tested on angstrom/beagleboard and angstrom/hawkboard Jan 05 19:57:07 03Koen Kooi  07org.openembedded.dev * re871274b9b 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Jan 05 20:00:07 now I am enjoying my birthday beer Jan 05 20:01:55 whoa! happy birthday woglinde :) Jan 05 20:02:00 what kind of beer? Jan 05 20:02:04 thanks kgilmer Jan 05 20:02:08 pils Jan 05 20:02:13 as usal Jan 05 20:02:21 I dont like weizen Jan 05 20:02:29 i'm with you woglinde Jan 05 20:02:38 real pilse Jan 05 20:02:43 not american Jan 05 20:02:46 *g* Jan 05 20:02:46 haha Jan 05 20:03:00 i really liked the beer in munich when i was there Jan 05 20:03:07 i drank *a lot* of it Jan 05 20:03:15 hm were you at augustiner? Jan 05 20:03:18 now i am on a beer vacation due to gout Jan 05 20:03:29 that sounds familiar woglinde Jan 05 20:03:36 i was pretty drunk the whole time Jan 05 20:03:39 lol Jan 05 20:03:43 a mass Jan 05 20:03:49 the beer comes in very large glasses Jan 05 20:04:08 do you know the movie bierfest? Jan 05 20:04:14 that was funny Jan 05 20:04:23 ha yeah Jan 05 20:04:29 the underground chamber Jan 05 20:04:44 in nyc we have lots of german style beer gardens Jan 05 20:04:54 radeburger, goffel, etc is very common Jan 05 20:05:09 and most bars now have something like that Jan 05 20:05:11 goffel? Jan 05 20:05:20 dont you mean gaffel? Jan 05 20:05:23 koelsch Jan 05 20:05:26 yeah Jan 05 20:05:29 yeah that's it Jan 05 20:05:38 hm yeah gaffel is light pils Jan 05 20:05:58 I mean whole koelsch Jan 05 20:06:06 gaffel is only one sort Jan 05 20:06:19 I liked the beers in england too Jan 05 20:06:29 tasted diffrent Jan 05 20:06:33 and had funny names Jan 05 20:06:35 26 minutes for parsing... Jan 05 20:06:41 new record I think Jan 05 20:06:49 kgilmer, FOSDEM looks bad for me due to airfare and work Jan 05 20:06:57 that's too bad Crofton Jan 05 20:07:04 i think if i go it will be on my own dollar Jan 05 20:07:15 what OE package is providing the xorg-macros.m4 file? On my Ubuntu host that would be the xutils-dev package, but that does not seem to exist for OE. Jan 05 20:07:18 kind of still up in the air Jan 05 20:07:45 Laibsch: xorg-macros is recipe name iirc Jan 05 20:07:58 I need to finally buy tickets Jan 05 20:08:03 woglinde: going for fosdem? Jan 05 20:08:58 yeah, I am watchiung for deals Jan 05 20:09:16 for me it is just easyjet from sxf Jan 05 20:09:37 hrw, yes i'm sure it's pretty easy for you :) Jan 05 20:09:42 yeah, that would be great Jan 05 20:10:06 if fosdem was in philly it would be pretty easy for me too :) Jan 05 20:10:31 kgilmer: and harder for me;D Jan 05 20:10:50 yep Jan 05 20:10:57 RP, how about you? fosdem this year? Jan 05 20:11:20 is there talk yet of oe hotel hrw for fosdem? Jan 05 20:11:22 same as last year? Jan 05 20:11:54 woglinde must be getting another birthday beer Jan 05 20:12:00 hrw hm I dont decided yet Jan 05 20:12:05 oh Jan 05 20:12:17 no I talked with cp15 about the navit crash on n900 Jan 05 20:13:03 woglinde: happy birthday! Jan 05 20:13:08 thanks hrw Jan 05 20:13:27 hrw hm right there was something with creditcard Jan 05 20:13:32 I will ask robert Jan 05 20:13:40 if tarent will sponsor something Jan 05 20:13:50 for robert they will Jan 05 20:13:51 but for me Jan 05 20:13:51 woglinde: so how old you are now? Jan 05 20:14:04 mid 30 nearly Jan 05 20:14:29 hehe, that would be too easy, I guess. There is no such package. "find recipes/|grep xorg|grep mac" returns util-macros, but I'm not sure that is the package, either. Jan 05 20:14:34 ah.. I have your bdate somewhere... Jan 05 20:14:55 Laibsch it is Jan 05 20:15:09 some should start BBCLASSEXTEND to get over from poky Jan 05 20:15:14 for the x-recipes Jan 05 20:15:26 so we can rid of the nasty -native duplication Jan 05 20:15:48 and beeing smaller with xorg.preffered-version file Jan 05 20:15:50 isnt' that an item of discussion for tsc? Jan 05 20:16:00 I should ask jama Jan 05 20:16:05 kgilmer why? Jan 05 20:16:17 rp pushed all the magic stuff into the oe-dev Jan 05 20:16:21 oh ic Jan 05 20:16:23 already Jan 05 20:16:31 so you can start to use it Jan 05 20:16:39 cool Jan 05 20:16:39 even the recipebased checksums Jan 05 20:16:41 woglinde: check -live of that preferred file.. Jan 05 20:16:43 jupp Jan 05 20:17:00 jama I will point you to it Jan 05 20:17:01 mom Jan 05 20:17:03 woglinde: you can remove all preferred versions not listed in -live I guess Jan 05 20:17:40 jama -> http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/xorg-util/util-macros_1.3.0.bb Jan 05 20:18:26 woglinde: ahh BBCLASSEXTEND Jan 05 20:18:46 jupp ged rid of -native recipes Jan 05 20:18:48 yes that would be nice.. but don't point me to it.. Jan 05 20:18:55 and PREF_VERSION Jan 05 20:19:00 for native Jan 05 20:19:05 I don't have much time lately.. so I won't do it any soon Jan 05 20:19:11 damn Jan 05 20:19:13 okay Jan 05 20:19:15 *g* Jan 05 20:19:44 we need to find someone else for this "monkey"-stuff Jan 05 20:20:04 * hrw wants rkirti work to be finished... Jan 05 20:21:14 03Koen Kooi  07org.openembedded.dev * rda196c1fde 10openembedded.git/recipes/ushare/ushare_hg.bb: ushare: adjust for broken hg fetcher in bitbake 1.8.x, 1.10.x works fine Jan 05 20:21:49 hm right the hg fetcher should be fixed somehow Jan 05 20:22:00 I wondered why koen didnt stumble over it Jan 05 20:22:07 as I saw the recipe Jan 05 20:22:15 oh Jan 05 20:22:21 1.8 is only borken Jan 05 20:22:22 hms Jan 05 20:25:08 pb_, is this your handy work? http://www.engadget.com/2010/01/05/pure-bursts-onto-us-scene-with-five-internet-radios/ Jan 05 20:34:08 kgilmer: sadly no, pure don't use our modules. I think they develop all their stuff in house. Jan 05 20:34:45 oh ic pb___ Jan 05 20:35:00 re pb_ Jan 05 20:35:06 i won't buy one of those then :) Jan 05 20:36:18 heh Jan 05 20:36:31 kgilmer *g* Jan 05 20:36:37 the pure radios are quite nice units, despite being our competitors. I wouldn't hold it against you :-) Jan 05 20:38:29 pb___, can you tell us which ones are not your competitor? Jan 05 20:38:41 We've got one of the logitech units Jan 05 20:38:45 the UI sucks though Jan 05 20:41:08 logitech is also not one of ours. I think the main brands that sell our stuff in the USA right now are Grace Digital, Sanyo and Livio. Possibly Sangean too. Jan 05 20:42:12 sorry about that :) Jan 05 20:42:19 that must explain why the UI sucks Jan 05 20:43:31 ironically, it is usually easier for me to say which units are our competitors, since we don't (usually) have any NDA problem with competing products. Jan 05 20:44:07 it is a bit difficult to keep track of which customer products have and haven't been publicly announced so it is difficult to give an exhaustive list of who is selling our units. Jan 05 20:44:45 * kgilmer sees a day where all CE device UIs are on cellphones and not on the devices themselves. Jan 05 20:45:37 rofl Jan 05 20:45:53 my wife bought speakers for her ipod touch, because she can operate it Jan 05 20:46:10 it is kind of ridiculous, both are in the same kitchen Jan 05 20:47:09 bye Jan 05 20:47:11 kgilmer: yeah, a couple of our customers are very keen on using an iPhone as the primary ui for the unit. Jan 05 20:47:56 i use an iphone, and apple remote application is very nice pb___. much better than keyboard/mouse for living room. now I want a similar ui for the reciever, tv, etc. Jan 05 20:48:27 blender, refrigerator, sink, toilet, the list goes on... Jan 05 20:49:01 kgilmer: hmm Jan 05 20:50:14 Makes sense, really. Jan 05 20:51:06 jo khem my friend Jan 05 20:51:11 kgilmer: something like universal remote with display and touch screen Jan 05 20:51:12 drink a beer with me Jan 05 20:51:23 Cheaper to avoid having nice screens in each device and means everything gets remote contorl. Jan 05 20:51:24 woglinde_: prost Jan 05 20:52:49 right khem. i have a universal remote from logic which is really terrible. the general problem is making physical plastics w/ buttons and keeping it simple does not scale past a few similar devices. Jan 05 20:53:01 soft menu systems with multi touch interfaces don't have this limitation. Jan 05 20:53:34 logic = logitec Jan 05 20:54:39 kgilmer: not a bad idea infact Jan 05 20:55:05 use bluetooth or home wifi for devices to talk to it Jan 05 20:57:32 and since it's software it's easy to update the uis, skin, theme etc. Jan 05 20:57:47 companies could charge extra, integrate with social sites, etc Jan 05 20:58:03 JaMa: Can you tell me what conf/distro/include/preferred-xorg-versions-live.inc is? Bleeding edge? Jan 05 21:00:06 Laibsch: it tracks latest releases on xorg download page and its generated by contrib/source-checker/bump.preferred-xorg-versions-live.sh Jan 05 21:00:35 Laibsch: I run that script from time to time.. and it creates recipe templates for new packages and updates this file.. Jan 05 21:00:36 03Khem Raj  07org.openembedded.dev * r2945ae2e39 10openembedded.git/conf/machine/qemumips.conf: Jan 05 21:00:36 qemumips.conf: Set KERNEL_IMAGETYPE to plain vmlinux. Jan 05 21:00:36 * qemu boots vmlinux on mips so set KERNEL_IMAGETYPE Jan 05 21:00:36 and KERNEL_OUTPUT accordingly. Jan 05 21:00:36 Signed-off-by: Khem Raj Jan 05 21:00:38 03Khem Raj  07org.openembedded.dev * r8f7ba7256d 10openembedded.git/recipes/gcc/ (gcc-4.4.2.inc gcc-svn.inc): Jan 05 21:00:42 gcc-4.4.2.inc: Disable decimal float for uclibc configurations. Jan 05 21:00:45 * gcc-svn bump SRCREV Jan 05 21:00:47 Signed-off-by: Khem Raj Jan 05 21:01:29 Laibsch: but now it needs only few handmade changes.. because I don't want to bump xorg-server to latest snapshot which is almost the same as 1.7.3 and also some intel beta driver etc.. Jan 05 21:02:50 does anyone make a ipod touch-like device that can run angstrom? Jan 05 21:02:52 Laibsch: and its as bleeding edge as distro without any include for preferred-xorg.. (almost, last time I checked only difference was pixman_git) Jan 05 21:06:00 xorg 7.4 currently does not build. The latest xineramaproto needs a newer util-macros. I think http://paste.debian.net/55715/ is the right solution. Anybody want to comment before I push this? Jan 05 21:06:45 see also http://tinderbox.openembedded.net/packages/402278/ and http://tinderbox.openembedded.net/public/logs/task/4195600.txt Jan 05 21:10:38 Laibsch no the soultion is to fix preffered-version Jan 05 21:10:46 for xorg7.4 Jan 05 21:11:08 and use it in your distribution Jan 05 21:11:12 woglinde: I thought that is what I did Jan 05 21:11:18 hm let me see Jan 05 21:11:33 Laibsch: yes that pastebin seems right.. Jan 05 21:12:04 laibsch did you check against the xorg7.4 site? Jan 05 21:12:05 Laibsch: I guess you checked that 1.1.2 is right version (at least because it was used in 7.4 before pushing new version to tree Jan 05 21:12:28 JaMa: It's the only other version in OE Jan 05 21:12:34 which is why I picked it Jan 05 21:13:06 BTW, the ushare bb file is still broken Jan 05 21:13:16 XorA|gone: can you kindly let koen know? Jan 05 21:13:40 hm xorg 7,4 site only mentioned libXinerama 1.0.3 Jan 05 21:13:56 but not the protos for xinerama Jan 05 21:14:25 laibsch than thumbs up Jan 05 21:14:28 and check it in Jan 05 21:14:40 hm mom Jan 05 21:15:03 it should go into update Jan 05 21:15:11 args not Jan 05 21:15:36 because there could some one include xorg.74 only and suffer the same problem Jan 05 21:28:04 ping? Jan 05 21:28:08 jo gnutoo Jan 05 21:37:44 re Jan 05 21:37:57 ERROR: Error, lockfile path does not exist!: /home/filip.zyzniewski/pda/oe/build_dir/tmp/work/i686-linux/openssl-0.9.8j-r11.0/packages-split Jan 05 21:38:00 argh Jan 05 21:38:13 and bitbake -c clean openssl-native didn't help Jan 05 21:40:11 filip: which bitbake version are you using Jan 05 21:43:07 khem: BitBake Build Tool Core version 1.8.18, bitbake version 1.8.18 Jan 05 21:44:22 thanks, woglinde and JaMa Jan 05 21:46:34 laibsch no thank you Jan 05 21:47:18 laibsch would be atask for you to convert all x-packages like rp did for poky? Jan 05 21:47:20 http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/xorg-util/util-macros_1.3.0.bb Jan 05 21:48:12 I don't think I'll have the time anytime soon Jan 05 21:48:19 woglinde, hi Jan 05 21:48:40 woglinde, I was eating Jan 05 21:49:08 hey, a recipe versioning question here Jan 05 21:49:29 is it ok for my package to be named package_1.23.bb even if it fetches from git? Jan 05 21:49:53 i assume so because many recipes are like that Jan 05 21:50:14 now, it is correct to name it package_git.bb even if i fetch specifically version 1.23? Jan 05 21:51:04 no, if you specifically fetch 1.23 (by hardcoding that rev in the recipe) then it would be best to name it _1.23. Jan 05 21:51:22 the _git recipes are traditionally "floating" versions not tied to any particular rev Jan 05 21:52:40 pb___, that has been my understanding. i'm in an argument about it, but have been unable to find those versioning conventions written anywhere Jan 05 21:52:46 mrc3: http://wiki.openembedded.org/index.php/Versioning_Policy Jan 05 21:52:49 http://wiki.openembedded.net/index.php/Versioning_Policy is not that specific Jan 05 21:53:19 The question is probably if 1.23 has been released or not Jan 05 21:53:37 mrc3_ if the version is taged Jan 05 21:53:48 it's very released, very tagged, just git is the means to get the code Jan 05 21:53:54 and the git reps has a frontend which offers tar.bz2 Jan 05 21:53:59 OK Jan 05 21:54:01 yoz could try use this as download Jan 05 21:54:08 then I agree that it's 1.23 Jan 05 21:54:23 Otherwise the section "Pitfalls" of above wiki page would apply Jan 05 21:54:29 if the tar.bz2 isnt provided anywhere else Jan 05 21:55:03 woglinde, Laibsch, pb___, thanks! i wanted to confirm we're on the right track Jan 05 21:55:35 mrc3_: they probably aren't written down anywhere, this is just how the convention has grown up over time. but, generally, if what you're fetching is the "1.23" release, the exact mechanism by which you fetch it is irrelevant: you wouldn't call it package_http.bb just because it's downloaded from a website. Jan 05 21:56:02 pb___, hehe i think i'll quote you with that! Jan 05 21:56:43 while we're on that topic, what is the general consensus on PR? i have seen some whacky things used instead of integers Jan 05 21:57:01 we started using "package_cvs.bb" to refer to a floating cvs checkout (generally, of unreleased code) and that gradually spread to _svn, _git and suchlike. but really, there's no need even for the SCM to be specified there: if we were starting over, I would try to use some more generic term. Jan 05 21:57:43 and by whaky with PR i mean something like "r13+FLAG+4.1" Jan 05 21:58:02 PR is, generally, either a single integer. some recipes define PR in terms of something like ${INC_PR}, in which case you end up with two or more integers separated by dots. Jan 05 21:58:15 khem: any hints about the lockfile ;)? Jan 05 21:58:44 * kergoth thinks itd be nice for the "r" in "r0" to just die Jan 05 21:58:56 there are some other wacky PRs floating around but I don't think that is something that you ought to emulate. iirc, most of those are there as workarounds for some or other historical infrastructure deficiency. Jan 05 21:59:27 kergoth: yeah Jan 05 21:59:45 * JaMa likes PR_append = "+gitr${SRCREV}" Jan 05 21:59:53 bletch Jan 05 21:59:57 as its used in few recipes already.. Jan 05 22:00:42 yeah, I still think that belongs in PV if anywhere. Jan 05 22:00:43 pb___: much better than PV = "1.0-${PR}+gitr${SRCREV} imho Jan 05 22:00:54 indeed, that's ghastly too Jan 05 22:01:17 thanks, guys! Jan 05 22:01:35 I would like the most something like PV = "1.0-SCM" and then normal PR with PR_append = "+gitr.... Jan 05 22:01:53 it would be easy to create PREFERRED_VERSION for that Jan 05 22:02:12 personally I don't think there is a whole lot of value in encoding the scm hash into the packaging data anywhere (except SRC_URI of course). Jan 05 22:02:18 always easy to notice that its build from SCM based recipe Jan 05 22:03:02 iirc we talked about it already.. so I guess our opinions haven't changed :) Jan 05 22:03:23 I would stick with PV = "1.0+SCM", PKGV = "1.0+SCM+${@bb.fetch.get_srcrev()}", PR = "r0" Jan 05 22:03:44 ah yeah, you're right, I think we did talk about this before. Jan 05 22:07:18 03Rolf Leggewie  07org.openembedded.dev * r693410e2b8 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.4.inc: Jan 05 22:07:18 preferred-xorg-versions-X11R7.4.inc: pin kbproto-native to 1.0.3 Jan 05 22:07:18 * 1.0.4 needs a newer xorg-util package (same as 314b28b844fd5) Jan 05 22:07:18 * kbproto is already pinned to 1.0.3 Jan 05 22:07:30 03Rolf Leggewie  07org.openembedded.dev * r314b28b844 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.4.inc: Jan 05 22:07:30 preferred-xorg-versions-X11R7.4.inc: pin xineramaproto to 1.1.2 Jan 05 22:07:30 version 1.2 needs a newer xorg-util package Jan 05 22:18:07 khem: please, when you change a .inc, make sure it still works with the versions we have... you converted iptables.inc to autotools, but 1.3.8 remains in our repo and doesn't use autotools. Jan 05 22:24:04 kergoth: hmmm thx for noting. there was another problem in same commit that jeremy laine fixed probably I wasnt in best frame of mind Jan 05 22:24:07 :) Jan 05 22:24:11 hehe Jan 05 22:24:27 no worries, I'll fix it up. syncing more mvl6 recipes up with OE Jan 05 22:24:32 03Rolf Leggewie  07org.openembedded.dev * ra439757609 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.4.inc: Jan 05 22:24:32 preferred-xorg-versions-X11R7.4.inc: pin down bigreqsproto-native and inputproto-native Jan 05 22:24:32 * the latest versions require a newer xorg-utils than available in xorg 7.4 Jan 05 22:24:32 * essentially the same as commit 314b28b844fd5 Jan 05 22:24:32 slooow going Jan 05 22:25:02 kergoth: OK I just tested with the default one and that too quickly Jan 05 22:25:11 * kergoth nods Jan 05 22:25:38 sometimes these are glitches you fix to get something else working and you dont pay much attention :) Jan 05 22:25:59 yeah Jan 05 22:26:57 sometimes formal parameters dont show up correctly in gdb backtrace Jan 05 22:27:22 funny part is same variable gets passed to multitude of functions in stack trace as param 1 Jan 05 22:27:39 in one of these function it loses it all other functions show it correctly Jan 05 22:27:54 I think somewhere gcc dozed off Jan 05 22:27:56 with PREFERRED_PROVIDER_virtual/kernel_shr = "linux-openmoko-2.6.32" in conf/machine/om-gta02.conf, can I override it somehow from local.conf? with unmodified OVERRIDES? Jan 05 22:28:08 PREFERRED_PROVIDER_virtual/kernel_shr_local Jan 05 22:28:49 does that work ? Jan 05 22:29:40 mmt trying.. Jan 05 22:30:16 you need to parse again :( Jan 05 22:30:35 somehow there should be a way that bitbake could incrementally parse stuff Jan 05 22:30:41 like incremental linking :) Jan 05 22:31:08 well it does to a certain extent when we change recipes though Jan 05 22:33:31 khem: yes reparsing.. and -e doesn't make it any faster :) Jan 05 22:39:54 03Denys Dmytriyenko  07org.openembedded.dev * rd11880cc0b 10openembedded.git/recipes/ushare/ushare_hg.bb: ushare: finish fixing for broken hg fetcher in bitbake 1.8.x Jan 05 22:44:07 khem: thanks a lot it works.. (btw PREFERRED_PROVIDER_virtual/kernel_shr_om-gta02 also works _om-gta02_shr which I tried before doesn't) Jan 05 22:44:28 yeah that would be machine override Jan 05 22:45:07 any thoughts on iptables-utils? Jan 05 22:45:12 -save and -restore are part of the main binary now Jan 05 22:45:16 itd just be symlinks Jan 05 22:45:25 lrwxrwxrwx 1 clarson clarson 15 Jan 5 15:35 ../../../tmp/work/i686-mv-linux/iptables-1.4.6-r5.0/package/usr/sbin/ip6tables-restore -> ip6tables-multi* Jan 05 22:47:09 03Rolf Leggewie  07org.openembedded.dev * rd1902fa250 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.4.inc: Jan 05 22:47:09 preferred-xorg-versions-X11R7.4.inc: pin xf86bigfontproto-native to 1.1.2 Jan 05 22:47:09 * version 1.2 needs a newer xorg-util (same as 314b28b844fd5) Jan 05 23:08:46 isn't there some standard machanism in bitbake for creating .md5 files for images in deploy dir? Jan 05 23:09:02 I think it could be usefull.. Jan 06 00:05:55 nite jama Jan 06 00:20:15 has anybody tried newer than 2.6.26-rp kernel on qemuarm ? Jan 06 01:19:14 I'm trying to compile libgphoto2 under Koen's demo Angstrom image on a Beagle Board - and it complains about not having libltdl - how do I install libtool under Angstrom? Jan 06 01:22:10 Hmm. Jan 06 01:24:49 opkg install libtool Jan 06 01:37:27 However, my ./configure script still fails, because it cannot find ltdl.h - which resides in /usr/share/libtool/libltdl, but is being looked for as according to config.log. Jan 06 02:20:01 I see that under Ubuntu 9.04 ltdl.h is in BOTH /usr/include/ AND in /usr/share/libtool/libltdl/ - but after opkg install libtool under Angstrom ltdl.h is ONLY in /usr/share/libtool/libltdl/libltdl/ Jan 06 02:20:14 Is this a packaging/install bug? Jan 06 02:27:46 /usr/include files are never in the main packages, unless the main package is already development specific. dev files go into the -dev packages, not the main ones Jan 06 02:27:58 HI kergoth. Jan 06 02:28:02 hey Jan 06 02:28:21 I'm trying to compile libgphoto2 and gphoto2 under Angstrom, and running into libtool problems. Jan 06 02:28:58 I did opkg install libtool, and still have a failed ./configure Jan 06 02:29:20 you'll have to be more specific than "failed" Jan 06 02:29:23 heh Jan 06 02:29:44 checking ltdl.h usability... no Jan 06 02:29:44 checking ltdl.h presence... no Jan 06 02:29:44 checking for ltdl.h... no Jan 06 02:29:57 I looked at the config.log. Jan 06 02:30:17 The test program is trying #include - which fails. Jan 06 02:30:27 Under Angstrom, that is. Jan 06 02:30:54 Works fine under Ubuntu - which has that particular header file in /usr/include as well as in the libtool area. Jan 06 02:31:01 Angstrom only has it in one place. Jan 06 02:31:18 again, that's because the default packaging splits /usr/include into -dev packages Jan 06 02:31:22 might just be a bug in the libtool packaging then, probably not enough people doing native development. Jan 06 02:31:41 Yes, I suspect so. I was trying to go native rather than cross compile. Jan 06 02:31:43 could probably install libtool-dev for now Jan 06 02:31:43 Sigh. Jan 06 02:31:59 or ask in #angstrom, or try to fix it yourself :) Jan 06 02:32:00 opkg install libtool-dev ?? Jan 06 02:32:05 yep Jan 06 02:32:13 BRB, I'll try Jan 06 02:32:28 nearly every recipe emits the main package, then -dev, and in some cases -doc Jan 06 02:37:20 Hmm... Found that heade now, got an inch further - Jan 06 02:37:33 checking for lt_dlinit in -lltdl... no Jan 06 02:37:33 configure: error: Jan 06 02:37:33 libgphoto2 requires the ltdl library, included with libtool Jan 06 02:37:33 Please make sure that the proper development package is installed Jan 06 02:37:33 (libltdl-dev, libtool-ltdl-devel, etc.) Jan 06 02:38:03 :-) Jan 06 02:40:44 Hmmm. Jan 06 02:41:03 opkg install libtool-ltd Jan 06 02:41:03 l-devel Jan 06 02:41:03 Collected errors: Jan 06 02:41:03 * Cannot find package libtool-ltdl-devel Jan 06 02:42:12 Hmm. Jan 06 02:59:52 hi holger **** ENDING LOGGING AT Wed Jan 06 02:59:57 2010