(Bad) results of running piuparts over the whole archive
Hi,
First of all, I am sorry to come up with this so late in the release
process. While it is very easy for me to generate data (it only took
a few hours to generate this data using ~30 nodes from the Grid'5000
platform), I am clearly not able to process it as fast as it is
generated. I really think we should work on this, and create a small
team of people interested in analyzing such data, so I stop being the
bottleneck...
I ran piuparts two times, both times ignoring all failed tests other
than failed commands (installations / removals). The first time, I
only installed the packages, so a successful test means that the
package was installed successfully. The second time, I did a "normal"
piuparts run, installing and removing the pakage.
Numbers:
173 packages failed to install (failed during run 1). This includes a
lot of false positives. Documenting those would be great, but is a
tedious task. Also, I had a package (piuparts-hangers) installed to
avoid installing packages that are known to cause piuparts to hang.
332 packages installed OK, but failed to remove. I believe that the
number of false positives amongst those is very low (probably under
20%). Of course, it doesn't mean 332 possible RC bugs, since some
packages failed because of others (e.g bacula failed because
bacula-common). Popular reasons include:
149 /usr/share/debconf/confmodule: No such file or directory
44 (userdel|deluser): command not found
17 update-inetd: command not found
5 ucf: command not found
4 (groupdel|delgroup): command not found
All logs are available on
http://people.debian.org/~lucas/logs/2007/01/16/
What do we do with that ? In another piuparts campaign at the end of
last year, I filed quite a lot of bugs, but voluntarily ignored
missing depends on packages of priority >= important, and missing
depends on ucf (which is prio:optional), just to keep the number of
failures manageable. Should we concentrate on finding "important"
failures (packages with missing depends|pre-depends on packages with
priority < important), or do we want to consider all those bugs RC ?
Depending on the outcome, I could generate data specific to what we
want to find, to avoid some/most of the log reviewing.
Also, to avoid duplicating efforts, please don't start randomly filing
bugs about this. If we decide on processing those failures now, we
should figure out a way to do that efficiently (maybe a wiki page on
wiki.d.o ?).
Lucas
Reply to: