[00:00] <LiftedKilt> marcoceppi: no I haven't had that problem with it yet
[00:03] <marcoceppi> LiftedKilt: :| I've it hit it twice, want to check if there's a bug
[00:08] <mup> Bug #1564662 opened: Juju binaries should be stripped <juju-core:Triaged> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1564662>
[00:11] <cherylj> marcoceppi, LiftedKilt what provider?
[00:11] <marcoceppi> cherylj: me, aws
[00:12] <cherylj> marcoceppi: ah, I bet your deploys were to hosted environments
[00:12] <cherylj> and I bet that we only clean up the admin model
[00:12] <cherylj> (d'oh, I said environments)
[00:13] <cherylj> I've been switching between 1.25 and 2.0 too much today
[00:13] <cherylj> marcoceppi: when you used kill-controller, was your controller machine alive?
[00:13] <cherylj> marcoceppi: also, there's the rate-limiting bug
[00:14] <cherylj> bug 1537620
[00:14] <mup> Bug #1537620: ec2: destroy-controller blow the rate limit trying to delete security group - can leave instances around <2.0-count> <ci> <jujuqa> <juju-core:Triaged> <https://launchpad.net/bugs/1537620>
[00:23] <mup> Bug #1564662 changed: Juju binaries should be stripped <juju-core:Triaged> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1564662>
[00:32] <mup> Bug #1564662 opened: Juju binaries should be stripped <juju-core:Triaged> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1564662>
[00:32] <mup> Bug #1564677 opened: Create one binary for juju and all plugins <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1564677>
[00:33] <katco> evening all
[00:34] <mgz> katacoh~~~
[00:35] <mup> Bug #1564677 changed: Create one binary for juju and all plugins <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1564677>
[00:36] <katco> mgz: lol is that some weird way of spelling my name?
[00:38] <mup> Bug #1564677 opened: Create one binary for juju and all plugins <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1564677>
[00:38] <mgz> katco: it was just the musical version...
[00:38] <katco> mgz: or perhaps the japanese literal pronunciation
[00:44] <mgz> katco: hm, I'd guess that would be キャットコ
[01:02] <bogdanteleaga> mgz, そうです :p
[01:03] <mgz> bogdanteleaga: :)
[01:31] <cherylj> hey axw, can you take another look?  http://reviews.vapour.ws/r/4389/
[01:32] <axw> cherylj: looking
[01:32] <mup> Bug #1564694 opened: Proxy updater fails with "permission denied" <juju-core:Triaged> <https://launchpad.net/bugs/1564694>
[01:33] <axw> cherylj: LGTM, thanks
[01:33] <cherylj> thanks, axw!
[01:38] <menn0> fucking fuck
[01:38] <menn0> thumper: this new default "default" model thing messes with migrations somewhat
[01:38] <thumper> in what way?
[01:38] <menn0> thumper: it means that you've got to remember to delete the "default" model on the target controller before you migrate
[01:39] <thumper> or just always create one called "to-migrate"
[01:39] <thumper> :)
[01:39] <menn0> thumper: sure, but it's dumb that we're setting up people to fail
[01:40] <thumper> well...
[01:40] <thumper> we aren't going to be migrating the default model very often
[01:40]  * thumper thinks
[01:40] <thumper> ...
[01:40] <thumper> maybe
[01:56] <mup> Bug #1564700 opened: juju 1.25 -- go 1.6 -- provider/joyent tests explode due to incorrect use of AddCleanup <juju-core:New> <https://launchpad.net/bugs/1564700>
[02:12] <davecheney> menn0: https://github.com/juju/juju/pull/4957
[02:17] <menn0> davecheney: will take a look in just a sec
[02:18] <rick_h_> menn0: can we juat warnfpr conflicting models?
[02:18] <rick_h_> menn0: seems we should do that anyway?
[02:19] <rick_h_> warn on conflicting models
[02:20] <menn0> rick_h_: warn and do what? rename the model and migrate it anyway, or abort?
[02:23] <menn0> thumper, rick_h_: FYI agent API connection cut over to the target controller during migration is sooo close
[02:23] <thumper> \o/
[02:24] <menn0> thumper, rick_h_: it's failing now because I didn't update the CA cert in the agent conf
[02:24] <menn0> thumper, rick_h_: and of course, there's currently no way to do that... so I'm going to have to add that
[02:24] <thumper> :)
[02:25] <menn0> thumper, rick_h_: I've found a bunch of other stuff that isn't quite right along the way but I'm ignoring them for now
[02:29] <menn0> thumper: I put this up yesterday but it hasn't had a review. could you take a look please? http://reviews.vapour.ws/r/4370/
[02:29] <thumper> sure
[02:32] <menn0> davecheney: as I said on the review, holy crap, ship it!
[02:32] <menn0> how did that get in?
[02:36] <thumper> menn0: I'll look at the branch after my coffee break
[02:36] <thumper> menn0: just submitted my gomaasapi merge for AllocateMachine
[02:36] <thumper> phew
[02:37] <menn0> thumper: painful?
[02:37] <menn0> thumper: no rush on that PR actually
[02:37] <thumper> a bit time consuming
[02:37] <thumper> had to refactor a few test classes
[02:37] <thumper> also added explicit error types into gomaasapi
[02:37] <menn0> thumper: actually hold off with the review completely until I get the CA cert stuff done
[02:37] <thumper> so we don't leak net/http errors
[02:37] <thumper> menn0: ack
[02:37] <thumper> added other utility helpers etc
[02:37] <thumper> next one will be much faster
[02:38] <menn0> ok cool
[02:38]  * thumper -> coffee
[02:38] <davecheney> throw your hands in the air for the joyent mock server that isn't safe for concurrent access!
[02:43] <menn0> davecheney: \?/
[02:44] <menn0> thumper: you *can* review this one: http://reviews.vapour.ws/r/4397/
[02:44] <rick_h_> menno sorry at the airport. yea warn and abort
[02:51] <menn0> rick_h_: that's basically what will happen, although currently perhaps not as early as it could
[02:54] <davecheney> thumper: I need to fork the joyent/gomanta package
[02:54] <davecheney> I cannot fix it from outside because of the way it's written
[02:54] <davecheney> I thought I could dot he same hack we did with the maas mocks
[02:54] <davecheney> but that won't work
[03:05] <thumper> bugger
[03:05] <thumper> davecheney: can we just submit the fix to them?
[03:05] <thumper> we can apply pressure to get it merged
[03:05] <thumper> especially if it is just wrong
[03:06] <davecheney> how fast do you want it fixed ?
[03:06] <davecheney> i'll make a gentlemans bet that they have abandoned that code
[03:06] <davecheney> why don't we cut over to our fork and then we can discuss upstreaming at a later date
[03:09] <menn0> thumper: pls review this one now: http://reviews.vapour.ws/r/4370/
[03:10]  * menn0 tries out a migration again
[03:18] <thumper> axw: we don't use environ Storage() any more do we?
[03:18] <axw> thumper: I think MAAS might be the only provider that needs it now, but it should be internal to the provider
[03:18] <thumper> what does maas use it for?
[03:18] <axw> thumper: perrito666 was working on excising the last bits, I'm not sure if it's finished
[03:19] <axw> thumper: for recording which machines host controllers
[03:19] <thumper> ugh
[03:19] <thumper> should so just do that with tags
[03:19] <axw> thumper: tags don't work like that in MAAS
[03:19] <axw> we do use tags in other providers
[03:19] <thumper> hmm...
[03:20] <axw> thumper: why does it matter?
[03:20] <thumper> because we want to make another provider type under the covers for maas 2.0
[03:22] <axw> thumper: I'm all for dropping maas/storage.go if we can, but I'm not sure what else we can use to record controllers in the environment
[03:22] <thumper> I'll think on it while dealing with maas 2 stuff
[03:23] <axw> we can probably delete half of what's in there anyway
[03:28] <menn0> thumper: migration with api cutover worked!
[03:28] <thumper> fuck yeah!!!
[03:28] <menn0> thumper: I had to do some dodgy shit to make it happen though
[03:29] <menn0> thumper: the main problem is that the watchers coalesce events so it's easy for the minion to miss phases
[03:30] <thumper> yeah...
[03:30] <thumper> that is bad
[03:30] <menn0> thumper: more synchronisation is needed to fix that properly... it's something that had to happen anyway
[03:31] <menn0> thumper: also, the migration master is quite fragile if it gets interrupted
[03:31] <menn0> thumper: I know what to do there, but it requires API changes
[03:31] <menn0> axw: tyvm for fixing the concurrent bootstrap issue btw
[03:31] <menn0> axw: that's made my life a lot easier
[03:32] <axw> menn0: cool, no worries
[04:35] <thumper> ok, I'm outa here
[05:36] <mup> Bug #1258027 changed: cloudinit: disable apt-get update/upgrade  <ubuntu-engineering> <juju-core:Fix Released> <https://launchpad.net/bugs/1258027>
[07:35] <rogpeppe1> axw: hiya
[07:35] <axw> rogpeppe1: howdy
[07:36] <rogpeppe1> axw: i wonder if you could enlighten me as to exactly what a controller uuid is...
[07:36] <rogpeppe1> axw: can it be used just like any other model uuid?
[07:36] <axw> rogpeppe1: it's just the UUID of the admin model
[07:36] <axw> a special model
[07:36] <rogpeppe1> axw: ah, ok
[07:36] <rogpeppe1> axw: does it have a special set of API facades?
[07:37] <axw> rogpeppe1: you can use the Controller facade if you're not connected to a specific model
[07:37] <axw> I don't know if there are others
[07:37] <rogpeppe1> axw: but the admin model will always exist, presumably?
[07:38] <rogpeppe1> axw: and... is not connecting to a specific model actually supported?
[07:38] <axw> rogpeppe1: I don't know what would happen if you tried to delete it TBH
[07:38] <rogpeppe1> axw: i see that you're currently allowed to connect with no uuid, but it looks like it's legacy code
[07:38] <rogpeppe1> axw: at least, the comments seem to indicate that
[07:39] <axw> rogpeppe1: it works at least :)  probably not recommended
[07:39] <rogpeppe1> axw: ok, that's useful thanks. BTW, can you deploy services in the admin model?
[07:40] <axw> rogpeppe1: yes, for now at least
[07:40] <axw> no plans to change it, though I kinda wish we'd lock off controller machines by default
[07:41] <rogpeppe1> axw: i'm thinking there should be a doc comment somewhere describing all of this
[07:41] <rogpeppe1> axw: but perhaps i've not found it yet
[07:41] <axw> rogpeppe1: yeah, docs on internals are severely lacking
[07:42] <rogpeppe1> axw: to be fair, this isn't really internal
[07:42] <axw> I intend to write some when I'm not furiously coding for 2.0 :)
[07:42] <axw> yeah, true
[07:42] <rogpeppe1> axw: it's detail that users of the API need to know
[07:43] <rogpeppe1> axw: thanks for clearing this up anyway. i've never been quite sure about this stuff.
[07:43] <axw> rogpeppe1: np
[07:43] <rogpeppe1> axw: (and FWIW it seems that no-one else is either :-])
[07:43] <axw> :)
[07:43] <axw> me included... getting there tho
[08:20] <rogpeppe1> axw: one other thing: if i want to grant a user admin-level access, is it sufficient to pass params.ModeWriteAccess to GrantModel?
[08:20] <rogpeppe1> axw: it seems a bit odd to me that GrantModel takes a string not a ModelAccessPermission for that argument
[08:21] <axw> rogpeppe1: I believe so - you may want to double check with cmars, who added that. I'm pretty sure that's what you need to do tho
[08:21] <rogpeppe1> axw: ok, thanks. so "write" implies read permission and admin rights.
[08:22] <rogpeppe1> axw: i guess i could just use a string literal (shock, horror!)
[08:22] <axw> rogpeppe1: sorry, you need to give write access to the user on the admin model
[08:22] <axw> that's my understanding anyway
[08:22] <axw> that makes them an admin
[08:22] <rogpeppe1> axw: ah, i don't want them to get admin access to the controller
[08:22] <axw> rogpeppe1: write on any other model just gives them read/write access to that model, of course
[08:23] <rogpeppe1> axw: just the ability to do anything within the given model
[08:23] <rogpeppe1> axw: i guess i was confused by:
[08:23] <rogpeppe1> 	// ModelAdminAccess allows a user full control over the model.
[08:23] <rogpeppe1> 	ModelAdminAccess ModelAccess = "admin"
[08:24] <axw> rogpeppe1: somewhere along the line write gets translated to admin
[08:24] <rogpeppe1> axw: which i *think* is equivalent to "write" at the top level
[08:24] <axw> not sure why there's two spellings
[08:24] <rogpeppe1> axw: i've seen at least three different representations of that same set of things
[08:25] <axw> rogpeppe1: yeah, I've seen them in params, juju/permissions (which should be core/permissions), and state
[08:25] <axw> we could do without the one in state, that should just use the one in core/permissions
[08:25] <rogpeppe1> axw: i guess
[08:26] <rogpeppe1> axw: the one in juju/permission is an int though
[09:00] <axw> rogpeppe1: FYI, this branch adds the API for getting the list of users that have access to a model: https://github.com/juju/juju/pull/4959
[09:00] <axw> rogpeppe1: (included within results of ModelManager.ModelInfo)
[09:00] <mup> Bug #1564791 opened: 2.0-beta3: LXD provider, jujud architecture mismatch <juju-core:New> <https://launchpad.net/bugs/1564791>
[09:00] <rogpeppe1> axw: cool, looking
[09:01] <axw> rogpeppe1: I'm not in a hurry for a review, logging off now - would appreciate comments if it's missing what you need tho
[09:01] <rogpeppe1> axw: ok, will do it now so i remember :)
[09:01] <axw> :)
[09:01] <dooferlad> fwereade: hangout?
[09:03] <dooferlad> voidspace: standup?
[09:04] <voidspace> dooferlad: omw - sorry
[09:06] <voidspace> dooferlad: babbageclunk: frobware: browser issues
[10:29] <voidspace> babbageclunk: frobware: drop-maas-1.8 landed apparently!
[10:29] <voidspace> which is great news
[10:39] <frobware> voidspace: yep, nice
[10:44] <babbageclunk> voidspace: o/
[11:02] <perrito666> morning all
[12:12] <voidspace> babbageclunk: right, daily report (so far) written up
[12:12] <voidspace> babbageclunk: with obligatory rant written and then thrown away
[12:13] <voidspace> babbageclunk: our merge failed - failing tests https://github.com/juju/juju/pull/4943
[12:13] <voidspace> babbageclunk: we can look at that after lunch, I'm going on lunch now
[12:25] <mup> Bug #1564880 opened: modelmanager.Client.GrantModel should be idempotent <juju-core:New> <https://launchpad.net/bugs/1564880>
[13:27] <dooferlad> voidspace / frobware: Smallest diff of the day if you can +1 it http://reviews.vapour.ws/r/4400/diff/#
[13:38] <babbageclunk> Man, I do not understand "go test" at all
[13:43] <natefinch> perrito666: you went on vacation and decided to build a PPA?  I bet you're happy to get back to work, where it's less stressful and annoying
[13:43] <perrito666> natefinch: well I decided to try the software but for that I wanted it to be packaged
[13:44] <natefinch> perrito666: bah.  packaging go code in a PPA is a waste of time. That's the whole point
[13:47] <perrito666> natefinch: installing things in a server that are not in a package is an accident wairing to happen
[13:48] <perrito666> plus, deb packages not only hold the binary, they also hold a basic conf and permission setting
[13:49] <perrito666> unless you are the kind of person that enjoys writing systemd services and upstart jobs
[13:49] <rogpeppe1> anyone good at git spelunking here? i'd like to find the code review that the changes in 520a90f3cc6f2a2f9fcb967fa78ea625be19042c were reviewed in... anyone know a decent way of doing that?
[13:49] <natefinch> perrito666: that's true... though to be fair, you have to write all that to make the PPA :/
[13:50] <rogpeppe1> i see lots of commits around that time but none with a review comment
[13:50] <perrito666> rogpeppe1: lemme check
[13:51] <rogpeppe1> once upon a time, every commit to juju master had a link to the associated review :-\
[13:51] <rogpeppe1> perrito666: thanks
[13:51] <perrito666> rogpeppe1: that is the issue of merging
[13:51] <rogpeppe1> perrito666: i don't understand why
[13:52] <perrito666> rogpeppe1: well you can have N commits inside a merge, a sane approach would be to flatten them before the merge
[13:52] <rogpeppe1> perrito666: surely every commit in both the master branch and the merged branch should have been reviewed?
[13:52] <natefinch> probably this one: http://reviews.vapour.ws/r/3654/
[13:52] <perrito666> natefinch: nope
[13:53] <natefinch> here ya go http://reviews.vapour.ws/r/3677/
[13:53] <perrito666> hint https://github.com/juju/juju/search?q=520a90f3cc6f2a2f9fcb967fa78ea625be19042c&type=Issues&utf8=%E2%9C%93
[13:54] <natefinch> I didn't do any git magic, just looked for reviews posted by andrew around the time of that commit that sounded likely :)
[13:55] <perrito666> you can actually look for the hash in github and filter by issues, prs are issues
[13:55] <rogpeppe1> perrito666: hmm, i wonder why the commit message doesn't have the reviewboard link, since https://github.com/juju/juju/pull/4237 shows it
[13:56] <perrito666> rogpeppe1: because the rb link is in the Pull Request not on the commit
[13:56] <rogpeppe1> perrito666: hmm, doesn't the bot ensure that the PR description is included in the commit message
[13:56] <rogpeppe1> ?
[13:57] <rogpeppe1> perrito666: lots of them do, so why not this one?
[13:57] <perrito666> rogpeppe1: the merge request commit message is https://github.com/juju/juju/commit/b033024f0dc55e2bc371978828e7301a532fc926
[13:57] <perrito666> but the one you are looking at is https://github.com/juju/juju/commit/520a90f3cc6f2a2f9fcb967fa78ea625be19042c
[13:58] <perrito666> so, you are looking at andrews commit not the bots one
[13:58] <perrito666> git is fun like that
[13:58] <rogpeppe1> perrito666: yes i'm looking at andrew's commit
[13:58] <rogpeppe1> perrito666: (that's the one i'm interested in)
[14:01] <rogpeppe1> perrito666: ha, that commit message is in four places
[14:01] <perrito666> rogpeppe1: yes, this is what happens
[14:01] <rogpeppe1> perrito666: sorry, 3 places
[14:01]  * perrito666 types
[14:01] <rogpeppe1> perrito666: i'd expect 2 places but not 3
[14:02] <perrito666> rogpeppe1: http://i.imgur.com/6krXnLO.png
[14:02] <perrito666> so the message repeats in both the actual commit and the merge
[14:02] <perrito666> the merges the bot does are not proper code merges but tree merges
[14:03] <perrito666> where the commits by the pr are added to the tree and there is a "merge" commit marking said addition
[14:03] <natefinch> rogpeppe1: http://stackoverflow.com/questions/17818167/find-a-pull-request-on-github-where-a-commit-was-originally-created/17819027#17819027
[14:03] <perrito666> I am curious about the 3 places though, might come from more than one people merging that branch into their work and then PRing
[14:03] <perrito666> I believe that our current feature branch approach is not being so good and our not squashing neither
[14:03] <natefinch> rogpeppe1: that worked for me... beware, it adds pull requests to the branches you get from github, wich is a lot
[14:04] <natefinch> rogpeppe1: after doing that and git describe --all --contains <hash>    I get remotes/origin/pull/4282~10
[14:04] <perrito666> the good thing is, after using bzr during a couple of days I re discovered my love for git
[14:04] <rogpeppe1> perrito666: yeah, it's odd. i see both 520a90f3cc6f2a2f9fcb967fa78ea625be19042c and c839dfdf8f226760ebeaa7eb302a2f1972763cc1 neither of which are merges
[14:05] <natefinch> hmm.. which is ian merging master, which is not super useful actually
[14:05] <perrito666> no, I tend to rebase master, makes clearer trees
[14:06] <perrito666> I dont want to be steve jobs-y but, we are using it wrong
[14:06] <rogpeppe1> perrito666, natefinch: i'd like to come up with a script: showreview <commit>, which will automatically find the review link where the given commit was reviewed
[14:06] <rogpeppe1> perrito666, natefinch: do you think that's possible?
[14:07] <rogpeppe1> perrito666, natefinch: because i'm often doing some archeology using git blame, and that points me to a commit but then i want to know more about the context
[14:07] <perrito666> rogpeppe1: yes, graphical tool shows it so it should be
[14:07] <rogpeppe1> perrito666, natefinch: i.e. this was broken then, but was there a good reason for that?
[14:07] <natefinch> I think it must be possible, it's just tricky with all the merging we do, and as perrito666 said, I think we're doing it wrong
[14:08] <perrito666> rogpeppe1: you need to trace back on the commit graph until your commit and whatever next merge is there should be the one
[14:10] <rogpeppe1> perrito666, natefinch: interestingly despite having the same commit message, both those commits are actually quite different
[14:11] <perrito666> rogpeppe1: that might be because of the use of amend
[14:11] <perrito666> on one of them at least
[14:11] <mbruzek> Does anyone know if we are building Juju 2.0 for ppc64le on 14.04 ? I have a partner trying to install and is so far unable
[14:24] <mbruzek> Juju 2.0 on ppc64le and 14.04 ...
[14:24] <natefinch> mbruzek: in theory, I think so?  AFAIK, we support ppc64le and 14.04
[14:25] <mbruzek> natefinch: can you show me the binaries that the ppa supports?
[14:25] <mbruzek> I can't seem to find it...
[14:25] <natefinch> mbruzek: uh... I have no idea, I'm sorry.
[14:26] <perrito666> mbruzek: https://launchpad.net/ubuntu/wily/ppc64el/juju-core
[14:26] <mbruzek> natefinch: OK I don't either.
[14:26] <natefinch> mbruzek: I try to stay away from launchpad and PPAs as much as possible
[14:27] <mbruzek> natefinch: Munging your URL I found nothing: https://launchpad.net/ubuntu/trusty/ppc64el/juju2
[14:27] <perrito666> mbruzek: ah juju2 sorry I missread you
[14:27] <perrito666> no, I dont know about 2
[14:27] <voidspace> babbageclunk: https://github.com/juju/juju/pull/4962
[14:27] <mbruzek> perrito666: Thanks for link...
[14:28] <mbruzek> This partner is only using LTS versions so since we haven't yet released 16.04 is a big ask of us
[14:29] <natefinch> rick_h_: ^ mbruzek is asking about juju2 on ppc64el.. do we have a PPA which supports that?
[14:29] <natefinch> (on trusty)
[14:33] <natefinch> errors.Errorf("(cannot happen)
[14:33] <natefinch> lol
[14:34] <rogpeppe1> natefinch, katco: you might be interested to see that subtest functionality has actually landed in go tip; not that it makes much difference in gocheck-land: http://tip.golang.org/pkg/testing/#T.Run
[14:36] <natefinch> rogpeppe1: ahh, cool, I knew they were working on that.  Is there explanation on how it should be used and what the output looks like?
[14:36] <katco> rogpeppe1: interesting... i wonder if niemeyer will update gocheck to take advantage
[14:36] <rogpeppe1> katco: i somewhat doubt it, but you never know
[14:36] <rogpeppe1> natefinch: suck it and see :)
[14:36] <natefinch> rogpeppe1: lol
[14:37] <natefinch> gah, there is so much charmstore logic littered around our code....
[14:43] <niemeyer> katco: That's nice, makes sense for gocheck to support it.. we'll just need to wait until it's mainstream.. a couple of years at least :(
[14:43] <katco> niemeyer: hehe well it'll get there
[14:44] <perrito666> we need a gotpkg.in/hipstergocheck that implements features before they are mainstream :p
[14:48] <voidspace> frobware: dooferlad: http://reviews.vapour.ws/r/4401/
[15:17] <rick_h_> natefinch: mbruzek i'm not sure we do. mgz and sinzui should be on soon and would know for sure
[15:17] <mbruzek> Hi rick_h_: we got it sorted, abentley and perrito666 helped me out.
[15:18] <mbruzek> rick_h_: It turns out they needed to add the ppa:juju/devel ppa.
[15:18] <mbruzek> rick_h_: I want to update the devel docs to suggest the devel ppa, do you object to that in anyway?
[15:23] <rick_h_> mbruzek: pr and o'll look and see if there's something better?
[15:24] <rick_h_> mbruzek: i guees since it's not final we push folks at xenial as it's not either
[15:24] <katco> fwereade: hey we need you in a chat rq, do you have a moment?
[15:24] <fwereade> katco, sure
[15:24] <katco> fwereade: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
[15:29] <mbruzek> rick_h_: https://github.com/juju/docs/pull/951
[15:29] <mbruzek> rick_h_: The issue with the partner was resolved, but if this change was in the docs they might not have had the problem.
[15:34] <dooferlad> frobware: ping
[15:36] <frobware> dooferlad: pong
[15:36] <dooferlad> frobware: are you making any progress with https://bugs.launchpad.net/juju-core/+bug/1556137 ?
[15:37] <mup> Bug #1556137: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count> <oil> <juju-core:Triaged> <MAAS:New> <https://launchpad.net/bugs/1556137>
[15:37] <frobware> dooferlad: over and above the comment I added yesterday I'm doing nothing more...
[15:38] <dooferlad> Are you free to jump in a hangout and discuss it?
[15:38] <frobware> sure
[15:39] <dooferlad> frobware: https://plus.google.com/hangouts/_/canonical.com/sapphire?authuser=0
[15:49] <freyes> hi there, the juju-core deb source used by ppa:juju/stable, where is it maintained?
[15:50] <perrito666> freyes: you mean the source for the package?
[15:50] <freyes> perrito666, yup, the debian/ directory
[15:59] <niedbalski> freyes, checkout https://code.launchpad.net/ubuntu/+source/juju-core
[16:01] <freyes> niedbalski, those are the debian sources for the packages that have been uploaded to the distro archives, I looking repository where the debian sources for juju-core are maintained
[16:02] <niedbalski> freyes, ah stable ppa. I have no idea, maybe abentley mgz ^^ ?
[16:04] <mgz> freyes: for xenial proposed packaging, see lp:~juju-qa/ubuntu/xenial/juju/xenial-2.0-beta3
[16:04] <mgz> freyes: I missed the initial question so I'm not sure what you're after
[16:04] <freyes> mgz, which one is used for ppa:juju/stable ?
[16:06] <mgz> freyes: last time I think and ol version of lp:~juju-qa/juju-release-tools/packaging-juju-core-default but that is changing
[16:08] <freyes> mgz, thanks, I think that will work for what I want
[16:09] <mgz> freyes: remember juju uses streams for everything but the client, so just rebuilding a debian package doesn't do much
[16:10] <freyes> mgz, yes, I'll use --upload-tools to make sure I use the version I have built
[16:11] <mgz> freyes: if you're going to be using --upload-tools you can just use a go build, you don't need the debian bits
[16:12] <freyes> mgz, this is part of a longer story, I need to provide a user with a patched 1.25.0 version to fix an specific problem they are having
[16:12] <freyes> and then they'll be able to upgrade
[16:12] <freyes> mgz, funny, isn't it?
[16:27] <ericsnow> katco, natefinch: we're done talking, if you want to continue our standup
[16:28] <katco> ericsnow: sounds good brt
[16:29] <mgz> freyes: I am interested in this, are you going to write up what you've done to mailing list or similar?
[17:48] <natefinch> ericsnow, katco: sorry, was at lunch. Want to meet now, or ?
[17:49] <ericsnow> natefinch: we decided there probably wasn't much to discuss, unless you have anything
[17:50] <natefinch> ericsnow: nah... really just need reviews on my branches so I can get them landed.. they're all dependent, so it makes things difficult the longer they stick around
[17:50] <ericsnow> natefinch: feeling your pain :/
[17:55] <natefinch> ericsnow: maybe I'll just squash them all into a single commit
[17:56] <ericsnow> natefinch: that certainly makes rebasing easier
[17:56] <natefinch> ericsnow: yeah, that's why I've started doing that for individual PRs
[18:59] <mup> Bug #1565044 opened: s390x unit tests fail because not tools for arch <s390x> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1565044>
[19:01] <perrito666> apparently github now allows squashing on merge, oh the hapiness
[19:02] <natefinch> oh no way
[19:03] <perrito666> that would fix rogpeppe2 complain from today
[19:06] <natefinch> oh man, that's awesome
[19:06] <natefinch> and you can turn off the non-squash merge
[19:25] <natefinch> Yet another problem with full stack tests:  Change a function deep in the stack... now try to find tests that need to update to test that function.
[19:25] <natefinch> Sure, you can run the tests and fix ones that fail... but that doesn't mean there aren't tests that are passing and shouldn't be.
[20:32] <natefinch> oh crap
[20:32] <natefinch> evidently you need to remember to do --parent when you rbt post -u
[20:33] <natefinch> This diff has been split across 120 pages
[20:34] <natefinch> ericsnow: do you know if there's any way to remove an errant diff from a review?
[20:34] <ericsnow> natefinch: better to just push up the correct one
[20:36] <natefinch> ericsnow: how do I do that?  rbt post complains the commit is already on reviewboard
[20:37] <ericsnow> natefinch: not sure
[20:38] <ericsnow> natefinch: perhaps add another commit?
[20:41] <natefinch> well, as long as no one looks at changelist #2, we're all set :)
[20:44] <natefinch> ericsnow: btw, just doing another rbt post -u with --parent added another changelist, and as long as you look at 0-N and skip the intermediary ones, it's fine
[20:44] <ericsnow> natefinch: yep
[21:17] <mup> Bug #1565089 opened: create-model does not use the same config format as bootstrap <jujuqa> <juju-core:Triaged> <https://launchpad.net/bugs/1565089>