[MIR] juju-core, juju-mongodb, gccgo, golang

[James Page]

>> golang <<

Availability
------------

In universe, limited to amd64, i386 and armhf archs.

Rationale
---------

golang is the primary focus of Go toolchain development; scale testing of juju with gccgo and golang gc built binaries revealed that the gccgo built binaries consume a significant amount of memory compared to golang gc built versions.

As juju is focussed on building scale out service deployments, choosing the toolchain that produces the most scalable binaries on the architectures that most users are going to be using would make sense.

Security
--------

Can't find any interesting security history.

QA
--

OK; the toolchain does have a test suite but its not run by default (yet).

Dependencies
------------

All build-deps are in main; some non-core packages depend on package in universe (kate, vim addons) - recommend that these are left in universe.

golang-go.tools can be demoted to a suggested to limit scope of main inclusion.

Standards compliance
--------------------

OK

Maintenance
-----------

>> gccgo-go <<

Availability
------------

In universe, available on all required architectures (x86, armhf, arm64, ppc64el).

Rationale
---------

'go' build tool built using gccgo, avoiding the need to promote two golang toolchains to Ubuntu main.

Security
--------

Searching for golang CVE's turned up nothing (this package is a rename of the golang 1.2 source package).

Quality assurance
-----------------

Package installs cleanly, go tool installed using alternatives at higher priority that golang-go version in universe.

Dependencies
------------

gccgo is in universe, all other dependencies in main.

Standards compliance
--------------------

OK

Maintenance
-----------

Some bugs expected upfront but should stabilize before release. Probably picked up by ubuntu-server if foundations team don't want to.

Background information
----------------------

This package is a re-cut of the golang upstream codebase with selected cherry-picks from upstream VCS for gccgo support, along with a patch to support building using gccgo + Make.

The only code actually used is in src/cmd/go.

>> juju-mongodb <<

Availability
------------

In universe, available on all required architectures (x86, armhf, arm64, ppc64el).

Rationale
---------

MongoDB is a dependency for operating a Juju deployed Ubuntu environment.

Security
--------

MongoDB has had some CVE's in the past, related to the use of the V8 and Spidermonkey Javascript engine in the Mongo Shell; however juju-mongodb builds without support for Javascript scripting, avoiding the historic CVE's (which where fixed upstream anyway).

Quality assurance
-----------------

Package installs cleanly, package build process runs upstream smoke tests (minus jstests due to disabling javascript support). Tests pass on all architectures.

Dependencies
------------

All in main already

Standards compliance
--------------------

OK (well is scons but we won't hold that against it)

Maintenance
-----------

Upstream MongoDB run stable releases with point updates; its intended that a MRE is applied for this package so point releases can be pushed as SRU's.

Its also possible that we might need to bump a major version (2.4.x -> 2.6.x); as this package is specific to Juju, we can constrain the impact and regression testing to Juju only.

Background information
----------------------

Why a separate package? it was agreed at the last vUDS that having a separate package allows us to limit a) use of v8 (disabled) which was a security concern and b) allows us to potentially update at a later date if need be only impacting juju itself.

>> juju-core <<

Availability
------------

In universe.

Rationale
---------

Juju is the recommended service orchestration tool for Ubuntu; as such it really needs to be a core part of Ubuntu.

Security
--------

No security history, but it was agreed that a security review would be undertaken as part of the MIR process.

Quality assurance
-----------------

No tests are run as part of the package build process; however upstream do run these tests for all target series (12.04 -> 14.04) prior to release so the overall quality of the codebase it pretty good.

The package has some basic DEP-8 tests that bootstrap a local Juju environment to ensure everything hangs together OK.

Dependencies
------------

juju-mongodb (see above)
gccgo + gccgo-go

Currently all required go dependencies are snapshotted at specific upstream commits and bundled with Juju.

Standards compliance
--------------------

OK

Maintenance
-----------

Upstream Juju team intend to manage stable point releases against the version shipped in 14.04. Ubuntu Server team will own the package in distro.

Background information
----------------------

Some decisions still need to be made, mainly around toolchain. Specifically the aim is to support a single Go toolchain in Ubuntu main for all architectures; golang-go does not support arm64 or ppc64el yet, whereas the gccgo implementation does.

Required changes to support gccgo have been upstreamed into the Juju codebase.

Its also worth noting that the package and binaries in Ubuntu are used for:

   client tool (juju)
   juju agent (jujud) - but only for local provider and where --upload-tools is used

Upstream released jujud binaries are/will be distributed officially via simplestreams using a documented build process (details TBC). The juju client will use these tools on public clouds and potentially in private cloud deployments where tools are synced into the cloud using the juju client tool (juju sync-tools).

[Curtis Hovey (sinzui)]

The juju-core aspect of this issue, and the driver to put a juju-mongodb in main, overlaps with bug 1243762.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Terry (mterry)]

Doko, these seem up your alley

[James Page (james-page)]

Adding golang toolchain to MIR; scale testing to 1000 clients had some rather nasty side-effects on the juju bootstrap node, which pushed a virtual memory footprint of 50G/resident at 1G. Compared to the binaries built using golang gc, this is an significant increase (over twice the footprint for resident memory) .

[Matthias Klose (doko)]

golang needs a team bug subscriber

[Matthias Klose (doko)]

juju-mongodb needs a team bug subscriber

[Matthias Klose (doko)]

gccgo-go needs a team bug subscriber

[James Page (james-page)]

doko - subscribed ubuntu-server to the packages details in #5->#7

[James Page (james-page)]

@ubuntu-mir

juju-core will need a security team review; this was discussed at UDS last.

Cheers

James

[Jamie Strandboge (jdstrand)]

Regarding adding golang toolchain to MIR, shouldn't we consider fixing the bug that causes the issue?

[James Page (james-page)]

Jamie

gccgo lacks a feature that golang gc has called escape analysis which is one of the causes for the increases memory usage with the gccgo built binaries.

This feature is not planned in the 14.04 timescale for gccgo.

[Martin Pitt (pitti)]

I find it rather concerning that golang-go has no runtime library, but everything gets linked in statically. This leads to enormous binaries (e. g. each of the juju program are > 30 MB) and hence lots of wasted download/hard disk/archive space, as well as being quite an interesting challenge wrt. security/bug fix updates, as pretty much every golang-go program had to be rebuilt. This also completely escapes symbol tracking, thus makes it hard to detect ABI changes, and thus leads to surprising FTBFS of packages once the underlying toolchain changed.

[Patricia Gaughen (gaughen)]

What's the time frame for this MIR review to complete?

[Seth Arnold (seth-arnold)]

Patricia, it is currently blocked by (at least) the security team review; this review is currently blocked by preparing a new apparmor package upload for trusty. I sincerely hope this upload is completed this week.

[Martin Pitt (pitti)]

Does the MIR/security teams seriously consider pulling all of golang/those static builds into main? The latter is quite a bad design as I pointed out in comment 12, and by Gustavo's own words the golang compiler grows old very quickly as there are constantly new upstream releases with new or changed language features, API breaks, and so on. So this doesn't appear to be a toolchain that we can support for 5 years in its current version?

[Jamie Strandboge (jdstrand)]

"Does the MIR/security teams seriously consider pulling all of golang/those static builds into main?"

This issue is quite complicated and slippery. Basically, the decision had been taken in Oakland last November that gccgo is the toolchain Ubuntu Engineering would support on the client and the foundations and security teams don't consider gc supportable from a distro standpoint due to the static linking issue. For the client, promoting golang would mean Ubuntu is not being responsible because we are making all these developers responsible for tracking *our* security and high impact bug fixes. On the client, I don't care if app developers embed some library that we don't provide-- that's on them to keep up to date, but I very much care if we ship a runtime as a standard part of Ubuntu/the SDK that developers are expected to use and we can't provide the fixes for them automatically.

That said, this MIR is about golang in support of juju for server/cloud, but the issue still remains-- we need to make sure we have something supportable. If golang is promoted to main, it is clear to me the Go community would rejoice and use it immediately, but then 3rd party developers will have to track Ubuntu's security fixes and recompile their applications on their own. Sure, we could add a note to the USN that people need to recompile their applications if they use golang, but USNs are not widely read and this practice is far outside the norm for updating stable releases and people will miss the fixes.

To paraphrase Steve Langasek from foundations, if there are blockers for the use of gccgo as the compiler, we should know what those are and we should be fixing those. Personally, my thinking is that if golang is truly the future and what the Go community and Canonical devs want, perhaps we should put resources behind fixing the upstream bug: http://code.google.com/p/go/issues/detail?id=256 (which incidentally, doesn't seem to have progressed in a long time).

The foundations and security team's stance is clear: if we ship something in Ubuntu in main, we need to be responsible for it and make sure people can get their updates. Moving forward, I see several options in my personal order of preference:
 1. put resources behind the golang dynamic linking upstream bug and fix it
 2. fix gccgo for the juju use case and/or update gccgo to a new version if one exists
 3. allow golang into main with very strong wording that it is only for juju and that 3rd party developers are on their own

'1' is by far my preferred solution because it would end this once and for all. I don't like '3' and I think it will tarnish Ubuntu's reputation. If we go for '3', a condition of the MIR would be reviewing where we declare the lack of support (an idea I had would be outputting a string at the beginning or end of the compile). Other options may exist, but I know the foundations team looked into them and my understanding is that '1' and '2' are really the only choices.

[James Page (james-page)]

"Basically, the decision had been taken in Oakland last November that gccgo is the toolchain Ubuntu Engineering would support on the client and the foundations and security teams don't consider gc supportable from a distro standpoint due to the static linking issue."

Ubuntu Server also took the same decision; we wanted a single toolchain to work across all target architectures and gccgo was the only option that could provide this; however after alot of work to a) get everything functional on gccgo and b) alot of testing including at scale, the performance of gccgo was just not at the same level as gc; The decision to prefer gc for architectures where it was supported was made based on this process. We have to use gccgo on ppc64el and arm64 right now as this is still the only option.

I appreciate that the static linking feature of gc does not fit with the distribution model generally; I'd encourage people to read the MIR in detail - specifically the way that juju server binaries are distributed which is also different as I want all interested parties/stakeholders to understand the full facts of what we are proposing for main inclusion.

[James Page (james-page)]

Jamie

Reading you comments in #16, it sounds like option 3) (statically linking with golang but just for juju-core) is a no-go; I don't believe that options 1) or 2) can be implemented for 14.04 so I think that means that juju-core is effectively blocked from main entry for this release?

It would be good to get a clear statement from both the foundations and security team in the context of 14.04.

[Adam Conrad (adconrad)]

"Upstream released jujud binaries are/will be distributed officially via simplestreams using a documented build process (details TBC)."

I've said it before, and I'll reiterate, this is fundamentally broken. A package in the archive shouldn't have have of its binaries not in the archive. This *must* be a solvable problem.

If the problem is that the package can't be BUILT in the archive, then this isn't remotely suitable for main. Otherwise, I don't see what the blocker is at all. Just package up those binaries, and done.

What fundamental flaw in the process is being hidden by shipping binaries outside the archive? Does the build system pull random deps from the internet, does it pull prebuilt objects from the internet, sans source code (again, absolutely unacceptable for main).

[James Page (james-page)]

@Adam

The jujud binary that is distributed via simplestreams can be built in the archive - its currently done in PPA for older Ubuntu releases as it requires a newer version of golang than we have in 12.04 - but for 14.04 I think the binary is actually picked from the packages in the archive.

I'll let one of the juju-core team respond on why the binary is distributed this way.

[Mark Ramm (mark-ramm)]

@adam

We *can* build and include tools binaries in the package. And in fact for many tools, we extract them from the builds, and upload them to a central distribution point (which uses the same toolchain as the ubuntu cloud images catalog -- simplestreams.

But, we don't distribute the tools binaries via ubuntu packages because they aren't installed on the a juju client user's machine. So we aren't pulling down binaries to extend what we package on the local machine -- we are pulling down binaries on the server side that the local juju client talks too.

We MUST distribute them through another mechanism because they will need to be chosen at workload deployment time based on whatever architecture, series, juju client version, and OS combination that is being targeted when that server is deployed. The key here is multi-OS support, we need to be able to support other unix and non-unix OS's, and we want one, standard code path for everything.

The local juju client package is not the right place for tools. This has nothing to do with hiding anything, and our prefered mechanism is to create the binaries in the archive -- where we don't we create them in PPA's now, and we will document a secure process for building them for non Ubuntu OS's as we start officially supporting those OS's next cycle.

We use simplestreams because we already have code that uses simplestreams to select the right architecture, series, and version for cloud images -- so we are re-using that same functionality to allow us to fulfill our multi-platform mandate in a sane way.

[Jamie Strandboge (jdstrand)]

I know a lot of people are looking at this bug and just wanted to follow up briefly to say that I'm working through some investigations and will have a response soon.

[Adam Conrad (adconrad)]

@Mark

So, if we can build them with the packages, what's stopping us from having a package that includes the bits, and even depends on the right things to set up a simplestreams provider that people can use on their closed networks? Sure, that won't have ALL the binaries for all supported platforms available, without a source to grab those from, but it would keep it self-contained for the simple use-case.

I think you'd agree that the obvious and simple usecase isn't "I installed juju-core on my Ubuntu desktop so I can rollout charms on OSX and Solaris".

[Mark Ramm (mark-ramm)]

@adam

> I think you'd agree that the obvious and simple usecase isn't "I
> installed juju-core on my Ubuntu desktop so I can rollout charms on OSX
> and Solaris".

Don't forget it will not support: old Ubuntu versions, Arm64, or power,
other versions of Linux, Windows, or anything but the series that the
package belongs to. I think we can all agree that a Trusty desktop and
Precise database server is a pretty common situation, and the combination
of all the things that won't work is definitely common enough to make it a
real issue.

> So, if we can build them with the packages, what's stopping us from
> having a package that includes the bits, and even depends on the right
> things to set up a simplestreams provider that people can use on their
> closed networks?

We certainly *can* do that. I have no objection to it in principle.

But, before we go down the path of "what's stopping us," Let's take a look
at the situation now:

The obvious and simple use case is that I'm using Amazon, or Azure, Joyent,
or HP Cloud. In those cases the tools are pre-published to a cloud local
"bucket" and it would slow things down and create pain for the user if
binaries had to be copied over from the local disk into the cloud. To top
it off, the jujud binary isn't used locally (except of course when you are
deploying charms locally) so having it on local disk is just waste in those
cases.

Furthermore, we need tools to be published to all the major clouds *before*
the matching client lands in Ubuntu, because a new clients can require
matching tools to bootstrap a new environment. (We do however maintain and
stringently test backwards compatibility with already bootstrapped
environments).

We *have to* publish tools in simplestreams. We *can* put them in the
package too -- as a limited and broken fallback mechanism that doesn't
support multiple archs, doesn't support multiple series, doesn't support
multiple OS's.

My question is, if I take folks away from current projects, and have them
update the packaging so that the tools you mention are there, what exactly
does that buy us? I'm happy to do it, but I would like to know why exactly
you want it, and what benifit it provides to our users.

Another idea we had was to build tools for all supported series, OS's and
arch's and put them in a single package, with the bits you need to push
things up in a simplestreams location for your closed network. But our
belief was that such a package would never be supported, particularly since
the binaries in question won't be run on the local machine anyway, and are
likely to just be a waste of disk space.

We've done a lot of thinking on this, and we have *tried* to figure out how
to use ubuntu packages to distribute tools -- and fundamentally
simplestreams is a better fit for the needs of a multi-os, multi-arch,
multi-series orchestration tool. And we already force users to trust
simplestreams to get Ubuntu images, so we're not adding *another*
mechanism, just re-using one that already exists and is quite widely used.

--Mark

On Wed, Mar 26, 2014 at 5:54 PM, Adam Conrad <[e-mail]> wrote:

> @Mark
>
> So, if we can build them with the packages, what's stoppi...

[Martin Pitt (pitti)]

> I think we can all agree that a Trusty desktop and Precise database server is a pretty common situation, and the combination
of all the things that won't work is definitely common enough to make it a real issue.

Of course. How come that mixing different Ubuntu releases worked in the previous python version? You said you are testing backwards compatibility, so why would that break in a package based approach?

Traditionally the Tech board has nacked everything in main which pulls code from third-party sources, i. e. "installer packages". Packages in main must not enable any third-party PPA, pull code or binaries from an upstream site and run it, and so on. The notable (and blessed) exception is flashplugin-installer, which is in multiverse for that reason. We do that for a good reason: There is an established trust level in Ubuntu packages. They have stability promise and defined procedures for post-release maintenance (security and bug fix updates with corresponding verification mechanisms), have a cryptographically secure trust path, they have a defined and well-working mirroring system around the world, there's well-known tools for local caching/mirroring, we can build installer images with them, and so on.

All of this would break down if we don't actually ship a binary package for juju clients which gets installed into ubuntu guest images. (Of course the repeatedly discussed immaturity of golang wrt dynamic linking and language changes also play a big role here). If you want to go down that route, I think you should go the full way and not pretend that we have and support Ubuntu binaries at all, and just always download the juju bits from simplestreams. With that you can support the same version on all Ubuntu releases and other OSes, but of course you have to introduce your own QA mechanisms, trust path to the binararies you download, options for local mirroring, and so on. So that comes with a big price attached, but it seems that's the direction you want to go to?

