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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1545913 Title: [FFe] juju-core 2.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
