=== hyperair is now known as Guest93522 === Tonio__ is now known as Tonio_ === jsgotangco is now known as greeneggsnospam === greeneggsnospam is now known as jsgotangco === juliux_ is now known as juliux === unimix_ is now known as unimix === Seeker`_ is now known as Seeker === Seeker is now known as Seeker` === jamie_ is now known as JamieBennett === soren_ is now known as soren === txwikinger2 is now known as txwikinger === yofel_ is now known as yofel [18:01] kees: meeting today? [18:01] robbiew: yup! just gathering notes [18:02] yayay [18:02] jdstrand: you ready? [18:02] * nxvl waves [18:02] heya nxvl :) [18:02] you finally got out of my lunchtime :D [18:02] hehe [18:02] o/ [18:02] back to a normal time. I dislike DST [18:03] It doesn't save me a thing [18:03] yeah [18:03] okay, starting... [18:04] I'm a day behind on triage -- I'll do a bug and CVE run this morning. over the weekend I worked on trying to reproduce the weirdness we've seen with AppArmor kernel memory [18:04] kees: too late, I've done it already [18:05] mdeslaur: you did the CVEs? you're fast! [18:05] kees: east coast ftw [18:05] totally :) [18:05] heh [18:05] well, let me do the 27 bugs that're New. At least two are embargoed issues I need to submit. [18:06] which brings me to publications -- I'll be doing a number of embargoed publications for things this week. [18:06] and finding syncs etc. [18:06] syncs? [18:06] no real news, but we should think about anything we want to put in the monthly report [18:06] mdeslaur: fake-syncs from Debian [18:06] oh! [18:07] and we should start brain-storming for UDS [18:07] we've got our very own track again. :) [18:07] kees: re syncs> fyi, check later in the week, we should be up to date as of friday) [18:07] jdstrand: yeah, you're all too fast for me. :) [18:08] I think that's it. I might be trying to chase down beta-bugs (raid1 installs, kernel IO, aa memory, etc) [18:08] well, I did it on Friday. one could say I was too slow... I'll take the praise though [18:08] * mdeslaur sends some praise to jdstrand [18:09] heh [18:09] mdeslaur: is up [18:09] maybe not 'too' slow, since it was within the allotted time, but slow nonetheless ;) [18:09] mdeslaur: :) [18:09] kees: they are making you look slower... [18:09] * kees cries [18:09] oh no! [18:09] I'll take a look at the openssl issues this week. [18:09] I'm also on triage, so I'll be doing that also [18:09] kees does great things all the time that we aren't talking about right here :) [18:10] and I'll take a look at Lucid cves to make sure we're all caught up [18:10] hehe [18:10] jdstrand: +1 [18:10] oh yeah, we should start walking the "almost released" checklist too [18:10] it's a bit confused what with 2 betas, but still. [18:11] * jdstrand was just thinking the same thing [18:11] I also want to document the actions/rights permissions in Ubuntu [18:13] mdeslaur: oh! yeah, that's really cool. I'm looking forward to that. [18:15] mdeslaur: [18:15] er [18:15] mdeslaur: shall I go? [18:15] you done? [18:15] oh sorry [18:15] yes :) [18:15] hehe [18:15] got my foot stuck in the email trap :) [18:15] heh [18:16] evil e-mail trap [18:16] ok, I'm happy place this week. I plan to pull the lever on clamav/dapper, have an erlang update, an embargoed update, a moin merge (for security update in lucid) and a little more work on apparmor-notify [18:17] apparmor-notify wasn't dealing with log rotation-- I fixed that for kern.log over the weekend, but need to fix it for when it drops privs (ie auditd) [18:17] jdstrand: oh, I've disabled parallel profile loading for now since it makes the AA memory-pressure thing worse. haven't uploaded it though, but it is tested. [18:18] kees: cool-- I turned on apparmor-notify too. so let's coordinate before the other wants to upload [18:18] (apparmor-notify is not installed by default and in universe, so this way, installing it will enable it) [18:18] \o/ [18:19] jdstrand: I'll put it in your court -- if you're ready to upload, go for it. I'm set, but I'm not uploading it for a bit since jj and I are still mucking around with test kernels and stuff [18:19] we probably need to discuss whether to disable apparmor-notify before release, but me feeling is probably no, since it is opt-in at present [18:19] kees: ack [18:19] * kees agrees [18:19] ok [18:19] all that was the 'little stuff' for the week [18:19] If the package doesn't get installed by default, it can be turned on by default [18:19] +1 form me [18:19] my big effort is to fix my last 3 blueprint items for libvirt [18:20] due to upstream changes, just getting a newer version to run with apparmor took some work last week. I now have a merge of 0.7.7-4 (from Debian) that works [18:20] plan is to upstream my stuff and then to 0.7.7-4 [18:21] I suggested that the server team consider my merge for lucid [18:21] jdstrand: you want to get 0.7.7 in? [18:21] (see email in ubuntu-server@) [18:21] jdstrand: that may require virtinst and possible virt-manager [18:21] mdeslaur: I do, but it is up to ubuntu-server [18:21] mdeslaur: I'm pretty sure it will work better with virt-manager, since you have such a newer version in lucid iirc [18:22] the dependencies between those components are unclear to me [18:22] mdeslaur: the merge is in my ppa, please feel free to play with it, but read my email in ubuntu-server [18:23] jdstrand: I did read your mail....and I freaked out about the "libvirt chown's the disk files to root:root for people using qemu:///system." part [18:23] I will be working with kirkland one day this week to verify it is ok. if they accept it, then I won't have to backport my patches to 0.7.5 (what is currently in lucid). otherwise, I will [18:23] mdeslaur: yeah-- I didn't much like that either :( [18:24] "How to become root in 3 easy steps..." [18:24] mdeslaur: it seems it is part of the DAC security driver work from upstream [18:25] mdeslaur: well, if you are in the libvirtd group (ie can use qemu:///system), you have root (though not trivially) [18:25] mdeslaur: that has always been the case (see README.Debian in lucid's libvirt) [18:26] anyway, that chown thing needs to be looked at more/fixed, probably by the server team [18:27] that is it from me, though I have two items to discuss [18:27] shoot [18:28] ok. I'm not totally satisfied with universe triage [18:29] it's a wasteland :( [18:29] while we deal with supported packages and the community is supposed to triage universe stuff, it doesn't happen [18:29] * jdstrand nods [18:29] now that people are starting to discover and write about UCT, maybe there are little things we can do to at least improve the situation somewhat [18:30] I thought of two things, neither of which are perfect, but both will help some [18:30] a) unconditionally use the version mentioned in MITRE's CVE (when available) as 'upstream: release (...)' [18:31] ugh [18:31] we can then have automation to check Ubuntu versions and mark then 'not-affected' with all others as 'needed' [18:31] mdeslaur: hold on a sec-- I'll justify this in a moment ;) [18:31] ok :) [18:33] b) we (manually) check Debian for a fixed version and add it to upstream: released (...) through automation of some sort, and then adjust not-affected releases [18:34] ok. I totally admit that this is imperfect-- MITRE gets the versions wrong sometimes (and we would have to figure out how to deal with when they take a vendor's version and say it is affected) [18:34] so, I already do "a" but only when the wording from Mitre is specific. I.e. "Foo before version XYZ, is vuln..." rather than "Foo version XYZ in vuln" [18:34] their "before version XYZ" tends to be triggered by upstreams claiming to fix stuff. [18:34] that said-- I think that putting something in there that is accurate most of the time is better than nothing in there. we/community members can adjust the CVEs as needed [18:35] for "b" we need the changelog-CVE-scanner back online. [18:35] when Debian fixes stuff, I'll use a debian version for the upstream: released line [18:35] kees: well, 'b' doen't have to be automatic, but it would be nice if it was [18:35] right. [18:35] kees: re Debian version> right, so do I [18:35] I think the big thing to help with visibility is getting cve-tracker mirrored into LP. [18:36] and when I do fake syncs I update the CVEs that they fix [18:36] unfortunately, that's still stuck on bug 314432 [18:36] Launchpad bug 314432 in malone "It's impossible to see all the bugs that affect a BugTarget if some bugs are targeted to one or more series and the Master task is closed" [High,Triaged] https://launchpad.net/bugs/314432 [18:36] I don't think as a team we do 'a' consistently [18:36] ie, there are a gagillion 'needs-triage' [18:37] I don't do 'a', as I don't like marking things "not-affected" when the code hasn't been looked at [18:37] kees: agreed on that [18:37] that's possible about "a". I tend to do it, but I've found it somewhat rare for Mitre to say "before version X.Y.Z" [18:37] too often I've seen it not fixed in the version that mitre has there [18:37] I've been burned by that before [18:37] I see 1.6.x before 1.6.2 all the time [18:37] and false negatives are a lot worse than false positives [18:38] mdeslaur: oh, for those I don't mark 1.5.x not-affected. I _really_ don't trust that. [18:38] and sure, it will have errors. but is having nothing better? maybe it is, but I think not [18:38] I feel like forward-versions are safe. [18:38] so you guys just mark the "upstream" line with a version? [18:38] I was talking about forward versions. [18:38] eg, 1.5.2 is fixed. therefore 1.5.3 is fixed [18:38] what are "forward versions"? [18:39] so you _do_ mark 1.5.3 as not-affected [18:39] while it's sometimes wrong, most times it's correct for "it has been fixed in version X.Y.Z" but I always leave stuff older (even unmentioned earlier release series) as needs-triage [18:39] mdeslaur: I'm proposing we do that for universe, yes [18:40] ok, from now on, "in xyz before 1.5.3", we mark upstream as 1.5.3, and anything we have that's 1.5.3 and more recent, we mark as not-affected? [18:40] if nothing else, I think it would be a good start to formalize how we should triage these [18:40] mdeslaur: if I see Mitre say "Foo 1.3.x before version 1.3.7 is vulnerable..." I will mark 1.3.7 and later in the 1.3.x series as fixed, but any other versions needs-triage (i.e. 1.4.x 1.2.x) [18:40] then maybe from there, we can automate [18:41] scripts/sync-from-versions already auto-closes stuff in the devel release if it's higher than the upstream: released version [18:41] should we be more vigilant when the cves-run updates descriptions? [18:41] oh, that's a good point -- I never adjust triaging from updated descriptions. [18:41] when/who runs sync-from-versions? [18:41] I don't [18:41] I run sync-from-versions any time I'm on triage or run sync-from-usns [18:42] it intentionally only closes devel. [18:42] wait-- I don't sync-from-versions. I do adjust triaging from updated descriptions [18:42] hahaha [18:42] I don't run sync-from-versions, I don't adjust triaging from updated descriptions [18:42] heh [18:43] and I've hit wrong "before 1.x.x" in descriptions on almost all mysql cves [18:43] well, technically, I referring to community stuff here, so it isn't horrible that we do different things [18:43] I really just want to identify if we can standardize it and see if after that we can do some things automatically [18:43] mdeslaur: sure, I will take exception with "known poorly triaged" software. the kernel, firefox, and mysql jump to mind. [18:44] all of those are not community supported [18:44] I am *only* talking about universe/multiverse [18:44] so, what's the ultimate goal here? to get rid of universe CVEs automatically when old distros get retired? [18:44] the policy I've been working under has been that universe stuff is marked as not-affected if it is the most recent series, and mitre says "before [version-from-that-series]" [18:44] mdeslaur: that already happens [18:45] mdeslaur: we do a big EOL thingamajig [18:45] mdeslaur: to keep the devel release of ubuntu up to date as new versions of software land in the archive. [18:45] kees: I do that [18:46] what I used to do differently is that I would mark versions under that as 'needed' [18:46] for that series, yeah, I'd do the same. [18:46] (being careful of multiple branches) [18:46] however, lately I've noticed mdeslaur doing those as needs-triage, and I've fallen into that myself [18:47] and by lately, I mean the last 6 months or so (roughly) [18:47] i.e. if we have 1.2.4, 1.3.2, 1.3.3, 1.4.0, and mitre says "before 1.3.3", I would marked: 1.2.4: needs-triage, 1.3.2: needed, 1.3.3: not-affected, 1.4.0: needs-triage [18:47] jdstrand: so you would blindly mark them as "needed" without actually looking at them? [18:47] kees: I like that [18:47] sorry, "1.3.x before 1.3.3" [18:47] mdeslaur: for *universe*, I would do as kees said, yes [18:47] if it said just "before 1.3.3", I'd mark 1.2.4 as needed too [18:48] right [18:48] I'd like to get back to that, and hopefully automate it, if possible [18:48] if not automate, the script it [18:48] ok, I don't mind doing that [18:48] although, I don't know what it will gain us [18:48] but, I can do it [18:48] I think overall it will gain us more accuracy [18:49] (granted, not 100%) [18:49] more completed, but less accurate :P [18:49] accuracy by way of less bit-rot as we move forward in time. [18:49] I also think that if UCT says it is affected, then someone will be more likely to fix it [18:49] i.e. filling in upstream: released future-proofs us a bit [18:50] kees: okay, that sounds valid [18:50] practically speaking, if it says 'needs-triage', community people aren't going to look at it. if it says it is needed, then we have a chance [18:50] * kees nods [18:51] well then we should change them all to needed :) [18:51] which is what I tried to get at with 'accuracy' [18:51] ok, fair enough, so 1.2.x is needs-triage, 1.3.x is needed, 1.4.x is not-affected [18:52] (ie, needs-triage translates to 'not-affected' or 'ignored' to community folk) [18:52] It may be worth spending a day or two to go through all the universe CVEs and actually retire a slew of them [18:52] ie: a one-time thing [18:52] I wouldn't mind doing that [18:52] I wonder if we should use a UDS slot for a mass-ancient-CVE-triage-jam [18:52] as in, follow our new procedure for what is in there? [18:53] well what about a context with a prize for the most RMS-worthy beard? [18:53] errrr [18:53] wrong channel [18:53] jdong: lol [18:53] I would say so ;) [18:53] hahaha [18:53] omg, thank goodness because my eyes just about popped out of my head trying to jam that into context [18:53] new theme and active window border contrast. [18:53] grumble XD [18:53] jdstrand: I would like to spend a few hours and triage the universe CVEs to get rid of half of them [18:54] mdeslaur: do you think there are a lot that will fall into this? [18:54] it may be easier to get some community help if we didn't have CVE-2006 stuff in there [18:54] kees: yes, I think so [18:54] I brought this up once before, I think that as far as UCT is concerned, we should treat all universe CVEs as non-LTS [18:54] ie, dapper/universe becomes 'ignored' [18:55] mdeslaur: well, since you're the most sceptical of this plan, I think you're the right person to do it. :) I don't want to get too aggressive with it, as you said, since I don't want to start losing accuracy [18:55] then people can triage them away from ignored if they want to maintain it [18:55] jdstrand: I disagreed with you at the time, but after a few months of messing with dapper and triage, I'm convinced. [18:55] I'm convinced also [18:55] dapper universe = ignored [18:56] +1 [18:56] +1 [18:56] ship it! :) [18:56] +7 [18:56] hehe [18:56] what about hardy? [18:56] 9 votes for! [18:56] intrepid is eol on april 30th [18:56] jdstrand: hardy isn't eol yet [18:56] jdstrand: you must have meant something I misunderstood :) [18:57] jdstrand: when hardy goes eol on the desktop, we should do the same [18:57] kees: if universe != LTS, then hardy/universe is EOL [18:57] * kees agrees. I think it's a fine policy [18:57] oh, hmm [18:57] mdeslaur: kde in hardy is not LTS [18:57] jdstrand: oh! er, I understood that the way mdeslaur just said it: once desktop is EOL, then treat universe as ignored for an LTS [18:57] kees: that was most of what I was saying [18:58] however, it gets tricky with LTS [18:58] I would rather wait for desktop to get EOL [18:58] (which is a subset of what I was getting at) [18:58] right, so let's treat universe like desktop as far as CVE tracking goes [18:58] mdeslaur: which desktop? gnome, kde, xfce? :P [18:58] desktop==gnome [18:58] what's "kde" and "xfce"? [18:58] heh [18:58] hehe [18:58] * mdeslaur slaps himself for saying that out loud [18:59] we love kde [18:59] I'm fine with universe -> ignored on LTS after 3 years [18:59] I think for triage, we should extend universe triage to match the "desktop" lifetime. [18:59] however, I think 'ignored' is more accurate [19:00] and people can still submit debdiffs on server stuff, which we'll sponsor until the server goes EOL [19:00] (since it really is being ignored by far most of the time) [19:00] shoot, I'll sponsor *anything* if it is ok [19:00] heh [19:01] jdstrand: cool, I've got a gutsy open-jdk debdiff for you to review [19:01] right, "ignored" matches the reality of it most closely. [19:01] not [19:01] mdeslaur: that's not ok :P [19:01] heh [19:01] you've gone TOO FAR! :) [19:01] hehe [19:02] let's summarize our discussion (I'll do it) [19:02] jdstrand: here or offline? [19:03] jdstrand: it should probably get reflected in the UCT README too [19:03] 1. universe CVEs for eol released should follow the eol for the release (ie desktop/universe is 3 years for LTS, 5 years for server/universe, and 18 months everywhere else [19:03] kees: is there a script to set dapper universe to ignored? [19:03] kees: gosh, here-- anyone reading this will need it! :) [19:03] jdstrand: heh yeah [19:04] jdstrand: no, server/universe should be 3 years for LTS [19:04] mdeslaur typed it faster [19:04] jdstrand: we don't have a way of separating desktop from server in universe [19:04] right [19:04] unless someone wants to volunteer, in which case we can revert [19:04] 1. universe CVEs for eol released should follow the eol for the release (ie desktop/universe is 3 years for LTS, 5 years for server) [19:04] (volunteer to figure out the seeds) [19:05] 2. look carefully at MITRE versions. if it has a 'fixed in' or less than, adjust 'upstream' field accordingly. mark later versions as 'not-affected' and earlier as 'needed. be careful and leaves as 'needs-triage' if status is not clear for multiple branches (ie 1.2 vs 1.4) [19:05] er, now we need a summary of the summary [19:05] lol [19:05] 2: +1 [19:05] 2: approved [19:05] 3. use Debian version as 'upstream: released' whenever possible [19:06] 3: use Upstream version as 'upstream: released' whenever possible, but it's okay to use Debian versions too. [19:06] kees' resummary of '1': +1 [19:06] i.e. prefer Upstream over Debian, but don't be shy of Debian versions. [19:06] hmm [19:06] kees: why prefer upstream? [19:06] ah, I didn't get to add a thought I had [19:06] mdeslaur: because it more directly tracks to real fixes in the future. [19:07] 'upstream' can have multiple releases in it [19:07] eg: [19:07] i.e. if 1.3.4 is fixed. 1.3.4-32940 will be fixed too [19:07] upstream: released (1.2.6, 1.4.0rc1) [19:07] ok, I don't have a preference there [19:07] jdstrand: won't that break scripts? [19:07] jdstrand: yeah, we skipped that a bit. I'm not sure how to handle it. sync-from-versions skips anything with a comma in it. [19:07] mdeslaur: it is already supported [19:07] is it? [19:07] oh, err [19:08] I did not know that! [19:08] well, I can't speak to sync-from-versions [19:08] I don't use it-- multiple versions works in other places [19:08] we could add the seris logic to sync-from-versions [19:08] (and there are plenty of examples in UCT) [19:09] ok, on '3': use Debian version as 'upstream: released ()' where appropriate [19:09] jdstrand: why prefer Debian over Upstream? [19:10] though in the past, if I have a choice between 1.2.3-1 and 1.2.3, I chose 1.2.3-1 every time [19:10] that'll miss 1.2.3-0ubuntu1 [19:10] kees: my resummary of '3' intended to not prefer Debian 'ie 'as appropriate') [19:10] which is why I like Upstream [19:11] How about debian if it's a version lower than upstream? [19:11] ie: Upstream: 1.2.3, Debian: 1.2.2-14, prefer debian [19:11] kees: yes, but when I have done that I have looked at the version in lucid). I'm convinced though [19:11] reresummary: [19:12] 3. prefer prefer upstream version to Debian version in 'upstream', except where it is fixed in Debian and no info on upstream version is available [19:12] s/prefer// [19:12] mdeslaur: yeah, that's cool; that's basically how it works out. usually I use a Debian version if it says "broken in 1.2.3" (i.e. no upstream fix yet) and Debian has released 1.2.3-2 with a patch. [19:12] 3: +1 [19:12] * jdstrand nods [19:13] alright, I'll add all this to UCT/README and we can finetune from there. I think this has taken enough time [19:14] I have one other item that won't be nearly as contentious :) [19:14] ready! [19:14] just so we can get started, kees: is there a script that can mark dapper universe as ignored? [19:14] jdstrand: shoot [19:14] mdeslaur: there's a commandline, one sec [19:14] isn't that in UCT/README already? [19:14] jdstrand: yeah [19:14] mdeslaur: it's under "Stable Release Actions" [19:14] adjust devel_ to dapper, etc [19:15] in lucid, apt is frustrating for me [19:15] wait, sync-from-eol.py ? [19:15] * jdstrand waits on changing the subject [19:15] mdeslaur: yes! check sync-from-eol.py -- it'll need adjustment [19:16] ok, thanks [19:16] I'll take a look [19:16] okay, I'm ready for subject change [19:16] well, now I have a question on the last thing [19:16] what are we changing dapper/universe to? eg: [19:17] dapper_foo: needed -> dapper_foo: ignored (reached end-of-life)? [19:17] sync-from-eol isn't mentioned in README [19:17] mdeslaur: there is an 'End of Life' section in README [19:17] it may need to be adjusted [19:18] ok, I'll check it out [19:19] 13:16 < jdstrand> what are we changing dapper/universe to? eg: [19:19] 13:17 < jdstrand> dapper_foo: needed -> dapper_foo: ignored (reached end-of-life)? [19:19] kees, mdeslaur: ^ [19:19] well, I wouldn't put "end-of-life" there [19:19] jdstrand: yup, agreed. ignored (reached end-of-life) [19:19] oh [19:19] I'd just set it to "ignored" [19:19] technically, server packages in universe are not end-of-life [19:20] sync-from-eol.py sets it to "ignored (EOL)" [19:20] mdeslaur: why? we've done '(reached end-of-life)' in the past for supported? [19:20] jdstrand: not sure what you mean by that [19:21] kees: I think if we state the reason, we should use '(reached end-of-life)' instead of '(EOL)'. less jargony [19:21] jdstrand: +1 [19:21] mdeslaur: you want 'ignored'. I want 'ignored (reached end-of-life)'. why do you prefer yours over mine? [19:21] on dapper, server packages in universe are not technically end of life [19:22] I now of only one that receives regular support: clamav [19:22] s/now/know/ [19:22] I think 'ignored' will make people go, 'why?' [19:23] mdeslaur: that was my original objection, but I gave in since "ignored" matches reality for it. [19:23] hmm [19:23] we/the community can triage/retriage away from ignored if desired [19:23] let me think a sec [19:23] this isn't set in stone or anything [19:23] * mdeslaur smells burning [19:24] we run sync-from-eol only once per cycle [19:24] ok, I accept [19:24] EOL it is [19:24] +1 [19:24] we can adjust boilerplate to ignore dapper/universe but we always have the opportunity to edit it [19:25] ok cool [19:25] so, now we are ready for my next item? [19:25] yes! [19:25] ok [19:25] apt is frustrating to me in lucid because it tries to be too smart. maybe I am doing things wrong, but when I do this: [19:26] apt-get source foo= [19:26] it will often (though not always) grab the latest version [19:26] jdstrand: yes, drives me insane. [19:26] adjusting the ordering of sources.list can help somewhat, but not totally [19:27] fake-security-sync is basically broken until you hack your sources.list [19:27] jdstrand: I worked around it with: $UST/package-tools/u-getsrc [19:27] * jdstrand goes to look [19:28] is there a bug open for that issue? [19:28] mdeslaur: it is by design [19:28] it is so you can do things like: [19:28] deb http://localmirror/... [19:28] deb http://archive.ubuntu.com/... [19:28] jdstrand: oh, perhaps it's just the addition of --only-source that fixes it? [19:29] it will get from the local mirro runless a newer version is in archive.ubuntu.com [19:29] how the heck can that be by design if you specify a version [19:29] kees: I was going to ask about that-- it is in no way clear to me why u-getsrc works better [19:29] the design is wrong :P [19:29] jdstrand: can you reproduce this? I don't see this problem. [19:30] mdeslaur: oh yes-- the changes are by design, this issue may not be and may be a bug (sorry) [19:30] kees: if I have deb-src lines for ubuntu and debian, then I can see it [19:31] kees: do you have deb-src lines for everything? [19:32] eg [19:32] jdstrand: I do, yes. [19:33] well, I'll try to reproduce and it can be discussed outside of the meeting [19:33] I'm done [19:33] okay, cool. anything else? [19:33] nopers [19:33] anyone? [19:33] Bueler? Bueler? [19:34] meeting over, thanks everyone! :) [23:58] * genii makes a large pot of coffee, hands out the mugs [23:59] ohhh. free mugs [23:59] free coffee! [23:59]