Raphaël Hertzog: How to use multiple upstream tarballs in Debian source packages?
Since the introduction of the 3.0 (quilt) source format, it is now possible to integrate multiple upstream tarballs in Debian source packages. This article will show you how to do the same with your own package shall you need it. It s quite useful to easily integrate supplementary plugins, translations, or documentation that the upstream developers are providing in separate tarballs.
Step by step explanation
We ll take the spamassassin source package as an example. The upstream version is 3.3.1. The main upstream tarball is named as usual (spamassassin_3.3.1.orig.tar.gz) and contains the top directory of our source package. We already have a debian directory because the package is not new.
Upstream provides spamassassin rules in a separate tarball named Mail-SpamAssassin-rules-3.3.1.r901671.tgz. We grab it, rename it to spamassassin_3.3.1.orig-pkgrules.tar.gz and put it next to the main tarball. The pkgrules part is the component name that we choose to identify the tarball, it s also the name of the directory in which it will be extracted inside the source package. For now that directory doesn t exist yet so we must create it.
$ mv Mail-SpamAssassin-rules-3.3.1.r901671.tgz spamassassin_3.3.1.orig-pkgrules.tar.gz $ cd spamassassin-3.3.1 $ mkdir pkgrules $ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gzThis is already enough, the next time that you will build the source package, the supplementary tarball will be automatically integrated in the generated source package.
$ dpkg-buildpackage -S [...] dpkg-source -b spamassassin-3.3.1 dpkg-source: info: using source format 3.0 (quilt)' dpkg-source: info: building spamassassin using existing ./spamassassin_3.3.1.orig-pkgrules.tar.gz ./spamassassin_3.3.1.orig.tar.gz dpkg-source: info: building spamassassin in spamassassin_3.3.1-1.debian.tar.gz dpkg-source: info: building spamassassin in spamassassin_3.3.1-1.dscThe supplementary tarball is now part of the source package but we re not making anything useful out of it. We have to modify debian/rules (or debian/spamassin.install) to install the new files in the binary package. A special case: bundling related software In very rare cases, you might want to create a bundle of several software (small perl modules for example) and you don t have any main tarball, you only have several small tarballs. Rename all the tarballs following the same logic as above and when building the source package you can ask dpkg-source to create an empty (and fake) main archive for you with the option
--create-empty-orig:
$ dpkg-buildpackage -S --source-option=--create-empty-origUse with care as the version number you give to the bundle is what users will see and it s likely unrelated to the version number of each individual software. Common mistakes Forgetting to extract the supplementary tarball If you forget to extract the content of the supplementary tarball in the pkgrules directory, dpkg-source will emit lots of warnings about those files being deleted. In fact, you did not delete them but you only forgot to create them in the first place.
dpkg-source: warning: ignoring deletion of directory pkgrules dpkg-source: warning: ignoring deletion of file pkgrules/20_fake_helo_tests.cf dpkg-source: warning: ignoring deletion of file pkgrules/60_shortcircuit.cf [...]Using a bad version number for the supplementary tarball Sometimes the supplementary tarball has a version of its own that does not match the upstream version. You must still name the file in a way that matches the upstream version of the main tarball otherwise it will not be picked up by dpkg-source and it will generate a new patch in debian/patches/ containing the whole new directory. It s possible to encode the version number of the supplementary tarball in the component name (in our example above we could have picked pkgrules-r901671 as component name) but this means that the name of the associated directory will regularly change and you must adapt your packaging rules to cope with this. However this last trick has the benefit of being able to update the additional tarball without bumping the upstream version. A sourceful upload of a new revision of the package will be accepted by the archive: the main tarball is ignored since it s unchanged but the supplementary tarball is taken since it s a new file for the archive (it has a different filename). Be sure to move away old versions of the additional tarball when you do that if you don t want to upload several versions of the same tarball by mistake! Misextracting the supplementary tarball dpkg-source is very smart when it extracts the supplementary tarball and you should be as well when you manually extract it. If the tarball contains only a single top-level directory, that directory is extracted, renamed to match the component name and moved in the source package directory.
If the tarball contains several top-level files or directories, then the target directory is first created and the content of the archive is directly extracted into that directory. Here are commands to install the files in both cases (we re already in the source package directory):
$ mkdir pkgrules # Archive contains a single top-level directory $ tar -C pkgrules --strip-components=1 -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz # Archive contains many top-level entries $ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz
I started to give
After 
* It is same old life, apart from:
+ Guitar is going good. Learning first thing apart from computer in life
Really, I should have known better than to buy myself a rather 'bleeding-edge' laptop. I suppose I've been lucky with my last couple of laptops and was thinking that pretty much everything works on Linux. Or maybe I'm being picky, because in fact pretty much everything does work on my new Dell Studio.
I bought this laptop mainly because it has a 1920x1080 screen, without being a 17" monster. I had such a monster about four laptops ago (an enormous Sony Vaio weighing in at around 5kg and with a 1hr battery life) and it was an disaster: lots of weird proprietary stuff that never worked, like the external speakers in the docking station. But I loved that screen right up until the day Fraser threw a pair of scissors into it.
With the advent of mass-market 1920x1080 screens I've been waiting for them to arrive in laptops at a reasonable price, and the availability of this screen in a few possible laptops seemed to me to be that point.
It's a Dell Studio 15, and as well as the nice screen, it comes with a new Intel i7 Quad Core CPU, 6G RAM, 640G hard drive and a Blu-ray drive. While there are a few similar models around this one seemed to have the best mix of features-for-weight-and-price, so I bought my first Dell.
I built a USB key with the latest Debian Installer from Squeeze and installed that and everything came up pretty well. I had to use the broadcom-sta driver for the wireless, since the BCM 43224 is not (yet) supported by the free b43 driver (though from looking the mailing list people seem to be working on it, and it looks like it might not be too far away).
Everything seemed good. X came up on the (georgeous) screen. I don't care too much about 3D performance, but it was nice to note that the ATI 5000 series is expected to have full support as soon as it's integrated into the right places - it seems the code is written, and public, it just isn't incorporated into the 'radeon' driver quite yet. The fact that ATI is nowadays a free-software friendly company was one of the reasons for choosing this, in preference to an NVidia-based laptop.
But it seems that it isn't all roses. The fan in the laptop seems permanently on, and not on, in a quiet-just-barely-audible way, but ON, in an 'IN UR LAPTOPZ KOOLIN UR P0RCESSAZ' kind of a way. Too damn noisy for me to concentrate in a quiet room.
I've investigated what's going on, and it seems likely there are some ACPI misunderstandings happening. Some googling and some pecking around in /sys makes me wonder if the laptop expects some kind of configuration choice between favouring Active cooling and Passive cooling, and it's defaulted to the first one. Perhaps you get better benchmarks that way.
Linux ACPI also seems to only half understand it, it has two thermal zones, and one of them always appears with 0 temperature. I can see set points for the fans, but have no control over them. In particular this got me out reading the ACPI 4.0 specification, and it explicitly mentions this choice of favouring 'Active' vs 'Passive' as being done by configuring the passive trip point setting to a higher value than the low & high active trip points.
In the ACPI 4 spec (page 409) it says:
In case anyone else hasn't found these tweaks:
Hey, look, a release! I ve decided to start making tarball releases that make it easier to build forked-daapd, especially on embedded platforms.
The tarballs come with the build system already generated (as should any real release) and they also contain pre-generated source files for the ANTLR3-based parsers used in forked-daapd. The pre-generated files will be used if antlr3 is not available for the build.
I expect that pretty much everybody will end up using the generated files, given the feedback I ve had about ANTLR3. I hope this will also clear the misconception that forked-daapd depends on Java.
I have expanded the installation instructions, making the distinction between building from the git tree and building from the tarballs.
A few more fixes made it to this version since my last post, and Kai also put the final piece to the sort headers by adding sort headers to the song listings.
Tarballs are available at
The most important moment in a Debian release cycle
By default the status is in the mode line only if you are in the Gnus group
buffer. But that's customizable, of course, since this is Emacs!
If you are using
As you may not have noticed, I migrated my site to WordPress some time ago as I did not want to maintain the old piece of crap I wrote myself when I was young ;)
Russel Garlick writes on behalf of the KohaCon10 Organising Committee: