On Mon, Aug 18, 2008 at 01:10:56PM +0000, Pierre Habouzit wrote: > On Sat, Aug 16, 2008 at 11:14:01PM +0000, Helge Deller wrote: > > Adeodato Simó wrote: > > >hppa has certainly had trouble during this release cycle. However, it's > > >been mostly reduced to a small set of packages, and since (a) it has not > > >been the kind of brekage that prevents the release team from doing their > > >job (alpha buildd outages eg. have been more painful), and (b) the > > >architecture is not generally broken, it was decided not to use /our/ > > >veto power to kick it out of lenny. (No decision taken for lenny+1 in > > >either direction, though.) > > >I realize the ruby1.9 situation is frustrating, but I don't think it's > > >fair to drop hppa from lenny because of it. I don't think your "it's > > >unlikely to be a 'good' stable arch" is true either. > > >Otoh, it's really commendable, and I mean it, that you decided to spend > > >your time towards having it fixed, rather than just kill ruby1.9 on hppa > > >as I suggested (which is, tbh, what I would've done in your position). > > >It really sucks that no hppa person is available to help, but my opinion > > >is that's still more valuable to release with hppa without ruby1.9 > > >there, > > >than to drop hppa completely. > > >So, what I would like from a release POV is to wait at most for this > > >glibc -14 upload with context-fu on hppa that somebody somewhere said > > >could fix the issue, > > > > I just looked into ruby19 on hppa. > > The makecontext()/setcontext()/switchcontext() functions which went into > > libc-ports recently [*2] will not help here. > > Clearly not, Adeodato was confused, this would fix the dirmngr issue, > not ruby's. > > > Instead, I think only when at some point the glibc on hppa switches to > > NPTL, ruby could work. > > This is probably not going to happen, and there are two things: > (1) linuxthreads is mostly pure C, and ruby works fine on kfreebsd > that uses linuxthreads ; As an illustration, we were told that the python issue was likely to be a linuxthread issue, whereas in the end it is probably a way different issue, related to what caused the glibc FTBFS which was a glibc problem. I've not rebuilt a python with the test-suite enabled again on hppa, but I wouldn't be surprised at all (read I'm almost sure it would work) that it's fixed. And the bug was absolutely not hppa related, it only was seen on hppa for some odd reason though. So unless proven wrong, I see still no valid reason to hide kernel bugs behind a libpthread soname bump. > (2) it produces unkillable processes which points to a kernel bug, and > switching to NPTL wont't fix that kernel bug that is very likely > to be used as a local DOS, and needs to be addressed either way. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpPg87x6meGV.pgp
Description: PGP signature