Re: Samuel: Do you have permission to _enable_ the gccgo patches again?
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.
> 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.
Samuel
Reply to: