Re: Samuel: Do you have permission to _enable_ the gccgo patches again?

[Matthias Klose]

On 27.03.2018 01:42, Samuel Thibault wrote:
> Svante Signell, on lun. 26 mars 2018 19:20:04 +0200, wrote:
>> On Mon, 2018-03-26 at 19:06 +0200, Samuel Thibault wrote:
>>> Svante Signell, on lun. 26 mars 2018 18:50:20 +0200, wrote:
>>>> I just saw:
>>>> https://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=10084
>>>>
>>>> This is really a large step BACK:
>>>
>>> It's not a step back, it's just fixing something that is completely
>>> wrong.
>>
>> What is really wrong is that Matthias Klose removed the Hurd patches.
> 
> Sure, but see what he wrote in the changlog: he found the patches
> "unmaintained", i.e. I guess he got an issue with it, and couldn't
> afford spending the time to fix it, and thus just dropped them. That's
> only normal for something that hasn't been upstreamed so far.

exactly. and you'll see that I updated some of these even before. So no, having
a complete port only done in the Debian package is not the best way to do that.
And I pinged you several times to do a proper upstream submission.

>> Adding them back is a piece of cake for you (or him), see #894080.
> 
> It's not: it means sorting out from your three mails what actually needs
> checking in, understanding what you mean by 
> “
> Finding the reverting commit and applying it
> gcc.git-b12c2c48c2c6aa1db9e6c50f6b26330deeee9caf.patch gcc+gccgo builds
> fine again.
> ”
> whether it's something that needs to be done on top of the patches,
> scratching one's head whether “I will report the build status when the
> latest version is built. (an eventually provide updated patches)” means
> one should wait for that to happen etc.
> 
> Then eventually try to build the whole thing, possibly realize it
> doesn't actually build, etc. etc. Not a piece of cake, really.
> 
>>>> Since you could issue that commit to _disable_
>>>> gccgo for Hurd, what about committing to _enable_ gccgo for Hurd instead.
>>>
>>> Because that would take *way* more time to do, and my current priority
>>> is rather glibc.
>>
>> And why would I help you with glibc upstream? Give me a good reason for that 
>> :(
> 
> Because if the work there is not done, the Hurd is basically screwed:
> glibc will drop the port, which means we'll get way more regressions
> etc.  Do compare that with just having go working.

that's the fate of some ports.  Look for kfreebsd instead. If nobody runs the
buildds the port is dying.  If nobody integrates the kfreebsd patch in openjdk
upstream, the patch is dying.  Look how m68k is still maintained upstream, and
you see floating in patches for go, openjdk, gcc, ...  It's the only way to keep
these ports alive, not carrying all these patches downstream.

Matthias