Seiten

Wednesday, October 29, 2008

/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.

Thursday, October 16, 2008

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.

Friday, May 16, 2008

/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.

Wednesday, May 14, 2008

[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)?

Tuesday, April 29, 2008

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.

Monday, March 31, 2008

DIN bestreitet Verfahrensmängel bei der Abstimmung zu OOXML mit 7 zu 13 Stimmen

Wie vor wenigen Tagen veröffentlicht, hat das Lenkungsgremium des DIN-Normenausschusses Informationstechnik und Anwendungen (NIA) entschieden, dass bei der Abstimmung zum OOXML-Schrott “nach formalen Kriterien der Prozessablauf in der ISO nach Meinung des Lenkungsgremiums” nicht “fehlerhaft gewesen sei”.

Bei gerade einmal 7(!) von insgesamt 20 Stimmen, die dafür stimmten (6 stimmten explizit dagegen und eine Ja-Stimme holte man sich auch noch vom hauptamtlichen Mitarbeiter des DIN), bleibt mir nur zu sagen: Wohl kaum, liebes DIN! Mit diesem Ergebnis dann auch noch von einer “falschen und irreführenden” Berichterstattung bei den objektiven Berichterstattern zu sprechen, ist einfach nur unverschämt. Wenn gerade einmal 1/3 der Stimmberechtigten votieren, dass ein Verfahren keine Verfahrensmängel hatte und das als Beweis dieser These herangezogen wird, dann spreche ich von einer falschen und irreführenden Berichterstattung bei der DIN.

Thursday, March 20, 2008

“Einschüchterung” hier und “Gelassenheit” da

Gestern hat das Bundesverfassungsgericht per Eilentscheidung die Vorratsdatenspeicherung zunächst einmal eingeschränkt. Dabei bescheinigten die Richter dieser Maßnahme einen:

erheblichen Einschüchterungseffekt.

Der stellvertrendende Regierungssprecher Thomas Steg sagte dazu:

Im Kabinett jedenfalls ist die Entscheidung nicht lange diskutiert worden und sie ist mit großer Gelassenheit zur Kenntnis genommen worden.

Wie bitte? Mir ist nicht ganz klar, wie sich die Einschüchterung der Bevölkerung mit der freiheitlich demokratischen Grundordnung vereinbaren lässt. Ist diese Regierung an letzterem nicht sonderlich interessiert? Hätte man sonst die Aussage der roten Roben mit großer Gelassenheit zur Kenntnis genommen?

Es bleibt nur zu hoffen, dass das Bundesverfassungsgericht die Zugriffsmöglichkeiten und die Speicherfristen in seiner endgültigen Entscheidung weiter beschränken wird. Nach bisherigem Vernehmen wird das Gesetz selber wohl nicht gekippt werden (AFAIK und IANAL).

Sunday, March 16, 2008

Diploma exams are calling: Please read if you want to NMU my packages

Because my diploma exams are getting nearer, I have to reduce my contribution to the Debian project for the next two months (up to mid/end of May). There is fortunately currently not much to do for me and also no need to NMU my packages. But please read the following notes, if you (still) think there is a reason for a NMU:

GCC 4.3 transition

Done. All related packages have been fixed. My sponsor just needs to upload psicode to fix the last outstanding bug.

PS: Also the build-twice-in-a-row release goal will be reached by the upload of the apbs update by my sponsor.

gfortran transition

Almost done. mpqc already reached the buildds. ghemical has been uploaded, but waits for mopac7 and libghemical, which are in NEW because of the new library names.

apbs and psicode already have been transitioned.

Other bugs

Ok, I've closed almost all relevant bugs in my packages. There are a few outstanding bugs that should be examined for Lenny and can be fixed in NMUs - preferable via delayed NMU queue and an information to the debichem group:

#420795: chemical-mime-data: Unknown media type in type ‘chemical/x-*’
Upstream bug tracker for shared-mime-info contains some more information, how to deal with this. Patches/ideas welcome.
#438694: gabedit: Crashes when loading any XYZ format file
Looks tricky. Maybe an OpenGL issue related to some video card drivers. Not sure.
#442223: openbabel: some connect information lost when convert from pdb to txyz
Nothing examined yet to solve this bug.
#464867: extrema: conflicts with psi3 package
Hope, my team will cover this asap.
#465723: mopac7 — please do not use g2c.
There is currently a workaround using f2c to solve this bug. But MOPAC7 has been written in FORTRAN and we can use gfortran and drop f2c completely. See the report for more information. This is something I would like to see in Lenny.

For the xmlto package it was planned to add the dblatex toolchain for PDF/PS/DVI creation because passivetex will very probably never have a comeback in Debian and docbook-xsl/fop is not fully main and cannot create DVI output. In the case you want to help, feel free to add this feature by NMU to experimental (maybe with version 0.0.21~dblatexX.Y). A first patch is available in bug report #416622.

