FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-07-2008, 09:46 AM
Lucas Nussbaum
 
Default RFH: piuparts testing of the archive

Hi,

[ for those who don't know piuparts: piuparts tests that .deb packages
(as used by Debian) handle installation, upgrading, and removal
correctly. It does this by creating a minimal Debian installation in a
chroot, and installing, upgrading, and removing packages in that
environment, and comparing the state of the directory tree before and
after. ]

Before the etch release, I did a few piuparts runs on all packages, and
filed the resulting bugs. I'd like someone to take over that task for
lenny.

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 .
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-07-2008, 10:32 AM
Kumar Appaiah
 
Default RFH: piuparts testing of the archive

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
 
Old 04-07-2008, 03:20 PM
Amaya
 
Default RFH: piuparts testing of the archive

Lucas Nussbaum wrote:
> Before the etch release, I did a few piuparts runs on all packages,
> and filed the resulting bugs. I'd like someone to take over that task
> for lenny.

Whoever takes up this task, please keep #322762 updated about findings
related to the /usr/doc symlink transition.

I can't wait to see it go away

--
'`. Fuck your fascist beauty standards
: :' :
`. `'
`- Proudly running (unstable) Debian GNU/Linux


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-08-2008, 03:08 AM
Russ Allbery
 
Default RFH: piuparts testing of the archive

Lucas Nussbaum <lucas@lucas-nussbaum.net> writes:

> Before the etch release, I did a few piuparts runs on all packages, and
> filed the resulting bugs. I'd like someone to take over that task for
> lenny.
>
> 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.

Fixing #454694 might help.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-08-2008, 09:26 PM
Raphael Geissert
 
Default RFH: piuparts testing of the archive

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)

On log processing, what about doing a dependency-based log processing?
so if package bar depends on foo, and foo fails to upgrade (or doesn't pass
all the piuparts tests) it is very likely that bar will fail too, at least,
because of foo.

I think there was some tool around to build a dependency tree out of a
Packages, so the main part of the log processing tool is already done.

Cheers,
Raphael


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org