[01:17] <axw> wallyworld: I have a few fixes for vsphere in https://github.com/juju/juju/pull/7256, I'd appreciate a review at some point so I can land it for the beta
[02:19] <cmars> anyone up for a fairly mechanical review? https://github.com/juju/juju/pull/7253
[02:20] <cmars> pm me if you have any questions
[02:31] <mup> Bug #1682827 changed: Bootstrap on OpenStack Cloud fails <juju:New> <https://launchpad.net/bugs/1682827>
[03:00] <axw> wallyworld: so you ok with me landing that MAAS PR then?
[03:01] <wallyworld> yeah
[03:01] <wallyworld> we can followup over the next few days and try and get it validated
[03:10] <cmars> axw, thanks for the review
[03:11] <axw> cmars: np
[03:18] <wallyworld> axw: the vsphere pr is reviewed
[03:18] <axw> wallyworld: thanks
[03:18] <wallyworld> hopefully that will be the last change for a while... :-)
[03:26] <axw> wallyworld: I'm going to leave it at 2 sec to match what the govc tool does, OK?
[03:26] <wallyworld> axw: sure, np. was just curious
[03:26] <axw> wallyworld: no worries. thanks
[06:30] <jam> axw: it doesn't seem right to disable the default cpu/cores stuff
[06:31] <jam> axw: as you can supply '--constraints' if you really are constrained
[06:31] <jam> the out-of-the-box result should be something that we feel is reasonable for a controller
[06:31] <jam> I know we've had problems with <1GB mem in the past
[06:31] <axw> jam: we already have controller-specific constraitns in the provider/common package
[06:31] <jam> axw: wouldn't that also be expected for any charm?
[06:32] <jam> default cpu cores = 2 might be a bit much
[06:32] <jam> maybe 1 core 1GB ?
[06:32] <jam> but removing it entirely seems like you'll just run into "all these charms just don't seem to work"
[06:33] <axw> jam: AFAIK, no other provider overrides CPU/mem in the provider code
[06:33] <axw> jam: hmm, maybe the 1GB limit is in the provider, mixed in with image selection. seeing it in the azure provider now. I can put that in.
[06:34] <jam> axw: I can't say as to where it exists, but some sort of sane "minimum default" seems useful.
[06:35] <axw> jam: it's different because it'll vary by site. but yes, we should - I thought it was handled outside the provider, but looks like I was wrong
[06:36] <jam> axw: could we just handle the "this is already off" error instead of pre-checking?
[06:36] <jam> not sure if they give clear errors
[06:38] <axw> jam: maybe, not sure if the destroy task will still be actioned if that happens. I'll look at optimising it later
[06:39] <jam> axw: not a big deal, pre-check is always a little bit racy
[06:46] <icey> juju is once again not setting JUJU_AVAILABILITY_ZONE in all cases: https://bugs.launchpad.net/juju/+bug/1684325
[06:46] <mup> Bug #1684325: customize-failure-domain has no effect when ceph-mon is deployed in a container <juju:New> <https://launchpad.net/bugs/1684325>
[07:35] <axw> jam: turns out there's a default of 1GB mem in the OVF anyway, and then vcenter may allocate more. since it's defined in the images and they could change, we should still check - but I'm going to defer until after my current work
[07:36] <jam> axw: k
[07:43] <wallyworld> jam: axw: i checked the code - the controller contraints are processed at bootstrap in withDefaultControllerConstraints() in environs/bootstrap. We honor any constraints the user may have passed in though. why do we think vSphere should be special and get to set it's own constraints that sometimes fail?
[07:43] <jam> wallyworld: juju should be defining default constraints for a controller, it doesn't have to come from vsphere
[07:44] <wallyworld> right, that's what we do
[07:44] <wallyworld> i was confused as to your pushback on the PR
[07:44] <wallyworld> all that was done was special vSphere constraints were removed and we rely on the controller contraints already in place
[07:45] <axw> wallyworld: the one piece I don't think we do in one location, is set default constraints for non-controller machines
[07:46] <axw> wallyworld: e.g. setting 1GB mem. I think we might do that when selecting instance types, but that doesn't apply to vSphere
[07:46] <wallyworld> right, there's aren't any
[07:46] <wallyworld> hmm, ok there could a mem constraint
[07:46] <wallyworld> not sure
[07:47] <axw> wallyworld: anyway, as I said above the OVF says by default that it needs 1GB mem, 2 vCPUs
[07:47] <axw> doesn't specify Hz
[07:47] <wallyworld> so we are ok then
[07:48] <axw> wallyworld: yes, but I think we should check the minimum memory, in case the images change, or images for other series/OS come along
[07:48] <wallyworld> if that's what we do for other providers, sgtm
[07:48] <axw> wallyworld: doesn't need to be done as a constraint, just check the ImportSpec that gets generated from the OVF
[07:49] <axw> I'll do it later, working on higher priority things atm
[07:49] <wallyworld> yep
[07:50] <wallyworld> axw: no rush since you have stuff happening; if you get a chance, but can wait till tomorrow, i have soccer in a bit anyway https://github.com/juju/juju/pull/7258
[07:51] <axw> wallyworld: ok, probably a bit later - I keep context switching and losing where I'm at :)
[07:52] <wallyworld> yeah, no worries, leave it go, just wanted to let you know it was there for later
[07:52] <wallyworld> tomorrow is fine
[07:52] <wallyworld> the gui doen't even use it yet
[08:07] <rogpeppe> axw, wallyworld, jam: any chance of a review of https://github.com/juju/juju/pull/7254?
[08:07] <wallyworld> rogpeppe: i'm just heading out to soccer but will be back later this evening
[08:08] <rogpeppe> wallyworld: k
[11:14] <mup> Bug #1680582 changed: Agents losing connection to leader tracker <canonical-bootstack> <juju-core:Won't Fix> <https://launchpad.net/bugs/1680582>
[11:23] <mup> Bug #1680582 opened: Agents losing connection to leader tracker <canonical-bootstack> <juju-core:Won't Fix> <https://launchpad.net/bugs/1680582>
[11:29] <mup> Bug #1680582 changed: Agents losing connection to leader tracker <canonical-bootstack> <juju-core:Won't Fix> <https://launchpad.net/bugs/1680582>
[11:40] <rogpeppe> here's a small addition to juju/utils, in case anyone cares to review it: https://github.com/juju/utils/pull/273
[12:14] <jam> rogpeppe: I made some comments on it as well
[12:14] <rogpeppe> jam: thanks
[12:14] <rogpeppe> jam: except you're too late :)
[12:14] <jam> rogpeppe: its never too late :)
[12:15] <rogpeppe> jam: well, it's merging already
[12:15] <jam> rogpeppe: sure, but you can always land a follow up
[12:15] <rogpeppe> jam: i'm not convinced by the "no panic ever" thing.
[12:15] <rogpeppe> jam: lots of our code can panic
[12:15] <jam> rogpeppe: we've been bit several times with panic() in production code, and adding more doesn't make it better
[12:16] <rogpeppe> jam: this is something that's easy to verify at the call site - like a number of panics that are in the go stdlib
[12:17] <jam> rogpeppe: well, I'd guess that not all callers are going to be passing in consts
[12:17] <rogpeppe> jam: more-or-less anything that takes a pointer as an argument can panic
[12:17] <rogpeppe> jam: in practice, all callers are passing in a const for the "var=" part
[12:18] <rogpeppe> jam: in this case, i think i prefer the panic to making it return an error
[12:20] <rogpeppe> jam: FWIW i just used the existing tests from juju/environs/tools/build.go
[12:20] <rogpeppe> jam: the implementation there didn't panic when not passed a "=" - it just silently got it wrong
[12:21] <rogpeppe> jam: i guess it could just silently ignore a badly formatted argument
[12:23] <jam> rogpeppe: if it is only ever used with const values, then I'm ~ok with a panic() but it feels like the type of helper that ends up folded into code that gets called from iterating over an array of env vars someone was asked to set
[12:25] <rogpeppe> jam: ok, i'll make it silently ignore the bad value. i'd prefer that to adding an error return, because it's very convenient to use it inline currently.
[12:26] <jam> thk
[12:26] <jam> thx
[12:27] <rogpeppe> jam: these are the only calls for the moment, BTW: http://paste.ubuntu.com/24419916/
[12:28] <rogpeppe> jam: thanks for the review of https://github.com/juju/juju/pull/7254
[12:34] <rogpeppe> jam: here you go: https://github.com/juju/utils/pull/274
[12:35] <jam> rogpeppe: lgtm
[12:36] <rogpeppe> jam: thanks
[12:36] <rogpeppe> jam: wanna approve it on the PR?
[12:36] <jam> I did
[12:36] <jam> well, I hit approve, apparently not submit review
[12:36] <jam> rogpeppe: done
[12:37] <rogpeppe> jam: thanks
[13:17] <wpk> jam: what's the PR you wanted to get reviewed?
[13:17] <jam> https://github.com/juju/juju/pull/7260
[13:22] <zeestrat> Is there a way to use dynamic variables such as env variables when deploying bundles with the native juju deploy in 2.x?
[13:32] <wpk> is there a doc on building juju dpkg?
[13:32] <wpk> *deb
[13:32] <wpk> ?
[13:34] <rogpeppe> anyone have a clue what failed here? http://juju-ci.vapour.ws:8080/job/github-merge-juju-utils/178/console
[13:40] <wpk> glitch in matrix
[13:40] <wpk> watch out for people in black coats
[13:42] <rogpeppe> wpk: :)
[13:43] <rogpeppe> here's a small change to make the cmd tests pass under Go tip: https://github.com/juju/juju/pull/7261
[16:47] <rogpeppe>  i'm looking for a second review of this if poss, please: https://github.com/juju/juju/pull/7261
[21:01] <thumper> morning


