Go in vivid

[Michael Hudson-Doyle]

Matthias Klose <doko at ubuntu.com> writes:

> On 04/16/2015 03:17 PM, Michael Hudson-Doyle wrote:
>> Hi Matthias (belated response sorry)
>> 
>> On 31 March 2015 at 17:33, Matthias Klose <doko at ubuntu.com> wrote:
>>> As part of packaging GCC 5, there is now also a gccgo-5 package in vivid.  GCC 5
>>> now builds the go and gofmt commands from it's own source, so the gccgo-go
>>> package was removed from the distro.  gccgo is now based on Go 1.4.2, while
>>> golang still stays at 1.3.  There is a hack in the golang package in that it
>>> builds empty golang-go and golang-source packages, just to see what can be built
>>> in the archive, and a lot of things build (including lxd and docker.io), even on
>>> powerpc after tweaking things.
>>>
>>> A backport for trusty can be found in the ubuntu-toolchain-r/test PPA.
>>>
>>> A co-worker mentioned they would consider filing a FFe for golang, so it may be
>>> useful to look at the things that will break and need an update, including some
>>> packages for the phone, so here are some findings (didn't investigate for all of
>>> these if these are gccgo specific things, or just exposed by Go 1.4).
>> 
>> Do you have a script for doing these kinds of test builds?
>
> yes, there is a launchpad script, however it's not possible to select just a few
> packages for a test rebuild.  We only can select the component and the
> architecture, or use package sets.  But afaik managing and maintaining package
> sets is cumbersome as well.

OK.  It seems to me that building all things that (transititvely)
build-dep on a package would be useful?

>> For other
>> reasons here at the sprint we were wondering about the feasibility of
>> backporting go versions to trusty and cobbled together something
>> involving a ppa with the go 1.4 package from debian experimental,
>> grep-dctrl, some sed and dput and found that *most* things that
>> build-dep on golang-go in trusty build with go 1.4:
>> https://launchpad.net/~mwhudson/+archive/ubuntu/go-1.4-test-builds/+packages
>
> well, you would have to do that for utopic and vivid as well, or else packages
> wouldn't see get updated when updating to utopic or vivid (waiting three more
> months will allow you to skip utopic).

Yes sure.  Newer releases are harder, because there is more Go stuff...

> I'm not keen to replace a toolchain with a new major version, as you are doing
> here.  It is not a big issue for gccgo-5, because it doesn't replace anything,
> but just adds a new compiler version (and you probably don't need the libgcc1
> from gccgo-5).  Same with llvm-x-y, which is backported by the desktop team to
> support newer X stacks. So package it as golang-1.4, patch it to call the
> versioned tools, and prepare it as an alternative to the existing go
> version.

Yes, that does seem safer, so thanks for the advice.  As an aside, what
would you think about moving to versioned packages for go in general?

>> But well, it was messy.  Is there an approved way(tm) of testing this
>> sort of thing?
>
> I think it is incomplete until everything is built. E.g. in vivid aptly
> build-depends on golang-go.tools, so you don't know if aptly builds
> with go 1.4.

Hm, true.

>  Is there a reason you built using  1.4.1 and not 1.4.2?

Just because it's what is in experimental currently.  (Debian all a bit
slow moving until Jessie is released I guess).

Cheers,
mwh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20150420/28c58b09/attachment.pgp>