Tag Archives: debian

Please Help to Port python-debianbts to Python3

Dear Lazyweb,

I’m currently trying to find a way to port python-debianbts to Python3. Debian’s standard bugreport tool reportbug depends on python-debianbts and can thus not convert to Python3 if python-debianbts does not as well. Unfortunately python-debianbts depends on SoapPy for parsing the Debian bugtracker’s responses, and that library is not ported to Python3 yet, and probably never will.

I’m planning to replace SoapPy with pysimplesoap which is available for Python2 and Python3. Unfortunately debbugs does not support WSDL which makes parsing of the replies extremely painful and error-prone. I wonder if there is a  SOAP/Python expert out there who’d be willing to give some assistance in porting python-reportbug to pysimplesoap? python-reportbug’s repository is on GitHub and patches are very welcome.

Since SOAP is quite a beast and debbugs uses it for read-only purposes only, another attractive solution would be to replace/augment debbugs’ API with something much more simple, like JSON. That would make parsing extremely easy as many programming languages including Python support JSON without any external libraries. In theory this could be quite easy but requires some serious Perl skills.

General Resolution is not required

The result for the General Resolution about the init system coupling is out and the result is, not quite surprisingly, “General Resolution is not required”.

When skimming over -devel or -private from time to time, one easily gets the impression that we are all a bunch of zealots, all too eager for fighting. People argue in the worst possible ways. People make bold statements about the future of Debian if solution X is preferred over Y. People call each other names. People leave the project.

At some point you realize, we’re not all a bunch of zealots, it is usually only the same small subset of people always involved in those discussions. It’s reassuring that we still seem to have a silent majority in Debian that, without much fuss, just do what they can to make Debian better. In this sense: A General Resolution is not required.

Wee! Wheezy is out (better late than never)

Last week we released Wheezy, roughly two years after our last release Squeeze.

I’d like to thank all the contributors in- and outside of Debian for your fine work! Every single contribution — no matter how big or small — summed up to the wonderful release we finished last week. Without you this release would not have been possible. Keep up the good work guys and make Jessie rock even harder!

PS: It is very nice to see once again fresh packages rolling into unstable and spending some time fixing broken dependencies :)

Shiny new iPod Nano 6G… fffffffuuuuuuuuuuuu

So I got an iPod Nano (6th generation) for Christmas this year, just in time since my trusty old iPod Mini started beg for retirement after almost 8 years of usage.

Since my old iPod was working like a charm all those years I expected a smooth sailing when I plugged in my new iPod Nano. Gnome recognized it correctly and mounted the device. The iPod showed up in Rhythmbox as I was used to and I started to fill it with some music. Everything worked as expected: Rhythmbox copied the music to the iPod without complaining and after unmounting the iPod and starting it — it was emtpy. Whait, what? Why is it empty? Didn’t I just… So I tried again, and again with the same result.

Half an hour later I found out that libgpod (the iPod “driver” for Linux) supports all iPods except the iPod Nano 6G. Bummer. Apparently Apple changed the algorithm to calculate the checksums of the files on the device and since that algorithm is unknown you cannot successfully write on it with free software.

That means technically this device is unusable for Linux users since iTunes doesn’t run on Linux. However, there seems to be a way to use the iPod Nano with libgpod if you are trusting this guy and willing to use his binary (only!) file with libgpod (which I am not). And somehow the guys over at Spotify managed to get the iPod Nano running in their Linux client but they don’t provide the code either.

Being already more than two years old, I don’t have much hope that the iPod Nano will work on Linux with libgpod in the foreseeable future. On the bright side I can say the device is not totally useless as it comes with FM radio…


A few days ago I found this blog explaining how to improve the tab completion by tinkering with your .inputrc.

The magic lines are:

set show-all-if-ambiguous on
set completion-ignore-case on
set completion-map-case on

Last two lines make tab-completion ignore case, hyphens, underscores, the first one spares you one tab when more than one match was found. Very neat! I would have never found out, since there wasn’t even an .inputrc in my home directory.

Do you know any other cool .inputrc-tricks?

Can aptitude show older versions of packages if available in /var/cache/apt/archives?

Dear Lazyweb,

is it possible to tell aptitude to show older versions of a package next to the currently available one if it is still present in /var/cache/apt/archives? Like it does when you use unstable and experimental side by side? I know that aptitude does not really support downgrades of packages, but showing those packages directly in aptitude if available in the cache is a lot easier than searching them in the file system and installing them manually, especially if you don’t know where they hide.

How to get a list of manually installed packages (and remove the other ones)

The Good

Every other year or so I feel the need to clean up my Debian system and remove the installed packages I’m not interested in anymore. I remember there was a nice aptitude pattern to search for packages which I have manually installed (i.e. which were not installed to satisfy a dependency). Ideally I would then go through the (presumably short) list of packages and remove the ones I don’t need any more.

Since I always forget the aptitude pattern to search for those packages, I google for something like “list of manually installed packages” and find a solution like: aptitude search ‘~i !~M’. Although this solution is not wrong, it is not quite what I was looking for. Sure, it will find you all packages which are installed and not installed to satisfy a dependency, but it also contains packages of priorities: required, important and standard which you usually don’t want to deinstall. So the actual solution should also exclude those packages.

aptitude search '~i !~M !~pstandard !~pimportant !~prequired'

The above line will do the trick and present you a list of packages which are: installed and not dragged in to satisfy a dependency and not of priority standard, important or required.

If you where only interested in the solution of the quest of getting a list of all manually installed packages you can stop reading here.

The Bad

If you’re running your system for longer than, say, a few weeks you will probably notice that the list is very long and contains much more packages than you actually installed manually. You will probably notice a lot of libs and other packages in this list and wonder why they aren’t marked auto as they should since you didn’t install them on purpose. Unfortunately I don’t have an answer for that question. I’m using aptitude exclusively to install packages and rely on the fact that aptitude does install the dependencies automatically and more importantly: also removes them if not needed any more. But it seems like something is broken in aptitude (or somewhere else) and packages simply lose their auto status instead of being removed and thus stay on your system forever if you don’t manually clean your system.

The Ugly

To solve that issue I started aptitude and filtered the package tree with the above pattern (press l in aptitude and enter ~i !~M !~pstandard !~pimportant !~prequired). Now the package view shows only packages which are safe to remove since they are not of of priority standard or higher and manually installed by you. Now I navigate with the cursor to the list of installed packages an mark all of them as auto by pressing M. For each package in this list, aptitude will try to find an installed package which depends on that package and mark that package auto. The remaining packages which no other packages depend on, aptitude will mark for deletion. If you now press g one time, aptitude will show you which packages will be removed. I then go through that list and mark every single of the remaining packages I really want on my system with + as manually installed. After I’m done I proceed by pressing g again which will remove all remaining packages. In my case nearly 600 packages (1GB) where removed.


I assume there is a bug in aptitude or some related package which sometimes(!) removes a packages auto status instead of removing it. Unfortunately I did not find a way to reproduce that (except that it obviously does happen). If someone could find a way to reproduce that problem, one could fill a bugreport and help to get that bug fixed. Right now, a Debian system suffers (like many other operating systems) from a slow but steadily growing bloat of installed software. In my case 600 packages with 1GB accumulated over one or two years.