Volunteers wanted for desktop bugs

Hi all. I’ve started trying to collect some historical data about various packages’ bug backlogs (since I don’t know how to query it arbitrarily from Launchpad). And there seems to be a couple of outliers at the moment. Both Nautilus and Xorg in particular need some TLC.

Nautilus is in most need of attention (https://bugs.launchpad.net/ubuntu/+source/nautilus). However I think you will find that much of those could be closed as bugs pertaining to now unsupported releases (https://wiki.ubuntu.com/Releases).

Xorg also needs a little attention (https://bugs.launchpad.net/ubuntu/+source/xorg). However I think many users like to log bugs there that are actually nothing to do with xorg. Xorg server bugs should be moved to xorg-server, and newer Gnome Shell bugs should be moved to source package gnome-shell or mutter.

You can see the full chart here:


ubuntu-bug display opens an xorg bug so if that isn’t right, maybe you should update the apport hook?


I’ve never looked into apport hooks before. Sounds like display would need to conditionally switch between a couple of packages.

I’ve just killed half-a-dozen nautilus bugs with a generic “can you check on a newer release” message. I’ll try to squash some more through the evening.

1 Like

Thanks @lucyllewy. Don’t be afraid to set old bugs straight to Invalid, if not Incomplete. So long as it’s accompanied by a reasonable message nobody should be shocked by that:

I’m using “incomplete” so that the original reporter has a chance to re-check the current state of the bug if they feel inclined. IIRC bugs set to incomplete will auto close after a period (90 days?) so even though I’m not closing them directly they’ll be more likely to fall out of scope in time rather than sitting open.

Thanks, this is the right thing to do as, as you said, some issues on a EOL release may still exist on a supported or the development release.
They will be set to “Expired” after 60 days if it has the “Incomplete” status and:

  • it is not marked as a duplicate of another bug
  • it has not been assigned to anyone
  • it is not targeted to a milestone.

As explained on this Launchpad Help page

I do both:
I usually do a quick over the bug and if try to determine if it looks like it will be relevant for the dev release (try to reproduce, see if that feature was dropped, etc). If it seems likely not relevant I say why I think so and mark it Invalid.

If there is a significant chance it could affect a new release, then I do Incomplete.

Sounds like general housekeeping.
Based on some things I’ve seen lately it seems you all are also in need of more bug triager’s & people who can clean crashers & move them from private to public for a bit more exposure.
An example is https://bugs.launchpad.net/bugs/1737701 which has been private for probably 4 months & something that will greatly affect some users in 18.04 if not dealt with
(- the actual bug is on libcdio17 which has a public untriaged bug with simple fix.

1 Like

Log on screen (not lock screen) does not indicate if CAPS lock in on.

How should crashes that are not easily reproducible be treated?

Instructions like these should enable people to do that themselves, but yes, sometimes someone else may need to do it to get the bug moving… admittedly I haven’t sorted out my own private bugs :confused:


  • it contains no bug watches or links to external bug trackers.

So if there is a bug watch pointing at an external tracker then the bug will never auto-close. You should check the links to external trackers and decide if they are still useful. If not then you will need to delete the links before the automatic 60 day countdown can start. You will occasionally find Incomplete bugs that should have expired already but did not, because of this.

Please discuss that issue in: Bug #1734887 “No caps lock indicator on login screen” : Bugs : gnome-shell package : Ubuntu


  1. Search errors.ubuntu.com (sorry if you don’t have access, I don’t remember the procedure). Find other instances of the crash and group them all together into a single bug report.

  2. Get a .crash file from the user, or else the bug should remain Invalid. You may need to start by asking them to “apply the workaround from bug 994921”. Then they should be able to look in /var/crash, find the relevant file and upload it to a new bug using ubuntu-bug /var/crash/WHATEVER.crash. But attaching crash files to existing bugs is not helpful.

  3. Once you have a retraced bug report from the user via ubuntu-bug you can mark the first bug as a duplicate of the second one.

  4. If still in doubt, keep the bug Incomplete until a satisfactory amount of system logs and other information is attached.

Bug 1737701 is this one:

which seems to have had 338 crash reports in bionic. It is indeed the second-most common crash in gvfs for 18.04:

Thanks, marked as effecting me.

Well the actual relevant report is here -

Contains a developer supplied 1 line patch for libcdio that resolves the issue

What I mean is what to do when there is a retraced bug that is not easily reproducible like this one?

For this type of bug where there is no duplicate, heat is low, it affects only one user and has been reported against an old release, you can safely use the standard “Old Untouched” response from the Bug Squad’s Knowledge Base, set it to incomplete and let it expire.

For this very specific bug you pointed out, I’ll just close it since I’m the reporter, it never happened again and affects no one else.