On 2 November 2016 at 15:23, Martín Ferrari wrote:
> On 02/11/16 01:26, Martín Ferrari wrote:
> > On 02/11/16 00:05, Martín Ferrari wrote:
> >> On 01/11/16 21:44, Michael Hudson-Doyle wrote:
> >>
> >>> Go 1.6 did that too, but the special behaviour here was removed for
> 1.7.
> >>> gccgo-6 still
On 02/11/16 01:26, Martín Ferrari wrote:
> On 02/11/16 00:05, Martín Ferrari wrote:
>> On 01/11/16 21:44, Michael Hudson-Doyle wrote:
>>
>>> Go 1.6 did that too, but the special behaviour here was removed for 1.7.
>>> gccgo-6 still has a version of the go tool based on 1.6 though, so
>>> (unfortuna
On 02/11/16 00:05, Martín Ferrari wrote:
> On 01/11/16 21:44, Michael Hudson-Doyle wrote:
>
>> Go 1.6 did that too, but the special behaviour here was removed for 1.7.
>> gccgo-6 still has a version of the go tool based on 1.6 though, so
>> (unfortunately) the GOROOT hack that
>> 3852c129b5154
On 01/11/16 21:44, Michael Hudson-Doyle wrote:
> Go 1.6 did that too, but the special behaviour here was removed for 1.7.
> gccgo-6 still has a version of the go tool based on 1.6 though, so
> (unfortunately) the GOROOT hack that
> 3852c129b5154b63e2b86ba5db13390096ba calls "uneeded" is, in fa
On 2 November 2016 at 09:31, Tianon Gravi wrote:
> On 1 November 2016 at 11:28, Martín Ferrari wrote:
> > Now it is failing to build on gccgo arches [0], possibly due to some
> > tool still hardcoding the location for godoc. It would be great if
> > somebody can take a look, I have already spent
On 1 November 2016 at 11:28, Martín Ferrari wrote:
> Now it is failing to build on gccgo arches [0], possibly due to some
> tool still hardcoding the location for godoc. It would be great if
> somebody can take a look, I have already spent way too much time on this
> this week :)
Here's the relev
On 31/10/16 21:45, Potter, Tim (HPE Linux Support) wrote:
> Great - thanks Martin! I think that's probably what I should have done in the
> first place instead of trying to get everything working. (-:
Oh well, it is hard to get this mess right :)
Now it is failing to build on gccgo arches [0],
On 1 Nov 2016, at 8:31 AM, Martín Ferrari wrote:
>
> On 31/10/16 14:20, Martín Ferrari wrote:
>> Unless somebody thinks it is a bad idea, I will split x-tools into more
>> packages, at least to keep the web crap away from the important stuff.
>>
>> I am undecided if I should also split the sourc
On 31/10/16 14:20, Martín Ferrari wrote:
> Unless somebody thinks it is a bad idea, I will split x-tools into more
> packages, at least to keep the web crap away from the important stuff.
>
> I am undecided if I should also split the source package, to maximise
> isolation. Thoughts?
In the end,
Unless somebody thinks it is a bad idea, I will split x-tools into more
packages, at least to keep the web crap away from the important stuff.
I am undecided if I should also split the source package, to maximise
isolation. Thoughts?
--
Martín Ferrari (Tincho)
__
On 31/10/16 11:14, Martín Ferrari wrote:
> I was asking the same question on #-release just now.. I thought this
> was because of the cyclic dependency with google-cloud, but the latter
> finally migrated 2 days ago. I don't know what's going on with x-tools...
Adam shone some light on this:
[11
On 31/10/16 00:34, Potter, Tim (HPE Linux Support) wrote:
> Does anyone have any idea why the golang-golang-x-tools package is not
> migrating to testing?
>
> If this doesn't happen many other packages will fall out as well which is
> going to be annoying.
>
> According to the QA page, the pack
12 matches
Mail list logo
