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