[05:44] <fabbione> morning
[06:43] <fabbione> hey jbailey 
[06:44] <jbailey> Heya Fabio
[06:44] <jbailey> I'm about to upload initramfs-tools 0.14
[06:44] <fabbione> nice
[06:44] <jbailey> Just need to figure out why bzr doesn't feel like commiting.
[06:44] <fabbione> jbailey: did you hear anything about binutils to fix that link problem on sparc?
[06:44] <jbailey> No, but I haven't had a chance to dig in yet.
[06:45] <jbailey> Sorry about that. =(
[06:45] <fabbione> no need to be sorry please
[06:45] <fabbione> :)
[06:45] <fabbione> i was only asking...
[06:46] <fabbione> the situation still looks good
[06:46] <jbailey> Well, I feel bad that I haven't had a chance.
[06:46] <jbailey> Feeling a bit swamped.
[06:46] <fabbione> but the gnome pkgs starts to pile up
[06:46] <jbailey> bzr commit done.
[06:46] <jbailey> This version actually now detects IDE correctly on my box, SATA on another one, and LVM and Raid1.
[06:47] <fabbione> nice
[06:47] <fabbione> i hope i won't crash today
[06:47] <fabbione> and give it a shot
[06:48] <fabbione> i am so tired you have no idea
[06:48] <jbailey> Still no evms or cryptroot.
[06:48] <jbailey> I just don't have test scenarios for those, so it'll be a bitch.
[06:48] <fabbione> if you have md and lvm you also have evms
[06:48] <jbailey> I do?
[06:48] <jbailey> I'll ask you sometime when I'm awake.
[06:49] <jbailey> I promised mdz that I'd put out a call for testers today on what I have.
[06:49] <fabbione> as it stands now.. evms and lvm are "only" 2 interfaces towards device-mapper
[06:49] <fabbione> if you get one, somehow you get the other
[06:49] <jbailey> Ah, okay.
[06:49] <fabbione> but mdz can give you more details about evms
[06:49] <fabbione> he was the maintainer
[06:49] <jbailey> 'cept that he's insanely busy.
[06:49] <fabbione> well he can spend 2 minutes
[06:50] <fabbione> at least this is at kernel level..
[06:50] <fabbione> if userland does something "weird" i dunno
[06:50] <fabbione> i was never able to make evms work in a decent way
[06:51] <jbailey> evms ate my partition table
[06:51] <jbailey> So I'm not inclined to try it again.
[06:52] <fabbione> ehhe
[06:58] <jbailey> Rejected: binary uploads are not allowed - please only upload source.
[06:58] <jbailey> Bah
[06:58] <jbailey> I must get that wrong like *half* the time.
[06:59] <fabbione> ehhehe
[07:12] <fabbione> jbailey: when i am linking.. can i avoid to specify -m $emulation ?
[07:12] <fabbione> or is it somewhat mandatory?
[07:12] <jbailey> Mmm, I thought it was supposed to detect it from the module.
[07:12] <jbailey> I might be mistaken.
[07:12] <fabbione> what i mean is:
[07:12] <jbailey> It's been so long since I've used ld directly.
[07:12] <fabbione> ld -m elf_i386 -r -o $dest $modules
[07:13] <jbailey> Right.
[07:13] <fabbione> if i omit -m elf_i386, which one will be selected?
[07:13] <jbailey> I think you ought to be able to leave it out.
[07:13] <jbailey> It should be detected, so in this case elf_i386
[07:13] <fabbione> i guess i need to try it
[07:14] <fabbione> yeah it works on i386
[07:34] <jbailey> Sleep time. 
[02:24] <jbailey> fabbione: Hey - did you get a chance to try the initramfs-tools stuff at all?
[02:25] <fabbione> no :(
[02:28] <zul> heylo
[02:29] <fabbione> hey zul
[02:29] <zul> hey how is it going?
[02:32] <fabbione> as usual
[02:34] <zul> exciting
[02:35] <fabbione> what's exciting about it?
[02:46] <zul> i was being sarcastic
[04:33] <lamont__> fabbione: rebooting now
[04:33] <fabbione> kw33l
[04:36] <lamont__> well.  that was painful
[04:36] <fabbione> so?
[04:36] <lamont__> good news for doko... it's not 3.4
[04:36] <fabbione> bad news for the ia64 porter :P
[04:36] <lamont__> bad news for me: it's not 3.4
[04:36] <lamont__> yeppers
[04:37] <lamont__> means I have to actually work on it.
[04:37] <fabbione> lamont__: the only thing i try to do is disable acpi on ia64
[04:37] <lamont__> ??
[04:37] <fabbione> it's the only big ia64 chunk of code that's different from Debian
[04:37] <fabbione> sorry. "i would try to do"..
[04:37] <lamont__> I should try booting with noacpi?  or there's a kernel patch I should try removing?
[04:37] <fabbione> try booting with noacpi first
[05:16] <jbailey> W00t Got my drivers license.
[05:17] <jbailey> Angie has to wait until she gets better proof of residence.
[05:17] <jbailey> So stupid.
[05:17] <zul> its the same in ontario dude
[05:18] <jbailey> Umm, no.
[05:18] <jbailey> Her lease was good enough, and a bank statement was good enough for me.
[05:18] <zul> well..for health card i guess
[05:18] <jbailey> Well + old license. =)
[05:19] <jbailey> But here, I needed passport,  ontario health card, ontario drivers license, and a current bill showing transactions only in quebec since I moved sent to this address.
[05:19] <jbailey> Andit has to be a bill from a 'respectable place'
[05:19] <zul> so pornos are out? :)
[05:19] <jbailey> The fact that she bought $3500 worth of appliances from Future Shop that got sent to the appartment that she leased isn't good enough.
[05:20] <jbailey> Nor is the confirmation from Hydro Quebec saying that her account is now open good enough.
[05:21] <jbailey> She had a visa bill with her, but the lady just said that it doesn't matter.  The bank will send a statememnt anywhere.
[05:21] <jbailey> *my* visa bill was fine, though, since it has a u-haul on it, a bunch of gas stops along the 401 and a dozen or so transactions in montreal after that.
[05:21] <zul> lol...stupid quebec
[05:23] <jbailey> I thought it was a bit extreme.
[05:23] <jbailey> But I got mine for now, anyway.
[05:24] <jbailey> The Hydro bill is in her name, so when that gets sent, that'll be good enough.
[05:28] <zul> getting married in quebec is pretty extreme i hear as well
[05:34] <jbailey> Oh?
[05:34] <jbailey> What's the story there?
[05:35] <zul> i dont really remmeber unforuntately..
[05:45] <jbailey> fabbione: ping?
[05:45] <jbailey> fabbione: any idea if this is going anywhere upstream: http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch
[05:47] <fabbione> jbailey: acpi -> mjg59 .. really...
[05:48] <jbailey> Hmm.  This is more initramfs handling, but alright. =)
[05:48] <jbailey> mjg59_: *poke* ^^^
[05:48] <jbailey> It looks like we need to apply either that one or this one:
[05:48] <jbailey> http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch
[05:52] <mjg59_> acpi upstream aren't keen on it
[05:53] <mjg59_> If it's needed for initramfs, then push it
[05:54] <lamont__> mjg59_: the ia64 issue is more basic... nothing from the kernel but timeout/machine-checks
[05:54] <mjg59_> lamont__: Mm?
[05:54] <lamont__> 2.6.10-5 boots fine and all, 2.6.12-current is not so happy.  with or without 'noacpi'
[05:54] <lamont__> so somewhere in there, I have issues to figure out.
[05:54] <mjg59_> Can you revert the acpi patch?
[05:54] <lamont__> could be a fun little bios interaction
[05:55] <mjg59_> Hmm. Hang on - I seem to remember something that may be related. Hang on.
[05:55] <lamont__> mjg59_: that's certainly on the list...
[05:55] <lamont__> mjg59_: the "one console" issue?
[05:55] <jbailey> mjg59_: Do they have specific concerns that I should work with?  Having it right in the filesystem is elegant in a number of ways.
[05:55] <mjg59_> jbailey: "Vendors should fix their hardware"
[05:55] <jbailey> mjg59_: Not the least of which that you can swap dsdt's at boottime with a trivial hack to grub.
[05:56] <mjg59_> lamont__: If it boots without that, can you grab the latest bleeding-edge ACPI patch and see if that's any better?
[05:57] <lamont__> mjg59_: certainly.  will probably pester you for where to grab said bleeding-edge razor
[05:58] <jbailey> fabbione: I have a really strong preference of the acpi-dsdt-initrd-v0.7d.... patch.  It has the advantage that if someone does a custom kernel, they just won't get a DSDT.  With the other one, if they run a stock kernel, the kernel can't load an initramfs with a DSDT in it.
[05:58] <jbailey> mjg59_, fabbione: What prep/testing do you need me to do in order to test it adequately for you to bless it?
[05:59] <fabbione> jbailey: are the 2 patches mutal exclusive?
[05:59] <fabbione> so it's either one or the other
[05:59] <jbailey> No
[05:59] <mjg59_> jbailey: The initramfs one looks correct. Break your DSDT, boot with it, see if your machine breaks
[05:59] <mjg59_> If so, I'm happy with it
[05:59] <jbailey> mjg59_: The one that just alters the read size to compensate for the DSDT hanging off the end?
[05:59] <mjg59_> Hang on
[06:00] <zul> ding dong the wicked witch...er..
[06:00] <mjg59_> jbailey: Ok. What's the precise issue?
[06:00] <jbailey> zul: Funny enough, there are bells rining outside.
[06:01] <zul> lol
[06:02] <jbailey> mjg59_: With an initramfs, using the traditional way of appending the DSDT to the initramfs causes a boot failure.  The people at this web site are proposing two solutions.  1) (http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch) makes the initramfs read function calculate the size of the initramfs without including the files so that it unpacks the initramfs correctly.  The rest of th
[06:02] <jbailey> e sstem should go on to process the dsdt correctly.
[06:02] <mjg59_> Yes. That looks clean enough.
[06:02] <jbailey> 2)  http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch makes the initramfs system available earlier so that acpi can simply open the file off of the filesystem and read it in.
[06:02] <mjg59_> Right. I've no preference.
[06:02] <mjg59_> The first seems less invasive
[06:03] <jbailey> So here's the catch.
[06:03] <jbailey> 1) Means that if someone does a custom kernel, but includes a DSDT at the end, they won't have the patch, so the machine won't boot.
[06:03] <mjg59_> Yes
[06:03] <jbailey> 2) Means that if someone does a custom kernel, and includes a DSDT in the initramfs, it simpy won't get read by anything.
[06:03] <mjg59_> Well, either is fine with me. 
[06:04] <jbailey> Have you seen either of these on upstream lists?  I have a preference for #2 to reduce the support nightmare.
[06:04] <jbailey> But I suspect that #1, being less invasive, is more likely to get accepted.  But that's entirely a guess.
[06:04] <mjg59_> Neither is going to make it upstream while acpi upstream are hostile
[06:04] <jbailey> If neither will make it upstream, then I'll do #2 =)
[06:06] <jbailey> fabbione: What sort of testing do you want me to do before I say "Please include this patch"?
[06:07] <fabbione> jbailey: it's enough it works for you....
[06:08] <jbailey> 'kay
[06:08] <jbailey> I guess I need to figure out how to compile a kernel now. =)
[06:08] <fabbione> it looks to me we already have 2
[06:08] <jbailey> Oh?
[06:10] <mjg59_> fabbione: I think we only have an earlier version of the patch that doesn't deal with initramfs
[06:10] <jbailey> Hmm, can I apt-get source the i386 kernel from a ppc?
[06:11] <fabbione> jbailey: the kernel is only one
[06:11] <fabbione> there is only ONE source
[06:11] <zul> use the source luke
[06:12] <fabbione> mjg59_: well i have no issues to update it..
[06:12] <jbailey> Ah, handy
[06:12] <jbailey> 26k source?
[06:13] <jbailey> Oh, that's linux-meta
[06:13] <jbailey> 47mb, much better
[06:15] <jbailey> Err..  Is i386 only at 2.6.12-3 ?
[06:15] <jbailey> That's all concordia seems to have in its chroot's apt sources
[06:19] <fabbione> jbailey: you can grab the sources from my home on concordia
[06:20] <fabbione> take 4.4 please
[06:20] <fabbione> 4.5 is the playground atm
[06:25] <jbailey> Hmm
[06:25] <fabbione> desrt: what kernel flavour do you use?
[06:25] <jbailey> I thought drivers-acpi-osl_attach-dsdt-to-initrd.dpatch
[06:25] <jbailey>  was already upstream
[06:26] <lamont__> hrm.. external-global-acpi_update.dpatch is pretty *&(^^%_ invasive
[06:26] <desrt> fabbione; 686-smp and powerpc64-smp
[06:26] <fabbione> desrt: ok.. i will make 686-smp for you to test
[06:26] <lamont__> mjg59_:  external-global-acpi_update* were the two you wanted me to pull?
[06:27] <desrt> fabbione; the hardware arrived today for our cluster :)
[06:27] <desrt> fabbione; so, as of tomorrow i'm gonna be running 5 boxes with powerpc64-smp :)
[06:28] <desrt> (and some time later about 12)
[06:28] <fabbione> desrt: cool!
[06:28] <fabbione> desrt: what kind of cluster are you going to run?
[06:28] <desrt> our own thing
[06:29] <fabbione> yeah.. i mean. HA or HP cluster?
[06:29] <fabbione> A=Availability
[06:29] <fabbione> P=Performance
[06:31] <mjg59_> lamont__: Yeah
[06:31] <jbailey> Anyone have a SuSE kernel source handy?
[06:31] <jbailey> I'd love to see if they apply this other one, it's one of their folks that wrote it:
[06:32] <jbailey> http://gaugusch.at/acpi-dsdt-initrd-patches/acpi_dsdt_initrd_initramfs.patch
[06:32] <jbailey> http://gaugusch.at/acpi-dsdt-initrd-patches/initramfs-before-acpi.patch
[06:35] <fabbione> dpkg-deb: building package `linux-image-2.6.12-4-686-smp' in `../linux-image-2.6.12-4-686-smp_2.6.12-4.5_i386.deb'.
[06:35] <fabbione> and NO ABI breakage!
[06:35] <fabbione> (....yet)
[06:35] <jbailey> This too shall pass ;)
[06:36] <fabbione> desrt: http://people.ubuntu.com/~fabbione/
[06:37] <fabbione> desrt: there are 3 linux-*-4.5*.deb
[06:37] <fabbione> can you test inotify with them?
[06:37] <fabbione> they include all the latest fixed
[06:37] <fabbione> fixes
[06:37] <fabbione> just rememeber that is NOT 4.5 final
[06:37] <fabbione> so you might have to upgrade it later
[06:50] <desrt> sorry for the delay.  got busy for a moment
[06:52] <fabbione> desrt: no problem, take your time to test.
[06:52] <fabbione> i need to go out now
[06:52] <fabbione> i will bbl
[06:53] <fabbione> ps don't use SYSCALLS 289 and 290.. they are fake and unsecure atm
[06:53] <fabbione> i already have a better patch done..
[06:53] <fabbione> but i need to know if it works for you now with the 291/292/293
[06:53] <fabbione> in sync with *
[06:53] <fabbione> later
[06:59] <desrt> fabbione; problem is not fixed
[07:00] <desrt> :q
[07:01] <desrt> erp
[07:26] <desrt> fabbione; looking at your source package, nothing has changed
[07:27] <desrt> fabbione; (from looking at source) sys_inotify_rm_watch is still doing improper input validation and (from testing against your binary) i'm still getting the crash
[07:35] <desrt> from 2.6.13-rc3-git8: http://manic.desrt.ca/inotify.c
[07:35] <desrt> search for /* verify that this is indeed an inotify instance */
[07:52] <fabbione> desrt: i didn't put any source there...
[07:52] <fabbione> did you take 4.5 ?
[07:52] <fabbione> or by mistake you took 4.4?
[07:52] <desrt> i took linux-source-diff that was in the group of them :)
[07:52] <fabbione> it's not the one to look at
[07:52] <desrt> ahh
[07:52] <desrt> well, in any case, the binary still exibits the crash :)
[07:52] <fabbione>  /* verify that this is indeed an inotify instance */
[07:52] <fabbione> this is there
[07:52] <desrt> uname -a shows Jul 27
[07:52] <fabbione> twice
[07:53] <desrt> weird.....
[07:53] <fabbione> dpkg -l linux-image-2.6.12-4-686-smp
[07:53] <desrt> 2.6.12-4.5
[07:53] <fabbione> yeah that's it
[07:53] <desrt> want me to send you a testcase?
[07:53] <fabbione> it's all the latest inotify
[07:54] <fabbione> desrt: did you change the syscalls to match the real ones?
[07:54] <desrt> yes
[07:54] <desrt> i'm using 293 now, i think
[07:54] <fabbione> well.. can you recheck please :)
[07:55] <desrt> you're using the same syscall numbers as the official 2.6.13, right?
[07:55] <fabbione> also.. did you check that it is fixed in git8?
[07:55] <fabbione> yes. right
[07:55] <desrt> no.  i haven't.
[07:55] <fabbione> by running it...
[07:55] <fabbione> well that would be something to do :)
[07:55] <desrt> cool
[07:55] <desrt> 293 is, in fact, the right number
[07:56] <desrt> will test git
[07:56] <fabbione> thanks
[07:56] <zul> ohwee...i got business cards
[08:01] <desrt> man... it's times like this when i'm building a kernel that i wish i had a nice pentium D system
[08:02] <desrt> crimsun; w3rd.
[08:03] <crimsun> 'lo desrt 
[08:04] <desrt> "nothing's gonna change my world....."
[08:15] <desrt> fabbione; i get -EINVAL on that syscall on 2.6.13-rc3-git8
[08:15] <desrt> and no crash
[08:16] <desrt> so 2.6.13-rc3: bad
[08:16] <desrt> so 2.6.13-rc3-git8: good
[08:16] <desrt> and 2.6.12-4.5: bad
[08:19] <fabbione> desrt: ok.. i will give you another kernel in a few minutes..
[08:19] <desrt> :)
[08:19] <fabbione> it looks like not all the patches in git as commented as they should...
[08:25] <fabbione> desrt: it's building..
[08:26] <fabbione> if this one still crash, i know exactly what it is
[08:26] <fabbione> but
[08:26] <fabbione> it's not going to be fun at all
[08:34] <fabbione> desrt; http://people.ubuntu.com/~fabbione/desrt/ <-
[08:34] <fabbione> i will be back in few minutes..
[08:54] <fabbione> desrt: ?
[08:54] <desrt> fabbione; just installed and am rebooting now
[08:54] <fabbione> cool
[08:55] <desrt> Jul 27 18:25:09 UTC
[08:55] <desrt> no crash
[08:55] <fabbione> perfect
[08:55] <desrt> ship it! :)
[08:55] <fabbione> do you want to know what it was?
[08:55] <desrt> ya.  for sure
[08:56] <fabbione> NEVER TRUST PATCH!
[08:56] <desrt> uhm... what happened?
[08:56] <fabbione> basically i was doing cg-mkpatch -r $id | patch -d $pathtokernel -p1
[08:56] <fabbione> on all inotify commit
[08:56] <fabbione> no rejects
[08:56] <fabbione> no fuzzyness
[08:56] <fabbione> it ended with 2 different files
[08:57] <fabbione> (same base of course)
[08:57] <desrt> like what?
[08:57] <fabbione> there were diffs in the order of some hunks
[08:58] <fabbione> the final inotify.c was different
[08:59] <fabbione> @@ -990,6 +991,8 @@
[08:59] <fabbione>         filp = fget_light(fd, &fput_needed);
[08:59] <fabbione>         if (unlikely(!filp))
[08:59] <fabbione>                 return -EBADF;
[08:59] <fabbione> +       dev = filp->private_data;
[08:59] <fabbione> +       ret = inotify_ignore (dev, wd);
[08:59] <fabbione> 
[08:59] <fabbione>         /* verify that this is indeed an inotify instance */
[08:59] <fabbione>         if (unlikely(filp->f_op != &inotify_fops)) {
[08:59] <fabbione> @@ -997,9 +1000,6 @@
[08:59] <fabbione>                 goto out;
[08:59] <fabbione>         }
[08:59] <fabbione> 
[08:59] <fabbione> -       dev = filp->private_data;
[08:59] <fabbione> -       ret = inotify_ignore(dev, wd);
[08:59] <fabbione> -
[08:59] <fabbione> something like this
[08:59] <desrt> er
[08:59] <desrt> that's the inverse of the patch you need :)
[08:59] <desrt> actually, it's just nonsense
[08:59] <fabbione> yes sorry..
[09:00] <desrt> it's like "do it first, check later" :)
[09:00] <fabbione> i did it the wrong way
[09:00] <fabbione> but it still landed in the wrong order in the final inotify.c
[09:00] <fabbione> that's the point
[09:00] <desrt> nod.
[09:00] <desrt> well
[09:00] <desrt> it all seems to be working fine now
[09:00] <fabbione> never mind the direction of that patch
[09:00] <desrt> maybe the cg-mkpatch wasn't generating enough lines of context
[09:01] <desrt> so it just went blindly by linenumber and put it in the wrong place
[09:01] <fabbione> possibly
[09:01] <desrt> that'd also explain why it didn't mention any fuzz
[09:03] <fabbione> baz commit -s'Update inotify'
[09:03] <desrt> ok.  so is this when a bug becomes PENDINGUPLOAD?
[09:03] <fabbione> M  patches/sth-fs_inotify.dpatch
[09:03] <fabbione> M  changelog
[09:03] <fabbione> yes
[09:03] <fabbione> but iirc you can't change from UPSTREAM to PENDINGUPLOAD directly
[09:04] <fabbione> so we will close it after we upload...
[09:04] <fabbione> not a big deal
[09:04] <desrt> nod.
[09:04] <fabbione> jbailey mjg59_: ping?
[09:04] <jbailey> pong
[09:04] <fabbione> otherwise you need to put it as ASSIGNED and than PENDINGUPLOAD
[09:04] <desrt> ya.  evil bugzilla :P
[09:04] <fabbione> jbailey: remember i will be VAC from 1st of Aug
[09:05] <fabbione> infinity will take care of the kernel
[09:05] <fabbione> but i plan an upload for no later than friday
[09:05] <fabbione> so if there is something important or urgent, it has to be withing friday morning
[09:05] <fabbione> mjg59_: the above is valid also for ACPI
[09:05] <fabbione> because the 8th of Aug is Feature Freeze
[09:05] <fabbione> (or the 5th.. i can never remember)
[09:06] <zul> hmmm...i think im going to be busy this weekend ;)
[09:06] <fabbione> zul: no crack please.. only tested committs...
[09:06] <fabbione> we need to go very stable and very fast
[09:06] <zul> yep
[09:06] <fabbione> zul: specially.. test before commit
[09:06] <fabbione> or at least build
[09:07] <fabbione> i don't want to come back and have to cleanup a mess :)
[09:07] <zul> heh...
[09:07] <zul> all of my group has gone home for the day. and its only 3:13pm
[09:08] <zul> slackers
[09:21] <fabbione> ok
[09:21] <fabbione> time to stop
[09:21] <fabbione> it's only 9:20 pm
[09:21] <fabbione> and i started at 6am
[09:22] <desrt> :)
[09:22] <desrt> fabbione++ 
[09:22] <fabbione> another 2 bug fixes done..
[09:22] <fabbione> desrt: i might upload tomorrow..
[09:22] <fabbione> or max friday
[09:22] <fabbione> you can use the temp kernel in the meanwhile
[09:22] <desrt> it's cool.  it's not actually affecting me
[09:23] <desrt> i can just avoid passing an invalid fd to inotify :P
[09:23] <fabbione> uh no.. the other 2 bug fixes are ACPI and USB related
[09:31] <zul> i think we might have to close some more non-responsive user bugs tonight as well
[09:33] <fabbione> zul: go ahead
[09:33] <fabbione> KILL THEM ALL!
[09:33] <zul> users or bugs?
[09:33] <fabbione> users of course
[09:33] <Mithrandir> both, preferably
[09:33] <fabbione> Mithrandir: why so much blood?
[09:33] <fabbione> users are enough
[09:33] <fabbione> unresponsive user on bug -> CLOSE
[09:34] <fabbione> i need to buy another THX
[09:34] <fabbione> after i moved mine in the living room i miss to listen to music in a decent way
[09:42] <fabbione> there.. i can't even type anymore...
 unresponsive user on bug -> CLOSE
 i need to buy another THX
