[03:09] wow [03:09] enough recipe mail today? [03:57] lifeless: I know about bzr builddeb's import-upstream, but I heard you mention 'import-tar' (sic) once. Is that something different? [03:58] yu[p [04:06] so I'm trying to push a pipeline to somewhere else with bzr sync-pipeline [04:06] but "bzr sync-pipeline bzr+ssh://lorien/path/to/dir" gives me "bzr: ERROR: Pipeline has no pipe named "dir"." [04:06] I guess I'm doing it wrong? [04:07] whats a pipeline? o.o [04:11] http://wiki.bazaar.canonical.com/BzrPipeline [04:18] mmm, okay, did bzr init on the remote location [04:18] and now sync-pipeline seems to have worked [04:19] yay [04:29] hmm, spoke too soon, that made a complete mess [04:29] i dont know much about pipelines =/ [04:39] okay clearly I don't understand how to use sync-pipeline :/ [04:40] someone more knowledgable can probably help [04:40] although they might be in bed o.o [04:40] I should be in bed too, it's 06:40 here [04:40] lol [04:40] bed [06:02] hi guys ! [06:02] meh, hi girls and guys ! [06:19] * idnar attempts to learn bzr-colo [06:19] hey vila [06:23] * fullermd is shocked at the discrimination against neuters... [06:45] fullermd: :) [06:58] hi * [06:58] morning all [06:59] meeting now or in an hour? [06:59] hi jam, jelmer, mgz [06:59] good question [06:59] * jelmer was wondering about that too :) [06:59] hey . [06:59] according to my mail it would be in an hour [06:59] I'm around, but officially we were keeping the UTC time [06:59] but, if everyone's here, we could go now [07:00] wfm [07:02] wfm, although I still have to finish the mumble setup dance.. [07:03] jelmer: I can see that ;) [07:03] hah, it works :) [07:03] is Riddell on yet? he's an hour later with me [07:07] mgz: good point, should we just wait then ? [07:09] Branches are also hidden if they have the option "bzr.branch.status" set to [07:09] "Hidden", "Merged" or "Abandoned". [07:09] how does bzr.branch.status get set? [07:17] vila, i don't see riddell yet so we should wait [07:17] idnar, i guess you can set it through 'bzr config bzr.branch.status=Merged', and i think explorer (?) has a thing to set it [07:17] ah okay, so no way to get it from launchpad or whatever [07:22] glitch in the matrix, both mgz and wgz are online [07:24] ha ha, no more. [07:24] jelmer: ping (low priority, just to chat when you get a moment) [07:29] idnar, no, not hooked up === gerard_1 is now known as gerard_ [07:39] AfC: hi [07:41] jelmer: yo [07:42] jelmer: so, I tried, a number of ways, to bzr branch "that tree". They all failed, until I drove it down to [07:42] $ bzr branch -r 1 foreign import [07:43] admittedly it didn't help there is only 1.5 GB of physical memory on that machine, but they all got wedged at ~3.2 GB virtual memory and, interestingly, 315 minutes of CPU time. [07:43] at that point, it was endless swapping. [07:45] I haven't tried it against the tree at the remote server; that's next, but I'm getting closer to feeling I'm going to have to give up. Now that I've got revno 1 it might get a bit better to pull 1 or 10 or 100 revisions at a time. [07:45] end [07:46] AfC: What kind of foreign tree is this with? [07:46] AfC: and what versions? [07:46] jelmer: git [07:46] jelmer: daily [07:47] AfC: hmm, that's odd [07:48] AfC: the launchpad importers probably have about the same resources and can handle the linux kernel [07:49] * jelmer tries locally [07:54] jam: hi [07:54] hi jelmer [07:54] jam: Goeiesmorgens deze morgen! [07:54] jam: I'm trying to figure out something with stacking, perhaps you have an idea [07:54] stacking doesn't work? :) [07:55] sure, go ahead [07:55] jam: in some situations :) [07:56] jam: In short, I'm finding that if I have some revisions in a stacked-on repository and then try to fetch some ancestors of that into the stacked repository things go boom. === mrevell_ is now known as mrevell [07:56] jelmer: [it turns out that I was, in effect, duplicated what vcs-import already did, since `bzr missing --line --mine` reported the same revs. But that's one of the things I needed to establish before using launchpad's branch] [07:57] duplicating* [07:57] AfC: yeah, the imports should be deterministic [07:57] jam: I'm getting an exception from pack_repo during commit_write_group() saying one of the parent texts was missing [07:58] jelmer: In any event, I'm also going to have a go at `bzr import-upstream` across the range of trees that I'm interested in [07:58] AfC: import-stream? [07:58] bzr-builddeb's import-upstream ? [07:59] jelmer: do you have a traceback I can peek at? [07:59] My immediate thought is that fetch doesn't work very well in this situation, because revision discovery will think you already have the data [07:59] jam: http://pastebin.ubuntu.com/702120/ [08:00] jam: fwiw this is with foreign branches [08:00] AfC: Do you mean in addition to importing from Git? Since they do very different things. [08:01] jelmer: from that traceback it looks like all of the logic of what needs to be transmitted is in bzr-svn (the layers of 'fetch' are all svn, just the 'commit_write_group' is bzr) [08:01] jelmer: in addition (separate branch family) yes [08:01] it looks like you fetched the revision texts but failed to fetch the associated file content [08:02] jelmer: lifeless was telling me that I should also look at `import-tar` which is something I'm not familiar with. Not sure what plugin its in, even. But when I find it, I'll try that too [08:02] AfC: Do you mean "bzr import" from bzrtools perhaps? [08:03] jelmer: ah, maybe. Don't [normally] have bzrtools installed. [08:03] * AfC wonders whether I'll have more luck with bzr-builddeb or bzrtools's take on this [08:04] jam: The file content is in the stacked-on repository [08:05] jelmer: just getting static from you [08:06] jelmer: so the immediate thought is that the "do you have references filled in" is only checking the newly created pack files. [08:18] jam: I think that's the crux of the problem. What does filling in the references mean exactly? [08:33] jelmer: looking at the code it sure looks like it is properly checking everything that is in the stacked repo (so not the fallback, but everything in the repository) [08:34] 'filling in the references', if you have a revision it needs an inventory, and it needs all referenced file texts [08:35] jam: ah, hmm. and I shouldn't rely on those being present in a stacked-on repository? [08:35] (well all referenced file texts that aren't in the parent revisions, etc) [08:36] That makes sense, and I'm not doing that at the moment. [08:36] jelmer: well, you said that they were, but Bazaar is saying they aren't [08:36] jelmer: ah, you mean they are in the fallback? [08:36] jam: yes [08:36] no, that is not sufficient [08:36] If a stacked repo has revision X, it needs to have the texts introduced in X [08:36] otherwise it cannot create a stream containing revision X [08:37] without talking to the fallback [08:37] which we require [08:37] but what about texts that weren't introduced in X but are present in X? [08:37] (remote smart server does not have access to its fallback) [08:37] jelmer: if you have rev A parent of rev B, and you have (file_1, A) you don't have to have that content in a stacked repo with just B [08:37] *if* you have the inventory for A [08:38] so that we can tell whether (file_1, A) was present in the parent [08:38] so what you need is set(present_revision_texts) - set(parent_revision_texts) [08:46] jam: So I should fetch the rev A inventory into the stacked repository, even if it's already present in the stacked-on repository? [08:50] Riddell, could you clean up and post those notes? [08:50] poolie: can do [08:50] ta [08:50] poolie: I think I should take a day off bzr sometime this week to check up on Kubuntu, it's their release week [08:51] oh good diea [08:51] *idea [08:51] or even more if necessary [08:54] jelmer: yes [08:57] jam: ok, that makes sense [08:57] jelmer: so if you want to put rev B in a stacked repository, you need to have inventory of A, and all of the texts that are in B that aren't in A [08:58] and B's inventory, of course [09:23] mgz, vila, so https://code.launchpad.net/~jameinel/bzr/drop-idle-connections-824797/+merge/75348 [10:11] jam: What's the easiest way of doing so (fetching an inventory into a repository if it isn't present yet, while excluding any stacked-on repos)? [10:17] vila: sorry, I missed that. What will I disagree with? [10:17] jelmer: making bzrlib.intialize() mandatory [10:18] ah [10:18] yes (though I wouldn't mind make it implicit and warn if it wasn't explicitly called) [10:19] Jelmer's bug? There's just one ? :P [10:19] (I lost my unity panel so I can no longer unmute :P) [10:23] bug 863401 jelmer if you're not already there [10:23] Launchpad bug 863401 in Bazaar "library state now requires explicit initialization" [Critical,In progress] https://launchpad.net/bugs/863401 [10:30] Riddell: thanks for sending the standup notes ! [10:31] how can I see collision merge proposals? launchpad times out on https://code.launchpad.net/~ubuntu-branches/+activereviews [10:31] poolie: it's calm and relaxing to have some typing going on in the background.. :) [10:45] jelmer :) [10:46] like those CDs of sea sounds [10:47] heh, indeed [10:47] jelmer, it's kind of nice, maybe we should stay on mumble during the evenings [10:47] especially if we either get noise suppression right or ptt [10:48] poolie: yeah, it is. I put getting a new headset on my todo list. [10:49] likewise. [10:50] ooh, fancy oops pages with my new team membership [10:52] oh, tracebacks [10:52] "fix me!" [10:52] https://bugs.launchpad.net/launchpad/+bug/866100 [10:52] Ubuntu bug 866100 in Launchpad itself "bug search with affects_me=on times out" [Critical,Triaged] [10:59] poolie: Is that the bug you just "fixed"? :D [11:00] ah, exposed as part of the fixing === yofel_ is now known as yofel [11:10] nigelb, now you can get to that page but it may not render :/ [11:10] poolie: Ouch! [11:11] poolie: why does that happe? I thought search was fast. [11:11] Or at least more efficient. [11:12] oh. I see you're talking to stuart already :D [11:22] jam, i'd appreciate if you can try to help the ohloh guy some more [11:22] with his memory leak [11:30] poolie: sure, I'm guessing it is us just caching more of the indexes, but I'll try to poke at it with him [11:31] hm, I wonder if what I was looking at yesterday was relevent then [11:31] just doing switch created 5 repository instances, 4 of which persisted through the operation, each with five LRUSizeCache objects with a 50MB limit [11:32] that's nearly a gig of potential cache, were they all doing stuff [11:32] (in practice only the texts cache is *that* large) [11:33] but if they're doing things with repos and bzr is giving them new caches each time and the old ones are being hung on to... [11:41] mgz: last warning from PP, if you don't land these proposals, I will ;) [11:45] mgz: more seriously, you proposed a fix for http://bugs.python.org/issue12544 what happened ? [11:48] it landed, but did onieric ever move from the problem python revision? [11:49] and yes yes, I'll land 'em... after lunch [11:50] mgz: Bon appétit ! [11:52] mgz: 50*4 = 200, not quite 1GB [11:53] mgz: also, we tend to have Repository objects that live a bit long because of reference cycles. [11:53] but it would be good to understand why we would have 5 repos opened [11:53] "each with 5..." [11:53] fullermd: 4 persisted [11:53] ah [11:53] 5*5 [11:53] sure [11:53] mgz: yup, oneiric seems to have your patch too (or its moral equivalent: self._type_equality_funcs = {}) [11:55] okay, just one more branch to bother the rm before lunch [11:56] ...dammit, lynx why won't you play nice with launchpad [11:57] s/rm/patch pilot/ [11:57] jam: each time control_dir.anything happens, you get a new repo [11:58] mgz: there are some cases where we allow passing in something new [11:58] I don't remembe rexactly where [11:59] mgz: they happen to be the same this week ;) [12:02] mgz: were bugs #866107 and bug #866111 supposed to be assigned to you? [12:02] Launchpad bug 866107 in Bazaar "Use testresources for bzr selftest" [Medium,Confirmed] https://launchpad.net/bugs/866107 [12:02] Launchpad bug 866111 in Bazaar "Run tests against out of process smart server" [Medium,Confirmed] https://launchpad.net/bugs/866111 [12:05] ...I'll take the first one [12:05] the second one I find a little more scary [12:06] okay, patch pilot bothered, lunch must be had. [12:09] mgz: approved [12:20] mgz: I just didn't know whether you were only filing them, or they were supposed to be assigned to you [12:20] not a big deal [12:26] jam: what's the easiest way to make sure inventory X is present in a repository itself (rather than any of its stacked repositories) ? [12:26] jelmer: X in repository.inventories._index.get_parent_map([X]) [12:26] or you can use the "inventories.no_fallbacks().get_parent_map()" [12:27] jam: Ah, and just call repo.add_inventory() if it's missing? [12:28] jelmer: generally i would add it as part of the record stream, but I'm not sure how it works with bzr-svn [12:29] doing add_inventory is going to be a serialization/deserialization overhead [12:29] jam: ah [12:29] maybe add_inventory_by_delta? [12:29] jam: I'm already using add_inventory_by_delta to add the revision I'm fetching [12:29] jelmer: then you can chain that to add the parent inventory [12:29] I believe that add_inventory_by_delta can use any basis [12:29] it doesn't have to be a direct parent/child/sibling [12:30] jam: This is about making sure the basis is in the repo I'm calling .add_inventory_by_delta on [12:30] jelmer: note that delta basis can also be 'null', but that is the same as doing just raw add_inventory() [12:30] jelmer: so you are adding the inventory for B, what is the basis for that delta? [12:31] jam: A, but A could be in my target repository or one of A's stacked repositories [12:31] jam: A, but A could be in my target repository or one of A's fallback repositories [12:33] sorry, not sure what's up with my typing today [12:33] jam: A, but A could be in my target repository or one of my target repository's fallback repositories [12:34] mgz: do you have 'feed-pqm' set up from hydrazine? I'm just going through and sending your approved patches to pqm [12:34] hopefully not stepping on toes [12:34] but I'm there already [12:35] vila: it says your 863401-library-state has been sent. Did it bounce? [12:35] I don't see anything in pqm right now [12:38] look again ? [12:43] vila: I see 2 that I submitted [12:43] neither is yours [12:44] vila: maybe it bounced but you didn't get the reply? [12:44] want me to submit it? [12:45] looks landed to me [12:48] jam: Please have another look at https://code.launchpad.net/~jelmer/bzr/more-foreign-tests-fixes-7/+merge/76776 when you have a moment [12:56] vila: it was still in "sent to pqm" on feed-pqm, maybe it just hadn't updated yte [12:56] yet [12:56] yep, looks like [12:56] I just hit it inbetween pqm finishing it, and launchpad noticing [12:57] hm, the release notes file could do with some sorting out [12:57] maybe I shouldn't try and sneak in news pqm lands the next branch [12:57] +before [13:11] mgz: pqm only takes about 30min, you can just put up a news fix [13:14] ah, missing the day of slow pqm... [13:23] ah, I see the ohloh thing now, twas a question not a bug [13:25] if he's running cmd_cat repeatedly, he's going to be getting a new cache each time, no jam? [13:25] mgz: he isn't [13:25] he changed it [13:25] if you read the follow up [13:25] but yes, the original suffered from stuff like that [13:26] yeah, I'm behind, getting there... [13:34] hm, landing the server hangs branch and the test cleanup branch so close to each other may have not been a good idea [13:48] vila: more-foreign-tests-fixes-{7,9} are both ready for review [13:49] jelmer: on them [13:54] jelmer: balloon ? :) [13:55] jelmer: is that some kind of crocodile to check the reviewer actually read your proposal ? ;-P [13:55] vila: that test was already there, I just moved it :) [13:55] oh, ok, not there yet then ;) [13:55] ha right, just after [14:00] jelmer: -9 approved [14:03] why so forceful vila? [14:04] hehe, took me two readings :) [14:04] jelmer: -7 approved [14:04] vila: merci! [14:30] jelmer: your foreign-tests-7 has 3 errors [14:37] jam: thanks, having a look now.. [14:49] hmm, the other one also has 3 failures [15:10] the pqm failure for my cleanup testcases branch is the stuff of nightmares [15:11] there's one failure. it's on *one* of the three iterations of test_random_seed and the other two pass. the failure output make no sense at all. [15:24] mgz: you ignored the expected failures right ? [15:26] yup, though they still confused me at first [15:27] found one actual issue with the code, the way tests get counted needs sorting out after adopting Robert's method of injecting extra testcases [15:35] mgz: where is this test ? [15:36] mgz: oh, the one about selftest itself ? [15:37] I'll paste in the mp. [15:38] k [15:45] posted. [16:00] okay, result.shouldStop is getting set somehow... [16:00] which still doesn't really explain the weirdness, but needs afixing [16:11] ubuntu is making fun of me: The program 'selftest' is currently not installed. You can install it by typing: [16:11] sudo apt-get install yagiuda [16:12] mgz: can' reproduce locally, any hint in stderr ? [16:14] nope. straight up unrepoable. [16:15] but I'm fixing this other bug, and may do one more tweak before trying PQM again [16:15] get rid of it, file a bug if you wish unless you're really using it to trigger more related issues, almost nobody use random [16:16] but in any case, it doesn't sound worth delaying the bulk of the patch just for that === beuno is now known as beuno-lunch [16:18] okay, got this one. [16:21] does PQM fork vila? [16:27] no [16:27] we'd like to eventually [16:28] ... but we recently went from several hours to 30 mins, we need to recover a bit from the shock [16:30] * vila EODing [16:30] almost :) [16:31] Hi. I have changes in my working tree, however I don't want to commit them to the branch I'm currently on. [16:31] However, bzr switch will not let me switch with "unmerged changes" and bzr shelf --all says "bzr: ERROR: Tree transform is malformed [('missing parent', 'new-8'), ('missing parent', 'new-2'), ('missing parent', 'new-3')]" [16:31] What to do? [16:32] jonnor: see the shelve command [16:32] briandealwis: shelve is what I tried, and failed as show above [16:33] oops sorry jonnor — missed that :/ [16:33] actually, I've seen that before too, and neglected to file a bug [16:33] my changes are actually from an uncommitted commit if that matters [16:35] jonnor: bzr version ? [16:35] vila: Bazaar (bzr) 2.4.1 [16:36] >-/ [16:36] jonnor: please file a bug [16:38] jonnor: 'shelf' was a typo right, you really meant 'shelve' (there was a shelf command long ago in bzrtools) [16:39] vila: yes [16:39] I have no idea on how to reproduce this issue though [16:43] jonnor: file a bug anyway, adding the relevant part of your .bzr.log file will give some data [16:51] vila: ok [16:52] Is it expected that bzr commit after an attempted merge does not have any metadata like the commit message of the commit that failed to merge? [16:57] it seems probable that https://bugs.launchpad.net/bzr/+bug/611739 is the bug I experienced [16:57] Ubuntu bug 611739 in Bazaar "shelve problem on shelving directory with ignored file inside" [Medium,Confirmed] [17:02] blast, didn't get to reviewing benoit's branch today. [17:03] ah well, tomorrow [17:19] mgz: Just crossed my mind, you know pqm is running old versions of testtools and subunit right ? [17:20] hello all. how do you run the tests (or better, a specific test) from the bzrlib testsuite ? === beuno-lunch is now known as beuno [17:21] aidos: bzr selftest -s bzrlib.tests.blackbox.test_push will run only the tests whose name starts with bzrlib.tests.blackbox.test_push [17:22] aidos: some short prefixes are available: bt -> bzrlib.tests, bb -> bzrlib.blackbox, bp -> bzrlib.plugins [17:23] vila: thanks. but is that going to run the testsuite from my installed bzr version, or from the branch I got from launchpad ? [17:24] vila: it seems strange that I need to call bzr to run tests, especially for bzrlib where i just want to add a test to some osutils.py functions [17:28] aidos: ./bzr will run from sources, but you probably want to run 'make' before to build the extensions [17:37] vila: thanks, now my test fails as expected, now onto the bugfix :) === med_out is now known as medberry [19:10] Hellooooo there :) Is there any list of apps (eg wikis) that can *sit* on a DSCM like Bazaar (using it as underlaying storage) ? Myself in particular, I'm looking for a collaborative task manager ^^ [19:17] caravel, there's wikkid [19:17] which is a wiki engine backed-up by bzr [19:22] beuno: yes thanks, I found this one indeed -- somehow I didn't find any ref on it at bazaar website (google helped me find it). [19:22] Besides, it doesn't advertise to be stable yet. [19:22] Are you people aware of more tapps of this knd, especially oriented to manage *tasks* ? [19:23] *apps [19:23] *kind (etc., sorry typing too fast) [19:23] ikiwiki too [19:25] james_w: hey thanks, I had "lost" that one ^^ [19:28] here we go, I'm lost in its plugin list again := [19:30] would you reckon a wiki could be turned to an efficient-enough task manager somehow ? ^^ [19:34] http://ikiwiki.info/todo/interactive_todo_lists/ [19:58] caravel: I'd recommend an issue tracker instead [19:59] and I do not see any reason to care about whether the underlying storage tech on a dscm === medberry is now known as med_out [20:12] jonnor: well, I do. :) To start with, stricly speaking about SCM, what are your reasons to use a DSCM ? [20:18] caravel: so I have full access to the history, and can add to the history without having to make these changes public or be connected to a central location [20:19] jonnor: well, I have the same requirements for managing tasks, simply ^^ [20:20] plus the will to push my changes, obviouly [20:21] caravel: how will conflicts be resolved? [20:26] jonnor: how do you solve conflicts with bzr, rsync, iFolders (...) or these 2 wikis running on top of a DSCM ? Well, you need conflifts brought to your attention, access to history, then manual resolution. How is this different to files ? A task manager that would store each task and each category as a single file on disk, would suit I think. But I didn't find any ^^ [20:29] caravel: it is just something you need to thing about when you decide on the solution. If it is OK for your users having to resolve conflicts line-by-line in text files, then something on top of dvcs might work ok === med_out is now known as medberry === medberry is now known as med_out [21:41] icalendar files are pretty readable [21:43] I used conics for todos for a while, replicated with bzr, I even forked it to add yaml export/import for easy editing [22:07] hi all [22:07] ccxCZ: thanks for your hints, will investigate [22:09] for issue tracker I find roundup interesting, but that's mail-based mostly [22:11] hey poolie. [22:16] hi there [22:18] what's the current contributor agreement arrangement? [22:19] I got Florian to do a more comprehensive version of his fix, hopefully that doesn't mean he now needs to print a pdf and find a scanner [22:19] wgz, just an email with an attachment is enoguh [22:20] the page is wrong and will soon be updated, if it's not already [22:20] that's a relief. [22:24] yes [22:37] 'morning poolie, ɯgz [22:38] poolie: how do I find merge proposals filed by udd importer? [22:38] ehe jelmer, I'm not sure freenode would let me have that [22:39] Riddell, funny you should ask, i was just adding that to the bug [22:39] it even doesn't always time out [22:40] I tried various likely pages under ~ubuntu-branches and they all timed out [22:40] https://code.launchpad.net/~ubuntu-branches/+activereviews does seem to work for me at the moment [22:40] it's a quiet time of day for lp [22:42] Timeout error here, a curious case of launchpad working better for australia than for britain [22:50] hit reload a few times :/ [22:50] urk, there's lots of fallout from my commit message change in bzr-builddeb jelmer? [22:50] wgz: oh? [22:51] I'm looking at bug 865753 and bug 867808 and wondering if they're running versions with that change [22:51] Launchpad bug 865753 in bzr-builddeb (Ubuntu) "bzr-builddeb: UnicodeDecodeError" [High,Triaged] https://launchpad.net/bugs/865753 [22:51] Launchpad bug 867808 in bzr (Ubuntu) "bzr crashed with UnicodeDecodeError in _escape_cdata(): 'ascii' codec can't decode byte 0xc5 in position 11: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/867808 [22:51] Riddell: with the number of ~canonical-bazaar staff folks around at midnight UTC it doesn't quite seem like quiet time ;) [22:52] http://sp.reddit.com/heavy-mallet.gif [22:53] ubot5: your change is only in bzr-builddeb 2.7.9 [22:53] wgz: your change is only in bzr-builddeb 2.7.9 [22:53] * wgz is a bot too, the real mgz is sensible and already asleep so he can get up on time tomorrow [22:54] bug 86708 is with 2.7.0, so it shouldn't be relevant to your change [22:54] Launchpad bug 19066 in firefox (Ubuntu) "duplicate for #86708 Pango-enabled firefox breaks MathML support" [Medium,Fix released] https://launchpad.net/bugs/19066 [22:54] perhaps it's even fixed by it [22:54] wgz: the other bug doesn't seem related to your fix either, apart from being a unicode issue too [22:55] hm from the debian report, that first is different indeed. [22:55] and maybe I'm just being paranoid about the second. [22:55] wgz: your nickname is really annoying, xchat keeps suggesting "wgrant" :) [22:56] wgz: see the BzrPlugins.txt attached on the second [22:56] ah yes, 0 is not 9. woho! [22:59] . o O (No wonder I can't sleep, they are all up too) [23:08] whoa :) [23:16] * Riddell offers vila some coffee