Matthias Klose <firstname.lastname@example.org> 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 <email@example.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:
> 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
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.
> 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).