Re: build failure on sparc64 (was: Re: [cvs] SF.net SVN: bogofilter:[6834] trunk/bogofilter)
"Matthias Andree" <[email protected]> Thu, 25 Jun 2009 01:37:43 +0200
| Newsgroups | gmane.mail.bogofilter.devel |
|---|---|
| Message-ID | <[email protected]> |
Am 23.06.2009, 23:38 Uhr, schrieb Serafeim Zanikolas <[email protected]>: > Hi all, > > On Thu, May 28, 2009 at 05:23:26PM +0200, Matthias Andree wrote [edited]: >> Am 28.05.2009, 14:06 Uhr, schrieb <[email protected]>: >> >> > Revision: 6834 > [..] >> Note that these fixes were required for some systems that suffered build >> failures otherwise. > > As the new maintainer of bogofilter for Debian, I'd like to point out > that a test from bogofilter 1.2.0 has failed in sparc64: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526018 > > and then it built fine on a subsequent try (due to an irrelevant > re-upload which didn't change the source in any way). Unfortunately I > can't report how often this failure is, as I don't have access to a > sparc64 machine. > > Any feedback welcome. Hi Serafeim, welcome to the job, it's good to see that bogofilter packages for Debian continue to be maintained. I've just tested the SVN checkout (r6836) on an old Sun Ultra 5 (UltraSPARC IIi in the 333/400 MHz class) running Solaris 8 FCS (for lack of a sparc64 running Debian), and the build (GNU make, GCC 3.4.5) and all 52 tests (we're skipping t.valgrind and t.leakfind there) pass. I'd say there are two possibilities for the bug: - The earlier upload might really have been busted somehow. Auxiliary Debian build files can change even if the source does not - but I'm not saying this was the cause. - The bug submitter's computer had a temporary hicc-up. Such things happen, and if that was the case, I've seen several older SPARC computers (none with a 200X mfg date) show erratic behaviour and die a few weeks later, usually with a fatal backplane (mainboard) fault. SIGBUS as reported in #526018 would look like unaligned memory access which real processors such as M680x0, SPARC or MIPS do not like at all, so if the LSB of the PC register was somehow trashed, or a relocated jump address was, then this might have caused the problem. Do Debian SPARC kernels log corrected RAM errors when using ECC? If so, the submitter's log should be checked around crash time for issues with the memory or other hardware components. Hope that helps. Cheers -- Matthias Andree _______________________________________________ Bogofilter-dev mailing list [email protected] http://www.bogofilter.org/mailman/listinfo/bogofilter-dev