[01:20] <wallyworld_> thumper: i have to go to the hardware store - bit of a bathroom issue, back soon hopefully
[01:33] <thumper> wallyworld_: ok.. ping me when you're back
[02:40] <wallyworld_> thumper: ping
[02:40] <thumper> wallyworld_: hi
[02:40] <thumper> wallyworld_: hangout?
[02:40] <wallyworld_> yep
[02:41] <wallyworld_> https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
[03:51] <kyhwana> hey thumper, do yo know cucumbererror?
[03:56] <thumper> kyhwana: sorry, no
[03:58] <kyhwana> ahh ok, he's dunners too, works at some educational instution in IT or helldesk
[04:00] <thumper> kyhwana: oh, I assumed you were talking about errors from the python library cucumber L(
[04:01] <thumper> L( should have been :)
[04:01] <thumper> but still, no
[04:01] <kyhwana> hehe
[04:04] <kyhwana> ah right, at UO. oh well
[04:09] <thumper> kyhwana: what it their real name, I may know them but not their irc nick
[04:09] <kyhwana> Oh, darryl someone
[04:56] <thumper> kyhwana: doesn't ring any bells
[04:58] <kyhwana> ah well, you probably know someone that knows him
=== tasdomas_afk is now known as tasdomas
[05:07] <thumper> kyhwana: almost certainly
[05:07] <kyhwana> thumper: Do you drink of the beers?
[05:08] <thumper> kyhwana: sometimes
[05:08] <kyhwana> hmm, do you goto Beervana in wellington?
[05:09] <thumper> no
[05:09] <thumper> not that keen
[05:09] <thumper> I know some who do
[05:09] <kyhwana> ahh ok
[05:10] <kyhwana> I think that's my only trips to wellington this year, Nethui, beervana and Kiwicon :P
[05:15] <thumper> kyhwana: I do kiwipycon
[05:15] <thumper> not going to nethui
[05:15] <thumper> although Unfocused is
[05:16] <thumper> wallyworld_: email sent to dev list re: opaque keys and natural business keys
[05:16] <kyhwana> ahh ok
[05:16] <thumper> wallyworld_: I mentioned that you feel stronger than I do in the email, so no additional rant needed
[05:17] <thumper> wallyworld_: but feel free to +1 it with a non-ranty additional info
[07:09] <TheMue> morning
[07:36] <fwereade> TheMue, heyhey
[07:38] <TheMue> fwereade: heya
[07:39] <TheMue> fwereade: where i just see you, could you tell me more about the background of nonce (e.g. used in StartInstance() )?
[07:39] <fwereade> TheMue, it's to deal with provisioner failures after starting an instance but before recording that fact in state
[07:40] <fwereade> TheMue, if that happens, we get a rogue instance starting up, thinking it's running machine (say) 7
[07:40] <fwereade> TheMue, but state being unaware of that
[07:41] <fwereade> TheMue, so when we start up a machine agent, the first thing we do is check that the nonce matches the one recorded in state
[07:41] <fwereade> TheMue, if it doesn't, or there's no nonce in state, the MA does nothing and just sits back and waits for its host instance to be trashed
[07:42] <TheMue> fwereade: ah, ok, thx, that makes it more clear.
[07:43] <TheMue> fwereade: my dict translates nonce as sex offender, esp. paedophile. strange.
[07:43] <fwereade> TheMue, when it's a container being provisioned, this is potentially less of a problem -- we *could* arrange matters so that "instance" ids are predictable based on machine ids -- but I'd prefer to just keep the nonce mechanism so we aren't forced to do that
[07:44] <fwereade> TheMue, and so that we have the same code path in all cases
[07:44] <TheMue> fwereade: +1 on that, yes
[07:44] <fwereade> TheMue, cool
[07:45] <fwereade> TheMue, (yeah, it's one of those interestingly overloaded terms, I knew that meaning before I was aware of the technical one)
[07:46] <TheMue> fwereade: i never heard it before
[07:46] <TheMue> fwereade: but wikipedia knows the correct meaning
=== wedgwood_away is now known as wedgwood
[08:48] <dimitern> fwereade: hey
[08:48] <fwereade> dimitern, hey dude
[08:49] <dimitern> fwereade: sorry, yesterday i suddenly felt tired and decided to lie down for a while and was midnight when I woke up :)
[08:49] <dimitern> fwereade: saw your msg too late
[08:49] <fwereade> dimitern, haha, no worris
[08:50] <dimitern> fwereade: I have a proof-of-concept proposal of the bulk-ops: https://codereview.appspot.com/9847044
[08:51] <fwereade> dimitern, awesome
[08:52] <fwereade> dimitern, btw, cath and I were pondering a cuba lunch today, feel like joining us?
[08:52] <dimitern> fwereade: i was thinking I can just get rid of srvUnit altogether
[08:52] <dimitern> fwereade: sgtm, although i'll bring my apples :)
[08:52] <fwereade> dimitern, haha, ok -- what time works for you?
[08:53] <dimitern> fwereade: either before standup at 13:30 or after 14
[08:53] <fwereade> dimitern, maybe 12 or 12:15 then?
[08:53] <dimitern> fwereade: ok
[08:54]  * dimitern brb
[08:54] <TheMue> fwereade, dimitern: shall i join too? ;)
[08:54]  * TheMue orders his jet
[08:59] <dimitern> TheMue: :) if you manage, by all means
[09:00] <TheMue> dimitern: don't think so, my wife just took it for a short trip to new york
[09:00] <dimitern> fwereade: so what do you think of the approach ^^ ?
[09:00] <fwereade> dimitern, looks ideal
[09:01] <dimitern> fwereade: haven't figured out a way to test is server-side yet, i'm afraid
[09:01] <fwereade> dimitern, I was about to say "I think it's time to introduce direct server testing" ;p
[09:02] <dimitern> fwereade: and also, if we need bulk ops exposed at client-side how do you picture it? having st.AllUnits? or something like that
[09:02] <fwereade> dimitern, I was vaguely expecting st.Units([]string)
[09:02] <fwereade> dimitern, I think AllUnits is potentially problematic
[09:02] <dimitern> fwereade: ah, ok can do that
[09:03] <dimitern> fwereade: will this be the only entry point?
[09:03] <fwereade> dimitern, and I would rather not implement either until there's a need -- so, for now, yes, the st.Unit will remain the only entry point in state/api
[09:03] <dimitern> fwereade: maybe if we need it later, we could have st.UnitsStatus(names) perhaps
[09:04] <dimitern> fwereade: s/UnitsStatus/Units.Status(names)/
[09:04] <fwereade> dimitern, I have a small part of my brain wondering whether a type that wraps a list of unit ids will be justifiable/handy at some point
[09:04] <fwereade> dimitern, but yeah, exactly
[09:05] <dimitern> fwereade: although if st.Units takes names, then .Status() is redundant, unless you don't want all the other info over the wire
[09:05] <dimitern> fwereade: in which case, we'll need separate top-level methods - st.UnitsStatus(names)
[09:06] <fwereade> dimitern, Status doesn't get sent over in the unit data does it?
[09:07] <dimitern> fwereade: anyway, I'm glad I got you finally :) i'm afraid i was being stupid last couple of days
[09:07] <dimitern> fwereade: well, no actually - only stuff accessible from the u.doc directly
[09:07] <fwereade> dimitern, fwiw I don't think you have been
[09:08] <fwereade> dimitern, the jujud agent stuff is not much fun to play with
[09:08] <dimitern> fwereade: agreed!
[09:08] <fwereade> dimitern, and the number of layers involved in the api stuff makes it very hard to communicate precise instructions
[09:09] <fwereade> dimitern, the blocker was in clearly explaining the precise scope of the problem
[09:09] <dimitern> fwereade: so to emulate Unit(name).Status() with bulk ops, i'll need to do srvUnits().Status(names) and call that
[09:09] <fwereade> dimitern, yep, sgtm
[09:09] <fwereade> dimitern, just one thing to bear in mind
[09:10] <dimitern> fwereade: ok, so my plan is to get rid of srvUnit and replace it with bulk-only ops, while keeping the client-side the same first, then think how to test it
[09:10] <fwereade> dimitern, returning a map potentially bumps up against the json key-type restriction; consider the tradeoffs in returning an []params.Unit instead
[09:10] <dimitern> fwereade: and add api.Units(names) as well
[09:11] <fwereade> dimitern, I'm not 100% sure it's smarter but my gut leads me that way
[09:11] <dimitern> fwereade: what are these restrictions, elaborate pls?
[09:11] <fwereade> dimitern, no int keys
[09:11] <dimitern> fwereade: well, we'll make them strings throughout :)
[09:11] <fwereade> dimitern, and there is at least one situation in which we need to retrieve relations by int key
[09:12] <dimitern> fwereade: or only return a map for string keys proper, so that lookups are fast client-side
[09:12] <fwereade> dimitern, suggestion: preserve order of input names
[09:13] <dimitern> fwereade: can do; that'll actually save some bytes over the wire
[09:13] <fwereade> dimitern, that way we can loop in a defined order if necessary, and otherwise don't have to mind
[09:13] <fwereade> dimitern, great
[09:21] <dimitern> fwereade: can you please comment on the CL, so it doesn't look like i'm pulling stuff from my ass there :)
[09:21] <fwereade> dimitern, ofc, sorry
[09:22] <dimitern> fwereade: cheers
[09:36] <fwereade> dimitern, sorry sent it a few mins ago
[09:37] <dimitern> fwereade: saw it, thanks
[09:38] <fwereade> dimitern, I've noticed something else in the api, that you had no way of knowing about... we really shouldn't be sending data down from the environ config watcher... we should be consistent with the other watchers and just send notifications
[09:38] <fwereade> TheMue, ^^
[09:38] <fwereade> TheMue, since you'll be working on the provisioner, please ensure you fix that end keep the API up to date
[09:39] <jam> fwereade, dimitern: anyone have insight into the state_test.go TestOpenDoesNotDelayOnHandShakeFailure test? I think it was written by davecheney
[09:39] <jam> It succeeds for me locally, but fails reliably on go-bot
[09:39] <dimitern> jam: not really
[09:39] <jam> It seems to do 3 TLS Handshake failures locally
[09:39] <jam> but on gobot I get maybe 6 ofthem
[09:40] <fwereade> jam, it *looks* like it's intended to test that we fail out immediately on handshake failure
[09:40] <fwereade> jam, I seem to get 4 locally
[09:41] <fwereade> (can you tell I've written no code since I got back? :/)
[09:41] <TheMue> fwereade: yep, will keep in mind
[09:41] <jam> fwereade: well, it is slightly indeterministic if you get the failure before the last log message (if I force the test to fail on an otherwise working system)
[09:41] <jam> I think I see 4 as well
[09:41] <jam> I'm slightly worried that it is a timing based test and the go-bot is just slow
[09:42] <fwereade> jam, from local behaviour it STM to be an actual problem
[09:42] <fwereade> TheMue, dimitern: are you getting that test passing?
[09:42] <jam> fwereade: as in, it should be only trying 1 time?
[09:42] <fwereade> jam, that's how I read the test name
[09:42] <jam> it passes for me locally
[09:43] <jam> (maybe the issue is that locally it is too fast?)
[09:43] <fwereade> jam, interesting
[09:43] <fwereade> jam, could be
[09:43] <dimitern> fwereade: let me check
[09:43] <jam> fwereade: it fails for you?
[09:43] <fwereade> jam, did just now, don't know whether it's consistent
[09:43] <jam> fwereade: so I believe the code it cares about is in open.go around line 93
[09:44] <dimitern> fwereade, jam: it passes for me - tried 3 times
[09:44] <jam> which has a time.Sleep if you have a connection failure
[09:44] <jam> but no time.sleep if you connect but fail to TLS handshake
[09:44] <fwereade> jam, ah, but the TLS bit below *does* retry but does not delay
[09:44] <fwereade> jam, yeah, ok, I suspect I misread intent
[09:44] <fwereade> jam, sounds timingy then :/
[09:45] <jam> fwereade: that is what I get from the "DoesNotDelay"
[09:45] <fwereade> jam, seems to consistently take 1.5s for me
[09:45] <jam> fwereade: that is what it was taking me as well on go-bot
[09:45] <jam> so it *sounds* a *lot* like an actual sleep somewhere
[09:46] <fwereade> jam, hmm, go version related perhaps?
[09:46] <fwereade> jam, go version go1.1 linux/amd64
[09:46] <jam> fwereade: it failed on gobot with 1.0.2, so I upgraded to 1.0.3 and still failed
[09:46] <jam> fwereade: the fact that you and I both get 1.5s on very different hardware
[09:47] <jam> means I'm pretty confident there is a hidden sleep
[09:47] <jam> or timeout
[09:47] <fwereade> jam, (I thought we'd standardized on go1.1?)
[09:47] <fwereade> jam, yeah
[09:47] <jam> fwereade: there will be no 1.1 in precise
[09:47] <jam> that we can use for building
[09:47] <jam> so use 1.1 when we can, but our syntax needs to stay 1.0.3 compatible
[09:47] <fwereade> jam, oh balls -- I suppose we can't use a PPA?
[09:47] <fwereade> jam, forget it, derail, anyway
[09:47] <jam> fwereade: there are issues with dependent builds
[09:48] <jam> at least for backports
[09:48] <jam> you can get go 1.1 into backports
[09:48] <fwereade> jam, heh, fair enough
[09:48] <jam> but a backport of juju-core can't use debs from other backports to build itself
[09:48] <jam> limitations of the builders
[09:48] <fwereade> jam, blarg, ok
[09:48] <fwereade> jam, good to know then
[09:48] <jam> and we can get 1.0.3 into an SRU (which builders *can* use)
[09:48] <jam> but not a 1.1 sort of change
[09:49] <jam> fwereade: especially given dfc just mentioned there is a bug in 1.1 and we should actually wait for 1.1.1
[09:49] <fwereade> jam, sounds worth investigating... sorry I can't help more :(
[09:49] <fwereade> jam, ah, yeah, dimitern found some gc-related panic?
[09:49] <dimitern> fwereade: yeah, let me find the issue link
[09:50] <dimitern> fwereade: https://code.google.com/p/go/issues/detail?id=5554
[09:50] <fwereade> dimitern, (fwiw, wrt 10 mins ago, please ping me before you implements any watchers that send actual data, rather than notifications... they're not all necessarily invalid, but they deserve discussion)
[09:50] <fwereade> dimitern, cheers
[09:51] <dimitern> fwereade: not planning to implement any today :) but might have to change what's already implemented
[09:52] <fwereade> dimitern, if it's just EnvironConfigWatcher I've kicked that over to frank, he's making provisioner changes
[09:52] <dimitern> fwereade: ah, cool
[09:52] <dimitern> TheMue: ping me if you need help around the api/watchers - it's not pleasant :)
[09:52] <TheMue> jam: test failed here with 1.0.3 too
[09:53] <fwereade> dimitern, (and should thus be the best person to coordinate keeping that precise bit in sync)
[09:53] <TheMue> dimitern: will do
[09:54] <dimitern> fwereade: meet you in 10-15m @cuba?
[09:54] <jam> TheMue: so the real question is why is it passing locally for me :)
[09:55] <jam> on go-bot, I actually see it retrying maybe 6 times
[09:56] <jam> found it, I think
[09:56] <jam> fails locally now
[09:56] <jam> the issue is that mgo driver
[09:56] <jam> changed
[09:56] <TheMue> jam: indeed, a good question
[09:56] <jam> it now sleeps
[09:56] <jam> it didn't as of the earlier rev I was using
[09:57] <jam> TheMue: I think: https://groups.google.com/forum/#!msg/mgo-users/DU5pXpIxCg8/cAXAGWaOl0sJ
[09:57] <jam> " A short delay was introduced at
[09:57] <jam>   this point to minimize the impact of these retries"
[09:57] <fwereade> jam, ahhhh
[09:57] <fwereade> dimitern, sgtm, just about to leave
[09:58] <dimitern> fwereade: omw in 5
[09:59] <jam> fwereade, TheMue: 'time.Sleep(500 * time.Millisecond)' was added to the retry code in mgo
[09:59] <jam> hence, 3 retries (4 total tries), always equals 1.5s for everyone
[10:01] <fwereade> jam, hmm, maybe the answer is to drop the delay in state.open regardless, and suck up the wait?
[10:01] <fwereade> not sure
[10:01]  * fwereade -> lunch
[10:06]  * dimitern lunch as well
[10:06] <TheMue> fwereade, dimitern: enjoy
[10:08] <TheMue> jam: I updated mgo yesterday, so that change may be the reason, yes
[10:12] <jam> TheMue: I'm pretty confident about it. 3 retries * 500ms = 1.5s, which is what we are all seeing.
[10:13] <jam> TheMue: https://bugs.launchpad.net/juju-core/+bug/1183320
[10:13] <_mup_> Bug #1183320: TestOpenDoesNotDelayOnHandshakeFailure fails with updated MGO <test> <juju-core:Confirmed> <https://launchpad.net/bugs/1183320>
[10:13] <jam> TheMue: so right now mgo allows you to specify a custom Dial (which is how we inject TLS support)
[10:14] <jam> does it sound like we should be able to inject a retry delay?
[10:14] <jam> or just punt
[10:14] <jam> and remove the test.
[10:14] <jam> I would think that locally for testing we'd *really* like to set the retry delay to something really low, because we aren't dealing with network partitions while running the test suite.
[10:14] <jam> so sleeping 500ms in a test suite is a bit silyy
[10:15] <TheMue> jam: sgtm
[10:15] <jam> I feel like waiting for a patch to land in mgo so that we can use the Tarmac bot for juju-core and goose is a bit of a *long* way around the problem... :(
[10:19] <TheMue> jam: niemeyer should be available soon
[10:20] <jam> dimitern: for the Units api that you're working on.
[10:20] <jam> Does the individual Unit objects you are returning have 'name' in them?
[10:21] <jam> (I'm guessing they do)
[10:21] <jam> For something like an RPC, I would like to avoid depending on the order being identical to the request order.
[10:21] <TheMue> jam: dimitern is at lunch
[10:21] <jam> also, I don't think we want 1 bad name to fail the rest of the requests because of potentially stale data.
[10:42] <jam> TheMue, fwereade: In go, if you close a channel, then a pending <- on the channel returns, right? And it returns the zero value for the type?
[10:43] <jam> Which means that technically the code in state/presence/presence.go which is waiting on "case <- done:" is actually getting false, but since it is just using it as a block
[10:43] <jam> it doesn't actually care that the result is 'false'
[10:46] <TheMue> jam: one moment
[10:46] <jam> TheMue: I *think* I sorted out that the logic is it wants a channel that returns a bool, but all the inner code does is close the channel it has pending
[10:46] <jam> it never sends something on that channel
[10:47] <TheMue> jam: just looking at the code
[10:47] <jam> it is a bit convoluted :)
[10:48] <jam> I was trying to understand TestSync
[10:48] <jam> as to why it thinks one call to Sync blocks
[10:48] <jam> (for at least 200ms)
[10:48] <jam> but it will be done after a later change.
[10:51] <TheMue> jam: so far it seems you're correct, it's just closing the collected syncs
[10:51] <TheMue> jam: wife called me for lunch, biab
[10:51] <jam> TheMue: enjoy
[11:24] <jam> fwereade, wallyworld_: I just sent an email to the list that is intended to roughly summarize what I got out of our chat last night about API. It would be nice if you could read over it and see where you agree/disagree/have more notes, etc.
[11:25]  * dimitern is back
[11:25] <wallyworld_> ok
[11:25] <dimitern> jam: what's up?
[11:31] <jam> dimitern: I ended up just commenting on your merge proposal
[11:36] <danilos> jam: hi, trouble connecting to mumble server (connection times out :/)
[11:38] <danilos> this seems to be the weird problem I've been seeing since quantal where my internet just stops working for any new connections but IRC keeps ticking along
[11:38]  * danilos reboots
=== wedgwood is now known as wedgwood_away
[12:12] <fwereade> aw hell
[12:14] <fwereade> dimitern, I think LifecycleWatcher is broken... ISTM that we trash intermediate results if the client doesn't pull from out before a new value arrives from in
[12:15] <fwereade> dimitern, also (and this is nothing to do with you) this style completely invalidates the assumptions rog made when he did the original always-call-Next model
[12:15] <fwereade> dimitern, do I recall you saying he was involved in its implementation?
[12:16] <dimitern> fwereade: standup still, will get back to you
[12:16] <fwereade> dimitern, np
[12:57] <TheMue> *hmpf*
[12:57] <fwereade> TheMue, encountering pain?
[12:57] <TheMue> fwereade: only effort. ;)
[12:58] <TheMue> fwereade: agent.Conf and upstart are so self-aware about their location (used in Write() and Install())
[12:58] <fwereade> TheMue, relative to DataDir, right?
[12:59] <TheMue> fwereade: yes, but they also write references to the DataDir as far as I can see
[12:59] <TheMue> fwereade: so using the container dir full qualified here would later to an illegal dir when used from inside the container
[13:00] <fwereade> TheMue, gaah, code reference?
[13:01] <TheMue> fwereade: I have to check, it has been an assumption as it is a field in each struct. but maybe you're right. that would be great.
[13:02] <fwereade> TheMue, I think you just write a conf to the full path, and start the agent with the container-relative path, and you're done
[13:02] <TheMue> fwereade: oh, in agent conf the read value from the file is overwritten by the passed one which is an arg of the jujud
[13:02] <TheMue> fwereade: nice
[13:02] <fwereade> TheMue, oh, we write it out? damn, that's stupid
[13:02] <dimitern> fwereade: just finished, but have to dash out quickly, sorry
[13:03] <fwereade> dimitern, no worries
[13:03] <fwereade> dimitern, ping me when you're back
[13:03] <TheMue> fwereade: we write it, but then, when reading the file in ReadConf(dir, tag), that dir is used.
[13:04] <TheMue> fwereade: so the right one is used later, only in the conf file the full qualified path is written
[13:05] <fwereade> TheMue, it is more than somewhat insane that we write the file's path into the file though, feel free to fix that (or at least comment it, because it's seriously misleading)
[13:05] <fwereade> TheMue, or hell just leave it
[13:05] <TheMue> fwereade: so it only would confuse somebody debugging and reading that file inside a container wondering where this dir comes from
[13:05] <fwereade> TheMue, agnt.Conf is ludicrous anyway :/
[13:06] <TheMue> fwereade: hehe
[13:06] <fwereade> TheMue, it's absurdly overloaded
[13:08] <TheMue> fwereade: absolutely. hmm, wouldn't omit the writing of that field be enough? if it is set each time after reading the file?
[13:08] <fwereade> TheMue, it'd probably be slightly better
[13:08] <fwereade> TheMue, better still to actually *separate* the ancillary in-memory data from the stuff we serialize rather than smooshing it all together
[13:11] <TheMue> fwereade: yes, but it's always so convenient to use a field instead of passing an argument through all nested methods. ;)
[13:13] <fwereade> TheMue, heh :(
[13:13] <TheMue> fwereade: hehe
[13:16] <TheMue> fwereade: *hmpf* again, there are so many references to that DataDir. thankfully most simply reading the field
[13:39] <dimitern> fwereade: back
=== wedgwood_away is now known as wedgwood
[13:53] <fwereade> dimitern, hey, sorry I missed you
[13:53] <fwereade> dimitern, 5 min chat in the hangout before kanban?
[13:58] <dimitern> fwereade: oops, too late i think
[13:59] <dimitern> fwereade: i'm in the kanban g+ now
[14:02] <fwereade> ffs
=== mramm2 is now known as mramm
[16:04] <Makyo> Running into the following problem, would appreciate input: a test is setup with a service (riak), but when running, the assert fails that the service "riak"doesn't exist.  if I deploy riak as the first step of the test, I get "cannot add service \"riak\": service already exists" - any ideas?
[16:09] <Makyo> Here: http://bazaar.launchpad.net/~makyo/juju-core/upgrade-charm2-1171548/view/head:/state/statecmd/upgradecharm_test.go#L80
[16:14] <dimitern> fwereade: mail sent
=== tasdomas is now known as tasdomas_afk
[17:14] <FunnyLookinHat> let's say I wanted to disable the security ( nova / quantum ) group stuff - where would I look to start commenting stuff out in src / trunk ?
=== deryck is now known as deryck[lunch]
=== wedgwood is now known as wedgwood_away
[18:19] <fwereade> FunnyLookinHat, driveby answer: environs/openstack/provider.go:809; and consider stubbing out all the methods with names like OpenPort, ClosePort, etc
[18:19] <FunnyLookinHat> fwereade, perfect - thanks!
=== deryck[lunch] is now known as deryck
=== BradCrittenden is now known as bac________
=== bac________ is now known as bac
[21:02] <wallyworld_> fwereade: hi, if you have a chance, can you take another look at https://codereview.appspot.com/9662048. tim had a question about the --series param and non-ubuntu deployments. i can change the flag's description text to something more generic. perhaps that's all we need for now
[21:05] <thumper> morning
[23:45] <thumper> hi wallyworld_
[23:45] <thumper> wallyworld_: how are you doing today?
[23:45] <wallyworld_> hi, was going to ping you soon. getting through some mechanical changes to clean up some aspects of our errors
[23:46] <wallyworld_> a bit noisy here - guys trashing our bathroom
[23:46] <thumper> hah
[23:46] <wallyworld_> :-(
[23:46] <wallyworld_> $$$$$$$
[23:46] <thumper> expected trashing?
[23:46] <wallyworld_> well, the shower has been rooted for weeks, big leak :-(
[23:46] <thumper> hopefully only one of them and not all at once
[23:47] <thumper> :(
[23:47] <wallyworld_> so they need to pull apart the entire room
[23:47] <thumper> wallyworld_: I've been trying to get loggo working
[23:47] <wallyworld_> cool
[23:47] <thumper> wallyworld_: however there are so many issues with our logging in the tests
[23:47] <thumper> that makes it hard
[23:47] <thumper> time consuming
[23:47] <thumper> and energy sapping
[23:47] <thumper> I need something enervating to do
[23:47] <wallyworld_> yeah, this is my surprised face, not
[23:48] <wallyworld_> we can discuss surrogate ids :-)
[23:48] <bigjools> g'day
[23:48] <thumper> hi bigjools
[23:48] <wallyworld_> bigjools: fuck off
[23:48] <thumper> bigjools: how are you feeling these days?
[23:48]  * thumper slaps wallyworld_
[23:48] <thumper> none of that here
[23:48] <thumper> play nice
[23:48] <wallyworld_> thumper: he knows i'm joking
[23:48] <thumper> wallyworld_: but others reading here don't
[23:48] <wallyworld_> it's the way we say hello in australa
[23:49] <bigjools> it's his standard greeting.  If he doesn't say it I know he hates me :)
[23:49] <thumper> lovely jubbley, say it on the private channels then :)
[23:49] <bigjools> consider yourself bitchslapped wallyworld_
[23:49] <wallyworld_> sigh
[23:49] <bigjools> heh
[23:49] <wallyworld_> everything is so politically correct nowadays
[23:49] <thumper> sarcasm also doesn't come across well on irc
[23:50] <thumper> wallyworld_: be non-pc on private channels, not public logged ones
[23:50] <thumper> sad but true
[23:50] <thumper> aspect of online life
[23:50] <wallyworld_> yeah i know
[23:51]  * thumper sighs
[23:51]  * wallyworld_ sighs again
[23:51]  * thumper looks to bigjools for the next sigh
[23:52] <bigjools> meh
[23:52] <bigjools> tired of sighing lately
[23:52] <bigjools> thumper: anyway to answer your question, I am slightly better than I was thanks.  Had a torrid time last week but seem to be relatively ok at the mo. (fingers crossed)
[23:55] <thumper> cool