init, apt-listbugs & apt-listchanges

Hi all,
This will be a sorta longish post about apt-listbugs and apt-listchanges, packages which can and do help you if you are using a deb-based distribution as your Operating System/Poison of choice. The rest of the blog post would be about how I do/go about configuring those two packages and where they are more helpful than others.

First of all, sorry for being away, I have been a bit lazy of late and don’t think this is going to be changing in the near-term. The second bit of sad and controversial news of what has been happening in Debian. I have been quite a bit of GNOME fanboy over the last several years with XFCE being a distant second. I have tried other desktops such as LXDE,KDE and a few others but have been loyal towards GNOME. Arguably, GNOME is the best supported desktop environment in Debian. Now whether it’s due to it being the default desktop or something else I would let more sharper individuals comment about it. Now coming to the sad part, there has been quite a few strong posts happening on debian-devel about a possible init replacement. Rather than try to explain about init in my clumsy way of things let me borrow the same from wikipedia :-

In Unix-based computer operating systems, init (short for initialization) is the first process started during booting of the computer system. Init is a daemon process that continues running until the system is shut down.

This is from . Now sysvinit has been the default in debian for number of years. Now due to various internal and external pressures, for quite sometime there has been a vocal request/demand for a newish init system as hardware has changed and people’s expectations from software too has changed. All of the newer contenders for sysvinit should make it faster than init is today but will require a lot of help from package maintainers overtime once a choice has been made. I would not delve into which side is better or not but will leave it at . Having said that I’m a bit biased towards systemd as it’s part of GNOME and me having quite a bit of bias against the Canonical CLA. The sad part is that one of the most prolific packagers, contributor and developer by far Michael Biebl has taken a sabbatical from contributing to Debian. Now while he is/was the main uploader and contributor to systemd, he is/was also responsible for at least more than half of packages of GNOME (at least this 3.4 -> 3.8 release transition) and even earlier ones.

Michael, you would be sorely missed and hopefully you will join us sooner than later if it’s for the discussion about init.

There is also this if people want to see the discussion about the init system as well.

Now coming back to the topic in question, like many other people I like newer stuff or the shiny things. The problem with getting shiny stuff (as in new packages) is that they bring or can bring nasty problems and surprises with them as well. Imagine you are updating a package and that updation results in your system gets locked, crashes and doesn’t boot up or any other myriad ways in which you mess the system. Now by default, Debian has no way to warn you about if you are installing or updating a package which would be harmful to you. Enter apt-listbugs to the rescue.

