**** BEGIN LOGGING AT Fri Sep 30 02:59:57 2005
Sep 30 03:24:46 <jpalten> rwhitby: turnup is for openslug, not for unslung, right?
Sep 30 03:30:04 <rwhitby> right.  sorry - I forgot you were running unslung
Sep 30 03:33:18 <jpalten> this time yes ;)
Sep 30 03:33:59 <jpalten> I switch back and forth too much between firmwares, I ordered my second slug to keep myself stable for a while: unslung on one, openslug on the other...
Sep 30 05:01:00 <rwhitby-away> conradl: g'day
Sep 30 05:03:23 <conradl> helo
Sep 30 05:03:36 <conradl> new job ..V busy.. damm it
Sep 30 05:03:44 <rwhitby-away> access to hardware?
Sep 30 05:04:05 <conradl> oh yes got my new Laptop tonight
Sep 30 05:04:13 <rwhitby-away> sweet :-)
Sep 30 05:06:50 <rwhitby-away> conradl: Are you still able to get me a ds101 ?   I definitely will get one now - we haven't found anything else which is fanless and is better.  dyoung might also want one (I'm asking him now, but no response yet) ...
Sep 30 05:08:43 <conradl> its no problem.
Sep 30 05:09:47 <conradl> i am looking at the normal price that dealers buy for. They did/are looking after me.
Sep 30 05:11:40 <rwhitby> is that still the AUD$275+GST price?
Sep 30 05:12:03 <conradl> 285+ from 101 290 + 101g+
Sep 30 05:12:10 <conradl> for 
Sep 30 05:14:02 <rwhitby> conradl: any idea what it would cost to ship one to hawaii?
Sep 30 05:14:08 <rwhitby> dwery: ping
Sep 30 05:14:25 <dwery> rwhitby: pong
Sep 30 05:14:41 <conradl> maybe $25-30 as parts;) 
Sep 30 05:15:10 <rwhitby> dwery: do you know if the button/led/buzzer driver architecture for nslu2 is modelled after any other arch/board driver architecture?
Sep 30 05:15:53 <rwhitby> (i.e. is there some "reference" way of doing this stuff, which we should be using, so that higher-level stuff doesn't need to be taught a new driver interface?)
Sep 30 05:15:59 <dwery> rwhitby: my current driver for buzzer is modelled after the similar buzzer/speaker implementation of toher arhcs (pc, mac, etc)
Sep 30 05:16:23 <dwery> button and led.. i have to check
Sep 30 05:17:13 <rwhitby> conradl: wanna log into MSN and we'll discuss the purchase?
Sep 30 05:17:21 <rwhitby> (dyoung is gonna buy one two)
Sep 30 05:18:27 <dwery> rwhitby: what you're gonna buy? :)
Sep 30 05:18:39 <rwhitby> Synology DS101
Sep 30 05:19:39 <rwhitby> It's a slug with 64MB of ram and an internal IDE interface for a PATA disk.
Sep 30 05:19:49 <dwery> nice one
Sep 30 05:19:53 <dwery> how much?
Sep 30 05:20:20 <rwhitby> Here it's about AUD$300.
Sep 30 05:20:50 <rwhitby> or about USD$225
Sep 30 05:21:04 <rwhitby> it's probably cheaper in the US, but also harder to find.
Sep 30 05:21:16 <dwery> I think i'll buy it another day :)
Sep 30 05:22:15 <joschi> hi there
Sep 30 05:22:23 <rwhitby> Hi joschi
Sep 30 05:22:26 <joschi> i just followed your discussion about ds101
Sep 30 05:22:29 <dwery> rwhitby: it seems there is an arm-wide interface for leds
Sep 30 05:22:34 <joschi> what about this one? :) http://www.synology.com/enu/products/diskstation/DS-101g_plus/index.php?page=overview.html
Sep 30 05:22:50 <joschi> is this linux too?
Sep 30 05:22:52 <rwhitby> joschi: it's got a noisy fan
Sep 30 05:22:57 <joschi> hm
Sep 30 05:23:00 <joschi> :(
Sep 30 05:23:18 <rwhitby> there's been a lot of discussion about that in #ds101-linux
Sep 30 05:23:38 <dwery> rwhitby: please do  a grep for leds_event in arch/arm
Sep 30 05:26:29 <joschi> funny, the ds101j is newer, but has less ram?!?
Sep 30 05:26:49 <rwhitby> yes, less flash and less ram
Sep 30 05:26:57 <rwhitby> dwery: very interesting
Sep 30 05:27:18 <dwery> rwhitby: no documentation.. but seem widespread
Sep 30 05:28:17 <dwery> rwhitby: i haven't find anything standard about io. 
Sep 30 05:31:40 <dwery> rwhitby: it seems led are used for cpu and/or timer
Sep 30 05:34:09 <dwery> rwhitby: and it seems there's an interface in /sys
Sep 30 05:35:36 <dwery> rwhitby: /sys/class/nslu2/leds/dev
Sep 30 05:38:24 <dyoung> 126:0 is the device major/minor for the nslu2 led device.
Sep 30 05:39:24 <dwery> mm...
Sep 30 05:39:26 <dwery> right
Sep 30 05:39:36 <dwery> in kernel/timer.c
Sep 30 05:39:41 <dwery> a /sys device is registered
Sep 30 05:39:42 <dwery> for leds
Sep 30 05:42:09 <dwery> it should be called "event"
Sep 30 05:42:16 <dwery> but I can't find it
Sep 30 05:42:48 <dwery> oh well. CONFIG_LEDS missing from my .config
Sep 30 05:42:54 <dwery> i'm goin to enable it and see
Sep 30 05:47:37 <dwery> uhoh.. Kconfig missing
Sep 30 05:47:42 <dwery> i'll have to write it
Sep 30 05:47:46 <dwery> strange anyway
Sep 30 05:50:28 <rwhitby> arch/arm/Kconfig has LEDS in it
Sep 30 05:50:43 <dwery> thanks
Sep 30 05:50:45 <dwery> i've missed it
Sep 30 05:59:35 <dwery> If we wanto to go for that interface, I can write the driver
Sep 30 05:59:40 <dwery> just let me know
Sep 30 06:02:11 <joschi> today someone here who can give some hints about bitbake? I'm trying to build cups...
Sep 30 06:03:31 <dwery> i think we can used the ready/status led for cpu/timer and leave disk1/disk2 free
Sep 30 06:06:44 <VoodooZ_Log> yeah, hopefully it's not too hard to disable it as I use the LEDs for signalling on my robot and don't care much any disk activity light.
Sep 30 06:07:13 <dwery> VoodooZ_Log: which leds do you use?
Sep 30 06:08:47 <VoodooZ_Log> well, considering I already burned both the I2C SCL pin and the DISK2 one (as a replacement for the former) I use both status and disk1
Sep 30 06:08:57 <VoodooZ_Log> brb
Sep 30 06:09:24 <dwery> how did you manage to burn them????
Sep 30 06:09:25 <dwery> :D
Sep 30 06:11:54 <dyoung> VoodooZ_Log is hard core. :-)
Sep 30 06:38:35 <VoodooZ_Log> sorry, my boss wanted to see me. 
Sep 30 06:39:30 <VoodooZ_Log> well, I was driving 5V devices on the I2C bus (which is ok in itself as it's an open-collector bus and 5V devices can read a 3.3V HIGH correctly)
Sep 30 06:40:09 <dwery> uh.. the 5V device drived the ixp? :)
Sep 30 06:40:13 <VoodooZ_Log> but I must have shorted them to 5V by accident the first time. I'm not sure what happened the second time around as everything is wired securely.
Sep 30 06:40:47 <VoodooZ_Log> no, the IXP i2c master pulls up the i2c bus at 3.3V but the slave devices are 5V.
Sep 30 06:41:32 <VoodooZ_Log> It worked since the beginning so it's possible my code inadvertently set the SCL/SDA pin high while flashing or something. not sure.
Sep 30 06:41:41 <VoodooZ_Log> oh well, I use USB now so no more problems.
Sep 30 06:41:58 <VoodooZ_Log> That means I can no longer read the RTC but not a big deal for a robot.
Sep 30 06:42:41 <VoodooZ_Log> bbl
Sep 30 07:47:22 <dwery> leds are working, very nice visual effect
Sep 30 07:49:00 <VoodooZ_Work> you mean the old interface?
Sep 30 07:49:10 <dwery> no, the new one.. 
Sep 30 07:49:19 <VoodooZ_Work> what's different about it?
Sep 30 07:49:34 <dwery> CONFIG_LEDS. the ready/status led signals timer and cpu idleness
Sep 30 07:50:13 <VoodooZ_Work> Is this temporary?
Sep 30 07:50:29 <dwery> well, not. but it's configurable
Sep 30 07:50:34 <VoodooZ_Work> ah. I see.
Sep 30 07:50:57 <VoodooZ_Work> It would be nice as an optional package that one can simply install/or not.
Sep 30 07:51:25 <dwery> if we follow other archs, is a compile time option
Sep 30 07:51:38 <VoodooZ_Work> that's cool too.
Sep 30 08:05:25 <yvasilev> I just see someone posted on the mailing list that he has working built in NIC on the slug in le mode, have someone (dwery?) got the patches that person used and/or reproduced this results?
Sep 30 08:05:52 <dwery> yvasilev: no.. i just saw the email
Sep 30 08:33:29 <dwery> red led is on when system is NOT idle, led green flashes every 50 timer ticks. is that ok?
Sep 30 08:34:15 <NAiL> hard to say without seeing it ;)
Sep 30 08:34:40 <dwery> use a lot of imagination :D
Sep 30 08:41:27 <dwery> to disable at runtime, just use:  echo "claim" >/sys/devices/system/leds/leds0/event
Sep 30 08:41:49 <NAiL> ok, good
Sep 30 08:42:31 <dwery> the opposite of claim is "release"
Sep 30 08:46:17 <CIA-8> 03mickeyl 07org.openembedded.dev * rf0fa6efb... 10/classes/ (qt3x11.bbclass qt4x11.bbclass): class qt3x11, qt4x11: remove DEPENDS
Sep 30 08:46:20 <CIA-8> 03mickeyl 07org.openembedded.dev * r5ef8750d... 10/packages/python/ (python_2.4.1.bb python_2.4.2.bb): python: upgrade to 2.4.2
Sep 30 08:46:35 <dwery> {red,green,amber} {on,off}
Sep 30 08:47:01 <dwery> now i don't know how to integrate the slug specific leds in this subsytem
Sep 30 08:51:16 <jbowler-zzz> dwery: so long as whatever you do supports the current IOCTLs leds will work, if you change the ioctls you need to change leds.
Sep 30 08:51:52 <dwery> other arch/mach support leds in a different way than ioctls.
Sep 30 08:51:56 <dwery> i would like to
Sep 30 08:52:03 <dwery> adhere to their standard
Sep 30 08:52:45 <jbowler-zzz> Sure, change leds then - it just needs to set the LEDs appropriate during boot and shutdown (from the /etc/init.d scripts).
Sep 30 08:53:15 <dwery> I'll left this task for someone else, I don't use leds :)
Sep 30 08:53:31 <jbowler-zzz> Then you must continue to support the existing ioctls
Sep 30 08:53:42 <dwery> a simple echo "red on" > /sys/devices/system/leds/leds0/event
Sep 30 08:53:44 <dwery> will work
Sep 30 08:54:31 <jbowler-zzz> Then you must change the startup scripts...  what gives here?
Sep 30 08:54:56 <dwery> I'm working on the kernel , I don't want and can't manage the startup scripts. 
Sep 30 08:55:07 <jbowler-zzz> Then don't make incompatible changes to the kernel.
Sep 30 08:55:25 <jbowler-zzz> There's a well know rule "you break it, you fix it."  It works pretty well.
Sep 30 08:56:01 <dwery> I will make the patch for my own use and propose it. If it gets accepted someone will have to make the fix. 
Sep 30 08:56:30 <jbowler-zzz> That's fine, but please keep it separate from the other patches.
Sep 30 08:56:38 <dwery> of course
Sep 30 09:21:30 <eFfeM> dwery, as you are working on leds, can you explain why led0 goes on when I connect a normal device and goes off when I connect the same device through a passive hub
Sep 30 09:22:02 <dwery> eFfeM: yes, i'm working on leds but I don't use OpenSlug nor the leds command
Sep 30 09:22:11 <eFfeM> ok
Sep 30 09:22:15 <dwery> eFfeM: i'monly workin gon the kernel side
Sep 30 09:22:26 <eFfeM> i understand
Sep 30 09:23:08 <dwery> (the space key on my keyboard must be broken)
Sep 30 09:23:11 <dwery> :-D
Sep 30 09:23:35 <eFfeM> btw, didn't merge in your changes yet, but just tried to compile with debug
Sep 30 09:24:04 <eFfeM> the old driver gives compilation errors on dev_dbg. Pointer deref as the compiler complains on ->
Sep 30 09:24:18 <eFfeM> haven't looked up the macro, just replaced by printk
Sep 30 09:26:19 <jbowler-away> eFfeM: there's a kernel patch to do the disk LEDs, I don't think it's in dwery's patch set, but I don't know.
Sep 30 09:26:39 <dwery> jbowler-away: confirmed, is not in my patchset
Sep 30 09:35:34 <eFfeM> ok, tnx, understood it
Sep 30 09:36:06 <eFfeM> meanwhile did something nasty to my slug, compiled with debug, it's writing to disk very intensive and I can't ping it
Sep 30 09:36:16 <eFfeM> led is green though
Sep 30 09:36:27 <eFfeM> trying to get some more info on me crashes ...
Sep 30 09:43:03 <nettie> Hi guys, anyone know where I can find UcSLugC binary images or src please?
Sep 30 10:03:40 <jbowler-zzz> At present you have to get it from monotone.
Sep 30 10:04:22 <jbowler-zzz> The master makefile (i.e. http://www.nslu2-linux.org/Makefile) will download/build ucslugc (as well as eveything else if you want).
Sep 30 10:14:24 <nettie> jbowler-zzz thanx a lot .. does it depends to the bb+oe or it's a totally diff build env? I'm pretty used to buildroot
Sep 30 10:17:06 <jbowler-zzz> It's bb+oe
Sep 30 10:17:33 <nettie> uhmm
Sep 30 10:18:37 <nettie> ok .. thanx for the hint.. .. I must get outta here catch you l8r. thanx.
Sep 30 10:44:11 <eFfeM> hi, is there a way to turnup after loading a new img without nuking the rootfs on hd ?
Sep 30 10:44:43 <eFfeM> on openslug
Sep 30 10:49:57 <hannesr> Hi people. Anybody have that 2.0-based LE ethernet patch mentioned on the mailing list?
Sep 30 10:54:38 <[g2]> hey hannesr.
Sep 30 10:54:42 <[g2]> You do right ? :)
Sep 30 10:55:04 <hannesr> I do what?
Sep 30 10:55:10 <[g2]> have that patch
Sep 30 10:55:43 <hannesr> no, I don't mean the one I made - I mean this one: http://groups.yahoo.com/group/nslu2-linux/message/8980
Sep 30 10:56:36 <hannesr> Sounds like it actually works, unlike my 1.5 patch :)
Sep 30 10:57:06 <[g2]> I think he posted something to the developers list too
Sep 30 10:57:39 <[g2]> or maybe I'm getting your messages and his all mixed up :)
Sep 30 10:58:15 <hannesr> yeah, I don't see anything on the developers list
Sep 30 10:58:54 <hannesr> It's interesting that he doesn't mention any crashes like I was seeing... I wonder if he has something different in his kernel.
Sep 30 10:59:04 <[g2]> I know I pulled your patches for the 1.5 stuff
Sep 30 10:59:22 <[g2]> I haven't compared patchsets with the 1.4 aggregate I've got
Sep 30 11:11:38 <CIA-8> 03justinp 07org.openembedded.dev * re965f050... 10/packages/ (76 files in 12 dirs): (log message trimmed)
Sep 30 11:11:38 <CIA-8> e17, efl: major upgrade to newer versions
Sep 30 11:11:38 <CIA-8> - Upgraded shapshot-based packages to newest released snapshots
Sep 30 11:11:38 <CIA-8> - Upgraded CVS-based packages to use a newer date
Sep 30 11:11:38 <CIA-8> - Moved e and e-wm to use snapshots as a default instead of CVS
Sep 30 11:11:40 <CIA-8> - Updated patches to work with newer versions
Sep 30 11:11:42 <CIA-8> - Added patches to fix problems introduced in newer versions
Sep 30 11:13:49 <dwery> mail sent to the list about leds driver, I appreciate any feedback. going to dinner now.. bye!
Sep 30 12:21:17 <CIA-8> 03justinp 07org.openembedded.dev * r7090b2f5... 10/packages/e17/entrance/config-db.patch: entrance: Make the Default session Englightenment since the sesion chooser doesn't work
Sep 30 13:11:13 <CIA-8> 03nail 07org.openembedded.dev * rc76952a2... 10/packages/bash/bash_3.0.bb: bash: create sysconfdir/shells upon install
Sep 30 13:39:35 <CIA-8> 03repvik * r210 10/releases/OpenSlug-2.5-beta/openembedded/packages/samba/samba_3.0.14a.bb: Fix smbmount bug
Sep 30 13:40:08 <CIA-8> 03repvik * r211 10/releases/OpenSlug-2.7-beta/openembedded/packages/samba/ (samba_3.0.14a.bb samba_3.0.20.bb): Fix smbmount bug
Sep 30 13:41:08 <CIA-8> 03nail 07org.openembedded.dev * r7cef5076... 10/packages/bash/bash_3.0.bb: bash: kill the output from grepping after shells
Sep 30 13:41:11 <CIA-8> 03nail 07org.openembedded.dev * r70ec7862... 10/packages/samba/ (samba_3.0.14a.bb samba_3.0.20.bb): samba: fix mount.smbfs symlink, so mounting smbfs works
Sep 30 14:54:21 <eFfeM> hi, anybody know what the source is for built-in.o in drivers/i2c/busses
Sep 30 14:54:41 <eFfeM> there is no such thing as built-in.c and it is not in the compile log ...
Sep 30 14:55:01 <senneth> built-in.o just containst all the stuff exported by the .c files
Sep 30 14:55:47 <eFfeM> ah, ok
Sep 30 16:06:26 <CIA-8> 03yuecelm 07org.openembedded.dev * r381f5ac5... 10/packages/avetanabt/ (files/maxConnectedDevices.patch avetanabt_cvs.bb): 
Sep 30 16:06:26 <CIA-8> avetana_cvs: some cosmetic changes and working patch
Sep 30 16:06:26 <CIA-8>  * better descriptions, use staging-only commands, remove cd handling
Sep 30 16:06:26 <CIA-8>  * now working patch (replaces avetanalocaldevice.patch)
Sep 30 16:16:15 <CIA-8> 03yuecelm 07org.openembedded.dev * re83da273... 10/packages/avetanabt/files/avetanalocaldevice.patch: avetanabt_cvs: remove avetanalocaldevice.patch
Sep 30 16:48:49 <dwery> Jacmet: ping
Sep 30 16:49:56 <rwhitby> dwery: sorry I led you down the garden path on the leds issue,
Sep 30 16:50:14 <dwery> rwhitby: np
Sep 30 16:50:43 <rwhitby> I agree with jbowler that we shouldn't change the ready/status led.  But I would like to see that cpu status functionality as an option for one of the other leds.
Sep 30 16:51:23 <dwery> I wrote an email explaing that. by default, the interface does not touch the leds
Sep 30 16:51:25 <rwhitby> But what I was really thinking about (and I didn't explain myself clearly) was the lower-level interface to the leds, rather than the code which gives the leds a meaning.
Sep 30 16:51:28 <dwery> it's just an interface
Sep 30 16:51:57 <dwery> if you want it to give meaning, you have to define two more CONFIG_
Sep 30 16:52:06 <rwhitby> dwery: nod.  I'd love to be able to give the user the ability to tie that functionality to, for instance, the DISK2 led.
Sep 30 16:52:18 <rwhitby> (without having to recompile)
Sep 30 16:52:34 <dwery> then just define CONFIG_LEDS and do everything in userspace
Sep 30 16:53:31 <NAiL> Actually, I'd love to have the status led being able to show cpu state... After bootup it's constantly green anyway 
Sep 30 16:53:58 <dwery> NAiL: then you;' have to define CONFIG_LEDS and CONFIG_LEDS_CPU :)
Sep 30 16:54:07 <NAiL> aha
Sep 30 16:54:12 <dwery> it's completely configurable,
Sep 30 16:54:14 <dwery> .
Sep 30 16:54:31 <rwhitby> NAiL: as long as it was on-top-off (rather than replacing) the boot status fuctionality for the ready/status led
Sep 30 16:54:35 <NAiL> but it requires a recompile though
Sep 30 16:54:43 <NAiL> rwhitby: yes
Sep 30 16:55:19 <rwhitby> so I think we have two great functionalities defined for the ready/status leds, and just have to work out how to combine them sensibly :-)
Sep 30 16:55:46 <dwery> NAiL: you can compile it in and disable it at runtime
Sep 30 16:56:34 <rwhitby> dwery: so maybe our startup scripts just enable the cpu status at the point where they currently turn it sold green ...
Sep 30 16:56:53 <rwhitby> and we make the status indicators consistent (colour-wise) with the boot indicators
Sep 30 16:57:30 <dwery> it works this way:
Sep 30 16:57:38 <rwhitby> (i.e. pulsing green)
Sep 30 16:57:41 <dwery> red led: cpu idle
Sep 30 16:57:50 <dwery> green led: timer ticks
Sep 30 16:57:52 <dwery> so during boot
Sep 30 16:58:01 <dwery> youl'have some flickering activity
Sep 30 16:58:07 <dwery> when the script starts
Sep 30 16:58:12 <dwery> you can claim the interface
Sep 30 16:58:18 <dwery> and do what you want
Sep 30 16:58:31 <rwhitby> dwery: we want to do this: http://www.nslu2-linux.org/wiki/OpenSlug/OpenSlugLEDsDuringBoot during boot
Sep 30 16:58:45 <dwery> let me see
Sep 30 16:58:47 <rwhitby> and then switch over to the cpu status stuff when everything is up and running
Sep 30 16:59:17 <rwhitby> and maybe flicker the green led to show cpu activity.  dunno.
Sep 30 17:00:12 <dwery> the run level thing seems doable
Sep 30 17:00:44 <dwery> the problem is that you can't easily control the led until the first script gets loaded
Sep 30 17:02:21 <dwery> we can have the interface come up with a steady red
Sep 30 17:02:33 <dwery> or a blinking green
Sep 30 17:02:37 <dwery> or amber
Sep 30 17:03:37 <rwhitby> dwery: jbowler-zzz is in agreement with overlaying the two functionalities, so I am sure we will together be able to work something out.
Sep 30 17:03:47 <dwery> i would take the solid red until user-space is ready
Sep 30 17:05:32 <NAiL> yeah
Sep 30 17:05:36 <NAiL> that makes sense to me
Sep 30 17:05:42 <NAiL> as long as the kernel is booting
Sep 30 17:06:09 <dwery> ok, the CONFIG_LEDS would do it
Sep 30 17:17:41 <dwery> anyway.. it's better to try it. I will make the patch and post the explanations...
Sep 30 17:21:55 <rwhitby> dwery: thanks again for doing this stuff, and not reacting to disagreements.  It's only through strong opinions on stuff that we can work out even better solutions ....
Sep 30 17:22:26 <dwery> rwhitby: thank you for pointing me to the interface.. i would not have found it otherwise
Sep 30 17:22:59 <rwhitby> actually, I just postulated the existence of such an interface.  You did the work of finding one :-)
Sep 30 17:23:39 <dwery> :-d
Sep 30 17:24:22 <dwery> about the buzzer.. what are the requirements?
Sep 30 17:24:53 <rwhitby> dunno.  just post whatever alternatives you find to nslu2-developers
Sep 30 17:25:15 <rwhitby> we'll reverse engineer the requirements from what's available :-)
Sep 30 17:25:44 <rwhitby> PC speaker is a good one, cause higher-level software may know how to drive that
Sep 30 17:26:00 <rwhitby> dyoung-zzzz wants a 1-bit MP3 player ;-)
Sep 30 17:26:23 <dwery> well. .. not.. even if an interface exists, it is usually not used.
Sep 30 17:26:39 <dwery> they often use the console interface
Sep 30 17:26:45 <dwery> but we don't have consoles :D
Sep 30 17:27:14 <rwhitby> wonder if we can have the buzzer do the job of the normal console bell :-)
Sep 30 17:27:18 <dwery> i have an rttl player :)
Sep 30 17:27:56 <dwery> and a modified version of the beep command line utility
Sep 30 18:33:57 <dwery> if i've understood correctly David A Thomas was able to run IAL 2.0 in LE????!!
Sep 30 18:34:41 <NAiL> that's my understanding as well
Sep 30 18:34:59 <dwery> wow
Sep 30 18:35:07 <dwery> it's late now for me to try it
Sep 30 18:36:22 <NAiL> I glanced at the readme
Sep 30 18:36:40 <NAiL> said something about *not* following intels instructions makes it work :P
Sep 30 18:36:55 <dwery> me too :)
Sep 30 18:37:01 <dwery> is david usually on irc?
Sep 30 18:37:12 <NAiL> no idea
Sep 30 18:37:17 <NAiL> dunno who it is
Sep 30 18:37:42 <dwery> I can't find any previous message from him...
Sep 30 18:37:49 <dwery> i need to send him my congrats!
Sep 30 18:38:42 <dwery> yvasilev and I tried very hard but is patch is far more complex
Sep 30 18:38:49 <dwery> s/is/his/
Sep 30 18:41:13 <dwery> quick look at the patch..
Sep 30 18:41:32 <dwery> there's a lot of interesting things...
Sep 30 18:42:58 <dwery> i'll try it tomorrow along with 2.6.14-rc3
Sep 30 18:44:31 <dwery> g'night
Sep 30 19:11:11 <CIA-8> 03jbowler 07org.openembedded.dev * r8233fc7a... 10/packages/freeze/files/freeze: freeze: regular expressions to recognise x11 package versions correctly
Sep 30 19:31:08 <CIA-8> 03jbowler 07org.openembedded.dev * r8cc66088... 10/ (7 files in 4 dirs): 
Sep 30 19:31:08 <CIA-8> python(openslug), openslug kernel: enable tcl/tk in python, move kernel to 2.6.14-rc2
Sep 30 19:31:08 <CIA-8> The changes overlap (in conf/distro/openslug.conf), the kernel change is, however,
Sep 30 19:31:08 <CIA-8> only the version change in that file.
Oct 01 00:07:09 <eFfeM> mornin'
Oct 01 00:23:44 <rwhitby> jbowler-zzz, dwery-zzz: Documentation/ibm-acpi.txt has some LED stuff in it
Oct 01 01:16:14 <CIA-8> 03jbowler 07org.openembedded.dev * r2fd17401... 10/packages/ (9 files in 5 dirs): ixp intel drivers: ixp4xx v1.5 ixp425-eth v1.2
**** ENDING LOGGING AT Sat Oct 01 02:59:56 2005