[00:12] <anastasiamac> axw: wallyworld: trivial PTAL - http://reviews.vapour.ws/r/3869/ (use in memory store)
[00:12] <wallyworld> ok
[00:19] <wallyworld> axw: i think that ssh fix should just be jfdi?
[00:43] <axw> anastasiamac: that turned out quite neat
[00:43] <axw> wallyworld: I don't think it's important enough to JFDI
[00:44] <axw> wallyworld: we've lived with it for 2 years or so... :)
[01:50] <rick_h__> wallyworld: ping, when you get a sec can you run me through this restore stuff? I'm missing something.
[02:10] <wallyworld> rick_h__: hey sure
[02:11] <rick_h__> wallyworld: https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1 when you get a sec
[02:11] <wallyworld> axw: wanna join
[02:12] <axw> okey dokey
[02:26] <anastasiamac> axw: yes. u r awesome :D
[03:20] <davecheney> thumper: backport PR for 1.25 https://github.com/juju/juju/pull/4431
[03:37] <thumper> davecheney: you don't normally have to worry about reviews for backports
[04:06] <davecheney> oneline timesheet ?
[04:06] <davecheney> i don't like the sound of this
[04:42] <axw> wallyworld: has anyone changed the "juju resolved" command for 2.0 yet?
[04:43]  * axw looks at the code and answers his own question
[04:43] <wallyworld> no, don't think so
[04:43] <wallyworld> we haven't
[04:43] <axw> wallyworld: we're going to tho, right?
[04:43] <wallyworld> yeah, supposedly
[04:43] <wallyworld> but not this week
[04:43] <wallyworld> we'll run out of time
[04:44] <axw> wallyworld: sure. just want to know it's still happening
[04:44] <axw> I don't think anyone likes it as it is
[04:44] <wallyworld> nope
[04:44] <wallyworld> i need to check notes, but in my mind it got approved
[04:52] <axw> wallyworld: I think I just need to fix tests now, new-style switch is working nicely
[04:53] <wallyworld> yay
[04:53] <axw> wallyworld: and I've gotten rid of the current-model file (again)
[04:53] <wallyworld> even better
[06:01] <anastasiamac> anyone has any idea what this online timesheeting is about? per davecheney^^^
[06:20] <axw> wallyworld: juju switch branch: http://reviews.vapour.ws/r/3872/
[06:49] <wallyworld> axw: looking
[06:54] <wallyworld> axw: rick's suggestion is show-controller and show-model without args would display the current controller / model
[06:54] <axw> wallyworld: sounds good
[06:54] <axw> wallyworld: kind of a pain if you just want the name though
[06:55] <wallyworld> axw: i think the intent is just the name
[06:55] <wallyworld> we need that for scripting
[06:55] <axw> wallyworld: ok, I don't really like that then... another dual purpose command
[06:55] <wallyworld> it's still a bit messed up though
[06:55] <wallyworld> yup
[06:55] <wallyworld> let's try it for the beta and get feedback
[06:56] <axw> wallyworld: try show-controller/show-model with no args?
[06:56] <wallyworld> yeah, in the absence of something better. i suggested "juju current-controller" and "juju current-model" and he didn't like it
[06:57] <axw> okay
[06:57] <wallyworld> but i do like my suggestions
[06:59] <axw> wallyworld: if you're making the changes to registration to return the controller UUID, can you please update the "juju register" command to record all the details in jujuclient as well?
[06:59] <axw> wallyworld: controller & account details
[06:59] <axw> wallyworld: if that's too much, I can do it after yours is landed
[07:00] <wallyworld> axw: ok, finishng tests for --share. getting lovely mgo dirty socket errors, will do registration after that if i get a chance after soccer soon
[07:00] <axw> okey dokey
[08:41] <dimitern> mgz, morning :)
[08:42] <dimitern> mgz, it seems a couple of CI jobs have SSH issues and result in false positives for failures
[08:44] <mgz> that's not a false positive
[08:44] <mgz> unless a failure is the result we want?
[08:45] <dimitern> the centos job succeeded apparently
[08:46] <dimitern> it was marked as a failure due to wait_for_port failing eventually with no route to host, which considering we're killing the controller is to be expected
[08:46] <mgz> why does that bug lead nowhere...
[08:47] <dimitern> I was wondering the same :)
[08:49] <dimitern> while the windows job fails similarly (after apparently succeeding) but due to python 2.7 incompatibility?
[08:49] <mgz> yeah, I have a solution for that
[09:04] <frobware> dimitern, ping. sync?
[09:04] <dimitern> frobware, hey
[09:04] <dimitern> frobware, yeah, omw - 2m
[09:23] <axw> wallyworld: I'm going to look at changing the initial model name back to admin, let me know if there's something else you want me to do
[10:00] <dimitern> dooferlad, voidspace, jam, standup?
[10:17] <frobware> dimitern, voidspace, dooferlad: new upstream branch is `maas-spaces2'
[10:19] <dimitern> frobware, cheers, pulling now
[10:21] <frobware> dimitern, voidspace, dooferlad: also deleting existing branch to avoid any confusion.
[10:24] <frobware> and gone
[10:25] <voidspace> frobware: great
[10:28] <dimitern> frobware, done
[10:44] <perrito666> morning
[10:53] <dooferlad> dimitern: do you have a moment to pair up on this?
[10:54] <dimitern> dooferlad, ok, just give me 2m
[10:54] <dooferlad> dimitern: sure, thanks
[10:58] <rick_h__> wallyworld: axw  right, the thing is that adding a new command, doc, tab completing, for such a one off scripting requirement seems :/
[10:58] <rick_h__> wallyworld: axw especially when I could just run switch and know I was there, or use existing commands to get the machine readable data and such
[10:58] <dimitern> dooferlad, standup HO?
[10:58] <dooferlad> dimitern: sure
[11:00] <dimitern> dooferlad, omw
[11:19] <mup> Bug #1546043 opened: unit tests leave apiserver/logsink.log behind <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1546043>
[11:19] <wallyworld> rick_h__: i guess that needs to be balanced against a dual purpose command that is not obvious
[11:21] <rick_h__> wallyworld: how is it dual purpose? It'll show the same info as normal?
[11:21] <wallyworld> use case 1: switch models. use case 2. print the current model
[11:21] <wallyworld> 2 differebt functions
[11:21] <wallyworld> one command
[11:21] <rick_h__> wallyworld: so this isn't the show-model command?
[11:22] <wallyworld> rick_h__: SORRY, I THOUGHT WE WERE TALKING ABOUT JUJU SWITCH
[11:22] <wallyworld> doh, caps
[11:22] <wallyworld> we want to remove the function of juju switch which prints the current model
[11:23] <wallyworld> if we use juju show-model instead, does that print the full yaml or a single name
[11:23] <voidspace> dimitern: ping
[11:23] <rick_h__> wallyworld: the full yaml of info
[11:23] <rick_h__> wallyworld: which includes the name?
[11:23] <wallyworld> if the full yaml, it's a bit of a pain to use in bash to get the name
[11:23] <voidspace> dimitern: so, I can switch from mapping space names to id to mapping subnets to space id instead
[11:24] <voidspace> dimitern: *however*, the effect is *exactly* the same
[11:24] <voidspace> dimitern: because...
[11:24] <voidspace> dimitern: ah no it's not
[11:24] <voidspace> dimitern: forget that
[11:24] <dimitern> :)
[11:24] <wallyworld> rick_h__: as in `juu show-model` and assigning that to a var
[11:24] <voidspace> dimitern: when maas lists subnets it only gives the space name - so I thought I still needed a name -> id map
[11:24] <voidspace> dimitern: however, the subnets are listed *within the space data structure*
[11:25] <voidspace> dimitern: so you already know the space id...
[11:25] <voidspace> so you don't need to lookup by name
[11:25] <voidspace> my bad :-)
[11:25] <dimitern> voidspace, exactly, and since the discovery will list spaces rather than subnets we'll have all bits we need in 1 api call - ids and names included (both for spaces and subnets)
[11:49] <rick_h__> wallyworld: sorry, was otp.
[11:49] <wallyworld> np
[11:49] <perrito666> wallyworld: well apparently last nights storm was a bit over average, it about 2 hs of duration it killed 3 people, broke countless trees and flooded hundreds of houses :p
[11:49] <rick_h__> wallyworld: I think that list-models should indicate current model, and that show-model without an arg shows details for the current model.
[11:50] <rick_h__> wallyworld: I know it's a pain to grab the name, but really it should be a simple grep'ing of the header?
[11:50] <rick_h__> wallyworld: or there's tools for parsing out the yaml
[11:50] <rick_h__> wallyworld: but since you're scripting it's not that it has to be simple/human one liner. You're assumption is they're running code
[11:50] <wallyworld> rick_h__: sure, just having a simple cli way to print just the name is very useful and we are taking that away
[11:51] <rick_h__> call the field model-name and a 'juju show-model | grep model-name' won't work?
[11:51] <wallyworld> guess so
[11:51] <rick_h__> wallyworld: right, but I just don't think it's useful enough for a one off command imo
[11:51] <wallyworld> np, your call, we can always add it if people complain
[11:51] <rick_h__> wallyworld: +1 I've been known to be wrong before :)
[11:52] <rick_h__> but you did ask my opinion :P
[11:52] <wallyworld> i did, and i expressed mine also. one of us will be proven to be right
[11:52]  * rick_h__ bets a bottle of wine on it 
[11:52] <rick_h__> let's make it interesting!
[11:52] <wallyworld> ok :-)
[11:54] <perrito666> we should start putting those things in the code
[11:54] <perrito666> like // if you remove/add this line inform X that he/she must pay a wine bottle to Y
[11:58]  * perrito666 enjoys of a rather good connection even though its only 10/2M only because every possible other user has a power outage so the whole connection is for him
[14:01] <mup> Bug #1546100 opened: Upgrade 1.24.7 -> 1.25.3 fails <juju-core:New> <https://launchpad.net/bugs/1546100>
[14:10] <alexisb> morning all
[14:11] <perrito666> alexisb: morning
[14:15] <rick_h__> morning alexisb
[14:44] <perrito666> lets say that I need to destroy-controller --force, and we no longer have force, what do I do now?
[14:55] <anastasiamac> perrito666: i think that kill-controller is kind of like destroy-controller-with-force
[14:55] <perrito666> yup, it is
[14:56] <perrito666> it is odd destroy sounds much more final than kill
[14:56] <anastasiamac> perrito666: neither work really well for me... I have to restart my computer if I want to re-bootstrap after. otherwise, I get "no matching addreses" error :(
[14:56] <anastasiamac> yes \o/
[14:56] <perrito666> oh, I have not tried to rebootstrap
[14:57] <anastasiamac> well, neither wallyworld nor axw have the same issue... deleting all caching files does not help :/ so dunno and don't have enough time to figure it out :D
[14:57] <anastasiamac> so there is a chance u r not affected :D
[14:58] <perrito666> karma hates me, I am most likely affected :p
[14:58] <anastasiamac> perrito666: and here I thought I was the only one with bad karma
[15:01] <alexisb> anastasiamac, what time is it for you?
[15:02]  * rick_h___ guesses late
[15:02] <perrito666> rick_h___: or early
[15:02] <perrito666> 1AM?
[15:04]  * anastasiamac wondering what answer alexisb would like to hear
[15:04] <anastasiamac> alexisb: it's good time for me :D i *think* i solved a bug
[15:04] <alexisb> I am going to bed
[15:04] <alexisb> ^^ that answer
[15:04] <alexisb> :) that is good
[15:04] <anastasiamac> alexisb: oh. k.. yes.. i will be :D
[15:04] <rick_h___> being aware at this time sounds like a bug :P
[15:04] <mup> Bug #1546135 opened: Joyent region not respected <bootstrap> <joyent-provider> <juju-core:New> <https://launchpad.net/bugs/1546135>
[15:08] <perrito666> rick_h___: I am sure she will come to her senses tomorrow morning when trying to re-read her code :p
[15:08] <perrito666> happens to me all the time
[15:11] <alexisb> frobware, I will be late to our 1x1, will ping
[15:13] <mup> Bug #1546135 changed: Joyent region not respected <bootstrap> <ci> <joyent-provider> <regression> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546135>
[15:25] <frobware> alexisb: probably a good idea as I have bouncing my machine a lot...
[15:26] <alexisb> k
[15:28] <mup> Bug #1546135 opened: Joyent region not respected <bootstrap> <joyent-provider> <juju-core:New> <https://launchpad.net/bugs/1546135>
[15:31] <mup> Bug #1546135 changed: Joyent region not respected <bootstrap> <joyent-provider> <juju-core:New> <https://launchpad.net/bugs/1546135>
[15:35] <mup> Bug #1546142 opened: After restore, the controller shows its local-cloud address as its public address <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1546142>
[15:38] <mup> Bug #1546142 changed: After restore, the controller shows its local-cloud address as its public address <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1546142>
[15:41] <mup> Bug #1546142 opened: After restore, the controller shows its local-cloud address as its public address <backup-restore> <juju-core:Triaged> <https://launchpad.net/bugs/1546142>
[15:51] <natefinch> fwereade: got a minute? I have a uniter question
[15:51] <fwereade> natefinch, sure
[15:52] <perrito666> lol, a minute for a uniter question
[15:52] <natefinch> fwereade: we're trying to update the code in the uniter so that charm-upgrade fires for updates resources as well as updated charmURL... but I seem to be having some trouble.. the hook fires ok... but it fires over and over. There's a localstate and remotestate that need to get synced and I am evidently not doing that correctly
[15:52] <cherylj> perrito666: lol!
[15:52]  * fwereade frantically swaps mental context
[15:55] <fwereade> natefinch, ok, so you have a resolver.LocalState and a remotestate.Snapshot
[15:56] <natefinch> fwereade: yes
[15:56] <fwereade> natefinch, LocalState encodes how you look right now, and the Snapshot tells you how you should look, and some NextOp implementation compares the two and decides what should be done next
[15:57] <fwereade> natefinch, so presumably there's some new representation of the resource version in each of those?
[15:57] <natefinch> fwereade: yep.
[15:58] <natefinch> fwereade: we call it the CharmModifiedVersion, just an int that increments when something in the charm changes
[16:01] <fwereade> natefinch, so it's a value supplied by the apiserver? and you set it on local-state, to the value-that-triggered-the-op, when you commit whatever operation makes resource changes?
[16:01] <natefinch> fwereade: I think it's that last bit that I'm having trouble with.  This stuff is all spread across like 7 files
[16:02] <fwereade> natefinch, yeah, I can imagine that's the point at which it's hard to close the loop
[16:03] <fwereade> natefinch, so, a bit more context: what operation is responsible for writing new charm resources?
[16:03] <fwereade> natefinch, does a deploy op now Do More, or is a resource change distinct? I can imagine they'd be tricky to separate?
[16:04] <natefinch> fwereade: deploy does more (you can also update resources later independently of the charm version)
[16:04] <natefinch> fwereade: https://github.com/juju/juju/pull/4439/files
[16:11] <fwereade> natefinch, ok, that makes sense
[16:12] <fwereade> natefinch, I think all your other operations are resetting CharmModifiedVersion to 0
[16:13] <fwereade> natefinch, at least, all the ones that call stateChange.apply
[16:14] <mup> Bug #1545196 changed: Juju claims AWS ap-northeast-2 not found <ci> <ec2-provider> <regression> <juju-core:Invalid> <juju-core cloud-credentials:Fix Released by wallyworld> <https://launchpad.net/bugs/1545196>
[16:14] <fwereade> natefinch, I'd leave that field off stateChange, and just write it explicitly into the returned *State from the deploy op
[16:14] <bogdanteleaga> I did something similar not long ago, isn't something like this needed? https://github.com/juju/juju/blob/master/worker/uniter/resolver/opfactory.go#L130
[16:14] <bogdanteleaga> to update the localstate
[16:17] <fwereade> natefinch, listen to this man, he speaks truth
[16:17] <fwereade> wrapUpgradeOp should be the right place
[16:17] <natefinch> awesome, ok
[16:20] <mup> Bug #1545207 changed: Rackspace os-security-groups not found <bootstrap> <ci> <rackspace> <regression> <juju-core:Invalid> <juju-core cloud-credentials:Fix Released> <https://launchpad.net/bugs/1545207>
[16:35] <mup> Bug #1545207 opened: Rackspace os-security-groups not found <bootstrap> <ci> <rackspace> <regression> <juju-core:Invalid> <juju-core cloud-credentials:Fix Released> <https://launchpad.net/bugs/1545207>
[16:41] <natefinch> fwereade, bogdanteleaga: thanks for the help, that seems to have done the trick!
[16:43] <bogdanteleaga> great :)
[16:44] <mup> Bug #1545207 changed: Rackspace os-security-groups not found <bootstrap> <ci> <rackspace> <regression> <juju-core:Invalid> <juju-core cloud-credentials:Fix Released> <https://launchpad.net/bugs/1545207>
[16:44] <mup> Bug #1455629 opened: TestResumerCalls <intermittent-failure> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1455629>
[16:44] <mup> Bug #1456725 opened: TestActionEvents fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1456725>
[17:14] <voidspace> dooferlad:  frobware: trivial one if you have time, but needed for my tests: https://github.com/juju/gomaasapi/pull/5
[17:19] <frobware> voidspace: occasionally fails for me
[17:20] <frobware> voidspace: http://pastebin.ubuntu.com/15094253/
[17:21] <voidspace> frobware: weird, looking
[17:21] <frobware> voidspace: that's on xenial using go1.6rc2
[17:21] <frobware> voidspace: 1 in 3 times
[17:21] <voidspace> frobware: it sometimes fails on an unsupported platform with an unsupported version of go?
[17:21] <voidspace> hmmm... how much do I care? ;-)
[17:22] <voidspace> frobware: can't get it to fail here
[17:22] <voidspace> I wonder if it's a dict iteration order or something
[17:22] <frobware> voidspace: heh. well, I mentioned that because I jumped to xenial today...
[17:24] <voidspace> different DNSServers
[17:24] <voidspace> odd
[17:24] <voidspace> on a subnet
[17:24] <voidspace> shouldn't be possible
[17:25] <voidspace> ah, no - different order of subnets
[17:25] <voidspace> so it is dictionary iteration order
[17:25] <voidspace> a nuisance to fix - I'll see if I can make it deterministic
[17:25] <voidspace> frobware: to be fair this PR doesn't introduce that problem
[17:26] <voidspace> but it needs fixing
[17:28] <voidspace> frobware: updated version shouldn't fail
[17:32] <frobware> voidspace: trying again
[17:34] <frobware> voidspace: thanks for supporting my unsupported combo. :-)
[17:34] <frobware> voidspace: LGTM
[17:34] <voidspace> hehe
[17:34] <voidspace> might have been the go version
[17:34] <voidspace> might not
[17:34] <voidspace> but it needed fixing
[17:34] <voidspace> frobware: thanks
[18:33] <jose> katco: ping
[18:33] <katco> jose: pong
[18:34] <jose> katco: hey, just read your email and I was thinking on something similar earlier today with my team
[18:34] <katco> jose: yeah?
[18:34] <jose> just wanted to make sure we're on the same idea
[18:34] <jose> with resources/units you mean machines?
[18:34] <jose> like, a 2GB 2cores machine, and a 4GB 4 cores machine?
[18:35] <katco> jose: ah, no
[18:35] <katco> jose: sorry, "resources" is a new concept we're developing in juju
[18:35] <katco> jose: think "binary blobs of data"
[18:35] <jose> oh gotcha
[18:35] <katco> jose: isos, tar files, runtimes, w/e
[18:35] <jose> sorry about the confusion :)
[18:35] <jose> yep
[18:36] <katco> jose: no worries at all. do you think i need to send a clarifying follow-up?
[18:36] <jose> it's probably just me not catching up with stuff
[18:37] <katco> jose: it looks as if i have another response, so that will probably steer the conversation in the right direction
[18:37] <jose> awesome, thanks :)
[18:37] <katco> jose: thanks for reaching out all the same :)
[19:44] <natefinch> ericsnow, katco: btw, got the upgrade-charm hook firing exactly right... working on tests and removing some unneeded code now
[19:45] <ericsnow> natefinch: sweet!
[19:45] <katco> natefinch: nice!
[20:00] <mup> Bug #1546272 opened: doc: docs/devel/developer-layers-interfaces typo: get_remove <docs> <juju-core:New> <https://launchpad.net/bugs/1546272>
[20:07] <perrito666> well, joy and happiness, a storm stronger than yesterday' s is approaching...
[20:08] <ericsnow> do we have any workers where code sends a request to the worker then blocks until the result comes back from the worker?
[20:09] <natefinch> ericsnow: workers are usually selfcontained... I don't think we usually send them messages.. they just read info off watchers and/or call the API if they need outside info
[20:10] <ericsnow> natefinch: that's my understanding as well
[20:11] <natefinch> ericsnow: my thought is that if you need to give information to a worker, you do so by putting it into mongo
[20:31] <mup> Bug #1532629 changed: Juju 2.0 should use a different default JUJU_HOME <juju-release-support> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1532629>
[20:43] <mup> Bug #1532629 opened: Juju 2.0 should use a different default JUJU_HOME <juju-release-support> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1532629>
[20:52] <mup> Bug #1532629 changed: Juju 2.0 should use a different default JUJU_HOME <juju-release-support> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1532629>
[20:58] <natefinch> OMG, I hate trying to figure out what's actually wrong when a uniter test fails....
[20:58] <katco> natefinch: it didn't get better in that regard?
[20:59] <natefinch> katco: uh... no
[20:59] <katco> natefinch: :(
[21:00] <natefinch> katco: here's an example test failure (with literally thousands of lines of logging stripped out): http://pastebin.ubuntu.com/15095985/
[21:01] <katco> natefinch: ah, is this related to my table-driven test gripe? e.g. you can't run the 1 test you think is broken?
[21:02] <natefinch> katco: partially... but also that they have factored out so much of the test that you can't actually tell what it's doing, and the failure is deep in some helper function
[21:02] <katco> boo =|
[21:05] <perrito666> I know I said this many times before but: status tests are a soul crushing torture
[21:05] <natefinch> katco: like... what is this testing? https://github.com/juju/juju/blob/master/worker/uniter/uniter_test.go#L723   The error I get is "never reached desired status"
[21:06] <katco> natefinch: are the structs passed in steps to perform?
[21:06] <perrito666> they seriously feel like being offered a leaf of lettuce and a small glass of hot wather after a marathon
[21:07] <katco> perrito666: lol that is an incredible analogy
[21:07] <perrito666> ahh never reached desired status, one of my favorites, nate you can ad c.Logf() in the status checking with more info oterwise it will mask the fact that you might be erroring
[21:12] <natefinch> perrito666: thanks
[21:13] <natefinch> katco: FWIW, it looks like they did break it up so it's one test per test function now
[21:13] <katco> natefinch: \o/ small victories
[21:14] <natefinch> katco: yep, at least it's a step in the right direction, and I don't have to run 4 minutes worth of tests for one failure
[21:26] <menn0> anastasiamac: I just reviewed your simplestreams signing change
[21:51] <anastasiamac> menn0: \o/
[21:52] <menn0> wallyworld: juju add-user --share reviewed
[21:52] <wallyworld> oh wow, thanks menn0
[21:55] <wallyworld> menn0: juju register is in the cloud-credentials branch
[21:56] <menn0> wallyworld: ok cool, ignore that then. I was hoping it was something like that.
[21:56] <perrito666> our expected vs obtained test logs, especially the ones that show missmatch between maps are insanely user unfriendly
[21:56] <wallyworld> np, all a WIP
[21:56] <wallyworld> perrito666: depends if gc of js is used
[21:56] <wallyworld> jc
[21:56] <wallyworld> jc is better
[21:57] <perrito666> wallyworld: none does a pretty print
[21:58] <wallyworld> pprint is for pussies :-) real men look at base64 and can tell the error :-)
[21:58] <perrito666> base64 is for weaks, real men feel the humming of the pc running tests and know the errors
[21:59] <wallyworld> yes!
[21:59] <perrito666> this is a beautiful example https://pastebin.canonical.com/149939/
[21:59] <perrito666> that usually gets printed line wrapped
[22:04] <perrito666> wallyworld: I got a LTE modem in case storm returns
[22:04] <wallyworld> dedication
[22:06]  * anastasiamac wonders what a definition of real women will be then...? just look at real men and know they are buggy?.. 
[22:11] <perrito666> uhhh, burn
[22:27] <perrito666> this modem is already paying for itself
[22:45] <blahdeblah> anastasiamac: +1
[23:05] <axw> katco: I take it wallyworld's suggested time doesn't suit someone? I'm afraid your invite is way too early for me :(
[23:05] <katco> axw: yeah =/ it's not meant to be permanent, just until we can figure something out
[23:05] <axw> katco: okey dokey
[23:05] <katco> axw: the problem is that the suggested time will always interrupt someone's family dinner
[23:05] <axw> katco: fair enough
[23:06] <katco> axw: it's just going to be difficult, but we'll work out something
[23:06] <katco> axw: also, i don't think i made this clear in the email: for now there will be 2 stand-ups until we do get that figured out
[23:07] <katco> axw: so you aren't being cast off or anything :)
[23:07] <axw> katco: heh :)  ok, no worries
[23:07] <axw> katco: I keep getting told I'm optional...
[23:07] <anastasiamac> axw: really? by whom?
[23:07] <anastasiamac> axw: we r all optional in comparison to u \o/
[23:08] <katco> axw: if you have imposter syndrome, i will be full on neurotic ;p
[23:09] <axw> a little bit doesn't hurt
[23:09] <axw> impostor syndrom.. not neurosis
[23:10] <axw> wallyworld: have you seen the latest CI results for cloud-credentials? looks very sick
[23:10] <axw> sick in a bad way, not fully sick
[23:10] <wallyworld> axw: yes, will discuss in standup
[23:10] <axw> wallyworld: ok
[23:33] <perrito666> so much struct duplication
[23:37] <axw> anastasiamac: I've added a comment to the tags bug, I think it should point you in the right direction
[23:38] <anastasiamac> axw: \o/
[23:44] <perrito666> anyone here is allwatcher savvy I have a sudden doubt
[23:44] <perrito666> ?
[23:44] <perrito666> nevermind