Re: Samuel: Do you have permission to _enable_ the gccgo patches again?
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-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: Upstreaming the glibc Hurd port
On Tue, 2018-03-27 at 00:50 +0200, Samuel Thibault wrote: > Svante Signell, on lun. 26 mars 2018 23:53:31 +0200, wrote: > > On Mon, 2018-03-19 at 02:52 +0100, Samuel Thibault wrote: > > > Samuel Thibault, on lun. 19 mars 2018 02:51:22 +0100, wrote: > > > > - Fixing GNU Coding Style, notably first line of files. > > > > > > Could people have a look in the libpthread repository? > > > Most probably, for a lot of these files, one can just take the first > > > line of the corresponding nptl file and put "Hurd version". > > > > Which branch, or master?? > > http://git.savannah.gnu.org/cgit/hurd/libpthread.git/ > > Master, simply. It would be nice if you could be more explicit next time when writing such mails. I cannot divine into your thoughts :D
Re: Samuel: Do you have permission to _enable_ the gccgo patches again?
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&suite=sid
Re: Upstreaming the glibc Hurd port
Hello Samuel, 19.03.2018 02:51 Samuel Thibault wrote: > > Hello, > > Thanks a lot for the feedback on what needs to be done. It was a busy > week-end :) I appreciate your work. :-) Sorry for a kinda off-topic but could you please visit the Patchwork site [1] and mark your committed patches as committed, or ask someone to do it for you? I'm asking in public because there are lots of patches from other people as well, also this makes a chance for someone to respond in case if I'm too overzealous. Thank you. Regards, Rafal [1] https://patchwork.sourceware.org/project/glibc/list/
Re: Upstreaming the glibc Hurd port
Svante Signell, on lun. 26 mars 2018 23:53:31 +0200, wrote: > On Mon, 2018-03-19 at 02:52 +0100, Samuel Thibault wrote: > > Samuel Thibault, on lun. 19 mars 2018 02:51:22 +0100, wrote: > > > - Fixing GNU Coding Style, notably first line of files. > > > > Could people have a look in the libpthread repository? > > Most probably, for a lot of these files, one can just take the first > > line of the corresponding nptl file and put "Hurd version". > > Which branch, or master?? > http://git.savannah.gnu.org/cgit/hurd/libpthread.git/ Master, simply. Samuel
Re: Samuel: Do you have permission to _enable_ the gccgo patches again?
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: Upstreaming the glibc Hurd port
On Mon, 2018-03-19 at 02:52 +0100, Samuel Thibault wrote: > Samuel Thibault, on lun. 19 mars 2018 02:51:22 +0100, wrote: > > - Fixing GNU Coding Style, notably first line of files. > > Could people have a look in the libpthread repository? > Most probably, for a lot of these files, one can just take the first > line of the corresponding nptl file and put "Hurd version". Which branch, or master?? http://git.savannah.gnu.org/cgit/hurd/libpthread.git/
Re: Samuel: Do you have permission to _enable_ the gccgo patches again?
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 :( > > 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. > 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.
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-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. Samuel
Re: Samuel: Do you have permission to _enable_ the gccgo patches again?
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&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?
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. 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?
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. > 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?
Hi Samuel, I just saw: https://anonscm.debian.org/viewvc/gcccvs?view=revision&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!
