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

[Samuel Thibault]

Svante Signell, on mar. 27 mars 2018 02:52:36 +0200, wrote:
> On Tue, 2018-03-27 at 00:49 +0200, Samuel Thibault wrote:
> > Svante Signell, on lun. 26 mars 2018 19:50:58 +0200, wrote
> > 
> > Well, a month is a long time indeed. I guess he needed to move forward,
> > so he dropped; no big deal.
> 
> Yes it is a big deal. If somebody spends numerous (spare time, unpaid) hours
> porting gccgo to Hurd and that work is thrown away then this _is_ a big deal.

What else could he do?  Really, please think about it.

No, he does not have (spare, unpaid) time to spend on fixing patches
himself.  What option did he have at the time except dropping the
patches? (waiting for fixes is not an option)

> > My point is: no, it's not obvious to just commit and forget.  While it
> > *is* obvious to just fix what's currently there.  If you don't see why
> > that commit was a move forward concerning Debian, please do check its
> > consequences and think about it.
> 
> ??

Please do take a think at what actual benefit my commit had, instead of
assuming that it is necessarily a step back.

> > > As I wrote in that bug report, all needed patches are there. And as the 
> > > bug
> > > report says: gcc-8 (8-8-20180321-1 and earlier) was successfully built.
> > 
> > But that's not the latest version, as you said it, even.
> 
> ??
> Latest released Debian version of gcc-8 is 8-8-20180321-1, see
> https://buildd.debian.org/status/package.php?p=gcc-8=sid

Ok, sorry, above I thought you were referring to thread "Hurd port of
go" which was talking about 8-8-20180312-1,2 only.

Anyway, nobody just applies patch blindly, so no it's not a piece of
cake to apply thousands of lines of patches.

Samuel

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=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-b12c2c48c2c6aa1db9e6c50f6b26330d9caf.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

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

[Svante Signell]

On Tue, 2018-03-27 at 00:49 +0200, Samuel Thibault wrote:
> Svante Signell, on lun. 26 mars 2018 19:50:58 +0200, wrote
> 
> Well, a month is a long time indeed. I guess he needed to move forward,
> so he dropped; no big deal.

Yes it is a big deal. If somebody spends numerous (spare time, unpaid) hours
porting gccgo to Hurd and that work is thrown away then this _is_ a big deal.

> But we don't care about previous versions but the last version.

See below.

> My point is: no, it's not obvious to just commit and forget.  While it
> *is* obvious to just fix what's currently there.  If you don't see why
> that commit was a move forward concerning Debian, please do check its
> consequences and think about it.

??

> > As I wrote in that bug report, all needed patches are there. And as the bug
> > report says: gcc-8 (8-8-20180321-1 and earlier) was successfully built.
> 
> But that's not the latest version, as you said it, even.

??
Latest released Debian version of gcc-8 is 8-8-20180321-1, see
https://buildd.debian.org/status/package.php?p=gcc-8=sid

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

[Samuel Thibault]

Svante Signell, on lun. 26 mars 2018 19:50:58 +0200, wrote:
> On Mon, 2018-03-26 at 19:42 +0200, Samuel Thibault wrote:
> > Svante Signell, on lun. 26 mars 2018 19:20:04 +0200, wrote:
> > > 
> > > 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.
> 
> Me being AFK for a month gives him reason to claim the the patches are un-
> maintined. Not nice :(

Well, a month is a long time indeed. I guess he needed to move forward,
so he dropped; no big deal.

> > > 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-b12c2c48c2c6aa1db9e6c50f6b26330d9caf.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.
> 
> All this stuff is from earlier mails. Additionally the versions built with the
> patches were reported.

But we don't care about previous versions but the last version.

My point is: no, it's not obvious to just commit and forget.  While it
*is* obvious to just fix what's currently there.  If you don't see why
that commit was a move forward concerning Debian, please do check its
consequences and think about it.

> > Then eventually try to build the whole thing, possibly realize it
> > doesn't actually build, etc. etc. Not a piece of cake, really.
> 
> As I wrote in that bug report, all needed patches are there. And as the bug
> report says: gcc-8 (8-8-20180321-1 and earlier) was successfully built.

But that's not the latest version, as you said it, even.

Samuel

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

[James Clarke]

On 26 Mar 2018, at 18:20, Svante Signell  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=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. Adding
> them back is a piece of cake for you (or him), see #894080.
> 
> Next step is to send them to golang-dev for upstream adoption. gcc-patches 
> seems
> to be a null sink. Sending patches there gives no reply whatsoever: Recent
> examples gdb and gccgo.

The best place for them is https://go-review.googlesource.com against 
go-frontend.

James

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

[Svante Signell]

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=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. Adding
them back is a piece of cake for you (or him), see #894080.

Next step is to send them to golang-dev for upstream adoption. gcc-patches seems
to be a null sink. Sending patches there gives no reply whatsoever: Recent
examples gdb and gccgo.

> > 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 :(

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

[Samuel Thibault]

Svante Signell, on lun. 26 mars 2018 18:50:20 +0200, wrote:
> I just saw:
> https://anonscm.debian.org/viewvc/gcccvs?view=revision=10084
> 
> This is really a large step BACK:

It's not a step back, it's just fixing something that is completely
wrong.

> 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.

Samuel

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

[Svante Signell]

Hi Samuel,

I just saw:
https://anonscm.debian.org/viewvc/gcccvs?view=revision=10084

This is really a large step BACK: Since you could issue that commit to _disable_
gccgo for Hurd, what about committing to _enable_ gccgo for Hurd instead. I just
filed a bug for gcc-8 to build gccgo again: https://bugs.debian.org/cgi-bin/bugr
eport.cgi?bug=894080

Thanks!