Re: Releasability of the HPPA port
On Thu, Aug 5, 2010 at 9:30 PM, Philipp Kern <email@example.com> wrote:
> Dear HPPA porters, dear HPPA port users,
> the Release Team is currently wondering if it makes sense to release with
> HPPA as a regular stable architecture with squeeze. It might be that
> it is not up to the standards of a regular Debian release. We seem to
> chase random segmentation faults, causing multiple give-backs to eventually
> yield a built package.
There are two key problems:
(1) Incorrect vfork implementation.
(2) Kernel memory subsystem issues.
Issue (1) has been fixed in upstream glibc and should resolve some of
the vfork problems seen while building and testing packages.
Issue (2) has experimental patches that the community is testing. Not
all issues are understood but some are understood and the patches
increase system stability.
In my opinion these are the *only* two key problems that are causing
instability on hppa.
It is up to the Release Team to make a decision if these problems
represent a serious quality issue.
For the record I never have any serious problems on my SMP 64-bit
A500. However, as you crank up the load, like on the buildd's you
start seeing problem (2). Most users don't run buildd's and the
systems work as expected.
> Especially this is also causing concerns from a security building point of
> view, as autobuilding has to work for this.
> If it's not entirely up to our standards, would a separate suite, like it
> has been done in the past for etch-m68k, help having some sort of release that
> can be updated independently from the main stable release? Such a suite could
> also be useful to land larger changes than normally allowed for stable and
> maybe to continue the hppa port from a stable foundation for some time.
> I think we do agree that it will be included into stable for the last time.
Under which metrics or evaluation process is this decision being made?
"Glibc ports maintainer for hppa"