Updated 10 Days AgoPublic

General information

The QA/Testing Team is responsible for using formal test cases to check images of Lubuntu. This allows the Release Team to easily gauge the health of the images. This makes it possible to tell whether an image is functional enough to justify a release and determine where resources need to be allocated to make sure an image gets released.

Testing consists of:

  1. Testing milestone images: Our most important job is preparing for release. A few days before a milestone is due (according to our release schedule), the daily image is selected and becomes the QA (Quality Assurance) test version (these are called Alpha, Beta, and Final, depending on the stage of the release cycle). Once it is confirmed that the release candidate works, it then becomes the released version.
  2. Daily image testing: Daily images are constantly being tested to give us an early warning notice of any problems that could affect Milestone releases. This also gives us an opportunity to do more heavy testing to discover any bugs we hadn't noticed before.
  3. Specific testing: Specific testing allows us to help with development.

All release stages are tracked by the ISO Tracker where you can get the latest builds, see and allocate any bugs, and formally report testing results.

For more information about testing, please see the main Ubuntu QA team.


Testing Versions

  • Current development is on Lubuntu 18.10 Cosmic Cuttlefish. Lubuntu 18.10 is scheduled to release in October 2018.
  • Lubuntu point releases are maintenance releases, do not expect too many changes. Daily testing and milestone testing will be needed here. See the release schedule for Bionic Beaver.

Current Supported Releases

The current supported releases are below:

Getting Involved

Before you get started

This section is dedicated to the current development version of Lubuntu. As with all early milestones, they are not suitable for a production environment.

Whenever you are testing, keep in mind these few notes:

  1. Using a development milestone is not suitable for daily production machines. That is why, to play it safe, it's better to use virtual machines, spare testing machines, and/or USB drives, especially with early milestone releases. Beta milestone releases are a bit more stable, but are still under heavy development to ensure the highest quality release possible.
  2. The most important part of testing is to actually install the system and check how the installation process will work. This is very important. Also, if you have an early milestone installed installed, it is less helpful to just upgrade. Please, do a fresh install.
  3. Always make sure to check the hashes of the downloaded ISO as well as the media it's installed on. If either is off by a single bit, it can cause all sorts of inexplicable problems.
  4. Most of the testing is done with virtual machines, but if you want to install to a hardware system, that's helpful, too. If you do this, make sure to backup your important data. If you are using Linux, the best and easier way is to make a copy of your /home folder or partition. If you want to do a full system backup, please see this link and this link too.
  5. To save downloading the whole iso again for the testing version, simply copy your trusty image of what ever architecture replacing the old codename with the new one, e.g. 'trusty' with 'utopic' and use zsync. zsync also does automatic checking of the integrity of the image.


What to do when

Familiarize yourself with the release schedule. The dates listed for the release of milestone images are typically on Thursday. Two days before that, on Tuesday, release canidate images are made available for final testing.

Be sure to watch out for point releases on Long Term Support images, too. They often come in the middle of cycles on the development release.

We must have formal testing done and any showstopper bugs resolved within the two days. This doesn't allow for a lot of room for errors. Because of that, it is imperative that the week before official testing opens up, we do daily testing. Make sure to report all successes, failures, and bugs on the ISO tracker.

Note that dailies are off during milestone testing and get turned on shortly after release. The Release Team's schedule for the milestone process can provide more information. Please consult this before asking them to turn the dailies back on.

It takes a little longer for the dailies to get turned on after a final release due to steps that will allow for development in the new cycle. This can take up to two weeks, so please be patient. For more information, please look at the Release Team's schedule for the new release cycle process.

When images build

When turned on, dailies build automatically according to a cron job. Look for the line with for-project lubuntu cron.daily; for-project lubuntu cron.daily-live --live and the time will be to the left in the form MM HH * * *.

The Alternates take approximately 30 - 45 minutes to complete. The Desktops take approximately 90 minutes to complete.

You can also see the status of images at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/RELEASENAME/lubuntu (change RELEASENAME to something like trusty, utopic, vivid, etc). Note if it says successfully built, that does not mean it's uploaded to the tracker yet.

You can also see the logs of automated builds. This is a good way to troubleshoot why an image is not there.

Jenkins runs automated tests. In particular, there's one that deals with Ubiquity that would be a good way to see if we're having problems with the Desktop ISO.

Problems with images

If you do notice that builds are not appearing as expected, please let us know in our IRC/Telegram/Matrix channel linked above.