$ aptitude show apt-listbugs
Package: apt-listbugs
State: installed
Automatically installed: no
Version: 0.1.11
Priority: optional
Section: admin
Maintainer: Francesco Poli (wintermute)
Architecture: all
Uncompressed Size: 428 k
Depends: ruby | ruby-interpreter, ruby-debian (>= 0.3.3), apt (>= 0.9.11), ruby-gettext (>= 3.0.2), ruby-xmlparser, ruby-httpclient (>=, ruby-soap4r
Suggests: reportbug, debianutils (>= 2.0) | www-browser | w3m
Breaks: libapt-pkg4.12 (< 0.9.11)
Description: tool which lists critical bugs before each apt installation
apt-listbugs is a tool which retrieves bug reports from the Debian Bug Tracking System and lists them. Especially, it is intended to be invoked before each upgrade/installation by apt in order to check whether the upgrade/installation is safe.

Many developers and users prefer the unstable version of Debian for its new features and packages. apt, the usual upgrade tool, can break your system by installing a buggy package.

apt-listbugs lists critical bug reports from the Debian Bug Tracking System. Run it before apt to see if an upgrade or installation is known to be unsafe.

Now as can be seen I’ve installed it as can be seen from the state of the package. To install it is simple, just use your favorite package manager and install it, for e.g. :-

$ sudo aptitude install apt-listbugs

and leave the rest to your package manager to work it out/install in your system. The defaults in apt-listbugs are good enough but if you want to change see the file at /etc/apt/apt.conf.d/10apt-listbugs. This is the file which controls which bugs it will show. The manpage of apt-listbugs gives much more info. I use the defaults and that is good enough for me. The only thing I did was changing the priority of the package so that it gets the bandwidth when it wants to handshake with the debian-bts to see if there are any serious/grave bugs when I’m upgrading a $PACKAGE.

It does and comes with a big caveat though, it would work only when a bug has been reported with a high enough severity, so somebody has to report the bug. So, if you are a person like me who does not want to be adventurous when updating packages wait for a day or two and then upgrade. Usually a day or two is enough for people to catch and triage a bug in case if it’s a much-used/mainstream package. A point to also keep in mind is that this is most useful in testing, unstable, backports and experimental. Stable would be the odd one out as it would have stable updates and it’s highly unlikely that anything other than bug-fixes come in.

Please do take that with a pinch of a fistful of salt as it’s a volunteer project and important and grave bugs can happen due to various factors which are beyond the package maintainer’s ability to test beforehand. If you look at the huge number of hardware architectures and number of permutations, combinations and relation a package can/may have with others, it’s next to impossible for a package uploader and maintainer to test and know all that beforehand.

For e.g. if you install a GNOME/GTK package and you are using kdm or some other display manager and for some reason that package does not work. It is possible and probable that the package maintainer might not have tried this combination, or some other combination.

The one where I have done some changes is apt-listchanges though. One of the things to be careful while using apt-listchanges is information overload. This would be understood as you start using it.

This is what apt-listchanges is all about :-

$ aptitude show apt-listchanges
Package: apt-listchanges
State: installed
Automatically installed: no
Version: 2.85.11
Priority: standard
Section: utils
Maintainer: Sandro Tosi
Architecture: all
Uncompressed Size: 208 k
Depends: python (>= 2.4), python-support (>= 0.90.0), apt (>= 0.5.3), python-apt (>= 0.7.93), ucf (>= 0.28), debianutils (>= 2.0.2), debconf (>= 0.5) | debconf-2.0
Suggests: x-terminal-emulator, www-browser, python-glade2, python-gtk2, default-mta | mail-transport-agent
Description: package change history notification tool
The tool apt-listchanges can compare a new version of a package with the one currently installed and show what has been changed, by extracting the relevant entries from the Debian changelog and NEWS files.

It can be run on several .deb archives at a time to get a list of all changes that would be caused by installing or upgrading a group of packages. When configured as an APT plugin it will do this automatically during upgrades.

Installing it as same as the other. What comes into play afterwards is the configuration file where there is quite a bit that can be played with quite a bit. You have to make a file in /etc/apt/ and call it listchanges.conf. The manpage tells how one can configure it. This is the way I configured it :-

/etc/apt$ cat listchanges.conf

The configuration file is pretty simple to follow. The first line tells which front-end to use. In my case I like to see a gtk window so using that. This is good if you have a GUI, if you are on a server than obviously changing to text would be the better course. I asked for confirmation as many a times there are and might be drastic changes in the new version of the package, so that extra confirmation makes it possible to either take backups of a configuration file/data whatever in case of a change you are not sure about. If you read the changelog as shared at times how the package is behaving can be understood. At other times the changelog can help to fine-tune the bug-report (if you encounter a bug). Do mind though, at times the changelog can be quite huge so it might not be everybody’s cup of tea as well.

The third line is to make a database so after a period of time when new changes come in, the changelog is diff’ed against the changelog in the database and only the diff. between the two is shown as a changelog could contain changes over number of years, the largest I have seen are going over 12 years or more which adds to lot of data without being able to comprehend the info. which you need to make sense of.

The fourth line is saying that I want to see both the changelog as well as news files as sometimes the package maintainer choose to put the changes in news files and have an emptyish changelog.debian.gz. OR as shared above, sometimes big changes to a package are told/shared in the NEWS.gz file. The policy about where to what info. is given in Debian policy as well as $PACKAGE_MAINTAINER’s right.

The biggest thing is that the changelog as can be seen in any package is a gunzipped file usually found at /usr/share/doc/$PACKAGENAME/changelog.debian.gz as well as sometimes NEWS.gz for e.g. see aptitude :-

/usr/share/doc/aptitude$ ls
changelog.Debian.gz changelog.gz copyright examples html NEWS NEWS.Debian.gz README README.Debian README.hier TODO

Now traversing the changelog.Debian.gz and trying to figure out what the recent changes were/are is going to be a pain. Having a tool like the above makes it much more manageable. In fact, I bet, in a production environment, having a changelog as well as the diff. between the two packages would help immensely in internal code-reviews as well.

So that tool could and does help a lot not just ordinary users who use debian but much more if you are a developer or a sysadmin who’s responsible for changes happening on a single system or a network.

I do hope my mumbling did give some insight as to how useful the packages themselves are. Now this post would not have been possible if it was not for the huge Debian community and the amount of support they give/share as well as the respective developers and package maintainers as well.

Francesco Poli of apt-listbugs (maintainer and upstream developer I think as s/he wears both hats recently) as well as Sandro Tosi, if we ever meet in a real-life, please ask me to buy you a beer as it has been rare but few times when you have saved my skin. Feel free to comment or/and flame. Till l8er folks.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.