--- Day changed

--- Log opened Thu Aug 21 00:00:01 2003
00:02 -!- anon [~anon@dsl-200-95-49-4.prodigy.net.mx] has quit [Remote host closed the connection]
00:04 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has joined #uml
00:04 -!- anon [~anon@dsl-200-95-49-4.prodigy.net.mx] has joined #uml
00:36 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has quit [Quit: Client Exiting]
01:44 -!- HIghoS [highos@highos.com] has joined #uml
02:05 -!- HIghoS [highos@highos.com] has quit [Quit: leaving]
02:06 -!- HIghoS [highos@highos.com] has joined #uml
02:07 < HIghoS> Quiet in here, eh? :P
02:09  * caker lurks in the darkness
02:09  * HIghoS grins.
04:13 -!- pirlouit [~peter@64.162.195.202] has quit [Quit: Time to frag!]
04:28 -!- G2_ [~G2@193.195.148.66] has joined #uml
04:30 < G2_> morning
04:47 -!- Michael2 [~chatzilla@algedi.dur.ac.uk] has joined #uml
04:48 -!- frediz [~frediz@ALyon-209-1-7-55.w80-13.abo.wanadoo.fr] has joined #uml
05:07 < frediz> anyone around here, with some knowledge in uml_switch ?
05:56 -!- spenne [~spenneb@ciscoms.dtag-ms.integrata.net] has joined #uml
06:15 -!- frediz [~frediz@ALyon-209-1-7-55.w80-13.abo.wanadoo.fr] has quit [Quit: crunch ]
06:16 -!- Jon_ [~jon@imhotep.hursley.ibm.com] has joined #uml
06:21 -!- Jon [~jon@imhotep.hursley.ibm.com] has quit [Ping timeout: 501 seconds]
06:21 -!- Jon_ is now known as Jon
06:56 -!- frediz [~frediz@ALyon-209-1-7-55.w80-13.abo.wanadoo.fr] has joined #uml
06:56 -!- frediz [~frediz@ALyon-209-1-7-55.w80-13.abo.wanadoo.fr] has quit [Client Quit]
06:57 -!- frediz [~frediz@ALyon-209-1-7-55.w80-13.abo.wanadoo.fr] has joined #uml
07:08 < G2_> mop e sorry
07:08 < G2_> nope sorry
07:11 < frediz> any uml_switch knowledgeable person
07:11 < frediz> please :)
08:59 -!- jax-work [~computer_@148.100.209.96] has joined #uml
09:27 -!- coryb [~cory@24.124.36.198] has quit [Quit: bbialb]
09:33 -!- jdike [~jdike@dhcp108.ists.dartmouth.edu] has joined #uml
09:34 < jdike> hi guys
09:35 < jax-work> how goes?
09:52 -!- anon [~anon@dsl-200-95-49-4.prodigy.net.mx] has quit [Read error: Connection reset by peer]
09:52 -!- anon [~anon@dsl-200-95-49-4.prodigy.net.mx] has joined #uml
09:52 < green> Hi Jeff!
09:53 < jdike> Hey Oleg
09:53 < jdike> green: I fixed the task_struct leak
09:53 < green> Great. What was the cause?
09:54 < jdike> green: the low-level switch_to not reassigning prev
09:54 < jdike> green: I think i386 doesn't either, but it works accidentally for them
09:55 < green> hm.
09:55 < green> Can you send me the patch?
09:57 < jdike> green: look at switch_to in arch/i386/system.h and see if you see prev being assigned
09:58 < frediz> hi, can uml_switch act as a router between 2 uml boxes from 2 different networks ?
09:58 < jdike> green: it ends up in %eax because __switch_to returns it, and that ends up being the return value from context_switch because switch_to is the last thing it does
10:00 < jdike> green: @namesys.com?
10:01 < green> yup
10:01 < jdike> green: On its way
10:02 < green> ok, thanks
10:02 < jdike> frediz: the switch just forwards ethernet frames, it doesn't know or care what IP addresses are involved
10:02 < frediz> ok
10:03 < jdike> frediz: or even if IP itself is involved
10:03 < frediz> is this what I should follow ? http://www.lathspell.de/linux/uml/
10:05 < green> jdike: can you please look up what uis the usual 2.6 '-DSTART=' value?
10:06 < jdike> green: normally 0xa0000000
10:07 < jdike> green: same on 2.6 as 2.4
10:07 < green> ok. 2.6.0-test3 from yesterdays bk broken the computations
10:08 < jdike> green: oops, can you tell what?
10:08 < green> /bin/sh: -c: line 1: syntax error near unexpected token `)'
10:08 < green> /bin/sh: -c: line 1: `set -e; echo '  CPP     arch/um/kernel/vmlinux.lds.s'; gcc -E -Wp,-MD,arch/um/kernel/.vmlinux.lds.s.d -D__ASSEMBLY__ -D__KERNEL__ -Iinclude -D__ASSEMBLY__ -nostdinc -iwithprefix include   -Ui386 -DSTART= * 0x20000000))) 
10:08 < green> so $TOP_ADDR seems to be empty now
10:09 < green> or smth like that
10:10 < jdike> green: that comes from Makefile-i386
10:11 < jdike> green: from here - include $(ARCH_DIR)/Makefile-$(SUBARCH)
10:11 < green> yup. Now I see that SIZE is now defined as ((0 + 1) * 0x20000000)
10:16 -!- coryb [~cory@easy-mac.ittc.ku.edu] has joined #uml
10:18 < green> ok, I see. there sould be extra $$ in arch/um/Makefile in SIZE = line
10:20 < jdike> green: exactly where?
10:20 < green> SIZE = $$(($(CONFIG_NEST_LEVEL) + $(CONFIG_KERNEL_HALF_GIGS)) * 0x20000000)
10:20 < green> the leading $$ were missing in my tree for whatever reason
10:20 -!- gump [user@81.5.136.90] has joined #uml
10:20 < green> in arch/um/Makefile
10:21 < jdike> green: They're missing in my tree too
10:21 < jdike> green: Because they're not supposed to be there
10:21 < green> why?
10:22 < jdike> green: because the actual calculation happens here : -DSTART=$$(($(TOP_ADDR) - $(SIZE)))
10:22 < green> but now calculation does not happen
10:23 < green> well, it happens, but not fully
10:23 < jdike> green: that expands to $((0xc0000000 - (0 + 1) * 0x20000000))
10:23 < jdike> green: or it should
10:23 < green> yes, but as I shown, I get -DSTART= * 0x20000000)))
10:23 < jdike> green: and that should make the shell calculate the actual number
10:23 < green> this strted after I did pull on tuesday
10:25 < jdike> green: that means '($(CONFIG_NEST_LEVEL) + $(CONFIG_KERNEL_HALF_GIGS))' expands to empty somehow
10:25 < green> yup
10:25 < jdike> green: and so does '$(TOP_ADDR) -'
10:26 < jdike> green: I could see the CONFIG_* expanding to empty with a botched config
10:26 < green> but if I put $(TOP_ADDR) and $(SIZE) separately on that line, I see correct stuff
10:26 < green> .config is right
10:26 < green> green@angband:~/bk_work/reiser4-linux-2.5> grep CONFIG_NEST_LEVEL .config
10:26 < green> CONFIG_NEST_LEVEL=0
10:26 < green> green@angband:~/bk_work/reiser4-linux-2.5> grep CONFIG_KERNEL_HALF_GIGS .config
10:26 < green> CONFIG_KERNEL_HALF_GIGS=1
10:26 < jdike> green: but the punctuation (+/-) should definitely still be there
10:27 -!- G2_ [~G2@193.195.148.66] has quit [Quit: Client exiting]
10:27  * green finishes building with those $$ added to see if the resulting kernel will boot at all
10:28 < jdike> green: is your /bin/sh bash?
10:28 < green> yes it is
10:29 < green> and it worked before I did that pull, anyway
10:30 < green> hm, it boots
10:46 < green> jdike: yeah, the leak is fixed. Great.
10:46 < green> thank you
10:47 < jdike> green: you figured out where it was happening
10:47 < jdike> green: just not exactly why :-)
10:47 < green> ;)
11:19 -!- rob [~rob@nat.office.legend.net.uk] has joined #uml
11:19  * rob waves
11:22 -!- mdz [~mdz@216.15.124.77] has quit [uranium.oftc.net jupiter.oftc.net]
11:22 -!- wojci [~wojci@62.107.97.240] has quit [uranium.oftc.net jupiter.oftc.net]
11:22 -!- green [green@217.76.32.60] has quit [uranium.oftc.net jupiter.oftc.net]
11:22 -!- BB [~chris@216.127.67.147] has quit [uranium.oftc.net jupiter.oftc.net]
11:22 -!- mdz [~mdz@216.15.124.77] has joined #uml
11:22 -!- wojci [~wojci@62.107.97.240] has joined #uml
11:22 -!- green [green@217.76.32.60] has joined #uml
11:22 -!- BB [~chris@216.127.67.147] has joined #uml
11:35 -!- anon [~anon@dsl-200-95-49-4.prodigy.net.mx] has quit [Quit: Client Exiting]
11:35 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has joined #uml
11:46 -!- spenne [~spenneb@ciscoms.dtag-ms.integrata.net] has quit [Remote host closed the connection]
11:57 -!- pirlouit [~peter@duvel.drunkcoders.com] has joined #uml
11:59 -!- Michael2 [~chatzilla@algedi.dur.ac.uk] has quit []
12:33  * jdike uses ubd_mmap to trash a filesystem
12:43 < rob> I've found a bug with 2.6.0-test3-bk5 as a host I think
12:52 < jdike> rob: is it a secret?
12:52 < frediz> :)
12:55 < frediz> seems to be
12:58 < green> jdike: ubd_mmap? wow! ;)
12:58 < jdike> green: yeah
12:59 < jdike> green: that's what I said when I noticed my filesystem didn't exist any more
12:59 < green> cool, put the code in some public place when you decide to go to sleep or smth like that, please
12:59 < jdike> green: it seems you must be careful to unmap the page when it gets freed
13:00 < green> sure
13:00 < jdike> green: otherwise it gets reallocated and random crap gets written to it :-)
13:00 < green> yup. I suspected something like that from the very beginning
13:00 < green> actually you may unmap it at reallocation time
13:00 < green> but it is safer to unmap at freeing time
13:01 < jdike> green: yeah
13:01 < jdike> green: you don't know whether the allocator is going to store bookkeeping information in it
13:02 < green> well, I think even allocator itself does some magic prior to using the page
13:02 < jdike> green: like what?
13:03 < green> I do not know. but it must allocate if first, I think. I do not have a proof for that, though. But I will be surprised if it does not
13:04  * jdike totally didn't understand that
13:04 < green> hehe. I can repeat taht in russian to make more sence ;)
13:05 < jdike> green: heh, it couldn't be any worse
13:06  * green starts to think where to send the resume
13:07  * jdike prepares a scratch filesystem
13:07 -!- Aetherios [~jeff@216.34.207.253] has joined #uml
13:09 < jdike> green: BTW, UML does a test access of a page as it comes out of the allocator
13:09 < jdike> green: to see if it is really backed on the host
13:09 < green> cool.
13:10 < jdike> green: otherwise random parts of the kernel get SIGBUS when tmpfs runs out of room
13:10 < green> the only problem remains that have no solution  is that in-memory page modifying will modify that area "on-disk" instantly
13:10 < jdike> green: better to get the SIGBUS in a known controllable place
13:11 < green> jdike: well, I think you can just handle sigbus instead. ;)
13:11 < jdike> green: why is that a problem?
13:11 < jdike> green: can that mess up filesystem write ordering?
13:11 < green> Well, as we discussed that already, at least reiserfs sometimes modifies a page and later decides it does not want to write changes to disk. That should not be big problem, though
13:12 < green> write ordering is a question, though
13:12 < green> you need to implement barrier stuff, once the patch is in vanilla kernel, though.
13:13 < jdike> green: hmmm
13:47 -!- mistral [mistral@jstevenson.plus.com] has joined #uml
13:53 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has quit [Remote host closed the connection]
13:55 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has joined #uml
14:03 -!- mistral [mistral@jstevenson.plus.com] has quit [Ping timeout: 501 seconds]
14:39 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has quit [Remote host closed the connection]
14:40 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has joined #uml
14:41 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has quit [Remote host closed the connection]
14:45 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has joined #uml
14:46 < jdike> ubd_mmap is pissing me off
14:48 -!- Umler [~anon@dsl-200-95-49-4.prodigy.net.mx] has quit [Remote host closed the connection]
14:49 -!- Umler [~anon@200.95.49.4] has joined #uml
15:00 < jdike> hmmm, it started working
15:01 < jdike> it seems OK, ro
15:02 < jdike> with rw it trashes filesystems
15:10 < green> still some progress ;)
15:34 -!- silug [~steve@64.240.156.225] has joined #uml
15:37  * jdike squashes another bug
15:38 < BB> with legs or the soft sort
15:38 < jdike> the soft sort
15:39 < BB> ;)
15:39 < jdike> grrr
15:39 < jdike> I built the wrong directory
15:39 < jdike> and wondered why the bug was still there
16:00 -!- jax-work [~computer_@148.100.209.96] has quit [Quit: going home]
16:05 < frediz> %)
16:06 < BB> well i've screwed my m8's server 3 times so far trying to get bridging working 
16:22 -!- peace [~katta@fenny.via.cornell.edu] has joined #uml
16:23 -!- peace is now known as shanti
16:23 < shanti> jdike: hello
16:24 < jdike> hi shanti
16:24 < jdike> I see you're on the job now
16:24 < shanti> jdike: Have you heard of revario.com in Tampa
16:24 < shanti> jdike: yes, I joined here on July 21st
16:26 < jdike> shanti: I have heard of them
16:27 < jdike> shanti: what do you know about them?
16:27 < shanti> 2 days ago they were talking to me about porting some application to Intel arch
16:28 < shanti> more specifically uml related stuff..so they were interested in hiring me
16:28 < jdike> shanti: what sort of app?
16:29 < shanti> jdike: I do not know the specifics now, but they mentioned about their virtual blade server
16:29 < jdike> shanti: interesting
16:29 < jdike> shanti: they are doing uml stuff, which is how I heard about them
16:30 < shanti> They told me that they are planning to have in their advisory committee
16:30 < shanti> have you in their advisory committee
16:30 < jdike> shanti: are you going to work for them?
16:30 < caker> http://revario.com/images/VirtualBladeArchitectureMas.gif
16:30 < jdike> shanti: that hasn't been fully decided yet
16:31 < caker> looks like they got UML running on a lot of arch's :-)
16:31 < jdike> shanti: hehe
16:31 < shanti> jdike: nothing is decided till now
16:31 < jdike> oops, I was laughing at caker :-)
16:32 < shanti> jdike: that's what I thought so :)
16:32 < jdike> shanti: you'd have to leave Cornell, presumably
16:33 < shanti> jdike: yes and people here will definitely be not happy
16:41 < silug> jdike: what do you think it might take to make it worth your time to do a skas patch for a recent redhat kernel (2.4.20-20.x)?
16:41 < silug> cheap hardware?  cash?  :)
16:41 < caker> silug: have you considered the skas module?
16:47 < jdike> silug: Haven't really thought about it
16:47 < jdike> silug: RH8 was easy, RH9 is apparently trickier
16:49  * green gets annoyed by this damn sobig.f virus, why do they send me all this crap? ;)
16:50  * caker has encountered many a full mailbox while sending legit emails ...
16:50 < BB> I'm annoyed by the number of ISPs that cant cope because of it
16:50 < green> hehe.
16:50  * green looks for a pattern to block those damn email on my relay. I figured out how to block ~ half of the traffic, but this is still annoying
16:51 < jdike> green: I'd think you could do it with subject matching
16:51 < jdike> green: plus they're all in the neighborhood of 100K
16:51 < green> well, this is too complex, I want single rule or smth like that
16:52 < caker> http://www.sarc.com/avcenter/venc/data/w32.sobig.f@mm.html
16:52  * green figured out that all mails from west (negative timezome) have double minus in timezone description, this is easy to filter.
16:52 < BB> heh
16:53 < green> jdike: this worm seems to like to send mails to Nikita using your address as source ;)
16:53  * green mostly get forget mail claiming to be from suse for whatever reason ;)
16:53 < jdike> green: hehe
17:13 < BB> hrm this is weird.. i add 2 tun's to a bridge allong with eth0, and the whole network is toast... i type "ifconfig" as root with no params and it all comes back to life.. anyone any ideas on how/why or do i just put "ifconfig" at the end of the script ;)
17:17 < BB> I think i need more stella
17:18 < jdike> BB: stella == a foodstuff?
17:18 < BB> "stella artois"
17:19 < BB> it was "on offer" beer at the local shop
17:20 < BB> this is a truely weird thing i recon
17:29 -!- mortck [~spam@217.226.85.104] has joined #uml
17:30 < mortck> re all
17:30 < BB> re
17:30 < mortck> i am running uml on a debian machine
17:30 < mortck> works quite well but the console inside screen hangs sometimes
17:31 < mortck> i can still ssh the uml and continue my work...
17:31 < mortck> any idea what might be causing this?
17:32 < jdike> mortck: what version of UML?
17:32  * mortck fires up his uml process
17:34 < mortck> 2.4.18-17um
17:34  * jdike tries to remember how many years old that is
17:34 < BB> lmao
17:36 < mortck> i guess 0.0.2...
17:36 < mortck> ;)
17:36 < mortck> well, so i guess it should be fixed with a newer version then...
17:37 < mortck> second question: i came to the conclusion that .cow files cannot grow bigger than the base file. is that true?
17:42 < BB> filesystem wise in the UML no, but in used space it could be slightly larger ... (is my guess ;)
17:42 < mortck> hmm, my problem was that i had a base image for debian, which was around 60mb
17:43 < mortck> i startet uml with a cow file
17:43 < mortck> and the filesystem inside the uml was limited to 60mb
17:43 < BB> I'd merge them back into one fill (uml_moo) and make a larger rootfs
17:43 < BB> fill=file
17:44 < mortck> bb isn't that a little bit too much work? i would need to create a different root_fs, each time i install a new machine that might need more or less space
17:46 < mortck> aka new uml instance...
17:46 < BB> well if you had a larger backing file, theres nothing that says you need to use all the space on the cow files since they are sparse it will take up little extra space
17:47 < mortck> i agree, and on the bigger instances? i guess i would need to enlarge the sparse root_fs then...
17:48 < BB> thats how i would do it
17:48 < mortck> i guess it would be a little more effective to add an option to "linux" which would limit the size of the cow file...
17:49 < BB> that might be a bad idea... as it has the possibility to corrupt the fs i would imagine if it is cut off in its prime
17:49 < mortck> might be, but you could have one root_fs and many different sized cow_fses then
17:50 < mortck> just with one parameter like cowfssize=1000M
17:50 < mortck> no need to resize root_fses then
17:50 < BB> and when it gets to that size it just trashes the filesystem?
17:50 < mortck> well, disk full?
17:51 < mortck> same happens today when the amount of data reaches the size of the root_fs
17:51 < BB> if you somehow limit the size of the cow file, theres no guarantee it wont be at a critical point altering the fs and toast it
17:52 < mortck> isn't the size of the cow file already limited by the root_fs?
17:52 < BB> yes give or take a few K i would say (depending on the backing file size)
17:53 < mortck> and when there is no more free space available the kernel cannot write more into the cow file, true?
17:54 < BB> but it knows how big the filesystem is, thats not hte same as making the requests fail once its over a certain size
17:55 < mortck> true, but i reads the size of the root_fs and this is the max size of the cow file (+/- some K). what would be so different in setting the max size by a parameter?
17:56 < mortck> you could still store in the cow_fs file header what its max size is...
17:56 < mortck> and you could easily grow it, but not make if smaller (which would be okay for me)
17:57 < BB> mortck then it would have to know about the filesystem thats running ontop of it to be able to modify it enough to convince the OS it was another size
17:57 < mortck> well, okay. skip that with the on the fly resizing.
17:58 < mortck> just being able to tell once the max size of the cow file would be wonderfull...
17:58 < mortck> it could still be merged with moo
17:58 < mortck> i just want to keep the administrative overhead low...
17:59 < BB> I'll just say good luck limiting it without trashing the filesystem one way or another... it would surely be easier to have a fixed size / and a different size /home or something if you wanted different sized instances
18:00 < mortck> BB surely also a way to go
18:01 < mortck> but would result in even more files ;)
18:01 < BB> yes, but one file for backing "OS" and one for the home.. isnt much for me ;)
18:02 < mortck> depends on how many instances you run ;)
18:02 -!- jdike [~jdike@dhcp108.ists.dartmouth.edu] has quit [Read error: Connection reset by peer]
18:02 < BB> i dunno the way i see it once its been setup it doesnt matter, and a dd/mke2fs isnt much trouble to script when you make a new instance
18:03 < mortck> true...
18:03 < mortck> but still more complicated the "linux ubd0=... cowmaxsize=XXX" ;)
18:03 < mortck> s/the/then/
18:04 < mortck> so the cow file is from the start the same size as the root_fs with sparse?
18:04 < BB> its the same "size" but doesnt use all of the space up it has holes in it
18:04 < mortck> japp
18:04 < mortck> as the root_fs does
18:06 -!- frediz [~frediz@ALyon-209-1-7-55.w80-13.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
18:09 -!- frediz [~frediz@81.51.112.45] has joined #uml
18:19 -!- mortck [~spam@217.226.85.104] has quit [Quit: Client Exiting]
18:22 -!- Kul [~Kul@82-34-59-46.cable.ubr01.gill.blueyonder.co.uk] has joined #uml
18:31 -!- frediz [~frediz@81.51.112.45] has quit [Quit: Pw3t]
18:37 -!- shanti [~katta@fenny.via.cornell.edu] has quit [Quit: Client Exiting]
18:49 -!- coryb [~cory@easy-mac.ittc.ku.edu] has quit [Quit: buh bye]
19:14 -!- shak [~shak@pc1-hudd2-6-cust166.hudd.cable.ntl.com] has joined #uml
19:14 < shak> hi
19:14 < shak> anyone alive?
19:21 < Getty> no
19:21  * caker drops to the floor
19:56 < wojci> shak: Define alive :P
20:05 < Kul> he means not like my server which is no longer alive after setting up networking for the forthcomming UML's :-|
20:17 < Idcmp> kul: futzing with brctl? :)
20:17 < Idcmp> whenever i futz with networking on a remote box, i tell it shutdown in 20 minutes.
20:18 < Kul> we did ...but it dies anyway and never reboots :(
20:18 < Idcmp> doh
20:18 < Kul> needs finger to reboot
20:43 < Idcmp> could someone help me with my bridge?
21:18 -!- bradley [~bradley@202.83.81.124] has joined #uml
21:21 < bradley> greets to all
21:22 < Idcmp> hey!  ever played with brctl?
21:23 < bradley> no, whats it do?
21:23 < Idcmp> creates headaches for idcmps
21:24 < bradley> ? whats an idcmps
21:24 < Idcmp> also creates ethernet bridges
21:25 < bradley> ..ok like a raw ethernet packet router
21:25 < bradley> you know of any startup/shutdown init scripts for uml?
21:27 < Idcmp> everyone writes their own :)
21:27 < bradley> i can figure the startup bit, but how to shut it down? hints?
21:27 < Idcmp> uml_mconsole
21:28 < bradley> it has command line options for that?
21:29 < Idcmp> yup
21:29 < Kul> http://user-mode-linux.sourceforge.net/mconsole.html
21:29 < bradley> cheers!
21:42 < Idcmp> does uml_switch actually work?
21:43 < Idcmp> (tjener/.uml) config eth1=daemon
21:43 < Idcmp> ERR
21:50 < bradley> any pointers on running UML as a jail?
22:07 < Idcmp> how so?
22:11 < Idcmp> well this is new.. i just mucked up the host networking but i can get on the umls fine
22:15 -!- Kul [~Kul@82-34-59-46.cable.ubr01.gill.blueyonder.co.uk] has quit [Quit: http://akakul.co.uk/ & http://camelbackup.com/ & http://www.cameldial.co.uk/]
22:29 -!- Idcmp [idcmp@69.41.229.181] has quit [Read error: Connection reset by peer]
22:29 -!- ElectricElf [~david@elf.noc.oftc.net] has quit [Ping timeout: 240 seconds]
23:04 < bradley> hey there
23:54 -!- bradley [~bradley@202.83.81.124] has quit [Quit: using sirc version 2.211+KSIRC/1.2.4]
--- Log closed Fri Aug 22 00:00:00 2003