General information
About + News
Overview
FAQ
Source
piuparts.d.o bugs
piuparts bugs / ToDo
Contact us
Documentation
piuparts manpage
README
README_server
piuparts.d.o configuration:
piuparts.conf,
distros.conf
and scripts
How to file bugs
Debian policy
Available reports
Bugs filed
experimental
sid2experimental
sid
sid-nodoc
testing2sid
stretch
jessie2stretch
jessie
jessie-rcmd
jessie-pu
jessie2proposed
wheezy2jessie
wheezy2jessie-rcmd
wheezy2bpo2jessie
wheezy2proposed
wheezy
squeeze2wheezy-proposed
squeeze2wheezy
squeeze2bpo-sloppy
squeeze2bpo2wheezy
squeeze2squeeze-lts
squeeze
lenny2squeeze
by maintainer / uploader
by source package
Other Debian QA efforts
Debian QA Group
Dose tools (former: EDOS)
Lintian
Debian Package Tracker (former: PTS)
Ultimate Debian Database
jenkins.debian.net
ci.debian.net
Last update
2015-08-31 11:05 UTC
How to file bugs based on tests run on piuparts.debian.org
This page shall grow into a well written explaination how to file useful bugs fast. It assumes you are familar with reporting bugs in Debian.
First, of all, read the piuparts logfile and identify why piuparts testing failed.
Then, check the BTS for that package, to see if this issue was already filed as a bug. Often it's also useful to check the source packages bug page. Sometimes a bug already exists, describing the problem piuparts has found. More often, new bugs have to be filed.
Usertagging existing bugs to make them known to piuparts.debian.org
If there already is a bug describing the same problem you're seeing in the piuparts logfile, you can usertag it, so that the next piuparts-analyse run will be able to link the bug report with the logfile on piuparts.debian.org. (piuparts-analyse runs twice a day.)
 User: debian-qa@lists.debian.org
 Usertags 987654 + piuparts
	
Filing new bugs
More often, there is no existing bug and you need to file one. To make this easy as well to have consistent quality bug reports, we collect templates for filing these bugs. Please use these templates! The following is an example bug report for illustration:
 To: submit@bugs.debian.org
 Subject: $package: fails to upgrade from 'testing' - trying to overwrite ...

 Package: $package
 Version: $version
 Severity: serious
 User: debian-qa@lists.debian.org
 Usertags: piuparts

 Hi,

 during a test with piuparts I noticed your package fails to upgrade from
 'testing'. It installed fine in 'testing', then the upgrade to 'sid'
 fails because it tries to overwrite other packages files without
 declaring a replaces relation.

 See policy 7.6 at
 https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

 From the attached log (scroll to the bottom...):

 $useful_except_from_logfile

 cheers,
        $your_name

 attachment: $failed_logfile
	
Please take care when filing bugs to file meaningful bugs and to not annoy maintainers. Don't nitpick or insist on severities, the important thing is to get the bug fixed, not the right severity. Optionally you can also send copies to the piuparts-devel mailinglist by adding X-debbugs-cc: piuparts-devel@lists.alioth.debian.org pseudo-headers.
Also, you should be aware that what you are doing can probably be seen as mass bug filing (even if you just file a few now, they are part of a series of bugs of one kind) and as such needs to be discussed on debian-devel@lists.d.o first! For many types of bugs this has already been done. This is or should be indicated in the summary web pages as well as the mail templates.
Marking bugs as affecting other packages
Sometimes there is a bug in another package which affects a package being tested. The following explains how to tell this to the BTS in a way piuparts-analyse will pick up:
 # assume 987654 is our bug report in buggy-package,
 # but the problem only shows up when testing (upgrades of)
 # failing-package with piuparts:
 bts affects 987654 failing-package

 # and if failing-package is from a different source with a different
 # version number:
 bts found 987654 failing-package/$FAILED_VERSION