On Wed, Sep 22, 2004 at 11:44:30PM -0500, Rob Browning wrote: > Summary: An RC bug has been filed claiming that stalin's source is > "too big" and that it shouldn't be built for m68k (and I'd presume > arm), though it has been built on both in the past. So I'd like to > figure out what action, if any, would be appropriate. The bug report isn't about whether the package *should* be built for m68k and arm, it's about whether it *can* be built for m68k and arm. > A bit back, a new version of stalin was uploaded which was intended > for testing. It has built for i386 and sparc, but hasn't built yet > for m68k or arm (though we have packages of the previous version for > both of those architectures). The packages for m68k were removed from unstable a while ago. > The arm build was attempted, but failed, most likely because it wasn't > given enough time; I asked about extending the build time on arm, but > never heard back. The last successful build on arm took < 3 hours; the most recent build failure there spent 5 hours trying to compile the C file in question without finishing it. There may be a difference in the relative power of smackdown and netwinder that explains this, or there may be toolchain differences that account for it. OTOH, this could also be a sign of a regression in the stalin sources between 0.9 and 0.9+0.10alpha2. > While I'm not very inclined to agree that the size of the source is a > release critical bug, especially since we've already been providing > packages for those architectures. I am willing to consider dropping > support for slower architectures if that's the "right thing to do". > Thoughts? Any relevant policy I might have overlooked? If the current toolchain is less forgiving than the version last used to build the package on arm, and it's no longer possible to build the package using the available build environments, we have an RC bug because we shouldn't ship binaries that we know we can't provide critical updates for. If the failure is caused by source changes in stalin itself that make the package more resource-intensive to build, we again have a serious bug (though only applicable to unstable) if the arm porters feel it's not reasonable to accomodate the package's build requirements. If you and the arm buildd maintainers can't come to an agreement that lets stalin build again on this architecture, the out-of-date binaries will need to be removed from the archive by an ftp-master. FWIW, since the problematic source file is in fact generated by stalin, and is exemplary of the kind of C code stalin generates in the course of normal use, I'd question how useful this package is on architectures that have a hard time building it. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature