The news are collected on http://wiki.debian.org/DeveloperNews: New archive for unofficial architectures, PTS web interface, Different compression algorithms for debs and more
The news are collected on http://wiki.debian.org/DeveloperNews
Feel free to contribute.
New archive for unofficial architectures
A new host has been setup to host archives of unofficial
architectures. It replaces gnuab.org and currently hosts the armel,
hurd-i386 (unreleased only), kfreebsd-i386 and kfreebsd-amd64
Developers can look at the build logs of their packages and check
PTS web interface
The PTS web interface has gone through some changes:
* added RSS feeds for the “latest news” part of the PTS pages (by
* added hyperlinks to per package svn-buildstat info (by luk and
* added rendering of some new info: DM-Upload-Allowed field,
maintainer being in the LowThresholdNmu wiki page, Homepage
field (by zack)
Different compression algorithms for debs
The ability to compress binary packages with something else than gzip
(for example bzip2) has been in dpkg-dev and dpkg for a long time,
since 1.11 .
The way to add it to a package is to use the “-Z” switch of dpkg-deb.
Or “dh_builddeb — -Z bzip2″ from within debian/rules.
Unfortunately, both lintian and linda incorrectly report that
this should not be used.
Advanced package search prototype in experimental
Enrico Zini created apt-xapian-index, a prototype indexer for a
system-wide Xapian-based index of packages.
The index allows to perform very fast queries on package descriptions
and tags, and any package can install plugins to add extra information
to the index.
Also available is an extensive tutorial on how to use the index.
apt-xapian-index, currently in experimental, will be uploaded to
unstable as soon as some technical feedback is received, especially
with regards to the index structure and the plugin interface.
Changelog entries must describe changes
While reading changelogs (through firstname.lastname@example.org), we
see too often bad changelog entries that describe the problem that they
fix without indicating how they fix it. In a changelog the important
bits are the description of the change and not only what lead you
to do the change. Hopefully some examples will make it clearer:
* Fix lintian error.
* Fix spelling error (maintainance -> maintenance) in description
(detected by lintian).
* Fix package building with new dpkg-shlibdeps.
* Pass LD_LIBRARY_PATH=/usr/lib/mypackage to dpkg-shlibdeps so that
the private libraries are properly found.
When you write changelog entries, have in mind that one must be able to
have a reasonably clear idea of what change you did without being
forced to read a debdiff between both versions.
– Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/