On Fri, Sep 26, 2003 at 11:37:06PM +0200, Joachim Breitner wrote: > sorry to bug you again, and for "escalating" this to debian-devel, but > something needs to be done. For those just joining us:
> gnucash (the probably most complete wand fit-for-real-use financing
> program in debian) is not in testing for sarge at all. While the package
> works very well for all users that get a binary, it just does not build
> on some architectures (arm, hppa, m68k, mips{,el}). The problem lies in
> the deep of some guile test in the gnucash testsuite, and is somehow
> related to a random generater. Anyway, the maintainer tried to fix it,
> upstream worked on it, but nothing helped yet, and nothing probably
> won't help - at least within the next few weeks.
> I would argue that it would be the best for our users if we put gnucash
> in testing on the arches it builds, and leave the others out until they
> are fixed. This would
> * give the majority (i386, powerpc, etc) of our future sarge users this
> program
> * have most of our woody users still have gnucash in their debian when
> they upgrade
> * is absolutely no worse for those on the failing architectures, since
> they won't have gnucash either way
> * if we fix the problem, we can add more architectures (for the same
> version) in a sarge-r1-release.
> The problem is that http://www.debian.org/devel/testing.en.html states:
> > 2. It must be compiled and up to date on all architectures it has
> previously been compiled for in unstable;
> So I am basically calling for an exception here.
What you are overlooking is that the main bug causing build failures
for gnucash is NOT architecture specific; rather, the potential for a
build failure appears to exist on all architectures, but the use of a
*pseudo*-RNG for generating test data tends to result in certain corner
cases being reliably hit in some build environments, and reliably
missed in others.
> PS: I wonder: why is the architecture count compared to prior versions
> in _unstable_, while the RC-Bug count is compared to the RC-Bug count of
> the perior version in _testing_? Seems to be inconsequent. Why not have
> the line say:
> > 2. It must be compiled and up to date on all architectures it has
> previously been compiled for in testing; ?
Because the principle is "if it built on the architecture at once, we
expect it to be buildable again unless given a good reason".
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
