Postings by Brian Murray

ubuntu-release-upgrader and postgresql

With the enabling of upgrades to Ubuntu 18.04 from Ubuntu 16.04 I've
been reminded of postgresql being in the blacklist of packages to
remove. I'm wondering if having this in the blacklist is still relevant.

Bug 1787349[1] is a recent report of the upgrade being blocked because
of postgresql being in the blacklist and bug 871893[2] contains the
historical information on why it was added.

update-manager 1:18.04.11 (Accepted)

I saw this upload to bionic today and a similar one for a different
package yesterday and had some questions about it.

Why is it necessary to modify individual packages so that GNOME
Software won't uninstall them?

Is update-manager being a dependency of ubuntu-desktop not enough to
prevent it from being uninstalled?

If it is necessary to modify every package which a metapackage depends
on how is this work being tracked?

What checks are in place to ensure that no packages are missed and that
new additions get appropriately changed?

----- Forwarded message from Jeremy Bicha < ... at ubuntu dot c

Changes to do-release-upgrade and meta-release files

I've recently made some changes to how do-release-upgrade, called by
update-manager when you choose to upgrade releases, behaves and thought
it'd be a good time to clarify how things work and the changes made.

When do-release-upgrade is called it reads a meta-release file from to determine what releases are supported and to
which release to upgrade. The exact meta-release file changes depending
on what arguments, --proposed or --devel-release, are passed to

PSA: Pending Stable Release Updates

