Hi, I'm trying to build gcc-3.0 manually because the autobuilder on m68k just timeout on it. So all this takes gcc-3.0 as example, nothing personal. This is more about improving the autobuilders.
Doing a test compile on i386 (way faster to check build-depends and general errors there) I noticed that the selftests of gcc had unexpected failures. But since that happens all the time the results of the selftests are just ignored and the build succeeds. The reason being that otherwise there would never be a successfull build, esspecialy for the MHz challenged archs. But neigther failing nor succeeding seems to be right here. My suggestion would be to have a target "selftests" in debian/rules. During build that should be called to carry out the selftests (if any). Now two things can happen: - The selftests work fine. The package completes its build and gets uploaded to unstable. (the build succeeds). - The selftests fail. The package gets flaged as suspect because of selftest failures and uploaded to experimental or selftest-failures or so. Then someone can take a look at the debs and check what caused the selftest failures. If its nothing serious (like outdated testcases) the package can still be released. If its something serious, he can patch it and upload a new version. Why not just fail the build when the selftest fails? Many packages build multiple debs. Many take very long to build, esspecially those with selftests. A selftest failure in for example the libjava portion of gcc should not hold back all other gcc packages. The debs should still be build and then the maintainer can move everything but libjava.deb to incoming. Comments, ideas, flames? Goswin