[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.

[Mark Ramm (mark-ramm)]

@all

Given the timeline and the various other bits on our roadmap, I think main inclusion for juju core is *not* critical this cycle. We would rather get agreement, and get this done the right way than create last minute chaos for the release. But, it is critical that we sort this and the MRE out as cleanly and quickly as possible.

Juju is a key to our strategy of growing Ubuntu's presence in the server and cloud worlds, and we can't afford not to be united in our approach.

My understanding of the current state of the conversation is that we need to solve two major issues:

1) Package security update rules/processes for Go.
2) SimpleStreams/Tools not in the package issues

I think that we are making good progress on the first issue. It seems like there are both short and long term activities that need to happen, and which we can include in our various team plans for next cycle. We can get embedded libraries out, rebuild when needed, and simultaneously try to push forward the state of the art on either GCC go, or the state of dynamic linking on golang-go.

I am less sure about us being on a path towards consensus on the second item though... My belief is that the juju team is doing something completely sane given that they have a mandate to support multiple OS's, and a mandate to support cloud image distribution through simplestreams already. And I think that it is not at all fair to call juju a "installer package" since the external distribution of tools is mostly a "remote side" issue, where this juju client package is not installed at all.

Since we are dropping this MIR for this cycle, can we setup time to go through this issue across the teams, and get alignment after the release, but before the Juju cloud sprint at the end of April?

Also, if I'm missing any critical issues on which we have to have alignment, but don't, please raise them NOW rather than wait until the end of the next cycle -- so we can make sure we put aside time to deal with them properly this time.

[Martin Pitt (pitti)]

@Mark: Thanks for these clarifications. So as far as I understand, simplestreams is conceptually way above the juju packaging, as it just selects which built Ubuntu cloud image to fetch and install. So this doesn't seem related to the question of how to build and package juju itself.

These Ubuntu cloud images still need to be built somehow. We usually build all our images (desktop, server, cloud, phone) right our of our Ubuntu archive, so it seems for these this isn't the case as the juju bits of these images are pulled down separately from simplestreams. That's what I (and Adam, Jamie, etc.) object to. It should just use the binary packages instead. However, I realize that this is a much smaller impact than having to download the juju client from simplestreams locally (which is still the case for juju-local though).

I have no official saying in that matter as I left the Mir/release teams some time ago, but if we can get away with not having to officially support these golang-go builds and golang-go itself with its current limitations, I'm all for that :-)

[Steve Langasek (vorlon)]

On Sat, Mar 29, 2014 at 04:24:22AM -0000, Gustavo Niemeyer wrote:
> [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.

Ok, thanks for setting me straight on this.

On Mon, Mar 31, 2014 at 01:30:45PM -0000, Mark Ramm wrote:
> 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.

I agree with Martin; the fact that these binaries do not originate in the
Ubuntu archive, and are not subjected to the normal standards and procedures
for the Ubuntu archive, is very concerning.

Using simplestreams as the distribution method or not makes no difference to
me - but the actual software that's being distributed should be built using
Ubuntu best practices.

We've been turning a blind eye to this so long as the package has been in
universe. I don't think we want juju-core to go into main until jujud is also
brought "in house" in Ubuntu.

[Steve Langasek (vorlon)]

> Since we are dropping this MIR for this cycle, can we setup time to go
> through this issue across the teams, and get alignment after the
> release, but before the Juju cloud sprint at the end of April?

+1. Feel free to bring myself or Adam (or both) into this conversation.

[John A Meinel (jameinel)]

Actually, because juju-local only supports one architecture (your local machine), it does *not* download the jujud tools from a remote site, but uses the one on your local machine. (It should be put into the juju-local package, rather than being in the 'juju-core' package, but that is just shuffling the executables around.)

So I think even the local case is already matching what was expected.

The main reason the remote case doesn't just 'apt-get install jujud' on the machines we are starting up, is because that would lead to really out-of-date and fairly incompatible versions of jujud running on a heterogenous system. Having Trusty & Precise machines, would lead to a case where you would only have the jujud that was available on Precise (I'm not even sure if juju-1.0 was available there), mixed with the latest jujud (hopefully 2.0 in Trusty).

It would have been possible to follow the cloud-archive model, where we look up the base Ubuntu image in simplestreams, start an instance with that base image, have that image's first step install a custom archive where we keep compatible versions of the jujud binaries in an archive. However, that doesn't solve the multiple-architectures-that-aren't-Ubuntu case, and we already depend on image lookup.

I *really* feel like there is a clearcut win to separating what is "juju" the client CLI application that you would install on your desktop from "jujud" the server tools that get installed on the machines that are launched. I think "jujud" the binary should be in the juju-local package, and it would make lots of sense to keep "juju-local" in Universe (as it also allows juju-mongodb to stay in Universe, rsyslog-gnutls, cpu-checker, kvm and LXC support can all be brought in by the juju-local package, and *not* by the relatively small juju package.)

I personally think the most productive path forward for Go-in-Ubuntu would be to put effort into the gccgo toolchain, since it is the only one that is going to support PPC/Arm64 anyway. I do think it is a shame to not be using the tool that gets the most focus upstream, but it would fit better into the Ubuntu ecosystem. (We would likely still want to statically compile our jujud binaries, but as they can't really be distributed from the Ubuntu primary archive, I don't think that is particularly problematic.)

[John A Meinel (jameinel)]

...

> On Mon, Mar 31, 2014 at 01:30:45PM -0000, Mark Ramm wrote:
> > 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.
>
> I agree with Martin; the fact that these binaries do not originate in the
> Ubuntu archive, and are not subjected to the normal standards and
> procedures
> for the Ubuntu archive, is very concerning.
>
> Using simplestreams as the distribution method or not makes no difference
> to
> me - but the actual software that's being distributed should be built using
> Ubuntu best practices.
>
> We've been turning a blind eye to this so long as the package has been in
> universe. I don't think we want juju-core to go into main until jujud is
> also
> brought "in house" in Ubuntu.
>
>
>
> I'm pretty sure the jujud binaries are being built by the archive. At
least, ISTR that we had to wait for some things to get built into Trusty
before we could publish them. It may be that we switched to a PPA to
increase turn around time, but that isn't as relevant for what we would
publish as a stable release.

John
=:->

[Matthias Klose (doko)]

Not addressing the component / archive / PPA questions, but other things which I think are required.

 - Upstream gc only works on adding shared library support to their C compiler, afaics
   there is currently no work done building shared go libs.

   Adding this seems to be orthogonal, and even if you can't yet do this with gc, then
   you can start developing this with gcc.

   Questions to address are what to put into a shared library. Just a single Go package,
   or a bunch of packages? E.g. libgo.so as built from gccgo uses this approach. My feeling
   is that with a shared library for each go package we end up with hundreds of new
   libraries.

 - Start thinking how to package and build third libraries built by gc and gccgo. Sure
    Debian already does this, but completely ignores gccgo.

 - Merge our go tool gcc port upstream. Maybe we need a branch for Go 1.2 based
   compilers?

 - Stop bundling every source in juju-core.

[Seth Arnold (seth-arnold)]

I partially reviewed juju-core version 1.17.6-0ubuntu1 as checked into
trusty. This shouldn't be considered a full security audit; this review is
even more cursory than usual, since the MIR has been retracted for trusty.

So, here's the notes I've collected thus far in the hopes that they are
useful for the next MIR review:

- release-public-tools.sh doesn't validate downloaded packages

The jujud that is served up through simplestreams or cloud service
provider tools buckets is entirely unchecked against accidental or
malicious replacement. Please use apt-get download to retrieve packages,
it performs all the necessary package hash comparisons and signed package
list comparisons that are currently missing in the shell script.

- utils/trivial.go ShQuote() is broken

The quoting method used is broken -- some clever arrangement of ",
`, and $() will be able to execute unexpected commands. Part of why
the quoting method is broken is because the design of the tool is
trying to accomplish too many things at once. ShQuote() is being used
both for quoting a single argument and for parsing entire scripts. It
cannot be used for both tasks, and in fact trying to "quote" an entire
script is a mistake. It needs to be re-done to focus on a single
argument and use the method of quoting outlined by Florian Weimer at
http://www.openwall.com/lists/oss-security/2014/02/04/3

    The proper way (at least if your shell runs in a UTF-8 or ISO-8859
    locale) to escape shell arguments is to wrap them in '', after replacing
    embedded ' characters with the four character sequence '\''.

I'm pretty new to Go, but it feels like there's a nice opportunity to
use the type system to create a ShellScript type that can only be
constructed from static strings and properly quoted arguments -- and then
the various Run commands could be typed to only accept arguments of the
ShellScript type, to statically discover when a shell injection site may
have been missed.

- juju-backup shell script uses incorrect quoting method needlessly

Another case of trying to quote an entire shell script; the base64 trick
used elsewhere may be a better fit for what is attempted here.

- The local environment hardcodes use of 'sudo' to raise privileges

Some of the functions will execute 'sudo' if they weren't called with
sufficient privileges. I'd rather have operations clearly fail if
permissions are insufficient instead of trying to raise privileges
behind the scenes. If some installations have configured sudo, these
may be unwelcome or raise awkward questions or provide a very unfriendly
user experience.

Using 'sudo' in the units is fine, juju owns those. But sudo on the local
host may be different.

Thanks

[James Page (james-page)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/04/14 06:38, John A Meinel wrote:
> I *really* feel like there is a clearcut win to separating what is
> "juju" the client CLI application that you would install on your
> desktop from "jujud" the server tools that get installed on the
> machines that are launched. I think "jujud" the binary should be in
> the juju-local package, and it would make lots of sense to keep
> "juju-local" in Universe (as it also allows juju-mongodb to stay in
> Universe, rsyslog- gnutls, cpu-checker, kvm and LXC support can all
> be brought in by the juju-local package, and *not* by the
> relatively small juju package.)

I'm not sure this is clear-cut at-all - juju-mongodb + other deps are
used in Juju deployed services outside of the local provider and we
want to be able to provide support and security updates in these
environments as well - not just for the local provider.

- --
James Page
Ubuntu and Debian Developer
<email address hidden>
<email address hidden>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPodVAAoJEL/srsug59jDhYcP/RGY9JhW6lRVkfh3OLQAa4HV
ygCTDD6hi0S7xBYiRb5XEQ4n8pMPIjabtifBFesZdMo1QieYC4qeqs/s7yiJPro6
mACr6EE/kCNsCtbW+1mO+EXgz/vzXslHjVyIE/OKfPt96O1jwTnAdH1pT0ZAnd0N
Du8jMZ8bZ8b8fCdSmhtX4MlBT1axQxcmd0NLnuiosh7xagPK8ZVT+LBqoAC4+HQq
qazM6Cxn2yx+dOlWE2cauMQTpJzzp1uwC5qIFil8tgkJ5VmhqDthk+g7oIKIBqHD
i5zsIXxpeLz5iouYFYxh22rTY1unf+T1VYudA+TQfoRJIr9iEsBtNlm/RNX1hmzY
1olLVD5y7R6G5QrzDd9XtkObUXRf1PJW/zZ5Klu6V52yUricCp4tCoK3NEaXCD4P
8Ws1NXElpQSzKWS1EAjF18b5EQ1FWzBLE8znc1NG81uNzj0kKJjw/Rffq5lcNsVN
WmlAVNbGtzFvHZnnJ56B7MC+H5y7OsOCCqW1p5Bnn/3BuMwr4qGgjUyWTtSvh14s
iHGDLmSvlV+8jiN7wEjuZWRFQjBv1oUwIQ3+IDBb0KUROxp6AigCwJ7E2m38PxAe
SMYPRUOL2JeLcDeAL9CO23B8VKflygt7DqA+TBxHtBjp0gDAjfm7xyMaz4OiQwcb
xeUI/U+N3QP/0m6JurqA
=fvnt
-----END PGP SIGNATURE-----

[James Page (james-page)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/04/14 15:18, Matthias Klose wrote:
> - Stop bundling every source in juju-core.

I think the dh-golang helper, albeit with golang gc as the default, is
now sufficiently developed to support this for juju-core; however this
ties heavily into how jujud tools are distributed as we could end up
with a situation where the jujud built in the Ubuntu archive != jujud
built for distribution in simplestreams.

I've been thinking about this over the last few days and I can't see a
route to main for juju-core unless the jujud bits are always built
in-archive - these could still potentially be distributed via
simplestreams to support the versioned tools approach that juju takes
- - probably worth covering how this works for the benefit of others.

When a user bootstraps and environment, a tool version selection is
made based on the best compatible tools for the client version - so a
juju client at 1.17.7 would always pick from 1.17.x; the environment
sticks to this version for all new units even if there is a new 1.17.x
release - the administrator of the environment initiates an upgrade to
this new version using juju:

   juju upgrade-juju myenv

at which point the jujud daemons on the service units pickup the new
version, perform any upgrade steps and restart with the new version of
the binary. This allows the juju-core development team to have direct
control over what happens during an upgrade and how its orchestrated
across a running environment.

I think this is a unique feature which is extremely hard to address in
the packaging space and is very useful for end-users.

However this does complicate updates of any kind; thinking in the
context of a security update in a world where all juju-core
dependencies are in separate packages and juju-core is still
statically linked, the security update in the dependency requires a
rebuild of juju-core - however this must bump the version of juju-core
otherwise its not possible to effectively distribute new tools via
simplestreams.

Right now addressing an update/bug/security fix has to be done
in-conjunction with juju-core upstream (as all dependencies are
currently bundled in the source tree) so that tools and distro
binaries stay in sync (hence the need for a MRE for juju-core which I
will be submitting soon).

Patching the distro package fixes issues for those using the local
provider or using --upload-tools, but not 'normal' users consuming
tool binaries from simplestreams.

I guess if juju understood how to interrogate package versions from
the archive, it might be possible to always build a version namespaced
binary package, e.g. juju-core-1.17.8, so that the archive would
retain a history of juju-core versions, allowing juju to pick a) the
current version it needs and b) upgrade to a new version if available.

- --
James Page
Ubuntu and Debian Developer
<email address hidden>
<email address hidden>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPoyTAAoJEL/srsug59jDC1kQAM70KG8V8FHRcnhekOyjCtH6
MUBJIMLi6JIcUn6g8rQ6XSqaVehlfa4bEAZV2sj2RcVr0vhC3TPWAEnfkmdfZAew
LPvnPX3GaHuw21...

[Seth Arnold (seth-arnold)]

Quoting myself: "I'm pretty new to Go, but it feels like there's a nice
opportunity to use the type system to create a ShellScript type that can
only be constructed from static strings and properly quoted arguments".

I don't know why it took me until just today to think it through, but what
bash (and Juju) are missing is an equivalent to SQL's prepared statements
with placeholders. That is the class that Juju is missing, and if properly
implemented, would doubtless be useful for the larger Go community beyond
just Juju, though Juju would likely be the largest consumer.

Thanks

[Matthias Klose (doko)]

gccgo-go is removed in vivid, superseded by gccgo-5

[Launchpad Janitor (janitor)]

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

[Ian Booth (wallyworld)]

RE: some of the issues raised in comment 48

- juju-backup shell script uses incorrect quoting method needlessly

Juju no longer uses a shell script for backup. That was a short term implementation which has now been replaced by server side functionality written in go.

- The local environment hardcodes use of 'sudo' to raise privileges

Juju's behaviour has changed in this area, I am not sure if what is done now is sufficient to consider the above issue addressed. Juju requires sudo when using the local provider because user mode lxc did/does not exist in all supported series. What Juju does now is to allow the user to execute bootstrap without first being root, and prompts to elevate privileges as needed to start the lxc containers. This is different to the original behaviour which was to require "sudo juju bootstrap" thus elevating the entire bootstrap process.

[Steve Langasek (vorlon)]

On Tue, Aug 04, 2015 at 10:26:43PM -0000, Ian Booth wrote:
> RE: some of the issues raised in comment 48

Seth, can you re-review juju in light of this response?

[Seth Arnold (seth-arnold)]

My primary concern was with the confused double duty of the shell quoting -- sometimes it was being used to protect an input from a user, and sometimes it was being used to transmit scripts to remote peers.

I really hope to see something akin to sql prepared statements in juju that use the class system to enforce proper quoting of inputs when they must be used as an argument to a command, so that ad hoc constructions aren't scattered throughout the codebase.

Replacing juju-backup sounds like an improvement, but that was just one instance of the above complaint.

Embedding sudo into the program to avoid running the entire bootstrap process as root does make sense, but I do wonder if unprivileged lxc containers would be more appropriate at this point. It still seems like a large assumption about how sudo can be used on the juju host -- perhaps it is fair to say the juju host must be dedicated to the task, but it'd be nice to see that spelled out explicitly.

I'll ask Tyler to look at our backlog and fit this in where we can. Thanks.

[Matthias Klose (doko)]

juju-mongodb ftbfs in wily

[Dustin Kirkland  (kirkland)]

Looks like @pitti fixed the ftbfs:

juju-mongodb (2.4.10-0ubuntu4) wily; urgency=medium

  * Fix FTBFS: (LP: #1483400)
    - Add 00git_boost_1.56.patch: Fix "std::swap" failure with current boost.
      (Backported from upstream git)
    - Add 00git_pymongo3.patch: Fix buildscripts/smoke.py for PyMongo 3.
      (Backported from upstream git)
    - Add no-unused-variable.patch: Don't fail to build on "unused-variable"
      warning.

 -- Martin Pitt <email address hidden> Tue, 11 Aug 2015 10:57:23 +0200

[Alexis Bruemmer (alexis-bruemmer)]

LP #1481502 has been opened to track the development work to fix ShQuote()

https://bugs.launchpad.net/juju-core/+bug/1481502

[Curtis Hovey (sinzui)]

Regarding - release-public-tools.sh doesn't validate downloaded packages. That script has not been used since October 2013.
The current script
    http://bazaar.launchpad.net/~juju-qa/juju-release-tools/trunk/view/head:/assemble-streams.bash
does not use "apt-get download" because that that command does not work for all series. The script is run a Jerff (streams.canonical.com), a machine the QA team does not control. We are not permitted to install software on it, nor can we change its apt settings. As the machine is precise, we could only get 3 of the 18 ubuntu agents built by Launchpad.

The modern script downloads the deb from a private ppa with only one subscriber (the QA team). The packages are downloaded within 30 minutes of being built. As juju doesn't distinguish between patch-level or origin in is checking of versions, and the fact that Juju itself creates fake versions, The assembly and publication script scripts validate the collection of agents. Agents cannot be changed. Only the agents added are permitted to be different in the collection. All the agents in the collect are hashed and verified to to match the local collection each time the script is run. The publication script rsyncs (or uses the clouds equivalent feature) the local stream of agents to the cloud. The final check verify the metadata is identical and public for users to access.

assemble-streams.bash is scheduled to be replaced this cycle. We are considering removing the phase to download debs and make agents. The process is not idempotent. We are considering a separate process controlled solely by the QA team to create and assess agents for the collection (test them before they are placed in streams). We could use "apt-get download" on machines/containers we control to make agents. Streams.canonical.com, like the clouds would get agents only from the QA team.

[Ian Booth (wallyworld)]

@Seth, with the user mode containers - lxc didn't support that when the local provider feature was first developed. And now we have lxd on the horizon so we will be re-tooling local provider to use lxd and this will be delivered for Juju 1.26 around end of January 2016. We don't plan on making any further changes to local provider / lxc in the meantime as any work there will be imminently obsolete by the lxd stuff.

[Jamie Strandboge (jdstrand)]

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 c...

[Jamie Strandboge (jdstrand)]

In addition to Seth's review, I can say that juju needs to make some packaging changes to meet the MIR requirements I set forth in the last comment. Specifically:
 * should use golang now for all supported archs (!powerpc)
 * should move embedded libraries out to proper packages
 * should use Built-Using in debian/control
 * should use dh-golang and follow Debian Go packaging guidlines (see https://wiki.ubuntu.com/MIRTeam)

The above should not be considered a comprehensive list-- there might be more that Seth find in the security review or others find in the packaging review.

[Jamie Strandboge (jdstrand)]

Based on the above, I think the gccgo tasks can be close?

[Matthias Klose (doko)]

well, it's already in main. needed to build the cross compilers and to cross-build gcc-5

[Jamie Strandboge (jdstrand)]

Per https://wiki.ubuntu.com/MainInclusionProcess, marking Incomplete since we need commitments from various folks before granting security team signoff.

[Steve Langasek (vorlon)]

On Fri, Sep 04, 2015 at 08:54:06PM -0000, Jamie Strandboge wrote:
> 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

Yes, the Foundations team understands this requirement and is committed to
delivery of golang 1.6 in Ubuntu for 16.04 and to assist the owners of
packages implemented in go with adoption of shared library support.

> * 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)

While discussions are still ongoing regarding how this will be handled over
the long term, the Foundations team is committed to be the point of contact
for the golang package and to ensure that this toolchain is properly
supported in Ubuntu.

> * 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

I believe Michael Hudson-Doyle is actively working on this. While Michael
isn't on the Foundations team, I think you can consider this a de facto
committment.

[Jamie Strandboge (jdstrand)]

Yesterday slangasek and I met with the juju team regarding the path forward for transitioning to shared libraries and Alexis will be commenting on that later.

Unrelated to that, juju is using many embedded code copies and juju-core will need to be adjusted to build with many of these broken out into golang-*-dev packages (see https://wiki.ubuntu.com/MIRTeam for details, and use dh-make-golang to make this easy). Before I give the list, a couple of things:
 * it is acknowledged that the Go community has traditionally embedded sources in their trees and then managed imports themselves. This works fine for the app model where bundling is the norm (eg, for Ubuntu Touch clicks and Ubuntu Core snaps). However, for the reasons outlined in the MIRteam wiki, this does not work well with the Linux distribution model and applying for main inclusion in Ubuntu by definition means working within the distribution model. Also, the Go community has acknowledged the benefits of shared libraries with regard to code reuse, project management, the distribution model, etc, which is why Go 1.5 has shared library capability (that doesn't mean the app bundling model doesn't still have its place)
 * it is also acknowledged that juju is different in some ways to other software delivered via the archive in that its current packaging of client, server, agents, etc is for multiple platforms, not just Ubuntu. However, juju is being delivered to Ubuntu juju clients via apt and therefore for those clients there isn't a technical reason why those embedded libraries can't be delivered as separate packages (in other words, it's fine if juju-core has embedded sources in the orig.tar.gz if that helps the juju team, it is just that (many of) those embedded sources should not be used during archive builds (where instead juju-core should use Build-Depends on golang-*-dev packages)). This is all standard Debian and Ubuntu archive practice and that is why the Debian Go team has been working so hard on dh-golang, Built-Using, etc
 * it should be acknowledged by go developers seeking main inclusion that the MIR, foundations and security teams have already made many concessions for golang and these changes to the process alone will result in increased maintenance effort for officially supported packages (but at a level we believe can be supported, unlike if we ignored embedded sources/shared libraries)
 * creating golang-*-dev packages for embedded sources doesn't mean the juju team can't still control the code, it is just that the lib will live in a different place. Eg, suppose that github.com/joyent/* is pulled out into golang-joyent-dev. A MIR would be required for golang-joyent-dev and the juju team would be the team committed to maintaining the package and fixing those bugs. The PPU acls would be adjusted to allow the juju team to upload this package, just like with juju-core. The SRU process would apply to it, etc. (Ie, nothing fundamentally changes wrt control if the juju team wants to maintain that control (ie, perhaps they wouldn't mind relinquishing control of some of them))
 * all the embedded packages do not necessarily need to be pulled out. Eg, github.com/juju and gopkg.i...

[Jamie Strandboge (jdstrand)]

One more comment on broken out libs (whether static or shared), juju-core might want to consider expanding autopkgtests to uncover regressions caused by dependencies.

[Seth Arnold (seth-arnold)]

I reviewed juju version ff791983cd1a186e2e09878a37cf243f7f9eb734. The
review covered significantly less portion of the codebase than usual, and
should not be considered a security audit.

Juju 1.18.1 is in trusty-release
Juju 1.22.6 is in trusty-updates
Juju 1.22.1 is in vivid-release, meaning upgrades from updated trusty to vivid fail
Juju 1.22.6 is in wily

When were 1339770 1389326 1391276 fixed? Are they fixed in all supported
releases? There's no mention of any of these bug numbers in the published
changelogs:
https://launchpad.net/ubuntu/+source/juju-core/+changelog

These bugs were known to be dangerous in 2014 yet still caused extensive
damage in May, 2015. What allowed them to persist so long? What steps have
been taken to ensure future bugs of similar severity don't last unpatched
in production for so long?

In 1339770, in May 2015, it was mentioned that 1.18 was end-of-life and no
further updates could be prepared for it. 1.18.0 was released just 13
months earlier and 1.18.1 had been included in 14.04 LTS. Why was the 1.18
infrastructure torn down so shortly after including 1.18 in a release with
five-year support? Have there been any similar changes in process that
would prevent or delay issuing an update to the currently supported
versions of juju already in the archive?

It is currently impossible to upgrade from 14.04 LTS to 15.04 due to
incorrect version numbers. Has anyone else noticed this yet? When will
this be fixed? Are there any changes in process needed to ensure this
doesn't happen in the future?

Will the juju team be asking for an MRE? Is it anticipated that new series
(e.g., the 1.18 to 1.22 change) would be included as an MRE? What
processes are in place to test updates before including updates into the
archive? What processes are available to the security team to test
updates that we would prepare?

I had more trouble reading the Juju code this review cycle than last
review cycle -- the Facade indirection mechanism makes code navigating
harder. I'm worried about it for a few reasons:
- Strings to reference method names are brittle and can't be checked at
  compile time. What methods are in place to ensure that these aren't
  typoed?
- Generic args and return types defeat type checking. What ensures types
  being returned or accepted have the desired properties?
- Java has had significant problems with their Reflection mechanism,
  probably dozens of issues per year. At what points of a process
  lifetimes is the Facade mechanism dynamic?

Here's a few issues I found:

- ./apiserver/apiserver.go logs passwords when tracing is enabled -- this
  is fine IFF this is loudly documented somewhere obvious. Is it? It'd be
  best to filter out passwords regardless.

- Chown() doesn't quote the user or group

- ./api/client.go WatchDebugLog() claims to read a line but looks like it
  may read up to 4096 bytes -- is this correct?

- significant number of TODO comments; is there a method in place to find
  unowned comments and assign them somewhere? is there a process in place
  to ensure they get revisited?

- Which versions of the client work with which versions of the servers?
  Where's that described?

- ./api/keyupdater/...

[Tim Penhey (thumper)]

This is an answer to some of the questions Seth asked

> In 1339770, in May 2015, it was mentioned that 1.18 was end-of-life and no
> further updates could be prepared for it. 1.18.0 was released just 13
> months earlier and 1.18.1 had been included in 14.04 LTS. Why was the 1.18
> infrastructure torn down so shortly after including 1.18 in a release with
> five-year support?

I believe that this change was primarily brought about by the change
from using bzr to git. The build and test infrastructure had to be
re-tooled to make this work.

> Have there been any similar changes in process that
> would prevent or delay issuing an update to the currently supported
> versions of juju already in the archive?

We are unlikely to change from git.

> It is currently impossible to upgrade from 14.04 LTS to 15.04 due to
> incorrect version numbers. Has anyone else noticed this yet? When will
> this be fixed? Are there any changes in process needed to ensure this
> doesn't happen in the future?

The older versions of Juju were not very good at handling unknown
series. I have targeted a previously created bug to address this:
  https://bugs.launchpad.net/juju-core/+bug/1403689

There are work-arounds that have been used by IS to upgrade older
environments.

We do test a number of upgrade combinations, and I'm curious as to why
you say it is impossible to upgrade? What exactly is the situation you
are attempting?

> Will the juju team be asking for an MRE? Is it anticipated that new series
> (e.g., the 1.18 to 1.22 change) would be included as an MRE? What
> processes are in place to test updates before including updates into the
> archive? What processes are available to the security team to test
> updates that we would prepare?

There are CI tests around upgrading from older versions to the current
tested release. I believe that one of these tests includes going from
1.18 to the current tested release.

> I had more trouble reading the Juju code this review cycle than last
> review cycle -- the Facade indirection mechanism makes code navigating
> harder. I'm worried about it for a few reasons:
> - Strings to reference method names are brittle and can't be checked at
> compile time. What methods are in place to ensure that these aren't
> typoed?

There are unit tests in place that test both the client and server side
of every call, and in addition to that there are full feature tests that
make sure all the parts align.

> - Generic args and return types defeat type checking. What ensures types
> being returned or accepted have the desired properties?

The specified unit and feature tests.

> - Java has had significant problems with their Reflection mechanism,
> probably dozens of issues per year. At what points of a process
> lifetimes is the Facade mechanism dynamic?

During the low level RPC call from the client to the API server.

> Here's a few issues I found:
>
> - ./apiserver/apiserver.go logs passwords when tracing is enabled -- this
> is fine IFF this is loudly documented somewhere obvious. Is it? It'd be
> best to filter out passwords regardless.

I have created a bug to address this more completely:
  https://bugs.launchpad.net/...

[Colin Watson (cjwatson)]

On Mon, Sep 28, 2015 at 07:51:47AM -0000, Tim Penhey wrote:
> We do test a number of upgrade combinations, and I'm curious as to why
> you say it is impossible to upgrade? What exactly is the situation you
> are attempting?

It's just about version numbers, as Seth says. The constraint that
should be satisfied is that, if a package is in both series A and series
B and B > A, then version(B, package) >= version(A, package). juju-core
fails this constraint because 15.04 hasn't been upgraded to Juju 1.22.6
but 14.04 LTS has:

  $ rmadison juju-core | egrep 'trusty|vivid'
   juju-core | 1.18.1-0ubuntu1 | trusty/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el
   juju-core | 1.22.1-0ubuntu1 | vivid/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el
   juju-core | 1.22.6-0ubuntu1~14.04.1 | trusty-updates/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el

[Seth Arnold (seth-arnold)]

On Mon, Sep 28, 2015 at 07:51:47AM -0000, Tim Penhey wrote:
> > It is currently impossible to upgrade from 14.04 LTS to 15.04 due to
> > incorrect version numbers. Has anyone else noticed this yet? When will
> > this be fixed? Are there any changes in process needed to ensure this
> > doesn't happen in the future?
> [...]
> We do test a number of upgrade combinations, and I'm curious as to why
> you say it is impossible to upgrade? What exactly is the situation you
> are attempting?

In short, install trusty, install juju, apt-get update && apt-get -u
dist-upgrade; then, use do-release-upgrade to upgrade from trusty to
vivid. This upgrade will fail and uninstalling juju will be the easiest
path forward for the administrator.

I filed https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1497087
for this bug.

The Debian tool piuparts is one way to do automated testing for this case,
it might be worth bringing it over to Ubuntu; in the meantime, teams need
to be aware to make sure that version numbers in supported releases always
allow upgrades.

Thanks

[Curtis Hovey (sinzui)]

@seth
I reported https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1500916 to address bug 1497087. While the Juju team has always provided backports for its community, we don't have the privileges to provide backports quickly. The Juju QA team has dedicated staff for release and backport, and in Time the team will have staff that can upload packages as needed.

[Alexis Bruemmer (alexis-bruemmer)]

> Will the juju team be asking for an MRE? Is it anticipated that new series
> (e.g., the 1.18 to 1.22 change) would be included as an MRE? What
> processes are in place to test updates before including updates into the
> archive? What processes are available to the security team to test
> updates that we would prepare?

To more directly answer this comment, Juju does have a Stable Release Update policy in place. As part of that policy the QA team outline testing Juju CI and testing procedures, details are here:

https://docs.google.com/document/d/1TVW0QzpLo622pzBUsEK9SqZAod4oJn9ROF1IWMqa9tg/edit#heading=h.f3goroun9jd1

[Alexis Bruemmer (alexis-bruemmer)]

Response to James' inquiries in comment #67:

* juju team: can you comment on the package breakdown? For items requiring further discussion, it might be worthwhile understanding how often you are updating the embedded package (useful for the SRU question, below)

On average 50% of the package dependencies change between minor release (for example there were 14 package dependency changes from 1.24 to 1.25)

* SRU team: juju-core already has a release exception. For packages that are being broken out that were formerly part of the juju-core package and that the juju team will now maintain, can those just be given a release exception?

Yes, those should also be given a release exception. Many of these are central to keeping ubuntu current with existing clouds. For Juju to actually work, if the dependent packages are being split out, every single one of them will need to be included in the release exception.

* Ubuntu Archive team: juju-core will likely need a PPU for members of the juju team when it goes to main. Can we extend the acl to include the packages that are being broken out that they are going to maintain?

Yes, to deliver a fix to juju core, we need to fix the dependencies at the same time. This will be done by the same person, so yes to extending the acls to those packages.

* MIR team: for the packages that are being broken out, I propose that they don't get extended MIR review, but rather simply the packaging review to make sure they are following the Go standards as outlined in the MIRteam document

Yes, agreed.

* juju team (/security team): the juju team has said that they would like coordination of security updates for juju-core and golang-*-dev packages for which they maintain. I propose the security team maintains a list of packages and when we triage a CVE against a package in that list, we file a bug for the juju team to fix, and sponsor their uploads (like for other Canonical upstreams). juju team-- does that address your concerns?

Yes, we will own fixing security bugs for juju, and dependent libraries that we control or can patch.

[Jamie Strandboge (jdstrand)]

Thanks! What about the embedded code copes question in comments #68 and #69.

[Jamie Strandboge (jdstrand)]

I of course meant 'copies' in that last comment.

To clarify what I'm thinking about wrt to juju embedded copies> the source package can ship various embedded code copies but the archive build should use archive golang-*-dev packages whenever possible and where it makes sense (see comment #68 for the list). For example, the archive build of juju should use golang-go.crypto-dev, but juju source package may contain code.google.com/p/go.crypto if code.google.com/p/go.crypto is needed for some other non-archive build.

If both are legitimately needed (and there should be justification for that) to support different clients, then the archive build should use golang-go.crypto-dev from the archive and embed code.google.com/p/go.crypto (justification being, all archive builds should use golang-go.crypto-dev and only juju needs code.google.com/p/go.crypto).

I need someone can go through that list in comment 68 and comment on it. Then anything that should be broken out of the juju source (ie, it is not juju-specific) should be into golang-*-dev packages and the archive build should use them and any other existing golang-*-dev packages from the archive.

[James Page (james-page)]

Martin and I reviewed and tested with golang-*-dev packages that are already in the archive; proposed packaging update is here:

  https://code.launchpad.net/~james-page/ubuntu/wily/juju-core/mir-fixes/+merge/274052

The only existing golang-dev package which we where not able to use was golang-go-systemd-dev - the version in archive is API incompatible with juju-core, which needs further investigation.

This will be a typical problem - not all golang projects maintain stable API's and projects are used to fixing on a specific version to maintain stability, but thats something we're going to need to workout as a distro.

[James Page (james-page)]

Looking at the dependency chain to support the MIR, we're currently pulling two versions of check into main (golang-gocheck and golang-check.v1). This is caused by the use of golang-goyaml which depends on the older golang-gocheck package.

golang-yaml.v2 aligns with the newer check version - I've asked the Juju team to see if we can patch that in for this release and switch the dependency in development for 1.25.

[James Page (james-page)]

MIR review information for new -dev dependencies

>> golang-github-bmizerany-assert <<

[Availability]
In universe

[Rationale]
Dependency for golang-github-bmizerany-pat

[Security]
No security history

[Quality assurance]
Package builds OK and unit tests are executed

[Dependencies]
All in main apart from dh-golang

[Standards compliance]
OK

[Maintenance]
ubuntu-server

>> golang-github-bmizerany-pat <<

[Availability]
In universe

[Rationale]
Dependency for juju-core

[Security]
No security history

[Quality assurance]
Package builds OK and unit tests are executed

[Dependencies]
All in main or covered by this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-server

>> golang-go-dbus <<

[Availability]
In universe

[Rationale]
Dependency for juju-core

[Security]
No security history

[Quality assurance]
Package builds OK and unit tests are executed

[Dependencies]
All in main or covered by this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-server

>> golang-juju-loggo <<

[Availability]
In universe

[Rationale]
Dependency for juju-core

[Security]
No security history

[Quality assurance]
Package builds OK and unit tests are executed

[Dependencies]
All in main or covered by this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-server

>> golang-check.v1 <<

[Availability]
In universe

[Rationale]
Dependency for golang-juju-loggo

[Security]
No security history

[Quality assurance]
Package builds OK and unit tests are executed

[Dependencies]
All in main or covered by this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-server

>> golang-go.crypto <<

[Availability]
In universe.

[Rationale]
Dependency of juju-core.

[Security]
No history of issues.

This (CVE-2014-7189) crypto bug is on the standard library crypto, not the extension package:
<https://code.google.com/p/go/source/detail?r=eae0457c101512f59296538f0162749eba325892&name=release-branch.go1.3>

[Quality assurance]
Tests run as part of build process. Some are skipped due to lack of openssh as a build dependency.

[Dependencies]
All in main or covered on this MIR

[Standards compliance]
Ok.

[Maintenance]
ubuntu-server

>> golang-go.net-dev <<

[Availability]
In universe.

[Rationale]
Dependency of juju-core.

[Security]
No history of issues.

[Quality assurance]
Tests run as part of build process. A small number skipped due to lack of root perms or network requirements.

[Dependencies]
None.

[Standards compliance]
Ok.

[Maintenance]
ubuntu-server

[James Page (james-page)]

If the move to golang-yaml.v2 is low risk and can be done, then I'll include that package for MIR and drop golang-goyaml and golang-gocheck; however if that's not the case, then I think we should *not* use golang-goyaml-dev and fallback to the embedded code copy in juju-core for this cycle; juju should be able to switch in a newer release at a future date.

[James Page (james-page)]

Tracking bug 1504821 in juju-core for yaml.v1 -> yaml.v2 switch:

[James Page (james-page)]

>> dh-golang <<

[Availability]
In universe

[Rationale]
Dependency for all other golang-* packages

[Security]
No security history

[Quality assurance]
Package builds OK but has no unit tests.

[Dependencies]
All in main or covered by this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-server

[James Page (james-page)]

juju-mongodb no longer ftbfs in wily

[Matthias Klose (doko)]

I think implementing autodep8 for go packages is a must.
http://anonscm.debian.org/cgit/collab-maint/autodep8.git/tree/README.md

At least to build the reverse dependencies so that new uploads are blocked in -proposed until all build failures are resolved.

[Michael Terry (mterry)]

dh-golang is fine; approved.

[Michael Terry (mterry)]

golang-github-bmizerany-assert is mostly good, but needs a tiny fix:

- debian/control should have Built-Using: ${misc:Built-Using} on the golang-github-bmizerany-assert-dev package

[Michael Terry (mterry)]

golang-github-bmizerany-pat is good; approved.

[Michael Terry (mterry)]

golang-check.v1 looks good; approved.

[Michael Terry (mterry)]

Doko, I just noticed your comment about dep8 tests. I agree that some sort of mechanism to avoid ftbfs would be good. Though in this respect, golang isn't so different than C libraries, where an unexpected API update or library bug can cause ftbfs in reverse-depends. We use dep8 tests as best practices to avoid that, but don't *require* it as part of a MIR.

But actually, I expected we could use Built-Using fields in our proposed-migration tooling to automatically test that reverse-depends could still build. Is that not in the works yet?

That seems more packaging-friendly than requiring a bunch of one-line dep8 tests to trigger a rebuild test. Especially if we have to add a delta to get it.

[Michael Terry (mterry)]

golang-go.net-dev build-depends on golang-x-text-dev (which didn't have a MIR section here -- I've added a bug task for it now anyway).

But golang-x-text isn't ready yet:
- It is ftbfs due to test failures. That should be looked at.
- It needs a team bug subscriber.

[Michael Terry (mterry)]

golang-go.net-dev though looks good, approved. There is an oddity in Debian around it being removed from testing [1], but that appears to be a mistake? I don't see any bugs filed against it, there was no removal hint, and the package tracker is giving inconsistent statuses/versions. In any case, we have the version that Debian seems to be OK with.

[1] https://packages.qa.debian.org/g/golang-go.net-dev.html

[Michael Terry (mterry)]

golang-juju-loggo needs some fixes:
- It's missing Built-Using: ${misc:Built-Using}
- Its name is wrong [1]. It should be golang-github-juju-loggo and golang-github-juju-loggo-dev. We should fix in Ubuntu so that if it's ever packaged in Debian, we'll be aligned.

[1] http://pkg-go.alioth.debian.org/packaging.html

[Michael Terry (mterry)]

golang-go-dbus has one blocking problem and I've got a few minor concerns:
- Needs to use Built-Using
- It's about to be removed from Debian testing due to its dependency on golang-gocheck. Not an immediate problem for us, but since we want to port away from gocheck anyway, maybe we can help Debian here and keep a little better in sync.
- This is a native Go implementation of libdbus. I'm not super thrilled about another DBus implementation in main, but I get the desire to be native and allow cross compilation.

[Michael Terry (mterry)]

Doko, I did some of the leafier modules here. I figure you'd be the best person for some of the core ones. If you're too loaded, bounce back to me.

[Martin Pitt (pitti)]

Michael Terry [2015-10-13 17:33 -0000]:
> That seems more packaging-friendly than requiring a bunch of one-line
> dep8 tests to trigger a rebuild test. Especially if we have to add a
> delta to get it.

autodep8 can "synthesize" a debian/tests/control for a group of
related packages. It already does that with perl, ruby, nodejs, and
dkms packages. I. e. the idea is you write a generic test, put it into
some golang-autopkgtest package (or another common one, maybe
dh-golang), and add some detection logic ("what kind of package is
this and can I create a test for it?") and creation of a
"Test-Commands:" to autodep8.

Besides, autopkgtests are totally suitable (and appreciated) for
forwarding to Debian too.

[Steve Langasek (vorlon)]

On Tue, Oct 13, 2015 at 05:33:37PM -0000, Michael Terry wrote:
> Though in this respect, golang isn't so different than C libraries, where
> an unexpected API update or library bug can cause ftbfs in
> reverse-depends.

It is different, because:

 - reverse-dependencies don't have to be rebuilt for a security update to a
   C library; even if an API does break, C revdeps can be left unbuildable
   for a while with much less impact
 - since we're not using shared libraries (at this point), there's nothing
   in the packaging of go packages (like sonames for C libraries) that
   signals to proposed-migration that there's been an incompatible change
   requiring a transition.

> But actually, I expected we could use Built-Using fields in our
> proposed-migration tooling to automatically test that reverse-depends
> could still build. Is that not in the works yet?

I'm not aware that anyone has discussed integrating such functionality into
proposed-migration.

[Michael Terry (mterry)]

> - reverse-dependencies don't have to be rebuilt for a security update to a
> C library; even if an API does break, C revdeps can be left unbuildable
> for a while with much less impact

I get that you're saying it's good because we don't have to waste security-update-time fixing reverse-depends. Which is a good point. But it also sorta sounds like "in this scenario, the advantage of C libraries is that we have unbuildable packages that we don't know about". So a bit of a mixed blessing.

> - since we're not using shared libraries (at this point), there's nothing
> in the packaging of go packages (like sonames for C libraries) that
> signals to proposed-migration that there's been an incompatible change
> requiring a transition.

For incompatible changes requiring transitions, I thought the Go convention was a new package name. Like check.v1 or check.v2. Which would be a whole new package in Debian/Ubuntu. Much like shared libraries bumping sonames.

--

So adding synthesized dep8 tests or proposed-migration logic to confirm no ftbfs by rebuilding Go reverse-dependencies are good ideas. But I maintain it's just as good an idea as doing the same thing for any other package upload (checking reverse-depends for ftbfs). The only difference I see is Steve's point about the security team being faced with ftbfs packages that they must now fix. Normal package updates wouldn't require a rebuild of all reverse-depends, so those would be status quo.

1) So, since the security team is facing this, I'll leave this specific question to them. They didn't mention monitoring for ftbfs in their list of requirements before, but maybe they'd like to? I guess the easiest route would be a golang-autopkgtest package like pitti mentioned.

2) Am I being too carefree? Do Go library minor updates tend to break builds more often than C or Python libraries? (Honest question, I'm not a Go native.) I had assumed Go folks have typical engineering practices, but maybe the statically-linked nature of Go causes people to play fast and loose with updates.

[Matthias Klose (doko)]

gccgo-go is removed from vivid and wily, no need for a MIR anymore. Unsubscribing myself.

[Matthias Klose (doko)]

golang:

The packaging of the golang package looks reasonable well, it is based
on the the Debian packaging. In Ubuntu the package suffered regular
maintenance up to and beyond the 15.04 release (vivid). It's good to
see another attempt to maintain this package.

While not required, it is good to see that shared library support is
being worked on, and targeted for the upcoming 1.6. release.

golang is not just a build dependency for juju, but for various
packages within the phone stack, so it will require coordination with
other teams to introduce new versions and keep the packages buildable.
From my point of view this just didn't happen in the past. I suppose
that golang 1.6 is targeted for the anticipated 16.04 LTS release, so
please make sure that maintenance and update plans are made and
communicated (see UOS in about two weeks).

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.

Setting the status for golang to incomplete, and waiting for this
confirmation. After that I think the package can be promoted to main.

[Matthias Klose (doko)]

juju-core:

Others already commented on the code, and finally approved with some comments.

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?

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

[Matthias Klose (doko)]

golang 1.5 is now built on arm64 and ppc64el, however juju-core is built using gccgo. Is there a reason for it?

[Jamie Strandboge (jdstrand)]

juju-mongodb has security team ACK so long as the builds use --disable-scripting in perpetuity.

I verified the wily version is correctly using --disable-scripting in debian/rules (if I build without '--disable-scripting', I see src/third_party/v8 being built and build with --disable-scripting, I don't).

[Matthias Klose (doko)]

juju-mongodb:

packaging bits only, the security team will follow-up with a code review.

 - the packaging is a copy of the mongodb package, however it looks
   like the packaging itself isn't merged / updated where needed.
   This problem is shared with the mongodb package in Ubuntu.

 - google-perftools is available on all archs. Is there a need to
   disable that for some architectures?

 - the package should be built for the upcoming s390x architecture as
   well.

[Matthias Klose (doko)]

Override component to main
dh-golang 1.12 in wily: universe/misc -> main
dh-golang 1.12 in wily amd64: universe/devel/extra/100% -> main
dh-golang 1.12 in wily arm64: universe/devel/extra/100% -> main
dh-golang 1.12 in wily armhf: universe/devel/extra/100% -> main
dh-golang 1.12 in wily i386: universe/devel/extra/100% -> main
dh-golang 1.12 in wily powerpc: universe/devel/extra/100% -> main
dh-golang 1.12 in wily ppc64el: universe/devel/extra/100% -> main
7 publications overridden.

[Jamie Strandboge (jdstrand)]

I see this is assigned to the security team. I already gave our ACK. Based on doko's comments, marking Incomplete.

[Jamie Strandboge (jdstrand)]

golang-go.crypto:
- builds fine on wily and pulls in no new MIR dependencies not listed in this bug
- has a testsuite that is run as part of the build
- Ubuntu does not carry a delta
- no watch file
- update history in Debian is sporadic
- lintian clean (one override that is ok)
- git snapshot from 20150618, which is not great that there isn't a stable release, but that is go for you
- debian/rules is ok
- uses dh-golang
- no open CVEs

ACK from security and MIR team.

[Jamie Strandboge (jdstrand)]

Actually, golang-go.crypto needs a bug subscriber. Marking incomplete. Once that is done, this can be moved back to Fix Committed.

[Jamie Strandboge (jdstrand)]

golang-go-dbus only ships a dev package with source code so does not need Built-Using (I updated the MIRteam wiki page to calrify this). Based on mterry's comments, golang-go-dbus is ok.

[Jamie Strandboge (jdstrand)]

"- debian/control should have Built-Using: ${misc:Built-Using} on the golang-github-bmizerany-assert-dev package"

This isn't needed for -dev packages. Marking Fix Committed.

[Jamie Strandboge (jdstrand)]

"golang-juju-loggo needs some fixes:
- It's missing Built-Using: ${misc:Built-Using}"

You can ignore this, but please do fix the package name.

[Jamie Strandboge (jdstrand)]

golang-x-text FTBFS due to testsuite failure:
=== RUN TestNumericCompare
--- FAIL: TestNumericCompare (0.02s)
 collate_test.go:119: Compare("\U00011730", "0") = 1; want 0
FAIL
FAIL golang.org/x/text/collate/colltab 1.473s

[Steve Langasek (vorlon)]

> golang 1.5 is now built on arm64 and ppc64el, however juju-core
> is built using gccgo. Is there a reason for it?

The reason for this is that the package is being backported directly to trusty, under the juju Stable Release Exception for SRUs. Since there is not a compatible version of golang in trusty, the package is currently built for all releases using gccgo.

I believe we will want to revisit this in the future, but I think this should be separable from the MIR question, do you agree?

> - the packaging is a copy of the mongodb package, however it looks
> like the packaging itself isn't merged / updated where needed.
> This problem is shared with the mongodb package in Ubuntu.

The mongodb package is in universe and unsupported. The juju-mongodb package exists to support juju-core and provides a subset of functionality specifically validated for use with juju. I don't think this should be a blocker for the MIR?

> - google-perftools is available on all archs. Is there a need to
> disable that for some architectures?

It's not available on arm64 in trusty, so probably should not be enabled on that architecture. It probably should be enabled on ppc64el and powerpc.

> - the package should be built for the upcoming s390x architecture as
> well.

Yes, it should; the architecture list in debian/control should just be dropped so that the package builds automatically for all architectures.

These last two points are good packaging feedback, but they don't seem to be critical for the package's current supportability in main (especially considering s390x is not in wily) (https://wiki.ubuntu.com/UbuntuMainInclusionRequirements). Can this be spun out into a bug report against the juju-mongodb package, unblocking the MIR for this component?

[Jamie Strandboge (jdstrand)]

@mterry,

I agree with doko and slangasek that we should block migration if APIs fail and I particularly like pitti's comment in 99.

Also, you said: "I get that you're saying it's good because we don't have to waste security-update-time fixing reverse-depends." The upstream Go community as a whole is less concerned about breaking consumers at this point in time and they haven't proven themselves wrt API stability. It is for that reason that we really need this. While it is the convention to change the package name, I very much prefer we not rely on this while the Go community (including Debian) is still figuring all this out. I really don't want to see decreasing Ubuntu developer or security update velocity when there is lurking bug for someone's next upload to ftbfs.

"Am I being too carefree? Do Go library minor updates tend to break builds more often than C or Python libraries?" I believe so, yes. A very popular Go model is to take a git snapshot from somewhere and use it, with no 'minor update' releases. Case in point, 10 out of the 11 dependencies of juju-core from this MIR use this model.

[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.