Have you ever sponsored an SRU and wanted to help with the verification
(since that's the right thing to do!) but then forgotten what you

Well, do I have news for you - the Pending SRU report[1] now displays
information about who uploaded and sponsored the package.

Have a look and see what you should help verify.

[1] <a href="" title=""></a>


Ubuntu Error Tracker is read-only

Some of you might remember that the Ubuntu Error Tracker had problems
with the size of its database when it first came into service and that
we had to use a fresh database a couple of times. We've always wanted
to merge all the data together into one grand database and that time has
finally come. The process will involve a period of time where the
current database will be read-only. During that time period it will not
be possible to open Launchpad bugs from crashes in the Error Tracker and
we will not be receiving new crash reports. This read-only period
should last about 24 hours.

PSA: Merge-o-Matic changes

Yesterday, I modified to display the version number of
the package in proposed, if one exists, and change the row color to

Ubuntu Error Tracker retraces

I recently discovered that the Ubuntu Error Tracker,
<a href="" title=""></a>, was creating uninformative retraces[1] or
failing to retrace some crashes that shouldn't. While the problem has
been resolved, by an update of apport and using a backport of the Xenial
version of gdb, it's likely there are problem buckets in the Error
Tracker that could use retracing again.

Ease of enabling -proposed

Reviewing crash reports in the Ubuntu Error Tracker and bug reports in
Launchpad, I've noticed quite a few tagged "package-from-proposed". This
tag is added by apport when the installed package version is available
from -proposed and not from -security or -updates. I'm even seeing these
from users of Vivid.

Evan suggested removing the "Pre-released updates ($release-proposed)"
checkbox from software-properties-gtk, thereby preventing accidental
enabling of it.

I think this should definitely be done for the development release of

Ubuntu Error Tracker

This week the Ubuntu Error Tracker has switched to using a new cassandra
database. This was primarily due to a lack of space on the previous database
nodes but will also facilitate moving to a more modern version of cassandra.
However, as we are starting over with an empty database if you haven't already
you may notice some issues.

The phased-updater halted the phasing of some Stable Release Updates due to an
increased rate of crashes for the package because there was no historical data
for the rate of crashes of the package.

Error Tracker retracing armhf crashes

Last week the Ubuntu Error tracker infrastructure, thanks to the hard
work of the Canonical Web Ops team (particularly David Ames), switched
from running on specific hardware systems to using Canonical's internal
cloud. An exciting benefit of this is that we now have retracers running
for the armhf architecture and are successfully retracing these crash

Phasing of Stable Release Updates

For some time[1] we've wanted to phase, gradually roll out, updates to
expanding subsets of Ubuntu users so that we may monitor for regressions
and stop the update process if there are any. The support for phased
updates has existed in update-manager for a while, but we did not have
the server side part implemented. Thanks to the work of Colin Watson,
Evan Dandrea, and myself this is now done.

This is initially enabled for Ubuntu 13.04 and going forward will apply
to any packages being released to -updates.

The future of migration-assistant

Following a review[1] of the quality of migration-assistant[2] and the
resources available to support it at the Ubuntu Development Summit in
Oakland for the Quantal release Ubuntu we have decided to remove
migration-assistant from the installer for Quantal and to move the
package to universe.

Package conflicts

I've recently updated apport so that package installation failures, bugs
tagged apport-package, will now also be tagged 'package-conflict' in the
event that are multiple packages dealing with the same file. I
additionally went through all the existing apport-package bug reports
and also tagged them 'package-conflict' where appropriate.

New information in bugs reported by apport

I've recently added a couple of features to apport which modify the
information collected when a bug reporter reports a bug about any

One is the addition of details regarding modified conffiles which are
a part of the package about which the bug is being reported. The bug
description will contain a key like 'mtime.conffile.' and data about
when the conffile was modified. Additionally, if the user approves it
the conffile will be attached. You can see an example of this in
<a href="" title=""></a>.

The other feature is the inclusion of upstart override files[1].

mass tagging of some bug reports

I'm planning on tagging about 5000 bug reports with attachments named
'VarLogDistupgradeApttermlog.gz' with the tag 'dist-upgrade'.

These bug reports have been reported by apport and are package
installation failures but are currently indistinguishable (well other
than checking the attachments) from regular package installation
failures as they are all tagged 'apport-package'.

Having the tag will allow us to search using Launchpad for package
installation failures that have occurred when performing a distribution

Natty apport-crash reports

I was recently looking at some aptdaemon bug reports and noticed that
there are surprising number of duplicates. Upon further investigation I
noticed that quite a lot were reported after Natty was officially
released and apport was disabled.

Release Targeting and Milestones

I've recently been reviewing bug reports that are targeted for a release
of Ubuntu or have a milestone set. From what I've observed there is a
disparity between <a href="" title=""></a> and what
really happens.

Examples of the disparity I've found include:

Bug tasks having a milestone set which are release critical sometimes
are not targeted to the release. The wiki page indicates that these
should have a release task. I believe the error here is not with the
wiki page but with not targeting the bug to the release.

Bug tasks being targeted to the release (e.g.

Installing drivers on USB sticks

I've recently discovered hundreds of bug reports regarding people trying
to install drivers (bcmwl, fglrx, nvidia) on their Live USB version of
Ubuntu and it failing[1]. Part of the large volume is due to the fact
that the bug reports are automatically reported by apport as package
installation failures.

Official Bug Tags

I've recently landed a change in Launchpad that allows members of the
bug supervisor team for a product or distribution to modify the official
bug tags for that object.

For Ubuntu this means that members of ubuntu-bugcontrol can now add and
remove official bug tags. This is done by clicking the "Edit official
tags" link at <a href="" title=""></a>.

Bug Reporting Guidelines and Acknowledgement

Objects which bugs can be reported about have a couple of attributes
that can help us receive more useful bug reports. They are the "bug
reporting guidelines" and "bug reported acknowledgement". The ability
to set and edit both of these used to be restricted to the project's
owner, which for Ubuntu is the ubuntu-drivers team.

Reviewing bugs with patches

In an effort to address the volume of unfixed bugs with patches we have
created an Ubuntu Review Team[1] for reviewing them. I’ve written a
launchpadlib script that is subscribing the team to any bugs with
patches where the patch has been added after February 1st. Depending on
the throughput of that queue we will start subscribing the team to older
patches. You can view the bugs the team is currently subscribed in

The team is also setup with a mailing list[3] for receiving bug mail. By
subscribing to the mailing list you will receive notification of these
bugs with patches.

Reporting bugs about Ubuntu

Hello fellow Ubuntu users,

I wanted to let you know about a change that has been implemented on Launchpad
for filing bugs about Ubuntu.

In an effort to increase the amount of information contained in initial bug
reports about Ubuntu and reduce the number of follow-up questions required to
make a bug report complete we are asking that bug reporters use apport to
report bugs about Ubuntu.

Packages without bug subscribers

Recently there was some discussion about packages that might have no one
looking after bugs reported about them. One way to monitor bugs about a
package, in Launchpad, is to subscribe to all of the package's bug
mail. This can be done by going to
<a href="" title=""></a> and clicking "Subscribe to bug
mail". (Of course replacing apcid with the package you are interested

I went looking for these packages and have compiled a wiki page[1] with
some of them.

Sponsorship Queue Process

I was looking at some documentation regarding the sponsorship queue[1]
the other day and noticed that it doesn't mention the Triaged status at
all. I understand that people requesting sponsorship wouldn't
necessarily be able to set the Triaged status but the documentation
might lead one to believe that a bug must be in Confirmed status for it
to be sponsored and that moving bugs from Triaged to Confirmed makes

Increasing Apport's Package Coverage

At the UDS for Karmic Koala the Ubuntu QA team discussed increasing the
number of packages that have an apport hook. The goal being to receive
higher quality bug reports and reduce the amount of bug ping-pong
necessary. While one could write an apport hook for any package we
decided to identify the packages that might benefit the most from one.
This was done by taking a sample of the 1000 most recent bug reports
filed and determining which packages received the top 20% of bug reports
by volume. Attached you'll find the data from the end of June.

Needs Packaging bug reports

As a part of the managing needs-packaging bug reports specification[1]
it was decided that all needs-packaging bug reports should have an
importance of wishlist. Subsequently, I've written a script using the
Launchpad API that will set the importance of almost all needs-packaging
bugs to wishlist.

Barring any objections I plan on running this on the Friday the 13th,
which will modify approximately 254 bug reports, and scheduling it to
run weekly thereafter.

The criteria used are bugs tagged 'needs-packaging' with an importance
of 'Undecided' and not bug 260918.

Package Removal Resource

I was trying to find information on packages that have been removed from
the archive - specifically for the report that used to be at
<a href="" title=""></a>. However, it
isn't there any more - is there a reason it isn't?

Additionally, it is referred to by the wiki page at
<a href="" title=""></a> which should
probably be updated if the report no longer exists.


Package Bug Reporting Guidelines

In Launchpad it recently became possible to have bug filing guidelines
on a per package basis[1]. The bug filing guidelines are presented
whenever someone files a bug about the package, for an example see the
linux package[2]. However, currently only the ubuntu-drivers team can
set those guidelines[3]. As an interim solution I've written a script,
using the Launchpad API, to set the guidelines for a package or a group
of packages. We are currently collecting guidelines in the
package-bug-guidelines directory of the ubuntu-qa-tools[4] project in

Ubuntu Bug Day - 11 September 2008

There seem to be quite a few Confirmed bug reports that don't have a
package assigned to them and these will be the target of the next hug
day on Thursday, September 11th. Ideally the number of these bugs
should be zero but at the moment we'll focus on driving the number down
from its current level of about 230. We'll do this by assigning bugs to
packages in addition to following up with reports, documenting test
cases, confirming bug reports and testing to see if the bug still exists
in Intrepid. The event will be held in #ubuntu-bugs on Freenode.