[05:19] <bandit5432> i have a question about questionst asked in #ubuntu
[05:20] <bandit5432> can i ask for help about things that i can install on ubuntu or linux in general or can i only ask about ubuntu software?
[05:22] <bandit5432> i did not feel that the responses i recieved from some of the ops after asking about installing kernel 3.1 where appreciated
[05:25] <pangolin> you can ask questions about anything that is available in the Ubuntu repositories but keep in mind you may be redirected to a different channel if the helpers feel it would be better for you.
[05:25] <pangolin> that said the 3.1 kernel is not in the ubuntu repos.
[05:25] <bandit5432> yes but it was not a very nice conversation and i have helped people for the last 2 nights
[05:26] <pangolin> how was it not nice?
[05:26] <bandit5432> tonyyarusso, responses where rude
[05:27] <pangolin> I saw his responses and did not see any rudeness on his part
[05:27] <pangolin> what exactly did you think was rude?
[05:27] <bandit5432> [04:08] <tonyyarusso> bandit5432: Well, currently 3.1 does not exist in any supported version of Ubuntu, so it's pretty reasonable that nobody here can support it, frankly.
[05:27] <tonyyarusso> I was explaining that you're unlikely to get help, particularly since you mentioned that this was your second day trying with no results.
[05:28] <pangolin> I suppose you could read that as rude if you really wanted to but knowing tonyyarusso I can say he was not being rude.
[05:29] <bandit5432> ok i take your work for it
[05:29] <bandit5432> word'
[05:29] <pangolin> bandit5432: We do appreciate you bringing your concerns to our attention though :)
[05:29] <tonyyarusso> You certainly *can* ask about such things (we're not telling you it was "offtopic" for the channel) - it's just unlikely to be particularly efficient at getting you the answers you need.
[05:29] <bandit5432> but the response of [04:11] <tonyyarusso> bandit5432: Not really.  It's generally understood that if you want to run bleeding-edge unsupported software you have to be able to support yourself.
[05:30] <pangolin> again nothing rude there
[05:30] <bandit5432> no but not helpful or supportive either
[05:30] <pangolin> bandit5432: I am sorry that you feel he was being rude but if it isn't in the repos it is not supported in #ubuntu.
[05:31] <bandit5432> is that in the guidlines ?
[05:31] <pangolin> no
[05:31] <pangolin> but the guidelines are just that, a guide.
[05:31] <pangolin> not a comprehensive list of everything allowed.
[05:32] <bandit5432> maybe that needs to be added to the channel announce
[05:32] <pangolin> there is also a bit in the guidelines about common sense. I think the not in the repos thing is common sense.
[05:32] <tonyyarusso> Again, you weren't being scolded for any kind of guidelines violation.  You were being told why you hadn't gotten any help yet.
[05:32] <bandit5432> cool
[05:33] <bandit5432> thanks for listening, thats what a lot of us want when we join and have issues or problems
[05:33] <pangolin> We try and thank you.
[05:34] <bandit5432> and you might want to think about adding the repo thing to the user quidelines so there is less confusion
[05:39] <pangolin> tonyyarusso: Stop being so rude :P
[05:39]  * pangolin runs off
[11:12] <Myrtti> niiiicce
[13:00] <iceroot> maybe this can be placed in the topic of #ubuntu? https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/887380
[13:02] <iceroot> https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349  this of course instead of the duplicate
[13:14] <ikonia> iceroot: I don't really think a link to a bug is useful in the topic and it's not really a show stopper, certainly a factoid may be more useful
[13:15] <iceroot> ikonia: sounds good
[13:16] <Myrtti> as I suggested to topyli earlier, perhaps we should make a factlet out of the old #gaim topic
[13:16] <ikonia> sounds a good option
[13:16] <Myrtti> [11:10] < topyli> to quote the old #gaim topic: "If you're having trouble connecting to MSN, assume  the problem is with MSN not Gaim"
[13:16] <jussi> what the heck?
[13:17] <jussi> oh yes. my changed clock
[13:17] <knome> clock? :P
[13:17] <jussi> cloak even
[13:17] <Myrtti> ie. most likely it's not a bug that Ubuntu can help at all.
[13:17] <Myrtti> or even upstream projects
[13:17] <Myrtti> "it's MSN, live and learn to use something else"
[13:17] <topyli> upstream can help eventually, once they crack the msn changes
[13:18] <Myrtti> topyli: in about 75% of the cases the problems exist only because MS has some glitch in their servers
[13:18] <Myrtti> about 20% are because there's something wrong with the all over networking
[13:19] <Myrtti> and 5% is actually something that upstream can help
[13:19] <Myrtti> as usual, these numbers are courtesy of the trustworthy Stetson-Harrison method, ie. facts, statistics and lies
[13:19] <topyli> yeah, and when msn has a problem of their own, patience is the only cure
[13:19] <iceroot> heise.de is reporting about routing-errors in the uk and usa (dont have an english link)
[13:19] <Myrtti> iceroot: the juniper issue still?
[13:19] <iceroot> Myrtti: yes
[13:20] <Myrtti> ah, figured as much.
[13:20] <Myrtti> I can only assume it effected IRC networks as well yesterday
[13:20] <iceroot> Myrtti: and the msn-fix is to use another server (see debdiff) so maybe its just because of the routing error
[13:20] <Myrtti> tsk
[13:20] <Myrtti> affected.
[13:21] <Myrtti> so, I stand by my opinion of "it's not you, it's MSN" and "learn to use something else"
[13:21] <Myrtti> :-P
[13:21] <Myrtti> I know it's not helpful, but filing bugreports probably isn't either
[13:21] <iceroot> can we do that on !iphone and !ipod too? :)
[13:21] <topyli> Myrtti: so, "assume the problem is with msn, not your chat client. also see !jabber" :)
[13:22] <topyli> !jabber
[13:22] <topyli> !msn
[13:23] <knome> huh, that's a bad factoid :P
[13:23] <Myrtti> !currentissues
[13:23] <Myrtti> !unforget currentissues
[13:24] <Myrtti> !currentissues
[13:24] <Myrtti> löl.
[13:24] <Pici> lawl
[13:24] <knome> RAWR
[13:24] <Myrtti> that made me laugh
[13:24] <Myrtti> oh man.
[13:25] <Myrtti> aaaaaand over to our factoidmasters.
[13:25] <Myrtti> give a huge round of applause! *clap*                      *clap*
[13:28]  * knome accidentally burps during the uneasy silence
[13:30] <topyli> i can't think of a good trigger for the broken-msn factoid
[13:30] <knome> !broken-msn
[13:31] <topyli> might make sense :)
[13:31] <jussi> why not just use currentissues ?
[13:31] <iceroot> "at the moment there are login-issues with msn. you cant do nothing then wait. In your waiting time have a look at free alternatvies like !jabber"
[15:12] <Pici> ikonia: sorry, been up for too many hours at this point
[15:13] <ikonia> no no, you're dead on to be factually correct
[16:32] <mneptok> http://26.media.tumblr.com/tumblr_lubeckSvJO1qi4xu8o1_400.jpg
[16:32] <pangolin> mneptok: is on page 14 of<PHONE_NUMBER>999999999999 of the internet :P
[16:36] <mneptok> but us Ubuntu IRC ops could do well at this. we do it all day, anyway. -  http://failblog.org/2011/11/01/epic-fail-photos-family-fun-fail-3/
[16:36] <mneptok> s/but/bet/
[16:37] <pangolin> haha
[17:11] <Pici> pangolin: thanks
[17:11] <pangolin> sure thing
[17:11] <pangolin> btw he is often, iffy.
[21:00] <bobweaver> I have a important question if you are on irc and see people hacking websites what to do ?
[21:00] <bobweaver> cracking websites *
[21:03] <Myrtti> is this happening on some Ubuntu channel now?
[21:04] <bobweaver> No
[21:04] <bobweaver> on a different network
[21:05] <bobweaver> people where using this http://www.exploit-db.com/exploits/18083/   with there bots
[21:05] <bobweaver> ajax_create_folder.php   > to remote shell
[21:05] <LjL> i suppose you could contact the website involved
[21:07] <bobweaver> because I was there I dont want to be involed with anything like this.  it puts me as a accessory to crime I think not sure
[21:07]  * bobweaver is noob
[21:08] <ikonia> ....this really isn't an ubuntu issue
[21:08] <bobweaver> ikonia: where to get help please
[21:08] <ikonia> LjL's advice is best
[21:09] <bobweaver> thank you ikonia
[21:09] <ikonia> but beyond that, nothing we can do
[21:09] <bobweaver> I know I was just wondering about how to go about something like this. thanks for your time


