| TheMue | morning | 07:27 |
|---|---|---|
| fwereade | heya TheMue | 07:29 |
| TheMue | fwereade: just went outside on our veranda to work there. the nice side of home office. | 07:30 |
| rogpeppe | fwereade, TheMue: mornin' | 07:35 |
| TheMue | rogpeppe: heya | 07:35 |
| fwereade | heya rogpeppe | 07:44 |
| fwereade | TheMue, sounds lovely :) | 07:45 |
| fwereade | TheMue, I find my balcony is just too damn hot/bright at the times I'd generally want to work out there, but hey ho | 07:45 |
| rogpeppe | ah, sun, i have vague memories of that. | 07:46 |
| * rogpeppe looks out at yet another grey wet day | 07:48 | |
| TheMue | Hope that the weather next week is fine. | 07:55 |
| rogpeppe | me too | 07:55 |
| rogpeppe | fwereade: niemeyer is suggesting that UploadTools becomes part of PutFile's functionality. i'm not quite sure how that'll work though, as there are two possible places to put and get things. | 07:56 |
| rogpeppe | fwereade: i'm wondering what you thing | 07:56 |
| rogpeppe | think | 07:56 |
| fwereade | rogpeppe, sorry, which are the places? I saw that suggestion, looked sane at first glance | 07:56 |
| rogpeppe | fwereade: if you're a user, you get the tools from a public place, but you get bootstrap info from a private place | 07:57 |
| fwereade | rogpeppe, ah, I'd had a vague assumption that the "local" version of the tools would always be stored in filestorage, and that would be the canonical location for that particular deployment, regardless of original source | 07:58 |
| fwereade | rogpeppe, like charms (right?) | 07:58 |
| rogpeppe | fwereade: i don't think every user should be charged with 5MB+ of uploads every bootstrap | 07:59 |
| rogpeppe | fwereade: it slows it down apart from anything else. | 07:59 |
| fwereade | rogpeppe, well, it wouldn't *necessarily* have to go through the user's machine (although not doing so would be somewhat fiddlier) | 07:59 |
| rogpeppe | fwereade: it would using that API | 08:00 |
| rogpeppe | fwereade: and in fact i'm not sure it's possible to initiate S3->S3 transfers without involving either a new machine in the cloud or shuttling the data through the local machine | 08:01 |
| rogpeppe | but there might be i guess | 08:01 |
| rogpeppe | interesting: http://docs.amazonwebservices.com/AmazonS3/latest/API/RESTObjectCOPY.html | 08:03 |
| fwereade | rogpeppe, I'd been thinking that in the local case, we upload somewhere and somehow communicate "there" to the bootstrap machine; which would always copy the juju files to the canonical location, regardless of source (but yeah, that could maybe shortcut it) | 08:03 |
| fwereade | rogpeppe, (it actually feels like things could be a bit annoying if we upload to the canonical location directly from the client) | 08:04 |
| rogpeppe | fwereade: by "the canonical location" are you thinking of a file path or a URL? | 08:04 |
| fwereade | rogpeppe, URL | 08:04 |
| rogpeppe | fwereade: so in the local case you're suggesting we store the binaries at two URLs? | 08:05 |
| rogpeppe | fwereade: one for the initial upload and one "canonical" place? | 08:06 |
| fwereade | rogpeppe, I'm not sure it's *actually* necessary to do so, and I think it's an implementation detail | 08:06 |
| rogpeppe | fwereade: i'm not sure i see the advantage in doing so | 08:06 |
| fwereade | rogpeppe, I'm really just saying that I don't think a deployment-local copy of the source code necessarily involves copying publicly available stuff through the user's machine | 08:07 |
| rogpeppe | fwereade: we've got to copy things *from* the user's machine, right? | 08:08 |
| fwereade | rogpeppe, only in dev mode, surely? | 08:08 |
| rogpeppe | fwereade: yeah, sorry i thought that's what you meant by "deployment-local' | 08:08 |
| rogpeppe | " | 08:08 |
| fwereade | rogpeppe, ha, sorry | 08:09 |
| rogpeppe | fwereade: why would non-devs need a deployment-local copy of the source code? | 08:09 |
| fwereade | rogpeppe, I'm just having a quick look at the python to remind myself of something | 08:09 |
| rogpeppe | or the binaries, come to that? | 08:09 |
| fwereade | rogpeppe, I'm not privy to the details of the original discussions; my only non-waffly/hedged argument is "because we decided to do that for charms", and I'm not convinced the two cases are different enough to warrant inconsistency ;) | 08:13 |
| fwereade | rogpeppe, it doesn't feel to me like an intrinsically bad thing for a deployment to pull in all its dependencies as they become apparent, though | 08:14 |
| fwereade | rogpeppe, it should I think just make things a little less dependent on the vagaries of the wider internets ;) | 08:15 |
| fwereade | brb | 08:15 |
| === lynxman- is now known as lynxman | ||
| rogpeppe | fwereade: yes, i agree with that. and it seems like the storage cost of storing the tools once per deployment is small. | 08:18 |
| rogpeppe | fwereade: however... | 08:18 |
| rogpeppe | fwereade: what about multiple architectures/OS versions etc? | 08:19 |
| fwereade | rogpeppe, sorry, not sure: what about them? won't we potentially need copies for each, whatever we do, independent of anything else? | 08:26 |
| rogpeppe | fwereade: so you're suggesting that every time we add a unit, we potentially copy toos to the local provider storage | 08:27 |
| rogpeppe | ? | 08:27 |
| rogpeppe | s/toos/tools/ | 08:27 |
| fwereade | rogpeppe, I think so; just like we do on deploy, right? | 08:28 |
| rogpeppe | fwereade: this wasn't the plan i'd understood. but maybe it's a good thing to do. | 08:28 |
| fwereade | rogpeppe, hm, I don't think it's necessarily intrinsically incompatible with what we'd discussed | 08:29 |
| rogpeppe | fwereade: i'd thought that upload-client was an explicit flag that we would give | 08:29 |
| fwereade | rogpeppe, I think we have a bit of freedom to do dev/real slightly differently | 08:30 |
| rogpeppe | fwereade: how would dev and real be different? | 08:31 |
| fwereade | rogpeppe, I'd seen the upload-client flag as an explicit I'm-in-dev-mode thing | 08:31 |
| rogpeppe | fwereade: me too. but i think you're suggesting that real deployments do something similar? | 08:32 |
| fwereade | rogpeppe, I'm suggesting that deployments should internally take responsibility for distributing juju binaries just as they do with charms | 08:33 |
| fwereade | rogpeppe, and that the dev mode stuff simply give devs an opportunity to hook into that mechanism at a useful point | 08:33 |
| fwereade | rogpeppe, it may ofc be that the charm-distribution strategy is a historical accident and I'm entirely on crack | 08:34 |
| rogpeppe | fwereade: how do we deal with different charm versions for different platforms? | 08:35 |
| fwereade | rogpeppe, I don't think we do | 08:35 |
| rogpeppe | fwereade: 'cos that's something we need to deal with for juju tools | 08:35 |
| fwereade | rogpeppe, I think that's up to the charm authors | 08:35 |
| rogpeppe | fwereade: i thought so | 08:36 |
| fwereade | rogpeppe, and yes, I see that they're not 100% the same situation | 08:36 |
| fwereade | rogpeppe, (well, in a sense we do, in that we have separate oneiric and precise versions of some charms, and that means they carry a different identifier) | 08:36 |
| rogpeppe | fwereade: but not, say, 386 vs amd64 vs arm? | 08:37 |
| fwereade | rogpeppe, there's nothing stopping me running wordpress on precise and oneiric in the same deployment, although I'm not sure why I'd want to | 08:37 |
| fwereade | rogpeppe, no; I think the core idea of variation is still in there | 08:37 |
| rogpeppe | fwereade: so... if we go this direction, how does the initial bootstrap happen? | 08:39 |
| rogpeppe | fwereade: bootstrap init pulls from a URL and pushes to local provider storage? | 08:39 |
| fwereade | rogpeppe, I think so, yes | 08:39 |
| rogpeppe | fwereade: maybe that only needs to happen when the first unit is deployed. | 08:42 |
| fwereade | rogpeppe, yeah, I think so; it feels sensible to me to keep using the same versions everywhere until we're told to upgrade | 08:42 |
| fwereade | rogpeppe, (but then I also think it makes sense to be lazy about grabbing (say) the 2.4.2 ARM binaries until we actually dpeloy to ARM | 08:43 |
| fwereade | ) | 08:43 |
| rogpeppe | fwereade: yeah. that's where i was coming from. | 08:44 |
| fwereade | rogpeppe, I'm just not quite sure where that fits in with dev mode | 08:44 |
| rogpeppe | fwereade: indeed. i'm all a bit confused about how things would work exactly now. | 08:45 |
| fwereade | rogpeppe, but a build-absolutely-everything script, and a dev-mode bootstrap that pushes everything, sounds, well, plausible at least | 08:45 |
| fwereade | rogpeppe, I'm definitely drawing heavy inspiration from how charm publishing works atm | 08:46 |
| fwereade | rogpeppe, er, in python, not in the store | 08:46 |
| fwereade | rogpeppe, that's something that appears to "just work" pretty well | 08:47 |
| fwereade | rogpeppe, but I am suddenly starting to worry that there are enough subtle differences that I've led myself astray | 08:48 |
| rogpeppe | fwereade: so... is this about right: when you want to deploy a service, an agent (the machine agent?) pulls the charm from a URL and pushes to the local provider storage. then when a unit starts, the unit agent pulls the charm from local provider storage and runs it? | 08:48 |
| fwereade | rogpeppe, unless I've really missed something, the charms even from the store round-trip through your local machine | 08:49 |
| rogpeppe | fwereade: i don't know. the main significant difference AFAICS is that there are no bootstrapping issues with charms. | 08:49 |
| fwereade | rogpeppe, I consider this to be sucky *but* an implementation detail | 08:49 |
| rogpeppe | fwereade: really? | 08:49 |
| fwereade | rogpeppe, pretty sure | 08:49 |
| rogpeppe | fwereade: i'd prefer that not to be true for the tools. they're 10MB already and will be larger. | 08:50 |
| fwereade | rogpeppe, "charm = yield repo.find(charm_url)" | 08:50 |
| fwereade | rogpeppe, hence my talking about it being an implementation detail | 08:50 |
| fwereade | rogpeppe, hm wait a mo | 08:50 |
| fwereade | rogpeppe, no, I'm right, repo.find downloads | 08:51 |
| fwereade | rogpeppe, I'd prefer also that it not be true for the charms | 08:51 |
| rogpeppe | fwereade: agreed. | 08:51 |
| fwereade | rogpeppe, but I think that in neither case is it actually *necessary* that the publicly available stuff be downloaded | 08:52 |
| fwereade | rogpeppe, I'm suggesting the philosophy is worth copying not the implementation | 08:52 |
| rogpeppe | fwereade: i think i agree. i'm just trying to work out what it means. | 08:57 |
| rogpeppe | fwereade: how's this for a sketch: http://paste.ubuntu.com/956991/ | 08:59 |
| rogpeppe | fwereade: actually, one slight mod: http://paste.ubuntu.com/956997/ | 09:00 |
| fwereade | rogpeppe, in essence yes; I think there are maybe some arch-related subtleties around the "version" there, but I think-hope they're impishdetails rather than fully devilish ones | 09:00 |
| rogpeppe | fwereade: what kind of things are you thinking of there? | 09:01 |
| fwereade | rogpeppe, I *think* it'll only be an issue in dev mode | 09:01 |
| fwereade | rogpeppe, and I think as a dev I can put up with building everything I plan to need for my env before bootstrapping and just splurging them all up there at bootstrap time | 09:02 |
| rogpeppe | fwereade: yeah. i think you have to. | 09:03 |
| fwereade | rogpeppe, with that assumption in place it feels like it'd work | 09:03 |
| rogpeppe | fwereade: and you *can't* deploy to a version with a different arch if you want to use your local version | 09:03 |
| rogpeppe | s/deploy to a version/deploy to a machine/ | 09:04 |
| fwereade | rogpeppe, hmm, can't we cross-compile? | 09:06 |
| rogpeppe | fwereade: not if we want to use DNS. | 09:07 |
| rogpeppe | (DNS uses cgo, which means that we need the dynamic libraries available when we compile) | 09:07 |
| fwereade | rogpeppe, ty | 09:08 |
| fwereade | rogpeppe, but this means we are actually not able to cross-compile at all? | 09:08 |
| rogpeppe | (i might be wrong about some of the details there) | 09:08 |
| rogpeppe | fwereade: pretty much, yeah. | 09:08 |
| fwereade | rogpeppe, I'm comfortable avoiding a deep-dive on the subject, that sounds like the critical issue | 09:09 |
| rogpeppe | fwereade: well... no, you can, and it's dead easy | 09:09 |
| fwereade | rogpeppe, ah ok... | 09:09 |
| rogpeppe | fwereade: but you don't get certain packages | 09:09 |
| fwereade | rogpeppe, ah, got it; so DNS really did mean DNS :) | 09:09 |
| rogpeppe | fwereade: the go compiler is always a cross compiler too | 09:09 |
| fwereade | rogpeppe, so I had thought :) | 09:09 |
| rogpeppe | fwereade: yeah. | 09:09 |
| rogpeppe | fwereade: the problem is that on some platforms you just can't do everything by invoking syscalls | 09:10 |
| rogpeppe | fwereade: there's magic in the local libraries too, so you need to call them. | 09:10 |
| fwereade | rogpeppe, that said I think we touchedon it in the thread and niemeyer agreed that no-foreign-dev-builds was an acceptable tradeoff for now anyway | 09:10 |
| fwereade | rogpeppe, ha, ok | 09:11 |
| fwereade | rogpeppe, TheMue: https://codereview.appspot.com/6129053 | 12:34 |
| fwereade | ...and lunch | 12:34 |
| TheMue | fwereade: enjoy | 12:35 |
| rogpeppe | fwereade: reviewed | 13:16 |
| fwereade | rogpeppe, tyvm | 13:17 |
| rogpeppe | fwereade: i've updated the uploadtools proposal in the light of gustavo's comments, which i think are compatible with the result of our discussion earlier. https://codereview.appspot.com/6128046/ | 14:47 |
| fwereade | rog, cheers | 14:48 |
| rogpeppe | (it's a pity that codereview/lbox doesn't deal with file moves well) | 14:48 |
| * rogpeppe just deleted >70 lines of slightly dubious code. oh, the pleasure! | 15:15 | |
| rogpeppe | make that >100 | 15:16 |
| niemeyer | Hello! | 15:31 |
| niemeyer | fwereade, rogpeppe, TheMue: Anyone around still? | 15:32 |
| rogpeppe | niemeyer: yo! | 15:32 |
| rogpeppe | niemeyer: i think we all are, probably | 15:33 |
| rogpeppe | niemeyer: we could even have our start-the-week meeting maybe | 15:33 |
| rogpeppe | niemeyer: how's things in californeye-ay? | 15:33 |
| TheMue | niemeyer: Heya. | 15:33 |
| niemeyer | rogpeppe: Probably not today, at least.. we're about to have the kick off talk by Mark | 15:34 |
| rogpeppe | niemeyer: k | 15:34 |
| TheMue | rogpeppe: BBQ is already hot here. | 15:34 |
| niemeyer | rogpeppe: I could wake up earlier tomorrow so we can do it, though | 15:34 |
| niemeyer | TheMue: Nice :) | 15:34 |
| rogpeppe | TheMue: sounds like you've got nice weather. jealous! | 15:34 |
| rogpeppe | niemeyer: that sounds good | 15:34 |
| TheMue | niemeyer: Yes, indeed, traditional party starting into May. | 15:34 |
| TheMue | rogpeppe: 20°C, sun is shining. | 15:35 |
| rogpeppe | niemeyer: i wonder if i could run something past you briefly that i discussed with fwereade this morning | 15:35 |
| niemeyer | rogpeppe: Sure, what's up? | 15:35 |
| rogpeppe | niemeyer: it's to do with how we do the bootstrap stuff | 15:35 |
| rogpeppe | niemeyer: here's a sketch of how i *think* it might work | 15:36 |
| rogpeppe | niemeyer: http://paste.ubuntu.com/957728/ | 15:36 |
| rogpeppe | niemeyer: the difficulty being that unlike Put/GetFile, upload tools has two places to go to | 15:36 |
| * niemeyer reading through | 15:37 | |
| rogpeppe | niemeyer: there should be a blank line before "on bootstrap machine init" BTW | 15:37 |
| niemeyer | rogpeppe:It all sounds good until the provisioning agent bits | 15:38 |
| rogpeppe | niemeyer: go on | 15:38 |
| niemeyer | rogpeppe: I'm wondering why it has to recompute | 15:39 |
| niemeyer | rogpeppe: I guess it makes sense, since there are different circumstances depending on what's being run | 15:39 |
| rogpeppe | niemeyer: exactly | 15:39 |
| fwereade | niemeyer, heyhey; sorry, landlady cam round early | 15:39 |
| niemeyer | fwereade: Heya! | 15:40 |
| rogpeppe | niemeyer: different versions might be appropriate for different os/arch combinations | 15:40 |
| niemeyer | rogpeppe: That scheme looks reasonable | 15:40 |
| rogpeppe | niemeyer: the only really new bit is that the binaries are usually copied to private storage | 15:40 |
| rogpeppe | niemeyer: that doesn't happen with the bootstrap machine, unless you force it with --upload-client | 15:41 |
| niemeyer | rogpeppe: Hmm | 15:41 |
| niemeyer | rogpeppe: private doesn't have to be private.. that might make things simpler | 15:41 |
| rogpeppe | niemeyer: fwereade's suggestion, based around what we do with charms | 15:41 |
| rogpeppe | niemeyer: how do you mean? | 15:42 |
| niemeyer | rogpeppe: Private might be a bit misleading, in the sense that this is the environment storage to which the client has write access | 15:43 |
| niemeyer | rogpeppe: There's no intrinsic reason why *those* files, specifically, have to be private | 15:43 |
| rogpeppe | niemeyer: it's also the same storage name space that's used for storing the environment zookeeper addresses | 15:43 |
| niemeyer | rogpeppe: Hmmm.. on S3, though, we can do even better | 15:44 |
| niemeyer | rogpeppe: We can make $u a signed URL, that has read access from the bucket even though it is private | 15:44 |
| rogpeppe | niemeyer: i'm not sure i see how that helps | 15:45 |
| niemeyer | rogpeppe: Hold on, sorry.. why is $u being copied? | 15:45 |
| niemeyer | rogpeppe: i've missed that in the scheme | 15:45 |
| rogpeppe | niemeyer: the idea is that an environent gets a stable, local copy of the juju tools, even if the originals have come from a remote, potentially unstable source. | 15:46 |
| niemeyer | rogpeppe: We shouldn't worry about that now IMO.. $PUBLIC is going to be configurable | 15:47 |
| niemeyer | rogpeppe: and right now both private and public are equally trustable, being in S3 | 15:47 |
| rogpeppe | niemeyer: the difficulty i'm having is that we've subsumed UploadTools into PutFile, but there are now *two* name spaces not one | 15:48 |
| rogpeppe | niemeyer: we've got the place that the tools are stored and the place that the environment settings (zookeeper addresses currently) are stored | 15:48 |
| niemeyer | rogpeppe: We've always had two.. that's not related to UploadTools vs. PutFile | 15:48 |
| rogpeppe | niemeyer: we didn't use PutFile for the other storage space though, right? | 15:49 |
| niemeyer | rogpeppe: Which other storage space? | 15:49 |
| rogpeppe | niemeyer: the storage space for the executable files | 15:49 |
| niemeyer | rogpeppe: Sorry, let's get a bit more specific | 15:50 |
| niemeyer | rogpeppe: PutFile should be used by the client to upload the tools to the environment storage | 15:50 |
| niemeyer | rogpeppe: PutFile is not used to upload to the public storage because it's not maintained by the juju client | 15:50 |
| niemeyer | rogpeppe: Does that make sense? | 15:52 |
| niemeyer | rogpeppe: If it does, I'm not sure about what you mean | 15:52 |
| rogpeppe | niemeyer: yes it does. and i think my confusion has gone. if i delete the lines that copy $u, it all looks fine. | 15:53 |
| niemeyer | rogpeppe: Sweet | 15:53 |
| rogpeppe | niemeyer: one other reservation was that the prefix "tools/" becomes rather special, but i think that's fine - i've documented it on Environ.PutFile: http://paste.ubuntu.com/957764/ | 15:55 |
| niemeyer | rogpeppe: Agreed | 15:55 |
| rogpeppe | niemeyer: and that makes it reasonable for an Environ implementation to know about files of that form when searching for tools | 15:55 |
| niemeyer | rogpeppe: We'll have another special prefix too: charms/ | 15:55 |
| rogpeppe | niemeyer: cool. | 15:56 |
| niemeyer | rogpeppe: That's how it was originally designed, but the ancient "nova object store" couldn't deal with slashes (!) | 15:56 |
| niemeyer | rogpeppe: We don't care about that anymore, so can do the right thing | 15:56 |
| rogpeppe | niemeyer: great. | 15:56 |
| rogpeppe | niemeyer: i've just been deleting the "juju-origin" code BTW and it feels marvellous | 15:57 |
| niemeyer | rogpeppe: +1000 :) | 15:58 |
| rogpeppe | niemeyer: >100 lines of code gone, just like that (and that's not even including the tests!) | 15:58 |
| * fwereade approves :) | 16:00 | |
| niemeyer | rogpeppe: re. this: | 16:01 |
| niemeyer | """ | 16:01 |
| niemeyer | rogpeppe: Well, I did suggest | 16:01 |
| niemeyer | Arm | 16:01 |
| niemeyer | Thanks copy & paste | 16:01 |
| niemeyer | i don't think so. "t" is for "test" here - i'm not sure that there's a | 16:01 |
| niemeyer | single set of arguments that will result in characteristic for all | 16:01 |
| niemeyer | commands, so we use the test table above. | 16:01 |
| niemeyer | """ | 16:01 |
| niemeyer | rogpeppe: The only difference in that table is the "juju" vs "jujud" string | 16:02 |
| niemeyer | rogpeppe: It's really not worth a table in that case.. | 16:02 |
| rogpeppe | niemeyer: i guess, if we can force a similar-looking usage message out of all juju commands by passing them the same arguments | 16:03 |
| rogpeppe | niemeyer: it's probably true of jujuc too, and perhaps that's all we'll ever have | 16:03 |
| rogpeppe | niemeyer: ok, will remove the table | 16:03 |
| niemeyer | rogpeppe: That's my guess, and we can always change back when it does make sense to have it | 16:03 |
| niemeyer | rogpeppe: Mostly a "doesn't look like it's necessary", rather than "we can't do this" | 16:04 |
| rogpeppe | niemeyer: k | 16:04 |
| TheMue | So, just came back to wish you a happy labour day tomorrow and you a good time in IAK, niemeyer. | 16:05 |
| TheMue | niemeyer: I've done the watcher test refactoring, it's proposed. | 16:06 |
| niemeyer | TheMue: Thanks a lot, have a good time too! | 16:06 |
| niemeyer | TheMue: Cheers.. I'll do a review pass tonight | 16:06 |
| TheMue | niemeyer: Thank you, will have. And looking forward to next week. But we'll meet here on Wednesday again. | 16:07 |
| TheMue | Bye | 16:07 |
| rogpeppe | niemeyer: i've made that change BTW | 16:10 |
| niemeyer | rogpeppe: Thanks! | 16:11 |
| === TheMue_ is now known as TheMue | ||
| niemeyer | rogpeppe: Looking, tentatively :) | 16:22 |
| niemeyer | Have to move | 16:29 |
| niemeyer | biab | 16:29 |
| rogpeppe | fwereade: ping | 16:43 |
| fwereade | rogpeppe, pong | 16:43 |
| rogpeppe | fwereade: here's a thought: rather than having a --upload-client flag, we have an upload-client command | 16:44 |
| fwereade | rogpeppe, hmm, that sounds like a good idea to me | 16:44 |
| fwereade | rogpeppe, although it makes me less certain that that's precisely the right name | 16:44 |
| rogpeppe | fwereade: 'cos i was just looking at looking as it as a flag and it's not really appropriate on quite a few commands, but seems like it might work well as a command in its own right | 16:45 |
| rogpeppe | fwereade: upload-tools? upload? | 16:45 |
| fwereade | rogpeppe, upload-tools sounds pretty good | 16:45 |
| rogpeppe | fwereade: the idea is you can execute it *before* bootstrap if you want | 16:46 |
| fwereade | rogpeppe, yes, very nice | 16:46 |
| rogpeppe | fwereade: good, thanks. | 16:46 |
| rogpeppe | fwereade: ok, i'll give that a go | 16:47 |
| rogpeppe | fwereade: unless you wanna | 16:47 |
| fwereade | rogpeppe, I'm very happily fiddling with the hook commands atm | 16:48 |
| rogpeppe | fwereade: ok great | 16:48 |
| rogpeppe | right, i'm off for the evening. see y'all tomorrow | 17:00 |
| fwereade | likewise | 17:01 |
| fwereade | take care all | 17:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!