1 Bugs
Dan Simmons edited this page 4 months ago

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

  1. Get a Launchpad account, as all bugs are tracked there.¹
  2. For the bug reporting tools to automatically collect important data, install apport and make sure it's enabled
  3. To create the bug report, open the terminal and run: ubuntu-bug name_of_the_affected_package (see below for a list of packages).³
  4. Subscribe the Lubuntu Packages Team (~lubuntu-packaging) to the bug report.
  5. 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 LXDE (≤18.04) LXQt (≥18.10) notes
window manager openbox openbox
display manager lightdm sddm
session manager lxsession lxqt-session
application launcher lxpanel lxqt-runner has run dialog
taskbar lxpanel lxqt-panel
file manager pcmanfm pcmanfm-qt also manages desktop
notification daemon xfce4-notifyd lxqt-notificationd
authentication agent lxpolkit lxqt-policykit
screen locker light-locker xscreensaver
Bluetooth manager blueman bluedevil


component LXDE (≤18.04) LXQt (≥18.10)
window manager configuration obconf obconf-qt
hot key configuration lxhotkey lxqt-globalkeys
theme configuration lxappearance lxqt-config
monitor settings lxrandr lxqt-config
input settings lxinput lxqt-config

Default applications

component LXDE (≤18.04) LXQt (≥18.10)
installer ubiquity calamares
software center gnome-software plasma-discover
package manager synaptic muon
deb installer gdebi libqapt or plasma-discover
archive tool file-roller ark
task manager lxtask qps
partition tool gnome-disk-utility partitionmanager
disc burner xfburn k3b
terminal lxterminal qterminal
text editor leafpad featherpad
music player audacious vlc
video player gnome-mpv vlc
image viewer gpicview lximage-qt
drawing program mtpaint libreoffice
web browser firefox firefox
email sylpheed trojita
calculator galculator kcalc
document viewer evince qpdf
word processor abiword libreoffice
spreadsheet gnumeric 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:

  1. The report is filed against an appropriate package. See below.
  2. The report has a clear title.
  3. 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.
  4. 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

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:

  1. The bug is reproduced by the triager and marked as confirmed.
  2. An upstream bug report is created and links to the downstream bug and vice versa.
  3. It is given a status of triaged.
  4. 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.

Do be aware that this covers the entire supported packageset, which means that until April 2021, both GTK (LXDE) and Qt (LXQt) versions of Lubuntu will be included, including all of the applications.


Here's an example of a complete, well-triaged bug report:

it has the following qualities:

  1. It has been marked as confirmed.
  2. 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.
  3. It is marked as triaged.
  4. It is given a reasonable priority.
  5. 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.
  6. It has the Lubuntu Packages Team subscribed.
  7. It's given appropriate tags, but especially the lubuntu one.

¹ Gitea (this site) has a bug tracker, but we use it only for tracking development tasks rather than collecting bug data. ² 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