Matthias Klose <doko@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@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
