**** BEGIN LOGGING AT Sat Nov 18 02:59:56 2006
Nov 18 04:12:34 <CIA-4> 03pfalcon 07org.oe.dev * rab5810cf... 10/ (6 files in 3 dirs): (log message trimmed)
Nov 18 04:12:34 <CIA-4> xserver-common_svn: Recipe to build xserver-common straight out of SVN.
Nov 18 04:12:34 <CIA-4> * Needed to test/support newest devel patches.
Nov 18 04:12:34 <CIA-4> * Specifically, at this time being added to let people more comprehensively
Nov 18 04:12:34 <CIA-4> test "common keyboardless buttonmap" patch, required for latest HH.orh kernels.
Nov 18 04:12:35 <CIA-4> * Makefile.dpkg_ipkg, Makefile.translation, svn_makefiles.patch: support files
Nov 18 04:12:39 <CIA-4> required to build from SVN.
Nov 18 04:51:33 <CIA-4> 03pfalcon 07org.oe.dev * r6402e465... 10/ (1 packages/libopie/libopie2_cvs.bb): 
Nov 18 04:51:33 <CIA-4> libopie2_cvs: Convert to use PV independent on the rest of OPIE.
Nov 18 04:51:33 <CIA-4> * libopie2 is a special package in OPIE. Its interface is mostly stable,
Nov 18 04:51:33 <CIA-4> and changes are made only to add support for new devices. So, let distro
Nov 18 04:51:33 <CIA-4> select specific SRCDATE for it.
Nov 18 04:51:34 <CIA-4> * Add DEFAULT_PREFERENCE = "-1"
Nov 18 04:51:36 <CIA-4> 03pfalcon 07org.oe.dev * r0d1b152a... 10/ (3 files in 3 dirs): 
Nov 18 04:51:40 <CIA-4> libopie2_cvs: Add ipaq-2.6-sys-class-backlight-support.patch.
Nov 18 04:51:42 <CIA-4> * Support kernel 2.6 backlight classdev to control backlight.
Nov 18 04:51:44 <CIA-4> * From Familiar tree.
Nov 18 04:51:46 <CIA-4> 03pfalcon 07org.oe.dev * rde589876... 10/ (3 files in 3 dirs): libopie2_cvs: Add HH.org kernel common keybaordless buttonmap patch.
Nov 18 05:25:13 <chouimat|Zzzz> rm *
Nov 18 06:40:12 <CIA-4> 03rwhitby 07org.oe.dev * r3ef89846... 10/ (3 files in 3 dirs): slugos: fixed kernel module depends in debianslug
Nov 18 07:34:59 <Bernardo> good morning
Nov 18 08:33:17 <cyrilRomain> 'morning all
Nov 18 08:59:56 <hrw> morning
Nov 18 09:05:16 <gremlin[it]> hi hrw 
Nov 18 09:09:36 <hrw> 81 packages not fetch 
Nov 18 09:09:50 <hrw> excluding maemo crap and svn/https ones
Nov 18 09:12:55 <koen> good morning all
Nov 18 09:13:54 <hrw> hi Kun
Nov 18 09:15:33 <koen> mozdir="${D}${libdir}/mozilla-minimo"
Nov 18 09:15:44 <koen> install -m 0755 minimo ${D}${mozdir}
Nov 18 09:15:57 <koen> gee, I wonder why we get such strange paths....
Nov 18 09:16:58 <hrw> how to fill up rootfs: boot with acpi debug
Nov 18 09:17:03 <hrw> and leave machine for few days
Nov 18 09:17:48 <koen> heh
Nov 18 09:17:59 <koen> I'm so used to syslog being a ringbuffer :)
Nov 18 09:18:37 <CIA-4> 03koen 07org.oe.dev * ra0a63efb... 10/ (1 packages/mozilla/minimo_0.016+cvs.bb): minimo 0.016: remove spurious ${D} in mozdir, should fix #1600
Nov 18 09:19:29 <sirfred> Morning
Nov 18 09:19:46 <koen> hey sirfred 
Nov 18 09:20:08 <hrw> hi sirfred 
Nov 18 09:22:15 <sirfred> Now that I think that the w100 driver is reaching some stable state, I'm not sure about what path to follow.
Nov 18 09:22:45 <CIA-4> 03koen 07org.oe.dev * rbd4a11cd... 10/ (1 packages/mozilla/minimo_0.016+cvs.bb): minimo 016: fix parse error and bump PR
Nov 18 09:23:22 <sirfred> I'm between start working in X and fix the qte work I made time ago.
Nov 18 09:24:15 <sirfred> How is all this moving? I mean, is qte being abandoned, waiting for qtopia to be GPL , perhaps?
Nov 18 09:24:35 <koen> pretty much
Nov 18 09:24:46 <koen> even zecke and mickey|dinner are using X nowadays
Nov 18 09:24:56 <sirfred> That's a signal
Nov 18 09:25:08 <sirfred> Winds of change
Nov 18 09:25:26 <sirfred> And what on X, qt/x or gtk?
Nov 18 09:25:26 <hrw> Obsolete Integrated Palmtop Environment
Nov 18 09:26:14 <hrw> I have one more reason to abandon qt/e now - progear does not have XGA fb but has XGA x11
Nov 18 09:26:53 <sirfred> Anyway, this path is perhaps the best for accel, because only givin acceleration to X, we will have it on SDL, QT, anything on it. 
Nov 18 09:27:24 <sirfred> But I always had the feeling (perhaps incorrect) that X is a little complex (code wise)
Nov 18 09:28:00 <sirfred> And Xw100 is being used, I suppose
Nov 18 09:28:30 <koen> running it on my hx4700 right now :)
Nov 18 09:29:26 <koen> I should reinstall my c700 some time
Nov 18 09:29:37 <sirfred> The only think I don't like about Xw100 is that AFAIR is using the ati microcode.
Nov 18 09:29:52 <koen> it is?
Nov 18 09:30:11 <sirfred> I think so, as it's using the ringbuffer and the CE to perform some operations.
Nov 18 09:30:13 <koen> I haven't loaded any microcode on mh hx4700
Nov 18 09:30:23 <sirfred> koen: It's embedded in the driver itself, I think.
Nov 18 09:30:33 <sirfred> Distributed as a header file.
Nov 18 09:31:07 <koen> sirfred: http://www.openembedded.org/repo/org.openembedded.dev/packages/xorg-xserver/xserver-kdrive/w100.patch
Nov 18 09:31:42 <sirfred> +static void
Nov 18 09:31:42 <sirfred> +ATIUploadMicrocode(ATIScreenInfo * atis)
Nov 18 09:32:00 <koen> where does it get the microcode from?
Nov 18 09:32:15 <koen> afaik I don't have that installed on my hx4700
Nov 18 09:32:17 <sirfred> koen: We extracted it from the libqte.so sharp original file.
Nov 18 09:34:28 <hrw> ati_microcode.c
Nov 18 09:35:58 <sirfred> The thing is that all the operations that are currently implemented in the Xw100 driver can be performed without the microcode, using direct register access.
Nov 18 09:37:07 <hrw> free free driver
Nov 18 09:37:34 <CIA-4> 03hrw 07org.oe.dev * r764fab90... 10/ (5 files in 2 dirs): nkf: update to 2.07 (2.06 not fetchable) and package docs
Nov 18 09:37:35 <hrw> koen: I vote for removing maemo from OE
Nov 18 09:37:56 <koen> hrw: I vote for updating them
Nov 18 09:37:57 <hrw> koen: its unfetchable
Nov 18 09:38:00 <sirfred> But, I've also found that feeding host data to the card when we want to perform colour conversion, is 4x faster using the imageon command processor commands.
Nov 18 09:38:28 <sirfred> So, I've started to add preliminary ringbuffer commands to the libw100 too
Nov 18 09:38:32 <hrw> koen: if no one will update then it will be sign of being unmaintained, which lead to removal
Nov 18 09:41:03 <hrw> what do you think?
Nov 18 09:41:13 <mmp> hrw: is there any correctly working browser in OE, not counting minimo?
Nov 18 09:41:28 <hrw> mmp: firefox 1.0.x was working
Nov 18 09:41:33 <koen> mmp: links, gpe-minibrowser, dillo, firefox
Nov 18 09:41:54 <hrw> koen: gpe-minibrowser != working
Nov 18 09:42:02 <koen> it is for me
Nov 18 09:42:05 <mmp> hmm, gpe-minibrowser renders correctly handhelds.org :)
Nov 18 09:42:11 <mmp> but not far more:)
Nov 18 09:42:16 <hrw> koen: scap me google.fr
Nov 18 09:42:24 <mmp> dillo performed something better, but not much
Nov 18 09:42:58 * mmp hasn't tried firefox yet; but is afraid of memory consumption and maybe performance
Nov 18 09:44:08 <RP> morning all
Nov 18 09:44:15 <sirfred> RP: Morning
Nov 18 09:44:19 <hrw> RP: fetchall finished after 6h
Nov 18 09:44:23 <koen> hey RP 
Nov 18 09:44:35 <hrw> RP: now I reverted all my drops and restarted it
Nov 18 09:46:48 <RP> hrw: I have an update for bitbake which should remove some of the duplicate fetches
Nov 18 09:46:54 <hrw> cool
Nov 18 09:47:29 <CIA-4> 03koen 07org.oe.dev * rdcbd942b... 10/ (1 packages/mozilla/minimo_0.016+cvs.bb): minimo 016: fix -dbg packaging
Nov 18 10:03:46 <hrw> hi lala
Nov 18 10:04:10 <hrw> ~lart SSL only subversion repos
Nov 18 10:04:10 * ibot puts on a hockey mask and jumps out at SSL only subversion repos
Nov 18 10:36:45 <hrw> cu
Nov 18 10:39:36 <zecke> RP: it makes a difference ~12 seconds on my system
Nov 18 10:41:10 <zecke> http://www.willitblend.com/videos.aspx?type=unsafe&video=movie
Nov 18 10:55:11 <florian> good morning
Nov 18 10:56:54 <RP> zecke: Every little helps :)
Nov 18 10:57:23 <zecke> I have an Intel Core Duo, so the numbers might be more different on slower CPUs
Nov 18 11:10:53 <zecke>  http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/PTO/srchnum.htm&r=1&f=G&l=50&s1=6,204,840.PN.&OS=PN/6,204,840&RS=PN/6,204,840
Nov 18 11:10:57 <zecke> lol
Nov 18 11:10:59 <zecke> ridicioulus
Nov 18 11:15:12 <florian> he
Nov 18 11:15:14 <florian> h
Nov 18 11:16:06 <zecke> Let us name TimeLine StoryLine
Nov 18 11:16:19 <zecke> and use Object Orienated thinking and say a file is a object
Nov 18 11:16:35 <zecke> and this patent can be implemented on UNIX and Macintosh wow, sure it is software...
Nov 18 11:20:29 <psokolovsky_> Hi!
Nov 18 11:21:00 <psokolovsky_> zecke, if the file was supposed to be attached to the mail in OE-dev ML, it's not there
Nov 18 11:21:31 <psokolovsky_> from few recent msgs in the ML, I got that attachments are filtered out
Nov 18 11:21:50 <psokolovsky_> (hope it's really not on my side)
Nov 18 11:22:24 <zecke> right, filtered away
Nov 18 11:22:47 <psokolovsky_> ;-)
Nov 18 11:23:28 <koen> flex -t bitbakescanner.l > bitbakescanner.cc
Nov 18 11:23:29 <koen> "bitbakescanner.l", line 67: unrecognized %option: reentrant
Nov 18 11:23:39 <zecke> koen: aptitude install flex
Nov 18 11:23:45 <zecke> koen: maybe remove flex-old first
Nov 18 11:24:00 <koen> psokolovsky_: not filtered out, just filtered
Nov 18 11:25:03 <koen> psokolovsky_: iirc it only allow text/plain upto 40k
Nov 18 11:26:06 <psokolovsky_> I meant that msg in, att out ;-)
Nov 18 11:26:10 <zecke> http://www.openembedded.org/~zecke/patches/
Nov 18 11:26:24 <psokolovsky_> cool
Nov 18 11:28:22 <zecke> numbers, numbers, numbers :)
Nov 18 11:28:29 <koen> zecke: still not working
Nov 18 11:28:33 <koen> zecke: flex 2.5.4
Nov 18 11:29:07 * koen installs flex-devel
Nov 18 11:29:18 * psokolovsky_ psokolovsky
Nov 18 11:29:43 <zecke> koen: flex 2.5.4 == flex-old, remove it
Nov 18 11:29:51 <psokolovsky_> zecke: will join in with testing as soon as out of bed completely ;-)
Nov 18 11:30:20 <zecke> I will torwards my physics assignment :)
Nov 18 11:30:21 <koen> zecke: that's what fink instaled
Nov 18 11:30:28 <zecke> koen: so fink sucks?
Nov 18 11:30:35 <koen> right
Nov 18 11:30:39 <zecke> koen: I'm too stupid for fink
Nov 18 11:30:56 <zecke> http://flex.sourceforge.net/
Nov 18 11:31:14 <psokolovsky_> koen, about nasty hacks: so, would overriding CXXFLAGS just for qte be a suitable solution for -nvisibility-inlines-hidden issue?
Nov 18 11:31:17 <zecke> koen: Why fink prefers flex from 1997 over flex from 2006 is...
Nov 18 11:31:33 <zecke> psokolovsky_: we have oe_filter_out
Nov 18 11:31:46 <zecke> psokolovsky_: it would be nice to find out why gcc is broken :)
Nov 18 11:31:55 <koen> psokolovsky_: you're the maintainer of the Obsolete Palmtop Integrated Environment
Nov 18 11:32:31 <psokolovsky_> koen, and that means... ? ;-)
Nov 18 11:32:31 <zecke> psokolovsky_: you could try adding a Q_EXPORT to the inline
Nov 18 11:32:51 <zecke> psokolovsky_: you are free to do whatever you want
Nov 18 11:33:03 <psokolovsky_> zecke, well, so far I hasn't even been able to get authoritative description what *exactly* that switch does ;-)
Nov 18 11:33:23 <zecke> psokolovsky_: googled already?
Nov 18 11:33:41 <psokolovsky_> zecke, koen: ok, thanks. I'll try Q_EXPORT first
Nov 18 11:33:52 <psokolovsky_> zecke, yeah, sure, googled
Nov 18 11:34:14 <psokolovsky_> not read teh newest gcc manual word ny word yet though ;-)
Nov 18 11:34:42 <koen|away> cute, every time I insult qt/e my a780 reboots
Nov 18 11:34:54 <psokolovsky_> but I wonder, why would they obfuscate it such way that google gives 5+ pages of their MLs for it first, and not the manual ;-)
Nov 18 11:35:03 <psokolovsky_> lol
Nov 18 11:35:50 <zecke> psokolovsky_: you know visibility?
Nov 18 11:36:04 <zecke> http://people.redhat.com/~drepper/ is always a good read
Nov 18 11:36:56 <psokolovsky_> zecke, sure, I understand the general concept ;-). I'd like to know the rules which gcc employs what to export with that switch and without it.
Nov 18 11:37:04 <zecke> psokolovsky_: http://people.redhat.com/drepper/dsohowto.pdf
Nov 18 11:37:16 <psokolovsky_> it cannot not to export *any* inline methods - that's plain dumb
Nov 18 11:37:17 <zecke> psokolovsky_: inline is a hint to the compiler and somehow it doesn't inline this function
Nov 18 11:37:24 <psokolovsky_> zecke, thanks, will read
Nov 18 11:37:26 <koen|gprs> psokolovsky_: any reason why that opie-2.6-backlight patch isn't upstream?
Nov 18 11:37:38 <zecke> psokolovsky_: but still removes it from one of the sections that export symbols
Nov 18 11:37:49 <psokolovsky_> koen|gprs, have no idea, but it applied to CVS HEAD, tested ;-)
Nov 18 11:39:15 <koen|gprs> g++ -dynamiclib -fPIC bitbakeparser.o bitbakescanner.o bitbakec.o -o bitbakec.so
Nov 18 11:39:15 <koen|gprs> ld: Undefined symbols:
Nov 18 11:39:15 <koen|gprs> _PyArg_ParseTupleAndKeywords
Nov 18 11:39:22 <koen|gprs> zecke: and a whole lot more symbols
Nov 18 11:39:34 <psokolovsky_> zecke, ok, thanks for hints. have to admit I know more how gcc work wrt export on windows, than on linux ;-). will catch up with that ;-)
Nov 18 11:40:18 <zecke> koen|gprs: yes, set LDFLAGS
Nov 18 11:40:29 <zecke> koen|gprs: send me a postcard and I tell you what do other than man ld
Nov 18 11:40:53 <zecke> psokolovsky_: I don't know this version of the document, I think I have read it last in 2005
Nov 18 11:41:20 <zecke> koen|gprs: LDFLAGS="-undefined -dynamic_lookup"
Nov 18 11:41:43 <koen|gprs> zecke: could you put that in the makefile?
Nov 18 11:42:06 <zecke> koen|gprs: I wanted to avoid wiritng if OSX... as I'm bad at authoring Makefiles
Nov 18 11:42:17 <koen|gprs> ld: -undefined: unknown argument: -dynamic_lookup
Nov 18 11:43:04 <zecke> export LDFLAGS="-undefined dynamic_lookup"
Nov 18 11:43:07 <zecke> this worked here
Nov 18 11:43:12 <koen|gprs> export LDFLAGS="-undefined dynamic_lookup"
Nov 18 11:43:29 <koen|gprs> yeah, 'man ld' told me about the spurious '-'
Nov 18 11:44:30 <zecke> koen|gprs: fink's python is probably broken :)
Nov 18 11:44:39 <zecke> python
Nov 18 11:44:43 <zecke> python -vvv
Nov 18 11:44:45 <koen|gprs> that's not fink's python
Nov 18 11:44:46 <zecke> import bitbakec
Nov 18 11:44:55 <zecke> oh Apple's python is broken as well :)
Nov 18 11:45:11 <koen|gprs>   File "ast.py", line 38
Nov 18 11:45:15 <koen|gprs>     class AstItem():
Nov 18 11:45:15 <koen|gprs>                   ^
Nov 18 11:45:15 <koen|gprs> SyntaxError: invalid syntax
Nov 18 11:45:42 <zecke> koen|gprs: hmm I managed to write python2.5 code :)
Nov 18 11:45:52 <koen|gprs> bbl, trainstop
Nov 18 11:45:56 <zecke> remove the ()
Nov 18 11:51:26 <mickeyl> morning
Nov 18 11:51:42 <mickeyl> RP: What do you need to be proven that Python Threads are better than you think?
Nov 18 11:52:50 <zecke> mickeyl: that they use two processors :)
Nov 18 11:53:09 <zecke> e.g. use clone on linux >= 2.4
Nov 18 11:53:19 <mickeyl> ok, i have a dual-xeon. if i can show that it's fully loaded using pythreads, it'll be enough?
Nov 18 11:53:54 * mickeyl claims the GIL won't be a limiting factor
Nov 18 11:55:02 <mickeyl> sirfred: at the moment, my work goes towards X/Gtk+, but eventually I'll be using X/Qt again.
Nov 18 12:13:33 <zecke> mickeyl: can you explain me the new object system and what is new in regard to Exceptions in py2.5?
Nov 18 12:14:08 <mickeyl> zecke: I'm afraid not :/ due to my workload I didn't have time to catch up with new developements.
Nov 18 12:14:16 <mickeyl> I'm falling behind wrt python
Nov 18 12:14:51 <mickeyl> the new object system has subtle changes in semantics, but removes a couple of warts. Just use it.
Nov 18 12:15:08 <zecke> mickeyl: use it by class Foo(object): pass
Nov 18 12:15:13 <mickeyl> right
Nov 18 12:15:21 <zecke> mickeyl: or is there more? e.g. not use __init__ but __new__?
Nov 18 12:15:37 <mickeyl> no, __new__ is optionally for sophisticated customizations
Nov 18 12:15:41 <mickeyl> __init__ is still the constructor
Nov 18 12:19:06 <zecke> koen|gprs: I will soon have a UMTS/GPRS flat rate as well
Nov 18 12:19:16 <mickeyl> you guys must be rich
Nov 18 12:19:22 <mickeyl> i can't afford the monthly fees :/
Nov 18 12:19:30 <mickeyl> 45 EUR here is just too much IMO
Nov 18 12:19:41 <zecke>  mickeyl: a) steve b) base
Nov 18 12:19:43 <mickeyl> yo koen
Nov 18 12:19:59 <mickeyl> zecke: yeah, base is 45 EUR:
Nov 18 12:20:05 <mickeyl> so steve will pay for it? :D
Nov 18 12:20:26 <zecke>  mickeyl: well, the flatrate in itself is 20 rest is phone :)
Nov 18 12:20:39 <zecke> mickeyl: now you can skip the SMS stuff and you are at 40 IIRC
Nov 18 12:20:45 <mickeyl> is it? i thought you can't take the dataflat without the voiceflat?
Nov 18 12:20:59 <zecke> mickeyl: dunno
Nov 18 12:21:17 <mickeyl> if the dataflat was independent i'd take it
Nov 18 12:21:31 <mickeyl> but voiceflat simply is no necessity here
Nov 18 12:21:41 <mickeyl> my mobile phone bill is like 5 EUR at max per month
Nov 18 12:22:37 <mickeyl> RP: we can use your forks, but use PyLinda for easy IPC
Nov 18 12:23:13 <mickeyl> RP: the really cool stuff is that this can also be used for cluster computing eventually
Nov 18 12:23:27 <zecke> mickeyl: let us keep the deps down
Nov 18 12:23:30 <mickeyl> think SETI@home :)
Nov 18 12:24:01 <mickeyl> zecke: there is no sense in inventing an own IPC when there are dozens of good solutions out there
Nov 18 12:24:06 <mickeyl> pylinda is light
Nov 18 12:24:44 <zecke> mickeyl: I'm just working around the patent system
Nov 18 12:29:28 <mickeyl> morning liam!
Nov 18 12:29:47 <lrg> hey mickeyl 
Nov 18 12:30:19 * mickeyl prepares breakfast
Nov 18 12:30:21 <mickeyl> l8er
Nov 18 12:46:31 <Spyro> lrg: hi?
Nov 18 12:48:52 <lrg> hey Spyro 
Nov 18 13:00:08 <koen|gprs> hey mickey|breakfast & zecke 
Nov 18 13:00:23 <zecke> jojo
Nov 18 13:00:34 <koen> zecke: €20/month for voice + gprs
Nov 18 13:01:27 <hrw> morning
Nov 18 13:01:37 <nicolasfr> hi
Nov 18 13:01:56 <koen> hey hrw & nicolasfr 
Nov 18 13:02:51 <hrw> hi nicolasfr 
Nov 18 13:03:32 <zecke> later
Nov 18 13:03:58 <hrw> zecke: that test with bitbake is for trunk?
Nov 18 13:04:36 <zecke> both, but the patch might only directly apply to trunk
Nov 18 13:04:55 <hrw> ok
Nov 18 13:18:57 <RP> hi mickey|breakfast 
Nov 18 13:20:06 <hrw> mickey|breakfast: smacznego
Nov 18 13:20:07 <Spyro> lrg: (sorr got called away)
Nov 18 13:20:18 <Spyro> lrg: I have a problem with the asoc code...
Nov 18 13:22:59 <hrw> hi Henning
Nov 18 13:23:26 <woglinde> hi marcin
Nov 18 13:23:46 <woglinde> did you get the cf-wlan card working?
Nov 18 13:24:12 <hrw> woglinde: tested in h2200/wince currently
Nov 18 13:24:33 <koen> hrw: you have a h2200 nowadays?
Nov 18 13:24:40 <hrw> koen: no, friend have
Nov 18 13:26:22 * koen starts ssh chain to the hx4700
Nov 18 13:27:01 <Spyro> lrg: still ther ?
Nov 18 13:33:46 <gerwinin> lo
Nov 18 13:33:58 <lrg> Spyro: still here
Nov 18 13:34:03 * gerwinin is recovered from yesterday
Nov 18 13:35:09 <Spyro> lrg: I created a platform device for the e740 pxa2xx ac97
Nov 18 13:35:18 <Spyro> lrg: but for some reason it doesnt attach
Nov 18 13:35:41 <Spyro> I copied the mainstone platform device code.
Nov 18 13:36:08 <lrg> Spyro: can you paste to pastebin
Nov 18 13:39:15 <Spyro> sure - wheres the pb ?
Nov 18 13:39:51 <RP> ~pastebin
Nov 18 13:40:02 <ibot> i guess pastebin is a place to paste your stuff without flooding the channel - try  http://pastebin.ca, or http://channels.debian.net/paste
Nov 18 13:41:26 * koen stabs minimo
Nov 18 13:41:31 <Spyro> http://pastebin.ca/251690
Nov 18 13:43:48 <lrg> Spyro: you don't need to register a pltform dev as asoc does this, it's probably best to base your machine driver on sound/soc/pxa/tosa.c
Nov 18 13:45:12 <lrg> Spyro: latest patch is at http://opensource.wolfsonmicro.com
Nov 18 13:45:40 <Spyro> k
Nov 18 13:46:02 <lrg> Spyro: alternatively, tosa.c is also available via alsa-kernel HG repo
Nov 18 13:46:41 <Spyro> lrg: so what are the other arches doing ? are they all wrong ?
Nov 18 13:47:06 <lrg> Spyro, pxa2xx and AT91xxxx work and are in alsa HG
Nov 18 13:47:37 <lrg> Spyro: i.MX and is in progress and S3C2xxx is almost working
Nov 18 13:47:39 <Spyro> lrg: yes, Im just trying to work out what this stuff all is - 
Nov 18 13:48:00 <Spyro> are the drivers like the mainstone one from the old code ?
Nov 18 13:48:35 <lrg> Spyro: the ac97 and dma are quite similar
Nov 18 13:49:36 <lrg> Spyro: btw, there are some docs in Doc/sound/alsa/soc
Nov 18 13:50:21 <Spyro> lrg: that should be useful.
Nov 18 13:50:38 <lrg> Spyro: :)
Nov 18 13:50:41 <microw> what is this channel for?
Nov 18 13:52:00 <koen> microw: www.openembedded.org
Nov 18 13:56:00 <mickeyl> heh
Nov 18 13:56:08 <nicolasfr> I have just updated my org.oe.dev branch, and now when compiling latest glibc-2.5 I have an error about missing -lgcc_eh ? Do I need some package on my host?
Nov 18 13:56:14 <Spyro> lrg: why does tosa.c include 'tmio' ?
Nov 18 13:57:55 <hrw> *JAWN*
Nov 18 13:57:59 <lrg> Spyro: afaik, it's for tosa specific audio control
Nov 18 13:58:54 <hrw> ok. time to hack on misc1
Nov 18 13:59:20 <hrw> 5G of sources wait
Nov 18 13:59:20 <lrg> hrw: misc1 ?
Nov 18 13:59:46 <hrw> lrg: misc1 is remote machine with one user: me
Nov 18 14:00:04 <lrg> hrw: ah :)
Nov 18 14:00:16 <hrw> ath64 3500+ but 32bit mode
Nov 18 14:00:27 <hrw> 758M    /home/hrw/devel/sources/svn_dir
Nov 18 14:00:27 <hrw> 1.5G    /home/hrw/devel/sources/cvs_dir
Nov 18 14:00:27 <hrw> 2.8G    /home/hrw/devel/sources/dl_dir
Nov 18 14:00:28 <hrw> 69M     /home/hrw/devel/sources/git_dir
Nov 18 14:01:00 <koen> that is kind of frightening
Nov 18 14:01:28 <koen> >30% of sources is fetched from scm
Nov 18 14:01:35 <koen> (not counting compression)
Nov 18 14:03:34 <Spyro> koen: also scm sources are generally bigger...
Nov 18 14:03:59 <koen> yeah, twice as big
Nov 18 14:04:05 <koen> to give svn a 'local diff'
Nov 18 14:04:41 <hrw> too bad that SCM snapshot archive are not SCM_rest-of-name
Nov 18 14:08:25 <gerwinin> Koen: I read this bug report : http://bugs.openembedded.org/show_bug.cgi?id=749
Nov 18 14:08:42 <gerwinin> Koen: But I am still encountering this error and I am bit stuck with it 
Nov 18 14:09:24 <koen> gerwinin: which version of rxvt?
Nov 18 14:10:02 <gerwinin> 7.9
Nov 18 14:10:22 <gerwinin> Koen: I tried to compile with 7.7 as well same issue 
Nov 18 14:10:33 <koen> for x86?
Nov 18 14:10:54 <gerwinin> yes
Nov 18 14:10:56 <koen> you could see if the site file is missing bits compared to arm
Nov 18 14:11:12 <gerwinin> Koen: let me check
Nov 18 14:14:00 <gerwinin> Koen: it seems the x86 site file has nothing about rxvt neither does the arm file
Nov 18 14:22:57 <hrw> INHERIT += "own-mirrors" :D
Nov 18 14:23:33 <hrw> hi CoreDump|home 
Nov 18 14:23:43 <koen> hey CoreDump|home 
Nov 18 14:23:43 <CoreDump|home> hi
Nov 18 14:24:05 <gerwinin> hey CoreDump
Nov 18 14:30:23 <hrw> ~hail PREMIRRORS
Nov 18 14:30:34 * ibot bows down to PREMIRRORS and chants, "I'M NOT WORTHY!!"
Nov 18 14:30:41 <hrw> 06:53:05 (35.45 MB/s) - `/a/home/hrw/devel/build/test/tmp/downloads/libtool-1.5.10.tar.gz' saved [2699923/2699923]
Nov 18 14:34:59 <hrw> bitbake -cfetchall gcc-cross with empty stamps and empty downlonad == 24s
Nov 18 14:36:39 <hrw> I want source mirror in my LAN...
Nov 18 14:36:52 <hrw> (but let it does not use my network connection ;D
Nov 18 14:49:51 <gerwinin> Koen: problem solved you think it is wise to add this to bugzilla ?
Nov 18 14:50:11 <koen> if you're still seeing, reopen the bug 
Nov 18 14:50:55 <hrw> real    0m44.607s
Nov 18 14:50:55 <hrw> user    0m16.712s
Nov 18 14:50:55 <hrw> sys     0m7.398s
Nov 18 14:51:09 <hrw> time needed for fetching sources for bootstrap-image
Nov 18 14:55:59 <RP> mickeyl: With python threads, I'm basically concerned that it seems to timeshare the interpreter amongst "threads" rather than true threading. True threading allows us to let the uderlying OS do the timesharing potentially over multiple CPUs and therefore looks more efficient for OE/bitbake use
Nov 18 14:58:11 <hrw> RP: PREMIRRORS can be set only in bbclass?
Nov 18 14:58:13 <mickeyl> RP: agreed. no problem with real processes. Just a matter of chosing the proper IPC
Nov 18 14:58:32 <RP> hrw: It should be a normal variable
Nov 18 14:58:51 <mickeyl> RP: how do you communicate between BB threads atm.?
Nov 18 14:58:53 <RP> mickeyl: right. I'm not sure what to do there...
Nov 18 14:59:04 <RP> mickeyl: We dont :}
Nov 18 14:59:12 <RP> mickeyl: We just watch the exit status of the processes
Nov 18 14:59:12 <mickeyl> RP: heh. i see. 
Nov 18 14:59:54 <mickeyl> RP: ok, let us do the following. tell me where do look at the thread "controlling" and I'll print that stuff out and spend a couple of hours reading that on the sofa and thinking about IPC
Nov 18 15:00:23 <RP> mickeyl: The thread controlling it at the bottom of runqueue.py
Nov 18 15:00:38 <RP> mickeyl: Although I have some updates I should commit which improve it
Nov 18 15:00:38 <hrw> RP: http://pastebin.com/827377
Nov 18 15:00:42 <RP> Let me do that now...
Nov 18 15:01:38 <hrw> when in inherit own-mirrors.bbclass to set PREMIRRORS it works. when I try to add PREMIRRORS in local.conf it fails.
Nov 18 15:02:09 <RP> mickeyl: I'm seriously considering using some kind of sockets as one thing I'd like is to be able to have bitbake on multiple machines, all being controlled from one GUI (using a shared set of directories)
Nov 18 15:02:47 <mickeyl> RP: yes. but please don't let us invent this
Nov 18 15:02:52 <mickeyl> RP: there are ready made solutions for that
Nov 18 15:03:01 <mickeyl> RP: solutions which don't add much overhead
Nov 18 15:04:03 <RP> mickeyl: We don't actually need much in the way of IPC when you think out it. We just need to know the exit status and what the errors were (if any)
Nov 18 15:04:20 <mickeyl> RP: you forget status updates
Nov 18 15:04:30 <RP> mickeyl: But I agree, we should try and use something standard if we can...
Nov 18 15:04:32 <koen> mickeyl: like OE 3 years ago :)
Nov 18 15:04:52 <koen> "look, python can do <foo>, lets use it"
Nov 18 15:05:11 <hrw> koen: instead of writing it in php :D
Nov 18 15:05:13 <RP> mickeyl: What status updates? Each task just runs and finished. There is no real status unbetween (unless you mean the logging messages)
Nov 18 15:05:37 <hrw> RP: status like 'I'm still running'
Nov 18 15:05:57 <RP> hrw: In that case, the process still exists ;-)
Nov 18 15:06:04 <koen> 'heartbeat'
Nov 18 15:06:06 <hrw> RP: imagine cluster of pII building world. what it one of them will get giac to build?
Nov 18 15:06:15 <hrw> hi den-ros 
Nov 18 15:06:50 <RP> We have no way to get status from the commands we run so we don't have anything to pass back
Nov 18 15:06:51 <hrw> RP: when OOM will go does task get time to report 'Help, help, Im dying...'?
Nov 18 15:07:15 <RP> hrw: Process exits with an error code
Nov 18 15:07:15 <hrw> ok
Nov 18 15:07:55 <RP> hrw: It looks like you need to use a class for the mirrors syntax
Nov 18 15:08:31 <mickeyl> RP: i mean the logging messages
Nov 18 15:08:40 <mickeyl> RP: these one should be communicated via IPC as well
Nov 18 15:09:06 <hrw> RP: I will probably introduce own-mirrors.bbclass with PREMIRROR_URL variable
Nov 18 15:09:23 <mickeyl> because the GUI will be responsible for displaying them soon
Nov 18 15:10:32 <RP> mickeyl: I have given this some thought and I'm wondering if we can't just extend the stamps directory, using the stamps to point to the logs
Nov 18 15:11:11 <RP> mickeyl: There is one thing I'd like to work into this - Having two bitbake's running at once on the same tmp dir safely
Nov 18 15:11:40 <mickeyl> RP: hmm... we could, but that looks like a hack to me. Why don't we rather substitute printing log message with sending via ipc?
Nov 18 15:12:22 <RP> mickeyl: It needs careful thought. I've not come up with any solution I like yet :-/
Nov 18 15:12:41 <RP> mickeyl: I would like 'MACHINE=foo bitbake opie-image' and 'MACHINE=bar bitbake opie-image' to be able to run on the same tmp at the same time
Nov 18 15:13:11 <mickeyl> RP: hmm, are we mixing two different issues here?
Nov 18 15:13:41 <mickeyl> print messages via IPC instead of console output is one
Nov 18 15:13:55 <mickeyl> the other one is making it safe for two BB's not stepping over each other's toe
Nov 18 15:14:02 <RP> mickeyl: yes and no. There is some overlap in that which bitbake should see which log messages
Nov 18 15:14:05 <Spyro> RP: the TOSA sound driver is including a TMIO header - is that intended ?
Nov 18 15:14:46 <RP> Spyro: tosa.c is machine specific so it can do that
Nov 18 15:15:15 <mickeyl> RP: well, unless you don't want one bitbake frontend controlling two different bitbake backends at the same time, it's really easy by using the IPC.
Nov 18 15:16:25 <mickeyl> anyway, let me read a bit of your current code before continung
Nov 18 15:16:31 * mickeyl prints out runqueue
Nov 18 15:16:53 <hrw> psokolovsky_: I want to remove some qpe apps due to their unfetchable status
Nov 18 15:17:13 <hrw> psokolovsky_: will add them into /removal.txt soon
Nov 18 15:18:18 <RP> mickeyl: I do agree IPC is the way to go
Nov 18 15:19:37 <Spyro> RP: yes but did you mean to?
Nov 18 15:19:52 <RP> Spyro: I didn't write it
Nov 18 15:20:03 <Spyro> oh ok
Nov 18 15:20:05 <RP> Spyro: I did poodle, corgi and spitz ;-)
Nov 18 15:20:11 <Spyro> :)
Nov 18 15:20:22 <Spyro> poo, my module seems to have stiffed the thing...
Nov 18 15:21:48 <hrw> I want to remove maemo
Nov 18 15:22:14 <RP> hrw: Please don't remove maemo yet. I would like to see it fixed up
Nov 18 15:22:26 <hrw> RP: I will add it to removal.txt
Nov 18 15:22:41 <hrw> maemo in OE has much worse support then OPIE
Nov 18 15:22:59 <hrw> opie atleast has maintainer and can be built.
Nov 18 15:23:00 <Crofton> thats name calling :)
Nov 18 15:23:05 <hrw> maemo lack both
Nov 18 15:23:31 <den-ros> hrw:  Hi :)
Nov 18 15:24:38 <CIA-4> 03rpurdie * r691 10bitbake/ (bin/bitbake lib/bb/runqueue.py lib/bb/shell.py): 
Nov 18 15:24:38 <CIA-4> runqueue.py: Change failed tasks handling so all failed tasks are reported, not
Nov 18 15:24:38 <CIA-4> just the first. Also add signal handling so Ctrl+C only interrupts the main
Nov 18 15:24:38 <CIA-4> tasks upon the first keypress, the second keypress sends SIGTERM to all children
Nov 18 15:25:05 <den-ros> hrw: Sorry, i was away from computer.
Nov 18 15:26:10 <RP> mickeyl: That should make runqueue a little more readable and handles failures a bit more gracefully
Nov 18 15:26:30 <hrw> RP: restarted fetchall after update.
Nov 18 15:26:39 <mickeyl> RP: ok
Nov 18 15:26:41 * mickeyl prints again
Nov 18 15:26:46 <mickeyl> bbl
Nov 18 15:26:50 <RP> mickeyl: sorry :-/
Nov 18 15:26:55 <mickey|bbl> np :)
Nov 18 15:27:23 <hrw> someone familiar with multifunction printers? I want to buy one of them to have printer/scaner/copier at home
Nov 18 15:27:42 <hrw> koen: this changeset is for you 
Nov 18 15:27:44 <CIA-4> 03hrw 07org.oe.dev * rd1a08813... 10/ (1 removal.txt): 
Nov 18 15:27:44 <CIA-4> removal.txt: first version of list of stuff to be removed from metadata
Nov 18 15:27:44 <CIA-4> - 2006-11-20: plinciv
Nov 18 15:27:44 <CIA-4> - 2006-12-12: maemo
Nov 18 15:28:02 <NAbyss> hrw: Yeah, I've got one here.
Nov 18 15:28:12 <koen> hrw: cool
Nov 18 15:29:39 <hrw> NAbyss: how this is supported under linux (when all functions are supported)? two usb devices after hub or other?
Nov 18 15:29:57 <woglinde> hrw hm about the printers
Nov 18 15:30:05 <woglinde> hrw laser oder inkjet?
Nov 18 15:30:35 <NAbyss> hrw: Usually appears as a single device with multiple endpoints, from what I remember of the one at work.. the one I have here's via parallel.
Nov 18 15:30:42 <hrw> woglinde: inkjet - laser ones are too expensive
Nov 18 15:30:50 <NAbyss> hrw: I'd definitely check linuxprinting.org for compatibility
Nov 18 15:30:53 <hrw> NAbyss: I do not have LPT in machines
Nov 18 15:31:28 <psokolovsky_> hrw, re:"removal.txt" ok
Nov 18 15:32:10 <hrw> psokolovsky_: I will prepare list during week probably
Nov 18 15:32:22 <psokolovsky_> ok
Nov 18 15:34:40 <woglinde> hrw than only a hp comes to my mind
Nov 18 15:34:58 <woglinde> samsung has only binary-linux driver
Nov 18 15:35:33 <zecke> ho
Nov 18 15:36:12 <hrw> ho zecke 
Nov 18 15:36:47 <zecke> hrw: the numbers? *numbers*
Nov 18 15:38:16 <hrw> zecke: progressing
Nov 18 15:38:31 <hrw> zecke: its 5-6minutes per pass, 9 passes
Nov 18 15:39:19 <zecke> hehe, 5 to 6 minutes on parsing?
Nov 18 15:39:21 <hrw> zecke: and I had to do something on machine in meantime so last test (3 passes) need to repeat
Nov 18 15:39:37 <hrw> real    5m34.047s
Nov 18 15:39:38 <hrw> user    4m46.000s
Nov 18 15:39:38 <hrw> sys     0m8.915s
Nov 18 15:39:41 <zecke> actually I only care about the user time
Nov 18 15:39:49 <zecke> my macbook does that in 2:42
Nov 18 15:40:37 <hrw> btw.. I want to add one nasty change to svn fetched
Nov 18 15:40:40 <hrw> fetcher
Nov 18 15:41:10 <hrw> s/'svn co'/'echo t|svn co' to get autofetching working with ssl repos
Nov 18 15:41:44 <hrw> or will change svncommands vars in local.conf
Nov 18 15:42:07 <zecke> hrw: or add a new param, ;BROKEN_HOST=1
Nov 18 15:42:14 <zecke> hrw: or put the SSL certificates into OE
Nov 18 15:42:33 <zecke> and people that verified the certificate to approve on the addition
Nov 18 15:42:36 <hrw> zecke: easier would be ;GOOD_CERT=1
Nov 18 15:42:49 <hrw> less recipes to change
Nov 18 15:43:11 <zecke> hrw: ssl for svn is a nice idea. No one can give you a bad rev due a man in the middle
Nov 18 15:43:24 <zecke> hrw: but this is completely void if you don't trust the SSL certificate
Nov 18 15:43:27 <hrw> speaking about ssl.. I need to test CACert certificate one day for my site
Nov 18 15:43:46 <zecke> hrw: you would accept certificates of random-joe man in the middle
Nov 18 15:43:48 <hrw> zecke: I do not trust self-signed certs
Nov 18 15:43:58 <zecke> and at that point just skip SSL
Nov 18 15:44:02 <hrw> I can accept CACert ones
Nov 18 15:44:38 <zecke> hrw: come to the 23C3 (or is it 24C3)
Nov 18 15:44:59 <hrw> zecke: ?
Nov 18 15:45:24 <hrw> CCC meeting?
Nov 18 15:45:41 <zecke> hrw: yes, CACert will be present and you can sign enough keys to self-sign the certificate again
Nov 18 15:47:40 <hrw> zecke: currently I have 102 points in cacert
Nov 18 15:52:10 <hrw> zecke: numbers sent
Nov 18 15:53:34 <mickey|bbl> RP: ok, if I understand it correctly, all we have to do to solve the ncurses integration is the following:
Nov 18 15:54:00 <mickey|bbl> a) factor the while 1 loop in runqueue into a runQueueIteration()
Nov 18 15:54:11 <mickey|bbl> b) call runQueueIteration() from ncurses main loop
Nov 18 15:54:33 <mickey|bbl> c) make try_build send all messages via IPC
Nov 18 15:54:47 <mickey|bbl> d) make ncurses main loop get data from IPC and display / act
Nov 18 15:54:55 <mickey|bbl> do you agree?
Nov 18 15:57:06 <mickey|bbl> if so, i can have a go at that tomorrow
Nov 18 15:57:15 <mickey|bbl> now back to relaxing for the rest of the day. cu
Nov 18 15:58:04 <woglinde> bye mickeyl
Nov 18 15:59:01 <zecke> hrw: so we save 20 seconds?
Nov 18 15:59:04 <RP> mickey|bbl: The waitpid calls are the tricky bit
Nov 18 15:59:26 <woglinde> zecke is specialist
Nov 18 15:59:29 <woglinde> *g*
Nov 18 16:01:23 <mickey|bbl> RP: might as well run the while1 in a seperate thread (yes, a Python thread ;))
Nov 18 16:01:45 <hrw> zecke: looks like
Nov 18 16:03:40 <koen> RP: can new bitbake clients be attached 'on the fly'?
Nov 18 16:04:05 <RP> mickey|bbl: right :}
Nov 18 16:04:19 <RP> koen: no idea yet
Nov 18 16:05:21 <RP> mickey|bbl: My question is how do you plan to filter the information into the right windows in a generic fashion?
Nov 18 16:06:03 <RP> mickey|bbl: Presumably, modify msg.py to redirect data but that doesn't tell you which window it should go to?
Nov 18 16:07:04 <RP> mickey|bbl: Also, can python threads and waitpid work in the same program?
Nov 18 16:12:28 <zecke> RP: should we push this cleaning of anonfuncs?
Nov 18 16:15:38 <RP> zecke: yes, i think so
Nov 18 16:17:23 <zecke> RP: the good thing is that this function shows up directly in a trace :)
Nov 18 16:18:28 <zecke> ~10 % speed up on parsing hmm
Nov 18 16:18:29 <hrw> zecke: do not forget about glib-2.0.inc
Nov 18 16:18:35 <RP> zecke: :)
Nov 18 16:22:00 <hrw> btw - I'm curious will someone notice ;umbaumba; in numbers mails
Nov 18 16:22:26 <hrw> ;D
Nov 18 16:29:44 <zecke> mickey|bbl: what is your favorite indention?
Nov 18 16:31:53 <zecke> hrw: would you like to continue using bitbake 1.7. for oz354x?
Nov 18 16:32:04 <mickey|bbl> zecke: 4 spaces. no tabs.
Nov 18 16:32:41 <zecke> mickey|bbl: that is sane :)
Nov 18 16:32:50 <zecke> mickey|bbl: python __anonymous now requires that
Nov 18 16:32:56 <mickey|bbl> zecke: cool
Nov 18 16:33:39 <hrw> zecke: I'm fine with 1.6 for it
Nov 18 16:34:41 <hrw> ~curse debian/amd64
Nov 18 16:34:44 <ibot> May the fleas of a thousand camels infest your most sensitive regions, debian/amd64 !
Nov 18 16:35:15 <zecke> hrw: should I send you a free amd64 ubuntu version? It is like debian but you don't need to configure it
Nov 18 16:35:51 <hrw> zecke: haha
Nov 18 16:35:53 <hrw> ha
Nov 18 16:35:58 * gremlin[it] wisper ... fedora ... fedora ... fedora :) :) :) 
Nov 18 16:36:17 <hrw> gremlin[it]: thx. I have RHEL on other tab in this console
Nov 18 16:36:59 <hrw> apt is nearly fixed
Nov 18 16:37:04 <CIA-4> 03freyther 07org.oe.dev * rc46bb9f6... 10/ (31 files in 10 dirs): (log message trimmed)
Nov 18 16:37:04 <CIA-4> Micro-Optimisation decreasing initial parsing time by 10%
Nov 18 16:37:04 <CIA-4>  python () {} and python __anonymous () {} are as the same
Nov 18 16:37:04 <CIA-4>  says functions without a name. They get executed when the
Nov 18 16:37:04 <CIA-4>  main bb file is completely parsed. This is used to set
Nov 18 16:37:07 <CIA-4>  information like FILESDIR.
Nov 18 16:37:09 <CIA-4>  This is a python method so it gets evaled which means compiled
Nov 18 16:38:28 <CIA-4> 03zecke123 * r692 10bitbake/lib/bb/parse/parse_py/BBHandler.py: 
Nov 18 16:38:28 <CIA-4> bitbake/ old parser: Compile all anonfuncs at once!
Nov 18 16:38:28 <CIA-4>  This gives a small speed-up and forces anonfuncs
Nov 18 16:38:28 <CIA-4>  to follow the same spacing/et/noet settings
Nov 18 16:40:59 <zecke> hrw: real    1m53.744s
Nov 18 16:40:59 <zecke> user    1m33.619s
Nov 18 16:40:59 <zecke> sys     0m6.340s
Nov 18 16:41:33 <hrw> zecke: nice
Nov 18 16:41:46 <zecke> that is the current python parser
Nov 18 16:42:15 <zecke> I wonder where the difference is (besides that apple is just more sexy)
Nov 18 16:43:08 <RP> zecke: That is much faster than on my server :-/
Nov 18 16:43:49 <zecke> RP: I always thought that IO must suck on a laptop but it doesn't...
Nov 18 16:44:00 <hrw> time to reboot. those acpi debugs kills this machine
Nov 18 16:44:10 <RP> zecke: Funnily enough, my laptop builds faster than my server too :}
Nov 18 16:44:10 <zecke> hrw: later
Nov 18 16:44:26 <zecke> RP: maybe your server has a better battery life?
Nov 18 16:45:10 <zecke> RP: we should apply the same strategy to expand that we have for update_data
Nov 18 16:45:23 <zecke> RP: on setting content remember if there was a ${}
Nov 18 16:45:43 <zecke> or better print how often eval was called and no expansion was done
Nov 18 16:46:53 <zecke> hmm I have another 1s speed up by not initializing fetcher and setting A
Nov 18 16:48:21 <hrw> re
Nov 18 16:48:29 <zecke> hrw: another test
Nov 18 16:48:43 <hrw> first will redo recent one
Nov 18 16:49:01 <zecke> http://rafb.net/paste/results/tIIOfS25.html
Nov 18 16:49:33 <RP> zecke: I'm wondering about actually tracking dependencies in the expand_cache
Nov 18 16:49:40 <hrw> RP: we need to add "USB hiddev" into kernels
Nov 18 16:50:48 <RP> hrw: ok
Nov 18 16:50:57 <hrw> RP: my BT dongle needs it to switch from hid 2 hci mode
Nov 18 16:51:37 <hrw> http://rafb.net/paste/results/hFZwwU55.html
Nov 18 16:51:51 <hrw> two bt dongles in one machine.
Nov 18 16:53:04 <RP> zecke: How to track depends within eval()? :-/
Nov 18 16:55:56 <zecke> RP: heuristic
Nov 18 16:56:12 <zecke> on setVar look if there is a ${ in the raw string
Nov 18 16:57:18 <zecke> I will generate some numbers now
Nov 18 16:58:12 <zecke> RP: BTW: I should add a Snail Mail PostCard license
Nov 18 16:58:21 <hrw> real    2m52.637s
Nov 18 16:58:21 <hrw> user    2m25.234s
Nov 18 16:58:21 <hrw> sys     0m4.702s
Nov 18 16:58:31 <hrw> zecke: thats with current OE/Bitbake
Nov 18 16:58:48 <zecke> how fast it before?
Nov 18 17:00:19 <hrw> will test but first with your paste
Nov 18 17:01:02 <hrw> zecke: and now this machine is at 2GHz instead of 1GHz
Nov 18 17:01:32 <RP> zecke: I mean how to I know that ABC = "${@bb.data.getVar('MACHINE', d, 0)}" depends on MACHINE
Nov 18 17:01:34 <zecke> magically changed?
Nov 18 17:01:42 <hrw> zecke: cpufreq
Nov 18 17:02:03 <zecke> RP: you don't, you ast least know you can expand it :)
Nov 18 17:02:18 <zecke> RP: see the two regexps we do go over the string twice (_twice_)
Nov 18 17:02:22 <zecke> __twice__
Nov 18 17:02:26 <zecke> _twice_
Nov 18 17:02:32 <zecke> hmm
Nov 18 17:03:32 <hrw> real    2m50.156s
Nov 18 17:03:33 <hrw> user    2m26.635s
Nov 18 17:03:33 <hrw> sys     0m4.941s
Nov 18 17:03:53 <hrw> thats with set_additional_vars disabled
Nov 18 17:05:12 <hrw> zecke: reverted your changes now
Nov 18 17:05:36 <zecke> spend more in user time :)
Nov 18 17:05:48 <zecke> hehe that is funny, spending more for less that is turbo capitalism
Nov 18 17:07:13 <zecke> RP: Expands 3505686
Nov 18 17:07:13 <zecke> Expanded 246821
Nov 18 17:07:43 <zecke> only in 246.821 cases the string changed after expand
Nov 18 17:08:36 <hrw> real    2m55.583s
Nov 18 17:08:36 <hrw> user    2m37.809s
Nov 18 17:08:36 <hrw> sys     0m5.229s
Nov 18 17:08:50 <hrw> zecke: thats without your recent changes
Nov 18 17:09:38 <zecke> so some time was saved
Nov 18 17:10:09 <zecke> RP: Expands 3764331
Nov 18 17:10:09 <zecke> Expanded 562240
Nov 18 17:10:13 <zecke> now without the expand_cache
Nov 18 17:10:39 <zecke> I wonder why we have more lookups now :}
Nov 18 17:10:45 <chouimat> morning
Nov 18 17:11:40 <zecke> RP: so we have 3.5 million string expands
Nov 18 17:11:52 <zecke> RP: about 0.5 million really expand something
Nov 18 17:12:06 <zecke> RP: proposal: Cache information if it is worth expanding the key
Nov 18 17:12:30 <zecke> just a heuristic like if '${' in string -> worth expanding
Nov 18 17:13:18 <RP> zecke: I'd agree with that
Nov 18 17:14:39 <zecke> http://rafb.net/paste/results/9467R651.html patch used to get the numbers
Nov 18 17:18:30 <CIA-4> 03hrw 07org.oe.dev * r099889fc... 10/ (1 packages/libchm/chmlib_0.38.bb): chmlib: fetch sources from Debian mirrors instead of non-reachable upstream
Nov 18 17:19:05 <zecke> mickey|bbl: can't you apply for a Prof. somewhere and I take all your classes
Nov 18 17:19:07 <hrw> Crofton: packages/ossie/*.bb are marked BROKEN
Nov 18 17:19:09 <zecke> mickey|bbl: and you let me pass?
Nov 18 17:19:35 <koen> aargh
Nov 18 17:19:40 * koen stabs svn
Nov 18 17:19:52 <hrw> Crofton: they are not fetchable (we have bug open for it)
Nov 18 17:19:55 <koen> SyntaxError: invalid syntax
Nov 18 17:19:55 <koen> koen@bitbake:~/OE/build$ bitbake gtk+ minimo
Nov 18 17:19:55 <koen> Traceback (most recent call last):
Nov 18 17:19:55 <koen>   File "/data/build/oe/bitbake/bin/bitbake", line 28, in ?
Nov 18 17:19:55 <koen>     from bb import utils, data, parse, event, cache, providers, taskdata, runqueue
Nov 18 17:19:56 <koen>   File "/data/build/oe/bitbake/lib/bb/runqueue.py", line 446
Nov 18 17:19:57 <koen>     <<<<<<< .mine
Nov 18 17:19:58 <hrw> Crofton: can you take care of it?
Nov 18 17:19:59 <koen>     ^
Nov 18 17:20:01 <koen> SyntaxError: invalid syntax
Nov 18 17:20:03 <hrw> koen: I also love it
Nov 18 17:20:11 <koen> which idiot decided that an scm may mess up content?
Nov 18 17:22:31 <Crofton> hrw, the problem is there is a password on the svn
Nov 18 17:22:45 <Crofton> of course anyone can get an account
Nov 18 17:23:28 <Crofton> I am seriously tempted to open anon access, even if it does annoy the uni lawyer
Nov 18 17:23:52 <Crofton> can I use svk to mirror a svn repo?
Nov 18 17:24:38 <hrw> Crofton: or you can release and use released versions by default in OE
Nov 18 17:24:57 <Crofton> We have an idiot lawyer that is in to click through licenses
Nov 18 17:25:01 <Crofton> ~lart lawyers
Nov 18 17:25:02 * ibot takes a large goose feather pillow and swings it wildly in lawyers's direction, hitting lawyers and sending lawyers flying into the closet
Nov 18 17:25:17 <Crofton> I am going o get her the open source licensing book for christmas
Nov 18 17:25:36 <hrw> Crofton: I'm working on source archive and actually .*ossie.* landed in bbmask
Nov 18 17:25:44 <Crofton> I am not sure if release versions work with oe yet :)
Nov 18 17:26:02 <zecke> Crofton: sure, or just use svnmirror
Nov 18 17:26:47 <Crofton> I saw a cool paper at a conference by some guys that se tinderbox
Nov 18 17:26:56 <Crofton> they integrated it with irc
Nov 18 17:27:05 <Crofton> for almost real time bitching
Nov 18 17:27:15 <zecke> *time*
Nov 18 17:27:18 <Crofton> I'll work on the ossie build stuff over the next week
Nov 18 17:27:25 <hrw> Crofton: thx
Nov 18 17:27:31 <zecke> I could bitch more vulgar if I would have the time...
Nov 18 17:27:43 <hrw> zecke: in how many languages?
Nov 18 17:27:48 <Crofton> I also need to commit some fixes for oe style checks
Nov 18 17:27:51 <mickey|bbl> zecke: dunno... I'm spoiled by non-academics by now
Nov 18 17:28:10 <mickey|bbl> zecke: oh btw... the first advisor has submitted his review for my thesis
Nov 18 17:28:15 <mickey|bbl> waiting for the 2nd now...
Nov 18 17:28:22 <hrw> mickey|bbl: positive review?
Nov 18 17:28:34 <mickey|bbl> hrw: absolutely. he gave me an 'A'
Nov 18 17:28:36 <mickey|bbl> :))
Nov 18 17:28:52 <hrw> kewl
Nov 18 17:28:54 <RP> mickey|bbl: yay :)
Nov 18 17:29:00 <mickey|bbl> :)
Nov 18 17:29:13 <hrw> mickey|bbl: so what's Doc?
Nov 18 17:29:19 <hrw> mickey|bbl: so what's up Doc?
Nov 18 17:29:22 <mickey|bbl> hehe
Nov 18 17:29:25 <woglinde> hehe
Nov 18 17:29:46 <mickey|bbl> unfortunately due to this delay (2nd one) I won't make it this year
Nov 18 17:29:54 <mickey|bbl> public defense will be pushed into 2007
Nov 18 17:30:02 <mickey|bbl> but it's ok... i'm busy enough
Nov 18 17:30:11 <hrw> mickey|bbl: more time to get some weapons for defence
Nov 18 17:30:18 <mickey|bbl> hehe#
Nov 18 17:30:19 <mickey|bbl> right
Nov 18 17:30:57 <hrw> when I had defence of my MoS we had suppliers of illegal russian weapons only few km
Nov 18 17:32:40 <hrw> ~lart amd for 1.0/1.8/2.0GHz steps in athlon64 3200
Nov 18 17:32:40 * ibot DoSes amd for 1.0/1.8/2.0GHz steps in athlon64 3200
Nov 18 17:33:13 <koen> note to self: don't show Photobooth.app to parents
Nov 18 17:34:10 <Crofton> why do I go to a conference and collect biz cards from people from various defense orgs
Nov 18 17:34:27 <Crofton> of course they are not only US based ....
Nov 18 17:38:28 <hrw> ok, time to go do some shopping
Nov 18 17:38:48 <hrw> and during late evening: The IT Crowd 
Nov 18 17:38:59 <koen> hrw: htat's a pretty nice show
Nov 18 17:39:24 <hrw> koen: I first heard of it 2 days ago
Nov 18 17:39:43 * koen 2 weeks ago
Nov 18 17:39:51 <hrw> but someone invented bittorrent just for it
Nov 18 17:39:56 <koen> and it's on belgian tv
Nov 18 17:40:00 <mmp> hrw: strange, I have 3400+ and I have 0.8/1.8/2.0/2.2 ...
Nov 18 17:40:08 <hrw> mmp: Venice?
Nov 18 17:40:27 <mmp> I'm not sure about the codenames...
Nov 18 17:40:30 <hrw> mmp: older cores can have it in other way
Nov 18 17:40:32 <mmp> mobile athlon 64
Nov 18 17:40:33 <zecke> I HATE PYTHON EXCEPTIONS
Nov 18 17:40:40 <hrw> mmp: mobile.
Nov 18 17:40:47 <koen> zecke: s/EXCEPTIONS//
Nov 18 17:40:49 <mmp> hrw: aha, I forgot:)
Nov 18 17:41:05 <hrw> mmp: venice is iirc latest core line - 1.8, 2.0, 2.2 were released
Nov 18 17:41:12 * mmp is reminding that his brother's desktop has also minimal frequency at 1.0GHz
Nov 18 17:41:14 <hrw> 3000/3200/3500
Nov 18 17:42:30 <hrw> ~lart mplayer 
Nov 18 17:42:30 * ibot beats the living hamstercrap out of mplayer
Nov 18 17:44:00 <hrw> they totally fscked font support
Nov 18 17:48:27 <CIA-4> 03koen 07org.oe.dev * ra5a56d52... 10/ (1 conf/distro/angstrom-2007.1.conf): angstrom-2007.1: prefer cairo 1.3.2
Nov 18 17:49:29 <mmp> hmm, sounds tasty
Nov 18 17:49:40 * mmp is considering updating his oe.dev tree
Nov 18 17:50:24 <koen> mmp: it's never wise to work of an outdated tree
Nov 18 17:51:02 <hrw> lets check debian package for mplayer...
Nov 18 17:51:23 <mmp> koen: I don't want to get my local modifications over written, at least not yet... . I'm doing ugly hacks to it (maybe because I don't know how to use bitbake efficiently)
Nov 18 17:51:49 <koen> mmp: monotone doesn't overwrite local modifications
Nov 18 17:52:15 <koen> it also doesn't fsck up content with 'inline diffs' like cvs and svn
Nov 18 17:52:25 <zecke> koen: it can fuck up content if you ask it to :)
Nov 18 17:52:35 <koen> zecke: indeed :)
Nov 18 17:52:41 <mmp> koen: yes, but modifications in build/work could be re-unpacked this way. And I've done few modifications there as well... .
Nov 18 17:52:59 <mmp> not enough mature to send patches, but quite important to me for now.
Nov 18 17:52:59 <zecke> mmp: a) use BB Collections
Nov 18 17:53:06 <zecke> mmp: b) Commit into your database
Nov 18 17:54:00 <mmp> zecke: hmm, I can google for it; but commiting kernel into local database might not be the wisest idea:)
Nov 18 17:54:12 <mmp> err, kernel changes
Nov 18 18:03:09 <psokolovsky_> hrw, zecke: so, you really saw 10% speedup with patches?
Nov 18 18:04:06 <zecke> psokolovsky_: yes, numbers don't lie that says 93.40% of all research on that topic
Nov 18 18:05:09 <psokolovsky_> zecke, I just sent much less optimistic numbers ;-I
Nov 18 18:05:34 <mmp> zecke: uhh, I forgot - thanks:)
Nov 18 18:05:50 <psokolovsky_> zecke, don't you think that solution to bitbake chores is not opmizing *parser*, but optimizing *reparsing*?
Nov 18 18:06:20 <zecke> psokolovsky_: a) I'm bad at numbers b) parsing is not the problem at all
Nov 18 18:06:32 <zecke> psokolovsky_: I parse the whole tree in 3 seconds
Nov 18 18:06:45 <zecke> psokolovsky_: but getting something we can operate on is more difficult
Nov 18 18:07:02 <psokolovsky_> zecke, that's what I mean ;-I
Nov 18 18:07:02 <zecke> and reparsing is fast as well (if bb file changes)
Nov 18 18:07:31 <zecke> psokolovsky_: if one changes are core depenendency you lose
Nov 18 18:07:42 <psokolovsky_> zecke, I guess, you'll post a notice to ML when your new lemon parser will be erady to use w/o too much hacking? 
Nov 18 18:08:06 <psokolovsky_> zecke, why not be smart on handling these core dependencies?
Nov 18 18:08:27 <zecke> psokolovsky_: Show me an approach that works
Nov 18 18:08:40 <psokolovsky_> zecke, in cache, you store small subset of .bb vars. if one change "core dependency", but doesn't touch one of tehse vars, why reparse the whole tree?
Nov 18 18:08:42 <zecke> psokolovsky_: and the idea was to use db' but they don't scale :)
Nov 18 18:09:11 <zecke> psokolovsky_: because there is not defined subset as everything can influence everything
Nov 18 18:09:11 <psokolovsky_> zecke, I looked at db stuff, and see that indeed, they wouldn't bring anything useful ;-)
Nov 18 18:09:21 <RP> psokolovsky_: To do that we need variable dependency tracking which we don't have
Nov 18 18:09:34 <psokolovsky_> zecke, but what is stored in cache is well-defined!
Nov 18 18:09:46 <zecke> psokolovsky_: it is a heuristic
Nov 18 18:09:50 <zecke> psokolovsky_: but changing one thing in auto.conf
Nov 18 18:09:54 <zecke> psokolovsky_: can change everything!
Nov 18 18:10:01 <psokolovsky_> RP, zecke : yeah, I'm raising again that old idea of var dep tracking ;-)
Nov 18 18:10:18 <zecke> psokolovsky_: this will bring us back to a cache that plays bad with the kernel
Nov 18 18:10:20 <RP> psokolovsky_: Simple question. How do you parse what ABC = "${@bb.data.getVar('MACHINE', d, 0)}" depends on?
Nov 18 18:10:23 <koen> yay! http://article.gmane.org/gmane.comp.file-systems.fuse.devel/3862
Nov 18 18:10:36 <psokolovsky_> zecke, but we can *track* what exactly that will be. it can be *evything*, but can be nothing!
Nov 18 18:10:53 <zecke> psokolovsky_: it will be everything and you have a cache of +50 mb
Nov 18 18:11:03 <zecke> psokolovsky_: which will perform baldy
Nov 18 18:11:13 <zecke> psokolovsky_: you will end up with a simple cache that is bigger than the metadata itself
Nov 18 18:11:33 <psokolovsky_> RP: If I had clean picture how to handle all that thing, I'd implement it or at least wrote spec for your, guys, review ;-)
Nov 18 18:11:51 <koen> zecke: like the good'ol 400MB cache?
Nov 18 18:12:10 <psokolovsky_> zecke, maybe. If you already tried to implement that.
Nov 18 18:12:35 <RP> psokolovsky_: The point is that we know how we'd like it to work but its not that simple to implement :-(
Nov 18 18:12:58 <psokolovsky_> zecke, RP: it's just that I think that investing time into more sophisticated dep tracking is better idea, than into optimizing parser per se. just IMHO
Nov 18 18:13:10 <psokolovsky_> RP: yeah, I know...
Nov 18 18:13:14 <zecke> psokolovsky_: your user time seems too low
Nov 18 18:13:47 <psokolovsky_> too bad I'm stuck in kernel stuff, and then have OE/OPIE stuff in q, so way away from bitbake hacking again...
Nov 18 18:13:50 <RP> psokolovsky_: At the moment I'm actually testing a patch to track dependencies in the expand_cache. Its a nightmare :-(
Nov 18 18:14:13 <psokolovsky_> zecke, I run stuff on colinux, that may answer it ;-)
Nov 18 18:14:13 <zecke> RP: My ole idea was to do getVar('Foo') 
Nov 18 18:14:21 <zecke> RP: and then find out which vars were touched
Nov 18 18:14:34 <zecke> psokolovsky_: so your results are void :)
Nov 18 18:14:45 <RP> zecke: Like the cache does? :)
Nov 18 18:14:57 <zecke> psokolovsky_: there is one thing that kills the idea of dep tracking
Nov 18 18:14:58 <psokolovsky_> zecke, lol. but it takes real 5+ mins to parse it, still ;-P
Nov 18 18:15:04 <zecke> psokolovsky_: immediate assignments
Nov 18 18:15:21 <koen> zecke: and 8-bit aligned pixmaps?
Nov 18 18:15:25 <zecke> psokolovsky_: to cite Ulrich Drepper. For perforamnce measuring you need a sane environment, Co-Lomux does not qualify
Nov 18 18:15:27 <psokolovsky_> zecke, yep, I had suspicions about them already!
Nov 18 18:15:37 <psokolovsky_> ;-)
Nov 18 18:15:45 <psokolovsky_> I tried to help as I can ;-)
Nov 18 18:15:48 <zecke> psokolovsky_: I wish I could draw pictures like njs
Nov 18 18:16:03 <zecke> psokolovsky_: you have one variable like DEPENDS
Nov 18 18:16:16 <zecke> psokolovsky_: and it somehow has a dependency on ${BAR}
Nov 18 18:16:48 <zecke> psokolovsky_: and BAR was changed with an immediate assignment in auto.conf to 123+${MOO}
Nov 18 18:17:01 <zecke> psokolovsky_: now you would need to track not only the dependencies for DEPENDS
Nov 18 18:17:13 <hrw> cu
Nov 18 18:17:14 <zecke> psokolovsky_: but ALL possible dependenices and results for BAR as well
Nov 18 18:17:24 <zecke> psokolovsky_: or at least the original string + operation on BAR
Nov 18 18:18:17 <psokolovsky_> zecke, yep, possibly. immediate's break all constraint propogation, that's true. I even wondered is their use is unavoidable, but I guess, yes...
Nov 18 18:18:34 <psokolovsky_> Ok, I'm at least glad you guys keep that direction in mind...
Nov 18 18:18:39 <zecke> psokolovsky_: replace them with anonfuncs :(
Nov 18 18:18:46 <zecke> psokolovsky_: and this is even more tricky to handle ;)
Nov 18 18:19:02 <zecke> psokolovsky_: you will have to cache the code, and order of includes
Nov 18 18:19:05 <psokolovsky_> Again, too bad I can't do some head-banging on it myself ;-)
Nov 18 18:19:09 <zecke> psokolovsky_: and patch the code on changed dependencies :)
Nov 18 18:19:26 <zecke> psokolovsky_: e.g. changing inherit bla, foo to inherit foo, bla
Nov 18 18:19:35 <zecke> psokolovsky_: changes the order of execution of anonfunc
Nov 18 18:19:50 <zecke> psokolovsky_: which can... change DEPENDS in many many many different indirect ways
Nov 18 18:19:57 <zecke> psokolovsky_: bang your head, it will be fun :)
Nov 18 18:20:04 <psokolovsky_> well, that's indeed sounds like something complex to do for just "tracking"
Nov 18 18:20:17 <psokolovsky_> zecke, I have that in queue ;-)
Nov 18 18:20:29 <RP> Dependency tracking on expand variables = 8% slowdown
Nov 18 18:20:41 <zecke> psokolovsky_: I think we have two options
Nov 18 18:20:54 <zecke> psokolovsky_: a) hide that it is slow by sanity checking stuff first
Nov 18 18:21:06 <zecke> psokolovsky_: b) redesign meta data to something more easy to track
Nov 18 18:21:11 <zecke> psokolovsky_: c) have less data
Nov 18 18:21:26 <koen> hmm
Nov 18 18:21:37 <zecke> psokolovsky_: d) do less lookups
Nov 18 18:21:38 <psokolovsky_> zecke, just not (c), please!
Nov 18 18:21:52 <zecke> psokolovsky_: express the same thing we have now, with less data
Nov 18 18:22:02 <psokolovsky_> OE should scale to 10000+ pkgs ;-)
Nov 18 18:22:02 <zecke> psokolovsky_: e.g. like the anonfunc change
Nov 18 18:22:06 <psokolovsky_> ah, I see
Nov 18 18:22:40 <zecke> RP: might be wise to do dep tracking using my AST
Nov 18 18:23:05 <zecke> psokolovsky_: what this parser finally brings is having an AbstractSyntaxTree (AST) for OE
Nov 18 18:23:16 <zecke>  /BitBake
Nov 18 18:23:23 <psokolovsky_> yes, I read about it
Nov 18 18:23:31 <zecke> psokolovsky_: this means we can optimize a) the tree, b) do stuff one does on trees
Nov 18 18:23:32 <psokolovsky_> that's good
Nov 18 18:23:58 <koen> make a treehouse!
Nov 18 18:24:11 <zecke>  koen: get laid in a treehouse?
Nov 18 18:24:20 <suihkulokki>  
Nov 18 18:24:28 <zecke> psokolovsky_: ah I know how to track deps in an AST :)
Nov 18 18:24:52 <psokolovsky_> well, nice!
Nov 18 18:25:03 <psokolovsky_> I'll need to look closer at your code
Nov 18 18:25:04 <zecke> psokolovsky_: but still, it could be time consuming as well
Nov 18 18:25:13 <zecke> psokolovsky_: Mostly Marc Singers
Nov 18 18:26:26 <koen> integrate the parser into apex ;)
Nov 18 18:26:59 <zecke> Asian Professional EXchange?
Nov 18 18:27:26 <koen> http://wiki.buici.com/wiki/Apex_Bootloader
Nov 18 18:32:38 <zecke> http://rafb.net/paste/results/K3ujNy29.html
Nov 18 18:32:42 <zecke> does this make a difference?
Nov 18 18:34:44 <koen> ~lart sSupportsArray::AppendElement ()
Nov 18 18:34:44 * ibot beats sSupportsArray::AppendElement () severely about the head and shoulders with a rubber chicken
Nov 18 18:34:48 <koen> ehm
Nov 18 18:34:52 <koen> ~lart nsSupportsArray::AppendElement ()
Nov 18 18:34:52 * ibot farts in nsSupportsArray::AppendElement ()'s general direction
Nov 18 18:35:40 <zecke> yes?
Nov 18 18:36:39 <zecke> psokolovsky_: BTW: I don#t find 44 files per second slow
Nov 18 18:39:04 <psokolovsky_> zecke, neither me. it's actually a case of pretty many files there, and even more to come. that's why I think chnaging parsing procedure what should be done eventually anyway (vs just tweaking parser)
Nov 18 18:43:18 <zecke> psokolovsky_: this is what I do :)
Nov 18 18:54:24 <koen> hey likewise  & florian_ 
Nov 18 18:54:29 <likewise> hey all
Nov 18 18:55:28 <zecke> RP: using the heuristic doesn't buy us anything :(
Nov 18 18:58:19 <RP> zecke: I tried something similar and got the same result
Nov 18 19:00:00 <zecke> still 3.5 million lookups
Nov 18 19:00:36 <zecke> 867 per bb file :(
Nov 18 19:02:04 <RP> zecke: lookups or just expansions?
Nov 18 19:02:37 <RP> zecke: I wonder if we always have to expand?
Nov 18 19:03:01 <RP> can we add some bb.data.getVar(x, d, 0) ?
Nov 18 19:08:08 <zecke> we need to
Nov 18 19:08:22 <woglinde> hi andersee
Nov 18 19:39:32 * emte prods kergoth 
Nov 18 19:45:48 <zecke> 2831316    4.249   16.825  /space/hacking/embedded/bitbake/svn_all/trunk/bitbake/lib/bb/data.py:269(expandKeys)
Nov 18 19:47:14 <zecke> RP: you expandKeys will not help :(
Nov 18 19:51:51 <zecke> hrw|gone: psokolovsky_ : could you test something?
Nov 18 19:52:16 <zecke> http://rafb.net/paste/results/QIbXXA65.html
Nov 18 19:53:30 <zecke> specially if things work
Nov 18 19:53:38 <zecke> real    0m37.963s
Nov 18 19:53:38 <zecke> user    0m34.479s
Nov 18 19:53:38 <zecke> sys     0m3.304s
Nov 18 19:54:09 <zecke> RP: this explains why my cache didn't work
Nov 18 19:54:19 <psokolovsky_> zecke, that patch? 
Nov 18 19:54:25 <zecke> psokolovsky_: yes
Nov 18 19:54:30 <psokolovsky_> ok
Nov 18 19:54:42 <zecke> specially if it starts building, OSX building is currently broken again
Nov 18 19:57:05 <hrw> re
Nov 18 19:57:13 <hrw> zecke: give me few minutes and will
Nov 18 19:58:00 <sirfred> Hmm, dbus-glib is failing to compile. It looks for dbus headers into dbus/dbus-*.h but the staging directory has them into dbus-1.0/dbus-*.h
Nov 18 19:58:22 <woglinde> sirfred always discussed on the ml
Nov 18 19:58:45 <sirfred> woglinde: So, it's a known problem?
Nov 18 19:58:53 <woglinde> sirfred yes
Nov 18 19:58:59 <woglinde> look in the ml-archiv
Nov 18 19:59:14 <sirfred> woglinde: What do I need to do, symlink manually?
Nov 18 19:59:17 <sirfred> woglinde: Let's see
Nov 18 19:59:47 <hrw> looks like dbus.pc is broken then
Nov 18 19:59:48 <woglinde> sirfred sorry I forget the soultion
Nov 18 20:00:02 <woglinde> ~hail zecke
Nov 18 20:00:06 <zecke> lol
Nov 18 20:00:13 * ibot bows down to zecke and chants, "I'M NOT WORTHY!!"
Nov 18 20:00:44 <sirfred> dbus-1.pc says: Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include
Nov 18 20:01:04 <sirfred> That seems to be right, isn't it?
Nov 18 20:01:08 <zecke> yes
Nov 18 20:01:23 <zecke> in include/dbus-1.0/dbus/ should exist...
Nov 18 20:03:02 <sirfred> Hmm, I've found that thread of the maillist, let's see
Nov 18 20:04:55 <sirfred> It seems this guy had problems with familiar-unstable, but it worked for another distros
Nov 18 20:08:42 <hrw> real    2m37.735s
Nov 18 20:08:42 <hrw> user    2m28.631s
Nov 18 20:08:42 <hrw> sys     0m4.556s
Nov 18 20:08:45 <hrw> without patch
Nov 18 20:08:50 <hrw> real    2m27.786s
Nov 18 20:08:50 <hrw> user    2m18.776s
Nov 18 20:08:50 <hrw> sys     0m4.425s
Nov 18 20:08:56 <hrw> with patch
Nov 18 20:12:02 <zecke> and it starts building?
Nov 18 20:14:19 <hrw> I did -p
Nov 18 20:14:38 <hrw> restarted without -p
Nov 18 20:14:40 <zecke> so 10 seconds is good?
Nov 18 20:14:57 <hrw> any gain on initiall parse is good
Nov 18 20:17:18 <hrw> zecke: it does not build
Nov 18 20:17:21 <hrw> will paste
Nov 18 20:17:45 <hrw> http://pastebin.com/827577
Nov 18 20:18:45 <zecke> no idea
Nov 18 20:24:42 <sirfred> I tried adding some DBUS_CFLAGS to the dbus-glib_0.72.bb to help it to find the dbus headers, but now , it complains about some missing stuff. I wonder if openzaurus-unstable is still a supported distro
Nov 18 20:25:00 <woglinde> sirfred *sigh*
Nov 18 20:25:06 <woglinde> thats in the ml too
Nov 18 20:25:15 <woglinde> ups
Nov 18 20:25:17 <woglinde> my fault
Nov 18 20:25:23 <woglinde> rad familar
Nov 18 20:25:26 <woglinde> read
Nov 18 20:25:34 <hrw> sirfred: my umbaumba-17.3.conf is kind of oz-unstable-3.5.4.x.conf - I will probably update in meantime
Nov 18 20:25:55 <sirfred> woglinde: Yes, but I'm suffering the same problems that guy has with familiar-unstable
Nov 18 20:25:57 <zecke> hrw: remove the '{' from the patch
Nov 18 20:26:15 <hrw> restarted build
Nov 18 20:26:34 <sirfred> It seems that this dbus-glib-0.72 does not like the staging dbus.
Nov 18 20:28:54 <sirfred> The defines DBUS_ERROR_FILE_EXISTS and DBUS_ERROR_INVALID_FILE_CONTENT don't exist in the installed dbus-protocol.h, but needed by this dbus-glib
Nov 18 20:29:02 <hrw> zecke: same situation
Nov 18 20:29:17 <CIA-4> 03rpurdie * r693 10bitbake/lib/bb/parse/parse_py/ (BBHandler.py ConfHandler.py): ConfHandler, BBHandler: Optmise number of expand calls
Nov 18 20:29:50 <zecke> RP: hey!
Nov 18 20:30:54 <zecke> RP: better fix expandKey
Nov 18 20:31:37 <zecke> hrw: and without that patch it works?
Nov 18 20:31:51 <hrw> moment
Nov 18 20:32:03 <hrw> 5 minutes and I will tell you
Nov 18 20:32:05 <RP> zecke: I just saw your comment. Was this related to its increased use in bin/bitbake?
Nov 18 20:32:38 <zecke> RP: no. the 3 million from 3.5 million expands come directly from expandKeys
Nov 18 20:32:56 <RP> zecke: eek :-/
Nov 18 20:33:12 <zecke> RP: and if you look at the code/loop you can imagine that
Nov 18 20:34:31 <Marex> zecke, hi
Nov 18 20:34:34 <RP> zecke: yes. Any ideas how to do this better?
Nov 18 20:34:37 <Marex> can I use OE logo in my presentation?
Nov 18 20:34:38 <zecke> Marex: no idea which codecs
Nov 18 20:34:46 <Marex> hehe
Nov 18 20:34:51 <zecke> Marex: sure, we don't have trademark yet
Nov 18 20:34:52 <RP> add a .find("${") ?
Nov 18 20:34:59 <zecke> Marex: and we don't have a policy yet
Nov 18 20:35:03 <zecke> RP: scroll up :)
Nov 18 20:35:09 <zecke> RP: one patch was posted, and errors from hrw
Nov 18 20:35:10 <Marex> zecke, can I use familiar logo too?
Nov 18 20:35:13 <Marex> is there any? ;)
Nov 18 20:35:24 <zecke> Marex: this would have to go to #handhelds.org
Nov 18 20:35:30 <Marex> ok
Nov 18 20:35:37 <hrw> or #familiar
Nov 18 20:35:41 <Marex> btw where can I get OE logo in decent size?
Nov 18 20:35:53 <hrw> in contrib/oe.svg?
Nov 18 20:36:00 <zecke> Marex: it is svg, so you can resize
Nov 18 20:36:17 <Marex> it's in svn or whatever you use, right?
Nov 18 20:36:23 <zecke> it is
Nov 18 20:36:32 <zecke> Marex: contrib/ is a dir in mtn
Nov 18 20:36:43 <zecke> http://www.openembedded.org/filebrowser/org.openembedded.dev/contrib
Nov 18 20:36:52 <RP> zecke: that shouldn't error? :-/
Nov 18 20:37:06 <Marex> thanx
Nov 18 20:37:09 <Marex> got it
Nov 18 20:37:33 <zecke> RP: right, this is why I asked why it errors
Nov 18 20:37:44 <hrw> zecke: bitbake with rp changes, removed your patch, no build
Nov 18 20:38:30 <zecke> hrw: so it is always broken
Nov 18 20:39:44 <hrw> looks like
Nov 18 20:40:03 <zecke> RP: new parser is at 33 seconds now
Nov 18 20:40:14 <zecke> RP: EXPORT_FUNCTION is missing and SRC_URI handling
Nov 18 20:40:35 <hrw> zecke: find a moment to stop or you will get into complex time
Nov 18 20:40:50 <hrw> and it will parse in 0+i20 seconds
Nov 18 20:41:18 <zecke> complex time is just a rotation on the time axes
Nov 18 20:43:08 <hrw> koen|away: thx for info about #openmoko
Nov 18 20:44:38 <psokolovsky_> zecke, with that patch:
Nov 18 20:44:38 <psokolovsky_> real    5m28.500s
Nov 18 20:44:38 <psokolovsky_> user    0m32.200s
Nov 18 20:44:38 <psokolovsky_> sys     4m34.640s
Nov 18 20:45:10 <zecke> psokolovsky_: your statistics are fucked up
Nov 18 20:45:21 <zecke> psokolovsky_: I think user and sys are the other way around ;)
Nov 18 20:45:23 <psokolovsky_> sorry ;-))
Nov 18 20:45:35 <zecke> one would have to look at colinux
Nov 18 20:45:43 <zecke> psokolovsky_: so is this 4:34 smaller than before?
Nov 18 20:45:46 <psokolovsky_> zecke, I though you'd be looking for real, anyway ;-)
Nov 18 20:46:13 <zecke> psokolovsky_: I just want to know if numbers go down, and how much :)
Nov 18 20:46:15 <psokolovsky_> zecke, hey, yes, it is!
Nov 18 20:46:27 <psokolovsky_> ~20-30 secs down!
Nov 18 20:46:40 <zecke> psokolovsky_: now the question, does it start building?
Nov 18 20:47:10 <zecke> psokolovsky_: and if it doesn't take 5 minutes anymore, will you quit smoking (I don't assume you smoke)
Nov 18 20:47:13 <psokolovsky_> good one ;-) I did -p, let me run normal
Nov 18 20:47:51 <psokolovsky_> zecke, sorry, I'm looking for 1-2mins before making any commitments ;-)
Nov 18 20:50:00 <psokolovsky_> zecke, it seems to build rootfs now
Nov 18 20:52:59 <zecke> psokolovsky_: using the patch from above? "${"
Nov 18 20:53:03 <psokolovsky_> zecke, build opie-image, size seems sane
Nov 18 20:53:10 <psokolovsky_> zecke, yes, w/that patch
Nov 18 20:53:26 <psokolovsky_> doing  opie-console -c rebuild
Nov 18 20:53:40 <zecke> psokolovsky_: you could do a rebuild and we have ipkg-diff :)
Nov 18 20:54:13 <Spyro> lrg: hello?
Nov 18 20:54:33 <lrg> Spyro: hey
Nov 18 20:54:49 <Spyro> lrg: is a codec_dev really _required_ in the asoc layer?
Nov 18 20:54:56 <Spyro> lrg: if not I found a bug
Nov 18 20:55:03 <CIA-4> 03zecke123 * r694 10bitbake/lib/bb/data.py: Hack to avoid 3 million key expansions by a simple string match
Nov 18 20:55:14 <Spyro> lrg: even if not its still an oopsable condition...
Nov 18 20:55:36 <Spyro> codec_dev->probe is called without checkign for codec_dev being non-null
Nov 18 20:55:59 <lrg> Spyro: can you send a patch
Nov 18 20:56:06 <Spyro> sure, Im just testing now
Nov 18 20:56:14 <lrg> cool
Nov 18 20:56:32 <Spyro> lrg: kexec is SO cool. unless I still it completely I never have to see wince again :)
Nov 18 20:56:39 <Spyro> still = stiff
Nov 18 20:56:52 <Spyro> its booting...
Nov 18 20:57:03 <hrw> Spyro: e740 still has to be booted from wince otherwise?
Nov 18 20:57:13 <lrg> heh
Nov 18 20:57:18 <Spyro> hrw: yeah but it can suspend/resume despite that
Nov 18 20:57:33 <hrw> Spyro: so kexec roxx for this device
Nov 18 20:57:34 <Spyro> hrw: it CAN be booted using ym flash loader but Im not making that pulic
Nov 18 20:57:39 <Spyro> public
Nov 18 20:57:47 <hrw> Spyro: tried uboot?
Nov 18 20:58:02 <Spyro> hrw: no, is there becomming a standard loader for pdas?
Nov 18 20:58:19 <Spyro> I shied away from the familiar bootloader last year.
Nov 18 20:58:23 <Spyro> bootldr
Nov 18 20:58:24 <hrw> pdas like pdas but looks like standard for devboards
Nov 18 20:58:27 <Spyro> nasty bit of code
Nov 18 20:58:45 <Speedy2> There are like 10 different bootloaders...who would have expected?
Nov 18 20:58:49 <Spyro> uboot is certainly popular, I'll give it that
Nov 18 20:59:04 <hrw> some zauruses can also be moved to uboot but it means also problems for users so I avoid moving into it
Nov 18 20:59:16 <Spyro> lrg: my driver probed ok
Nov 18 20:59:28 <lrg> Spyro: cool
Nov 18 20:59:47 <zecke> hrw: how is sash doing?
Nov 18 21:00:00 <hrw> zecke: looks like my system here is somekind fucked. on other machine build is progressing with recent bitbake
Nov 18 21:00:12 <Spyro> lrg: hmm. the wm97xx-ts driver module is 'missing'... wtf?
Nov 18 21:00:15 <hrw> zecke: no idea, looks like pdax is starving totally
Nov 18 21:00:41 <lrg> Spyro: ts isn't included in asoc patch
Nov 18 21:00:42 <psokolovsky_> zecke, so opie-console kinda builds too
Nov 18 21:00:49 <hrw> btw, did I said already that source mirror in same lan as build machine roxx?
Nov 18 21:00:51 <hrw> ;D
Nov 18 21:01:04 <zecke> hrw: gigabit net?
Nov 18 21:01:13 <hrw> zecke: localhost
Nov 18 21:01:24 <zecke> which mtu size? ;)
Nov 18 21:01:33 * Spyro runs all his boxes on nfsroot on gigabit :)
Nov 18 21:01:59 <zecke> stefan_schmidt: what is the state of the debian package?
Nov 18 21:02:04 <hrw> zecke: I have access to two machines in lan but second one is production so I prefer to not touch it (got other machine for exclusive usage)
Nov 18 21:02:25 <hrw> Spyro: eseries too?
Nov 18 21:03:19 <stefan_schmidt> zecke: Needs man page and package description.
Nov 18 21:03:21 <Spyro> hrw: heh
Nov 18 21:03:35 <Spyro> hrw: not yet... although NFS over wifi could be a laugh...
Nov 18 21:03:57 <Spyro> flash root? where we're going we dont need no steenking flash root...
Nov 18 21:04:39 <stefan_schmidt> zecke: Etch release is comming soon. So all devs are care about rc bugs atm.
Nov 18 21:04:45 <Spyro> hmm. ok so I have wm97xx_ts loaded and evdev but neither do anything
Nov 18 21:05:10 <Spyro> lrg: do I need anything beyond snd_soc_pxa2xx, snd_soc_e740 and wm97xx-ts ?
Nov 18 21:05:16 <stefan_schmidt> zecke: Shoragan also uses hrw's oe-essential package now, which depends on bitbake yet.
Nov 18 21:05:17 <lrg> Spyro: what ts version ? latest is here http://opensource.wolfsonmicro.com/~lg/wm97xx/
Nov 18 21:05:18 <hrw> ah... now I understand why stefan_schmidt was talking so much about debian packages ;)
Nov 18 21:05:30 <Spyro> lrg: it was current last night...
Nov 18 21:05:57 <lrg> Spyro: ok, what about ts probe messages
Nov 18 21:06:02 <Spyro> nothing
Nov 18 21:06:10 <Spyro> wm97xx: version 0.64 liam.girdwood@wolfsonmicro.com
Nov 18 21:06:13 <Spyro> thats all
Nov 18 21:06:22 <Spyro> do I need snd-soc-ac97 ?
Nov 18 21:06:33 <hrw> stefan_schmidt: I will work on openembedded-essential and bitbake packages tomorrow (rpms) - will commit updated version of o-e also for debian
Nov 18 21:06:44 <lrg> Spyro: you need snd soc-pxa2xx-ac97
Nov 18 21:07:06 <Spyro> lrg: isnt that built into snd-soc-pxa2xx ?
Nov 18 21:07:45 <stefan_schmidt> hrw: nice
Nov 18 21:07:45 <Shoragan> hrw, stefan_schmidt: i've also build a openembedded-essential package based on hrw's
Nov 18 21:07:45 <Shoragan> which depends on bitbake
Nov 18 21:08:12 <stefan_schmidt> Shoragan, hrw: Which one of you will push o-e in debian?
Nov 18 21:08:42 <Spyro> lrg: thats odd . my Kconfig entry for e740 does select the pxa2xx-ac97 module...
Nov 18 21:08:58 <Shoragan> i'll do it after etch is released, it isn't much use to put it in the new queue now
Nov 18 21:09:16 <zecke> should one file an RC bug for missing bitbake?
Nov 18 21:09:48 <lrg> Spyro: ah, it should select SND_PXA2XX_SOC_AC97
Nov 18 21:10:10 <Spyro> yes it does
Nov 18 21:10:12 <Shoragan> but debian probably won't include a pure metapackage like oe-essential, it should perhaps include a script that sets up a build environment
Nov 18 21:10:12 <stefan_schmidt> zecke: RC for wnpp is unlikely. ;)
Nov 18 21:10:36 <Shoragan> it's too late now for etch
Nov 18 21:10:36 <Spyro> lrg: oh Im blind - there it is
Nov 18 21:10:47 <hrw> stefan_schmidt: I'm not DD
Nov 18 21:10:56 <Spyro> lrg ok loaded that
Nov 18 21:11:00 <Spyro> still no messages
Nov 18 21:11:37 <lrg> Spyro: did you see my pm
Nov 18 21:11:40 <hrw> stefan_schmidt: I planed to be DD but found OpenEmbedded
Nov 18 21:11:46 <Spyro> lrg: thats weird, despite my loading it it hasnt appeared in the module list...
Nov 18 21:11:51 <Shoragan> my bitback package could probably reach unstable in january (if etch is released in december)
Nov 18 21:11:51 <hrw> so I became OECD
Nov 18 21:11:56 <Spyro> lrg: no, hold on
Nov 18 21:12:20 <stefan_schmidt> hrw: Why get distro dev if you can have your own distro? ;)
Nov 18 21:12:45 <stefan_schmidt> Shoragan: Pushing bitbake in january is fine.
Nov 18 21:13:23 <stefan_schmidt> hrw: What's about a build env setup script in o-e? Good or bad idea?
Nov 18 21:14:58 <zecke> stefan_schmidt: bad :)
Nov 18 21:14:59 <Spyro> lrg: pm back :)
Nov 18 21:16:47 <Shoragan> zecke: why? :)
Nov 18 21:17:10 <zecke> Shoragan: Building and Maintaining a distro is not easy
Nov 18 21:17:36 <zecke> Shoragan: so avoiding  cookbook stuff helps us not wasting our time on script kiddies :)
Nov 18 21:17:45 <Shoragan> hehe
Nov 18 21:18:08 <Shoragan> then i debian bitbake package probably is a bad idea, too
Nov 18 21:18:26 <zecke> psokolovsky_: you could try freeze and see if it is faster
Nov 18 21:18:48 <zecke> Shoragan: well you still need to set BBPATH so it is a good kind of convience
Nov 18 21:18:55 <zecke> Shoragan: and I do not know where to draw the line
Nov 18 21:18:57 <hrw> Shoragan: I was thinking about such one
Nov 18 21:19:24 <hrw> Shoragan: but rather as 'use this script to fetch everything needed'
Nov 18 21:19:42 <CIA-4> 03pfalcon 07org.oe.dev * rf3886f54... 10/ (14 files in 8 dirs): 
Nov 18 21:19:42 <CIA-4> linux-handhelds-2.6: Add linux-handhelds-2.6-2.6.17 override dir.
Nov 18 21:19:42 <CIA-4> * Prepare to upgrade to 2.6.18.
Nov 18 21:19:42 <CIA-4> * Copied from linux-handhelds-2.6/.
Nov 18 21:20:01 <Shoragan> you better decide that amogst yourselves first ;)
Nov 18 21:20:47 <zecke> I will be a bofh anyway :)
Nov 18 21:21:27 <stefan_schmidt> The bitbake package should be fine anyway. The question is if a o-e package is needed besides bitbake or not.
Nov 18 21:24:26 <hrw> cu
Nov 18 21:25:21 <CIA-4> 03pfalcon 07org.oe.dev * r1a49ef5c... 10/ (3 files in 2 dirs): 
Nov 18 21:25:21 <CIA-4> linux-handhelds-2.6 2.6.17: Use own pre-version override dir, free "main"
Nov 18 21:25:21 <CIA-4> override dir for 2.6.18.
Nov 18 21:28:36 <zecke> psokolovsky_: use 'freeze' and make to compile bitbake into an executable
Nov 18 21:28:46 <zecke> psokolovsky_: it could change the speed (to the better/worse)
Nov 18 21:29:41 <psokolovsky_> zecke, python's freeze? well, I doubt that would change anything more than 10%, and that's too little
Nov 18 21:30:17 <RP> zecke: Did the order we execute anonymous methods in change?
Nov 18 21:31:56 <zecke> RP: eek, maybe
Nov 18 21:32:06 <zecke> RP: go to base.bbclass and change them
Nov 18 21:32:40 <RP> zecke: poky broke but it could be I've not updated it locally properly...
Nov 18 21:33:25 <zecke> RP: i hope I kept the order
Nov 18 21:33:36 <zecke> RP: revert lib/bb/fetch.py, change base.bbclass
Nov 18 21:33:47 <zecke> and say sorry to mallum that I might broke poky
Nov 18 21:36:36 <RP> zecke: mallum would just tell me to fix it ;-)
Nov 18 21:37:06 <zecke> RP: the invocation in base.bbclass might have changed
Nov 18 21:38:06 <RP> zecke: Its something to do with multimachine.bbclass
Nov 18 21:38:36 <zecke> RP: or revert lib/bb/parse_py/BBHandler.py
Nov 18 21:38:56 <zecke> RP: what kind of error do you get?
Nov 18 21:50:59 <zecke> I'm moving to bed now
Nov 18 22:07:55 <lrg>  night all
Nov 18 22:07:55 * lrg -> sleep
Nov 18 22:07:55 <RP> 'night lrg 
Nov 18 22:09:05 <RP> zecke: things like http://pastebin.ca/251993
Nov 18 22:13:05 * Spyro is updating hh.org CVS to 2.6.19 :)
Nov 18 22:13:18 <Spyro> (in my local git repo that is)
Nov 18 22:16:35 <zecke> RP: hmm
Nov 18 22:16:41 <zecke> RP: have fun finding out
Nov 18 22:17:42 <hrw|tv> 'The IT Crowd' is nice
Nov 18 22:25:40 <RP> The issue is that anonymous functions can "return" :-/
Nov 18 22:30:26 <Genesis> what's the best accesspoint to work with OE ?
Nov 18 22:44:06 <hrw|tv> Genesis: which way or 'work with OE'?
Nov 18 22:44:34 <hrw|tv> s/or/of
Nov 18 22:44:44 <Genesis> a AP i could have fun with OE , to dev on OE for my free time
Nov 18 22:44:57 <hrw|tv> hm.
Nov 18 22:45:07 <hrw|tv> meshcube can be hard to get
Nov 18 22:45:19 <Genesis> yep the cube seems cool
Nov 18 22:45:26 <Genesis> i look 
Nov 18 22:45:39 <hrw|tv> wrt54 family is limited: size of ram/flash and OE support
Nov 18 22:45:44 <Genesis> hard to ship perharps , im not far from deutschland
Nov 18 22:46:44 <hrw|tv> if you want good WAP/router I would suggest reading openwrt or dd-wrt wiki to get infos about which machine is best/suggested
Nov 18 22:47:28 <Genesis> oki  , i know a bit on this product , but they are old
Nov 18 22:47:42 <Genesis> ( new release sometime , but the base is old i think )
Nov 18 22:47:59 <hrw|tv> I have wrt54gs running openwrt here
Nov 18 22:48:20 <hrw|tv> got it few years ago as donation 
Nov 18 22:49:33 <Spyro> :)
Nov 18 22:49:36 * CoreDump|afk curses
Nov 18 22:49:41 <CoreDump|afk> /dev/md2              373G  373G   64K 100% /media/md2
Nov 18 22:49:48 <Spyro> I'd curse too if I was a coredump :)
Nov 18 22:49:52 <emte> last i heard the new gens wrt54gs cant be programmed
Nov 18 22:50:19 <Genesis> :/
Nov 18 22:50:32 <Genesis> meshcube : 32MB flash , seem good for OE :)
Nov 18 22:50:34 <hrw|tv> emte: wrt54g v5
Nov 18 22:50:45 <hrw|tv> Genesis: if you find them
Nov 18 22:51:05 <emte> all the wrt54g are programmable tho
Nov 18 22:51:18 <emte> its just the newer gs series
Nov 18 22:51:23 <hrw|tv> emte: v5 was vxworks rather
Nov 18 22:51:51 <emte> ah
Nov 18 22:51:53 <Genesis> i worked with vxworks during my study 
Nov 18 22:52:09 <emte> vxworks has access to some propritary stuff do they not?
Nov 18 22:53:08 * emte curses at autotools
Nov 18 22:54:02 <hrw|tv> emte: nope, you was right. wrt54gs v5.0/v5.1/v6.0 are work-in-progress
Nov 18 22:54:28 <hrw|tv> but also wrt54g v5/6/7
Nov 18 23:16:30 <hrw|tv> cu
Nov 19 00:27:37 <Genesis> no way , meshcube is hard to buy
Nov 19 00:31:49 <likewise> koen: hi.
Nov 19 00:36:19 <koen> hey likewise 
Nov 19 00:36:24 * koen returns from pub
Nov 19 00:36:38 <Genesis> yo likewise 
Nov 19 00:36:51 <likewise> koen: then I won't ask questions anymore. Not that I can think of any.
Nov 19 00:38:25 <koen> :)
Nov 19 00:56:21 <likewise> good nite everyone, I am hitting the sack
Nov 19 01:06:38 <CIA-4> 03lenehan 07org.oe.dev * rddff3b08... 10/ (7 files in 4 dirs): 
Nov 19 01:06:38 <CIA-4> cherokee 0.5.5: Add version 0.5.5 which fixes a large number of bugs
Nov 19 01:06:38 <CIA-4> and improves performance a lot. My requirement was for authentication
Nov 19 01:06:38 <CIA-4> on the root of the site which was unsupported in earlier releases.
Nov 19 01:06:38 <CIA-4> This version patches the configure input files, unlike the previous
Nov 19 01:06:39 <CIA-4> version which patched the output files. Tested on i486 and sh4.
Nov 19 01:47:09 <CIA-4> 03lenehan 07org.oe.dev * re853ab6b... 10/ (5 files in 2 dirs): 
Nov 19 01:47:09 <CIA-4> cherokee: Factor out common parts to cherokee.inc and fix up the packaging
Nov 19 01:47:09 <CIA-4> for cherokee-nossl which is even more broken then before after this change.
Nov 19 01:49:09 <psokolovsky_> Stoopid ipkg-itils bugs away, common buttonmap for HH.org kernel devices working! Woo-hoo!
Nov 19 01:50:50 <v8jlene> psokolovsky_: None of my devices have keyboards or screens... so I'm probably not all that excited about a common buttonmap ;)
Nov 19 01:52:57 <psokolovsky_> v8jlene, yep, I understand ;-) pretty local win, but for us, poor pocketpc guys, should be a big relief to get away from such stipud problems as buttons not working from a device to device ;-)
Nov 19 01:53:51 <v8jlene> Yep, I understand... there's been plenty of complaints in that area.
Nov 19 02:08:21 <CIA-4> 03pfalcon 07org.oe.dev * r7dc2fd45... 10/ (4 files in 3 dirs): (log message trimmed)
Nov 19 02:08:21 <CIA-4> qpe 2.3.10: Apply common keyboardless buttonmap for HH.org kernel ports.
Nov 19 02:08:21 <CIA-4> * keyboardless-buttonmap.patch does that
Nov 19 02:08:21 <CIA-4> * ipaq-keyboard.patch is patch for 2.4 kernels, should go away.
Nov 19 02:08:21 <CIA-4> * ipaq_sound_fix.patch status is unknown. It seems to conatin useful
Nov 19 02:08:21 <CIA-4> validation patch, but at the same time talks about hardcoding something
Nov 19 02:08:21 <CIA-4> for uda1341 (which also smells of 2.4). Either way, if it contains something
Nov 19 02:17:15 <CIA-4> 03pfalcon 07org.oe.dev * ree0a10ae... 10/ (1 packages/qte/qte-common_2.3.10.inc): 
Nov 19 02:17:15 <CIA-4> qte 2.3.10: Workaround symbol export issue with GCC 4.1
Nov 19 02:17:15 <CIA-4> * "Workaround GCC 4.1 issues with -fvisibility-inlines-hidden (see #1521)
Nov 19 02:17:15 <CIA-4> by disabling it for qpe only. TODO: pinpoint actual issue causing GCC
Nov 19 02:17:15 <CIA-4> misbehavior."
Nov 19 02:17:16 <CIA-4> * Eases #1521 a bit.
Nov 19 02:29:52 <CIA-4> 03lenehan 07org.oe.dev * r1cdcad82... 10/ (4 files in 2 dirs): 
Nov 19 02:29:52 <CIA-4> cherokee: Move the .la files and the .so files associated with shared
Nov 19 02:29:52 <CIA-4> libraries (not those that are plugins) into from the main package into the
Nov 19 02:29:52 <CIA-4> -dev package since they are not required to run cherokee.
Nov 19 02:38:44 <CIA-4> 03lenehan 07org.oe.dev * r1e4e8801... 10/ (4 files in 3 dirs): 
Nov 19 02:38:44 <CIA-4> cherokee: In the init script pass the config file as a parameter. This
Nov 19 02:38:44 <CIA-4> currently matches the default so makes no actual difference. However in the
Nov 19 02:38:44 <CIA-4> case where you want to run multiple instances of cherokee it makes it clear
Nov 19 02:38:44 <CIA-4> how you specify an alternate configuration file.
**** ENDING LOGGING AT Sun Nov 19 02:59:56 2006