On Mon, Apr 07, 2008 at 11:46:24AM +0200, Lucas Nussbaum wrote: > What needs to be done is: > - run installation/removal/purge tests for all packages > - run upgrade tests for all packages in etch > - make changes to piuparts to fix false positives or reduce the number > of failures by ignoring the less critical ones > - file all the bugs (many of those are RC) > > The main problem is that there's currently ~4400 failures for the > installation/removal/purge tests. This includes issues about files being > added/removed/modified during the test, which are not as critical as the > tests where installation simply fails. But still. > > Skills needed: > - python, since piuparts is written in python > - understanding of issues piuparts reports (mostly maintainer scripts > stuff) > - ability to deal with large data sets and semi-automate the process by > writing scripts > > I can of course help by running piuparts on all packages with the > needed options, but that's only a small part of the task. > > If you are interested, the logs for all packages are available on > http://people.debian.org/~lucas/logs/2008/04/07/ , and a dd-list of the > failing packages is available at > http://people.debian.org/~lucas/logs/2008/04/07-piuparts-ddlist.txt . I wish to add that I did an initial round of bug filing for this task last December, and even supplied a few patches and some NMUs. But that was when there were holidays. Later, since I tried to help out a bit more in the gfortran transition and real life difficulties, I did not pursue this goal with the same force. My modus operandi for scripting was as follows. First, a general perusal of the logs reveals that several of the reports are "duds". By this, I don't mean that all of the problems are wrong, but it is just that the problem manifests because of no fault of this package. Please do point out mistakes below; I am not sure if everything I've written is correct. For example, if you check out the logs for libitpp6gf, proc is not mounted, and there seems to be no other major issue. For most other packages, the problem is because some dependencies don't clean up properly. For example, for pkpgcounter, the problem areas are: /etc/alternatives/djview not owned /etc/cups owned by: libcupsys2, cupsys /etc/cups/ssl owned by: cupsys /etc/cups/ssl/server.crt not owned /etc/cups/ssl/server.key not owned /etc/sgml owned by: xml-core, docbook-xml /etc/ssl owned by: openssl /etc/ssl/private owned by: openssl [snipped for brevity] Clearly, there's nothing in pkpgcounter's hands for fixing the above; other packages have the cleaning up to do. So, I tried to parse the logs to get the list of "not found" files, made a list of them, and histogrammed them to find the file(s) which appeared the maximum number of times in these logs. Then, I looked at which package(s) is responsible for mopping up that file, and confirm that that package manifests a similar behaviour. For example, in the above case, cupsys and openssl seems to be among the packages causing pkpgcounter to fail the piuparts test. Checking their piuparts logs, we do find that at least cupsys doesn't clean up quite well before leaving. So, the bug belongs to cupsys, and that should take care of pkpgcounter and the tens (or, in some cases) hunderds of packages which display this error. In short, this is a VERY painful task, since I have to reproduce this error before actually filing a bug. So, it is time consuming. Also, some maintainers probed further and found cases where "disowning" a package's file during upgrade causes dpkg to forget about it. These, of course, are exceptions, and can be handled separately. I hope this was useful. I am not in a position to give my scripts as such, since they were written as dirty one off attempts to get the job done. But in case someone wishes to rewrite scripts, I would be glad to share with them some issues related to this. I also wish to apologise for the fact that I am unable to take this task to completion myself. Thank you! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036
Attachment:
signature.asc
Description: Digital signature