--- Day changed

--- Log opened Sun May 15 23:59:01 2005
23:59 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
00:11 -!- b2s [~b2s@66.111.53.150] has joined #xen
00:27 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
00:32 -!- b2s [~b2s@66.111.53.150] has joined #xen
01:02 -!- lilo_ is now known as lilo
01:12 -!- muli [~muli@nesher3.haifa.il.ibm.com] has quit [Ping timeout: 480 seconds]
01:45 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
01:51 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
02:00 -!- Squink [~purple@S010600131077a67e.vc.shawcable.net] has quit [Read error: Connection reset by peer]
02:15 -!- muli [~muli@nesher3.haifa.il.ibm.com] has joined #xen
02:20 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
02:21 -!- b2s [~b2s@66.111.53.150] has joined #xen
02:48 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
02:56 -!- muli [~muli@nesher3.haifa.il.ibm.com] has quit [Read error: Connection reset by peer]
03:09 -!- b2s [~b2s@66.111.53.150] has joined #xen
03:30 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [Ping timeout: 480 seconds]
04:31 -!- nub [~nub@lez.mag.keio.ac.jp] has joined #xen
04:38 -!- athomas [~athomas@ppp-0-106.lond-a-1.access.uk.tiscali.com] has joined #xen
04:43 < mael> hi
05:19 -!- nub [~nub@lez.mag.keio.ac.jp] has quit [Remote host closed the connection]
06:16 -!- jesse_ [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
06:17 -!- jesse_ is now known as wenchien
07:01 -!- crisen [~crisen@spank.terdmonk.com] has quit [Ping timeout: 480 seconds]
07:27 -!- riel [~riel@imladris.surriel.com] has quit [Read error: Operation timed out]
07:34 -!- riel [~riel@imladris.surriel.com] has joined #xen
08:01 -!- DEac- [~deac@xdsl-213-196-202-130.netcologne.de] has quit [Ping timeout: 480 seconds]
08:15 -!- DEac- [~deac@xdsl-213-168-105-91.netcologne.de] has joined #xen
08:31 -!- cfreak [cfreak@dsl-084-056-105-030.arcor-ip.net] has joined #xen
08:46 -!- riel is now known as surriel
09:07 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
09:11 -!- jimix [~jimix@yktgi01e0-s4.watson.ibm.com] has joined #xen
09:21 -!- jimix [~jimix@yktgi01e0-s4.watson.ibm.com] has quit [Quit: jimix]
09:21 -!- jimix [~jimix@yktgi01e0-s4.watson.ibm.com] has joined #xen
09:22 -!- jimix [~jimix@yktgi01e0-s4.watson.ibm.com] has quit [Remote host closed the connection]
09:38 -!- unriel is now known as riel
09:41 -!- jimix [~jimix@yktgi01e0-s4.watson.ibm.com] has joined #xen
09:57 -!- rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
10:08 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
10:58 -!- tessier [~treed@203.210.212.17] has joined #xen
11:00 -!- Robot101 [robot101@light.bluelinux.co.uk] has quit [Quit: kthxbye]
11:43 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
11:56 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
12:12 -!- bunoc [~bun@YahooBB219206220072.bbtec.net] has joined #xen
12:13 < bunoc> hello. i am using bk to pull the -unstable. in bk, is there anyway to find exactly when a specific file was updated in the repo?
12:14 < bunoc> (i am not used to bk)
12:14 < hollis> bk revtool <file>
12:16 < bunoc> hollis: great, but it seems that only shows the day that file is committed, not when it was push in?
12:17 < bunoc> how can we know when that file was pushed in?
12:18 < hollis> what do you mean "pushed in"? you mean when that changeset made it to the "main" repository?
12:18 < hollis> I mean, it was committed when it was committed
12:18 < knewt> i'd guess he means when it got merged into the -unstable repo, yep
12:19 < bunoc> knewt: yes, that is it
12:19 < bunoc> i look at the changeset. it seems that the code are pulled from many trees
12:20 < bunoc> but that only shows the time when it was first committed in the original tree, not when it was merged into -unstable?
12:21 < bunoc> it seems there is no such information stored in the tree ?
12:21 < Tv> not really, no
12:21 < Tv> what you can do is look for a merge changeset
12:21 < tessier> Should I be running stable or unstable if I actually want to try to use Xen to get some work done?
12:22 < Tv> but clean merges don't generate those
12:22 < bunoc> Tv: where is the merge changeset?
12:22 < bunoc> at xen.bkbits.net?
12:22 < Tv> tags will tell the last release before it got merged
12:22 < bunoc> i looked, but the information is not detailed enough
12:22 < tessier> I know traditional wisdom says stable but sometimes with open source projects that advance very rapidly the latest cvs/svn/bk pull can be more stable than the latest "stable" build.
12:22 < Tv> bunoc: where the rest the changesets are..
12:22 < hollis> tessier: use stable
12:22 < knewt> bunoc: right now -testing is the best bet for stability
12:23 < hollis> unstable doesn't even compile quite frequently
12:23 < bunoc> knewt: i am not askng about stable ;). that is tessier asked 
12:23 < tessier> hollis: ok
12:24 < knewt> bunoc: whoops. not paying enough attention *g*
12:24 < bunoc> i am making a file-based image. is there anyway to make partitions into a file?
12:24 < bunoc> normally we just mkfs <file>, then there is no partitions inside that file
12:25 < Tv> bunoc: so use multiple files
12:25 -!- matta [~matta@69.93.28.254] has joined #xen
12:25 < bunoc> Tv: yes, just wonder if it is possible to do that or not
12:25 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
12:25 < Tv> not just possible, better than trying to kludge partitions in loopbacks
12:25 < Tv> though lvm is the best thing since sliced bread
12:26 < knewt> bunoc: which file were you looking at? just want to try something
12:26 < Tv> I configured one box so it can boot either with xen, with the "main" host in domU, or the main host natively.
12:26 < Tv> That rocks.
12:27 < bunoc> knewt: for example Config.mk
12:28 < bunoc> Tv: what is kludge partition?
12:29 < Tv> bunoc: verb, not noun
12:29 < Tv> bunoc: also, dict(1)
12:29 < hollis> bunoc: it's a real PITA to loopback mount a filesystem from a partition in a file
12:30 < bunoc> kludge? never seen that word before. also cannot look it up in my dictionary
12:31 < bunoc> (sorry, english is not my native language)
12:32 < knewt> bunoc: ok, you can use the browser on xen.bkbits.net. find the file you want to look at and you can see which changesets the file has been involved in on -unstable
12:37 < bunoc> knewt: yes that works, but same result as "bk revtool <file>"
12:38 < knewt> bunoc: you're looking at the changeset list, not the revision list, for the file, right? they give different info
12:39 < bunoc> knewt: sorry if i dont express my idea clearly. i am not used to bk. my question is: when a specific file was pushed in -unstable.
12:43 < knewt> for instance, for Config.mk:
12:43 < knewt> revisions: 1.1 / 20 march --  1.2 / 2 april --  1.3 / 2 april --  1.4 / 15 april
12:43 < knewt> changesets: 1.1236.1.105 / 22 march --  1.236.1.199 / 2 april --  1.236.1.200 / 2 april --  1.1305 / 15 april
12:44 < knewt> so the first revision was made on the 20th march, but didn't make it to -unstable until 2 days later
12:44 < knewt> i think that's right, anyway
12:50 -!- bunoc2 [~bunoc2@YahooBB219206220072.bbtec.net] has joined #xen
12:51 < bunoc2> knewt, how can we know that 1.1 rev corresponds to cset 1.1236.1.205?
12:52 < bunoc2> i dont understand where this number 1.1236.1.205 is from? how bk created that number?
12:55 -!- athomas [~athomas@ppp-0-106.lond-a-1.access.uk.tiscali.com] has quit [Quit: Leaving]
12:58 -!- bunoc [~bun@YahooBB219206220072.bbtec.net] has quit [Read error: Operation timed out]
13:23 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
13:47 < hollis> bunoc2: that's the changeset number. bk invented it
13:47 < hollis> bunoc2: you can use bk r2c and c2r to convert between the two
14:03 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Leaving]
14:04 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
14:20 < tessier> It is possible to boot the xen hypervisor and domain0 under vmware?
14:28 < riel> it should be, in theory
14:28 < riel> but it can't be efficient
14:28 < riel> vmware wants the same address space as the xen hypervisor ;)
14:29 < yosh> tessier: are you then going to run uml in domainU ?
14:29 < yosh> ;)
14:29 < tessier> A friend of mine said he booted xen under vmware.
14:29 < tessier> I didn't believe him.
14:29 < tessier> I thought it would choke for sure as soon as xen tried to grab ring 0
14:30 < tessier> Since vmware already had it.
14:30 < aliguori> tessier: no, vmware emulates a ring 0
14:30 < aliguori> that should be fine
14:30 < tessier> ah
14:30 < aliguori> i'd imagine the oddness would be in xen using ring 1
14:30 < tessier> That actually makes sense now.
14:31 < aliguori> vmware might support ring 1 operations but i imagine it's not tested all that well
14:31 < aliguori> i can't think of another os that uses ring 1
14:34 < hollis> I hear OS/2 did :)
14:34 < aliguori> hehe, why doesn't that surprise me :-)
14:34 < aliguori> perhaps that's why it's so hard to get OS/2 running in vmware or virtualpc
14:36 -!- mael_ [~Mael@kali.tirnamban.org] has joined #xen
14:36 < tessier> I didn't realize PC's had 4 separate rings
14:36 < tessier> Is that an artifact of using two bits to describe them or something like that?
14:36 < mael_> hi aliguori 
14:37 < aliguori> mael_: howdy
14:37 < hollis> tessier: x86 has four rings, and it's intentional
14:37 < mael_> are you over-loaded today?
14:38 < aliguori> tessier: it's because it was required to compete for DoD contracts..
14:38 < aliguori> mael_: what's up?
14:38 < tessier> Funny how nobody really uses all 4. 
14:38 < hollis> aliguori: are you sure? I'm willing to bet there are many non-x86 processors in use at the DoD
14:38 -!- monrad [~monrad@0x535b06c0.ronxx3.adsl-dhcp.tele.dk] has joined #xen
14:38 < tessier> hollis: All with at least 4 levels of protection?
14:39 < mael_> well I was about to compile uClibc and busybox
14:39 < hollis> tessier: no, I haven't heard of another processor with such a design (though I'm sure they exist)
14:39 < hollis> tessier: that's my point
14:39 < aliguori> hollis: the way it was explained to me, is that when they were designing the chip, one of the requirements was to be able to have processor separation so you could have like top secret, classified, confidential, and unclassified...
14:40 < aliguori> but there might be a considerable amount of myths about the 4 rings at this point :-)
14:40 < hollis> aliguori: yeah, I don't buy it
14:40 < aliguori> this was from one of the intel guys when he came to lecture in one of my classes (actually, i think it was Arun..)
14:40 < hollis> hm, ok...
14:41 < tessier> Was he the Lord Of The Rings?
14:42 < aliguori> we also read a paper explaining why intel uses little endian :-)
14:42  * hollis winces
14:42 < hollis> aliguori: and what did that say?
14:42 < aliguori> it goes way back to the days when intel made calculuator processors
14:42 < mael_> has any of you a practical experience of virtuozzo?
14:42 < mael_> this stuff seems impressive
14:42 < aliguori> using that format happened to save some wiring for doing adds or something
14:43 < hollis> aliguori: one of the Research guys was there when IBM/Intel were designing the PC, and he blames himself for not talking them out of it
14:43 < hollis> he said it was simply due to bit numbering. calculators were not mentioned ;)
14:49 < aliguori> ah, here's the paper
14:49 < aliguori> http://inventors.about.com/gi/dynamic/offsite.htm?site=http://www.dotpoint.com/xnumber/Microcomputer%5Finvention.htm
14:49 < aliguori> it was the JUMP instruction, not the add
14:51 < hollis> ha, even he says "regrettably" :)
14:51 < aliguori> yeah, that's what's always stuck out to me about that paper :-)
14:51 < aliguori> it's an interesting paper...
14:51  * hollis nominates "The lack of [endian] standardization has been a problem in the industry." for an Understatement Award
14:51 < aliguori> hehe
14:52 < aliguori> it really surprised me that the microprocessor pretty much grew out of the fact that intel was a memory company and wanted to expand
14:52 < aliguori> it was sort of like dumb luck
15:04 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
15:05  * riel suspects that having 4 security rings is pretty common
15:05 < riel> after all, you need 4 rings to run VMS
15:06 < riel> and VMS has run on a few different architectures ...
15:12 < murble> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/win 14
15:13 < murble> bugger
15:23 < tessier> aliguori: MS too was in the right place at the right time...
15:24 < tessier> riel: What architectures does vms run on besides Alpha and whatever the original processor was?
15:24 < hollis> apparently Itanium
15:25 < hollis> oops I meant "Itanic" ;)
15:27 < tessier> Itanic is definitely the common name for it. You can't read a trade rag about it without them cracking that one.
15:27 < tessier> I have never actually seen a box running an Itanium nor have I seen Itanium chips advertised anywhere I shop.
15:27 < tessier> Itanium seems to be Unobtanium
15:28 < riel> tessier: VAX, MIPS, Alpha and Itanic
15:28 < tessier> I am amazed a company can survive such a failure. But I guess Intel is a pretty darn big company.
15:28 < riel> Intel will survive it just fine, I'm more worried about HP
15:28 < tessier> MIPS and Itanic eh? Didn't know that. What processor did VAX originally run on? Was it a 68k?
15:29 < riel> tessier: VAX is a processor
15:29 < riel> it is _the_ original 32 bit processor ;)
15:29 < mael_> tessier:  well just because you don't find itanium at next door reseller doesn't mean it has no market
15:29 < tessier> Oh, it is a processor itself. I see. I was thinking 68k didn't have protection levels. So that makes sense.
15:29 < mael_> thought it seems a pretty small one for sure :)
15:29 < tessier> mael: True but that means it is a very niche market which means very expensive chip which traditionally don't do well for the manufacturer.
15:30 < mael_> hmm I don't like this kind of reasonning very much
15:30 < tessier> I missed the whole vax generation by a few years. I had a couple of VMS accounts but never really learned how to use them. Never had administrator rights on a vax/vms box.
15:30 < tessier> Once I found un*x/Linux VMS seemed to painful anyhow so I never looked back.
15:30 < mael_> this is the kind of stuff that can lead to wintel domination without choice
15:31 < mael_> (MH2C)
15:34 < riel> HP appears to still have 95% of the Itanium market, btw
15:36  * tessier is amazed that we finally have dual core chips
16:18 < mael_> aliguori:  yet another compile error
16:18 < mael_> (and I don't use the daily snapshots)
16:18 < aliguori> mael_: compiling what?
16:18 < mael_> uClibC/busybox using buildroot
16:19 < aliguori> oh, that's odd
16:19 < aliguori> what compiler?
16:19 < mael_> I'm not yet able to compile vmtools
16:19 < aliguori> well....
16:19 < aliguori> vm-tools is a problem right now
16:19 < aliguori> xen-unstable has gone through massive changes
16:19 < mael_> hehe I guess you're in trouble adapting it to rusty changes
16:19 < aliguori> no
16:19 < aliguori> it's not rusty's changes actually
16:19 < mael_> gcc 3.3.5
16:20 < aliguori> but mike wray has a different tree
16:20 < mael_> ah?
16:20 < aliguori> that we're currently working out of
16:20 < aliguori> yeah, it's linked off the wiki
16:20 < aliguori> and i haven't updated a public version of vm-tools for it.. we're in a bit of a pickle
16:20 < aliguori> it'll probably stay that way until 3.0-testing is released
16:20 < aliguori> b/c things are just changing too rapidly
16:21 < mael_> yeah I do think this is a general xen problem
16:21  * mael_ feels being on a moving ground all the time
16:21 < mael_> every time I think I grasp so idea, it's obsolete
16:21 < mael_> -so+some
16:25 -!- knewt [~jmb@zeus.pimb.org] has quit [Remote host closed the connection]
16:25 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
16:31 -!- yarihm [~yarihm@217-162-114-216.dclient.hispeed.ch] has quit [Quit: Leaving]
16:32 < riel> ahhh, Makefile is screwed up in -rc4
16:32 < riel> that's why things weren't compiling any more
16:33 < mael_> :)
16:33 < mael_> that's a good news :)
16:33 < mael_> you're not the one responsible for that mess, are you?
16:34 < riel> nope
16:34 < riel> just ran into it
16:34 < mael_> then that's a good news :)
16:34 < mael_> now you can do something else while it's fixed :)
16:34 < mael_> s/while/until/
16:36 < riel> no, FC4 freeze is soon ;)
16:36 < riel> I fixed it instead
16:36 < mael_> hehe
16:45 < mael_> riel:  will Xen be integrated in FC4?
16:46 < mael_> I mean officialy
16:46 < mael_> +l
16:47 < riel> what do you mean by "officially" ?
16:48 < mael_> Will Xen packages be integrated in FC4 official package pool?
16:48 < mael_> (or what is equivalent to Debian package pool in FC world)
16:49 < mael_> I know official support is not a meaningful stuff for FC as this is mainly the "test" distro for RH
16:50 < mael_> but if the package is "mainstream" in FC distro and FC kernels supporting Xen are realeased, I guess this is an official package
16:54 -!- jimix [~jimix@yktgi01e0-s4.watson.ibm.com] has left #xen []
16:55 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
16:58 < riel> mael: they already are
16:58 < riel> mael: they're in the FC4 test releases and will be in the FC4 final release
16:58 < mael_> ok
16:59 < mael_> which version of Xen? 2.0.5? or the unstable branch?
17:03 < riel> unstable
17:04 < riel> somebody needs to test it
17:04 < mael_> yeah that's right
17:04 < riel> besides, it seems to work pretty well most of the time
17:04 < riel> and things like SMP guests and VT support are nice to have
17:04 < matta> riel: you get anywhere with the bug I sent you?
17:05 < riel> matta: I'll upgrade to a newer upstream Xen to see if that makes it go away
17:05 < mael_> and it changes so much that an average user just like me can't follow/solve the problems
17:05 < matta> slab errors
17:05 < riel> matta: but I'm not actively debugging Xen ATM
17:05 < matta> oh, just packaging
17:05  * riel is preparing for the Red Hat Summit, and doing some other stuff
17:05 < matta> and accepting the reports
17:06 < riel> besides, if when I do Xen development, I look at bugzilla.xensource.com first ;)
17:06 < riel> that's where the code is maintained, after all - so that's where I try to help out
17:06 < matta> i'm pretty sure it was a FC4 kernel problem anyway
17:06 < riel> matta: quite probable ;)
17:06 < riel> oh wait, that happened with the non-xen kernel too?
17:06 < riel> e100 driver ?
17:07 < matta> I noted I had gotten the same errors under stock FC4 kernel but someone still moved the bug to you because it was a -xen0 kernel
17:07 < matta> yes actually
17:07 < riel> ahhhh right
17:07 < matta> was there a problem that was fixed recently?
17:07 < matta> actually, might be e1000
17:08 < matta> it is e1000
17:08 < riel> I'm not seeing changes to that driver in the diff between -rc3 and -rc4
17:08 < matta> eh, was worth a shot
17:08 < matta> for now i'm back at FC3 and running stable :)
17:09 < riel> can't blame you
17:09 < riel> if the bug also happens with the upstream kernel, lkml may be worth a try, or bugzilla.kernel.org
17:09  * riel goes back to some non-code parts of his job
17:09 < matta> it works fine with -testing and 2.6.11
17:09 < matta> could be the .12 patch to the FC4 kernel
17:10 < matta> or any other of the numerous patches
17:10 < riel> yeah, the e1000 driver changed in -rc4
17:17 -!- Tv [~Tv@hq.inoi.fi] has quit [Quit: Client exiting]
17:18  * riel reassigns the bug to a driver guy and hopes for the best ;)
17:18 < matta> heh
17:18 < matta> i bet that is it
17:28 -!- riel is now known as unriel
17:29 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
17:56 -!- mael_ [~Mael@kali.tirnamban.org] has quit [Quit: good night]
17:56 -!- b2s [~b2s@66.111.53.150] has joined #xen
18:03 -!- monski [~monrad@213083190130.sonofon.dk] has joined #xen
18:03 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
18:07 -!- crisen [~crisen@spank.terdmonk.com] has joined #xen
18:08 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
18:10 -!- monrad [~monrad@0x535b06c0.ronxx3.adsl-dhcp.tele.dk] has quit [Ping timeout: 480 seconds]
18:24 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Leaving]
18:24 -!- monski is now known as monrad
18:25 -!- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has quit [Quit: no reason]
19:08 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
19:12 -!- b2s [~b2s@66.111.53.150] has joined #xen
19:25 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
19:27 -!- b2s [~b2s@66.111.53.150] has joined #xen
19:27 -!- DEac- [~deac@xdsl-213-168-105-91.netcologne.de] has quit [Quit: Verlassend]
19:30 -!- DEac- [~deac@xdsl-213-168-105-91.netcologne.de] has joined #xen
19:30 -!- DEac- [~deac@xdsl-213-168-105-91.netcologne.de] has quit [Quit: ]
19:35 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
19:41 -!- tessier [~treed@203.210.212.17] has quit [Ping timeout: 480 seconds]
19:41 -!- monrad [~monrad@213083190130.sonofon.dk] has quit [orion.oftc.net charm.oftc.net]
19:41 -!- knewt [~jmb@zeus.pimb.org] has quit [orion.oftc.net charm.oftc.net]
19:41 -!- matta [~matta@69.93.28.254] has quit [orion.oftc.net charm.oftc.net]
19:41 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [orion.oftc.net charm.oftc.net]
19:41 -!- JViz` [Anomaly@cpe-065-190-045-031.triad.res.rr.com] has quit [orion.oftc.net charm.oftc.net]
19:41 -!- nextime [~nextime@213-140-6-96.fastres.net] has quit [orion.oftc.net charm.oftc.net]
19:41 -!- cc [~cc2@c210-49-121-44.eburwd3.vic.optusnet.com.au] has quit [orion.oftc.net charm.oftc.net]
19:42 -!- tessier [~treed@203.210.212.17] has joined #xen
19:42 -!- monrad [~monrad@213083190130.sonofon.dk] has joined #xen
19:42 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
19:42 -!- matta [~matta@69.93.28.254] has joined #xen
19:42 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
19:42 -!- JViz` [Anomaly@cpe-065-190-045-031.triad.res.rr.com] has joined #xen
19:42 -!- nextime [~nextime@213-140-6-96.fastres.net] has joined #xen
19:42 -!- cc [~cc2@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #xen
19:44 -!- b2s [~b2s@66.111.53.150] has joined #xen
19:47 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [Ping timeout: 480 seconds]
19:48 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
19:49 -!- monrad [~monrad@213083190130.sonofon.dk] has quit [Quit: Leaving]
19:50 -!- monrad [~monrad@213083190130.sonofon.dk] has joined #xen
19:52 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
20:03 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
20:15 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
20:41 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
20:45 -!- cfreak [cfreak@dsl-084-056-105-030.arcor-ip.net] has quit [Quit: .]
21:16 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: This computer has gone to sleep]
21:22 < bunoc2> |||||||\
21:26 < mikegrb> /|||||||
21:33 < rusty> mikegrb: I think ||||||\_ is next, actually.
21:33 < mikegrb> oh :<
21:33 < bunoc2> eh sorry, my cat jumpped to the keyboard :)
21:35 < rusty> bunoc2: Oh, I assumed this was Ascii dominos.
21:35 < bunoc2> no, it wasnt :)
21:41 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
21:45 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: ]
21:51 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
21:51 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: ]
21:51 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
21:54 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
22:20 -!- Pete [~Pete@pcp01685957pcs.wchstr01.pa.comcast.net] has joined #xen
22:30 -!- b2s [~b2s@66.111.53.150] has joined #xen
22:33 < surriel> sweet, akpm took the Makefile fix into -mm
22:42 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
23:02 -!- b2s [~b2s@66.111.53.150] has joined #xen
23:10 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
23:11 -!- b2s [~b2s@66.111.53.150] has joined #xen
23:17 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has quit [Ping timeout: 480 seconds]
23:19 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
23:21 -!- b2s [~b2s@66.111.53.150] has joined #xen
23:27 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has joined #xen
23:40 -!- Pete [~Pete@pcp01685957pcs.wchstr01.pa.comcast.net] has quit [Read error: Operation timed out]
23:44 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
23:55 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: Leaving]
--- Log closed Mon May 16 23:59:00 2005