Greetings from your friendly neighborhood package torturer. I ran piuparts on most of etch/main. This resulted in somewhere between one and two thousand failures. For a long time, I read and tried to figure out what the cause of each failure was. Eventually I gave up: there were too many failures that were caused by a dependency, and investigating each log file took way too much time. I concluded that there was no point in testing A, if it depends on B, and B is untested. And if B fails, well, testing of A will also fail, as far as piuparts is concerned.
Thus I wrote a small tool to run piuparts in this way. This resulted in much fewer failures, and in fact a manageable number. It means, however, that about two thirds of the archive isn't getting tested for now. At the moment, I'm all caught up with etch: all packages that can be tested with my scheme have been tested. I'll be running my script daily, and reporting any new failures as bugs (after the proper analysis, of course). I've filed bugs from all failed logs so far (not too many, only 66, I think: 319601, 325901, 325905, 325907, 325911, 325913, 325921, 325923, 326046, 326050, 326235, 326240, 326248, 326264, 326266, 327076, 327122, 327144, 327146, 327238, 327242, 327521, 327522, 327526, 327530, 327532, 327535, 327537, 327540, 327544, 327615, 328250, 328252, 328256, 328261, 328283, 328284, 328295, 328296, 328297, 328300, 328301, 328310, 328315, 328320, 328321, 328322, 328326, 328327, 328329, 328330, 328331, 328332, 328362, 328366, 328472, 328476, 328478, 328486, 328487, 328490, 328491, 328492, 328493, 328495, 328497; as you can see, some people are impolite enough to insert their bugs in the middle of my log processing runs, ruining my pretty consecutive numbers). Here's some statistics of the current situation: already-failed: 71 already-tested: 4234 dependency-untested: 10393 ignoring-important-required-essential: 122 unknown-dependency: 384 So, about ten thousand packages are waiting for a dependency to be tested first. Circular dependencies probably prevent most of those (if A depends on B, and B depends on A, neither will be tested with my current setup). I don't want to spend much time on breaking the circular chains to run piuparts: circular dependency chains tend to make the testing fail anyway at removal time (though not deterministically), so running piuparts on such can be a waste of time. Since I'm filing bugs on piuparts failures, and will include relevant information, I don't think there's much point in setting up a system for providing log files on the web. If you want them, mail me in private; if enough people do that, I'll reconsider. I may expand to contrib and non-free. I don't expect to write more summaries of this, unless there's unexpected surprises that overwhelm me. If you want to test a package, the following command works with piuparts 0.10 [1], on current sid, when run against etch: sudo piuparts -d etch -al liwc.log liwc If you add a "-s etch.tar.gz" option, piuparts will save the chroot it creates with debootstrap, and then you can replace that option with "-b etch.tar.gz" in future runs, which will be much faster. I run piuparts against etch instead of sid, because sid is in quite a turmoil, what with all the transitions going on. (For example, while testing the above command, I got errors about lib64gcc1.) I would like to see people use piuparts, or other ways, to test their packages before they upload them. This should catch all sorts of easy mistakes, such as failing to remove log files, or removing alternatives the wrong way. Remember: a piuparts a day keeps the torturer away from the bts. [1] I've just uploaded 0.10. It will probably take a day or so to be on the mirrors. You can get it from here in the mean time: http://liw.iki.fi/liw/temp/piuparts_0.10-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]