Re: armhfentures

Especially for platforms that aren't amd64, I think we want newer go compilers. I would imagine the architecture support has gotten better as they've introduced more architectures. And I'd be especially cautious rolling back a crypto branch as they tend to fix security issues. I don't know the

armhfentures

There is a bug filed over Juju 2.0 not building with go 1.2 on armhf: I believe I understand all the moving parts here, but it's a little fiddly and we're going to have to make a choice about how we plan to build 2.0, so wanted some input. The

Re: Juju devel 2.0-beta2 is available for testing

Awesome, thanks for reporting back Jorge! On Fri, Mar 11, 2016 at 1:08 PM, Jorge O. Castro wrote: > On Fri, Mar 11, 2016 at 3:42 PM, Curtis Hovey-Canonical > wrote: > > * LXD provider (requires lxd 2.0.0~rc2-0ubuntu2 or later): > > I'd like to report

Re: Juju devel 2.0-beta2 is available for testing

On Fri, Mar 11, 2016 at 3:42 PM, Curtis Hovey-Canonical wrote: > * LXD provider (requires lxd 2.0.0~rc2-0ubuntu2 or later): I'd like to report that both Marco and myself have successfully deployed the trusty realtime-syslog-analytics bundle to our individual machines using

old, untouched PRs

Hi In our last team meeting, we have decided that we will be removing all untouched PRs in RB that are older than a month. Please ensure that all PRs that are important to you are either hand-held to completion or receive regular progress comments. For example, there are some PRs in the queue

Re: Do we still need juju upgrade-charm --switch ... ?

> > We use switch a lot, and customers use this as well. The primary use case > is "I have a bug in production charm that is not available upstream yet". I > expect future 2.0 uses to look like this: > > charm pull > > juju upgrade-charm --switch ./ > > Another example, esp because of how

Re: Do we still need juju upgrade-charm --switch ... ?

On Thu, Mar 10, 2016 at 10:28 PM Ian Booth wrote: > So we have a feature of upgrade-charm which allows you to crossgrade to a > different charm than the one originally deployed. > > From the upgrade-charm help docs: > > The new charm's URL and revision are inferred as