[09:49] <jbailey> buy another user?
[09:49] <jbailey> Dude, you don't PAY for those.
[09:49] <jbailey> They come free. =0
[09:49] <jbailey> =)
[10:01] <lamont__> Mithrandir: who went tropical-fish on us?
[10:02] <Mithrandir> lamont__: http://www.raspberryginger.com/jbailey/weblog/entries/photos/hpim2587.jpg
[10:02] <jbailey> Mithrandir: eh... =)
[10:02] <jbailey> Mithrandir: I'm *not* adding a highlight on "blue".  That would be a bit too much. =)
[10:02] <lamont__> jbailey: you need more elmers glue.
[10:03] <jbailey> lamont__: Err.  Why?
[10:03] <Mithrandir> jbailey: looks nice, though
[10:03] <lamont__> jbailey: no spikes.  that's why. :-)
[10:03] <jbailey> Mithrandir: Thanks.  What's fun is that 1) There are 10 of them, but most are buried, so they only poke out occasionally.  2) They're all on the side and the back, so I still look respectable if I tie my hair back.
[10:04] <jbailey> lamont: *lol*
[10:04] <jbailey> lamont__: The funny part is that they're extensions, so they're basically epoxied onto other hair near the roots.
[10:04] <lamont__> heh
[10:05] <Mithrandir> jbailey: have you read citizen cyborg?  I think you may find it interesting.
[10:05] <Mithrandir> s/may/might/
[10:06] <jbailey> I haven't, I'll look for it.
[10:29] <lamont__> fabbione: still awake
[10:29] <lamont__> ?
[10:51] <fabbione> lamont__: not for more than 2 minutes
[10:51] <fabbione> i am crashing
[10:53] <fabbione>  /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory
[10:53] <fabbione> GREAT
[10:53] <fabbione> now what did reintroduce this...
[10:55] <fabbione> bah
[10:55] <fabbione> i am going to sleep
[10:55] <fabbione> good night
[11:00] <lamont__> g'night fabbione 
[11:15] <lamont__> jbailey: ping