[00:11] <perrito666> its the checker that does reflective stuff, ill try
[00:18] <alexisb> axw, made an update to the TB call, let me know if that time sitll works
[00:26]  * perrito666 loves git squash
[00:34] <redir> squash perito666 +1
[01:00] <perrito666> wallyworld: did you see https://github.com/juju/juju/pull/5341/files#diff-0ceede1328e8e268f09822be9fc4cf5fR70  ?
[01:01] <wallyworld> perrito666: one sec, otp
[01:02] <axw> alexisb: sorry went to take charlotte to school. that time is fine for me
[01:06] <redir> see you tomorrow juju-dev
[01:18] <perrito666> wallyworld: ping me when you are !otp
[01:19] <wallyworld> perrito666: yo
[01:20] <perrito666> wallyworld: yo?
[01:21] <wallyworld> perrito666: a colloquial term for "hello" or "i'm here"
[01:21] <perrito666> ah, also means I in spanish
[01:21] <perrito666> wallyworld:  the link I passed, did you see that before asking for ernonnilless? (or you meanth something else?)
[01:22] <wallyworld> didn't see the link
[01:23] <wallyworld> perrito666: which link?
[01:23] <perrito666> https://github.com/juju/juju/pull/5341/files#diff-0ceede1328e8e268f09822be9fc4cf5fR70
[01:24] <wallyworld> perrito666: oh, didn't see that
[01:24]  * perrito666 clicks fixed
[01:24] <wallyworld> we want jc.ErrorIsNil though right?
[01:24] <perrito666> we do, actually
[01:24] <perrito666> I wonder I used isnil
[01:25] <wallyworld> errorisnil covers some corner cases
[01:25] <perrito666> let me try with errorisnil
[01:26] <perrito666> wallyworld: the code got dizzy with everything we tried and I forgot to errorisnil that
[01:26] <wallyworld> np
[01:26] <perrito666> ... value *params.Error = <nil>
[01:26] <perrito666> ... value of (*params.Error) is nil, but a typed nil
[01:26] <perrito666> meh
[01:26] <perrito666> that is a fine example of a useless error message
[01:28] <perrito666> ah its the apiserver
[01:29] <perrito666> its a params.Error
[01:36] <perrito666> well fine people, I need sleep
[01:36] <perrito666> see you all tomorrow
[02:13] <thumper> fuck
[02:13] <thumper> fuckity fuck
[02:13]  * thumper composes email...
[02:20] <thumper> wallyworld, menn0: see email for WTF moment
[02:20] <menn0> looking
[02:20] <wallyworld> ok
[02:23] <wallyworld> thumper: +1 from me on fixing
[02:23] <thumper> wallyworld: I may quickly whip up a branch that cleans this up
[02:24] <thumper> the idea of a unique index on something that can be empty is werid
[02:24] <thumper> wierd
[02:24] <thumper> weird
[02:24] <thumper> ?
[02:24] <thumper> one of those
[02:25] <menn0> thumper: isn't the issue though that the providerid isn't necessarily known in this case?
[02:25] <thumper> does sparse mean ignore empty?
[02:25] <menn0> thumper: nil values aren't stored in sparse indexes
[02:25] <thumper> ok
[02:25] <menn0> thumper: the index doesn't include documents where the indexed value is nil
[02:27] <menn0> thumper, wallyworld: I don't know what the behaviour is when you have a compound sparse index
[02:28] <menn0> docs are here: https://docs.mongodb.org/manual/core/index-sparse/#sparse-compound-indexes
[02:28] <menn0> but I don't know what they mean by "ascending/descending index keys"
[02:29] <thumper> Sparse compound indexes that only contain ascending/descending index keys will index a document as long as the document contains at least one of the keys.
[02:29] <natefinch> axw: that bug you linked to in the mail about os.Exit in a test.... that test should just return unless you somehow have JUJU_WANT_HELPER_PROCESS set in the environment
[02:29] <thumper> yeah
[02:29] <axw> natefinch: it does not.
[02:29] <axw> natefinch: it calls Main, and Main is calling os.Exit
[02:29] <axw> natefinch: Main should return rc, and main should call os.Exit
[02:29] <axw> which is what I'm changing it to do now
[02:30] <natefinch> axw: I explicitly changed main *not* to os.exit
[02:30] <natefinch> axw: maybe that change got overridden somehow
[02:30] <natefinch> er Main that is
[02:31] <axw> natefinch: blame says the line is unchanged since 2014 *shrug*
[02:31] <thumper> menn0: perhaps we should be doing the provider unique check in a different way
[02:31] <natefinch> axw: weird, maybe I reverted it by accident..
[02:31] <menn0> thumper: I think we should.... I'm replying to the thread now
[02:31] <thumper> thanks
[02:33] <mup> Bug #1578456 opened: cmd/juju/commands: not all tests are being run <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1578456>
[02:34] <natefinch> axw: you're right, I don't see it. That's so weird.
[02:35] <natefinch> axw: oh crap, here it is: https://github.com/juju/juju/pull/5250
[02:35] <axw> natefinch: heh :)
[02:36] <natefinch> axw: mind if I land mine? it has some better testing in it, too
[02:36] <axw> natefinch: fine with me, but I think you'll have some ssh/scp tests to fix too
[02:36] <axw> natefinch: I've just run with my changes, and there's some test failures
[02:36] <natefinch> axw: blech
[02:37] <axw> natefinch: if you like I can press on, and you can land over the top
[02:37] <axw> should be mostly the same anyway, apart from your other changes
[02:37] <natefinch> axw: fine by me
[02:38] <natefinch> axw: sorry to make you waste time debugging that.
[02:39] <axw> natefinch: no worries, didn't take long to track down. I was mostly concerned about the tests being skipped, but thankfully there's just a couple of small ones broken
[02:40] <axw> ugh, my writing has become atrocious, constantly missing words out
[02:40] <thumper> axw: who needs words
[02:40] <thumper> you know...
[02:40] <thumper> thingy
[02:40]  * axw beams thoughts
[02:41] <thumper> menn0: bugger
[02:41] <thumper> menn0: migration fails...
[02:41] <thumper> for spaces with a provider set
[02:41] <thumper> 	github.com/juju/juju/state/spaces.go:141: ProviderId "provider" not unique
[02:41] <thumper> so I'm not sure it is actually working...
[02:42] <menn0> thumper: nuts
[02:42]  * thumper pokes and adds a bucket of logging
[02:44] <thumper> ha
[02:44] <thumper> it isn't the import
[02:44] <thumper> but the factory creation
[02:44] <thumper> WTF
[02:48] <thumper> menn0: ok, need help
[02:48] <thumper> got a minute?
[02:48] <thumper> I *think* what I'm doing should work
[02:48] <thumper> but it isn't
[02:49] <menn0> thumper: 1:1?
[02:49] <thumper> ack
[03:04] <axw> spontaneous shutdown is one way to get me to update my kernel
[03:06] <natefinch> lol
[03:09] <natefinch> what is supposed to happen if you juju deploy trusty/ubuntu --series xenial? :/
[03:13] <thumper> menn0: where is the manifold for the apiserver
[03:13] <thumper> ?
[03:13] <natefinch> why do we even have a --series on deploy?  isn't that what the foo/bar format is for?
[03:14] <menn0> thumper: that's one fo the things that jesse was working on but I don't think it's done yet
[03:14] <thumper> oh fark...
[03:15] <menn0> thumper: I believe he got it mostly working but there were issues, or he had to wait for some other stuff to land or something
[03:15]  * thumper nods
[03:15] <thumper> we probably want that landed very soon
[03:15] <thumper> definitely pre 2.0
[03:16]  * menn0 checks jesse's repo
[03:17] <menn0> thumper: here it is: https://github.com/waigani/juju/tree/MADE-apiserver
[03:18] <axw> natefinch: --series is for multi-series charms. we're moving away from "ubuntu/trusty", to plain old "ubuntu"
[03:18] <axw> natefinch: and IIRC you should be able to force charms to series of the same OS by using --series, wallyworld will remember better tho
[03:18] <menn0> thumper: I can take a look at that once this SSH stuff is done
[03:19] <thumper> menn0: ok, that's be good
[03:19] <wallyworld> axw: --series and --force if needed
[03:19] <natefinch> axw: it just means we have two different ways of specifying the same thing... which is confusing and in this case, causing a bug
[03:19] <menn0> thumper: it's migrations related anyway
[03:19] <wallyworld> eg if a charn declares it supports trusty and we want to install on xenial
[03:19] <thumper> menn0: it is
[03:19] <natefinch> juju deploy precise/ubuntu will deploy ubuntu on xenial
[03:20] <axw> menn0: how many changes to you have in cmd/juju/commands/scp.go? I'm looking at moving off JujuConnSuite, and using a mock API
[03:20] <axw> menn0: don't want to make your life difficult tho
[03:20] <wallyworld> the expectation is those series specific urls are not going to be necessary, but in the interim, that charm should go to precise
[03:21] <menn0> axw: i've made extensive changes to the tests so it would be good if you waited
[03:21] <axw> menn0: okey dokey
[03:21] <menn0> axw: I'm hoping to be done with it today
[03:21] <natefinch> I can fix that, of course, but then we still have the case of juju deploy precise/ubuntu --series xenial.... I guess at that point I just have to error out, since I don't actually know what the user wants
[03:21] <axw> menn0: can you please test them in isolation, because I found TestSCPCommand fails atm if you run it with others
[03:21] <axw> menn0: actually I can fix that later if need be
[03:21] <axw> never mind
[03:21] <wallyworld> natefinch: no, in that case you require --force
[03:22] <wallyworld> and yeah, error if --force is not provided
[03:22] <natefinch> wallyworld: well, asking the charmstore for precise/ubuntu returns you the multi-series ubuntu charm
[03:22] <wallyworld> it does yes
[03:22] <natefinch> wallyworld: which can deploy to xenial just fine
[03:23] <wallyworld> those series/charm urls are for backwards compatibility
[03:23] <natefinch> ...so right now, it does
[03:23] <wallyworld> natefinch: but the user has specified precise in the url - it they want --series xenial we need --force
[03:23] <menn0> axw: by "in isolation" do you mean just run the individual suites?
[03:24] <wallyworld> if they specify the charm without series in url, that's different
[03:24] <axw> menn0: actually I had arse about, so forget I said anything :)   I'm finding that the scp tests fail because the output includes identity files from the fake juju home, and that's not expected in the output. running TestSCPCommand passes if I run it by itself
[03:24] <axw> menn0: so it seems to not be getting a clean fake home
[03:25] <menn0> axw: hmmm... I haven't noticed that
[03:25] <axw> menn0: I'll fix that and forget about changing scp for now
[03:25] <axw> menn0: well, cmd/juju/commands doesn't run all the tests atm. have you changed that in your branch?
[03:25] <axw> menn0: i.e. because of the bug I sent to the list
[03:25] <menn0> axw: no I haven't changed that, just the ssh, scp and debug-hooks tests and implementations
[03:26] <axw> ok
[03:26] <menn0> axw: yeah I saw that
[03:26] <menn0> axw: but i've been running the individual tests/suites using -gocheck.f
[03:26] <menn0> axw: did you fix that problem already?
[03:26] <axw> menn0: nope, still looking into it
[03:27] <axw> menn0: I'll fix that and come back to removing JujuConnSuite after you land your changes
[03:27] <menn0> axw: ok thanks
[03:36] <menn0> axw: one wrinkle, I can't land this stuff until master is unblocked
[03:36] <axw> menn0: it's cool, no hurry
[05:14] <menn0> axw: if someone is use juju scp/ssh to an arbitrary hostname or address, do you think the users personal known_hosts should be used, or just /dev/null ?
[05:14] <menn0> axw: e.g. "juju ssh 10.1.2.3", as opposed to "juju ssh 3"
[09:04] <anastasiamac> fwereade: o/
[09:05] <anastasiamac> fwereade: lts PR was backport to 1.25... should we forward sugestions to master once the PR is ready?
[09:16] <fwereade> dimitern, http://reviews.vapour.ws/r/4772/diff/1/?file=346652#file346652line93
[09:17] <fwereade> anastasiamac, ooh, yes please, that would be great
[09:17] <fwereade> anastasiamac, sorry I missed that
[09:18] <anastasiamac> fwereade: thank you. I'll add it to the comment so that Reed keeps track of it :D
[10:55] <axw> fwereade: would you kindly take a look at http://reviews.vapour.ws/r/4776/? fixes one of the critical blockers
[10:59] <fwereade> axw, ack
[11:00] <fwereade> axw, LGTM
[11:00] <axw> fwereade: cheers
[12:58] <fwereade> dimitern, http://reviews.vapour.ws/r/4734/ looks good but undertested
[12:59]  * fwereade bbiab
[14:11] <mup> Bug #1577798 opened: Juju gives unhelpful error when azure out of resource groups <azure-provider> <blocker> <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1577798>
[14:33] <tych0> http://paste.ubuntu.com/16239197/
[14:33] <tych0> any reason it's looking for lxdbr0 on make install?
[14:47] <rick_h_> aisrael: ping
[14:47] <aisrael> rick_h_: pong
[14:48] <rick_h_> aisrael: got a sec for hangout please?
[14:48] <aisrael> rick_h_: absolutely
[14:51] <mgz> tych0: see pr #5300 - sinzui make the makefile work on a fresh install. yeah, you get kipple in your case, but the install still works, no?
[14:59] <tych0> mgz: it does, it's just weird
[15:03] <mgz> tych0: suggestions on making it less weird welcome
[15:03] <tych0> mgz: yep :)
[15:05] <mgz> tych0: l104 of Makefile - using ifconfig lxdbr0 to find out if the networking is setup, is the cause of the stderr output
[15:06] <mgz> I guess just a 2>&1 would do but maybe there's something smarter
[15:07] <tych0> oh, right
[15:07] <tych0> because make executes the if statements when parsing the file
[15:08] <tych0> mgz: yeah, that seems reasonable to me, do you want to send a patch or should I?
[15:08] <mgz> tych0: go for it
[15:09] <tych0> mgz: ok, will do, thanks
[15:10] <tych0> mgz: https://github.com/juju/juju/pull/5349
[15:13] <mgz> tych0: lgtm
[15:13] <mgz> tested the change locally as well
[15:13] <tych0> mgz: cool, thanks
[15:17] <tych0> mgz: does your LGTM mean that i can $$merge$$? id on't know much about the process here still
[15:18] <mgz> tych0: yes, you can
[15:18] <mgz> and yeah, it's not super clear :) (I didn stamp on the review site)
[15:18] <mgz> hm, though, might be blocking bugs at present
[15:18] <mgz> lets see
[15:19] <mgz> tych0: yeah, like a million
[15:20] <tych0> mgz: ha, ok :0
[15:20] <tych0> :)
[15:59] <mup> Bug #1578337 changed: no command to remove controllers <juju-core:Invalid> <https://launchpad.net/bugs/1578337>
[16:02] <mup> Bug #1578337 opened: no command to remove controllers <juju-core:Invalid> <https://launchpad.net/bugs/1578337>
[16:05] <dimitern> fwereade: thanks for the review on http://reviews.vapour.ws/r/4734/ btw!
[16:06] <dimitern> fwereade: if you're still about, I'm pushing some updates, including the missing tests and will also tackle your suggestions
[16:09] <fwereade> dimitern, cool, thanks
[16:09] <dimitern> fwereade: I'll ping you in the next 30m or so for a final look, while I finish a few more live tests
[16:11] <mup> Bug #1578337 changed: no command to remove controllers <juju-core:Invalid> <https://launchpad.net/bugs/1578337>
[16:16] <natefinch> fwereade: do you have thoughts on what should happen if someone does juju deploy precise/ubuntu --series xenial?  Should it depend on whether or not ubuntu is a multiseries charm or not?  If it's not a multiseries charm, it's pretty clear that this should fail without --force, but if it is a multiseries charm, precise/ubuntu really is the same charm as xenial/ubuntu, so should we let it deploy to xenial without --force, or enforce regularity in
[16:16] <natefinch> the CLI even though --force is not technically needed?
[16:17] <natefinch> also welcome anyone else's thoughts on this.  I'm not really sure I know what the right answer is.  I feel like, either way, we're going to annoy someone
[16:18] <natefinch> I guess, if we're going to annoy people either way, we might as well make it consistent, and require --force.
[16:19]  * natefinch rubber ducks with the channel as a whole.
[16:19] <fwereade> natefinch, ha -- it feels to me like the user is explicitly specifying a charm, and explicitly specifying a series; and expecting us to resolve the charm, discover that it's multiseries and xenial is supported, and do what they told us to
[16:19] <fwereade> natefinch, if it's not multiseries, --force for sure, but I don't think we should need it if they're doing something sane in an unorthodox fashion
[16:20] <natefinch> fwereade: I just have a feeling that it would feel weird that juju deploy precise/ubuntu --series xenial would work, but juju deploy precise/mysql --series xenial would not
[16:21] <fwereade> natefinch, I think of "precise/ubuntu" as a charm selector
[16:22] <natefinch> fwereade: to the user, it's different behavior based on invisible information
[16:22] <fwereade> natefinch, that's always been the underlying intent: what the user types is input to a specific component that resolves an *actual* charm, and we then proceed purely on the basis of the charm we found: it feels odd to me to attach additional weight to the selector, just to make something fail
[16:24] <fwereade> natefinch, deploying "precise/ubuntu" to machines with two different series is, I think, a clear way of specifying that you want the exact charm in both places
[16:24] <fwereade> natefinch, it's not an unreasonable request
[16:24] <fwereade> natefinch, it will succeed or fail based on the charm in either case
[16:24] <natefinch> fwereade: right, but, to an end user, sometimes it'll magically work, and sometimes it'll magically require --force
[16:25] <natefinch> fwereade: I guess that's ok, since working indicates that it's supposed to be ok there, and not working indicates it may well explode
[16:26] <fwereade> natefinch, I think so, yeah
[16:26] <fwereade> natefinch, and if they *really* want to try it they can always --force
[16:26] <natefinch> fwereade: I think that makes sense... it does give the user extra information that "hey this might break" whereas with a multjseries charm we can say "hey, this should work"
[16:27] <fwereade> natefinch, exactly, yeah
[16:28] <natefinch> fwereade: cool. thanks for helping me talk it out :)
[16:28] <fwereade> natefinch, always a pleasure :)
[17:23] <niedbalski> alexisb, ping
[17:25] <alexisb> niedbalski, ping
[17:25] <niedbalski> ericsnow, https://bugs.launchpad.net/juju-core/+bug/1514874 I am seeing this now with 1.25.5, juju is uninstalling after rebooting the units/state.
[17:25] <mup> Bug #1514874: Invalid entity name or password error, causes Juju to uninstall <juju-core:Triaged> <https://launchpad.net/bugs/1514874>
[17:29] <niedbalski> ericsnow, I think that even if 'returned during API open: invalid entity name or password' is a valid cause, throwing a ErrTerminateAgent exception is an over-reaction, instead of putting the connect-try in a loop and log a warn/fatal error.
[17:30] <ericsnow> niedbalski: OTP
[17:32] <perrito666> niedbalski: I thought we had taken care of that
[17:47] <niedbalski> perrito666, I thought the same, but that's probably only on 2.0
[17:48] <perrito666> niedbalski: I am pretty sure we fixed that around 1.21
[17:48] <perrito666> the last time that bit someone was in 1.18, for reference se PS4
[17:48] <ericsnow> niedbalski: taking a look
[17:49] <niedbalski> perrito666, which specific bug?
[17:49]  * perrito666 clicks what niedbalskilinked to see what exactly are we talking about
[17:53] <natefinch> fwereade: still around?
[17:53] <niedbalski> perrito666, well, with 1.25.5 it's quite easy to reproduce; edit the agent.conf of the unit, change the apipassword, and restart. Now it seems that some other condition can be causing this same behavior.
[17:54] <redir> alexisb: what command you working on flattening currently? block?
[17:54] <perrito666> niedbalski: that smells strongly like a regression
[17:54] <alexisb> redir, yep
[17:54] <alexisb> the others are all yours
[17:54] <alexisb> and i am happy to meet and discuss if you like
[17:54] <perrito666> I should know, I have broken agent.conf in very creative ways with restore and juju never uninstalled
[17:54] <alexisb> katco, ping
[17:54] <katco> alexisb: pong
[17:54] <niedbalski> perrito666, I just did it, wiped.
[17:55] <katco> alexisb: sorry was eating lunch earlier. responded to you email
[17:55]  * perrito666 scratches chin
[17:55] <perrito666> niedbalski: is this behavior also present in 2.0?
[17:55] <alexisb> katco, np, I see the response now thank you
[17:55] <alexisb> katco, we are going to want to jump on that bug right away
[17:55] <katco> alexisb: ah, that was 13:00 today?
[17:55] <redir> alexisb: I'm looking through https://github.com/juju/juju/pull/5240/files to see how you tackled it.
[17:56] <niedbalski> perrito666, I can check.
[17:56] <perrito666> niedbalski: if you say yes I am very much about to ring a hughe alarm
[17:56] <katco> alexisb: kk
[17:57] <alexisb> redir, once I am done with my upcoming call we should probably chat, I probably can save you some time
[17:57] <fwereade> natefinch, briefly
[17:58] <natefinch> fwereade: along the same lines as before juju deploy precise/ubuntu currently deploys to xenial, since the selected charm says xenial is best
[17:58] <natefinch> fwereade: bug or feature?
[17:58] <fwereade> anyone who's around, I don't quite have time to look at dimitern's branch but the only thing blocking an LGTM was a lack of unit testing -- I am happy with the code
[17:58] <fwereade> natefinch, ha
[17:59] <fwereade> natefinch, that *does* rather seem to break the law of least surprise, doesn't it :-/
[17:59] <natefinch> fwereade: I actually kind of wish precise/ubuntu wouldn't resolve anymore if ubuntu is a multiseries charm
[17:59] <fwereade> yeah
[17:59] <dimitern> fwereade: thanks! I'm doing a final live test after adding concrete errors as discussed (it was surprisingly hard to do outside of the errors package and still get the same effect)
[18:00] <fwereade> natefinch, the most DWIMmy thing I can think of is to use features of the selector as tie-breakers when the user hasn't otherwise specified
[18:01] <natefinch> fwereade: that seems fair
[18:01] <fwereade> natefinch, cool
[18:01] <natefinch> fwereade: cool, thanks
[18:02] <fwereade> dimitern, hard to do as single error values?
[18:02] <natefinch> core team meeting anyone?
[18:02] <fwereade> natefinch, ...dammit, I can't really :( need to get supper
[18:02] <dimitern> fwereade: well, that would've been a lot simpler, but I wanted to preserve the error stack and the usual way of tracing/annotating
[18:03] <natefinch> fwereade: totally understood :)
[18:03] <fwereade> dimitern, fair enough, but I think once you've understood the situation well enough to pick a specific error the rest of the context is less interesting and can probably be dropped
[18:03] <fwereade> regardless :)
[18:04]  * fwereade gtg
[18:08] <perrito666> so anybody coming to the team meeting?
[18:13] <redir> alexisb: OK.
[18:13] <redir> on the team meeting
[18:18] <dimitern> alexisb, fwereade, also OCRs, etc: http://reviews.vapour.ws/r/4734/ is ready and tested well enough to get approval and land I think, which will fix bug 1321442
[18:18] <mup> Bug #1321442: Juju does not support EC2 with no default VPC <ec2-provider> <network> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1321442>
[18:29] <natefinch> redir: btw - http://juju.fail/ will give you the state blocked release branches
[18:34] <alexisb> redir, I am available when you are
[18:36] <mup> Bug #1501398 changed: Test suite failures with WSARecv timeout <blocker> <centos> <ci> <go1.6> <ppc64el> <test-failure> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1501398>
[18:36] <mup> Bug #1570883 changed: imageSuite.TestEnsureImageExistsCallbackIncludesSourceURL fails on centos go 1.6 <blocker> <centos> <ci> <go1.6> <jujuqc> <lxd> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1570883>
[18:36] <mup> Bug #1578254 changed: Race in apiserver/common and apiserver/proxyupdater <blocker> <ci> <race-condition> <regression> <juju-core:Fix Released by hduran-8> <https://launchpad.net/bugs/1578254>
[18:41] <mgz> natefinch, starving his family
[18:55] <alexisb> redir, I am going to step out for a bit for lunch, I will ping you when I am back
[18:55] <redir> alexisb: me too and I'll be back.
[18:57] <mgz> sinzui: should bug 1571914 and so on actually be blockers?
[18:57] <mup> Bug #1571914: github.com/juju/juju/cmd/jujud unit tests fail if xenial is the LTS <juju-core:In Progress by reedobrien> <juju-core 1.25:In Progress by reedobrien> <https://launchpad.net/bugs/1571914>
[18:57] <mgz> we hacked around the failures, but holding up the branch from landing seems perverse
[18:58] <sinzui> mgz: I will make a exception for the LTS fixes. We are running our of time to land those before my hack fails
[18:59] <mgz> sinzui: is it really an exception?
[18:59] <mgz> without the hack, it would be failing tests, which would block
[18:59] <mgz> so, I think redir should land, and we should remove the hack
[19:00] <sinzui> mgz: yes, that is what I mean.
[19:00] <mgz> $$fixes-1571914$$
[19:02] <niedbalski> ericsnow, any idea?
[19:03] <ericsnow> niedbalski: just about to add a lengthy comment to the bug
[19:03] <niedbalski> ericsnow, thanks.
[19:10] <ericsnow> niedbalski: done; hope that helps
[19:21] <redir> mgz that didn't work against master
[19:21] <mgz> redir: let me double check
[19:22] <mgz> redir: I see, only marked as 'high' against master, fixing now
[19:22] <mgz> redir: go again
[19:33] <fwereade> alexisb, http://reviews.vapour.ws/r/4734/ LGTM, none of my issues should block landing
[19:33]  * fwereade disappears again
[20:15] <katco> ericsnow: natefinch: we need to chat rq
[20:15] <natefinch> katco: kk
[20:15] <katco> natefinch: moonstone
[20:33] <alexisb> fwereade, awesome thank you
[20:33] <alexisb> redir, I am back and ready when you are
[20:38] <redir> k
[20:38] <redir> alexisb: gimme 5
[21:11] <redir> sinzui: the s390x /tmp issue is all sorted yes?
[21:11] <sinzui> redir: yes it is
[21:11] <redir> tx
[21:13] <redir> alexisb: there's no cards in leankit for these command updates are there?
[21:14] <redir> alexisb: what about launchpad?
[21:14] <alexisb> redir, no
[21:14] <alexisb> and no
[21:14] <redir> k
[21:14] <alexisb> redir, probably worth adding a card to tanzinite board for this
[21:14] <redir> gx
[21:14] <redir> tx
[21:14] <redir> OK will do alexisb
[21:21] <perrito666> mgz: can you pass me that link for maas images again?
[21:24] <mgz> perrito666: wiki.cloudbase.it/maas
[21:25] <perrito666> tx
[21:35]  * perrito666 kicks his maas until it works
[21:45] <katco> bogdanteleaga: ping?
[21:51] <mup> Bug #1578834 opened: update-alternatives fails to switch between juju-1 and juju-2 <juju-core:New> <https://launchpad.net/bugs/1578834>
[21:54] <perrito666> curiosity, cannot run qemu and vbox at the same time
[21:56] <perrito666> wallyworld: is 1:1 going to happen?
[21:56] <wallyworld> perrito666: yeah, finishing a qa meeting, and also just need to ensure another clash won't happen, will ping in a sec
[21:57] <perrito666> k
[22:52] <axw> menn0: sorry for piking last night, I hope my notes were at least helpful. did you talk about remote lxd / untrusted users vs. profiles at all?
[22:52] <menn0> axw: np. your notes were very helpful.
[22:53] <menn0> axw: we didn't talk about the lxd profiles item much, but the one pager for it is on my plate now.
[22:53] <menn0> axw: can we perhaps talk about it on monday?
[22:53] <axw> menn0: yep, no worries
[22:53] <menn0> axw: i'm a bit pushed for time today
[22:54] <axw> menn0: np, just wondering if it came up that's all. we can talk later
[22:54] <axw> (it only occurred to me while I was writing notes :))
[22:54] <menn0> axw: to be honest, before I saw your notes about it I thought it was only about the lxd provider. I wasn't think about remote lxd containers.
[22:55] <menn0> axw: one thing which was mentioned last night is the Will was pretty sure placement directives were the right way to go.
[22:55] <axw> menn0: it may be, but I meant lxd provider targeting a remote host, not lxd containers
[22:55] <axw> menn0: yeah that's my feeling too
[22:55] <menn0> axw: I haven't put enough thought into it yet
[22:56] <redir> mgz: sinzui: FWIW, both the 1.25 and master fixes for the LTS hack have merged. In case you missed 'em.
[22:56] <mgz> redir: ta
[22:56] <axw> menn0: you can't *yet
[22:56] <axw> *
[22:56] <sinzui> redir: thank you