General information
About
News
FAQ
Contact us
Documentation
How to file bugs
using templates
Debian policy
piuparts.d.o configuration:
piuparts.conf,
distros.conf,
scripts and logs
README
README_server
piuparts manpage
Summaries
Bugs filed
Suites overview
Suite: sid
by maintainer / uploader
by source package
states graph
all tested suites
experimental
sid2experimental
sid
sid-strict
sid-nodoc
sid-merged-usr
sid-broken-symlinks
testing2sid
trixie
trixie-rcmd
bookworm
bookworm-rcmd
bullseye
bullseye-rcmd
bullseye-security
bullseye-pu
bullseye2next
stable2sid
stable22sid
buster
buster-rcmd
buster-security
buster-pu
buster2next
stretch2buster
stretch2Xbuster
stretch2buster-rcmd
stretch2Xbuster-rcmd
stretch2bpo2buster
stretch2bpo
stretch
stretch-rcmd
stretch-security
stretch-pu
stretch2next
oldstable222sid
oldstable22testing
jessie2stretch
jessie2Xstretch
jessie2stretch-rcmd
jessie2Xstretch-rcmd
jessie-lts2stretch
jessie2bpo2stretch
jessie2bpo
jessie2lts
jessie
jessie-rcmd
jessie-security
wheezy2jessie-lts
wheezy2jessie
wheezy2jessie-rcmd
wheezy2bpo2jessie
wheezy2lts
wheezy
wheezy-security
squeeze2wheezy-lts
squeeze2wheezy
squeeze2bpo-sloppy
squeeze2bpo2wheezy
squeeze2squeeze-lts
squeeze
lenny2squeeze
src: piuparts
Source
piuparts.d.o bugs
piuparts bugs / ToDo
Other Debian QA efforts
Debian QA Group
Dose tools (former: EDOS)
Lintian
Debian Package Tracker
Ultimate Debian Database
jenkins.debian.net
ci.debian.net
Last update
2024-03-19 05:25 UTC
How to file bugs based on tests run on piuparts.debian.org
This page aims to summarize 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-analyze run will be able to link the bug report with the logfile on piuparts.debian.org. (piuparts-analyze 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#overwriting-files-and-replacing-packages-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@alioth-lists.debian.net 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-analyze 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