Software inevitably has bugs. Sometimes despite the most rigorous testing, bugs still get through. Luckily, bug reporting is an easy way to alert developers to the need to solve an issue. Additionally, it’s easier to analyze and troubleshoot bugs in a central repository than it is on a mailing list or chat.
How to report bugs
- Get a Launchpad account, as all bugs are tracked there.
- For the bug reporting tools to automatically collect important data, install apport and make sure it’s enabled.²
- To create the bug report, open the terminal and run:
ubuntu-bugname_of_the_affected_package (see below for a list of packages).³ - Subscribe the Lubuntu Packages Team (~lubuntu-packaging) to the bug report.
- Read the documentation below for advice to write an effective bug report.
Package Names
NOTE: When in doubt about what package to file the bug against, please use lubuntu-meta.
Common packages
| component | package |
|---|---|
| settings | lubuntu-default-settings |
| artwork | lubuntu-artwork |
| splash screen logo | lubuntu-artwork |
| splash screen text | lubuntu-artwork |
| display manager settings | lubuntu-artwork |
| installer settings | calamares-settings-ubuntu |
| metapackage | lubuntu-meta |
Core desktop environment
| component | LXQt (≥18.10) | notes |
|---|---|---|
| window manager | openbox | |
| display manager | sddm | |
| session manager | lxqt-session | |
| application launcher | lxqt-runner | has run dialog |
| taskbar | lxqt-panel | |
| file manager | pcmanfm-qt | also manages desktop |
| notification daemon | lxqt-notificationd | |
| authentication agent | lxqt-policykit | |
| screen locker | xscreensaver | |
| Bluetooth manager | bluedevil |
Configuration
| component | LXQt (≥18.10) |
|---|---|
| window manager configuration | obconf-qt |
| hot key configuration | lxqt-globalkeys |
| theme configuration | lxqt-config |
| monitor settings | lxqt-config |
| input settings | lxqt-config |
Default applications
| component | LXQt (≥18.10) |
|---|---|
| installer | calamares |
| software center | plasma-discover |
| package manager | muon |
| deb installer | libqapt or plasma-discover |
| archive tool | ark |
| task manager | qps |
| partition tool | partitionmanager |
| terminal | qterminal |
| text editor | featherpad |
| music player | vlc |
| video player | vlc |
| image viewer | lximage-qt |
| drawing program | libreoffice |
| web browser | firefox |
| calculator | kcalc |
| document viewer | qpdf |
| word processor | libreoffice |
| spreadsheet | libreoffice |
How to write a good bug report
It is a common misconception that reporting bugs is an extremely difficult task, but as long as you clearly explain the problem, someone with more experience can guide you in getting any additional information. New people reporting bugs are very strongly encouraged to read How To Write Bugs Effectively to help with wording their bug report.
Essential components
The more complete you can make your bug report, the more likely it is to be fixed. Here’s the pieces you should consider essential:
- The report is filed against an appropriate package. See below.
- The report has a clear title.
- The report description includes the following pieces:
- Steps to reproduce (this is the most important thing; if it’s not reproducible, it’s nearly impossible to fix).
- Expected results.
- Actual results.
- Affected versions.
- Optionally, any other notes concerning conditions required to reproduce the bug, testing information, log files, etc.
- The report includes appropriate tags, but especially “lubuntu.”
General guidelines
- Ideally, it’s good to do a little web search or ask around to see if your bug is really a support issue.
- One quick way to ensure you have a real bug is to set up a virtual machine with the version of Lubuntu you’re using and see if you can repeat the behavior. If you can’t, you might still have a bug, but the issue will be related to some specific aspect of your system, which will need to be tracked down.
- If you do have a bug, it’s a good idea to do a search on Launchpad to see if you find a duplicate bug. If you do, work to add to and triage that bug report instead of reporting a new one.
- MOST IMPORTANTLY: if you’re not sure if you should report a bug, report it anyway!
Additional resources
- The Ubuntu wiki features a page about reporting bugs.
- The Ubuntu QA Team publishes general information on how bug reporting works and why it is so important, as well as how to write a proper bug report.
- We publish a quick intro to using Launchpad with bugs.
- The Ubuntu team made a nice, easy video walkthrough: https://www.youtube.com/watch?v=27OhY83MsU8
Triage: making bug reports better
An important part of QA is not only making bug reports, but making them in such a way that they can be worked on by developers. Additionally, triage should be something that QA considers part of their workload. Bug reports are there to help developers know what to work on next. The only way development happens is if these bug reports are clear and clearly marked.
The work here is making sure all of the essential components above are set up appropriately. Additionally, the following components are done:
- The bug is reproduced by the triager and marked as confirmed.
- An upstream bug report is created and links to the downstream bug and vice versa.
- It is given a status of triaged.
- It is given a reasonable priority.
Advice to these ends are provided by the Ubuntu Bug Squad team which has an open membership. Their documentation is a valuable reference, but they are available by IRC and email for additional questions. Or you can contact the friendly Lubuntu Development/QA teams!
You will also need to contact the aforementioned folks to set statuses and priorities. Alternately, you can submit an application to the Ubuntu Bug Control team. The more well-equipped triagers we have on this team, the better, so please do so!
What to triage
Of course, before you triage you need bugs to triage! Sometimes bugs are reported on the various communication channels or through tasks here, but more often than not they’re not. They’re otherwise invisible unless you go to a particular package on Launchpad and look at its bugs. Luckily, the Lubuntu Packages Team was created to collect all the bugs from the entire Lubuntu packageset. You can go to its bug page and sort through all the different bugs.
Example
Here’s an example of a complete, well-triaged bug report:
it has the following qualities:
- It has been marked as confirmed.
- It is linked to an upstream bug report. If you follow the link to the tracker, you’ll find it links back to the downstream bug.
- It is marked as triaged.
- It is given a reasonable priority.
- It has clear steps to reproduce, expected results, actual results, and any other additional notes detailing the version numbers and other conditions that apply and don’t apply.
- It has the Lubuntu Packages Team subscribed.
- It’s given appropriate tags, but especially the lubuntu one.
² This is sent only through the Launchpad servers and should include no private information.
³ Alternately, you can manually create a report with https://bugs.launchpad.net/ubuntu/+source/[name_of_the_affected_package]/+filebug