Comment 37 for bug 1545913

Well, mixed news.

The 1.25.5 upload yesterday got bopped by the keyserver failing, but has now been reuploaded and we're waiting on the autopkgtest run.

The 2.0-beta4 upload happened, and we have test results:

<http://autopkgtest.ubuntu.com/packages/j/juju-core/>

Things are in a better state (s390x is actually green) but the substrates that can run the lxd test all failed with:

<https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/j/juju-core/20160415_045320@/log.gz>

+ juju bootstrap my-controller lxd --upload-tools --debug --config default-series=xenial
2016-04-15 04:44:46 INFO juju.cmd supercommand.go:60 running juju [2.0-beta4 gc go1.6.1]
2016-04-15 04:44:46 INFO cmd cmd.go:141 cloud "lxd" not found, trying as a provider name
2016-04-15 04:44:46 INFO cmd cmd.go:141 no credentials found, checking environment
2016-04-15 04:44:46 DEBUG juju.cmd.juju.commands bootstrap.go:365 preparing controller with config: map[type:lxd name:admin uuid:2bf2d716-0a36-46a3-8b77-83dc8fc66507 controller-uuid:2bf2d716-0a36-46a3-8b77-83dc8fc66507 default-series:xenial]
2016-04-15 04:44:50 DEBUG juju.tools.lxdclient client.go:73 connecting to LXD remote "local": ""
2016-04-15 04:44:52 DEBUG juju.tools.lxdclient client.go:73 connecting to LXD remote "juju-remote": "10.0.8.1"
2016-04-15 04:44:52 ERROR cmd supercommand.go:448 Get https://10.0.8.1:8443/1.0/profiles: Forbidden
adt-run [04:44:53]: test current-lxd-provider: -----------------------]
adt-run [04:44:53]: test current-lxd-provider: - - - - - - - - - - results - - - - - - - - - -
current-lxd-provider FAIL non-zero exit status 1

I'm not sure what is different here, from the setup I got to pass successfully, using a canonistack machine:

<http://paste.ubuntu.com/15852422/>

The 30 mins fetching stuff from the archive into the container there is... suspect, but also well after the autopkgtest.ubuntu.com setup fails.

I'm not sure how to debug further, given I can't exactly reproduce the real setup.

Additionally, and easier to fix, the armhf future-manual-provider test fails because it can't install juju-mongodb3.2:

<https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/j/juju-core/20160415_091616@/log.gz>

2016-04-15 09:16:01 DEBUG juju.cmd.jujud bootstrap.go:322 starting mongo
2016-04-15 09:16:01 DEBUG juju.cmd.jujud bootstrap.go:347 calling ensureMongoServer
2016-04-15 09:16:01 INFO juju.mongo mongo.go:394 Ensuring mongo server is running; data directory /var/lib/juju; port 37017
2016-04-15 09:16:01 INFO juju.mongo mongo.go:559 installing [juju-mongodb3.2]
2016-04-15 09:16:01 INFO juju.utils.packaging.manager utils.go:57 Running: apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install juju-mongodb3.2
2016-04-15 09:16:02 ERROR juju.utils.packaging.manager utils.go:103 packaging command failed: encountered fatal error: unable to locate package; cmd: "apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install juju-mongodb3.2"; output: Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package juju-mongodb3.2

This is fun, but not an unexpected result from other choices. We're not building mongo 3 on 32 bit arches, and the fallback to the old package in juju was explicitly only for xenial and lower series.