piuparts mass bug filing, summary
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
Reply to: