Make 'bts' (devscripts) accept TLS connection to mail server with self signed certificate

My mail server runs with a self signed certificate. So bts, configured like this ...

BTS_SMTP_HOST=mail.wgdd.de:587
BTS_SMTP_AUTH_USERNAME='user'
BTS_SMTP_AUTH_PASSWORD='pass'

...lately refused to send mails with this error:

bts: failed to open SMTP connection to mail.wgdd.de:587
(SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed)

After searching a bit, I found a way to fix this locally without turning off the server certificate verification. The fix belongs into the send_mail() function. When calling the Net::SMTPS->new() constructor, it is possible to add the fingerprint of my self signed certificate like this (bold):

if (have_smtps) {
    $smtp = Net::SMTPS->new($host, Port => $port,
        Hello => $smtphelo, doSSL => 'starttls',
        SSL_fingerprint => 'sha1$hex-fingerprint')
        or die "$progname: failed to open SMTP connection to $smtphost\n($@)\n";
} else {
    $smtp = Net::SMTP->new($host, Port => $port, Hello => $smtphelo)
        or die "$progname: failed to open SMTP connection to $smtphost\n($@)\n";
}

Pretty happy to being able to use the bts command again.

Setting up a network buildd with pbuilder ... continued

Last year I'd described my setup of a local network-buildd using pbuilder, ccache, inoticoming and NFS. One then-still-open goal was to support different Debian releases. This is especially necessary for backports of e.g. bluefish. The rules to contribute backports require to include all changelog entries since the last version on debian-backports or since stable if it's the first version in an uploaded package. Therefor one needs to know the last version in e.g. wheezy-backports. Because I'm not typing the command (the source package only gets uploaded and inoticoming starts the build process) I was looking for a way to automatically retrieve that version and add the relevant -vX.Y-Z switch to dpkg-buildpackage.

The solution I found requires aptitude and a sources.list entry for the relevant release. If you are only interested in the solution, just jump to the end :)

I'm going to add the version switch to the DEBBUILDOPTS variable of pbuilder. In my setup I have a common (shared) snippet called /etc/pbuilderrc.inc and one configuration file per release and architecture, say /etc/pbuilderrc.amd64.stable. Now the first already contains ...

DEBBUILDOPTS="-us -uc -j2"

... and DEBBUILDOPTS can be extended in the latter:

DEBBUILDOPTS+="..."

Because the config file is parsed pretty early in the process the package name has not yet been assigned to any variable. The last argument to pbuilder is the .dsc file. So I use the last argument and parse the file to retrieve the source package name.

cat ${@: -1} | grep -e ^Source | awk -F\  '{ print $2 }'

The solution above works, because pbuilder is a BASH script. Otherwise it maybe needs some tweaking. I use the source package name, because it is unique and there is just one :) Now with this name I check for all versions in wheezy* and stable* and sort them. The sort order of aptitude is from low to high, so the last line shopuld contain the highest version. This covers the possibility that there has not yet been a backport or that there is one:

aptitude versions -F '%p' --show-package-names=never --group-by=none --sort=version \
   "?narrow(?source-package(^PACKAGE\$), ?or(?archive(^wheezy.*), ?archive(^stable.*)))" |\
   tail -n 1 | sed -e 's#~bpo.*$##g'

The sed-part is necessary because otherwise dh_genchanges will add a superfluous changelog entry (the last one of the last upload). To make things easier, I assign the name and version to variables. So this is the complete solution:

[..]
MYPACKAGE="`cat ${@: -1} | grep -e ^Source | awk -F\  '{ print $2 }'`"
MYBPOVERS="`aptitude versions -F '%p' --show-package-names=never --group-by=none --sort=version "?narrow(?source-package(^$MYPACKAGE\$), ?or(?archive(^wheezy.*), ?archive(^stable.*)))" | tail -n 1 | sed -e 's#~bpo.*$##g'`"

log "I: Package is $MYPACKAGE and last stable/bpo version is $MYBPOVERS"

DEBBUILDOPTS+=" -v$MYBPOVERS"
[..]