Some examples:

  • All of the architectures or types not being represented.
  • Old daily versions (the version in the form YYYYMMDD should be today's date).

Packaging issues

Unwanted packages

Some packages can be automatically installed, but are not wanted on a default installation. To find the package which automatically installed the package that you don't want :

  • Install apt-rdepends
  • Run apt-rdepends -r --show=Depends the_unwanted_package => It will show which packages depend on the_unwanted_package.
  • Run apt-rdepends -r --show=Recommends the_unwanted_package => It will show which packages recommend the_unwanted_package (Recommended packages are installed by default).
  • You may have to run the commands several times to see the complete chain of depends / recommends.


NOTICE: always subscribe Lubuntu Packages Team to bugs encountered within Lubuntu. There is a page with known bugs affecting Lubuntu here.

Please head over to All about bugs for further information on how bug reporting works and why it is so important, as well as how to write a proper bug report.

An important part of QA is not only making bug reports, but making them in such a way that they can be triaged. 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. That being said, look at the Bug Squad for info on how to write and triage reports. There is a subteam called Bug Control that you need to be approved for that can handle changing all statuses and priorities.

Why report bugs?

Reporting bugs is important to improve the quality of Lubuntu and of all the software included. Before you can report bugs, if you not have a Launchpad account please follow these instructions. If you're not sure if you should report a bug, report it anyway. Also, it's easier to troubleshoot bugs in a single place than it is on a mailing list or IRC. The results of any testing should always end up on the bug report.

How to report bugs?

For general documentation of how reporting bugs, please read the documentation about Ubuntu, or this more generic document can help as well. Launchpad has a quick introduction to using/tracking bugs on Launchpad.

Where to report bugs?

Bug on a specific component

If you find a bug on a specific component, run ubuntu-bug the_name_of_the_component.

If ubuntu-bug is not available, you need to install apport (sudo apt install apport). See: Enabling Apport.

Names of important components:

  • The panel: lxpanel
  • The filemanager: pcmanfm
  • The login manager: lightdm
  • The windows manager: openbox
  • The music player: audacious
  • The video player: gnome-mplayer

You also can see the detailled list of applications on Lubuntu.

Request for adding a new program or a new package

Please report a bug against lubuntu-meta package, using this command: ubuntu-bug lubuntu-meta

Artwork problems

Please report a bug against lubuntu-artwork package, using this command: ubuntu-bug lubuntu-artwork

Problems with default settings

Please report a bug against lubuntu-default-settings package, using this command: ubuntu-bug lubuntu-default-settings

Missing translation, or bugs

Please refer to the Translations page.

Don't know where to report ?

In the case you still don't know where to report a bug, please report it against lubuntu-meta.

Improve bug reports

Manual Backtrace

When a program crashes, it's useful to report a backtrace of the crash. To do so, follow those instructions:

  • Install gdb with sudo apt install gdb
  • Install useful debug packages with sudo apt install libglib2.0-0-dbg libgtk2.0-0-dbg
  • Install the debug package of the program you want to debug. See the wiki instructions.
  • Generate the Backtrace using the wiki instructions.
  • You can also pass --g-fatal-warnings inside gdb to debug gobject criticals
Subscribe Lubuntu Packages Team
  • If you're sure the bug only affects Lubuntu and not other flavors, then make sure to subscribe the Lubuntu Packages Team to the bug report. If you're unsure, do it anyways.
  • Consider joining the Bug Squad team and help out with bug triage.
  • Also please consider submitting an application to the Bug Control team which can change all statuses and priorities.
Enable automatic reports

Daily Builds

These ISOs are automatically generated every 24 hours using the latest updates on the system. They are available from ISO tracker. They are there to check that bugs that are resolved between the Milestone releases do not break the install. They also are used to confirm that any fix for a bug that seriously affects an initial install which is released for testing now works. Daily builds are suspended when pre-milestone testing is being carried out. There is a process for re-initiating the dailies after the cycle is over. Assuming we have a name, it should happen fairly quickly, as it's dependent on that.

Make sure to check for previously reported bugs and include them in your results if they're still applicable!

Milestone releases

Alpha, Beta and Final (formerly known as Release Candidates (RC)) are also tested using ISO tracker. If you want to help out in this important area of testing, please read Procedures for further details. These appear a couple of days before the actual Milestone release so that we can check they are okay to become Milestone releases.

Once a Milestone release passes the QA testing, it becomes a Milestone Release and is listed on the Releases as such.

Note this also includes point releases on LTS versions. Basically, a point release brings in all the various bug fixes into one 'new' image. To get in to the build they have to pass SRU testing.

If you would to know more about how this all works, have a read of Stages of testing.

Make sure to check for previously reported bugs and include them in your results if they're still applicable!

Contents of this page originated from the Ubuntu Wiki, all copyright goes to the respective author

Last Author
Last Edited
Mon, Aug 6, 7:41 PM
hxcdk, alamo18, tsimonq2, wxl