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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