Examples

I've recently built a new bluefish backport. The last backport version is 2.2.6-1~bpo70+1. There is also the stable version 2.2.3-4. So the version I need is 2.2.6-1 (2.2.6-1~bpo70+1 < 2.2.6-1!!). Checking the log it works:

I: Package is bluefish and last stable/bpo version is 2.2.6-1

A different example is rsync. I've recently locally rebuilt it for a stable system (wanted to make use of the --chown switch). There is not yet a backport. So the version I (would) need is 3.0.9-4. Checking the logs again and works too:

I: Package is rsync and last stable/bpo version is 3.0.9-4

Feedback appreciated ...

Links

• aptitude: Search term reference
• aptitude: Customizing the package list

Removal of debian.wgdd.de and {cvs,svn,vcs}.wgdd.de

If you've recently tried to browse to or apt-get from either cvs.wgdd.de, svn.wgdd.de, vcs.wgdd.de, debian.wgdd.de or ubuntu.wgdd.de you've probably seen (and still are) an error (410, Gone) coming up and I'd like to give a short explanation why.

{cvs,svn,vcs}.wgdd.de

I've left my server provider and shut down the above services and only keep a small amount of services running. The domains {cvs,svn,vcs}.wgdd.de were used to provide (a) a subversion (SVN) server (via HTTPS and dav_svn) for some public and private work and (b) a CVS web-client to some old project works in CVS.

Among the latter was e.g. old code to generate manual pages for the proprietary fglrx graphics driver, stuff that laid there untouched for many years. So I guess, it was about time to finally remove it :)

The subversion web-client gave public access to some packaging work I do for the Debian GNU/Linux distribution, e.g. for the cvsweb, gtypist packages and some non-official packaging work. For the official packages I plan to move the files into the collab-maint web space and adjust the packages control files accordingly. Everything else will be hosted non-publicly in the future. I still intend to move stuff, that turns out to be useful for more people, to public places like github and Co. Update 17.11.2014: cvsweb, gurlchecker and gtypist have been moved to collab-maint.

debian.wgdd.de

