Re: linux/arm64 benchmark improvements

Wow, great values. Nice work. Thanks Dave (I'll contact Aram too) On Thu, Apr 16, 2015 at 8:50 AM, David Cheney david.che...@canonical.com wrote: Hello, Here are the results of the work Aram and I did last week on improving the performance of our arm64 port of Go. This is comparing the

linux/arm64 benchmark improvements

Hello, Here are the results of the work Aram and I did last week on improving the performance of our arm64 port of Go. This is comparing the build from April 06 (before we started) to today (April 16th). http://paste.ubuntu.com/10831430/ Cheers Dave -- Juju-dev mailing list

Re: Deploying Juju charms from Github

On 15/04/15 11:51, Robert Day wrote: I agree that not having juju-deployer handle the Git side of things, and just working locally from a Git checkout, would be simpler – but I don’t think that sort of bundle would work in the Juju GUI, because the extra steps needed mean that you can’t

Juju 1.23.0 is proposed for release

# juju-core 1.23.0 A new proposed stable release of Juju, juju-core 1.23.0, is now available. This release may replace version 1.22.1 on Thursday April 16. ## Getting Juju juju-core 1.23.0 is available for vivid and backported to earlier series in the following PPA:

Juju 1.23.0 is proposed for release

# juju-core 1.23.0 A new proposed stable release of Juju, juju-core 1.23.0, is now available. This release may replace version 1.22.1 on Thursday April 16. ## Getting Juju juju-core 1.23.0 is available for vivid and backported to earlier series in the following PPA:

'ERROR juju.cmd supercommand.go:430 no instances found' when bootstrapping Juju on OpenStack Juno

Hi all, I'm trying to set up Juju on my private OpenStack Juno cloud, but 'juju bootstrap' is consistently failing with 'ERROR juju.cmd supercommand.go:430 no instances found'. My juju-core package version is 1.22.1-0ubuntu1~12.04.1~juju1. The relevant section of my environments.yaml file is:

[Review Queue]

squeezed in a quick review: - ghost update for precise that replaces vendored asset blob with a configurable download. - ntp bug fix both approved [0] https://code.launchpad.net/~hatch/charms/precise/ghost/trunk/+merge/255168 [1]

[Review Queue] - Kibana, NTP

[1] Kibana: -1'd based on lack of tests [2] NTP - +1'd and merged 1. https://code.launchpad.net/~evarlast/charms/trusty/kibana/add-port-path-config/+merge/255144 2. https://code.launchpad.net/~brad-marshall/charms/trusty/ntp/add-auto-peers/+merge/253132 Charles Butler

Re: Reminder: Juju Office Hours, 16 April (tomorrow)

Ok everyone, we'll be in here in about 15 minutes, https://plus.google.com/events/c4t2adthcqk723kbd6j6otr1orc I'll post the followup Youtube URL afterwards. On Wed, Apr 15, 2015 at 10:50 AM, Jorge O. Castro jo...@ubuntu.com wrote: Hello everyone! Just a reminder that we have Juju office hours

[Review Queue] ibm-mq

I spent some time reviewing the IBM MQ charm in the review queue today. My review can be found here: https://bugs.launchpad.net/charms/+bug/1432489 One important thing to note is this charm does *NOT* contain the binary needed to deploy, *nor* does it download the binary. This creates a lot of

Re: Existing Charms: Can we get ppc64 PPA's built?

We need to have in kind that these are packaged by individuals or teams who may do it in their spare time, hence the lack of ppc64. If we remove them, what would be the consequences? Are the packages in the archives the same version as the PPA, or does the PPA provide us with a newer version? If

Existing Charms: Can we get ppc64 PPA's built?

Hi all, The following bugs, identified internally by Canonical, reference a situation where the charm relies on a PPA. There is an existing PPA for the x86 architecture, but not one for ppc64el. Can someone look and see if they can generate the appropriate ppc64el PPA for the following