* thumper sighs | 00:04 | |
thumper | tests failed because other people landed code... | 00:04 |
---|---|---|
* thumper merges and updates | 00:04 | |
axw | wallyworld__: actually, before tmpfs it would be more useful to have "loop" | 02:19 |
axw | wallyworld__: so we have the fallback case covered | 02:20 |
wallyworld__ | axw: yes, i was hoping we'd churn out tmpfs, loop more or less together | 02:23 |
wallyworld__ | but loop first, i agree | 02:23 |
=== kadams54 is now known as kadams54-away | ||
menn0 | thumper, wallyworld__ : holy crap there's lots of crazy duplication of test helpers in state | 03:36 |
thumper | :) | 03:36 |
menn0 | thumper, wallyworld__ : fixing a bunch of it now | 03:36 |
thumper | cheers | 03:36 |
wallyworld__ | \o/ | 03:36 |
menn0 | thumper, wallyworld__ : it's tricky because some tests in state are internal, but I see a path to making a lot of it better | 03:37 |
axw | wallyworld__: http://reviews.vapour.ws/r/757/ | 03:48 |
wallyworld__ | looking | 03:48 |
=== kadams54-away is now known as kadams54 | ||
thumper | menn0: I'm getting there with the tests but I have one leaving a dirty socket around | 04:15 |
thumper | a mongo connection | 04:15 |
thumper | it is definitely the test where we have a different connection from state | 04:15 |
thumper | but I can see that my resource cleanup is getting called | 04:15 |
thumper | so not sure where | 04:15 |
thumper | if you are good with it, perhaps we could go through it in the morning to see WTF is going on? | 04:16 |
menn0 | thumper: happy to | 04:23 |
thumper | menn0: good, I think I've looked at it too long this afternoon, pushing up current | 04:28 |
menn0 | thumper: this state testing refactoring is going really well btw | 04:29 |
menn0 | thumper: tons of lines being removed | 04:29 |
thumper | cool | 04:29 |
thumper | night folks | 04:32 |
axw | wallyworld__: mind seeing my comments before I land? | 04:33 |
wallyworld__ | axw: yah, looking now | 04:34 |
wallyworld__ | axw: commented, not sure if you wsnt to discuss | 04:44 |
axw | wallyworld__: LVM is at a higher level. there's nothing stopping you from creating a volume group across different providers. I'm not sure if we should be using quite the same machinery for them. how do you tell it which device(s) to operate on? | 04:47 |
axw | wallyworld__: I could well see an LVM storage provider that creates "disks" as logical volumes for you, but I think the relationship between the LV and the disks in its volume group is outside this model | 04:51 |
axw | wallyworld: not sure where you saw up to... | 04:54 |
axw | wallyworld: LVM is at a higher level. there's nothing stopping you from creating a volume group across different providers. I'm not sure if we should be using quite the same machinery for them. how do you tell it which device(s) to operate on? | 04:54 |
axw | wallyworld: I could well see an LVM storage provider that creates "disks" as logical volumes for you, but I think the relationship between the LV and the disks in its volume group is outside this model | 04:54 |
wallyworld | axw: sigh, freenode hates me, keeps kicking me off :-( | 04:55 |
wallyworld | axw: instead of LV, what about loopback? i guess the point for me is that the provisioner etc sees a block device and it's outside of its interest how that is provider, physical disk or otherwise | 04:57 |
wallyworld | axw: afk, bbiab | 04:58 |
axw | wallyworld: the name Disk is probably just a poor one. what I mean is "block device that the provider manages", as opposed to "block device that a machine sees" | 04:59 |
axw | wallyworld: let me know when you're back | 05:29 |
axw | -_- | 05:30 |
wallyworld | axw: yeah, that's how i think of it too. Disk though gives the opposite connotation. gad i hate naming things | 05:34 |
axw | wallyworld: it's really "volume" and "attachment", but that doesn't marry with discovered devices | 05:37 |
wallyworld | should or could we go with Volume instead of Disk for what we have currently? that would still work with discovered devices i think? | 05:42 |
wallyworld | i *think* that may remove the current ambiguity? | 05:43 |
wallyworld | anastasiamac: it's clear these a mix of approaches wrt api param naming :-( let's go with what you have so we can get it landed | 05:44 |
axw | wallyworld: I'm fine with calling it Volume, though I don't see much of a difference | 05:46 |
axw | except that it might be a little clearer that it's not necessarily a physical or dedicated disk | 05:48 |
wallyworld | axw: perhaps i'm being too pedantic wrt naming. or confused. or both. I think of Disk as a physical device, whereas Volume is an abstraction that better applies to various device types loopback vs VG vs disk etc | 05:48 |
wallyworld | yes | 05:48 |
wallyworld | that's where i'm coming from | 05:49 |
axw | wallyworld: fair enough. I'll change it. I'll need to update juju/names too, but I'll do that later | 05:49 |
axw | wallyworld: PTAL | 06:05 |
wallyworld | sure | 06:06 |
wallyworld | axw: thanks, i think the naming is clearer now. well to me it is :-) | 06:09 |
axw | wallyworld: cool | 06:09 |
menn0 | wallyworld: you might like this: http://reviews.vapour.ws/r/759/ | 06:09 |
wallyworld | looking | 06:10 |
wallyworld | oooh refactoring | 06:10 |
axw | wallyworld: in case you missed it, I added a TODO to rename the results of {Create,Describe}Volumes to return something other than BlockDevice, since it will want to convey information that isn't pertinent to the machine level | 06:10 |
axw | such as detachability, persistence, etc. | 06:10 |
menn0 | wallyworld: see what happens when you make a single review comment about extracting some test helpers out | 06:10 |
wallyworld | axw: yep, sounds good | 06:10 |
menn0 | wallyworld: I then went and noticed all the awful duplication and felt the need to fix it | 06:10 |
wallyworld | menn0: \o/ thank you | 06:10 |
wallyworld | axw: short term goal is to get collaboration possible, i think this branch enables that | 06:11 |
menn0 | wallyworld: dealing with kids now so no rush | 06:12 |
axw | wallyworld: yep. I will land and get back to juju deploy | 06:12 |
wallyworld | menn0: ok, will finish a few things and then look, really appreciate the work to do this | 06:12 |
wallyworld | axw: we still need some glue to plug it all in, but at least the storage sources for eg loopback can be written and tested | 06:13 |
dimitern | morning all | 06:50 |
anastasiamac | dimitern: morning :D | 07:01 |
dimitern | anastasiamac, o/ | 07:02 |
dimitern | anastasiamac, nice new facade btw :) | 07:04 |
menn0 | wallyworld_: thanks for the review. i'll add that comment and then get it in. | 07:08 |
wallyworld_ | awesome | 07:08 |
anastasiamac | dimitern: thnx :) | 07:25 |
wallyworld__ | axw: got a few minutes? hangout in our 1:1? | 07:27 |
axw | wallyworld__: sure | 07:27 |
jam1 | morning dimitern | 07:32 |
dimitern | jam1, morning, sorry - omw :) | 07:32 |
jam1 | just grabbing a coffee, but I joined the hangout | 07:32 |
=== jam2 is now known as jam1 | ||
axw | wallyworld__: are you there still? | 08:04 |
axw | can't hear you on hangouts... | 08:04 |
=== mthaddon` is now known as mthaddon | ||
TheMue | dimitern: so, system is started | 09:10 |
dimitern | TheMue, great! i'll be in the hangout shortly | 09:11 |
TheMue | dimitern: fine | 09:11 |
voidspace | dimitern: I'll be back in 5 minutes as well | 10:24 |
dimitern | voidspace, ok | 10:27 |
voidspace | dimitern: and back... | 10:30 |
dimitern | voidspace, I've reviewed your subnets PR btw | 11:03 |
=== urulama_ is now known as urulama | ||
voidspace | dimitern: you've suggested using a string set, which I would *love* | 12:14 |
voidspace | dimitern: which packge is that from | 12:14 |
voidspace | dimitern: import "set" does not work... | 12:14 |
dimitern | voidspace, it's in juju/utils/set IIRC | 12:19 |
voidspace | ah.... | 12:19 |
voidspace | *great* | 12:19 |
voidspace | dimitern: ah, I can't use the set, because I'm using the underlying value (true/false) to carry meaning | 12:22 |
voidspace | dimitern: (did we actually find the subnet) | 12:22 |
perrito666 | morning to the few of you who are here | 12:26 |
voidspace | perrito666: morning | 12:27 |
dimitern | voidspace, well, you could construct the set initially with all ids, then remove ones that are not found.. | 12:34 |
dimitern | voidspace, but i'll leave it up to you | 12:34 |
voidspace | well, I *can't* remove the ones not found | 12:35 |
voidspace | I use the set to track *found* ones :-) | 12:35 |
voidspace | knowing which ones I haven't found is the problem I'm trying to solve :-) | 12:35 |
voidspace | but I've switched the map to string[bool] as it involves less casts | 12:36 |
voidspace | one instead of three | 12:36 |
voidspace | dimitern: I've hit $$merge$$ and am onto the next task | 12:36 |
dimitern | voidspace, ok, fair enough | 12:40 |
dimitern | voidspace, cheers! :) | 12:40 |
anastasiamac | voidspace: merge failed :( | 12:50 |
* dimitern needs to step out for ~45m | 13:08 | |
* perrito666 is still drinking mate trying to swallow the news from his govt | 13:10 | |
perrito666 | fwereade: sweeeeeeet 666 additions :p | 13:15 |
perrito666 | that is your last patch | 13:15 |
fwereade | perrito666, lol, awesome | 13:15 |
* perrito666 imagines fwereade adding blank lines to get there | 13:15 | |
fwereade | perrito666, if I'd noticed I was near I probably would have done, yeah ;p | 13:16 |
voidspace | anastasiamac: thanks, fixed | 14:55 |
voidspace | dimitern: ping | 15:06 |
dimitern | voidspace, pong | 15:06 |
voidspace | dimitern: should I work on (first) either a) NetworkInterfaces for MaaS | 15:07 |
voidspace | dimitern: or b) filling in the missing bits of the ec2 implementation? | 15:07 |
voidspace | or c) it doesn't matter which order... | 15:07 |
voidspace | if b) I have some follow up questions :-D | 15:07 |
dimitern | voidspace, well :) | 15:08 |
dimitern | voidspace, i'm not quite done with the ec2test filtering for NICs, so I suppose a) is best for now | 15:08 |
voidspace | ... | 15:08 |
voidspace | ah, cool | 15:08 |
voidspace | that's what I wanted to hear... | 15:08 |
voidspace | dimitern: thanks | 15:08 |
dimitern | voidspace, :) | 15:09 |
dimitern | voidspace, and I think splitting up the ec2 and maas implementations in separate PRs is good | 15:09 |
voidspace | dimitern: yeah | 15:10 |
voidspace | parsing lshw, yay! | 15:12 |
dimitern | voidspace, :/ I sympathize | 15:13 |
voidspace | dimitern: I created separate cards for EC2/MaaS implementation | 15:14 |
voidspace | dimitern: and assigned MaaS to me and EC2 to you | 15:14 |
voidspace | doesn't have to stay like that but will do for now | 15:14 |
dimitern | voidspace, thanks! | 15:16 |
voidspace | although, extractInterfaces pretty much does it all already | 15:18 |
voidspace | might need to extend it a bit, but not much | 15:18 |
dimitern | voidspace, while doing that would you mind adding ProviderSubnetId network.Id to InterfaceInfo ? | 15:25 |
voidspace | dimitern: ok | 15:26 |
voidspace | dimitern: ProviderSubnetId instead of SubnetId ? | 15:26 |
dimitern | voidspace, and rephrase ProviderId's doc comment to clarify it's the NIC id | 15:26 |
voidspace | ok | 15:26 |
dimitern | voidspace, yeah, let's make it obvious | 15:26 |
voidspace | okeydokey | 15:26 |
dimitern | voidspace, cheers | 15:26 |
voidspace | dimitern: looks like I'll be visiting friends on the Monday and Tuesday of our sprint week | 15:29 |
voidspace | dimitern: so Wednesday for team meal would be ideal please :-) | 15:29 |
dimitern | voidspace, sure, will keep that in mind | 15:30 |
voidspace | dimitern: thanks, sorry to be a pain | 15:30 |
dimitern | voidspace, no trouble at all :) | 15:30 |
voidspace | dimitern: I don't get down to London often, so have a couple of friends keen to see me | 15:30 |
voidspace | dimitern: and I was already booked for a meal there on Thursday! | 15:30 |
dimitern | voidspace, of course, sgtm | 15:31 |
* TheMue will also visit a friend, but not date yet fixed ;) | 15:38 | |
voidspace | TheMue: don't make it Wednesday please :-) | 15:39 |
TheMue | voidspace: hehe, sure, just seen | 15:40 |
voidspace | cool | 15:40 |
voidspace | otherwise we have a dilemna | 15:40 |
voidspace | and dimitern has to decide who he loves more ;-) | 15:40 |
TheMue | *rofl* | 15:40 |
dimitern | :D | 15:40 |
TheMue | dimitern: do we have a kind of definition how we extend the provider interface for networking? or is it currently just a loose coupled set of functions? | 15:42 |
voidspace | TheMue: we add new Environ methods ad-hoc as we need them... | 15:42 |
voidspace | TheMue: the current "entry point" for new networking stuff is the SupportAddressAllocation method | 15:42 |
voidspace | TheMue: if a provider returns True for this then it must support all the new networking methods | 15:43 |
voidspace | TheMue: this is only true for MaaS and EC2 currently | 15:43 |
TheMue | voidspace: ok | 15:43 |
voidspace | TheMue: the other providers return false for SupportAddressAllocation and errors.NotImplemented for the other new networking methods | 15:43 |
TheMue | voidspace: so do those methods have an own interface and where needed we we do a type assertion? | 15:43 |
voidspace | TheMue: they *don't*, they *could* | 15:44 |
TheMue | voidspace: or do the others have to implement "empty" methods? | 15:44 |
voidspace | TheMue: they're just part of the Environ interface | 15:44 |
voidspace | so yes, at the moment all providers implement them | 15:44 |
voidspace | a separate interface that extends Environ would probably be clearer | 15:45 |
TheMue | voidspace: so all providers have to provide them, even w/o address allocation? | 15:45 |
voidspace | yep | 15:45 |
voidspace | you can see that they do | 15:45 |
voidspace | e.g. for NetworkInterfaces Subnets (etc) | 15:45 |
TheMue | voidspace: yeah, then I would prefer one or more extra interfaces | 15:45 |
dimitern | TheMue, I had a sort of plan 9 months ago - everything changed since then, so now it's ad-hoc until we get it done :) | 15:45 |
voidspace | TheMue: that would be a great initial contribution :-) | 15:46 |
TheMue | voidspace: hah | 15:46 |
voidspace | TheMue: or did you mean you would prefer it if someone else did it? | 15:46 |
voidspace | in which case, me too! :-) | 15:46 |
voidspace | TheMue: just teasing, but yes I agree in principle | 15:46 |
TheMue | voidspace: no, would be fine to me, so I'm forced to take a look at each networking method | 15:47 |
voidspace | go for it | 15:47 |
voidspace | would be quite easy, and then you'd see the new methods | 15:47 |
TheMue | dimitern: how is p9 doing it? | 15:47 |
voidspace | AllocateAddress and ReleaseAddress too | 15:47 |
voidspace | I believe | 15:47 |
dimitern | TheMue, I have no idea frankly :) | 15:47 |
TheMue | dimitern: *rofl* | 15:47 |
TheMue | dimitern: what I once liked is the idea of "everything is a device" | 15:48 |
dimitern | TheMue, I do like this - nice and polymorphic, but alas.. | 15:49 |
dimitern | voidspace, ping | 18:06 |
dimitern | voidspace, have a look at https://github.com/go-amz/amz/pull/20 later if you have time | 18:07 |
voidspace | dimitern: ok | 18:07 |
voidspace | dimitern: not long before I leave, but I can take a look | 18:07 |
dimitern | wallyworld___, axw, katco , rogpeppe, can any of you please review the above PR for goamz that improves ec2test server? ^^ | 18:07 |
voidspace | dimitern: cool, nice work | 18:08 |
dimitern | voidspace, cheers! the important part is that now we can filter NICs by "attachment.instance-id" | 18:08 |
rogpeppe | dimitern: am finished for the day now and doing a sprint this week, so it might be a little while until i get around to it | 18:08 |
voidspace | rogpeppe: hey, I don't suppose you can remember the name of that restaurant we went to in London? | 18:09 |
voidspace | rogpeppe: we're back in London next week... | 18:09 |
dimitern | rogpeppe, np, I'm just mass-pinging in the hope someone might have a look :) | 18:09 |
rogpeppe | voidspace: hmm, it was nice, wasn't it? | 18:09 |
rogpeppe | voidspace: i'm in london now... | 18:09 |
voidspace | rogpeppe: yep... | 18:09 |
rogpeppe | voidspace: no, sorry, i can't remember at all | 18:09 |
voidspace | rogpeppe: heh, cool :-) | 18:09 |
voidspace | never mind, shame | 18:09 |
rogpeppe | voidspace: we probably found it through tripadvisor | 18:09 |
voidspace | ah, I'll try searching for restaurants near Blue Fin | 18:10 |
voidspace | there's probably only about 200 to check in that radius... | 18:10 |
rogpeppe | dimitern: from a quick skim, it looks reasonable | 18:10 |
rogpeppe | voidspace: istr it might've been north of the river | 18:11 |
voidspace | ah yes, I vaguely remember crossing the river | 18:12 |
voidspace | I'm signing off for the day | 18:16 |
voidspace | time to go jogging | 18:16 |
voidspace | g'night all | 18:16 |
dimitern | rogpeppe, cheers | 18:18 |
=== robbiew1 is now known as robbiew | ||
thumper | jw4: are you working or taking the day off? | 20:00 |
jw4 | thumper: working, but I was just about to break for the gym | 20:06 |
thumper | jw4: just wanted to make sure you were aware: https://bugs.launchpad.net/juju-core/+bug/1412292 | 20:06 |
mup | Bug #1412292: Intermittent test failure in ActionSuite.TestActionsWatcherEmitsInitialChanges <action> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1412292> | 20:06 |
jw4 | thumper: yeah I saw that. Thanks for filing it. I need to figure out what causes it. I thought that test was isolated well enough but obviously not. | 20:07 |
thumper | coolio | 20:11 |
hazmat | how do we set feature flags ? | 22:11 |
hazmat | looks like via env var on client | 22:14 |
hazmat | thumper, re env manager, how does one get access to it? its not showing up in the client api facades on logged in conn | 22:28 |
thumper | hazmat: no, it isn't hooked up | 22:29 |
thumper | and yes, feature flags are set by env var | 22:30 |
hazmat | thumper, ah, that would explain it | 22:30 |
hazmat | JUJU_DEV_FEATURE_FLAGS valid values storage,actions | 22:30 |
hazmat | yeah | 22:30 |
thumper | hazmat: I have a branch, but got derailed | 22:30 |
thumper | found two kinda critical things that were more important | 22:30 |
thumper | and now I'm banging my head against the fucking dummy provider | 22:30 |
hazmat | thumper, no worries was just looking at restructuring the jujuclient to automatically expose facades as objects off the conn, corresponding to those actually present | 22:31 |
thumper | I do feel like we are getting close though | 22:31 |
hazmat | thumper, there's a couple of interesting integrations around envmanager(obviously) mostly looking to get those rolling end of feb | 22:31 |
* thumper nods | 22:31 | |
thumper | should be well hooked up before then :) | 22:32 |
thumper | ah mah gaad | 22:54 |
thumper | finally have the test failing the way I expect | 22:54 |
thumper | what a freaking mission | 22:54 |
* thumper must remember to reset the branch before proposing to remove expletives | 22:55 | |
thumper | so... apart from that panic, we're good | 22:57 |
* thumper grumbles | 22:57 | |
thumper | meh | 22:58 |
* thumper head desks | 23:04 | |
thumper | fark!!!!! | 23:20 |
* thumper wonders if he has broken anything else | 23:21 | |
perrito666 | thumper: feeling like colombian revolution? | 23:21 |
thumper | perrito666: I don't get it | 23:21 |
perrito666 | thumper: farc is the name the colombian "revolutionary" group that drives narcotrafic calls them selves | 23:21 |
thumper | ah | 23:22 |
perrito666 | iirc fuerzas armadas revolucionarias de colombia | 23:22 |
thumper | no I was mentally bitching about why the common.Resources didn't stop things in the reverse order they were registered | 23:22 |
thumper | but rather randomly | 23:22 |
thumper | which ment my pinger died because the state connection was closed already | 23:23 |
perrito666 | by design? | 23:23 |
thumper | by not caring | 23:23 |
thumper | now they do work that way | 23:23 |
thumper | before there wasn't any dependency between resources | 23:23 |
thumper | now there can be | 23:23 |
thumper | before it didn't matter | 23:23 |
thumper | now it does | 23:23 |
perrito666 | changes, i hate those | 23:27 |
thumper | menn0: I think I have this ready to go now | 23:29 |
thumper | menn0: all the tests are running and passing except for one "bad record MAC: | 23:29 |
menn0 | thumper: orrsum | 23:31 |
thumper | menn0: although to get it fully working, there is more work needed in the apiserver code | 23:33 |
thumper | but for the other handlers | 23:33 |
thumper | like tools, charms, iamges, debuglog | 23:33 |
menn0 | wallyworld_: i've updated http://reviews.vapour.ws/r/754/ in response to your review comments. | 23:35 |
anastasiamac | thumper: what's worng with charms handlers?.. | 23:35 |
wallyworld_ | menn0: ty, looking | 23:35 |
menn0 | wallyworld_: there's a couple of things that i need your feedback on | 23:35 |
thumper | anastasiamac: they don't support the correct state connectino for non-state server environments | 23:35 |
anastasiamac | thumper: :( | 23:35 |
anastasiamac | thumper: what's correct state connection look like? | 23:36 |
thumper | I'll fix it. All the workers will need the same fix | 23:36 |
menn0 | wallyworld_: no rush. I'm about to have lunch and take Amelia to preschool. | 23:36 |
anastasiamac | thumper: can't wait :D | 23:36 |
wallyworld_ | ok | 23:36 |
thumper | menn0: http://reviews.vapour.ws/r/763/ | 23:40 |
thumper | 13 changed files with 250 additions and 93 deletions. | 23:40 |
thumper | never freakin easy, is it? | 23:40 |
menn0 | thumper: at least the diff still fits on one RB page :) | 23:50 |
thumper | :) | 23:50 |
thumper | I think I hit the same problem waigani did before | 23:51 |
thumper | where I was wanting to add machines to an environment that isn't the state server one | 23:51 |
thumper | that required the provider.Prepare in the factory | 23:51 |
waigani | thumper: how did you solve that? | 23:52 |
thumper | waigani: take a look at the review above | 23:52 |
thumper | wallyworld_: nested errors.Trace call are preferable | 23:53 |
thumper | otherwise you don't get a stack | 23:53 |
thumper | that's the whole point | 23:54 |
thumper | wallyworld_: there is no harm in returning 'return errors.Trace(err)' over 'return err' | 23:54 |
thumper | wallyworld_: and I would say it is preferable to a bare return err | 23:54 |
anastasiamac | thumper: would | 23:55 |
wallyworld_ | thumper: ok, wasn't sure of the preferred usage | 23:55 |
anastasiamac | wouldn't u want to trace once and then annotate as u come up? | 23:55 |
thumper | anastasiamac: you either trace or annotate or wrap | 23:55 |
thumper | anastasiamac: if there is no useful context to add with an annotation, tracing is fine | 23:55 |
wallyworld_ | why not trace and then annotate at layer boundary | 23:56 |
anastasiamac | thumper: what wallyworld_ said^^ | 23:56 |
thumper | wallyworld_: it depends where the useful context is | 23:56 |
thumper | context isn't always at the boundary | 23:56 |
wallyworld_ | and i maintain tracing is not always necessary | 23:56 |
thumper | wallyworld_: it is *never* necessary | 23:56 |
thumper | wallyworld_: but it is very useful for debugging | 23:56 |
thumper | and it doesn't hurt | 23:57 |
thumper | so why not? | 23:57 |
wallyworld_ | can be, but not always needed | 23:57 |
wallyworld_ | code clutter | 23:57 |
thumper | dude, it is *never* needed | 23:57 |
* thumper challenges that | 23:57 | |
wallyworld_ | you know what i mean | 23:57 |
menn0 | thumper: so, I'm fairly sure i've added machines to the non-initial env using the factory before | 23:58 |
thumper | bah humbug, actions test failure - the intermittent one I filed that bug for yesterday | 23:58 |
menn0 | thumper: so why is the prepare stuff req'd | 23:58 |
menn0 | ? | 23:58 |
thumper | menn0: ah... because I'm using the dummy provider | 23:58 |
thumper | not an unregistered 'someprovider' | 23:58 |
jw4 | thumper: sorry :) | 23:59 |
menn0 | thumper: cool. | 23:59 |
thumper | dummy needs to be registered | 23:59 |
thumper | sorry, prepared | 23:59 |
menn0 | thumper: i've had a quick look over your PR and it looks good. but I need to have a closer look once i've done the school run etc | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!