**** BEGIN LOGGING AT Sat Apr 01 10:59:57 2006
Apr 01 11:06:30 <RP> hi mickeyl 
Apr 01 11:06:46 <mickeyl> hey RP
Apr 01 11:08:56 <pb_> mickeyl: none
Apr 01 11:09:09 <mickeyl> pb_: *sigh* i was afraid of you telling that
Apr 01 11:09:11 <pb_> calling autoreconf is, unfortunately, pretty much obligatory when libtool is involved
Apr 01 11:09:44 <mickeyl> ok, so i need to take that up with upstream
Apr 01 11:10:00 <mickeyl> thanks
Apr 01 11:10:06 <pb_> yeah, that'd be best
Apr 01 11:11:00 <pb_> you could try just calling aclocal and autoconf directly, and avoiding automake.  it's possible (though unlikely, I think) that this would be sufficient to work around your problem
Apr 01 11:12:12 <mickeyl> tetex is a b****
Apr 01 11:12:28 * mickeyl prepares a mail to Thomas Esser, the TE in tetex
Apr 01 11:16:42 <CoreDump|home> hi
Apr 01 11:18:25 <mickeyl> hmm, when I force it to using our libtool via
Apr 01 11:18:51 <mickeyl> LIBTOOL="${STAGING_BINDIR}/${TARGET_PREFIX}libtool" it appears to go further but bails out in
Apr 01 11:18:59 <mickeyl> | arm-linux-libtool: link: `package.lo' is not a valid libtool object
Apr 01 11:19:02 <mickeyl> ever seen that?
Apr 01 11:19:29 <pb_> mm, no, haven't seen that
Apr 01 11:19:42 <pb_> I have no idea what might be going on there
Apr 01 11:19:52 <mickeyl> sounds like an upstream problem as well
Apr 01 11:19:57 <pb_> yeah
Apr 01 11:20:11 <pb_> kergoth might know more about that error, but I guess he is asleep at the moment
Apr 01 11:26:13 <TheMasterMind1> any clue what could be going on here, i'm stumped: http://pastebin.com/634043
Apr 01 11:41:57 <pb_> hail zecke
Apr 01 11:45:13 <polyonymous> is there a recommended bitbake revision?
Apr 01 11:46:28 <polyonymous> I updated bitbake yesterday and now it fails at parse
Apr 01 11:47:25 <mickeyl> rm -rf tmp/cache
Apr 01 11:47:58 <polyonymous> I've already done mv tmp tmp-away
Apr 01 11:48:10 <mickeyl> no idea then
Apr 01 11:48:18 <mickeyl> removing the cache did it for me
Apr 01 11:48:42 <zecke> mickeyl: hey
Apr 01 11:48:47 <mickeyl> hi zecke
Apr 01 11:49:01 <polyonymous> Hmm.. I also updated oe, but I'm not sure the problem is there...
Apr 01 11:49:08 <zecke> polyonymous: what does fail to parse mean?
Apr 01 11:49:19 <zecke> polyonymous: did you read oe@hh.org or bitbake-dev?
Apr 01 11:49:32 <polyonymous> nope.
Apr 01 11:50:03 <polyonymous> and fail to parse means that bitbake -i / parse leads to lots of errors
Apr 01 11:50:14 <zecke> polyonymous: what errors?
Apr 01 11:50:31 <polyonymous> NOTE: Handling BitBake files: | (2860/2861) [99 %]NOTE: exceptions.SyntaxError:EOL while scanning single-quoted string (line 1) while evaluating:
Apr 01 11:50:42 <polyonymous> For many files, I suppose, all file
Apr 01 11:50:45 <polyonymous> files
Apr 01 11:53:05 <zecke> better find that out?
Apr 01 11:53:23 <polyonymous> Ah, wait.
Apr 01 11:53:45 <polyonymous> NOTE: Parsing finished. 0 cached, 2562 parsed, 68 skipped, 0 masked. -- is skipped about failed files?
Apr 01 11:54:44 <mickeyl> no, skipped is something else
Apr 01 11:54:51 <polyonymous> Ah, okay.
Apr 01 11:55:41 <mickeyl> skipped i.e. because your target is not compatible with the package
Apr 01 11:55:43 <mickeyl> e.g. grub is x86 only
Apr 01 11:56:02 <polyonymous> I see. Nevermind then, that was just a guess.
Apr 01 11:56:33 <polyonymous> Well, anyway, basically it comes down to scanning single quoted strings
Apr 01 11:57:35 <zecke> polyonymous: that is likely to be a CVSDATE when it should read SRCDATE
Apr 01 11:58:02 <polyonymous> Here is the last file failed, for instance: http://pastebin.com/634069
Apr 01 11:58:41 <polyonymous> zecke, what? Or better where? :)
Apr 01 11:59:02 <zecke> polyonymous: oh well, use bitbake r329 for the oz354 branch or a released version
Apr 01 11:59:14 <zecke> polyonymous: koen or hrw might correct me for the version
Apr 01 11:59:29 <polyonymous> Ah, that was my question a while ago, if there is a recommended revision :)
Apr 01 11:59:32 <polyonymous> thanks, I'll try.
Apr 01 12:01:31 <polyonymous> parsing with r329
Apr 01 12:08:50 <polyonymous> parsed fine. I'll go have tea now :) Thanks guys.
Apr 01 12:12:28 <CoreDump|home> [http://www.userfriendly.org/cartoons/archives/06apr/uf009001.gif] =)
Apr 01 12:14:24 <mickeyl> heh, that's mean
Apr 01 12:14:59 <zecke> polyonymous: you are welcome
Apr 01 12:27:05 <zecke> uv1: I think your 2005 version is for Qt3
Apr 01 12:27:21 <zecke> uv1: and konqueror embedded is unmaintained
Apr 01 12:29:16 <uv1> zecke: OK. Just reported a bug regarding GPE (qemu build docs package) and provide a patch to avoid that (bug ID 801). Could you please check that in ?
Apr 01 12:29:34 <zecke> uv1: I'm not responsible for GPE
Apr 01 12:30:38 <uv1> zecke: Who is ?
Apr 01 12:31:05 <zecke> uv1: your patch has nothing to do with GPE?!
Apr 01 12:31:36 <uv1> zecke: No, exept that gpe-image builds now on my host ;-)
Apr 01 12:31:44 <uv1> zecke: Just a qemu patch.
Apr 01 12:31:47 <zecke> uv1: okay
Apr 01 12:31:54 <zecke> uv1: Isn't qemu using autotools?
Apr 01 12:32:04 <zecke> uv1: in that case patching a Makefile is not too smart
Apr 01 12:33:03 <uv1> zecke: Could not find out really. At least "qemu-qop-nogfx-native_svn.bb" builds after a clear with that patch.
Apr 01 12:33:43 <zecke> uv1: sorry to nitpick :)
Apr 01 12:33:43 <uv1> zecke: So I assume, that for some reason the Makefile is not rebuild during configure.
Apr 01 12:33:59 <zecke> uv1: 1. it is not GPE, 2. texi2html is ASSUMED_PROVIDED
Apr 01 12:34:32 <uv1> zecke: So you say remove the ASSUME_PROVIDED would help ? How can I do ?
Apr 01 12:34:50 <uv1> zecke: BTW does it make sence to build docs packages during a OE build ?
Apr 01 12:34:57 <zecke> uv1: lol
Apr 01 12:35:09 <zecke> uv1: no OE requires texi2html to be present
Apr 01 12:35:21 <zecke> uv1: this is what our ASSUME_PROVIDED line indicates
Apr 01 12:35:36 <uv1> zecke: Any ideas how to get that (Debian Sarge)
Apr 01 12:36:31 <zecke> uv1: wait a second
Apr 01 12:36:33 <pb_> "apt-get install texi2html"?
Apr 01 12:36:35 <pb_> just guessing
Apr 01 12:37:05 <zecke> tetex sounds good as well
Apr 01 12:37:21 <zecke> tetex-doc sounds better
Apr 01 12:37:42 <zecke> uv1: packages.debian.org is quite good as well
Apr 01 12:38:12 <zecke> lol
Apr 01 12:39:27 <zecke> uv1: sorry to nitpick further: qemu-qop-nogfx-native_svn.bb is an existing file?
Apr 01 12:39:27 <uv1> texi2html ;-) Any other new SW required ? I have to update www.uv-ac.de/openembedded/
Apr 01 12:39:50 <uv1> zecke: in qemu (snapshot from this moning)
Apr 01 12:40:01 <zecke> uv1: in that case attach patches
Apr 01 12:40:09 <zecke> sorry for this nitpicking
Apr 01 12:40:44 <uv1> Sorry I asked that in #GPE ;-) You still want to have a patch ?
Apr 01 12:42:19 <zecke> uv1: http://ewi546.ewi.utwente.nl/tmp/viewmtn/file.psp?id=673bca9251529537e80eaed829b3fd18917250e8&path=conf/bitbake.conf
Apr 01 12:42:33 <zecke> uv1: find ASSUME_PROVIDED
Apr 01 12:42:40 <zecke> uv1: this is the software OE currently requires
Apr 01 12:44:22 <uv1> zecke: Thanks, will take that into account.
Apr 01 12:46:22 <uv1> Just struggled about another bug. "linux-jlime-sh3_2.6.11.bb" does not file "http://www.jlime.com/downloads/releases/shrek/kernels/6xx/sources/linuxsh-snapshot-050320-jlimepatched-3.tar.bz2" as "Releases" need Upper Case "R" ;-)
Apr 01 12:46:42 <uv1> Someone here to do a quick fix ?
Apr 01 12:47:51 <uv1> Though I do not understand, why this kernel is build / needed for my collie machine ;-( Any ideas ?
Apr 01 12:48:06 <mickeyl> bitbake -v should give you the necessary insights
Apr 01 12:48:08 <zecke> uv1: you don't have a gcc 2.95 compiler
Apr 01 12:48:32 <uv1> zecke: No, hours ago gcc 3.4.4 was build.
Apr 01 12:49:41 <uv1> Found out. multiple providers are available (linux-jlime-sh3, ... Just takes the first found ;-(
Apr 01 12:50:42 <uv1> Is that, because I want to build familiar for a collie ?
Apr 01 12:51:23 <mickeyl> shouldn't be. it's more likely that you are missing a PROVIDER, because collie.conf exactly defines the preferred provider for its kernel
Apr 01 12:51:53 <mickeyl> out of interest, why familiar? i think building openzaurus would make more sense for a collie
Apr 01 12:51:56 <zecke> mickeyl: so collie 2.4er kernel does not need a gcc 2.95 any more?
Apr 01 12:52:24 <mickeyl> zecke: no, it still needs one. my response was to "just takes the first found"
Apr 01 12:52:57 <uv1> Ah. 2.4 kernel as PREFERRED. I need that machine run 2.6 and assume, thats not possible yet ?
Apr 01 12:53:37 <mickeyl> right, 2.6 is pretty experimental on collie at that time. unless you want to help developing it won't be of any use
Apr 01 12:54:47 <uv1> mickeyl: I need a device with 240x320 together with a 2.6 kernel and X11 as an example for another target. What means experimental here. Does anything work at leat more or less  ?
Apr 01 12:54:59 <mickeyl> no
Apr 01 12:55:21 <uv1> Thanks mickeyl.
Apr 01 12:55:25 <mickeyl> np
Apr 01 12:56:00 <mickeyl> 240x320 w/ 2.6 sounds like a good job for one of the ipaqs
Apr 01 12:56:04 <zecke> uv1: what about using Xephyr?
Apr 01 12:56:06 <mickeyl> not the old ones, though
Apr 01 12:56:31 <zecke> uv1: or using qemu for demoing?
Apr 01 12:57:05 <uv1> Have an ipaq, but only 3600. I assume thats too old ?
Apr 01 12:57:38 <uv1> zecke: Do we have a machine / distro config for a qemu-arm image ?
Apr 01 12:58:34 <CoreDump|home> is anyone here familiar with /etc/keylaunch's syntax?
Apr 01 12:59:02 <zecke> uv1: yes that it too old
Apr 01 12:59:07 <zecke> uv1: check the wiki for qemu
Apr 01 12:59:19 <zecke> uv1: or just use Xephyr on your desktop
Apr 01 12:59:57 <uv1> zecke: Xephyr ?
Apr 01 13:00:27 <zecke> ~google Xephyr
Apr 01 13:01:18 <uv1> Thanks for help and bye for now
Apr 01 13:05:27 <CIA-4> 03mickeyl 07org.oe.dev * r12f0dadb... 10/packages/lyx/ (lyx_1.3.6.bb lyx_1.4.0.bb): 
Apr 01 13:05:27 <CIA-4> lyx: update to 1.4.0
Apr 01 13:05:27 <CIA-4> we're fetching the svn version now, because the tarball doesn't contain
Apr 01 13:05:27 <CIA-4> the necessary bits to autoreconf.
Apr 01 13:07:48 <pb_> doh, crazy upstream maintainers
Apr 01 13:07:59 <pb_> it's always annoying when they leave stuff like that out of the disted tarballs
Apr 01 13:09:39 <zecke> I wonder what uv is working on...
Apr 01 13:36:52 <zecke> cya later
Apr 01 17:00:50 <hhhcz> hi all, i have a problem compiling openzaurus 3.5.4
Apr 01 17:01:42 <hhhcz> intltool-native fails to find XML::Parser, although it seems to have been installed
Apr 01 17:01:58 <hhhcz> http://pastebin.com/634419
Apr 01 17:06:26 <mickeyl> i recommend checking config.log for details
Apr 01 17:10:54 <reenoo> evening
Apr 01 17:12:48 <reenoo> lamikr: mind if I check in a fix for h6300.conf? a few things don't belong in there and the include path to tune-arm9tdmi.conf is wrong.
Apr 01 17:14:42 <mickey|writing> hey REdOG
Apr 01 17:14:44 <mickey|writing> ups
Apr 01 17:14:49 <mickey|writing> hey reenoo as well
Apr 01 17:15:01 <reenoo> hey mickey|writing 
Apr 01 17:15:28 <hhhcz> mickeyl: config.log doesn't say much...
Apr 01 17:32:34 <CIA-4> 03xora 07org.oe.dev * r7399b613... 10/packages/ (gnome/goffice_0.2.1.bb gnumeric/gnumeric_1.6.3.bb): 
Apr 01 17:32:34 <CIA-4> goffice_0.2.1.bb, gnumeric_1.6.3.bb : New versions of these.
Apr 01 17:32:34 <CIA-4> Also fixed the problem with gnumeric packaging where is depended on
Apr 01 17:32:34 <CIA-4> gnumeric-dev.
Apr 01 17:33:58 <CSMan> hello
Apr 01 17:34:10 <CSMan> in a build system like bitbake, how do I deal with INCLUDE files that are not currently installed, but are available in packages previously built ?
Apr 01 17:34:14 <XorA|gone> CSMan: fix the .bb that produced the includes to stage them
Apr 01 17:34:57 <CSMan> you mean, i have to specify the includes in the .bb file instead of the Makefile ?
Apr 01 17:35:39 <CIA-4> 03rw 07org.oe.oz354fam083 * r1639fd40... 10/packages/alsa/alsa-driver_0.9.6-hh4c.bb: alsa-driver: adjust KERNEL_CC to include HOST_CC_ARCH so bit-flipping operations on registers will work. make MAINTAINER reflect de-facto situation.
Apr 01 17:36:05 <XorA|gone> CSMan: when a .bb stages it copies the include in ${STAGING_INCDIR} if a bb isnt doing this for the include you need, you need to add some lines to do_stage() to do this
Apr 01 17:36:56 <XorA|gone> CSMan: if you includes are already in staging then you just need to find out how to pass -I${STAGING_INCDIR} to your makefile
Apr 01 17:38:01 <CSMan> if i do it in do_stage() will that automatically export those includes ?
Apr 01 17:38:21 <XorA|gone> CSMan: have you looked in tmp/staging ?
Apr 01 17:38:32 <CSMan> let's see...
Apr 01 17:39:04 <XorA|gone> CSMan: comparing the contents of tmp/staging/amr-linux/include with the .bb files that filled it should show you the method
Apr 01 17:39:15 <XorA|gone> s/amr/arm/
Apr 01 17:39:22 <CSMan> i'll take a look and see what I can grasp
Apr 01 17:39:29 <XorA|gone> assuming your doing an arm build that is
Apr 01 17:39:36 <CSMan> indeed
Apr 01 17:40:28 <CSMan> well yeah, i have a lot of stuff in staging/arm-linux/include
Apr 01 17:40:47 <CSMan> gtk's dirs are there also
Apr 01 17:41:13 <CSMan> so i just have to pass -I${STAGING_INCDIR}
Apr 01 17:41:55 <XorA> CSMan: basically yes, but it depends on your exact situation how to do that for your build
Apr 01 17:42:21 <CSMan> it's a local tiny build
Apr 01 17:42:45 <XorA> CSMan: try $(CC) $(CFLAGS) in your Makefile
Apr 01 17:42:55 <CSMan> it'd be so different if at least I get a pentium II machine =P
Apr 01 17:45:11 <XorA> suppose its time to feed me :-)
Apr 01 17:45:38 <CSMan> thanks XorA|gone 
Apr 01 17:55:08 <zecke> http://partners.trolltech.com/partners/directory/lineo.html
Apr 01 17:55:09 <zecke> lol
Apr 01 18:01:45 <CIA-4> 03rw 07org.oe.oz354fam083 * r254be142... 10/packages/ (10 files in 8 dirs): matchbox-(common,desktop,panel), gpe-session-scripts: include patches to fix hh.org Bug #1462 (remove Utilities, add Media category) from .dev
Apr 01 18:06:13 <CIA-4> 03rw 07org.oe.oz354fam083 * r6407bfe5... 10/packages/matchbox-panel/ (3 files in 2 dirs): matchbox-panel: add patches courtesy of Phil Blundell to the tree instead of downloading them.
Apr 01 18:10:44 <zecke> koen|away: could you install gvim? :}
Apr 01 18:12:10 <zecke> koen|away: or (x)emacs?
Apr 01 18:20:30 <zecke> ljp: hey
Apr 01 18:20:37 <zecke> ljp: can I ask you a question?
Apr 01 18:20:49 <zecke> ljp: I'm watching a diff between qte-2.3.10 and qte-rsync
Apr 01 18:21:08 <zecke> ljp: I see many white space changes in qpeapplication_qws.cpp, did you change the policy on that?
Apr 01 18:23:31 <zecke> RP: I think it can be easy to fix QtE for the Integrator
Apr 01 18:24:08 <RP> zecke: That sounds good :)
Apr 01 18:24:48 <zecke> RP: I just changed my mind :)
Apr 01 18:25:04 <zecke> RP: but still, it looks like a matter of touching N files, where N is relative small 2-4
Apr 01 18:25:24 <RP> That doesn't sound too bad...
Apr 01 18:27:00 <zecke> RP: A workaround could be, drive the screen at 8 Bit
Apr 01 18:27:36 <CSMan> what would be a do_stage directive to get my includes in the staging dir ?
Apr 01 18:28:18 <zecke> RP: forgot what I have claimed... it is tough
Apr 01 18:28:37 <zecke> oh well, at least it looks challenging -> file it into my task tracker
Apr 01 18:30:34 <RP> zecke: Alternatively, you change the kernel and qemu to use RGB...
Apr 01 18:30:55 <zecke> RP: hehe, and send Russell a kernel patch :}
Apr 01 18:32:41 <zecke> "Dear Russell, you need to admit breaking the kernel is easier than fixing Qt. Please include the following patch..."
Apr 01 18:32:42 <RP> zecke: I can just imagine the response...
Apr 01 18:33:34 * RP -> food
Apr 01 18:45:03 <zecke> mickey|writing: QtE2 has IPv6 support
Apr 01 19:04:54 <Jin^eLD> hi, did anyone here try XDirectFB? I am struggling to get it to work on my embedded platform :> maybe someone has a few hints or something..
Apr 01 19:05:23 <zecke> Jin^eLD: No, I think we don't even a build description in OE for it
Apr 01 19:05:47 <Jin^eLD> but you guys do have Kdrive, right? anyone tried Xsdl? :>
Apr 01 19:06:00 <zecke> yes we can build kdrive
Apr 01 19:06:06 <zecke> we even have Xqt
Apr 01 19:07:49 <Jin^eLD> hmm ok a different question... Kdrive running on nodmral framebuffer deivce.. on 16bpp it looks ok but displays only half the size on the X axis, like the screen is scaled in half; with 24 and 32 bpp it's weird/blinking/etc, something wrong.. any ideas?
Apr 01 19:08:09 <zecke> no
Apr 01 19:09:55 <Jin^eLD> hm )
Apr 01 19:10:25 <Jin^eLD> well, thanks anyway, I guess I have some debugging to do :P
Apr 01 19:36:13 <lamikr> reenoo: You are fixing h6300 conf in 083? Go ahead, I noticed that some of the apps took draw qpe libs within. Can you anyway left the gomunicator to gpe-image?
Apr 01 19:38:30 <mithro> hey zecke 
Apr 01 19:57:45 <zecke> hey mickey|writing 
Apr 01 19:57:47 <zecke> hey mithro 
Apr 01 19:58:40 <mithro> gnome just keeps getting nicer and nicer
Apr 01 20:02:06 <zecke> yes the millions of money invested to it slowly pay off
Apr 01 20:23:19 <CIA-4> 03rw 07org.oe.oz354fam083 * r7a945d4c... 10/conf/machine/h6300.conf: 
Apr 01 20:23:19 <CIA-4> h6300.conf: remove stuff that doesn't belong in a MACHINE.conf. fix include path to tune-arm9tdmi.conf.
Apr 01 20:23:19 <CIA-4>  - PREFERRED_PROVIDER_libsdl is a per-build-tree setting, please set it in
Apr 01 20:23:19 <CIA-4>  local.conf or similar
Apr 01 20:23:19 <CIA-4>  - ENABLE_BINARY_LOCALE_GENERATION is a DISTRO decision (enabled by familiar.conf btw)
Apr 01 20:23:19 <CIA-4>  - ASSUME_PROVIDED is a per-build-host setting, you could set it in site.conf (or local.conf)
Apr 01 20:23:21 <reenoo> lamikr: yah, the point is that the settings in question are per-build-tree or per-build-machine
Apr 01 20:25:57 <reenoo> lamikr: as for gomunicator, I haven't touched anything but the stuff mentioned in the commit message
Apr 01 20:36:32 * RP returns
Apr 01 20:47:23 <lamikr> reenoo: Ok, that's fine. Are you btw. building h6300 image for test?
Apr 01 20:47:58 <reenoo> yeah
Apr 01 20:51:46 <reenoo> haven't rebuilt gpe images after your h6300.conf changes but I'm about to do so now
Apr 01 20:52:10 <lamikr> reenoo: Could you try to check from the pre-build image why the /etc/modules is not generated automatically for h6300. I think we have everything what is needed in /etc/modutils dir.
Apr 01 21:01:11 <reenoo> lamikr: not sure. the postinst of the modules should run update-modules
Apr 01 21:03:26 <lamikr> Yes, I know koen told me also that the "ipkg-cl" should execute the "update-modules" but it did not do that for me. If I run "update-modules" manually, it will generate that ok.
Apr 01 21:05:42 <lamikr> reenoo: I thought it would not happen because of the "oom" but it happened for me also after glibc locale generation fixed the oom issue for me.
Apr 01 21:12:15 <zecke> hrw|gone: mickey|writing CoreDump|afk : I'm done with merging
Apr 01 21:12:38 <zecke> hrw|gone: mickey|writing CoreDump|afk : once I have updated my OE.db I will push that change and I would like you to test them
Apr 01 21:41:47 <CIA-4> 03rw 07org.oe.oz354fam083 * re881d8fe... 10/packages/linux/ (2 files in 2 dirs): handhelds-pxa: add -hh41 courtesy of Erik Hovland.
Apr 01 21:51:17 <CIA-4> 03rw 07org.oe.oz354fam083 * r810eb211... 10/packages/opie-bluepin/ (opie-bluepin-1.2.1/bluepin opie-bluepin_1.2.1.bb): opie-bluepin: add bluepin wrapper script courtesy of Erik Hovland in OE bug #794.
Apr 01 21:52:52 <CIA-4> 03freyther 07org.oe.dev * rcc6dde24... 10/packages/qte/ (qte-2.3.10/kernel-keymap.patch qte_2.3.10.bb): (log message trimmed)
Apr 01 21:52:52 <CIA-4> packages/qte/qte_2.3.10:
Apr 01 21:52:52 <CIA-4>  Thanks to the ROAD GmbH we now have a bugfixed
Apr 01 21:52:52 <CIA-4>  QtE kernel-keymap.patch
Apr 01 21:52:52 <CIA-4>  Bugfixes:
Apr 01 21:52:53 <CIA-4>  -Handle keys > 127 (7Bit)
Apr 01 21:52:55 <CIA-4>  -Workaround broken keymaps
Apr 01 21:53:36 <jnc> RP: how are you?
Apr 01 21:54:02 <jnc> maybe i mean to ask, how busy are you this April?
Apr 01 21:55:14 <CIA-4> 03freyther 07org.oe.dev * r78651619... 10/packages/qwt/qwt_4.2.0rc1.bb: 
Apr 01 21:55:14 <CIA-4> packages/qwt:
Apr 01 21:55:14 <CIA-4>  We need a better selection handling. This version of QWT
Apr 01 21:55:14 <CIA-4>  is meant to be used by QtE2.
Apr 01 21:55:14 <RP> jnc: good question. It depends how many things I try and do I guess :)
Apr 01 21:55:14 <CIA-4>  We need to define -DQWS for QtE builds otherwise we will
Apr 01 21:55:16 <CIA-4>  have references to symbols found in the x11 edition
Apr 01 21:56:00 <jnc> RP: the person i was selling my C3000 to backed out, i will have it a little while longer
Apr 01 21:56:21 <RP> jnc: ok, I'll try and get to that code...
Apr 01 21:56:21 <jnc> eager to see working suspend/resume on it
Apr 01 21:56:38 <jnc> thanks.  how are your submissions to lkml going?
Apr 01 21:57:02 <RP> jnc: The LED, RTC and backlight patches will be in 2.6.17
Apr 01 21:57:11 <jnc> yay!
Apr 01 21:57:46 <jnc> congratulations on that.  
Apr 01 21:58:17 <RP> jnc: thanks :)
Apr 01 21:58:38 <RP> I'm slowly getting things done - I'll have to make another raft of LED patches now of course...
Apr 01 21:58:58 <jnc> oh, yes.   is it busy work, or must you know what the code does
Apr 01 21:59:08 <jnc> i'm good at grafting patches though i don't know what the code is doing
Apr 01 22:02:21 <RP> It just seems to always take me an age to fine tune patches...
Apr 01 22:18:12 <zecke> RP: well, other people would just give up!
Apr 01 22:18:23 <zecke> RP: I think this is the famous 10% :)
Apr 01 22:32:09 <reenoo> hrm. didn't the fetcher at some point try to download regular tarballs from CVS_TARBALL_STASH as well?
Apr 01 22:34:03 <zecke> reenoo: regular in what sense?
Apr 01 22:34:34 <reenoo> SRC_URI = "http://foo.bar/baz.tar.gz"
Apr 01 22:35:40 <reenoo> I need it to look for baz.tar.gz at $VAR/baz.tar.gz
Apr 01 22:35:59 <kergoth> thats what MIRRORS/PREMIRRORS are. uses a regex to determine what $VAR is
Apr 01 22:36:20 <reenoo> hey kergoth 
Apr 01 22:36:23 <kergoth> hey
Apr 01 22:38:23 <reenoo> hmm
Apr 01 22:38:40 <reenoo> is a PREMIRRORS_prepend () { ... legal in a .conf?
Apr 01 22:39:12 * reenoo tries
Apr 01 22:41:24 <reenoo> that would be a no >:)
Apr 01 22:42:04 <pb_> g'day kergoth
Apr 01 22:42:09 <pb_> hi reenoo 
Apr 01 22:42:18 <reenoo> yo pb_ 
Apr 01 22:42:23 <zecke> reenoo: put them in a .inc :}
Apr 01 22:43:02 <reenoo> zecke: working on that right now
Apr 01 22:46:15 <pb_> reenoo: I'm pretty sure the fetcher never went to CVS_TARBALL_STASH for anything other than cvs and svn URIs.
Apr 01 22:47:11 <reenoo> pb_: yah, I was mixing something up there I guess. MIRRORS contains oesources.org which is what CVS_TARBALL_STASH is usually set to.
Apr 01 22:47:41 <pb_> ah right.  yeah, I can see how confusion could set in there.
Apr 01 22:52:45 <reenoo> kergoth: thanks for the pointer btw. waiting for bitbake to re-parse stuff now...
Apr 01 22:53:13 <kergoth> np
Apr 01 22:54:35 <like2wise> bye bye all
Apr 01 22:56:54 <reenoo> ok, that worked :)
Apr 01 22:57:43 <zecke> kewl
Apr 01 23:54:20 * NAbyss laughs.. http://www.userfriendly.org/cartoons/archives/06apr/xuf009001.gif
Apr 01 23:55:29 <reenoo> heh
Apr 01 23:55:42 <reenoo> that is so... yesterday :P
Apr 01 23:56:06 <NAbyss> reenoo: Yeah, but what else do you expect for a site hosted in such a distant timezone? :)
Apr 02 00:22:38 <CIA-4> 03rw 07org.oe.oz354fam083 * r9374fbdb... 10/packages/familiar/familiar-version.bb: familiar-version: unset MAINTAINER. fix PACKAGE_ARCH. allow DISTRO_VERSION to be that of a release candidate. rename do_compile to do_install.
Apr 02 00:22:45 <CIA-4> 03rw 07org.oe.oz354fam083 * r660c67df... 10/conf/distro/familiar.conf: familiar.conf: really set MAINTAINER.
Apr 02 00:40:39 <zecke> nite guys
Apr 02 00:43:34 <reenoo> 'night zecke 
Apr 02 00:47:22 <zecke> damn
Apr 02 00:47:30 <zecke> time to sleep...
Apr 02 00:48:33 <reenoo> :q
Apr 02 00:48:36 <reenoo> err
Apr 02 00:48:56 <reenoo> time to go to bed indeed it seems
Apr 02 00:49:35 <zecke> I have three unsuccessful ubuntu installations :}
Apr 02 00:49:42 <zecke> a
Apr 02 00:49:49 <zecke> all fail to install grub/lilo
Apr 02 00:51:25 <koen|away> ~[5~[5~[5~[5~[6~[5~[5~[5~[5~[5~
Apr 02 01:26:59 <CIA-4> 03rw 07org.oe.oz354fam083 * r0cd4208b... 10/conf/distro/familiar.conf: familiar.conf: add DEFAULT_MAINTAINER and make MAINTAINER default to it.
Apr 02 01:27:03 <CIA-4> 03rw 07org.oe.oz354fam083 * re7b30323... 10/classes/gpe.bbclass: gpe.bbclass: really override MAINTAINER.
Apr 02 01:54:42 <jnc> hmm
Apr 02 01:54:57 <jnc> is there a build server for OE devs?
Apr 02 04:25:07 <Jason_Foss> Ping.
Apr 02 05:40:39 <jnc> pong
Apr 02 07:40:04 <CoreDump|home> morning
Apr 02 07:56:42 <RP> morning all
Apr 02 07:57:11 <_law_> morning RP
Apr 02 08:19:41 <CoreDump|home> hi RP 
Apr 02 08:30:25 <do13> morning all
Apr 02 08:32:30 <CoreDump|home> hi do13 
Apr 02 08:32:53 <do13> hey CoreDump|home 
Apr 02 08:55:04 <Cockroach-> monring
Apr 02 08:55:17 <Cockroach-> ... 
Apr 02 09:08:18 <CoreDump|home> ~lart collie
Apr 02 09:08:18 * ibot blasts collie to oblivion with a kamehameha wave
Apr 02 09:11:01 <johnX> for the situation with SD? or something else?
Apr 02 09:11:49 <CoreDump|home> just for its small flash
Apr 02 09:12:58 <johnX> ah
Apr 02 09:13:56 <CoreDump|home> collies display looks like crap after you've worked with sl-cxxxx
Apr 02 09:14:14 <johnX> yeah I know
Apr 02 09:14:21 <johnX> I have both on my desk right now
Apr 02 09:14:37 <johnX> I kinda like the collie form factor though
Apr 02 09:14:57 <CoreDump|home> yep same here
Apr 02 09:15:03 <johnX> almost makes me want to see my car and get a 6000
Apr 02 09:15:11 <CoreDump|home> lol
Apr 02 09:15:25 <CoreDump|home> I've gotten used to the clamshell design
Apr 02 09:15:30 <johnX> sell my car rather
Apr 02 09:15:53 <CoreDump|home> but nothing beats protrait for e-book reading =)
Apr 02 09:16:03 <johnX> or one handed operation
Apr 02 09:16:08 <CoreDump|home> indeed
Apr 02 09:16:50 <johnX> rather than the hardware differences that's the thing that makes me think of the 5500 as a PDA, and the clamshells as mini-laptops
Apr 02 09:17:02 * CoreDump|home nods
Apr 02 09:17:13 <CoreDump|home> 400MHz sure is better
Apr 02 09:17:49 <johnX> landscape 640x480 is so nice after you come to expect it
Apr 02 09:17:58 <CoreDump|home> indeed!
Apr 02 09:18:00 <johnX> especially for X11
Apr 02 09:18:13 <CoreDump|home> GPE on collie stinks heh
Apr 02 09:18:25 <CoreDump|home> GPE on VGA is very nice tho
Apr 02 09:18:30 <johnX> I agree
Apr 02 09:18:46 <johnX> my collie still has opie, my akita has the latest gpe out of .dev
Apr 02 09:18:56 * CoreDump|home is working on his collie image. Even tho he isn't motivated at all
Apr 02 09:19:12 <CoreDump|home> same here lol
Apr 02 09:19:22 <CoreDump|home> ok not GPE from .dev 
Apr 02 09:19:40 * johnX lives on the edge
Apr 02 09:19:51 <CoreDump|home> which SL-Cxxxx do you own?
Apr 02 09:19:58 <johnX> Akita
Apr 02 09:20:06 <CoreDump|home> same as me then
Apr 02 09:20:38 <johnX> I don't really like the thought of moving parts in mobile electronics
Apr 02 09:20:55 <johnX> and I didn't have the money at the time
Apr 02 09:21:42 * CoreDump|home 's akita was donated. 
Apr 02 09:21:59 <CoreDump|home> I couldn't have bought it as I'm uber broke
Apr 02 09:24:05 <johnX> I'd had a good job that summer and I diverted funds that would have gone to upgrading my desktop
Apr 02 09:26:39 <CoreDump|home> heh my desktop needs to survive a few more years =)
Apr 02 09:44:20 <Cockroach-> Hmm. I might need an advice
Apr 02 09:46:04 <Cockroach-> If anyone has ideas on how to develope software on x86 platform first. I mean, I have built meta-sdk for x86 and gpe-image for x86, but I'm not sure what would be the right way to go from there. chroot:ing to the gpe-image rootfs directory doesn't allow me to run matchbox (segfaults).
Apr 02 09:46:37 <Cockroach-> maybe building an linux-uml package and trying to run the gpe-image .ext2 from there?
Apr 02 09:46:54 <Cockroach-> Really don't know
Apr 02 09:47:40 <pb_> Chrooting to the gpe-image directory ought to work fine.  I guess your matchbox problem is due to a bug.
Apr 02 09:48:37 <Cockroach-> I lack knowledge and experience in this area, so do I need to address the /dev issue?
Apr 02 09:48:43 <Cockroach-> since chrooting I lose access to the /dev
Apr 02 09:52:50 <Cockroach-> And a fast test trying to build the linux-uml failed
Apr 02 09:54:43 <RP> Cockroach-: You could experiment with the qemuarm images
Apr 02 09:55:41 <Cockroach-> Well, I'm running out of time for experiments :) I need a build environment and somewhat working practises to start the actual implementation of my software
Apr 02 09:55:48 <Cockroach-> Cursed thesis
Apr 02 10:00:05 <Cockroach-> YES!
Apr 02 10:00:09 <Cockroach-> I got it to work
Apr 02 10:05:59 <punk-ass> mount --bind /dev /chroot/dev
Apr 02 10:06:09 <Cockroach-> well at least the GPE started
Apr 02 10:06:16 <Cockroach-> punk-ass: I shall try that
Apr 02 10:09:43 <Cockroach-> oh, it's improving.
Apr 02 10:10:11 <Cockroach-> Now I only get tons of 'Cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders' errors and applications don't work because of that
Apr 02 10:10:31 <pb_> You need to run the gdk-pixbuf postinsts.
Apr 02 10:10:51 <pb_> Try doing "ipkg configure" inside the chroot.
Apr 02 10:11:05 <Cockroach-> Oh my
Apr 02 10:11:37 <Cockroach-> I can't believe it
Apr 02 10:11:39 <Cockroach-> it all works
Apr 02 10:11:43 <Cockroach-> or so it seems
Apr 02 10:11:43 <punk-ass> mount --bind /etc /chroot/etc
Apr 02 10:11:43 <punk-ass> :)
Apr 02 10:14:13 <Cockroach-> I needed to bind the /proc too
Apr 02 10:14:23 <Cockroach-> didn't bind etc though =)
Apr 02 10:15:00 <johnX> mount -t proc proc /proc didn't work?
Apr 02 10:16:41 <Cockroach-> Well I didn't even try that, wouldn't it mess up the things from the host environment point of view (in opposite to chrooted gpeimage)
Apr 02 10:17:34 <johnX> hmm...I think you're right and I was thinking of something else
Apr 02 10:17:50 <punk-ass> no mounting proc more than once is just fine
Apr 02 10:18:01 <punk-ass> but bind probably works just as good
Apr 02 10:18:41 <Cockroach-> Oh my, this is relief
Apr 02 10:18:58 <johnX> having things work is a nice feeling :)
Apr 02 10:20:05 <Cockroach-> I just noticed that since (as an ubuntu user) I chrooted using "sudo", I need to create a symlink inside gpeimage chroot from /home/root to /home/<un-sudoed-username>
Apr 02 10:20:24 <Cockroach-> even if "whoami" says I'm root
Apr 02 10:20:38 <Cockroach-> some other programs don't see it that way
Apr 02 10:24:47 <pb_> yah, or adjust the environment.
Apr 02 10:24:54 <pb_> you probably have an old value of $HOME or something
Apr 02 10:25:50 <pb_> (or $USER, maybe: check with "env" to see what's there)
Apr 02 10:26:50 <CIA-4> 03dirk 07org.oe.dev * r9bd1feff... 10/packages/wlan-ng/ (5 files in 2 dirs): 
Apr 02 10:26:50 <CIA-4> Packages/wlan-ng: make current svn compile
Apr 02 10:26:50 <CIA-4>  - fix PV
Apr 02 10:26:50 <CIA-4>  - disable pci and cs driver, because we don't need them
Apr 02 10:26:50 <CIA-4>  - update usb patch
Apr 02 10:26:51 <CoreDump|home> i have IMAGE_FSTYPES = "jffs2 ext2 tar.gz" in my local.conf. Is it possible to define a DEPENDS override (as in DEPENDS_ext2) to modify a variable depending on the rootfs type?
Apr 02 10:26:54 <CIA-4> 03dirk 07org.oe.dev * r9d3828ac... 10/packages/wlan-ng/ (9 files in 2 dirs): packages/wlan-ng: drop non working 0.2.2 version
Apr 02 10:29:29 <CoreDump|home> basically what I would like to accomplish is something like: IPKG_INSTALL_collie_ext2 = "some more packages than in a jffs rootfs"
Apr 02 10:30:40 <Cockroach-> pb_: ah, true.
Apr 02 10:33:21 <pb_> CoreDump|home: you could do that, but it might be better just to define a new image target.
Apr 02 10:33:28 <pb_> opie-big-image or something
Apr 02 10:34:21 <CoreDump|home> pb_: now that would be to easy wouldn't it? =D
Apr 02 10:34:54 <CoreDump|home> if that works, a single image build results in all files I need for a hentges release
Apr 02 10:35:59 <pb_> you could do that the other way too: just create a hentges-release.bb with DEPENDS = "opie-small-image opie-big-image opie-massive-image" or whatever.
Apr 02 10:36:09 <CoreDump|home> true
Apr 02 10:36:36 <pb_> if you want to pursue the ext2 thing, though, the rune you need is OVERRIDES_append = ":${IMAGE_FSTYPE}" or some such.
Apr 02 10:37:41 <CoreDump|home> ouch, that sounds painful
Apr 02 10:38:10 <CoreDump|home> XTRA_DEPENDS_collie_ext2 = "task-hentges-gpe-xtra" didn't work. Maybe because I build jffs, tar.gz and ext2 in one go?
Apr 02 10:38:33 <pb_> oh, right
Apr 02 10:38:35 <pb_> yeah, that won't work
Apr 02 10:38:40 <CoreDump|home> darn
Apr 02 10:39:04 <CoreDump|home> ~lart collie
Apr 02 10:39:04 * ibot hits collie with an anvil and laughs with a contralto voice ... Haha Ha HA Ha
Apr 02 10:39:44 <pb_> image_ipk.bbclass only builds one filesystem tree, so all your IMAGE_FSTYPES will end up containing the same files.
Apr 02 10:39:51 <CoreDump|home> i see
Apr 02 10:40:12 <pb_> i.e. it calls rootfs_ipk to generate the tree, then it iterates over ${IMAGE_FSTYPES} creating all the images from that single tree (via bbimage)
Apr 02 10:40:48 <CoreDump|home> i feared that was the case :\
Apr 02 10:41:09 <pb_> It wouldn't be impossible to make it work the way you want, but it would be quite difficult.  I don't think it will be worth the effort.
Apr 02 10:42:26 <pb_> It's almost certainly better to use separate .bb files for each image flavour that you want.  That way you can do anything you like.
Apr 02 10:42:53 <CoreDump|home> up until this point, overrides worked perfectly for anything I needed ;)
Apr 02 10:44:51 <CoreDump|home> bleh screw the users
Apr 02 10:46:53 <johnX> heh
Apr 02 11:05:36 <reenoo> morning
Apr 02 11:53:00 <CIA-4> 03rw 07org.oe.oz354fam083 * re12a0cb1... 10/packages/jamvm/jamvm_1.3.3.bb: jamvm: upgrade to 1.3.3
Apr 02 11:53:05 <CIA-4> 03rw 07org.oe.oz354fam083 * rcf64b025... 10/packages/classpath/classpath_0.18.bb: classpath: upgrade to 0.18 from .dev.
Apr 02 12:10:54 <CIA-4> 03rpurdie 07org.oe.dev * r534f03b1... 10/packages/linux/ (8 files in 2 dirs): (log message trimmed)
Apr 02 12:10:54 <CIA-4> linux-oz-2.6: various updates to 2.6.16 and openzaurus.inc
Apr 02 12:10:54 <CIA-4>  * Update LED patches to math those merged into mainline
Apr 02 12:10:54 <CIA-4>  * Update defconfigs to reflect IDE disk trigger changes
Apr 02 12:10:54 <CIA-4>  * Update backlight patches to reflect those merged into mainline
Apr 02 12:10:55 <CIA-4>  * Add poodle patches to fix MTD partition size and detect the correct
Apr 02 12:10:59 <CIA-4>  amount of memory
Apr 02 12:11:01 <CIA-4> 03rpurdie 07org.oe.dev * r39ce6b5b... 10/classes/kernel.bbclass: kernel.bbclass: Make sure the directory in staging exists
Apr 02 12:11:56 <CoreDump|home> ~lart collie
Apr 02 12:11:57 * ibot whacks collie with the cluebat
Apr 02 12:12:41 <RP> What that messages really means is that poodle is considerably fixed up :)
Apr 02 12:12:57 <zecke> CoreDump|home: hey, you could try compiling libqte :)
Apr 02 12:13:32 <CoreDump|home> zecke: is building a .dev image enough to get your changes?
Apr 02 12:14:10 <RP> zecke: Will this qte patch fix my console switching issues?
Apr 02 12:14:30 <CoreDump|home> RP: yay for poodle =)
Apr 02 12:15:22 <RP> CoreDump|home: collie backlight driver was also fixed/enhanced in the truncated part of the log (and poodle/collie console rotation was added)
Apr 02 12:16:03 <CoreDump|home> RP: that's all great and good, but w/o SD driver Collie 2.6 will be a double-plus no for many people :(
Apr 02 12:16:14 <zecke> CoreDump|home: yes
Apr 02 12:16:23 <zecke> RP: explain your issues *once again*
Apr 02 12:16:29 <zecke> RP: ah I start to remember
Apr 02 12:16:41 <CoreDump|home> zecke: I'll build dev for Akita then for tomorrow
Apr 02 12:17:06 <zecke> RP: you would like QtE to set the keyboard to MEDIUMRAW on VT switch back to Opie?
Apr 02 12:17:09 <pb_> zecke: good afternoon
Apr 02 12:17:16 <zecke> RP: and possible reread the keymap after a vt switch?
Apr 02 12:17:19 <RP> zecke: yes :)
Apr 02 12:17:32 <RP> zecke: That is exactly the problem
Apr 02 12:17:55 <zecke> RP: *no*, it is not yet fixed
Apr 02 12:18:07 <RP> zecke: ok, I'm just ever hopeful :)
Apr 02 12:18:24 <zecke> RP: I need to get my desktop machine going again...
Apr 02 12:18:39 <zecke> RP: I have so far three unsuccessfull installs :}
Apr 02 12:19:33 <RP> zecke: Lets hope 4th time lucky :)
Apr 02 12:19:53 <zecke> RP: actually, the system is installed, grub and lilo refuse to do the same
Apr 02 12:22:36 <RP> zecke: use a boot disk? :}
Apr 02 12:23:25 <zecke> RP: good thinking, update-grub does not fix it though :}
Apr 02 12:27:00 <zecke> OT: wasn't grub capable of booting a lvm2 disk?
Apr 02 12:31:30 <CoreDump|home> what the hell if wrong with collies VT's grrr
Apr 02 12:33:24 <pb_> zecke: no, iirc you need to have /boot in a non lvm partition
Apr 02 12:34:10 <zecke> pb_: it changed with lvm2 :}
Apr 02 12:34:20 <zecke> but now something is deeply broken
Apr 02 12:47:42 <zecke> Free Valium for everyone, calm down pals
Apr 02 12:51:16 <RP> We could use a MAINTAINER policy...
Apr 02 12:52:24 <zecke> "Don't get pissed off, don't make other pissed off" 
Apr 02 12:56:39 <reenoo> heh. koen is just looking for reasons to disable my key again. he's done so twice (without even notifying mickey who run vanille.de) with temporary success and is just trying it the "propose to oe@" way now
Apr 02 12:57:03 <reenoo> s/run/runs/
Apr 02 13:00:45 <reenoo> given that various projects use OE now the whole MAINTAINER thing is pretty bogus anyway. even if someone maintains a package in OE doesn't mean he will want to deal with bug reports for $DISTRIBUTION
Apr 02 13:01:22 <RP> It might be better to have a BBAUTHOR field
Apr 02 13:01:43 <reenoo> something along those lines yeah
Apr 02 13:02:03 <RP> Although having MAINTAINERS is a good concept, if we had enough people for it to work effectively
Apr 02 13:03:39 <reenoo> how about MAINTAINER vs RMAINTAINER?
Apr 02 13:04:09 <reenoo> and distros need to be able to override RMAINTAINER in a .conf
Apr 02 13:04:18 <CoreDump|home> MAINTAINER_OZ, MAINTAINER_FAM etc
Apr 02 13:04:19 <reenoo> (per package)
Apr 02 13:04:38 <RP> People won't understand the differences between them :-/
Apr 02 13:04:48 <RP> Peope have enough trouble with RDEPENDS vs DEPENDS...
Apr 02 13:04:54 <CoreDump|home> hehe
Apr 02 13:05:38 <RP> Perhaps we could identify what information we'd actually like the bb files to contain, then we can worry about the set of fields we need to contain that information
Apr 02 13:06:27 <RP> The author of the .bb file is one thing, another is where to send bugs with the generated packages and another is where to send build time failures
Apr 02 13:06:40 <reenoo> agreed
Apr 02 13:07:41 <zecke> reenoo: what we see is MAINTAINER_nslu2 = "Some one Else"
Apr 02 13:07:56 <zecke> reenoo: and I think I like that
Apr 02 13:08:29 <likewise> Does the maintainer check every patch against his work?
Apr 02 13:09:27 <reenoo> zecke: ah, interesting. I'd prefer MAINTAINER_${PN}_${DISTRO} in a .conf though.
Apr 02 13:11:27 <zecke> oh well the debian installer got rid off Windows XP - without asking me...
Apr 02 13:13:13 <reenoo> zecke: as for familiar-version.bb, I guess you'll agree that MAINTAINER_familiar doesn't make much sense there, so I didn't think of that there...
Apr 02 13:16:05 <zecke> reenoo: yes I agree on that. Familiar bits should be maintained by familiar devs
Apr 02 13:16:25 <zecke> reenoo: if they are so generic, it should be renamed to distri-versions...
Apr 02 13:17:57 <reenoo> yeah, renaming it and using overrides would work. there's nothing specifically Familiar about it
Apr 02 13:20:09 <zecke> reenoo: I have seen your commit thanks to the CIA bot
Apr 02 13:20:24 <zecke> reenoo: and my first impression was "There wasn't any communication on that one"
Apr 02 13:20:30 <zecke> reenoo: and then I saw the branch name
Apr 02 13:20:54 <reenoo> right, I haven't touched .dev
Apr 02 13:44:41 <zecke> http://lessig.org/freeculture/free.html <- wow
Apr 02 13:54:54 <gremlin[it]> hi all, trying to build opie-image for ep93xx (dev.oe.org repo) got >>> ERROR: dependency openobex-apps (for libopieobex0) not satisfied <<< any solution ? 
Apr 02 15:19:01 <mickey|writing> what was the magic again to prevent shlib renaming to do its job for one of the emitted subpackages ?
Apr 02 15:19:15 <mickey|writing> hi, btw.
Apr 02 15:22:58 <mickey|writing> greentux_alt: mt pull
Apr 02 15:23:00 <mickey|writing> no
Apr 02 15:23:02 <mickey|writing> gremlin[it], even
Apr 02 15:25:44 <CIA-4> 03mickeyl 07org.oe.dev * r017daaab... 10/packages/openobex/openobex_1.2.bb: openobex: PROVIDE openobex-apps
Apr 02 15:29:55 <gremlin[it]> thanks mickey|writing  :) 
Apr 02 15:31:24 <zecke> mickey|writing: hi
Apr 02 15:42:50 <mickey|writing> hey
Apr 02 15:42:54 <mickey|writing> bbiab, need to reboot :/
Apr 02 16:14:27 <zecke> mickey|writing: is that a big iron machine?
Apr 02 16:14:40 <zecke> mickey|writing: do you expect the Initial Program Loading to finish this month?
Apr 02 16:15:28 <mickey|writing> the harddisk in my archos jukebox is dying
Apr 02 16:15:35 <zecke|food> :(
Apr 02 16:15:51 <mickey|writing> hickups everywhere, especially on usb detection
Apr 02 16:15:53 <zecke|food> time to get a sharp with a hard disk
Apr 02 16:15:55 <zecke|food> and to fix xine
Apr 02 16:16:04 <mickey|writing> yeah
Apr 02 16:16:10 <mickey|writing> hmm, now that you say ti
Apr 02 16:16:17 * mickey|writing looks at his dusty c3000
Apr 02 16:16:41 <zecke|food> cya later
Apr 02 16:16:46 <mickey|writing> ~bon appetit
Apr 02 16:16:48 <ibot> i guess bon appetit is smacznego.  Guten Appetit.  Eet Smakelijk.  God Appetitt.  Buon Appetito.  Buen apetito  Bom Apetite. buen apetito
Apr 02 16:20:30 <reenoo> bloody t-offline
Apr 02 16:38:05 <Bernardo> what version of bitbake should I use with branch 354x? I'm trying right now with 418, but no luck
Apr 02 16:38:33 <reenoo> 329 I believe
Apr 02 16:39:57 <Bernardo> ok, thanks. Will try that one
Apr 02 16:56:46 <hrw> hi
Apr 02 16:57:00 <hrw> zecke|food: will build qte today and try to get some testers
Apr 02 16:57:20 <hrw> Bernardo: r329 is needed for 3.5.4x
Apr 02 16:58:54 <zecke|food> hrw: I'm in the process of (re)installing ubuntu on my desktop...
Apr 02 16:59:02 <zecke|food> hrw: I plan to do some testing as well
Apr 02 17:00:49 <CIA-4> 03hrw 07org.oe.oz354x * r144e63a6... 10/packages/iqnotes/ (files/pro.patch iqnotes_2.0.99-2.1.0rc1.bb iqnotes_2.0.2.bb): IQNotes: added 2.1.0-rc1 and set me as Maintainer
Apr 02 17:00:53 <CIA-4> 03hrw 07org.oe.oz354x * r035d5035... 10/packages/matchbox-applet-cards/ (8 files in 2 dirs): added matchbox-applet-cards 1.0.2 from .dev
Apr 02 17:00:57 <CIA-4> 03hrw 07org.oe.oz354x * r7c961dad... 10/packages/matchbox-applet-tasks/matchbox-applet-tasks_1.0.0.bb: added matchbox-applet-tasks 1.0.0 from .dev
Apr 02 17:01:01 <CIA-4> 03hrw 07org.oe.oz354x * r5439a648... 10/packages/matchbox-applet-tasks/matchbox-applet-tasks_1.0.0.bb: matchbox-applet-tasks: fixed building
Apr 02 17:01:05 <CIA-4> 03hrw 07org.oe.dev * r3eec9c93... 10/packages/iqnotes/ (iqnotes_2.0.2.bb iqnotes_2.0.99-2.1.0rc1.bb): IQNotes: set me as Maintainer
Apr 02 17:02:50 <hrw> ops. forgot to bump iqnotes
Apr 02 17:27:26 <zecke> hmm harri does not reply
Apr 02 17:29:40 <hrw> koen: matchbox-applets-* renamed in .oz354x
Apr 02 17:29:57 <CIA-4> 03hrw 07org.oe.oz354x * r3da6aefb... 10/packages/iqnotes/ (iqnotes.inc iqnotes_2.0.2.bb iqnotes_2.0.99-2.1.0rc1.bb): 
Apr 02 17:29:57 <CIA-4> iqnotes: moved common part to iqnotes.inc
Apr 02 17:29:57 <CIA-4> - fixed HOMEPAGE
Apr 02 17:30:05 <CIA-4> 03hrw 07org.oe.dev * r0261a509... 10/packages/iqnotes/ (iqnotes_2.0.2.bb iqnotes_2.0.99-2.1.0rc1.bb): 
Apr 02 17:30:05 <CIA-4> iqnotes: moved common part to iqnotes.inc
Apr 02 17:30:05 <CIA-4> - fixed HOMEPAGE
Apr 02 17:30:15 <zecke> bumped version now?
Apr 02 17:30:33 <zecke> any heavy 'find' user around?
Apr 02 17:30:47 <hrw> bumped
Apr 02 17:30:51 <hrw> define heavy
Apr 02 17:31:13 <koen> hrw: thanks
Apr 02 17:31:33 <zecke> hrw: I want to delete anything that is not in a .svn directory
Apr 02 17:32:19 <hrw> svn does not have command for it?
Apr 02 17:32:49 <zecke> hrw: I'm importing QtE snapshots
Apr 02 17:32:57 <zecke> hrw: and I do not want any orphaned file around
Apr 02 17:33:10 <hrw> zecke: I would do: rm -f `find . |grep -v .svn` probably
Apr 02 17:33:10 <zecke> well, I should use svk anyway
Apr 02 17:34:45 <CIA-4> 03hrw 07org.oe.dev * r4dad2963... 10/packages/iqnotes/iqnotes.inc: iqnotes: added forgotten file
Apr 02 17:37:14 <hrw> cu
Apr 02 17:47:42 <Bernardo> hrw|gone: thanks
Apr 02 17:50:50 <jnc> umm
Apr 02 17:50:51 <jnc> for qte
Apr 02 17:51:05 <jnc> why aren't we patching the code to accept a keymap file to import... ?
Apr 02 17:51:15 <jnc> instead of this wacky bb logic
Apr 02 17:51:28 * zecke shakes head...
Apr 02 17:51:40 <zecke> kergoth: TT finally raped tslib
Apr 02 17:51:48 <jnc> TT?
Apr 02 17:51:49 <jnc> ohh
Apr 02 17:51:52 <jnc> trolltech
Apr 02 17:52:15 <jnc> 1 out of 1 hunk FAILED -- rejects in file src/kernel/qkeyboard_qws.cpp
Apr 02 17:54:39 <galvAtr0n> anyone know if zgcc workd on OZ 3.5.4 ?
Apr 02 17:57:27 <jnc> not sure
Apr 02 17:58:05 <koen> galvAtr0n: you mean 'ipkg install gcc'?
Apr 02 18:01:21 <galvAtr0n> not sure if that includes the zgcc native compiler. to compile .c apps on Z
Apr 02 18:01:39 * koen doesn't know what zgcc is
Apr 02 18:01:53 <jnc> specially hacked gcc 2.95
Apr 02 18:01:54 <koen> if you want to compile apps, you need gcc 
Apr 02 18:02:07 <jnc> it was the version of gcc for sharprom i think
Apr 02 18:03:03 <jnc> could someone with knowledge of qte please have a look at org.openembedded.dev/packages/qte/qte_2.3.10.bb and the patch file org.openembedded.dev/packages/qte/qte-2.3.10/kernel-keymap-CXK.patch to update the patch?
Apr 02 18:03:11 <jnc> it won't apply here
Apr 02 18:03:29 <jnc> i'm not sure i understand how the patch is supposed to be generated
Apr 02 18:03:34 <jnc> not sure how to fix it
Apr 02 18:07:03 <galvAtr0n> how can i list the files in a package ???
Apr 02 18:07:44 <jnc> good question
Apr 02 18:07:52 <jnc> don't know the answer
Apr 02 18:08:06 <koen> galvAtr0n: I think your questions are more suited for #openzaurus
Apr 02 18:08:11 <zecke> RP: what is a good strategy on file parsing?
Apr 02 18:08:23 <galvAtr0n> ok thanks ;)
Apr 02 18:08:25 <zecke> RP: one processing loading files and another handling them?
Apr 02 18:08:54 <zecke> RP: this would allow us to parse while the system loads the other files?
Apr 02 18:09:10 <zecke> i hope this makes some sense
Apr 02 18:09:40 <zecke> alternatively we can switch to Schily mode and claim Solaris2 superior
Apr 02 19:55:53 <RP> zecke: That sounds reasonable to me
Apr 02 19:58:00 <RP> zecke: I have an alternative/suplemetal idea as well. There are only a handful of variables bitbake actually uses. Why don't we save these to a seperate much smaller cache file?
Apr 02 19:59:59 <csmanx> uhmm, does this mean bitbake is using the native compiler to build my package?
Apr 02 20:00:02 <csmanx> /usr/bin/ld: skipping incompatible /home/manuel/ipaq/tmp/staging/arm-linux/lib/libgtk.so when searching for -lgtk
Apr 02 20:02:27 <RP> csmanx: it certainly looks suspicous...
Apr 02 20:09:36 <csmanx> =/
Apr 02 20:15:28 <zecke> Who is caring for libgcrypt?
Apr 02 20:15:48 * emte looks at the cryptkeeper  :P
Apr 02 20:15:59 <poli> Ok. Something wrong with rhythmbox on oz354fam083... On a bitbake rhythmbox I get:
Apr 02 20:16:00 <emte> sorry bad pun
Apr 02 20:16:01 <poli> | No package 'gstreamer-gconf-0.8' found
Apr 02 20:16:01 <poli> | configure: error: GStreamer not found, or older than version 0.8.1
Apr 02 20:16:40 <poli> But checking gstreamer has several .bb files, all of them 0.8.4 and beyond.
Apr 02 20:16:52 <poli> What could be causing that?
Apr 02 20:17:02 <zecke> RP: I don't think that helps much
Apr 02 20:17:28 <zecke> RP: I think it is more expensive to load the file than to unpickle :}
Apr 02 20:48:48 <csmanx> RP: i thought that just by invoking bitbake it will use its own build tools
Apr 02 20:49:46 <zecke> csmanx: it uses your native tools to build stuff as well
Apr 02 20:49:52 <zecke> csmanx: e.g to build -native packages
Apr 02 20:50:01 <zecke> csmanx: or to build the cross compiler
Apr 02 21:00:47 <csmanx> yeah, i just have to know how to tell bitbake to build oe packages
Apr 02 21:01:19 <zecke> csmanx: ?
Apr 02 21:02:48 <zecke> csmanx: OE tells bitbake how it should build stuff (via bbclasses)
Apr 02 21:03:34 <zecke> csmanx: do you have a current issue?
Apr 02 21:04:05 <zecke> RP: you should add a 'got finger in the arse check'-check to sanity
Apr 02 21:04:12 <csmanx> not with oe, i'm just trying to build my own package
Apr 02 21:05:18 <csmanx> but it's using native tools instead of cross tools
Apr 02 21:05:55 <zecke> the wonderful world of autotools
Apr 02 21:06:13 <csmanx> i built my package deps using bitbake package_name, that was no problem.
Apr 02 21:07:46 <csmanx> you mean i should inherit autotools ?
Apr 02 21:32:40 <RP> zecke: Loading a few files with just the required variables like RDEPENDS, DEPENDS etc should be a lot faster than unpickleing the whole data structure?
Apr 02 21:36:12 <zecke> RP: I think most cached files fit in a single block on the fs?
Apr 02 21:36:28 <zecke> RP: So reading a smaller or bigger file should not be an issue
Apr 02 21:38:35 <zecke> RP: on my todo list is also writing the 'complete' data to a cache
Apr 02 21:38:45 <zecke> RP: and have a special flag to discard mtimes completely
Apr 02 21:39:08 <zecke> RP: I just see no easy way updating these information
Apr 02 21:50:14 <RP> zecke: Each cached file is ~140kb here :-/
Apr 02 21:53:52 <RP> zecke: For current bitbake that's 300MB+ of data to read through which is always going to take a while. If we reduce the size of the cached data, it will be able to parse from the cache faster
Apr 02 21:54:39 <delta_> hei hei
Apr 02 21:57:20 <RP> s
Apr 02 21:59:51 <delta_> I am trying to figure out how to produce patches that have "index:" written at the first line, like the oe-kernel patches..
Apr 02 22:02:44 <CSMan> i removed CFLAGS and LDFLAGS from my Makefile, how do i add these to the .bb file to force CROSS building ?
Apr 02 22:05:30 <RP> CSMan: Those variabes should be set in the environment correctly by bitbake
Apr 02 22:05:31 <zecke> RP: okay this is a argument :)
Apr 02 22:07:21 <zecke> RP: we should try it, we maybe could even store everything in one file :}
Apr 02 22:07:44 <zecke> RP: I see some minor and bigger issues - but they are present today as well
Apr 02 22:08:28 <RP> zecke: My gut feeling is that if we have a much smaller cache, things will be a lot faster. I'd not realised our cache was this big...
Apr 02 22:10:03 <zecke> RP: I fear the data inconsistencies...
Apr 02 22:10:17 <zecke> but we have them now already :}
Apr 02 22:11:41 <RP> zecke: The reason for the poor bitbake performance on my server is due to the IO required :-/
Apr 02 22:12:21 <zecke> as I said try Solaris or Win3.11 instead
Apr 02 22:12:42 <RP> zecke: no thanks ;-)
Apr 02 22:12:46 <zecke> I deserve some sleep now :)
Apr 02 22:13:13 <RP> zecke: Ok, sleep well :)
Apr 02 22:13:26 <zecke> RP: I'm doing a sprint this week, so I think I will not find the time to scratch that itch
Apr 02 22:13:42 <CSMan> RP: could you help me ?
Apr 02 22:13:49 <RP> zecke: no problem. Perhaps I might come up with a patch :)
Apr 02 22:14:12 <zecke> I will be happy to turn it down ;)
Apr 02 22:14:25 <RP> zecke: ;-)
Apr 02 22:14:38 <RP> CSMan: How do you call gcc in this makefile?
Apr 02 22:14:39 <zecke> + I start to get issues with my 'wisdom tooth' again
Apr 02 22:14:46 <zecke> okay cya
Apr 02 22:15:05 <RP> CSMan: pastebin your makefile
Apr 02 22:15:06 <CSMan> RP: gcc
Apr 02 22:15:08 <CSMan> ok
Apr 02 22:15:28 <RP> CSMan: Calling gcc directly is your first mistake. Try $(CC)
Apr 02 22:15:29 <CSMan> maybe i have to do something that looks like $(BB_GCC) =P
Apr 02 22:15:43 <CSMan> almost right
Apr 02 22:15:45 <CSMan> =P
Apr 02 22:15:55 <RP> This is standard makefile stuff...
Apr 02 22:16:13 <CSMan> that's right, i should get used to it
Apr 02 22:19:09 <RP> CSMan: When cross compiling, instead of gcc, you'd use the cross compiler which is something like arm-linux-gcc. bitbake sets this in the CC environmental variable so you don't need to worry about what gcc is called though...
Apr 02 22:19:21 <CSMan> RP: http://pastebin.ca/47913
Apr 02 22:19:27 <CSMan> my tiny Makefile
Apr 02 22:19:43 <CSMan> yeah, i noticed the arm-linux-gcc but it came with a file not found error
Apr 02 22:20:29 <CSMan> which is weird because i've been building packages in the standard way (bitbake foo)
Apr 02 22:20:30 <RP> CSMan: you have let bitbake build the cross compiler?
Apr 02 22:20:56 <CSMan> RP: i thought that happened when i did bitbake nano
Apr 02 22:21:24 <RP> CSMan: it should have done but it depends what you did
Apr 02 22:21:46 <RP> CSMan: Does arm-linux-gcc exist somewhere in tmp/cross/ ?
Apr 02 22:21:58 <RP> CSMan: bitbake sould also set its path so it can find it itself
Apr 02 22:22:15 <CSMan> yeah it's there
Apr 02 22:22:38 <CSMan> do i have to export PATH in my .bb file ?
Apr 02 22:23:22 <RP> CSMan: No, bitbake should just do that. You are building this makefile from an OE .bb file right?
Apr 02 22:23:25 <CSMan> because it seems that just invoking bitbake won't do it
Apr 02 22:23:33 <CSMan> RP: nope, it's my own .bb
Apr 02 22:23:50 <RP> CSMan: That's what I mean. Can you pastebin the .bb?
Apr 02 22:24:56 <CSMan> here : http://pastebin.ca/47914
Apr 02 22:25:23 <CSMan> you may find some atrocities 
Apr 02 22:28:52 <RP> CSMan: It needs some work :-/
Apr 02 22:29:22 <RP> CSMan: I guess you've been simplifying things and that's a good approach to take. 
Apr 02 22:29:36 <CSMan> i tried to grasp some from GettingStarted , but i don't totally  follow the logic of bitbake 
Apr 02 22:30:03 <CSMan> RP: yeah, i tried to make it tiny so i can understand , and then i can start building basic gtk apps
Apr 02 22:30:11 <RP> CSMan: I'd comment out that CFLAGS line, run the .bb after making the $(CC) change and then pastebin the log of the error
Apr 02 22:30:45 <CSMan> do i need to set CC in the .bb ?
Apr 02 22:31:18 <RP> CSMan: no
Apr 02 22:32:29 <CSMan> i get the arm-linux-gcc error http://pastebin.ca/47915
Apr 02 22:33:35 <RP> CSMan: Have you looked in /home/manuel/ipaq/hello/tmp/work/arm-linux/hello-1.0-r0/temp/ ?
Apr 02 22:34:33 <RP> CSMan: You'll find the script bitbake generates to run the compile - perhaps you can find a clue in there as to why the PATH isn't working right. Bitbake should set it to include a place where arm-linux-gcc can be found
Apr 02 22:34:51 <CSMan> ok, i look through those logs
Apr 02 22:36:37 <CSMan> ok this is not right : /home/manuel/ipaq/hello/tmp/cross/bin
Apr 02 22:36:48 <CSMan> it's adding the "hello" in the path
Apr 02 22:37:57 <CSMan> why does it do that ?
Apr 02 22:39:41 <RP> Which variable is that? PATH?
Apr 02 22:39:48 <CSMan> yeah
Apr 02 22:40:03 <CSMan> it'd be ok if the "hello" is not there
Apr 02 22:40:36 <CSMan> *was
Apr 02 22:41:13 <CSMan> my question is , from where did bitbake get that particular path
Apr 02 22:41:46 <RP> CSMan: Probably from conf/bitbake.conf
Apr 02 22:42:29 <RP> CSMan: Specifically probably CROSS_DIR
Apr 02 22:42:42 <RP> CSMan: You didn't mess around with TMPDIR did you?
Apr 02 22:43:16 <CSMan> nope
Apr 02 22:43:56 <CSMan> i don't have CROSS_DIR in my bitbake.conf
Apr 02 22:44:52 <RP> CSMan: Did you set TMPDIR in your local.conf?
Apr 02 22:45:13 <RP> CSMan: You are looking at openembedded/conf/bitbake.conf?
Apr 02 22:46:47 <CSMan> ok, i do have CROSS_DIR , i was looking at the wrong .conf
Apr 02 22:49:21 <CSMan> RP: TEMPDIR is not set
Apr 02 22:49:45 <CSMan> *TMP
Apr 02 22:51:25 <CIA-4> 03rw 07org.oe.oz354fam083 * rdedf215b... 10/packages/libgpepimc/libgpepimc_0.6.bb: libgpepimc: add 0.6 which is referred to by preferred-gpe-versions-2.7 already.
Apr 02 22:52:25 <RP> CSMan: I suggest runusning bitbake xxx -e where xxx is the name of the package you're using
Apr 02 22:52:59 <RP> CSMan: See if you can work out which variable is getting corrupted and work backwards, probably starting with CROSS_DIR
Apr 02 22:53:30 <CSMan> ok
Apr 02 23:08:57 <RP> rpsys.net and hence me around going offline for a bit for some hardware investigations. Hoepfully back soon...
Apr 02 23:29:10 <CSMan> RP: i managed to compile, where does the build goes by default before creating the .ipk?
Apr 02 23:31:01 <CSMan> found it.
Apr 02 23:54:32 <CSMan> heh, i did all that to find out that gpe runs on gtk-X11
Apr 03 00:21:55 <CSMan> at last, my first gtk widget
Apr 03 00:55:11 <jnc> i'm the libgcrypt maintainer now i guess
Apr 03 00:55:14 <jnc> where'd zecke go
Apr 03 03:44:24 <Zero_Chaos> ibot: literal stewie
Apr 03 03:44:43 <Zero_Chaos> ~emulate stewie
Apr 03 03:44:46 <ibot> Damn you, damn the broccoli, and damn the Wright Brothers!
Apr 03 03:44:59 <Zero_Chaos> ibot: botsnack
Apr 03 03:44:59 <ibot> aw, gee, Zero_Chaos
Apr 03 06:59:37 <ronan> yop
Apr 03 07:07:38 <CoreDump|home> morning
Apr 03 07:34:05 <do13_> morning all
Apr 03 07:40:46 <CoreDump|home> morning do13 
Apr 03 07:44:01 <XorA> morning
Apr 03 07:47:01 <do13_> hey XorA, CoreDump|home 
Apr 03 07:55:25 <richard2> morning all
Apr 03 07:57:25 <hrw|work> morning
Apr 03 07:57:50 <hrw|work> RP: lot of stuff added into 2.6.17-rc1
Apr 03 07:58:37 <do13_> morning hrw|work 
Apr 03 08:00:09 <hrw|work> | /home/hrw/devel/build/oz354x/tmp/cross/lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld: cannot find -lxpcom
Apr 03 08:00:13 <hrw|work> minimo ;(
Apr 03 08:00:20 <RP> hrw|work: Thankfully, yes. We should be able to clean up the .bb file a bit :)
Apr 03 08:00:41 <hrw|work> RP: any plans of adding 2.6.16 to .oz354x?
Apr 03 08:01:14 <RP> hrw|work: I'd hoped to do that this weekend. I only got as far as updating it in .dev :-/
Apr 03 08:02:15 <hrw|work> ok
Apr 03 08:02:20 <RP> Some not to good news from Russell:http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3453/1
Apr 03 08:03:30 <CoreDump|home> "I'll apply this under protest " hehe
Apr 03 08:04:26 <hrw|work> fsck
Apr 03 08:05:10 <RP> "collie range" had me confused for a minute as well...
Apr 03 08:05:53 <hrw|work> ~curse linux
Apr 03 08:05:56 <ibot> May the fleas of a thousand camels infest your most sensitive regions, linux !
Apr 03 08:06:21 <hrw|work> 'if you have a zombie then you cannot do nothing with it - reboot req'
Apr 03 08:06:23 <hrw|work> argh..
Apr 03 08:06:38 <hrw|work> someone know command to rename process?
Apr 03 08:06:57 <hrw|work> cant run kmail because one copy left as zombie ;(
Apr 03 08:07:06 <CoreDump|home> I didn't even know there was such a command heh
Apr 03 08:07:21 <CoreDump|home> hrw|work: kill the parent and the zombie dies
Apr 03 08:07:48 <hrw|work> CoreDump|home: not possible if parent is my x-session...
Apr 03 08:07:48 <CoreDump|home> try kill -9 all the kde* crap
Apr 03 08:08:07 <CoreDump|home> hrw|work: I bet the parent is kdeinit or some such
Apr 03 08:08:47 <CoreDump|home> but I agree, children w/ dead parent should be killable
Apr 03 08:09:01 <hrw|work> now it dies^Whangs on reading from dcop ;(
Apr 03 08:10:37 <hrw|afk> re
Apr 03 08:10:45 <hrw|afk> had to kill whole session...
Apr 03 08:11:14 <hrw> re
Apr 03 08:11:38 <CoreDump|home> ~lart kde then
Apr 03 08:11:38 * ibot eats kde then's liver with some fava beans and a nice chianti
Apr 03 08:21:37 <ade|desk> bugger me some is using qemu-qop version :)
Apr 03 08:22:16 <Genesis> qop version ?
Apr 03 08:22:23 <Genesis> what is it ?
Apr 03 08:23:55 <obergix[work]> hi
Apr 03 08:24:53 <CIA-4> 03coredump 07org.oe.dev * r16c085cd... 10/packages/altboot/ (3 files in 3 dirs): 
Apr 03 08:24:53 <CIA-4> altboot: Change the way we check if altboot is called by the kernel or the user.The old function only worked because on most Zaurii /var is lost on reboot.
Apr 03 08:24:53 <CIA-4> This fixes altboot on Spitz / Borzoi w/ kernel 2.6.
Apr 03 08:24:53 <CIA-4> Courtesy polyonymous @ #openzaurus
Apr 03 08:25:27 <CoreDump|home> (also includes Borzoi 2.6 config)
Apr 03 08:34:51 <ade|desk> Genesis: its a different backend to qemu
Apr 03 08:37:29 <Genesis> oki
Apr 03 08:57:00 <Genesis> some people member of  linux-arm-kernel ?
Apr 03 08:57:49 <Genesis> i don't know how to get the diff files of the right kernel to the mx21ads board ( http://www.spinics.net/lists/arm-kernel/msg27671.html )
Apr 03 09:13:02 <CIA-4> 03coredump 07org.oe.dev * rb4a73a90... 10/packages/altboot/ (11 files in 5 dirs): altboot: Drop kernel 2.4 support for Spitz and Borzoi. These two were a support nightmare w/ 2.4
Apr 03 09:13:06 <CIA-4> 03coredump 07org.oe.dev * rad6ee3d2... 10/packages/altboot/altboot_0.0.0.bb: altboot: Remove spitz's postinst and postrm for kernel 2.4
Apr 03 09:15:44 <hrw|work> re
Apr 03 09:18:54 <koen> good morning all
Apr 03 09:19:01 <XorA> hey koen 
Apr 03 09:19:09 <CoreDump|home> morning koen 
Apr 03 09:19:30 <koen> hey XorA & CoreDump|home 
Apr 03 09:19:34 <do13_> key koen 
Apr 03 09:19:44 <koen> hey do13_ 
Apr 03 09:19:50 <XorA> koen: another upgrade on gnumeric and I finally bothered me arse to fix gnumeric-dev
Apr 03 09:20:28 <koen> XorA: yay!
Apr 03 09:21:09 <XorA> koen: shall I clean the old gnumerics and goffice .bb files away
Apr 03 09:23:30 <koen> XorA: afaik nobody uses them
Apr 03 09:23:49 <koen> and monotone doesn't forget :)
Apr 03 09:24:17 <XorA> koen: well as official MAINT, thought Id check first :-)
Apr 03 09:24:24 <koen> :)
Apr 03 09:28:29 <koen> I hope the gtk icon cache works for gpe
Apr 03 09:28:43 <koen> it would make poodle and corgi users a bit happier :)
Apr 03 09:41:02 <CIA-4> 03xora 07org.oe.dev * r9c58b777... 10/packages/gnumeric/ (13 files in 5 dirs): packages/gnumeric/* : drop old versions.
Apr 03 09:42:52 * koen looks at https://stage.maemo.org/svn/maemo/projects/haf/hafbuildbot/sources
Apr 03 09:43:49 * koen needs more time!
Apr 03 09:44:32 <CIA-4> 03xora 07org.oe.dev * rccad05d2... 10/packages/gnome/ (7 files): packages/gnome/goffice*.bb : drop old versions
Apr 03 09:51:08 * XorA puts his dust buster away before sucking up anymore of OE
Apr 03 09:58:26 * hrw|work want cherrypicker in monotone
Apr 03 09:58:58 * koen too
Apr 03 09:59:21 <hrw|work> I have 3 changes in .oz354x which need to propagate into .dev
**** ENDING LOGGING AT Mon Apr 03 09:59:59 2006