I did not perform a code or packaging review for golang. I did reevaluate the current situation wrt static linking and under what conditions, if any, golang and packages depending on it would be supportable in main. In general, statically compiled binaries are not suitable for the Ubuntu archive because they increase the maintenance burden significantly.
golang 1.4 packages and earlier could only statically compile their binaries. golang 1.5 introduces -buildmode=shared to build shared libraries and -linkshared to dynamically link against shared libraries. wily now has golang 1.5 and Canonical is working on shared libraries for the remaining supported architectures. The golang project has stated that 1.6 will include shared library support for all the architectures that we officially support, and golang 1.6 will be available before 16.04 is released. The understanding has always been that if golang had proper shared library support enabled for archive builds by default, then there are no additional maintenance concerns beyond the packages themselves. A lot of effort has gone into shared library support in golang, this has all been upstreamed and is in wily now. While the work is not done yet (eg, arm64 is not finished), I think we can reach across the aisle and define how to support a limited set of (strategic) golang packages while the shared library support is being finished. In support of this, I've defined the MIR requirements for packages depending on golang[1][2] and have defined the security team processes for properly supporting them[3]. So long as the number of packages remains low and only as in interim solution, strategic (to Canonical) golang projects that statically build their binaries may be considered for MIR provided they follow the guidelines outlined in the wiki. It is vitally important to understand that even with these procedures, the process does not scale and we all must push forward to have golang 1.6 for 16.04 with shared library support on by default. As such, golang-go has security team signoff provided the following conditions are met: * the Ubuntu Foundations team/et al state their commitment to golang 1.6 with shared library support on by default in 16.04 * all packages that depend on golang that are in main must transition to golang 1.6 and use shared libraries. In terms of this MIR, the juju team must state their commitment in this bug * In addition to a bug subscriber, a team must state their commitment to supporting golang in Ubuntu (officially supporting a language is resource-intensive and we must ensure the resources are in place to do properly support those that depend on the language) * as per the MIRteam requirements, the juju team must state their commitment to testing no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release * ideally, a commitment (possibly Foundations and juju?) is stated in this bug that Ubuntu will work with Debian on dh_golang so that it properly supports shared libraries. This is not a strict requirement from the security team, but it will almost certainly provide the easiest path forward Once the above commitments are stated in this bug, I'll provide security team ACK for golang. [1]https://wiki.ubuntu.com/MIRTeam#golang [2]https://wiki.ubuntu.com/MIRTeam#Packaging_red_flags [3]http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/README.built_using -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to golang in Ubuntu. https://bugs.launchpad.net/bugs/1267393 Title: [MIR] juju-core, juju-mongodb, gccgo, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
