[00:41] <waigani> wallyworld: fix: http://reviews.vapour.ws/r/2603/
[00:41] <wallyworld> ty, looking
[00:42] <wallyworld> waigani: we need a test also
[00:42] <waigani> wallyworld: okay, I'll add that now
[00:42] <wallyworld> in general, any bug fix should be accompanied by a test
[00:42] <wallyworld> ty
[00:56] <waigani> wallyworld: test added
[00:56] <wallyworld> looking
[00:59] <axw> wallyworld: so just so I understand the status history change: previously we didn't store the latest status in history, and now we do? and because of that, returning history would duplicate the latest?
[00:59] <wallyworld> waigani: lgtm but are there any call sites to update (see comment in review)
[01:00] <waigani> looking
[01:00] <wallyworld> axw: yes - william did a whole lot of refactoring there and changed how status history was recorded, but the retrieval method wasn't unit tested nor updated to match
[01:01] <axw> wallyworld: ok
[01:01] <wallyworld> axw: tested live, works nicely
[01:02] <wallyworld> waigani: actually, how do we handle the "never logged in" case now in a new 1.26 install?
[01:12] <waigani> wallyworld: so user.LastLogin() will return a time.Time{} but the API server will still return a nil. See checkCreds func in apiserver/admin.go for example.
[01:12] <waigani> wallyworld: there is also a feature test to ensure we display the correct "never connected" message, e.g. TestSystemEnvironmentsCommand
[01:14] <axw> wallyworld: reviewed
[01:15] <wallyworld> waigani: without being overly familar with the code, would it be better to return a NeverLoggedInError ? ie is there a record that we just should not write out during the upgrade if last login is nil
[01:16] <wallyworld> axw: thanks, looking
[01:20] <wallyworld> axw: with HistoricalUnit, I think I ran into the same issues as in the uniter work recently - too much existing code being called back into. i'll double check though if i can rework it
[01:20] <axw> wallyworld: thanks
[01:21] <waigani> wallyworld: you're talking about the upgrade step? If user has never logged in, skip creating a lastLoginDoc? Actually, yes that makes more sense.  As user.LastLogin() returns neverConnectedErr for a missing lastLoginDoc.
[01:21] <wallyworld> waigani: exactly
[01:21] <waigani> wallyworld: I'll redo fix
[01:21] <wallyworld> ta
[01:22] <wallyworld> i was a bit hastely with my shipit :-)
[01:42] <davechen1y> https://github.com/juju/juju/pull/3226
[01:42] <davechen1y> here is an easy one
[01:46] <waigani> wallyworld: third time lucky: http://reviews.vapour.ws/r/2603/
[01:46] <wallyworld> looking
[02:48] <davechen1y> waigani: your branch failed to merge
[02:49] <waigani> davechen1y: I saw. I can't see how the panics are related to my changes. I'm halfway through running all unit tests locally.
[03:08] <davechen1y> usual background test failures i'd say
[03:34] <waigani> davechen1y, wallyworld: fix merged. updating bug...
[03:34] <wallyworld> awesome, ty
[03:58] <wallyworld> jam: i got a surprise - i looked at juju/charm.v5 and see that there's already a Series metadata attribute which contains a single series. But I can see any charms which use it (I didn't look hard). So I think we could attempt to parse both a scalar and a list maybe and if a scalar, emit a deprecation warning and make it a single value list. What do you think?
[03:58] <jam> wallyworld: it should be "serieses", clearly :)
[03:59] <wallyworld> barf
[04:00] <davechen1y> series is an irregular noun
[04:00] <davechen1y> like sheep
[04:00] <jam> yes, I realize that the plural of series is series, it is just fun to be silly.
[04:00] <jam> hence the smiley
[04:00] <wallyworld> indeed
[04:01] <jam> wallyworld: Sounds fine to me to go with a single-or-list sort of parsing, though it probably complicates our internal structure.
[04:01] <wallyworld> i'll mark the parsing tolerant
[04:01] <wallyworld> i'll also asl eco who uses it
[04:02] <jam> wallyworld: I wonder if we actually have it there because we use that spot internally to store what we cached the charm for
[04:02] <jam> as in, it isn't for the data in charm's metadata file, but instead for what we store in the DB
[04:02] <jam> Looking at: https://github.com/juju/charm/blob/v5/meta.go that only has "bson" notation, which means its for the DB, right?
[04:02] <wallyworld> i couldn't see any obvious usages in juju code, but will look harder
[04:03] <wallyworld> yeah, that could be right actually
[04:03] <wallyworld> makes sense
[04:03] <wallyworld> but that sure now complicates it
[04:03] <wallyworld> might have to go with "os-series"
[04:04] <wallyworld> that's what mark changed it to in the spec originally
[04:05] <wallyworld> jam: also, i need to get the resources spec moving again. are you able to schedule some time to have another look before it goes to mark?
[04:05] <jam> wallyworld: so IIRC it seemed good enough before I left, but if you want me to look at it again, I can.
[04:06] <wallyworld> jam: i added stuff to the vcs and web source bits, mainly around authentication etc
[04:06] <wallyworld> i think those are well enough defined for a mvp
[04:06] <wallyworld> since i added material after you last looked, a once over would be great
[04:16] <wallyworld> jam: i looked harder at meta.go, and there is a yaml serialisation tag for Series. so seems like it can be defined in metadata.yaml
[06:35]  * fwereade has just discovered it's a public holiday today
[06:51]  * fwereade has *also* been being a terrible person and failing to look at reviews he should
[06:52] <fwereade> axw, don't suppose you're free to take a very quick look at the uniter interactions in http://reviews.vapour.ws/r/2593/ ?
[08:11] <axw> fwereade: sorry was out. I'll take a look
[08:26] <axw> fwereade: seems fine, apart from growing complexity.
[08:27] <fwereade> axw, I was mainly thinking about "how does it interact with the maltese-falcon changes"
[08:59] <axw> fwereade: I see. still looks fine.
[09:03] <rogpeppe> fwereade: aargh, i just made a bunch of replies to http://reviews.vapour.ws/r/2597 and reviewboard seems to have lost them all. doesn't it save replies as drafts?
[09:03] <fwereade> rogpeppe, I thought it did
[09:04] <rogpeppe> fwereade: ah, false alarm. for some reason they just weren't showing for me.
[11:59] <jam> wallyworld: hey, I'm not feeling great. Since rick can't be at the meeting anyway, can we just do it tomorrow, more around 6UTC ?
[12:00] <wallyworld> jam: sure, works for me
[12:00] <wallyworld> hope you're feeling btter
[12:00] <jam> thanks. I started some antibiotics today, so I expect to be doing better
[12:01] <wallyworld> we can move on resources also
[12:03] <rogpeppe> wallyworld, anyone else: http://reviews.vapour.ws/r/2606/ move to using charm.v6-unstable
[12:03] <wallyworld> rogpeppe: looking
[12:03] <rogpeppe> wallyworld: thanks
[12:04] <wallyworld> rogpeppe: says there are conflicts, were you aware?
[12:04] <rogpeppe> wallyworld: i resolved them
[12:05] <rogpeppe> wallyworld: perhaps i should take the conflict messages out of the PR description
[12:05] <wallyworld> tis ok, i now know, but yeah
[12:06] <rogpeppe> wallyworld: done (well, I edited the PR description in github - i'm hoping that's sufficient)
[12:06] <wallyworld> np :-)
[12:09] <wallyworld> rogpeppe: just started looking - are all those dependencies.tsv changes deliberate?
[12:09] <rogpeppe> wallyworld: yes
[12:09] <rogpeppe> wallyworld: i tried to make them as minimal as possible
[12:09] <wallyworld> np, ty
[12:09] <rogpeppe> wallyworld: new deps are on the latest version
[12:10] <wallyworld> rogpeppe: and the new deps has charm.v5-unstable?
[12:10] <rogpeppe> wallyworld: ues
[12:10] <rogpeppe> yes
[12:10] <wallyworld> not v6?
[12:10] <rogpeppe> ah, no
[12:10] <rogpeppe> it *should* have v6-unstable
[12:10] <rogpeppe> let me check
[12:11] <rogpeppe> wallyworld: looks right to me
[12:12] <rogpeppe> wallyworld: uses charm.v6-unstable
[12:13] <wallyworld> rogpeppe: gopkg.in/juju/charmstore.v5-unstable	git	a921c6c69d74361c38a99a95d2aceec76533038d	2015-08-27T20:19:40Z
[12:13] <wallyworld> i copied that from the review board diff
[12:13] <rogpeppe> wallyworld: that's charmstore, not charm
[12:13] <wallyworld> oh ffs
[12:14] <wallyworld> sorry, is late here
[12:14] <rogpeppe> wallyworld: np
[12:14] <wallyworld> sigh
[12:14] <rogpeppe> wallyworld: i've made that mistake several times before :)
[12:20] <wallyworld> rogpeppe: wow. so much churn. i miss python where you could update *one* file to change a dep. that's what i was refering to before in the email :-)
[12:20] <wallyworld> it's a hell of a lot to look over for a dep change. imo churn should be avoided :-)
[12:21] <rogpeppe> wallyworld: yeah, i have to say i think there should be a better way. haven't found one yet though.
[12:21] <perrito666> wallyworld: all is fun and games until you return an object from the wrong version of a lib :p
[12:21] <wallyworld> use python :-D
[12:23] <wallyworld> also maks me wonder if we've done the right thing threading charm store dependency through so many of our files
[12:23] <rogpeppe> wallyworld: charm store dependency != charm dependency
[12:23] <wallyworld> s/charmstore/charm
[12:23] <wallyworld> sorry, mistyped
[12:24] <rogpeppe> wallyworld: it's not that surprising - charms are at the heart of what juju does
[12:25] <wallyworld> true, was musing out loud maybe it could be encapsulated in some helpers
[12:25] <wallyworld> but probably a crap iea
[12:25] <wallyworld> just annoyed by the churn and trying to think of how to isolate it :-)
[12:26] <rogpeppe> wallyworld: it would be nice if there was a way to view diffs without showing changes that were just import path changes
[12:27] <wallyworld> yeah, that would be nice
[12:29] <rogpeppe> wallyworld: at least with the change from v6-unstable to v6, the change will be *entirely* automatic - you won't even need to look through the diff
[12:30] <wallyworld> true
[12:33] <wallyworld> rogpeppe: +1 but i dislike the error message changes :-)
[12:34] <rogpeppe> wallyworld: thing is that now those URLs can refer to both charms and bundles
[12:34] <rogpeppe> wallyworld: so "charm URL" is technically wrong
[12:34] <wallyworld> so "charm or bundle" then ?
[12:34] <wallyworld> entity has no meaning for an end user
[12:36] <rogpeppe> wallyworld: yeah. i'm not keen on "entity" either
[12:36] <rogpeppe> wallyworld: but "charm or bundle" seems clumsy
[12:36] <wallyworld> can it be changed?
[12:36] <wallyworld> accurate and clear
[12:36] <wallyworld> though
[12:36] <wallyworld> or even "charm/bundle not found" works
[12:37] <wallyworld> maybe not with the / as that could be confusing
[12:37] <wallyworld> but still "entity" kinda sucks
[12:37] <rogpeppe> wallyworld: i'd prefer to change it in another PR if that's OK
[12:38] <wallyworld> sure, that's why i didn;t mark it a blocker, just a whine :-)
[12:38] <rogpeppe> wallyworld: :)
[12:38] <wallyworld> right, i better get sleep before i confuse charm and charmstore again
[12:41] <rogpeppe> hmm, if this bug https://bugs.launchpad.net/juju-core/+bug/1493016 is marked as fix-committed, why is master still blocked? http://juju.fail/
[12:41] <mup> Bug #1493016: Panic on upgrade from 1.22 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Fix Committed by waigani> <https://launchpad.net/bugs/1493016>
[13:04] <frobware> dimitern, you joining the MAAS HO?
[13:12] <dimitern> frobware, yeah, omw
[13:12] <frobware> dimitern, too late. Call just dropped. :)
[13:12] <dimitern> frobware, oh :/ too bad
[13:12] <frobware> dimitern, 10 minutes and you're out!
[13:12] <frobware> :)
[13:12] <dimitern> frobware, I was fighting until a few minutes ago to fix my config here
[13:13] <frobware> dimitern, want to HO around the SubnetsAvailabilityZoneNames card?
[13:13] <dimitern> frobware, I managed to break bash, unity, emacs and dbus with just a few edits in the wrong places :)
[13:13] <dimitern> frobware, all fixed now though ..
[13:13] <frobware> dimitern, well the Emacs is obviously bad; the rest? meh... :)
[13:14] <dimitern> frobware, sure, but as I need to go to the store now, how about to do it in ~30m?
[13:14] <frobware> dimitern, yep np
[13:47] <dimitern> frobware, hey, I'm back
[13:48] <frobware> dimitern, want to use the standup HO?
[13:48] <dimitern> frobware, joining our 1:1 HO
[13:48] <dimitern> frobware, :)
[14:01] <voidspace> dimitern: ping
[14:13]  * perrito666 returns from the mecanic and figures he chose the wrong career
[14:31] <natefinch> perrito666: lol that is what I think every time I have to pay someone to do something for me.
[14:32] <perrito666> natefinch: well, he had to rebuild the whole engine cooling system, Its not like I can complain
[14:42] <mgz> perrito666: well I'm glad the mechanic could fix you
[14:42] <mgz> would be a shame to have to sell you for scrap
[14:45] <voidspace> frobware: ping
[14:48] <perrito666> mgz: lol
[15:15] <frobware> voidspace, pong; in a HO with dimitern
[15:27] <voidspace> frobware: ok
[15:30] <mup> Bug #1493016 changed: Panic on upgrade from 1.22 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Fix Released by waigani> <https://launchpad.net/bugs/1493016>
[16:22] <mup> Bug #1493444 opened: juju upgrade from 1.24-beta2 to 1.24.5 broken <juju-core:New> <https://launchpad.net/bugs/1493444>
[16:25] <mup> Bug #1493444 changed: juju upgrade from 1.24-beta2 to 1.24.5 broken <juju-core:New> <https://launchpad.net/bugs/1493444>
[16:27] <mramm> Could someone respond to this bug: https://bugs.launchpad.net/juju-core/+bug/1490865
[16:27] <mup> Bug #1490865: destroy-environment on an unbootstrapped MAAS environment can release all my nodes <cloud-installer> <oil> <juju-core:New> <MAAS:Triaged> <https://launchpad.net/bugs/1490865>
[16:31] <mup> Bug #1493444 opened: juju upgrade from 1.24-beta2 to 1.24.5 broken <juju-core:New> <https://launchpad.net/bugs/1493444>
[16:31] <marcoceppi> who did the status-history stuff?
[16:31] <mgz> what's the new way of connecting directly to mongodb on the state server?
[16:31] <mgz> marcoceppi: perrito666 mostly
[16:32] <marcoceppi> perrito666: you around? I'm trying to figure out the API endpoint for status-history
[16:33] <mramm> For bug #1490865 I am interested in people's opinion
[16:33] <mup> Bug #1490865: destroy-environment on an unbootstrapped MAAS environment can release all my nodes <cloud-installer> <oil> <juju-core:New> <MAAS:Triaged> <https://launchpad.net/bugs/1490865>
[16:35] <marcoceppi> Is there a list of the API endpoints? or doc on that?
[16:36] <mramm> that bug reportedly has juju destroying nodes it didn't create
[16:36] <mramm> and it is reproducable
[16:36] <mramm> BUT it does require passing --force --yes  to destroy environment on an non-existent environment.
[16:39] <marcoceppi> mramm: having been bitten by this, it's a huge problem
[16:39] <mramm> were you bit by this recently?
[16:40] <marcoceppi> I had a similar issue 10 months ago on MAAS
[16:40] <marcoceppi> issue/experience
[16:40] <mramm> that was a separate issue IIRC
[16:40] <mramm> we added behavior to juju to not kill things it doesn't know about in MAAS
[16:40] <mramm> even if they are by the same user
[16:40] <marcoceppi> ack
[16:41] <mramm> BUT in this case, we can't know about anything as there is no juju server to talk to
[16:42] <mramm> I expect that calling "destroy-environment --force --yes maas" on a non-existent environment to be dangerous
[16:42] <mgz> mramm: this would not be an issue were it not for the fact ever tearing down juju properly requires --force --really --super-hard
[16:43] <mgz> destroy-environment without flags just leaves stuff half-torn down too much of the time to do anything else...
[16:44] <mramm> to fix this we would need to know how to reliably differentiate juju deployed maas instances from those that are not juju deployed.
[16:45] <mramm> the current implication does this -- but requires an active juju state server to talk to (since it knows)
[16:45] <mramm> possibly we could just include maas-agent-name in the config even before we bootstrap
[16:46] <mramm> which isn't 100% reliable (unless we use a GUID for the name)
[17:10] <mup> Bug #1493458 opened: backups restore: fails when machine number differs <juju-core:New> <https://launchpad.net/bugs/1493458>
[17:28] <mup> Bug #1489087 changed: certificate verify failed <juju-quickstart:New> <https://launchpad.net/bugs/1489087>
[17:28] <mup> Bug #1490552 changed: local hostname not in /etc/hosts <juju-core:New> <https://launchpad.net/bugs/1490552>
[17:28] <perrito666> marcoceppi: back, UnitStatusHistory
[17:28] <marcoceppi> thanks perrito666
[17:35] <perrito666> marcoceppi: sorry for the delay
[18:47] <ericsnow> perrito666: could you take a look at http://reviews.vapour.ws/r/2610/?
[18:47] <ericsnow> perrito666: it relates to one of your recent merges
[18:48] <perrito666> ericsnow: did I remove the tests? :|
[18:48] <perrito666> no, that seems like my patch :p did you?
[18:49] <ericsnow> perrito666: I accidentally disabled them in June
[18:49] <perrito666> ericsnow: june? some of the things you are adding are from status-available which is fairly recent
[18:49] <ericsnow> perrito666: your recent patch would not have passed the tests on 1.25 otherwise
[18:49] <perrito666> oh
[18:49] <perrito666> ok
[18:50] <perrito666> ericsnow: can it wait about 1h need to run an errand (bad day for my concentration)
[18:50] <ericsnow> perrito666: right, when you merged from 1.25 you had conflicts and appear to have removed the changes rather than fixing them <wink>
[18:50] <ericsnow> s/from 1.25/to 1.25/
[18:50] <perrito666> ericsnow: In the meantime, is the removal of the huge block from dimitern to begin with?
[18:50] <perrito666> ericsnow: mm damn, ill have to review master too then, thanks for that
[18:51] <perrito666> anyway gtg, bbl
[18:51] <ericsnow> perrito666: don't worry, I'll fix master too
[19:07] <natefinch> you know what bugs the hell out of me?
[19:07] <natefinch> func (c *Settings) <something>
[19:07] <natefinch> c? Really?
[19:15] <perrito666> Ce-tings works in Spanish :p
[19:15] <perrito666> Ericsnow
[19:16] <ericsnow> perrito666: yep
[19:16] <perrito666> So the only thing troubling me is the big chunk from network being removed
[19:16] <ericsnow> perrito666: what is removed?
[19:16] <ericsnow> perrito666: keep in mind that apiserver/params/status.go has everything
[19:20] <perrito666> Ok re reviewed the patch
[19:21] <perrito666> Ericsnow so this patch looks as if re applying the agentversion work for tests can you expand on what happened?
[19:22] <perrito666> And the removed chunk is http://reviews.vapour.ws/r/2610/diff/#4
[19:22] <ericsnow> perrito666: your forward-port from 1.24 was missing several changes due to merge conflicts so I added them back in
[19:23] <perrito666> Ahhh duh I see it now, sad
[19:24] <perrito666> And re http://reviews.vapour.ws/r/2610/diff/#4
[19:26] <xwwt__> jog: I will likely miss the meeting today.  Are you cool with running that?
[19:26] <jog> sure
[19:27] <jog> I'm planning to use this sheet as a discussion point: https://docs.google.com/spreadsheets/d/1CWq1CAIYjJLetnageShXVU0-0etxAE2O0KtRgc3-D_8/edit#gid=0
[19:27] <xwwt__> kk
[19:27] <jog> Example of the various issues we see with the charm tests
[19:28] <jog> The point I want to make is that there are many charm related failures that need investigation. Most of these look like charm issues (not infrastructure)
[19:32] <natefinch> you know your tests aren't isolated enough when you change the signature of a method and find 1 place in production code that calls it, and 30 in test helpers.
[19:36]  * TheMue is grumpy about his current network status. from fri to sat total breakdown and today every few minutes *hmpf*
[20:16] <natefinch> man, I hate that juju deploy can't just take config options on the command line, and that if you pass a file to --config, you have to put the charm name in the file, like mysql:  option:value
[20:19] <perrito666> ericsnow: ?
[20:19] <ericsnow> perrito666: yeah
[20:19] <perrito666> ericsnow: sorry I was chatting on a phone, now back to the computer: "And the removed chunk is http://reviews.vapour.ws/r/2610/diff/#4"
[20:20] <ericsnow> perrito666: all that code is superflous; it was moved over to apiserver/params/status.go in June
[20:21] <ericsnow> perrito666: looks like you accidentally pulled it back in during a merge
[20:21] <perrito666> ericsnow: then lgtm
[20:21] <ericsnow> perrito666: k
[20:27] <ericsnow> natefinch, katco: could I get a quick review of http://reviews.vapour.ws/r/2610/?
[20:28] <katco> ericsnow: will review before EOD, trying to get tests passing before release standup
[20:28] <ericsnow> katco: k
[20:28] <mup> Bug #1491132 changed: TestNetworkInterfaces fails <juju-core:New> <https://launchpad.net/bugs/1491132>
[20:40] <mup> Bug #1491547 changed: [upgrade-juju] Poor user experience <docteam> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1491547>
[20:42] <natefinch> state's export_test is 443 lines long
[20:43] <mup> Bug #1491547 opened: [upgrade-juju] Poor user experience <docteam> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1491547>
[20:59] <mup> Bug #1491547 changed: [upgrade-juju] Poor user experience <docteam> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1491547>
[20:59] <perrito666> mm, that last one seems to be duplicated
[21:02] <mup> Bug #1178312 changed: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <cts-cloud-review> <sts> <ui> <juju-core:Fix Released> <https://launchpad.net/bugs/1178312>
[21:02] <mup> Bug #1325040 changed: juju upgrade-juju is utterly confusing <canonical-is> <ui> <upgrade-juju> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1325040>
[21:02] <mup> Bug #1492241 changed: juju upgrade-juju cli doesn't provide clear feedback on action being taken <canonical-bootstack> <ui> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1492241>
[21:05] <mup> Bug #1178312 opened: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <cts-cloud-review> <sts> <ui> <juju-core:Fix Released> <https://launchpad.net/bugs/1178312>
[21:05] <mup> Bug #1325040 opened: juju upgrade-juju is utterly confusing <canonical-is> <ui> <upgrade-juju> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1325040>
[21:05] <mup> Bug #1492241 opened: juju upgrade-juju cli doesn't provide clear feedback on action being taken <canonical-bootstack> <ui> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1492241>
[21:08] <mup> Bug #1178312 changed: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <cts-cloud-review> <sts> <ui> <juju-core:Fix Released> <https://launchpad.net/bugs/1178312>
[21:08] <mup> Bug #1325040 changed: juju upgrade-juju is utterly confusing <canonical-is> <ui> <upgrade-juju> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1325040>
[21:08] <mup> Bug #1492241 changed: juju upgrade-juju cli doesn't provide clear feedback on action being taken <canonical-bootstack> <ui> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1492241>
[21:32] <xwwt__> sinzui: are you able to join standup?
[22:07] <thumper> wallyworld: holy shit...
[22:07] <thumper> wallyworld: that uniter branch is quite far reaching
[22:07] <wallyworld> it is
[22:08] <wallyworld> doc being worked on now
[22:20] <perrito666> do all worker facades need to be nouns?
[22:20]  * perrito666 thinks we are being a bit exagerated with that
[22:50] <thumper>  wallyworld got time for a quick chat?
[22:51] <wallyworld> sure
[22:54] <wallyworld> thumper: in 1:1