bluefish-unstable packages for Etch removed from repository

The bluefish-unstable packages for Etch have been removed from the repository. The 1.1 development series has been superseeded by the 1.3 series (1.0 is still the current stable series!), which needs Glib/Gtk versions higher than available in Etch. Unfortunately, the necessary versions are also not available from backports.org. So I can't build packages for Etch anymore :(.

If you have some self-packaged or -compiled versions of these libraries, you can of course build the application from its source.

Ubuntu Hardy repository replaced by Intrepid repository

The Ubuntu Hardy repository has been dropped and replaced by an Intrepid repository. If you need the bluefish-unstable package for an Ubuntu Hardy installation, keep the deb-src entry from the previous sources.list snippet, get the source and the build-dependencies. Then build the package(s) and install them.

apt-get source bluefish-unstable
apt-get build-dep bluefish-unstable
cd bluefish-unstable-version
debuild -us -uc
...
dpkg -i package.deb

The same goes for building the package for a different architecture than i386!

/etc/apt/sources.list.d/ snippets available for download

I now provide small snippets to download into the /etc/apt/sources.list.d/ directory, so you don't have to edit /etc/apt/sources.list directly. The necessary commands are described described here. Every snippet is limited to one release. So if you want to have the entries for more than one release (e.g. Sid+Experimental) you have to download several files.

Repository key expired IV

The repository-key has expired at October 16th 2008. The new expiration date of the renewed key is October 16th 2009. You will have to update the key in your apt keyring. It can be found at the pgp.mit.edu keyserver or locally in ASCII format at wgdd_archive_key.asc. Detailed information can be found here.

/usr/lib/python2.3 garbage

Yesterday I stumbled about files and dead symlinks left in /usr/lib/python2.3/site-packages/ on my Sid box. These files/symlinks seem to have been shipped/created(?) by:

python-ldap python-cairo python-crypto kiki python-foomatic python-mysqldb
python-logilab-common python-egenix-mxtools python-numarray python-pygresql
python-imaging-sane python-imaging python-xml python-reportlab

Deleting /usr/lib/python2.3 (dpkg -S didn't show any package relationship nor did I find something in /var/lib/dpkg/info/) and reinstalling the above mentioned packages did not recreate the files/symlinks. So it seems the directory can be safely removed. Maybe I missed some announcement or one (or more) packages need to be fixed. No time to examine it atm.

Update

This is known as Debian bug #409390. Thanks to Josselin Mouette for the information.

[DSA 1571-1] New openssl packages fix predictable random number generator

Ok, shit sometimes also happens to Debian users.

Now I read a lot of FUD, flames, arrogant claims and much more bad things, including blaming of downstream in general.

Well, Debian maintainers are NOT upstream authors. Maintainers often care about a lot more than just 1 package. Now I wonder if one can really expect, that maintainers know the source code of their packages as good as upstream authors do? Is this, what the user or the Debian project expects from a package maintainer? I agree, that this would be the ideal situation. But how realistic is it, if one maintains 10, 20 or more packages?

Normally users report us issues. We take a look at the source, try to catch the issue, track it down and fix it. And IMHO in almost all cases this is enough and it lets us handle several packages. And maybe this is also, what happened here. The maintainer got a report, tracked it down and tried to fix it. It seems, he posted it to the openssl-dev list, which is to my reading considered for such questions, and got a positive response. And with fixing it, he made a horrible mistake. But apparently it also seems, that the question had been discussed earlier more than just once (I wish, the OpenSSL guys would have created the FAQ entry earlier).

I don't want to blame the maintainer for doing this mistake. We are humans. But do we need another instance, that (periodically) checks (probably only Debian-specific) patches/changes to security relevent software or do we need different requirements for maintainers of such software ^[1] or should we simply archive this under “Shit sometimes happens … even to Debian users”?

[1] Consider gnupg which is currently almost unmaintained. It also has Debian specific patches applied and I wonder, which skills the new maintainer should or must(?) have (IIRC this question was raised in the linked threads too)?

Sorry

I'm sorry for any inconvenience you had yesterday or today trying to access my web services. But I had to perform some long standing maintenance tasks. The service is now running again. If you still observe problems, please don't hesitate to tell me.