hppa in lenny? (Was: Freeze exceptions related to libdb-ruby)

[Lucas Nussbaum]

Hi,

On 16/08/08 at 17:35 +0100, Adeodato Simó wrote:

> * Michael Schutte [Sat, 16 Aug 2008 18:02:01 +0200]:
>
> > On Sat, Aug 16, 2008 at 04:51:59PM +0100, Adeodato Simó wrote:
> > > * Michael Schutte [Sat, 16 Aug 2008 17:08:32 +0200]:
>
> > > > May I now ask you to force libdb-ruby into Lenny?
>
> > > We need it built on hppa, so you'll have to ask somebody with an hppa
> > > machine to build it for you... (Maybe Frank Lichtenheld or Domenico
> > > Andreoli.)
>
> > See [1].  So I guess there is no real agreement on this?
> > [1] http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/2008-August/003010.html
>
> Lucas is right that forcing it into testing without hppa is one
> possibility that the release team has.
>
> However, I am not arbitrarily deciding not to use it and ask you to go
> out of your way instead to get it built on hppa.
>
> The reason is that if libdb-ruby/0.6.5-1 does not get build on hppa one
> way or another, it will be literally impossible to drop libdb4.[234]-ruby
> from Lenny, which I believe was your initial goal...
>
> Hope this helps to clear things up a bit.

ruby1.9 is broken on hppa: 1.9.0.1, that previously built fine (it's in
the archive) exhibits the same problems as 1.9.0.2 and 1.9.0.3.

I spent hours trying to do the hppa porters' work by investigating the
ruby1.9 build failure, with no success (and no help from the hppa
porters, except giving me access to an hppa machine, since hppa doesn't
have any developer-accessible machine maintained by DSA).

In [1], the state of hppa was already raised, and, while no real
conclusion has been drawn from this thread, it seems that, while most
people involved on hppa find it very sad (which I agree with), the right
thing to do is to drop hppa from the list of official archs for lenny,
since it's unlikely to be a "good" stable arch.

So far, I haven't heard any official position from the release team
about that, and we are 3 weeks away from the release according to Neil's
talk.

[1] http://lists.debian.org/debian-hppa/2008/07/msg00044.html

Thank you,
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Adeodato Simó-4]

* Lucas Nussbaum [Sat, 16 Aug 2008 14:10:16 -0300]:

> ruby1.9 is broken on hppa: 1.9.0.1, that previously built fine (it's in
> the archive) exhibits the same problems as 1.9.0.2 and 1.9.0.3.

> I spent hours trying to do the hppa porters' work by investigating the
> ruby1.9 build failure, with no success (and no help from the hppa
> porters, except giving me access to an hppa machine, since hppa doesn't
> have any developer-accessible machine maintained by DSA).

> In [1], the state of hppa was already raised, and, while no real
> conclusion has been drawn from this thread, it seems that, while most
> people involved on hppa find it very sad (which I agree with), the right
> thing to do is to drop hppa from the list of official archs for lenny,
> since it's unlikely to be a "good" stable arch.

> So far, I haven't heard any official position from the release team
> about that,

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, and if it persists, to kill ruby1.9 on hppa so that
we get that part of the archive on a releseable state.

> [1] http://lists.debian.org/debian-hppa/2008/07/msg00044.html

Cheers,

--
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
                                         Listening to: James Blunt - Cry


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 16/08/08 at 21:09 +0100, Adeodato Simó wrote:

> 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, and if it persists, to kill ruby1.9 on hppa so that
> we get that part of the archive on a releseable state.

I also investigated the other possibility (killing ruby1.9 on hppa), but
it's not easy, since ruby1.9 is a build-dependency for many packages.
Some of them are Ruby libs and could simply be NFUed as well, but others
are more annoying.

Sources packages affected:
ruby1.9 # NFU
libcairo-ruby # NFU
ruby-gnome2 # NFU (dep on libcairo-ruby)
libdb-ruby # NFU
libexif-ruby # NFU
libfcgi-ruby # NFU
libgpgme-ruby # NFU
libhpricot-ruby # NFU
libinotify-ruby # NFU
mapserver # NMU to remove ruby1.9 package?
ncurses-ruby # NFU
rrdtool # NMU to remove ruby1.9 package?
stfl # NMU to remove ruby1.9 package?