New upstream releases

It is possible that there will be a new upstream release for docbook-xsl in the near future. DO NOT consider uploading it by NMU if you did not test it! This upcoming release ships manpage stylesheets, that have been rewritten in large parts. So regressions can be expected. Fortunately Michael Smith and me agreed, that we should test it carefully, before the release is done. Unfortunately I will not have the time to do it. So if you consider uploading it, please get in contact with Michael (xmldoc) and offer your help testing it. He added (and I hope, many Debian packagers and packaging groups will like that) some kind of regressions tests. These tests build the manpages from several Debian packages: e.g. samba, apt, aptitude, git, fglrx and some more. There are further some new supported features, that should be added to the manpage example shipped with the Debian package. I also planned to split the source package (atm, docbook-xsl and docbook-xsl-doc tarballs are merged together for Debian) as soon as docbook-xsl-ns is packaged - which I wanted to do with the next upstream release. So consider all of the above notes if you plan an NMU to upload a new upstream release and in question, mail me and wait for my answer (which will need some days).

In all other cases, new upstream releases should be easier to handle.

ITPs

All my ITPs are delayed. However if you plan to still upload one of these packages, you should consider the following notes:

docbook-xsl-ns
See the above note about docbook-xsl and the source package split.
html-xml-utils
Already in a good shape, but I sent upstream some patches to improve the manpages. Version 4.6 of the html-xml-utils should contain these patches and this version should be uploaded into Debian. With this version, Bert Bos will probably also decide, which prefix will be used for the binaries (they have very generic names atm; the prefix will probably be hx- or hxu-). Waiting for this releaes therefor is IMHO a good choice.
DocBook 5
I already found a problem that need to be addressed in the package: Where to install its catalog? You will see, that there is already a catalog file in /usr/share/xml/docbook/schema/dtd/ shipped by the docbook-xml. Now I'm not sure, what to do here. Upstream ships one catalog file for all supported schemas (RNG, DTD, W3C schema and schematron), so maybe the catalog file can go into /usr/share/xml/docbook/schema/. Really not sure atm. The answer to this question might affect the Debian XML policy and should be made carefully.

QA work/fixes

Several lintian warnings have already been fixed in the SVN repositories used for my packages but have not yet been uploaded.

I really only plan to reduce my work during the preparation and the exams. So whatever you do, please try to make it easy for me to continue my packaging work after the exams :)

Friday, February 29, 2008

Packages removed from the debian.wgdd.de repository

Several packages have been removed from the archive:

CDK
The »Chemistry Development Kit« (CDK) now has been officially packaged and uploaded by Michael Koch. If you still have my packages installed, first uninstall/purge libcdk-java-doc, cdk und libcdk-java-dirbrowser (completely) and then install the current version of libcdk-java. Scripts found in cdk will probably be added to the Debian distribution soon.
Jchempaint
Jchempaint has been merged into CDK some time ago and there are plans to build/package it for Debian. My packages were just outdated. Please expect updated packages from the Debian mirror next to you :)
Jmol
Ditto. We are working on an official Debian package. I'm not planning nor working on an official Debian package. But there is an ITP (#512930) for it.
MOLDEN
This package was outdated. The current release is version 4.6. The packaging files have been moved to the debichem groups SVN. You can build the package yourself by using svn-buildpackage. Just download the MOLDEN source and the packaging files. Then set the configuration option svn-override=buildArea for svn-buildpackage to the place where the upstream tarball resists (create the symlink molden_4.6.orig.tar.gz -> molden4.6.tar.gz) and run svn-buildpackage with your preferred options.
We are currently not allowed to distribute MOLDEN binaries or its source with the Debian distribution. But we are in contact with upstream.
clamassassin
There is an official clamassassin Debian package for some time now. However, the package only ships the clamssassin script, but not clamdassassin.

Friday, February 15, 2008

pbuilder and SUN Java

pbuilder with default settings will fail to build a package depending on sun-java5 or sun-java6, because the license needs to be accepted first.

Now some time ago I saw a patch for pbuilder itself to “fix” this, but for the time beeing I used to set DEBIAN_FRONTEND to readline in my pbuilderrc. But today Michael Koch came up with much better suggestions: Preset the debconf value in the CHROOT and save it.

It's pretty easy:

$ sudo pbuilder login --save-after-login
# echo "sun-java5-jdk shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections
# echo "sun-java6-jdk shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections
# exit

and voila, problem solved. Thanks to Michael for the tip.

Update

Manual Prinz suggested a slightly different way, that realizes the same debconf setting, but with hooks.