[00:02] <Len-1204> Is this release beta now? where is the page to report what works and does not?
[00:03] <Len-1204> There is no link from our web page /wiki, I can't find it with a search
[00:23] <len-nb> Ok, I found a testing tracker which shows daily, alpha1 and alpha 2 (and Lucid 10.04.4) so I guess there is no beta yet.
[00:23] <micahg> TheMuso: anything related to that kernel :)
[00:24] <len-nb> it is: http://iso.qa.ubuntu.com/
[00:53] <ScottL> len-nb, did you find the right test case?
[00:55] <ScottL> 64 bit - http://iso.qa.ubuntu.com/qatracker/milestones/208/builds/12719/testcases
[00:55] <len-nb> ScottL: beta is march 1, it's not out yet. We may get to test for lowlat kernel...
[00:55] <ScottL> 32 bit - http://iso.qa.ubuntu.com/qatracker/milestones/208/builds/12720/testcases
[00:55] <ScottL> len-nb, right, beta 1 is not officially released but what we are doing is validating the ISO images
[00:56] <ScottL> we wouldn't want to release a beta 1 (or any other) image officially with a large, pervasive bug when the image was uninstallable
[00:56] <ScottL> if an image is not fully tested, the the release team has the right not to release that milestone image for wide spread testing
[00:56] <len-nb> ScottL, it looks pretty good actually, was the eamil helpful at all?
[00:57] <ScottL> len-nb, yeah, i'm very relieved that there didn't see to be any additional significant problems :P
[00:57] <len-nb> s/aemil/email/
[00:57] <kubotu> len-nb: You did something wrong... Try s/you/me/ or tell me "help sed"
[00:57] <ScottL> len-nb, and the email was very helpful, i should attend to the menu this week
[00:59] <len-nb> Scott: ok, do you still want me to pull the settings and mod it or would it be easier to send fills etc.? What else should I do? I have some panel stuff too if you like.
[01:00] <len-nb> BTW, when the user first logs in, a lot of stuff from /etc/xdg/xdg-ubuntustudio/xfce4/
[01:00] <len-nb> gets copied to ~/.config
[01:02] <len-nb> If you use the settings panel to change these setting, you can see what changed in the file in that directory to know how to make changes in the default file in /etc/
[01:02] <len-nb> ScottL  ^^^
[01:10] <ScottL> len-nb, i'd say let's approach the panels next week, but i would say this...
[01:10] <ScottL> i agree with you and mike about not modding the panel too much, especially for work flows
[01:11] <ScottL> but i wouldn't mind keep the 2nd panel for the mundane desktop stuff (i.e. web browser, terminal, file browser)
[01:11] <ScottL> but will probably change a few things
[01:11] <ScottL> TheMuso, i'm not in a hurry to change the seeds for the -lowlatency kernel, i would like to get through this week and beta1 released first in the least
[01:11] <ScottL> TheMuso, but i would like to try to maximize our time after beta 1 however
[01:18] <len-nb> ScottL, I will remove the mini-menu from what I have shown on the webpage. So I have a file you can use. The menu directory/file seem to just work even with all our other menu bits hanging around.
[01:19] <len-nb> I just copy it into the right directory and the next time I open the menu it works.
[01:19] <len-nb> cleaning up the old stuff would be nice though.
[01:20] <len-nb> I have made up a temp set of icons for Hexter, the firewire mixer and the photography menu as well as the needed directory files.
[01:20] <ScottL> len-nb, is your menu stuff in your launchpad code still?
[01:21] <len-nb> Yes.
[01:21] <ScottL> cool
[01:22] <len-nb> The panel stuff is not.
[01:23] <len-nb> ScottL, the original ubuntustudio-menu will give a good idea as to what needs to be removed from the settings package before adding those files. There are actually only about 2 files that get kept.
[02:24] <micahg> BTW, there's a GTK3 version of audacious in Debian now, not sure if you want that in precise, you'll want to sort that out with gilir from Lubuntu (I think they'd probably prefer GTK3)
[03:02] <TheMuso> ScottL: Right.,
[03:07] <len-nb> ScottL, with regard to the menu package, should there be a script that removes the old files in the case of an upgrade? The old files don't have to be removed for this to work so it may be better to leave them alone in case they are used by other session types.
[03:40] <ScottL> i can't get the 64 bit version of the beta1 image to install :/
[03:40] <ScottL> not sure if it is ubiquity or my discs, but i've had two discs that have stopped installing saying that it can't copy files and saying it might be the dvd
[05:22] <ScottL> all images tested *whew*
[16:20] <knome> it's evident we need help testing xubuntu images :/
[16:41] <holstein> knome: ill see what i can do today!
[16:41] <knome> holstein, thanks. i'm going to work on the amd64 desktop stuff
[16:42] <knome> holstein, and yeah, we only have a few hours... ;)
[16:42] <holstein> dammit!
[16:42] <holstein> not sure if i can even get images downloaded then
[16:42] <knome> yeah. no worries.
[16:42] <holstein> the internet here is funky
[16:42] <knome> i'll sort it out
[16:42] <knome> we'll need to get this stuff sorted so we get tests done...
[16:55] <scott-work> knome: i can start downloading in 7 hours time to start testing, is that still helpful?
[16:55]  * scott-work would really like to help
[16:55] <knome> scott-work, not anymore for today
[16:55] <scott-work> :(
[16:55] <knome> as said, we only have a few hours
[16:56] <knome> i'm running some tests now
[16:57] <scott-work> ah, i'm sorry that i couldn't be more help, i talked to micah about it last night, but i ended up running studio test until quite a bit past my bedtime last night
[16:57] <knome> ah, np
[16:57] <knome> have had to be away from computer more lately
[16:57] <knome> so i can't blame anybody else really
[17:00] <holstein> knome: who's doing what?
[17:00] <holstein> looks like 0/3 on the alternates
[17:00] <holstein> i'll download that iso
[17:00] <holstein> or start...
[17:00] <knome> holstein, i'm on the amd64 desktop
[17:01] <holstein> ok
[17:01] <holstein> im not
[17:01] <holstein> well... i could be
[17:01] <knome> because the amd53 alt tests were done on earlier cycles
[17:01] <holstein> i could wipe that machine
[17:01] <knome> err amd64
[17:01] <holstein> knome: where do you need me?
[17:01] <holstein> i can likely download one iso and do one test in time
[17:01] <knome> in that case, i386 desktop auto-resize
[17:02] <holstein> this looks correct? http://cdimage.ubuntu.com/xubuntu/daily-live/20120228/precise-desktop-i386.iso
[17:02] <knome> yep
[17:02] <holstein> :)
[17:02] <holstein> we'll see if i can squeeze it in
[17:03] <holstein> down to 25minutes
[17:03] <knome> okay, thanks a lot
[17:03] <holstein> and i
[17:03] <holstein> 'll do it on metal
[17:03]  * knome just finished his first test
[17:03] <knome> ...ever
[17:03] <holstein> :)