The list was generated manually. It might make sense to process those
packages, and then play with edos-(build)?debcheck to pick up the other
packages.

I won't have time to work on that.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Helge Deller-3]

Adeodato Simó wrote:

> * Lucas Nussbaum [Sat, 16 Aug 2008 14:10:16 -0300]:
>
>> ruby1.9 is broken on hppa: 1.9.0.1, that previously built fine (it's in
>> the archive) exhibits the same problems as 1.9.0.2 and 1.9.0.3.
>
>> I spent hours trying to do the hppa porters' work by investigating the
>> ruby1.9 build failure, with no success (and no help from the hppa
>> porters, except giving me access to an hppa machine, since hppa doesn't
>> have any developer-accessible machine maintained by DSA).
>
>> In [1], the state of hppa was already raised, and, while no real
>> conclusion has been drawn from this thread, it seems that, while most
>> people involved on hppa find it very sad (which I agree with), the right
>> thing to do is to drop hppa from the list of official archs for lenny,
>> since it's unlikely to be a "good" stable arch.
>
>> So far, I haven't heard any official position from the release team
>> about that,
>
> 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.
Instead, I think only when at some point the glibc on hppa switches to
NPTL, ruby could work.

[*2] http://permalink.gmane.org/gmane.comp.lib.glibc.cvs/25637


 > and if it persists, to kill ruby1.9 on hppa so that
> we get that part of the archive on a releseable state.

Probably the best idea, unless my hand-built (and partly buggy) ruby19
binaries on http://gsyprf10.external.hp.com/~deller/ruby/ may help (see
my other mail on the debian-hppa list).

>> [1] http://lists.debian.org/debian-hppa/2008/07/msg00044.html
>
> Cheers,
>


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Pierre Habouzit-2]

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 ;
  (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@...
OOO                                                http://www.madism.org

[Pierre Habouzit-2]

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@...
OOO                                                http://www.madism.org

[dann frazier]

On Sun, Aug 17, 2008 at 01:14:01AM +0200, Helge Deller wrote:

> Adeodato Sim?? wrote:
>> * Lucas Nussbaum [Sat, 16 Aug 2008 14:10:16 -0300]:
>>> ruby1.9 is broken on hppa: 1.9.0.1, that previously built fine (it's in
>>> the archive) exhibits the same problems as 1.9.0.2 and 1.9.0.3.
>>> I spent hours trying to do the hppa porters' work by investigating the
>>> ruby1.9 build failure, with no success (and no help from the hppa
>>> porters, except giving me access to an hppa machine, since hppa doesn't
>>> have any developer-accessible machine maintained by DSA).
>>> In [1], the state of hppa was already raised, and, while no real
>>> conclusion has been drawn from this thread, it seems that, while most
>>> people involved on hppa find it very sad (which I agree with), the right
>>> thing to do is to drop hppa from the list of official archs for lenny,
>>> since it's unlikely to be a "good" stable arch.
>>> So far, I haven't heard any official position from the release team
>>> about that,
>> 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.
> Instead, I think only when at some point the glibc on hppa switches to
> NPTL, ruby could work.

hey Helge!
 fyi, John Wright and I have had a buildd running w/ an NPTL glibc for
a while, and we're not having any better luck with ruby1.9 builds -
they seem to fail just as before ('miniruby' spinning indefinitely).

In general, I haven't noticed any better or worse behavior between
linuxthread/NPTL buildds.

> [*2] http://permalink.gmane.org/gmane.comp.lib.glibc.cvs/25637
>
>
> > and if it persists, to kill ruby1.9 on hppa so that
>> we get that part of the archive on a releseable state.
>
> Probably the best idea, unless my hand-built (and partly buggy) ruby19
> binaries on http://gsyprf10.external.hp.com/~deller/ruby/ may help (see my
> other mail on the debian-hppa list).
>
>>> [1] http://lists.debian.org/debian-hppa/2008/07/msg00044.html
>> Cheers,
>
>
> --
> To UNSUBSCRIBE, email to debian-release-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@...
>

