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 protected]> 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.
> 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).
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.
> 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?
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel