[00:36] <sinzui> thumper-afk, wallyworld_ CI cannot make a tarball for r2283. The error here implies Lp or goyaml project is borked. http://162.213.35.54:8080/job/prepare-new-version/960/console
[00:36] <sinzui> ^ I cannot make sense of it
[00:36] <wallyworld_> let me look
[00:38] <wallyworld_> i blame lp
[00:38] <wallyworld_> the last commit to trunk was back in nov i think
[00:39] <sinzui> I agree
[00:39]  * thumper is back
[00:40] <sinzui> I can branch that though
[00:40] <wallyworld_> sinzui: maybe just retry? could be transient?
[00:41] <sinzui> I did two reties, but I am doing a 3rd since I can see the branch
[00:41] <sinzui> http://162.213.35.54:8080/job/prepare-new-version/961/console
[00:41] <wallyworld_> this time tomb is borked
[00:42] <sinzui> I just branched tomb as well
[00:43] <sinzui> what!
[00:43] <sinzui> wallyworld_, This is my rapid rebuild: http://162.213.35.54:8080/job/prepare-new-version/962/console
[00:43]  * sinzui finds an old-fashioned losa
[00:43] <wallyworld_> wtf
[00:45] <sinzui> I have have several rebuilds now and the failures are always a random Lp branch
[00:49] <sinzui> wallyworld_, I am going to let CI rest. Lp is have bazaar issues. random 503s for branches that are fine
[00:49] <wallyworld_> ok
[00:50] <wallyworld_> sinzui: did someone ask you about a 1.17.2 release?
[00:50] <sinzui> Yeah
[00:50] <wallyworld_> would be easier if lp worked
[00:50] <thumper> sinzui: y u break lp?
[00:51] <sinzui> Local deploy hasn't passed in 7 days though, and and azure is doesn't work either
[00:51] <thumper> sinzui: well that is fucked up
[00:51] <thumper> I wish I knew what was going on there
[00:51] <thumper> I deployed to local on trusty today :-(
[00:52] <wallyworld_> it worked?
[00:52] <thumper> yes
[00:52]  * thumper think
[00:52] <wallyworld_> i must retry that
[00:52]  * thumper tries
[00:57] <thumper> wallyworld_:sinzui, yes just deployed the ubuntu charm locally successfully
[00:58] <hazmat> do addresses need to be defined up front when adding machines to state, or can they be detected at runtime by the machine agent?
[01:10] <axw> thumper: does rsyslogd create /var/log/juju-${namespace} if it doesn't exist...?
[01:10] <axw> I can't see a mkdir for it
[01:10] <thumper> axw: i believe it should
[01:10] <axw> mk
[01:13] <hazmat> thumper, can proxy values be set at runtime?
[01:13] <thumper> hazmat: yes
[01:13] <hazmat> axw, do addresses need to be defined up front when adding machines to state via inject machine, or can they be detected at runtime by the machine agent?
[01:13] <hazmat> cool
[01:13] <axw> hazmat: they can be detected, but if you do that there's no guarantee about which one will be "public"
[01:13] <axw> so dns-name in status may show up some interface you don't want
[01:14] <axw> s/can/will/
[01:15] <axw> hazmat: I made a change just yesterday to the manual provider to record the bootstrap-host as public
[01:15] <axw> for that reason
[01:18] <axw> thumper: is there a reason not to change MachineConfig.LogDir, and not hard-code the /var/log/juju${namespace} in log/syslog?
[01:18] <hazmat> axw, hmm. ic. thanks. the notion of public and private in a private cloud is a bit wonky.
[01:18] <thumper> axw: yes there is a reason
[01:18] <axw> hazmat: indeed
[01:18] <thumper> axw: but on a call right now with waigani
[01:19] <axw> ok
[01:32] <davecheney> hey, did I hear that deploying to hp cloud was fixed ?
[02:11] <sinzui> I added a jackhammer to CI. It will try harder to get the branches from Lp. r2283 is being tested now
[02:20] <hazmat> davecheney, got a minute to help out with a golang cross compile setup?
[02:21] <hazmat> davecheney, also does go support aarm64?
[02:22] <hazmat> er t242-servergroup0002s:
[02:22] <hazmat> er.. aarch64
[02:48] <davecheney> hazmat: ack
[02:48] <davecheney> golang-go does not support aarch64
[02:48] <davecheney> if you are using trusty
[02:48] <davecheney> install gccgo-go
[02:49] <sinzui> I have more info on bug 1274780. postfix cannot be setup on the unit because the unit's host name doesn't appear to be sane
[02:49] <_mup_> Bug #1274780: Wordpress charm no longer works with local deploy. <charms> <ci> <local-provider> <lxc> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1274780>
[02:57] <hazmat> davecheney, hmm
[02:57] <thumper> sinzui: I commented on that bug
[02:57] <thumper> according to the RFC, dash is a valid hostname character
[02:58] <sinzui> A leading dash is valid?
[02:58] <davecheney> hazmat: yeah, mwd is working on the aarch64 support in gccgo
[02:58] <davecheney> thumper: i think it cannot be the first character
[02:59] <davecheney> experts-exchange.com << all good
[02:59] <davecheney> -expertsexchange.com << not good
[03:01] <thumper> we don't have leading dashes though do we?
[03:01] <thumper> ah... -local-machine-1
[03:02] <thumper> the local provider grabs $USER I think
[03:02] <thumper> let me look
[03:02] <davecheney> ah
[03:02] <davecheney> $USER-local-machine-1
[03:02] <thumper> namespace = fmt.Sprintf("%s-%s", os.Getenv("USER"), cfg.Name())
[03:03] <thumper> sinzui: how are you running this?
[03:03] <thumper> why is there no USER env var?
[03:04] <sinzui> thumper, CI runs it
[03:04] <thumper> sinzui: sure... how?
[03:04] <thumper> CI isn't running like a user would
[03:04] <thumper> so we need to fix CI
[03:04] <thumper> to behave like a user
[03:04] <thumper> that also means having a valid environement
[03:05] <sinzui> thumper, This script is calling juju during the test of the env named local http://bazaar.launchpad.net/~juju-qa/juju-core/ci-cd-scripts2/view/head:/deploy_stack.py
[03:06] <thumper> ok, so what is the environment the script is running under?
[03:07] <davecheney> thumper: if juju requires a $USER to be set
[03:07] <davecheney> then it should abort
[03:07] <davecheney> bigjools: see what I did there
[03:07] <thumper> davecheney: agreed
[03:07] <davecheney> thumper: i think this might also be an issue during cloud init bootstrap
[03:07] <sinzui> thumper, jenkins run a bash script that sets JUJU_HOME (which is not entirely honored) then destroys anything left behind by a previous test, then calls ^ that script to bootstrap deploy and status
[03:08] <davecheney> sinzui: i'm having problems making saucy environments in HP cloud
[03:08] <davecheney> i heard that there was an known issue
[03:08] <davecheney> is this true ?
[03:08] <thumper> sinzui: ok, we can get around this by adding "USER=jenkins-ci" to the environment
[03:08] <sinzui> I have heard that, I have not test it
[03:08] <thumper> in the same place you set JUJU_HOME
[03:09] <thumper> but I do agree with davecheney
[03:09] <thumper> juju should abort if it isn't set
[03:09] <sinzui> I think it is set
[03:09] <sinzui> jenkins@juju-juju-ci-machine-1:~$ echo $USER
[03:09] <sinzui> jenkins
[03:10] <sinzui> thumper, the charm only fails in local-deploy. 1.16.5 deploys it locally. So to other clouds, and the charm has not changed in a month
[03:10] <thumper> sinzui: but CI has changed
[03:10] <thumper> it works fine for me
[03:11] <thumper> I can tell you that the process that is running juju doesn't have $USER set
[03:11] <sinzui> You are a developer with taited setup
[03:11] <thumper> that is why the name starts with a -
[03:11] <thumper> it may be because the environment is being overridden when it shells out
[03:11] <thumper> I don't know
[03:11] <thumper> what I do know
[03:11] <thumper> is that it isn't set
[03:12] <davecheney> sinzui: I can confirm as of 12 hours ago I could not make saucy environments in HP cloud
[03:12] <sinzui> I am forcing a built with an exported USER
[03:12] <thumper> is there any way we can hook into the bit that calls juju
[03:12] <thumper> to see what $USER is?
[03:14] <sinzui> . o (sudo was set to pass the env, sudo is not used anymore)
[03:15] <axw> thumper: how did this work before? we used $USER before too...?
[03:15] <sinzui> davecheney, WTF, where is https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910/juju-dist/tools
[03:16] <davecheney> i have no idea
[03:16] <thumper> axw: you may make me go look, but check blame
[03:16] <davecheney> i was using --upload-tools so I didn't notice
[03:16] <thumper> I think it looked at SUDO_USER
[03:17] <sinzui> davecheney, typo. I have got to get sleep
[03:18] <axw> thumper: pretty sure it used $USER, but I'll double check
[03:18] <thumper> axw: well, it worked before :)
[03:18] <axw> thumper: ah, it used $USER and then $SUDO_USER if $USER wasn't set...
[03:18] <sinzui> davecheney, I see the tools are in place, but have you lost os images?
[03:19] <axw> or rather, if it was root
[03:19]  * sinzui sees that trusty is not an option on hp
[03:20] <thumper> sinzui: and now there is no fallback to check on the SUDO_USER so it is empty
[03:20] <sinzui> thumper I award you a star ✶
[03:20] <sinzui> Alas jenkins was so excited by the success it fell over and is reseting the tests, damn it
[03:21] <axw> I think we can just fall back to using os/user
[03:21] <axw> seems odd not to have $USER set though.
[03:23] <davecheney> sinzui: we don't have trusty support anywhere
[03:23] <davecheney> but if you can get a saucy macine
[03:23] <davecheney> you can upgrade it
[03:24] <sinzui> davecheney, You have a brilliant suggestion. We test trusty on aws and caonistack. azure has it too,
[03:24] <davecheney> sinzui: to make trusty work we need two things
[03:25] <davecheney> 1. juju has to understand trusty as a series
[03:25] <davecheney> i'm looking for the magic constant now
[03:25] <davecheney> 2. we have to have trusty images avaialble in simple streams
[03:25] <axw> thumper: would you like me to fix this one, or are you doing it already?
[03:25] <davecheney> i'm guessing that happens at alpah 1
[03:25] <sinzui> dave 2. is true alpha two
[03:25] <thumper> axw: fix what?
[03:26] <axw> thumper: things not working if $USER not set
[03:26] <thumper> axw: can you?
[03:26] <axw> yes, I think so
[03:26] <davecheney> cloudinit/sshinit/configure_test.go
[03:26] <davecheney> 74:var allSeries = [...]string{"precise", "quantal", "raring", "saucy"}
[03:26] <davecheney> ^ we have a lot of these magic constants
[03:29]  * davecheney fixes
[03:33] <sinzui> davecheney, I think the simplestreams module also defines that, then overrides it with the data from /usr/share/distro-info/ubuntu.csv
[03:36] <davecheney> simplestreams does define trusty, i wonder where other places do not
[03:36] <davecheney> sinzui: to clarify, suacy on HP appears broken, should I raise a bug ?
[03:37] <sinzui> yes
[03:37] <thumper> sinzui: are you coming to cape town?
[03:38] <sinzui> Yes, thumper
[03:38] <davecheney> sinzui: ok
[03:39] <sinzui> http://www.youtube.com/watch?v=P3-f0k620Vg
[03:39] <thumper> sinzui: I can't remember, do you drink alcohol?
[03:39] <thumper> sinzui: if so, I'll get you a drink for all the CI work :)
[03:39] <thumper> if not, then geez
[03:39] <thumper> water
[03:39] <sinzui> thumper, Most when trying to use windows, otherwise a beer does me well
[03:41]  * thumper fixes two of the remaining proxy issues
[03:41] <thumper> man my triceps hurt today
[03:41] <thumper> I thought that boxing gave them a good workout
[03:42] <thumper> but yesterday I took my first Gracie Jiu-Jitsu class
[03:42] <thumper> very different muscles uses
[03:42] <thumper> used
[03:56] <thumper> axw, wallyworld_: https://code.launchpad.net/~thumper/juju-core/remove-container-special-proxy/+merge/204152
[03:57] <axw> heading out for lunch in a few minutes, will take a look when I get back
[03:57] <wallyworld_> looking
[04:11]  * thumper EOWs and goes to pack
[07:11] <dimitern> bac, hey, are you still there?
[07:59] <axw> wallyworld_: would you mind taking a look at https://codereview.appspot.com/58140044/?
[07:59] <wallyworld_> sure
[08:00] <wallyworld_> i did see that one and meant to do it but forgot
[08:00] <axw> nps
[08:00] <axw> I forgot about it myself :)
[09:58] <wallyworld_> fwereade: hi, i have a fix for the instance type selection. now selects 1024MB instance by default on canonistack (not 512MB) and constraints which cannot be satisfied eg cpu-cores=9000 are rejected https://codereview.appspot.com/58950043/
[09:58] <fwereade> wallyworld_, *sweet*
[09:59] <fwereade> wallyworld_, I will try to take a look today but am uncomfortably aware of a bunch of SA prep I am behind on
[09:59] <wallyworld_> i added extra tests which illustrate the behaviour, seems to ll work ok
[09:59] <wallyworld_> yeah. np. i won't land till you look, can wait till next week
[10:00] <TheMue> fwereade: this is the current debug-log after the reimplementation, review by roger and changes based on that
[10:01] <TheMue> fwereade: we decided to filter now with regexp, and it's really nice
[10:01] <fwereade> TheMue, I direct the honourable gentleman to my previous response
[10:01] <TheMue> fwereade: already played with it yesterday
[10:01] <fwereade> TheMue, cool
[10:02] <TheMue> fwereade: eh, that link was missing https://codereview.appspot.com/58510045/ ;)
[10:04] <TheMue> fwereade: SA means South Africa?
[10:05] <fwereade> TheMue, yeah
[10:07] <TheMue> fwereade: will surely be an interesting trip. but also exhausting. mine next week is shorter, only flying to munich to give talks about juju and golang.
[10:51] <fwereade> dimitern, rogpeppe1: standup?
[10:52] <rogpeppe1> fwereade: 3 mins
[11:12] <TheMue> fwereade, rogpeppe1: could it be that the Environment of state stores the name of the env, but doesn't provide an accessor?
[11:18] <hazmat> what's provider-safe-mode do?
[11:20] <hazmat> oh.. its the  don't kill instances
[11:43] <TheMue> fwereade or rogpeppe1: when using the local provider, nothing is written into its all-machines.log. is this a known problem or only a local problem with rsyslog?
[11:49]  * TheMue looks around in the channel. no one here?
[11:50] <TheMue> fwereade: ping
[11:50] <TheMue> rogpeppe1: ping
[11:50] <rogpeppe1> TheMue: we're in the standup
[11:50] <TheMue> rogpeppe1: still? ok
[11:51] <TheMue> rogpeppe1: thx for info, i'll be patient. ;)
[12:16] <bac> hi dimitern
[12:18] <dimitern> hey bac
[12:19] <dimitern> bac, i commented on the bug
[12:19] <bac> hi dimitern, i've just read your bug report.
[12:20] <bac> i'll try to isolate the problem and update the bug if i discover anything new.  thanks for looking at it.
[12:21] <dimitern> sure
[12:22] <bac> dimitern: your testing was on trusty?
[12:23] <dimitern> bac, i'm on saucy and I've been deploying on precise
[12:23] <bac> dimitern: thanks
[12:33] <natefinch> fwereade, rogpeppe1, mgz, dimitern:  Morning guys, sorry I missed the standup.  Overslept.  Zoë was up every hour last night :/
[12:33] <dimitern> natefinch, morning ;)
[13:23]  * TheMue needs help with local provider
[13:23] <TheMue> rogpeppe1: ended standup?
[13:24] <dimitern> rogpeppe1, review poke, when you can pls
[13:24] <dimitern> TheMue, what's the issue?
[13:25] <TheMue> dimitern: the bootstrap environment creates its all-machines.log but the data of machine-0.log isn't written into it
[13:25] <TheMue> dimitern: the rsyslog config looks good so far (as I can tell)
[13:26] <dimitern> TheMue, maybe syslog is not running?
[13:27] <dimitern> TheMue, there's a syslog-port in the env.yaml you can set (and a default is used otherwise)
[13:27] <TheMue> dimitern: thx, will try. rsyslogd is running
[13:29] <fwereade> dimitern, mgz, rogpeppe1, hazmat: sorry, I need to go out for a bit -- is it better for me to be late, or for us all to push the meeting back 30 mins?
[13:30] <fwereade> please confer amongst yourselves
[13:30] <dimitern> fwereade, i'm ok pushing it 30m
[13:32] <hazmat> sounds good
[13:35] <rogpeppe1> fwereade: sgtm
[13:42] <dimitern> natefinch, updated https://codereview.appspot.com/54680045/
[13:44] <ahasenack> guys, any idea what's up with this error while bootstrapping on aws?
[13:44] <ahasenack> 2014-01-31 13:42:36 WARNING juju.environs open.go:258 failed to write bootstrap-verify file: cannot make S3 control bucket: A conflicting conditional operation is currently in progress against this resource. Please try again.
[13:44] <ahasenack> 2014-01-31 13:42:36 ERROR juju supercommand.go:282 provider storage is not writable
[13:44] <rogpeppe1> TheMue: pong
[13:45] <rogpeppe1> TheMue: (finally! sorry)
[13:45] <natefinch> dimitern: looking
[13:46] <TheMue> rogpeppe1: do you no any reason why no data is written into all-machines.log at the local provider? it is created by syslog
[13:47] <rogpeppe1> TheMue: all-machines.log is at a different file path in the local provider
[13:47] <rogpeppe1> TheMue: hence my comment on your review
[13:48] <TheMue> rogpeppe1: yeah, sure, I know
[13:48] <TheMue> rogpeppe1: I talk about the all-machines.log of the local provider
[13:48] <TheMue> rogpeppe1: it is created at its right place below ~/.juju/<env>/log/
[13:48] <TheMue> rogpeppe1: but empty
[13:49] <TheMue> rogpeppe1: while e.g. machine-0.log contains data (which should be aggregated then)
[13:50]  * TheMue is happy that at least testing with local provider is by far faster than with EC2 :)
[13:51] <natefinch> dimitern: if the charm packaging code you put into the apiserver is basically a copy of the code in the charm package.... could we not just reference the charm package code here?
[13:51] <dimitern> natefinch, no, fwereade wants them separate
[13:52] <dimitern> natefinch, most of these are unexported helpers
[13:52] <dimitern> natefinch, and exporting them is not an option
[13:52] <rogpeppe1> TheMue: i'm afraid i don't know why - i'd have to look into the code
[13:53] <rogpeppe1> TheMue: it might be something to do with the address that containers are putting into the syslog configs
[13:53] <TheMue> rogpeppe1: ok, thx, only asked if somebody may made the same experience
[13:53] <rogpeppe1> TheMue: i've not looked actually
[13:54] <rogpeppe1> TheMue: one mo, i'll see if it happens on my machine
[13:54] <dimitern> ahasenack, did you retry successfully?
[13:54] <TheMue> rogpeppe1: I'll continue investigating
[13:54] <TheMue> rogpeppe1: ta
[13:55] <ahasenack> dimitern: no
[13:55] <rogpeppe1> TheMue: i don't see any all-machines.log in my local env/log file
[13:55] <rogpeppe1> s/file/dir/
[13:55] <rogpeppe1> TheMue: but that may be an old juju version
[13:55] <rogpeppe1> TheMue: let me try with trunk
[13:55] <dimitern> ahasenack, if retrying doesn't help, file a bug please?
[13:57] <rogpeppe1> anyone remember how to fix the gobot when there's an exclusive lock that it's blocked on?
[13:57] <dimitern> rogpeppe1, yep
[13:57] <ahasenack> dimitern: ok
[13:57] <dimitern> rogpeppe1, kill the mongo and delete its sock file from tmp
[13:57] <rogpeppe1> it's been moribund since 7am this morning
[13:57] <rogpeppe1> dimitern: ok, thanks
[13:57] <TheMue> rogpeppe1: I'm using one near trunk. location is $HOME/.juju/$JUJU_ENV/log/all-machines.log
[13:58] <rogpeppe1> ha, i wonder what happens if you name your local environment "environments"
[14:06] <hazmat> dimitern, hangout for that meeting?
[14:07] <dimitern> hazmat, none created, we can reuse the standup one - https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[14:07] <hazmat> argh.. not allowed to join call.
[14:08] <dimitern> fwereade, rogpeppe1, mgz, ^^ (it's in 20ish minutes)
[14:08] <dimitern> hazmat, can you do now? i invited you
[14:09] <hazmat> dimitern, yup that works thanks
[14:09] <hazmat> nice empty room :-)
[14:10] <dimitern> hazmat, it's not on for 20 more minutes
[14:11] <ahasenack> dimitern: turns out a bug about it already exists: https://bugs.launchpad.net/juju-core/+bug/1183571
[14:11] <_mup_> Bug #1183571: A conflicting conditional operation... <cmdline> <hours> <juju-core:Triaged> <https://launchpad.net/bugs/1183571>
[14:11] <dimitern> ahasenack, hmm it seems intermittent and region-specific
[14:31] <rogpeppe1> hazmat: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[14:31] <rogpeppe1> fqw
[14:55] <mramm> sinzui: any news on the possibility of 1.17.2 release with the lxc bridge fix and the MAAS metadata fix?
[14:56] <sinzui> mramm, I selected r2285 this hour and am writing the release notes
[14:56] <sinzui> mramm, Azure is very brittle and I may note that in the note for the release
[14:57] <sinzui> If r2286 passes this hour, I will use it instead
[15:01] <mramm> nice
[15:01] <mramm> thanks
[15:01] <mramm> sinzui: you rock
[15:02] <TheMue> sinzui: he, found a solution for the local debug-log
[15:02] <TheMue> sinzui: s/he/ha
[15:03] <TheMue> sinzui: if all-machines.log now would contain data too it would be fine
[15:05] <dimitern> fwereade, are any of metadata.yaml, config.yaml and revision optional for a charm?
[15:05] <sinzui> TheMue, https://bugs.launchpad.net/juju-core/+bug/1270671 says it is fix committed
[15:05] <_mup_> Bug #1270671: local provider all-machines.log is empty  <juju-core:Fix Committed by thumper> <https://launchpad.net/bugs/1270671>
[15:05] <fwereade> dimitern, pretty sure config is optional
[15:05] <sinzui> TheMue, It is in today's release
[15:05] <fwereade> dimitern, and in theory revision is, sort of
[15:05] <TheMue> sinzui: fantastic
[15:06] <dimitern> fwereade, ok, so only metadata is mandatory
[15:06] <fwereade> dimitern, although that's something we should fix as it comes in, and Ithink the charm package handles that anyway
[15:06] <fwereade> dimitern, yeah, missing config is fine, missing revision is sorta fine but we should fix it aswe repack
[15:06] <dimitern> fwereade, ok
[15:24] <TheMue> sinzui: hmm, it changed into a symlink in /var/log/..., but is still empty *sigh*
[15:24] <TheMue> sinzui: just merged trunk
[15:25] <sinzui> :(
[15:29] <TheMue> sinzui: oh, stop, strange, it's only missing machine-0. machine-1 and unit-... are now added
[15:30] <sinzui> That is odd
[15:31] <TheMue> sinzui: and my debug-log works locally *yippieh*
[15:35] <dimitern> rogpeppe1, btw I'm still getting godeps: cannot parse "dependencies.tsv": cannot parse "github.com/loggo/loggo\tgit\t89458b4dc99692bc24efe9c2252d7587f8dc247b\t": unknown VCS kind "git" after pulling the latest godeps
[15:35] <rogpeppe1> dimitern: go get -u launchpad.net/godeps
[15:35] <dimitern> rogpeppe1, I did
[15:36] <dimitern> rogpeppe1, and then I went in $GOPATH/src/...godeps and did bzr pull - same issue
[15:36] <dimitern> (it said no revisions to pull)
[15:36] <rogpeppe1> dimitern: what revno do you get in the godeps dir?
[15:36] <rogpeppe1> dimitern: try rm -r the godeps dir, then go get it again
[15:36] <dimitern> rogpeppe1, rev 10
[15:37] <dimitern> rogpeppe1, ha! it appears to have moved from ~rogpeppe/godeps/trunk
[15:37] <rogpeppe1> dimitern: ah
[15:37] <rogpeppe1> dimitern: rev 14 is the latest
[15:38] <dimitern> rogpeppe1, yep, now it's fine, thanks
[15:38] <rogpeppe1> dimitern: cool
[15:46] <sinzui> rogpeppe1, dimitern Do ewither of you have time to review this branch because I am releasing 1.17.2 https://codereview.appspot.com/59050044
[15:46] <rogpeppe1> sinzui: looking
[15:47] <rogpeppe1> sinzui: LGTM
[15:47] <sinzui> thank you rogpeppe1
[15:51]  * fwereade needs to be out again for a bit, will be around again most of the evening
[16:12] <rogpeppe1> TheMue: you have another review
[16:13] <TheMue> rogpeppe1: yep, thx, just answering
[16:16] <gary_poster> jamespage, hi.  do you still think you'll have time for quickstart packaging?  if you are going to capetown I suspect that might take some of your time
[16:18]  * gary_poster stepping out for lunch
[17:03] <dimitern> TheMue, you have yet another review
[17:25] <jamespage> gary_poster, just did the packaging work and uploaded to trusty for archive admin review
[17:34] <TheMue> dimitern, rogpeppe1: thanks for your reviews. I added some comments and one for the whole stuff. will continue on monday.
[17:38] <dimitern> TheMue, thanks
[18:02] <gary_poster> awesome, thanks jamespage!
[18:51] <hatch> hey why does -e not work in destroy-environment but it's required everywhere else?
[18:52] <hatch> I'm trying to figure out the proper message to tell users of quickstart
[18:52] <hatch> but now the -e is also dependent on the version too?
[18:53]  * hatch hopes it's a bug and he can leave the -e in there
[18:53] <hazmat> hatch, it used to be.. it was abruptly changed without notice.. its been restored on trunk w/ a deprecation warning
[18:54] <hazmat> 1.17.2 should have it
[18:54] <hatch> hazmat so now everything else will not have -e either eventually?
[18:54] <hazmat> hatch, just destroy-env for hysterical raisons
[18:54] <hazmat> its so people don't accidentally destroy something
[18:55] <hazmat> because env to act upon  can be looked in one of four ways
[18:59] <hatch> ok thanks for clarifying
[19:02] <natefinch> hazmat, hatch: that was me, sorry.  I wanted the environment name to be mandatory, to make it less likely you'd accidentally destroy-environment on a production environment... however, I didn't think to make -e optional, and should have.
[19:05]  * hatch shakes finger at natefinch 
[19:05] <hatch> :P
[19:05] <natefinch> :D
[19:06] <natefinch> really, I just wanted to see if anyone was paying attention ;)
[19:06] <hatch> it's fine either way really, I just need to know what to tell the user in quickstart
[19:06] <hatch> haha
[19:23] <hazmat> .