I used this site to describe my usage of Debian GNU/Linux on the hardware I own ... laptop, servers etc. I wrote a few HOWTOs and provided a link collection with useful links. You can still find all of this using the archive.org service. I also had a repository up and working, especially to provide bluefish packages for users of Debian stable and Ubuntu. Half a year ago I dropped the Ubuntu build environments and packages and moved the Debian stable backports to official places. This effectively emptied the repository and left only the wgdd-archive-keyring package in place. So, there is no real need for a public repository anymore and the linklist probably got outdated too. All in all, I decided to stop this service (maybe I'll forward the site to here later :)).

If you see an error regarding the debian.wgdd.de URL running apt-get or aptitude, then there is a reference to this site in /etc/apt/sources.list or /etc/apt/sources.list.d/*, which can be safely removed. Further you should get rid of the wgdd-archive-keyring package:

apt-get autoremove --purge wgdd-archive-keyring

... or the repository key:

apt-key del E394D996

What else

In case you need any content from the mentioned services, just let me know.

Bluefish packages for Ubuntu Linux now provided by Klaus Vormweg PPA

I will not longer provide packages of the bluefish-project for the Ubuntu distribution, because I lack time and interest in building and maintaining the necessary environments. Ubuntu-users however can still install and use recent releases of bluefish by changing to the PPA provided by Klaus Vormweg, who kindly agreed to officially provide packages for the project. Please follow the instructions given there.

Entries in /etc/apt/sources.list or /etc/apt/sources.list.d/* pointing to my repository should lead to the above mentioned PPA. But because Klaus is only offering the main-tree in his PPA, you might see some errors thrown by apt-get|aptitude|... as long as you keep my repository in your sources.list. So you probably want to remove any reference to my repository together with my repository key and/or the wgdd-archive-keyring package.

# remove sources.list snippets
rm /etc/apt/sources.list.d/debian.wgdd.de_ubuntu_*.list
# find any references left
grep -rn debian.wgdd.de /etc/apt/sources.list* # --> now delete those entries
# remove and purge the wgdd-archive-keyring package
apt-get autoremove --purge wgdd-archive-keyring
# or delete the key, if you never had the above package installed
apt-key del E394D996

You are done. Now download and install recent packages:

apt-get update
apt-get upgrade

Setting up a network buildd with pbuilder, ccache, inoticoming and NFS

I recently bought an N54L HP microserver, which shall act as a build-daemon (buildd) for Debian packaging. The idea of my workflow is the following:

1. do the maintenance tasks locally, usually using svn-buildpackage, quilt etc.pp
2. build a source package locally
3. upload the source to an incoming directory on the server
4. watch this incoming directory and start a build process as soon as a package is uploaded
5. put the result into an accessible directory
6. support different vendors (debian, ubuntu)
7. support different releases (experimental, unstable, stable, oldstable)
8. support different architectures (amd64, i386)
9. speed up the build process

Setting up the building environment

My first idea was to use sbuild as described in several places. However I went with pbuilder for a long time having a setup I personally like. So I decided to stay with it. I reduce the time and work to update the configure files by using

• one central file /etc/pbuilderrc.inc defining all the common/shared settings and
• small configure files defining vendor, release, architecture and mirrors

Here are the relevant parts of my central configure snippet:

[..]
EXTRAPACKAGES="apt-utils debconf debconf-utils libfile-fcntllock-perl"
[..]
BASETGZ="/var/cache/pbuilder/base.$DISTRIBUTION.$ARCHITECTURE.tgz"
APTCACHE="/var/cache/pbuilder/aptcache/$DISTRIBUTION/$ARCHITECTURE/"
BUILDRESULT="/var/cache/pbuilder/result/$DISTRIBUTION/$ARCHITECTURE/"
[..]
case "$VENDOR" in
ubuntu)
MIRRORSITE="http://archive.ubuntu.com/ubuntu"
COMPONENTS="main restricted universe multiverse"
OTHERMIRROR="\
deb http://de.archive.ubuntu.com/ubuntu $DISTRIBUTION main restricted universe multiverse|\
deb http://archive.ubuntu.com/ubuntu $DISTRIBUTION-updates main restricted universe multiverse|\
deb http://security.ubuntu.com/ubuntu $DISTRIBUTION-security main restricted universe multiverse|\
"
;;
*)
MIRRORSITE="http://ftp.debian.org/debian"
COMPONENTS="main contrib non-free"
OTHERMIRROR="\
deb http://ftp.de.debian.org/debian $DISTRIBUTION main contrib non-free|\
"
;;
esac
[..]
DEBBUILDOPTS="-us -uc -j2"
AUTO_DEBSIGN=no
USE_PDEBUILD_INTERNAL=yes
[..]

You get the main idea, right? Create own files and directories for each architecture, release and vendor. Further I only want to pull build related packages into the build environment, not into the server environment. So I enabled USE_PDEBUILD_INTERNAL. I don't want to sign anything on the buildd itself and use both cores. That's what DEBBUILDOPTS and AUTO_DEBSIGN are used for. Further I saw some warnings reported during build processes. I therefor install the packages mentioned in EXTRAPACKAGES to every build enviroment. The following are the configure files for the unstable amd64 (default) and the stable i386 build environments:

VENDOR="debian"
DISTRIBUTION="sid"
ARCHITECTURE="amd64"

. /etc/pbuilderrc.inc

VENDOR="debian"
DISTRIBUTION="wheezy"
ARCHITECTURE="i386"

. /etc/pbuilderrc.inc

OTHERMIRROR+="\
deb http://security.debian.org $DISTRIBUTION/updates main contrib non-free|\
"

Now to not having to update all of these environments manually there is a small parallelized script /usr/local/sbin/update-pbuilder-chroots:

#!/bin/sh

t=$(tempfile -p .upc. -s .list) || exit 1

cat > $t << EOF
/etc/pbuilderrc.amd64.sid
/etc/pbuilderrc.i386.sid
/etc/pbuilderrc.amd64.wheezy
/etc/pbuilderrc.i386.wheezy
/etc/pbuilderrc.amd64.squeeze
/etc/pbuilderrc.i386.squeeze
EOF

parallel /usr/sbin/pbuilder update --override-config --configfile :::: $t | tee -a /var/log/pbuilder.log

rm -f $t

exit 0

The script will make sure, that every change to the configuration file(s) will be considered (--override-config) and is run once a week via cron. The default build environment is updated on a daily base without this restriction:

@reboot root    rm -rf /var/cache/pbuilder/build/*/ >> /dev/null 2>&1
@daily  root    test -x /usr/sbin/pbuilder && /usr/sbin/pbuilder update --configfile /etc/pbuilderrc.amd64.sid | tee -a /var/log/pbuilder.log >> /dev/null 2>&1
@weekly root    test -x /usr/local/sbin/update-pbuilder-chroots && /usr/local/sbin/update-pbuilder-chroots >> /dev/null 2>&1

Speeding up the build process

Sometimes it is necessary to recompile a package. The tool to speed up this process is ccache, which can be easily integrated into pbuilder by setting CCACHEDIR in /etc/pbuilderrc.inc. It acts like a cache for compiled files and avoids recompilation in several buildd runs.

CCACHEDIR=/var/cache/pbuilder/ccache

It is also possible to use a TMPFS for BUILDPLACE to speed up the build process itself. In this case APTCACHEHARDLINK must be disabled. Well, yeah, I don't do this.

Watch an incoming directory and start the build process

Not much to say about this except that the user nobody is used to run the pbuilder command. Therefor it is necessary to mention this in /etc/sudoers to allow him to do this via sudo command:

Defaults        env_keep = "DH_OPTIONS DH_VERBOSE DEB_BUILD_OPTIONS DH_OPTIONS MAKEFLAGS CC CXX CPP F77 F90"
[..]
nobody          ALL=NOPASSWD:/usr/sbin/pbuilder

The first line is only necessary, if a pbuilder command is started with one of these environmental variables set. This can be useful when e.g. debugging a build failure with a future gcc version that is not yet the default or when debugging a clang build issue or when creating non-stripped binary packages for creating a backtrace (BTW: When there is a common repository of all debugging symbols created?).

Now to start the build process, I created an incoming directory with mods 777 at /var/cache/pbuilder/incoming/ and use inoticoming to watch it. This is started during boot via cron. The following shows the entry for the default unstable amd64 build environment:

@reboot root    /usr/bin/inoticoming --logfile /var/log/inoticoming.log --pid-file /var/run/inoticoming.pid /var/cache/pbuilder/incoming --chdir /var/cache/pbuilder/incoming --suffix .dsc --stderr-to-log --stdout-to-log /bin/su -c '/usr/bin/sudo /usr/sbin/pbuilder build --autocleanaptcache {}' nobody \;

Done. That's how the basic buildd works.

Getting the results

The pbuilder BUILDRESULT directory with mods 777 is shared via NFS mount to the workstation. After successfully building the package, debsign and dput can be used as usual.

Setting up the workstation

I use svn-buildpackage for most of my packages. Because pbuilder won't download source tarballs on demand by default (maybe via hook?), the tarball must always be included building the source package, which then gets uploaded via dput to the buildd. This is considered in the command listed in svn-builder in ~/.svn-buildpackage.conf (note, below shows my personal layout):

svn-builder=debuild --post-dpkg-buildpackage-hook=\"dput -f buildd /usr/local/src/packages/$PACKAGE/%p_%s_source.changes\" --no-lintian -d -sa -us -uc -S
svn-override=origDir=/usr/local/src/packages/$PACKAGE
svn-override=buildArea=/usr/local/src/packages/$PACKAGE
[..]

The host buildd has been added to ~/.dput.cf:

[buildd]
fqdn = mybuildd
login = mylogin
method = scp
incoming = /var/cache/pbuilder/incoming
allow_unsigned_uploads = 1
run_lintian = 0

Done. Now the svn-buildpackage command will create a source package including the source tarball and upload it to the buildd, where the package building starts right after the upload.

Conclusions

This is the main setup which works nicely for the default build environment so far. On the TODO list is to extend this setup so I can easily deal with all the architectures and releases (point 6..8 at the beginning).

Update 17.02.2015

The original article suggested to use the %v variable in the hook to transfer the _sources.changes file to the build-daemon. This will fail if the source version e.g. is X:Y-Z in which case the file created is package_Y-Z_source.changes but the command to execute is:

dput -f buildd package_X:Y-Z_source.changes

and thus will fail. According to dpkg-buildpackage(1) the hook command also accepts a %s variable, which seems to extract the superflous version characters.

Repository key expired VII

The repository-key expiration date has been extended recently. The expiration date of the renewed key has been set to be October 3rd, 2013. You will have to update the key in your apt keyring by either using (e.g.) the pgp.mit.edu keyserver:

apt-key adv --keyserver subkeys.pgp.net --refresh-keys E394D996

or a local keyfile in ASCII format at wgdd_archive_key.asc

wget -O - http://debian.wgdd.de/stuff/wgdd_archive_key.asc | apt-key add -

or by updating the wgdd-archive-keyring Debian package. Detailed information can also be found here.

Repository key expired VI

The repository-key had expired. The expiration date of the renewed key has been set to be October 20th 2012. You will have to update the key in your apt keyring by either using the pgp.mit.edu keyserver or a local keyfile in ASCII format at wgdd_archive_key.asc or by updating the wgdd-archive-keyring Debian package. Detailed information can also be found here.

New bluefish 2.0 packages available for i386 and amd64

With the release candidate 2 for Bluefish 2.0 my repository provides bluefish packages for the amd64 and i386 architectures. They will be automatically installed when you update your installed bluefish-unstable packages:

# apt-get dist-upgrade
The following NEW packages will be installed:
  bluefish bluefish-data bluefish-dbg bluefish-plugins
The following packages will be upgraded:
  bluefish-unstable bluefish-unstable-data bluefish-unstable-dbg bluefish-unstable-plugins

The latter became so called "transitional packages" and don't provide any functionality. They can be safely removed after upgrading to the bluefish packages:

# apt-get autoremove --purge bluefish-unstable bluefish-unstable-data bluefish-unstable-dbg bluefish-unstable-plugins

The package upgrade/installation will further replace any installation of the bluefish packages of Debian and Ubuntu!

Re: Making pbuilder just that little bit faster

It is true that making /var/cache/pbuilder/build a tmpfs makes a noticeable speed difference. But it seems you cannot cache the downloaded debs: ln: creating hard link ...: Invalid cross-device link.

Repository key expired V

The repository-key has expired at October 16th 2009. The expiration date of the renewed key has been set to be October 17th 2010. You will have to update the key in your apt keyring by either using the pgp.mit.edu keyserver or a local keyfile in ASCII format at wgdd_archive_key.asc or by updating the wgdd-archive-keyring Debian package. Detailed information can also be found here.

Ubuntu Jaunty repository replaced by Ubuntu Intrepid repository

Packages of bluefish-unstable are now built for Ubuntu Jaunty instead of Intrepid. You must adjust the entries in /etc/apt/sources.list or update /etc/apt/sources.list.d/debian.wgdd.de_ubuntu.list. You'll receive HTML error code 410 ("resource gone") using the old entries.

Debian/Ubuntu packages of bluefish-unstable for amd64

Debian- and Ubuntu-packages of bluefish-unstable - the development series of bluefish - for the amd64 architecture are now available. Thanks to Olivier Sessink for providing a build-daemon.

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.

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 :)

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.

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.

bluefish-unstable packages ready for testing

I promised it some time ago and now it has been done: Debian packages for the development tree (1.1 series) of Bluefish are ready for Debian users and called bluefish-unstable. The packages can be installed along with the stable version, so you can safely test new features and give us feedback and bug reports.

NOTE

The packages cannot be (re)built on Etch, because debhelper version 5.0.57 or higher is necessary. I will fix this part of debian/rules soon, so it can be (re)built on Etch too.