Re: Maintainers, porters, and burden of porting
On Sat, Sep 10, 2011 at 05:50:29PM +0000, brian m. carlson wrote:
> On Sat, Sep 10, 2011 at 01:27:01PM +0000, Felipe Sateler wrote:
> > On Thu, 08 Sep 2011 19:34:41 +0200, Andreas Barth wrote:
> > > I disagree with "let's first remove things". If a package like ruby
> > > doesn't build on sparc this bug report is RC exactly as long as sparc is
> > > a release arch. The release team has (and does) override such bug
> > > reports for testing migration if appropriate. Removing the binary
> > > package doesn't help at all but just makes things worse. So please don't
> > > do it, especially for packages with reverse dependencies.
> >
> > The big issue (as I understood from the OP) here is that the toolchain is
> > not keeping up. Why should the maintainers of other software be bothered
> > about that architecture?
>
> I think the major issue for a particular arch depends on that arch.
> For sparc, the majority of times I see posts to debian-sparc for porting
> issues, the problem is a bus error, which is not a toolchain issue.
> It's a buggy C/C++ code issue in the original package. Alignment issues
> are also noted on ia64, but there they're not as obvious since they
> cause a SIGSEGV, not a SIGBUS.
>
> In order to assist developers, I tried to write a library to enable
> alignment check on i386/amd64 for ease of debugging, but the C library
> does not function correctly with that enabled, so I gave up.
We have a few arches where the behaviour on unaligned access can
be controlled with prctl: ia64, hppa, powerpc, alpha. However,
I think at least most our hosts including buildds are set up to
not cause an error in that case. I would rather see people run it
with it enabled.
Kurt
Reply to: