Conary:How To File An Effective Bug Report
From rPath Wiki
|
Conary users and packagers are encouraged to inform Conary developers when they find bugs or want to request features for Conary. The following sections recommend ways to file an effective bug report for Conary.
Use the rPath Issue Tracking System
Conary developers handle reports as part of the rPath Issue Tracking System at issues.rpath.com. Use rPath Community:Issues as a reference to create an issue for the Conary project.
Gather Information about the Bug
Conary developers can better handle each issue when sufficient information is provided about the observed bug. Some things to include in the issue are described in the following sections.
Steps to Reproduce
Reproducibility is important for debugging problems with any code, and Conary is not an exception. Develop your issue description with a step-by-step procedure for reproducing the problem, or with a sequential list of actions that lead up to observing the bug.
One tool that can be used to reproduce Conary bugs is the --root <newrootpath> option to run a separate Conary environment in a new root without changing anything on the affected system. Replace <newrootpath> with the path to use for the separate root.
In many cases, to reproduce a bug involving an update, you can find out what version(s) of that trove and its components are installed:
- #> conary update --root /tmp/myroot trove1 trove2 --no-deps
- #> conary --root /tmp/myroot <command_that_failed>
If you can make the bug reproduce in a root, it is likely that a tester will be able to reproduce it in a different environment when addressing the issue.
Error Messages
Any error messages displayed by Conary provide useful information to Conary developers for troubleshooting the error. Be sure to include all error messages in the issue description.
Affected Troves
If you know that the trove example is targeted in the error messages, include the full version string and flavor of the trove as displayed when running a Conary query with the appropriate options:
$> conary q example --full-versions --flavors
Enhance this further by reporting whether the trove is pinned or unpinned, seen when running Conary query with the info option. This may be relevant if the error is related to updates or file permissions.
Containing Groups
If the trove is installed and managed as part of a Conary group on the system, information about that group can help with the troubleshooting effort. This is especially useful if the error is related to a conary updateall command. To find this information, query for a list of installed groups, then query each group for the troves installed by that group:
$> conary q | grep group- $> conary q group-example --diff --flavors --fullversions | grep example
See the conary query command page for more information on query options.
Update Information
If the bug was produced as part of an update, include information about the update. Conary developers need information produced from the following commands:
- $> conary config
- $> conary config
- $> <update command used> --info (or, if that fails because of dependencies) $> <update command used> --info --no-deps
Conary Database
The Conary database contains all the information about what troves are installed on a Conary-based system. The database is located at /var/lib/conarydb/conarydb. A copy of the Conary database right after an update error is a useful debugging tool.
The database is relatively large, typically several megabytes in size. If disk space permits, create a compressed archive of its contents and note that you have that available as part of the issue description. Keep the archive until a Conary developer requests it or until the issue is resolved. The following command can be used to make such an archive:
$> bzip2 -c /var/lib/conarydb/conarydb >somewhere/backup.bz2
If Conary developers request the archive, and you do not have a place to temporarily upload the database for developers' access, rPath recommends dropload.com or yousendit.com for temporary upload.