(Caveat: I have no idea what simplestreams is and how it works; the description on https://launchpad.net/simplestreams isn't very enlightening, but it sounds like you want to use it as a kind of package distribution system not unlike pip?)

[Adam Conrad (adconrad)]

I'm still pretty confused here on the Ubuntu usecase (let's ignore other OSes, I realise that's a curiously different issue).

1) I run juju locally and want jujud installed on a bunch of cloud VMs.
2) Some magic happens (which, frankly, I don't care about) that gets jujud from some random place into the filesystem on my VM.

Why is (2) not "apt-get install jujud" in the VM?

[Jamie Strandboge (jdstrand)]

Since others have been very capably discussing the issues surrounding "installer packages", I won't add much to that conversation except to make the observation that Go follows an established model for building projects with other's code (eg, ruby gems, python pip, etc). There is nothing wrong with this and I have no problem with developers leveraging these tools for their own projects since it is something that they actively opt in to. The problem comes when an "installer package" that comes from the archive wraps all this up for the user and pulls down code that is isn't verified or maintained by the distribution. If that "installer package" is in main, who is responsible for the authenticity of the downloaded software or for its maintenance?

So, putting the installer package issue aside, juju-core is the first Go software to pursue main inclusion and those responsible for maintenance of the Ubuntu archive realize that we need to be careful with how we proceed to make sure that we set the proper precedents and go down a sustainable path that works for everyone. I'd like to give my perspective on Go in Ubuntu to try to avoid an impasse.

Go is marketed as an open source programming language that makes it easy to build simple, reliable, and efficient software. People are excited about it and its clear that we want to support Go in Ubuntu. Interesting software is being written in Go, whether that is juju, scopes, click apps and more. The Go community wants to use golang-gc over golang-gccgo and I recognize that viewpoint.

Conversations surrounding Go have been challenging because Go was not designed with traditional OS distribution methods in mind (it statically links its runtime[1], uses remote code imports and encourages embedding code copies), yet we are trying to leverage Go using traditional distibution methods (ie, including Go software in the Ubuntu archive with Canonical support). If we take a step back, I think we have a disconnect where the Go developers may not be fully considering the problems of the Go model with regard to Canonical support while at the same time the traditional OS developers (ie, the ones responsible for the archive and its support) may not fully appreciate the needs of the Go community.

Go's model of statically compiling software works fine for developers and administrators who are responsible for supporting their software and I have no objections with providing the tools to make Go development great on Ubuntu. I believe the developer model works mostly ok with click packages because click is about empowering developers to deliver their software in a manner that is much less dependent on the OS. Go developers can develop using standard Go techniques then package as click and things are mostly fine. That said, I challenge the proponents of Go in Ubuntu to consider how we can have a better developer story for people developing on Ubuntu-- namely, if Ubuntu provides the Go runtime and compiler that developers then use to statically compile their apps, what can we do to alert developers that they (or someone) should recompile when we update our runtime for a security update. While we could probably get away with ...

[Jamie Strandboge (jdstrand)]

I wrote this before:

"The foundations and security team's stance is clear: if we ship something in Ubuntu in main, we need to be responsible for it and make sure people can get their updates. Moving forward, I see several options in my personal order of preference:
 1. put resources behind the golang dynamic linking upstream bug and fix it
 2. fix gccgo for the juju use case and/or update gccgo to a new version if one exists
 3. allow golang into main with very strong wording that it is only for juju and that 3rd party developers are on their own

'1' is by far my preferred solution because it would end this once and for all. I don't like '3' and I think it will tarnish Ubuntu's reputation. If we go for '3', a condition of the MIR would be reviewing where we declare the lack of support (an idea I had would be outputting a string at the beginning or end of the compile). Other options may exist, but I know the foundations team looked into them and my understanding is that '1' and '2' are really the only choices.
"

In light of my comment #27, I still consider '2' most correct and '1' is interesting but I don't think either is a requirement anymore so long as we define sane embedding policies (ie, don't allow it) and agree that we can provide updates in a manner resembling what I described in comment #27.

I'll let Seth comment on the security review for juju-core. Others have commented on the "installer package" issue.

Assuming those issues are addressed, I have this to say:
* juju: conditional ACK provided we pull out the embedded copies and push them into golang-*-dev packages. If this is not feasible for 14.04, we may be able to defer this to 14.10 (after all, juju will be the only Go package in main so it doesn't really matter where the libraries are for one package)
* golang: conditional ACK provided packaging policy, support procedures and MIR standards conversations are started (I don't expect these to be resolved by 14.04)

[Steve Langasek (vorlon)]

> * We figure out how to have a reasonable support story using golang-go. One
> idea is that we could consider automatically performing no-change uploads to
> -proposed with some bug automation if we update the runtime in an SRU/security
> update. All packages in main are supposed to have a team subscribed to them,
> so that team would be responsible for verifying the package in -proposed.
> This seems to be in the spirit of Go development-- teams choosing to use Go
> are responsible for recompiling and retesting and a team's choice of Go will
> have to consider this cost.

No-change uploads in response to a security update in a depended-on go library package addresses the problem of making sure the security updates happen, but it's still a suboptimal delivery method for those security updates because of the download size. Instead of pushing an update for just the library with the security fix, you're pushing the update for that package plus all its reverse-dependencies, which is made all the worse by the fact that each of those revdeps is statically linked (==larger). We might be able to make this work for juju in the short term, but it doesn't scale particularly well.

> If we do this with golang-gc (gccgo would follow established update procedures),
> then right away if there is a security update or SRU in golang-foo-dev, we can
> do 'reverse-depends -b golang-foo-dev' to see what needs no change rebuilds.

If we were to implement this at all, we should leverage the Build-Using field as defined in Debian policy.

> Developers may of course choose to use gccgo, but my current thinking is that
> based on various conversations with Go developers, efforts to improve
> gccgo might be better spent making golang-go supportable and this necessarily
> means stretching our existing policies and processes.

My biggest concern here is that making golang-go genuinely supportable in the distro context means supporting dynamic linking, and the Go upstream community appears to be quite hostile to the principle of dynamic linking. So I'm not sure this is actually the path of least resistance - unless you are suggesting that we compromise our standards for main over the long term by doing the reverse-build-dep rebuilds you described.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gustavo Niemeyer (niemeyer)]

We've had extensive conversations on this topic elsewhere, and these were pretty much entirely covered in Jamie's comment #27, which does an excellent job describing the various perspectives for the same problems. Thanks for that Jamie.

Just a couple of points that might be useful to add:

[Jamie]
> If we do this with golang-gc (gccgo would follow established update procedures),
> then right away if there is a security update or SRU in golang-foo-dev, we can
> do 'reverse-depends -b golang-foo-dev' to see what needs no change rebuilds.

As an obvious point yet perhaps worth raising, a bug in a library doesn't necessarily mean everything has to be rebuilt.

[Steve]
> My biggest concern here is that making golang-go genuinely supportable in the distro context means
> supporting dynamic linking, and the Go upstream community appears to be quite hostile to the
> principle of dynamic linking.

That sounds like an overstatement. It is true that the Go community appreciates static linkage, and some members have public sayings about how dynamic linkage has its own issues, neither the Go community nor the Go core development team (most important in this case) is not hostile to dynamic linking.

Here is evidence showing progress rather than hostility:

https://code.google.com/p/go/issues/detail?id=256

http://code.google.com/p/go/source/detail?r=885321ad387328c16c6f69fb04b12ac69b69b691
http://code.google.com/p/go/source/detail?r=c9e8491bbfcee7a9c05934f8be0718bccbf29aec
http://code.google.com/p/go/source/detail?r=98034d036d03213807879975629172945169c7c8
http://code.google.com/p/go/source/detail?r=1eadf11dd1b7b19d4857681363553c2cfd2ad47d

[Gustavo Niemeyer (niemeyer)]

Sorry, it's late here..

> neither the Go community nor the Go core development team (most important in this case) is not hostile to dynamic linking.

This should read:

> note that neither the Go community nor the Go core development team (most important in this case) are hostile to dynamic linking.

[Jamie Strandboge (jdstrand)]

From Gustavo:

"Just a couple of points that might be useful to add:

[Jamie]
> If we do this with golang-gc (gccgo would follow established update procedures),
> then right away if there is a security update or SRU in golang-foo-dev, we can
> do 'reverse-depends -b golang-foo-dev' to see what needs no change rebuilds.

As an obvious point yet perhaps worth raising, a bug in a library doesn't necessarily mean everything has to be rebuilt."

Right, I tried to mention this when I said "but long term, perhaps we could figure out how to declare what changed in the update and have the no change auto builds mechanism detect what needs to be built based on that". I was trying to convey that even in the very nearest of short term, we can just rebuild everything, and we can figure out how to be smarter as we go.

[Jamie Strandboge (jdstrand)]

"No-change uploads in response to a security update in a depended-on go library package addresses the problem of making sure the security updates happen, but it's still a suboptimal delivery method for those security updates because of the download size. Instead of pushing an update for just the library with the security fix, you're pushing the update for that package plus all its reverse-dependencies, which is made all the worse by the fact that each of those revdeps is statically linked (==larger). We might be able to make this work for juju in the short term, but it doesn't scale particularly well."

I agree and mentioned this in my comment, which is why I feel gccgo is the most correct solution (or golang-go with dynamic linking support). However, I don't feel the download size is itself a blocker. We can perform uploads for everything at first, figure out how to be smarter/more selective later and along the way work with upstream on dynamic linking if that makes sense. In the meantime, developers wanting to target the phone or environments with potentially aggressive data restrictions, etc should carefully consider the choice of Go for their projects since there is a download cost.

[Mark Ramm (mark-ramm)]

@jamie

"However, I don't feel the download size is itself a blocker. We can perform uploads for everything at first, figure out how to be smarter/more selective later and along the way work with upstream on dynamic linking if that makes sense."

I think that is particularly true in *this* case where we are talking just about Juju Core. Of course as a standard policy, for a future where there may be many go applications in the distro, I think we really do want either golang-go or gcc-go with dynamic linking to be moved into a supportable state. And I also agree that we should not confuse the current case (1 app) with the future.

[Mark Ramm (mark-ramm)]

@gustavo

I think it is right that there are many people in the go community who would welcome dynamic linking in golang-go, but I also think that if we want to have it, we need to do the work to add it there. Now that we have to have Arm64 and Power, if we are going to be investing in improving a toolchain for Go, I'm not exactly sure where that dev effort should go -- improving, fixing, and making GCC a viable option for us, or doing the dynamic linking in upstream go, as well as figuring out an alternative solution for architectures not supported by golango-go. What are your thoughts on the matter?

[Mark Ramm (mark-ramm)]

@martin

"Traditionally the Tech board has nacked everything in main which pulls code from third-party sources, i. e. "installer packages". Packages in main must not enable any third-party PPA, pull code or binaries from an upstream site and run it, and so on."

I think a key point here is that the juju package does not generally install or pull down binaries from anywhere to your machine. It does instruct the cloud installation of a server to use a specific ubuntu image from simplestreams and a specific jujud binary (also from simplestreams) on the remote host.

"(Caveat: I have no idea what simplestreams is and how it works; the description on https://launchpad.net/simplestreams isn't very enlightening, but it sounds like you want to use it as a kind of package distribution system not unlike pip?)"

Simplestreams is a tool the server team created to help us catalog, sign, and distribute "cloud images" which are Ubuntu OS images, which can be generic, or customized to run on a specific cloud. The server that gets launched in the cloud when you use "juju bootstrap" picks a cloud image from simplestreams, verifies it's cryptographic signature, and starts a machine using it, we then grab the appropriate juju binary from simplestreams and install it (again on the remote server). So, juju isn't creating a need to trust simplestreams for the juju binary -- it already must be trusted for cloud images. And we're not creating our own system of packaging for jujud binaries, we're just piggiybacking on the way we distribute Ubuntu images in a cloud context.

There is a small caveat: juju does have a "local provider" feature that sets up lxc containers and runs the jujud binary there. The local provider is designed to simulate a full cloud environment in containers on your local system, and when you do that we do the same thing as I mentioned in doing on the remote side above, we use simplestreams to select the right cloud image, and juju tools binary. That is the only case in which the juju client would download a binary from simplestreams and run it locally, and in that case it is downloading both the cloud image, and the juju binary. So, fixing the juju binary doesn't fix that -- we're still grabbing a binary blob from simplestreams and executing it locally -- the cloud image itself.

[Steve Langasek (vorlon)]

> Having seen these past issues, and issues with another not well
> maintained language stack in main for the last two years (ruby), I'm
> asking for explicit confirmation that the teams who are supposed to
> maintain golang do have the required resources to do so. This will
> not only include the maintenance of the golang package, but also the
 >maintenance of go libraries in main, and an eye to other go library
> packages in the archive.

Per comment #67, the Foundations team is assuming responsibility for the maintenance of the golang toolchain, and will work with the juju team to ensure this is properly resourced.

The go libraries that are being brought into main as dependencies of juju and lxd will be the responsibility of those respective teams (which is the status quo).

[Jamie Strandboge (jdstrand)]

@doko:
"While not required, it is good to see that shared library support is
being worked on, and targeted for the upcoming 1.6. release." It is only not required for 15.10, it is a condition of this MIR (that the juju and foundations teams already agreed to) that we gain shared library support by default in the archive for 16.04 if possible.

The juju team still reserves the right to statically link for juju-core in 16.04 if shared library decreases stability for the project for the LTS (in which case, they'll pursue shared library support for juju-core in 16.10). This has all been discussed with the security team.

[Jamie Strandboge (jdstrand)]

@doko
"I'm still sceptical about how to track third party libaries, i.e. if
they are included as a dependency, or built form the vendorized
copies. dh-golang tries to do that, and sets the "Built-Using"
attribute for the binary packages. If juju-core doesn't want, or cannot use dh-golang, that should be done directly in the packaging. Is this a solved problem how to select which copy to use, or does this still need investigation?"

The security team has a mechanism for tracking embedded copies and while I would've preferred to see many of the embedded copies moved out to golang-*-dev packages, for 15.10 the security team agreed to the juju team updating juju to use the golang-*-dev packages that currently exist in the archive. I'll be filing a separate bug for 16.04 to pull out the others. Furthermore, We have developed in response to this MIR a process and tooling for tracking Built-Using. The upcoming https://code.launchpad.net/~james-page/ubuntu/wily/juju-core/mir-fixes/+merge/274052 uses Built-Using and dh-golang, so juju-core is 'ok' on this front.

"jujud is still linked statically. Is this needed for the juju-core
copy in the archive?"

As mentioned in comment 119, this is ok for 15.10.

This should remain 'Incomplete' and can be marked 'Fix Committed' once https://code.launchpad.net/~james-page/ubuntu/wily/juju-core/mir-fixes/+merge/274052 is uploaded.

[Jamie Strandboge (jdstrand)]

Based on Steve's comment in 118, I'm marking golang as Fix Committed.

[Jamie Strandboge (jdstrand)]

@slangasek: I agree on your point regarding juju-mongodb. It is fine for support and I filed bug 1506989 for perftools and bug 1506990 for architectures.

Between that, the security team ACK and doko's review, marking as Fix Committed.

[Jamie Strandboge (jdstrand)]

Regarding the golang-juju-loggo rename, I think it is too late and a minor issue. I filed bug 1506993 so this can happen next cycle. As such, marking as Fix Committed.

[Jamie Strandboge (jdstrand)]

Ok, this is a very complicated MIR with so many comments it is difficult to track. I went through the bug and came up with the following list of remaining items. If I missed something, please comment. Hopefully, no one has to look before this comment on if everything is done. :)

* security team commitments: develop a process for the list of packages to notify the juju team on when there is a security update. This is not a precondition of this MIR, but a request of the juju team
* golang-go.crypto
 - needs a bug subscriber
* golang-gocheck
 - can be dropped when bug #1504821 is fixed (comment #82)
* golang-goyaml
 - can be dropped when bug #1504821 is fixed (comment #82)
* golang-x-text
 - ftbfs (comment 115)
 - needs a bug subscriber
* juju-core
 - what is the status of
   https://code.launchpad.net/~james-page/ubuntu/wily/juju-core/mir-fixes/+merge/274052 ? jamespage said it is 'pending testing by the juju qa team'.
* dep8 question (comments 86, 93, 99, 100, 101, 117)
 - pitti's comment in #99 needs to be done. It could be done as an SRU. If that is the approach, please file a bug on this and comment here

Basically, need to merges to land in juju-core, fix the test in golang-x-text, bug suscribers and someone to do the dep8 work.

[Jamie Strandboge (jdstrand)]

"* security team commitments: develop a process for the list of packages to notify the juju team on when there is a security update. This is not a precondition of this MIR, but a request of the juju team"

FYI, we have this list and have the tooling update in our backlog.

[Steve Langasek (vorlon)]

golang promoted.

$ change-override -c main -S golang
Override component to main
golang 2:1.5.1-0ubuntu2 in wily: universe/devel -> main
golang 2:1.5.1-0ubuntu2 in wily amd64: universe/devel/optional/100% -> main
golang 2:1.5.1-0ubuntu2 in wily arm64: universe/devel/optional/100% -> main
golang 2:1.5.1-0ubuntu2 in wily armhf: universe/devel/optional/100% -> main
golang 2:1.5.1-0ubuntu2 in wily i386: universe/devel/optional/100% -> main
golang 2:1.5.1-0ubuntu2 in wily powerpc: universe/devel/optional/100% -> main
golang 2:1.5.1-0ubuntu2 in wily ppc64el: universe/devel/optional/100% -> main
golang-doc 2:1.5.1-0ubuntu2 in wily amd64: universe/doc/optional/100% -> main
golang-doc 2:1.5.1-0ubuntu2 in wily arm64: universe/doc/optional/100% -> main
golang-doc 2:1.5.1-0ubuntu2 in wily armhf: universe/doc/optional/100% -> main
golang-doc 2:1.5.1-0ubuntu2 in wily i386: universe/doc/optional/100% -> main
golang-doc 2:1.5.1-0ubuntu2 in wily powerpc: universe/doc/optional/100% -> main
golang-doc 2:1.5.1-0ubuntu2 in wily ppc64el: universe/doc/optional/100% -> main
golang-go 2:1.5.1-0ubuntu2 in wily amd64: universe/devel/optional/100% -> main
golang-go 2:1.5.1-0ubuntu2 in wily arm64: universe/devel/optional/100% -> main
golang-go 2:1.5.1-0ubuntu2 in wily armhf: universe/devel/optional/100% -> main
golang-go 2:1.5.1-0ubuntu2 in wily i386: universe/devel/optional/100% -> main
golang-go 2:1.5.1-0ubuntu2 in wily powerpc: universe/devel/optional/100% -> main
golang-go 2:1.5.1-0ubuntu2 in wily ppc64el: universe/devel/optional/100% -> main
golang-src 2:1.5.1-0ubuntu2 in wily amd64: universe/devel/optional/100% -> main
golang-src 2:1.5.1-0ubuntu2 in wily arm64: universe/devel/optional/100% -> main
golang-src 2:1.5.1-0ubuntu2 in wily armhf: universe/devel/optional/100% -> main
golang-src 2:1.5.1-0ubuntu2 in wily i386: universe/devel/optional/100% -> main
golang-src 2:1.5.1-0ubuntu2 in wily powerpc: universe/devel/optional/100% -> main
golang-src 2:1.5.1-0ubuntu2 in wily ppc64el: universe/devel/optional/100% -> main
Override [y|N]? y
25 publications overridden.

[Steve Langasek (vorlon)]

$ change-override -c main -S golang-check.v1
Override component to main
golang-check.v1 0.0+git20150729.11d3bc7-1 in wily: universe/devel -> main
golang-check.v1-dev 0.0+git20150729.11d3bc7-1 in wily amd64: universe/devel/extra/100% -> main
golang-check.v1-dev 0.0+git20150729.11d3bc7-1 in wily arm64: universe/devel/extra/100% -> main
golang-check.v1-dev 0.0+git20150729.11d3bc7-1 in wily armhf: universe/devel/extra/100% -> main
golang-check.v1-dev 0.0+git20150729.11d3bc7-1 in wily i386: universe/devel/extra/100% -> main
golang-check.v1-dev 0.0+git20150729.11d3bc7-1 in wily powerpc: universe/devel/extra/100% -> main
golang-check.v1-dev 0.0+git20150729.11d3bc7-1 in wily ppc64el: universe/devel/extra/100% -> main
Override [y|N]? y
7 publications overridden.

[Martin Packman (gz)]

> * golang-go.crypto
> - needs a bug subscriber

Looks like it's ~ubuntu-server now.

> * golang-gocheck
> - can be dropped when bug #1504821 is fixed (comment #82)
> * golang-goyaml
> - can be dropped when bug #1504821 is fixed (comment #82)

To clarify, I am making these changes on master. Backporting the code changes required to change the dependency for 1.24 carries considerable risk to application-level api compatibility, as yaml.v2 changes some serialisation behaviour. I would prefer if for 1.24 we relied on the bundled yaml.v1 package that been consistently used in testing through this cycle.

> * golang-x-text
> - ftbfs (comment 115)
> - needs a bug subscriber

This package is not a dependency of juju. It's used by golang.org/x/net/html/charset only, so is just pulled in as a side effect of taking the debian package. My preference would be to drop the juju packaging dependency on golang-go.net-dev for 1.24 instead.

> * juju-core
> - what is the status of
> https://code.launchpad.net/~james-page/ubuntu/wily/juju-core/mir-fixes/+merge/274052 ? jamespage said it is 'pending testing by the juju qa team'.

We have manually tested the packaging change, but it is not yet included in our automated testing and release process. We have work in progress to break out our series-independent packaging branch. That said, the merge should not be considered blocked on our verification.

> * dep8 question (comments 86, 93, 99, 100, 101, 117)
> - pitti's comment in #99 needs to be done. It could be done as an SRU. If that is the approach, please file a bug on this and comment here

I would appreciate if someone who has a clear understanding for the work pitti is requesting (such as pitti himself) could file the bug and subscribe me. We'll happily update our packaging to use any such new mechanism if it's provided.

[Steve Langasek (vorlon)]

$ change-override -c main -S juju-mongodb -y
Override component to main
juju-mongodb 2.4.10-0ubuntu4 in wily: universe/database -> main
juju-mongodb 2.4.10-0ubuntu4 in wily amd64: universe/database/optional/100% -> main
juju-mongodb 2.4.10-0ubuntu4 in wily arm64: universe/database/optional/100% -> main
juju-mongodb 2.4.10-0ubuntu4 in wily armhf: universe/database/optional/100% -> main
juju-mongodb 2.4.10-0ubuntu4 in wily i386: universe/database/optional/100% -> main
juju-mongodb 2.4.10-0ubuntu4 in wily ppc64el: universe/database/optional/100% -> main
6 publications overridden.

[Jamie Strandboge (jdstrand)]

Per comment#128, marking golang-go.crypto Fix Committed.

[Jamie Strandboge (jdstrand)]

Per comment #128, marking golang-gocheck and golang-goyaml as 'Won't Fix'. Go ahead and use the embedded copy for 15.10 but please ensure the transition for these is completed for 16.04.

[Jamie Strandboge (jdstrand)]

"This package is not a dependency of juju. It's used by golang.org/x/net/html/charset only, so is just pulled in as a side effect of taking the debian package. My preference would be to drop the juju packaging dependency on golang-go.net-dev for 1.24 instead."

Are you saying you want to use the embedded code copy? Has anyone looked at the testsuite issue to fix it? Embedded code copies should be avoided at all costs per MIR guidelines -- we are making huge concessions for the juju and lxd teams already, can someone take a look at this ftbfs and report back?

[Jamie Strandboge (jdstrand)]

"We have manually tested the packaging change, but it is not yet included in our automated testing and release process. We have work in progress to break out our series-independent packaging branch. That said, the merge should not be considered blocked on our verification."

IIUC, this means that this can be uploaded to archive. Please do so ASAP and then juju-core can be marked Fix Committed.

[Jamie Strandboge (jdstrand)]

"I would appreciate if someone who has a clear understanding for the work pitti is requesting (such as pitti himself) could file the bug and subscribe me. We'll happily update our packaging to use any such new mechanism if it's provided."

I'll see if I can find someone to help you.

[Matthias Klose (doko)]

@steve

"Per comment #67, the Foundations team is assuming responsibility for the maintenance of the golang toolchain, and will work with the juju team to ensure this is properly resourced."

no, comment #67 doesn't say this. It only talks about adoption of shared library support and golang 1.6. The phrase "I believe ..." is not a statement for commitment. if comment #118 adds new information, fine, however just adding this information without any chance to check for validity and then just promoting the package isn't exactly following any MIR guidelines.

[Martin Pitt (pitti)]

Martin Packman [2015-10-16 22:45 -0000]:
> > * dep8 question (comments 86, 93, 99, 100, 101, 117)
> > - pitti's comment in #99 needs to be done. It could be done as an SRU. If that is the approach, please file a bug on this and comment here
>
> I would appreciate if someone who has a clear understanding for the work
> pitti is requesting (such as pitti himself) could file the bug and
> subscribe me. We'll happily update our packaging to use any such new
> mechanism if it's provided.

It won't actually go into any particular Go package, but into
autodep8. The main thing that this needs is to come up with an
idea/strategy how a group of go libraries/packages can be tested in a
generic fashion. Based on my loose comprehension of this bug the
MIR/security's primary concern is to ensure that all reverse build
dependencies of a new Go package still build. A mere package rebuild
test is a trivial thing to synthesize, but maybe there's some other
useful things that can be done, such as running tests (unless the
package build already does that). If that's sufficient for now, we
merely need an algorithm to detect a go library as such.

You can look at /usr/share/autodep8/support/ (detect and generate)
scripts for examples like it's done for Perl.

[Martin Pitt (pitti)]

As per Jamie's request, I created bug 1507470 as a skeleton for adding generic autopkgtesting of Go libs/packages. Can someone who is familiar with Go packages please assign themselves and provide the details? Thanks!

[Jamie Strandboge (jdstrand)]

@pitti

Thanks for creating the bug. IMO the bare minimum and the first step is simply to rebuild (many of these golang packages do have in-build testsuites too). More stuff could then be added later.

[Martin Packman (gz)]

"Are you saying you want to use the embedded code copy? Has anyone looked at the testsuite issue to fix it? Embedded code copies should be avoided at all costs per MIR guidelines -- we are making huge concessions for the juju and lxd teams already, can someone take a look at this ftbfs and report back?"

Short version, these extended-standard library packages are in practice pretty closely tied to the golang minor version.

Debian currently has go 1.4 and the go-x-text package is from May, before the go 1.5 release:

<https://golang.org/doc/devel/release.html>

In go 1.5 the unicode package, which includes generation of various data tables, was updated to use Unicode 8.0.0 - which amongst other changes introduces the Ahom script:

<http://unicode.org/versions/Unicode8.0.0/>

This means the test in golang.org/x/text which uses the data from the standard library unicode package now finds its own data out of sync with the system golang on wily. Specifically, the new character U+11730 AHOM DIGIT ZERO should be numerically equal to 0, but is not. Obviously there are other failures as well.

There's an easy fix for wily, which is just update the package to use a current revision of golang.org/x/text for go 1.5 compatibility. I've proposed a debian/experimental branch that does that:

<http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20151019/001878.html>

(Minor wrinkle, still a test failure even with the latest code, I patched it in the packaging but presumably needs resolving upstream.)

Anyway, where this gets really fun is when we start considering backports of latest juju. None of these packages existed when trusty was released, and their current versions will generally be incompatible with go 1.2.1. We could pick out the revisions that worked for specific backport packaging, but won't have support upstream for security fixes to random older checkouts so won't really gain anything.

[Jamie Strandboge (jdstrand)]

@Martin Packman: can you get the fixed version of golang-x-text uploaded to wily?

As for backport packaging for current stables, like trusty, you are free to do whatever you want with those (following whatever archive processes you would normally follow). Ie, juju on trusty is not officially supported by the security team. Going forward, we agreed that the juju team would be allowed to update the non-juju golang-*-dev that it requires (provided other packages in the archive still work). I realize that doesn't solve everything, but those discussions can happen outside of this bug.

[James Page (james-page)]

Fixed version of golang-x-text uploaded to wily (fresh snapshot).

[James Page (james-page)]

Revised packaging for juju-core using -dev packages also uploaded (see linked branch for full details).

[James Page (james-page)]

golang-go.net-dev was renamed to golang-golang-x-net-dev; please can we promote the right source package and drop golang-go.net-dev from wily.

[James Page (james-page)]

golang-pretty and golang-text are showing in the dep chain for golang-github-bmizerany-assert - adding bug tasks

[James Page (james-page)]

>> golang-text <<

[Availability]
In universe

[Rationale]
Dependency for github-bmizerany-assert

[Security]
No security history

[Quality assurance]
Package builds OK and runs unit tests

[Dependencies]
All in main or covered by this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-server

>> golang-pretty <<

[Availability]
In universe

[Rationale]
Dependency for github-bmizerany-assert

[Security]
No security history

[Quality assurance]
Package builds OK and runs unit tests

[Dependencies]
All in main or covered by this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-server

[James Page (james-page)]

(neither of text or pretty executed unit tests - they now do - bugs submitted back to Debian).

[Martin Pitt (pitti)]

>golang-go.net-dev was renamed to golang-golang-x-net-dev; please can we promote the right source package and drop golang-go.net-dev from wily.

Ack, updating bug tasks. However, we can't remove golang-go.net-dev yet, as we still need the transitional package until 16.04 LTS. It can be removed during 16.10 development.

[Martin Pitt (pitti)]

Indeed the golang-go.net-dev transitional package is now built by the golang-golang-x-net-dev source, so the old source can indeed be removed:

Removing packages from wily:
 golang-go.net-dev 0.0+git20150226.3d87fd6-1 in wily
Comment: renamed to golang-golang-x-net-dev

[Jamie Strandboge (jdstrand)]

Remaining 15.10 issues fixed in juju-core 1.24.6-0ubuntu2.

[Jamie Strandboge (jdstrand)]

golang-x-text now builds fine. Marking Fix Committed.

[Jamie Strandboge (jdstrand)]

golang-pretty packaging looks fine. Testsuite enabled in the build. Builds on wily. Marking Fix Committed.

[Jamie Strandboge (jdstrand)]

golang-text packaging looks fine, testsuite enabled in the build, builds on wily. Marking Fix Committed.

[Jamie Strandboge (jdstrand)]

$ ./change-override -c main -t juju-core
Override component to main
juju-core 1.24.6-0ubuntu2 in wily: universe/devel -> main
Override [y|N]? y
1 publication overridden.

[Jamie Strandboge (jdstrand)]

juju-local was already in main, but juju-core is seeded and was not.

$ ./change-override -c main juju-core
Override component to main
juju-core 1.24.6-0ubuntu2 in wily amd64: universe/devel/extra/100% -> main
juju-core 1.24.6-0ubuntu2 in wily arm64: universe/devel/extra/100% -> main
juju-core 1.24.6-0ubuntu2 in wily armhf: universe/devel/extra/100% -> main
juju-core 1.24.6-0ubuntu2 in wily i386: universe/devel/extra/100% -> main
juju-core 1.24.6-0ubuntu2 in wily powerpc: universe/devel/extra/100% -> main
juju-core 1.24.6-0ubuntu2 in wily ppc64el: universe/devel/extra/100% -> main
Override [y|N]? y
6 publications overridden.

[Jamie Strandboge (jdstrand)]

$ ./change-override -c main -t golang-juju-loggo golang-github-bmizerany-assert golang-github-bmizerany-pat golang-go-dbus golang-golang-x-net-dev golang-pretty golang-text golang-x-text
Override component to main
golang-juju-loggo 0.0~git20150318-0ubuntu1 in wily: universe/devel -> main
golang-github-bmizerany-assert 0.0~git20120716-1 in wily: universe/misc -> main
golang-github-bmizerany-pat 0.0~git20140625-1 in wily: universe/misc -> main
golang-go-dbus 1~bzr20150203-0ubuntu1 in wily: universe/misc -> main
golang-golang-x-net-dev 0.0+git20150226.3d87fd6-3 in wily: universe/misc -> main
golang-pretty 0.0~git20130613-1ubuntu1 in wily: universe/misc -> main
golang-text 0.0~git20130502-1ubuntu1 in wily: universe/misc -> main
golang-x-text 0+git20151019.0fe7e68-0ubuntu1 in wily: universe/misc -> main
Override [y|N]? y
8 publications overridden.

$ ./change-override -c main golang-github-bmizerany-assert-dev golang-github-bmizerany-pat-dev golang-go-dbus-dev golang-go.net-dev golang-golang-x-net-dev golang-juju-loggo-dev golang-pretty-dev golang-text-dev golang-x-text-dev
Override component to main
golang-github-bmizerany-assert-dev 0.0~git20120716-1 in wily amd64: universe/devel/extra/100% -> main
golang-github-bmizerany-assert-dev 0.0~git20120716-1 in wily arm64: universe/devel/extra/100% -> main
golang-github-bmizerany-assert-dev 0.0~git20120716-1 in wily armhf: universe/devel/extra/100% -> main
golang-github-bmizerany-assert-dev 0.0~git20120716-1 in wily i386: universe/devel/extra/100% -> main
golang-github-bmizerany-assert-dev 0.0~git20120716-1 in wily powerpc: universe/devel/extra/100% -> main
golang-github-bmizerany-assert-dev 0.0~git20120716-1 in wily ppc64el: universe/devel/extra/100% -> main
golang-github-bmizerany-pat-dev 0.0~git20140625-1 in wily amd64: universe/devel/extra/100% -> main
golang-github-bmizerany-pat-dev 0.0~git20140625-1 in wily arm64: universe/devel/extra/100% -> main
golang-github-bmizerany-pat-dev 0.0~git20140625-1 in wily armhf: universe/devel/extra/100% -> main
golang-github-bmizerany-pat-dev 0.0~git20140625-1 in wily i386: universe/devel/extra/100% -> main
golang-github-bmizerany-pat-dev 0.0~git20140625-1 in wily powerpc: universe/devel/extra/100% -> main
golang-github-bmizerany-pat-dev 0.0~git20140625-1 in wily ppc64el: universe/devel/extra/100% -> main
golang-go-dbus-dev 1~bzr20150203-0ubuntu1 in wily amd64: universe/devel/extra/100% -> main
golang-go-dbus-dev 1~bzr20150203-0ubuntu1 in wily arm64: universe/devel/extra/100% -> main
golang-go-dbus-dev 1~bzr20150203-0ubuntu1 in wily armhf: universe/devel/extra/100% -> main
golang-go-dbus-dev 1~bzr20150203-0ubuntu1 in wily i386: universe/devel/extra/100% -> main
golang-go-dbus-dev 1~bzr20150203-0ubuntu1 in wily powerpc: universe/devel/extra/100% -> main
golang-go-dbus-dev 1~bzr20150203-0ubuntu1 in wily ppc64el: universe/devel/extra/100% -> main
golang-go.net-dev 0.0+git20150226.3d87fd6-3 in wily amd64: universe/devel/extra/100% -> main
golang-go.net-dev 0.0+git20150226.3d87fd6-3 in wily arm64: universe/devel/extra/100% -> main
golang-go.net-dev 0.0+git20150226.3d87fd6-3 in wily armhf: universe/devel/extra/100% -> main
golang-go.net-dev 0.0+git20150226.3d87fd6-3 i...

[Jamie Strandboge (jdstrand)]

golang-race-detector-runtime is a Recommends of golang. I looked at it-- packaging is fine, pulls in no new depends, builds fine and has a testsuite.

[Jamie Strandboge (jdstrand)]

$ ./change-override -c main -S golang-race-detector-runtime
Override component to main
golang-race-detector-runtime 0.0+svn229396-0ubuntu1 in wily: universe/devel -> main
golang-race-detector-runtime 0.0+svn229396-0ubuntu1 in wily amd64: universe/devel/extra/100% -> main
Override [y|N]? y
2 publications overridden.