Re: hppa release status
On Sun, Jun 08, 2008 at 09:46:17PM +0200, Andreas Barth wrote: Hi, I've waited a while to weigh in on this. Anyway, I don't particularly much care for stable releases. I have no problems with HPPA being punted from lenny and existing only as sid, as long as people still take patches to fix the issues without the release-critical bug burden over their heads. Holding up Debian because of a minority of people with a small amount of time to work on things doesn't seem entirely fair. I would encourage anyone who disagrees to step up and put actions before mails. regards, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
Kyle McMartin wrote: Anyway, I don't particularly much care for stable releases. I have no problems with HPPA being punted from lenny and existing only as sid, as long as people still take patches to fix the issues without the release-critical bug burden over their heads. Holding up Debian because of a minority of people with a small amount of time to work on things doesn't seem entirely fair. This could mean losing D-I support for hppa. The whole D-I infrastructure is built around having a usable testing. If hppa abandons stable releases and thus is no longer included in testing, I personally will immediately stop investing any energy in hppa D-I and may argue for dropping it, especially if nobody else takes any interest. I also doubt that Debian in general will allow architectures to only have a presence in unstable. It's much more likely that hppa would at some point be relegated to http://www.debian-ports.org/. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: hppa release status
answer with my glibc hat on On Thu, Jun 12, 2008 at 03:39:07PM +, James Bottomley wrote: On Tue, 2008-06-10 at 23:44 +0200, Helge Deller wrote: My personal feeling is, that a switch to NPTL is probably the best solution. Even if this involves a abi change. Maybe experts on NPTL could comment here? Well ... we asked for a switch to NPTL over a year ago, raising the ABI change issue (and requesting glibc6.1 or something similar). At that time there was a resounding lack of interest from Debian. Ordinary release logic does say that you shouldn't rev an ABI just before a release. However debian release logic seems to require some type of crisis before we can get nptl in, so if this is it ... This is totally unfair, at the time Carlos said that it was probable that the ABI bump wasn't necessary but that he needed some time to figure it out and. I've seen absolutely no hard push for NPTL at the time, and except python2.5 (and again it's still remain to be proven it's LT related) we've seen no issue on hppa with linuxthreads so far. So I remain convinced that it's better to see if the ABI bump can be avoided or not, and if it can't, we can do it in lenny+1 OK. Actually, I can't reproduce this on ion, which is my debian testing build box. The only difference from a normal testing system is that it's running 2.6.26-rc1 (it's also a pa8800 which makes its coherency a bit more stringent). Building python 2.5.2-6 and running all the built in tests except the two parisc exceptions runs. Ryan Murray stated that the failing test was test_sys, so this is what I get running it alone: [EMAIL PROTECTED] pwd /home/jejb/sources/python2.5-2.5.2/build-shared [EMAIL PROTECTED] ./python -E -tt ../Lib/test/regrtest.py -w -l -uall -s test_sys test_sys 1 test OK. So I think more investigation of the actual alleged failure is warranted. At this time, if it is a real failure, I'm not sure it's necessarily threads related. This is really coherent with our observations: LT is almost pure C, and kfreebsd uses LT and python works really well. So either it's a bug in the LT hppa specific code, or a kernel issue. Your tests tends to show the latter. So, with respect to the python2.5 issue, what now? At the technical side, best of course would be if linuxthreads would continue to work at least enough for lenny, this was the case for a few years already, it should be able to survive a few months more, and python2.5 can build with the test-suite on hppa. Of course not breaking the API during a linuxthreads - NPTL switch would be even better. I can't comment on that. I'll see if I can fix it whatever it is, but right now I need a reproducible test case. It looks like the current failure might be tied to whatever the buildd system was doing or some weird installation dependency it happens to have that I don't. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpZC7rYvRKD7.pgp Description: PGP signature
Re: hppa release status
Pierre Habouzit wrote: [snip] Actually, I can't reproduce this on ion, which is my debian testing build box. The only difference from a normal testing system is that it's running 2.6.26-rc1 (it's also a pa8800 which makes its coherency a bit more stringent). Building python 2.5.2-6 and running all the built in tests except the two parisc exceptions runs. Ryan Murray stated that the failing test was test_sys, so this is what I get running it alone: [EMAIL PROTECTED] pwd /home/jejb/sources/python2.5-2.5.2/build-shared [EMAIL PROTECTED] ./python -E -tt ../Lib/test/regrtest.py -w -l -uall -s test_sys test_sys 1 test OK. So I think more investigation of the actual alleged failure is warranted. At this time, if it is a real failure, I'm not sure it's necessarily threads related. This is really coherent with our observations: LT is almost pure C, and kfreebsd uses LT and python works really well. So either it's a bug in the LT hppa specific code, or a kernel issue. Your tests tends to show the latter. I recall a similiar failure on mips/mipsel went away after upgrading the buildd kernels to 2.6.24+. (I have no idea what version the hppa buildds use.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
On Fri, 13 Jun 2008, Thiemo Seufer wrote: I recall a similiar failure on mips/mipsel went away after upgrading the buildd kernels to 2.6.24+. (I have no idea what version the hppa buildds use.) peri and penalosa both use a 2.6.24 etch 1/2 kernel. -- weasel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
On Tue, 2008-06-10 at 23:44 +0200, Helge Deller wrote: CC'ed: parisc-linux kernel development list Andreas Barth wrote: during the upload of python2.5, the build failed on hppa due to stalls in the test suite, see http://bugs.debian.org/483042 and http://buildd.debian.org/fetch.cgi?pkg=python2.5ver=2.5.2-5arch=hppastamp=1211583145file=log (Matthias fixed that bug by disabling the testsuite, not something that makes us happy.) After that happened, we asked on #parisc if someone could take a look, and we were told that linuxthreads is currently unmaintained for hppa, and the issue could only be fixed by moving to nptl and we need to do an (incompatible) abi change in glibc. Such a change would be really unfortunate, and we hope that every other roads have been evaluated first (like trying to understand why python on linuxthreads fails on hppa but not on e.g. kfreebsd). We also would like to be sure that ntpl is really better than linuxthreads for python2.5 before a transition. My personal feeling is, that a switch to NPTL is probably the best solution. Even if this involves a abi change. Maybe experts on NPTL could comment here? Well ... we asked for a switch to NPTL over a year ago, raising the ABI change issue (and requesting glibc6.1 or something similar). At that time there was a resounding lack of interest from Debian. Ordinary release logic does say that you shouldn't rev an ABI just before a release. However debian release logic seems to require some type of crisis before we can get nptl in, so if this is it ... In addition to the python2.5 issue, there are two other issues that are quite concerning: * a problem with ruby1.9 which likely is kernel related #478717. Hmm.. Actually, I can't reproduce this on ion, which is my debian testing build box. The only difference from a normal testing system is that it's running 2.6.26-rc1 (it's also a pa8800 which makes its coherency a bit more stringent). Building python 2.5.2-6 and running all the built in tests except the two parisc exceptions runs. Ryan Murray stated that the failing test was test_sys, so this is what I get running it alone: [EMAIL PROTECTED] pwd /home/jejb/sources/python2.5-2.5.2/build-shared [EMAIL PROTECTED] ./python -E -tt ../Lib/test/regrtest.py -w -l -uall -s test_sys test_sys 1 test OK. So I think more investigation of the actual alleged failure is warranted. At this time, if it is a real failure, I'm not sure it's necessarily threads related. * dirmngr that segfaults, likely because of some signalstack issues #459567. Yes, we need to implement makecontext()/getcontext() in glibc. We've seen no porter activity on those bugs yet. I'd volunteer to try on thedirmngr/makecontext() issue. (At least as far as my time permits). On further discussing that within the release team, we noticed that the Qualification page on http://wiki.debian.org/hppaLennyReleaseRecertification is not really complete, e.g. it says: | The installer is being maintained by ... and it's currently working | effectively. Successful installation reports are available at: ... It would really be great (read: it is necessary) that the Qualification Page is filled with the missing information, and that we actually have enough porters for hppa. I've added myself there in a few items. I'd be willing to look into issues with the installer, but not being a active debian developer I'd need help from a debian guy if necessary. So, with respect to the python2.5 issue, what now? At the technical side, best of course would be if linuxthreads would continue to work at least enough for lenny, this was the case for a few years already, it should be able to survive a few months more, and python2.5 can build with the test-suite on hppa. Of course not breaking the API during a linuxthreads - NPTL switch would be even better. I can't comment on that. I'll see if I can fix it whatever it is, but right now I need a reproducible test case. It looks like the current failure might be tied to whatever the buildd system was doing or some weird installation dependency it happens to have that I don't. James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
On Tue, Jun 10, 2008 at 09:44:55PM +, Helge Deller wrote: CC'ed: parisc-linux kernel development list Andreas Barth wrote: during the upload of python2.5, the build failed on hppa due to stalls in the test suite, see http://bugs.debian.org/483042 and http://buildd.debian.org/fetch.cgi?pkg=python2.5ver=2.5.2-5arch=hppastamp=1211583145file=log (Matthias fixed that bug by disabling the testsuite, not something that makes us happy.) After that happened, we asked on #parisc if someone could take a look, and we were told that linuxthreads is currently unmaintained for hppa, and the issue could only be fixed by moving to nptl and we need to do an (incompatible) abi change in glibc. Such a change would be really unfortunate, and we hope that every other roads have been evaluated first (like trying to understand why python on linuxthreads fails on hppa but not on e.g. kfreebsd). We also would like to be sure that ntpl is really better than linuxthreads for python2.5 before a transition. My personal feeling is, that a switch to NPTL is probably the best solution. Even if this involves a abi change. Maybe experts on NPTL could comment here? The NPTL in glibc works well afaict, the downside is the ABI bump, because doing the archive-wide rebuild as a 66% chance to hurt the port so bad that it will not be ready in time for lenny. This is a last resort measure, and everything _must_ be tried before, because even losing a week trying to fix linuxthreads is way faster than rebuilding the whole archive which is rather a matter of months and risking no HPPA at all in the end. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp4ftAkSAKuc.pgp Description: PGP signature
Re: hppa release status
CC'ed: parisc-linux kernel development list Andreas Barth wrote: during the upload of python2.5, the build failed on hppa due to stalls in the test suite, see http://bugs.debian.org/483042 and http://buildd.debian.org/fetch.cgi?pkg=python2.5ver=2.5.2-5arch=hppastamp=1211583145file=log (Matthias fixed that bug by disabling the testsuite, not something that makes us happy.) After that happened, we asked on #parisc if someone could take a look, and we were told that linuxthreads is currently unmaintained for hppa, and the issue could only be fixed by moving to nptl and we need to do an (incompatible) abi change in glibc. Such a change would be really unfortunate, and we hope that every other roads have been evaluated first (like trying to understand why python on linuxthreads fails on hppa but not on e.g. kfreebsd). We also would like to be sure that ntpl is really better than linuxthreads for python2.5 before a transition. My personal feeling is, that a switch to NPTL is probably the best solution. Even if this involves a abi change. Maybe experts on NPTL could comment here? In addition to the python2.5 issue, there are two other issues that are quite concerning: * a problem with ruby1.9 which likely is kernel related #478717. Hmm.. * dirmngr that segfaults, likely because of some signalstack issues #459567. Yes, we need to implement makecontext()/getcontext() in glibc. We've seen no porter activity on those bugs yet. I'd volunteer to try on thedirmngr/makecontext() issue. (At least as far as my time permits). On further discussing that within the release team, we noticed that the Qualification page on http://wiki.debian.org/hppaLennyReleaseRecertification is not really complete, e.g. it says: | The installer is being maintained by ... and it's currently working | effectively. Successful installation reports are available at: ... It would really be great (read: it is necessary) that the Qualification Page is filled with the missing information, and that we actually have enough porters for hppa. I've added myself there in a few items. I'd be willing to look into issues with the installer, but not being a active debian developer I'd need help from a debian guy if necessary. So, with respect to the python2.5 issue, what now? At the technical side, best of course would be if linuxthreads would continue to work at least enough for lenny, this was the case for a few years already, it should be able to survive a few months more, and python2.5 can build with the test-suite on hppa. Of course not breaking the API during a linuxthreads - NPTL switch would be even better. I can't comment on that. If really you see no other option than switching to NPTL, even at the current unfortunate moment, the only way how this could be done in a timely fashion would be to exempt hppa from the list of architectures our testing migration scripts look at for updateness and non-breakness. Then upload glibc ASAP, and schedule an archive-wide binNMU campaign. Of course, this demands enough buildd power, and wanna-build access by (some of) the porters (or whatever else you consider appropriate). Moreover it needs quite a lot of time to track that closely, which the Release Team probably won't have on its own, so we will need hppa buildd-admin and hppa porters time, a lot. After the transition is done (and we can only hope it is in time for lenny), hppa could be added back to the normal architectures. Downside of this is of course that in case hppa is slower than lenny, lenny would be released without hppa. which would be sad... Of course, we also need plans for the ruby and dirmngr issues. Yes. So, after that long mail, what's your take on this? How do we continue? Any other comments? Helge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
On Tue, Jun 10, 2008 at 11:44:55PM +0200, Helge Deller wrote: CC'ed: parisc-linux kernel development list Andreas Barth wrote: during the upload of python2.5, the build failed on hppa due to stalls in the test suite, see http://bugs.debian.org/483042 and http://buildd.debian.org/fetch.cgi?pkg=python2.5ver=2.5.2-5arch=hppastamp=1211583145file=log (Matthias fixed that bug by disabling the testsuite, not something that makes us happy.) After that happened, we asked on #parisc if someone could take a look, and we were told that linuxthreads is currently unmaintained for hppa, and the issue could only be fixed by moving to nptl and we need to do an (incompatible) abi change in glibc. Such a change would be really unfortunate, and we hope that every other roads have been evaluated first (like trying to understand why python on linuxthreads fails on hppa but not on e.g. kfreebsd). We also would like to be sure that ntpl is really better than linuxthreads for python2.5 before a transition. My personal feeling is, that a switch to NPTL is probably the best solution. Even if this involves a abi change. Maybe experts on NPTL could comment here? In addition to the python2.5 issue, there are two other issues that are quite concerning: * a problem with ruby1.9 which likely is kernel related #478717. Hmm.. * dirmngr that segfaults, likely because of some signalstack issues #459567. Yes, we need to implement makecontext()/getcontext() in glibc. We've seen no porter activity on those bugs yet. I'd volunteer to try on thedirmngr/makecontext() issue. (At least as far as my time permits). On further discussing that within the release team, we noticed that the Qualification page on http://wiki.debian.org/hppaLennyReleaseRecertification is not really complete, e.g. it says: | The installer is being maintained by ... and it's currently working | effectively. Successful installation reports are available at: ... It would really be great (read: it is necessary) that the Qualification Page is filled with the missing information, and that we actually have enough porters for hppa. I've added myself there in a few items. I'd be willing to look into issues with the installer, but not being a active debian developer I'd need help from a debian guy if necessary. hey Helge, Feel free to contact me if you need something done that requires DD privs. So, with respect to the python2.5 issue, what now? At the technical side, best of course would be if linuxthreads would continue to work at least enough for lenny, this was the case for a few years already, it should be able to survive a few months more, and python2.5 can build with the test-suite on hppa. Of course not breaking the API during a linuxthreads - NPTL switch would be even better. I can't comment on that. If really you see no other option than switching to NPTL, even at the current unfortunate moment, the only way how this could be done in a timely fashion would be to exempt hppa from the list of architectures our testing migration scripts look at for updateness and non-breakness. Then upload glibc ASAP, and schedule an archive-wide binNMU campaign. Of course, this demands enough buildd power, and wanna-build access by (some of) the porters (or whatever else you consider appropriate). Moreover it needs quite a lot of time to track that closely, which the Release Team probably won't have on its own, so we will need hppa buildd-admin and hppa porters time, a lot. After the transition is done (and we can only hope it is in time for lenny), hppa could be added back to the normal architectures. Downside of this is of course that in case hppa is slower than lenny, lenny would be released without hppa. which would be sad... Of course, we also need plans for the ruby and dirmngr issues. Yes. So, after that long mail, what's your take on this? How do we continue? Any other comments? Helge -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
Andreas Barth wrote: On further discussing that within the release team, we noticed that the Qualification page on http://wiki.debian.org/hppaLennyReleaseRecertification is not really complete, e.g. it says: | The installer is being maintained by ... and it's currently working | effectively. Successful installation reports are available at: ... As I've mentioned before [1] I do maintain the installer for hppa to some degree. There is no serious known breakage and all D-I releases (unstable and stable) get tested on my own hppa box. We also do get occasional installation reports, either on the d-hppa list or in the BTS, but those are few and far between. The work I do on D-I for hppa is done as part of my general D-I work, but I am not a hppa porter and have little to no knowledge of hppa hardware other than my own box [2]. For that reason I'm not willing to have my name at is being maintained by but I am willing to vouch for it's currently working effectively. Some porter involvement is needed for _all_ Debian ports to keep support in Debian Installer at an acceptable level. In the past Kyle has done this for hppa (and he still does take care of the daily D-I builds), and I'd be more than happy to work with Helge if he's willing to take over that role. Note that hppa is not the only port that is lacking substantial porter involvement in D-I. Others are powerpc and sparc. As I also have a sparc box, the status of D-I for sparc is similar to hppa as described above. Cheers, FJP [1] http://lists.debian.org/debian-hppa/2008/05/msg00037.html [2] a bulky but nice 785/J5600 signature.asc Description: This is a digitally signed message part.
hppa release status
Hi, during the upload of python2.5, the build failed on hppa due to stalls in the test suite, see http://bugs.debian.org/483042 and http://buildd.debian.org/fetch.cgi?pkg=python2.5ver=2.5.2-5arch=hppastamp=1211583145file=log (Matthias fixed that bug by disabling the testsuite, not something that makes us happy.) After that happened, we asked on #parisc if someone could take a look, and we were told that linuxthreads is currently unmaintained for hppa, and the issue could only be fixed by moving to nptl and we need to do an (incompatible) abi change in glibc. Such a change would be really unfortunate, and we hope that every other roads have been evaluated first (like trying to understand why python on linuxthreads fails on hppa but not on e.g. kfreebsd). We also would like to be sure that ntpl is really better than linuxthreads for python2.5 before a transition. In addition to the python2.5 issue, there are two other issues that are quite concerning: * a problem with ruby1.9 which likely is kernel related #478717. * dirmngr that segfaults, likely because of some signalstack issues #459567. We've seen no porter activity on those bugs yet. On further discussing that within the release team, we noticed that the Qualification page on http://wiki.debian.org/hppaLennyReleaseRecertification is not really complete, e.g. it says: | The installer is being maintained by ... and it's currently working | effectively. Successful installation reports are available at: ... It would really be great (read: it is necessary) that the Qualification Page is filled with the missing information, and that we actually have enough porters for hppa. So, with respect to the python2.5 issue, what now? At the technical side, best of course would be if linuxthreads would continue to work at least enough for lenny, this was the case for a few years already, it should be able to survive a few months more, and python2.5 can build with the test-suite on hppa. Of course not breaking the API during a linuxthreads - NPTL switch would be even better. If really you see no other option than switching to NPTL, even at the current unfortunate moment, the only way how this could be done in a timely fashion would be to exempt hppa from the list of architectures our testing migration scripts look at for updateness and non-breakness. Then upload glibc ASAP, and schedule an archive-wide binNMU campaign. Of course, this demands enough buildd power, and wanna-build access by (some of) the porters (or whatever else you consider appropriate). Moreover it needs quite a lot of time to track that closely, which the Release Team probably won't have on its own, so we will need hppa buildd-admin and hppa porters time, a lot. After the transition is done (and we can only hope it is in time for lenny), hppa could be added back to the normal architectures. Downside of this is of course that in case hppa is slower than lenny, lenny would be released without hppa. Of course, we also need plans for the ruby and dirmngr issues. So, after that long mail, what's your take on this? How do we continue? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
On Sun, Jun 8, 2008 at 9:46 PM, Andreas Barth [EMAIL PROTECTED] wrote: Of course, this demands enough buildd power, and wanna-build access by (some of) the porters (or whatever else you consider appropriate). Moreover it needs quite a lot of time to track that closely, which the Release Team probably won't have on its own, so we will need hppa buildd-admin and hppa porters time, a lot. After the transition is done (and we can only hope it is in time for lenny), hppa could be added back to the normal architectures. Downside of this is of course that in case hppa is slower than lenny, lenny would be released without hppa. Should the need arise, I can provide hppa buildd horsepower. I (pretty much) know how to run a buildd[0], thanks to lamont, and I can give root access to my cluster to whoever (provided minor trust checks) needs it (lamont already has it). Time is definitely something I have very little control over nowadays tho, but I'll try my best ;P HTH T-Bone [0] unless it has significantly changed in the last couple years: I ran the first autobuild effort for hppa ubuntu, and I'm currently running hppa/ia64/alpha autobuilders for debian-multimedia.org -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
