Comment 20 for bug 1481507

The promotion of this package was premature and it doesn't meet the security requirements. Furthermore, the packaging is not meeting the requirements for a Go package in main. Specifically:
1. it is is not using dh-golang
2. debian/control use Built-Using: ${misc:Built-Using} for each non'-dev' binary package
3. it depends on gccgo for powerpc ppc64el (AIUI, you should use golang-go and it will pull in gccgo if needed)
4. it doesn't use any golang-*-dev packages when they are available in the archive and hasn't broken out other embedded libraries. Seth pointed this out in his review ("The lxd team will break apart the vendorized Go dependencies").

Of those, '1' is not a hard requirement for this MIR, but I strongly recommend you consider it for using the golang-*-dev packages (see http://pkg-go.alioth.debian.org/packaging.html; might want to use dh-make-golang). '3' should also be fixed, unless Foundations says otherwise. '2' must be fixed (but that is easy).

Which leaves '4': embedded sources with corresponding source in the archive:
- dist/src/golang.org/x/crypto: use golang-go.crypto-dev (part of juju MIR)
- dist/src/github.com/chai2010/gettext-go: use golang-gettext-dev, needs MIR
- dist/src/github.com/dustinkirkland/golang-petname: use golang-petname-dev, needs MIR
- dist/src/github.com/godbus/dbus: use golang-go-dbus-dev (part of juju MIR)
- dist/src/github.com/golang/protobuf: use golang-goprotobuf-dev, needs MIR
- dist/src/github.com/inconshreveable/go-vhost: use golang-vhost-dev, needs MIR
- dist/src/github.com/gorilla/context: use golang-context-dev, needs MIR
- dist/src/github.com/gorilla/mux: use golang-mux-dev, needs MIR
- dist/src/github.com/gorilla/websocket: use golang-websocket-dev, needs MIR
- dist/src/github.com/mattn/go-sqlite3: use golang-gosqlite-dev?, needs MIR
- dist/src/github.com/satori/go.uuid: use golang-uuid-dev, needs MIR
- dist/src/github.com/stretchr/objx: use golang-objx-dev, needs MIR
- dist/src/github.com/stretchr/testify: use golang-testify-dev, needs MIR
- dist/src/github.com/syndtr/gocapability: use golang-gocapability-dev, needs MIR
- dist/src/gopkg.in/check.v1: use golang-check.v1-dev (part of juju MIR)
- dist/src/gopkg.in/tomb.v2: use golang-gopkg-tomb.v2-dev, needs MIR
- dist/src/gopkg.in/yaml.v2: golang-yaml.v2-dev (juju is using golang-goyaml but trying to go to golang-yaml.v2-dev)

These have no corresponding source in the archive, and should be broken out:
- dist/src/code.google.com/p/go-charset
- dist/src/github.com/elazarl/goproxy
- dist/src/github.com/mattn/go-colorable
- dist/src/github.com/olekukonko/tablewriter
- dist/src/gopkg.in/flosch/pongo2.v3
- dist/src/gopkg.in/inconshreveable/log15.v2 (maybe choose one of the other
  options that are already in the archive?)

These seem LXD specific and seem ok to leave embedded(?):
- dist/src/github.com/stgraber/lxd-go-systemd
- dist/src/gopkg.in/lxc/go-lxc.v2 (should this be broken out?)

Stephane mentioned "We have the list of those, a good bunch are already packaged, we'll have to package at least two new ones and move away/replace a few more." At the time I took this to mean it was all in flight, but I still don't see that it has happened yet. Is this still on track?

Finally, bug subscribers aside (which the server or LXD team should be one for each of the above), does the LXD team want to do security maintenance for any of these embedded updates and/or have close coordination with the security team regarding them? (This is opposed to the normal process where the security team handles stable maintenance (unless we ask for help). I ask because the juju team specifically asked for their dependencies to be more tightly controlled by them)