--
dann frazier


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Helge Deller-3]

dann frazier wrote:

> On Sun, Aug 17, 2008 at 01:14:01AM +0200, Helge Deller wrote:
>> Adeodato Sim?? wrote:
>> I just looked into ruby19 on hppa.
>> The makecontext()/setcontext()/switchcontext() functions which went into
>> libc-ports recently [*2] will not help here.
>> Instead, I think only when at some point the glibc on hppa switches to
>> NPTL, ruby could work.
>
> hey Helge!
>  fyi, John Wright and I have had a buildd running w/ an NPTL glibc for
> a while, and we're not having any better luck with ruby1.9 builds -
> they seem to fail just as before ('miniruby' spinning indefinitely).
>
> In general, I haven't noticed any better or worse behavior between
> linuxthread/NPTL buildds.

Hi Dan,

Thanks for testing it! That's interesting. It was always my assumption,
that NPTL would fix a few problems. If this is not the case, then it's
time to look into the glibc/linuxthreads/NPTL coding again. I'll try to
find some time this week to analyze that, but sadly debugging
thread-issues is not easy nor really funny :-(

Helge


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[dann frazier]

On Mon, Aug 18, 2008 at 08:34:17PM +0200, Helge Deller wrote:

> dann frazier wrote:
>> On Sun, Aug 17, 2008 at 01:14:01AM +0200, Helge Deller wrote:
>>> Adeodato Sim?? wrote:
>>> I just looked into ruby19 on hppa.
>>> The makecontext()/setcontext()/switchcontext() functions which went into
>>> libc-ports recently [*2] will not help here.
>>> Instead, I think only when at some point the glibc on hppa switches to
>>> NPTL, ruby could work.
>> hey Helge!
>>  fyi, John Wright and I have had a buildd running w/ an NPTL glibc for
>> a while, and we're not having any better luck with ruby1.9 builds -
>> they seem to fail just as before ('miniruby' spinning indefinitely).
>> In general, I haven't noticed any better or worse behavior between
>> linuxthread/NPTL buildds.
>
> Hi Dan,
>
> Thanks for testing it! That's interesting. It was always my assumption,
> that NPTL would fix a few problems. If this is not the case, then it's time
> to look into the glibc/linuxthreads/NPTL coding again. I'll try to find
> some time this week to analyze that, but sadly debugging thread-issues is
> not easy nor really funny :-(

hey Helge,
 Thank you for making an effort to help us here. If having an NPTL
chroot would help, let me know. We're publishing the autobuilt NPTL
bits here:
  http://parisc-linux.org/~dannf/hppa-nptl-mirror/
I don't think it has all of base built yet, but I can tar up our build
chroot if necessary.

--
dann frazier


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Schutte-2]

On Sun, Aug 17, 2008 at 01:14:01AM +0200, Helge Deller wrote:
> Probably the best idea, unless my hand-built (and partly buggy) ruby19
> binaries on http://gsyprf10.external.hp.com/~deller/ruby/ may help (see my
> other mail on the debian-hppa list).

May I politely ask you to consider the libdb-ruby packages provided by
Helge?  Or is it a problem that the changes file isn’t signed?

Sorry for my bugging, but there is not much I can do beyond that :-)

--
Michael Schutte <michi@...>

[Adeodato Simó-4]

* Michael Schutte [Tue, 19 Aug 2008 21:32:42 +0200]:

> On Sun, Aug 17, 2008 at 01:14:01AM +0200, Helge Deller wrote:
> > Probably the best idea, unless my hand-built (and partly buggy) ruby19
> > binaries on http://gsyprf10.external.hp.com/~deller/ruby/ may help (see my
> > other mail on the debian-hppa list).

> May I politely ask you to consider the libdb-ruby packages provided by
> Helge?  Or is it a problem that the changes file isn’t signed?

It's a problem that he doesn't seem to be a DD. I've asked a DD with
access to hppa to build libdb-ruby for you.

> Sorry for my bugging, but there is not much I can do beyond that :-)

No problem, let's keep moving this libdb-ruby transition forward.

Cheers,

--
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Will you just stand still?
                -- Luke Danes


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...