Firstly, I haven't been following debian-devel as closely as in recent months and some things have passed me by. Secondly, I am rather pre-occupied with my own small world of Embedded Debian. One result of this is that I wasn't really paying attention to arguments over the source package format and took longer than I expected to respond to a request to take a look at tslib - a touchscreen library for embedded devices. When I did start work on it I managed to upset Joey Hess by implementing dpatch support which he had recently decried as unhelpful. I also added some extra fuel by getting myself in a two-and-eight over svn-buildpackage and it's broken bias towards native packages.
I happen to disagree with the idea that maintainers should alter upstream files directly, merely relying on the .diff.gz or some weird $RCS runes. Instead, I seek to ensure that the .diff.gz contains no changes outside the debian/ directory. I'm not happy keeping the entire upstream source in yet another RCS (for any reason) and would much rather make updates to my Debian packages by simply copying the debian/ contents into an unpacked pristine upstream source (preferably via uscan). I find it really useful to simply check out the latest CVS/SVN/$RCS, dump debian/ into place and call 'debuild' when testing various upstream development issues. Maybe this is because I have relatively few Debian packages that need debian/patches/* and certainly few that need more than a couple of patch files. It certainly has a lot to do with my embedded work where I need to make changes to the contents of debian/ to make an Emdebian package whilst retaining the same upstream code as is used in existing embedded projects like Open Embedded and Familiar. I don't want to be chasing changes through the upstream source - I want all the changes in a single place so that I can create Emdebian patches against the Debian source. (I'd rather not have patches in the Debian source at all but this is only realistic for either my own packages or those released as part of GPE for various embedded-native compatibility reasons.) I certainly do not want any Debian $RCS to be lumbered with yet another set of upstream sources that will always be out of date compared to the real upstream sources.
I am also a great fan of CDBS - much to the horror of some in Debian - primarily for one very simple reason, it cross builds so easily. Considering my workload, it should not be a surprise that the ability to support cross building without requiring any changes to the Debian package is incredibly persuasive when selecting a build system for a package of my own. debhelper really is woeful at cross building - each package needs customised cross building support painstakingly devised and tested, making script-based mass bug filing impossible. CDBS shows that with a little wrapping, debhelper can support cross building in a clean and completely non-intrusive manner.
This means I can concentrate on those changes that are actually important - the changes that provide the benefits of cross-building and justify the effort of actually cross building the entire dependency chain: the ability to fully control Debian-specifics like "Essential: yes" and to disable, modify or adapt components of any package such that the installed system has a fraction of the dependencies of the Debian version of precisely the same package. TDeb support is good too but that can be implemented against any build, it doesn't need to be a cross build.
Sadly, the end result of all this for tslib is that it will be removed from collab-maint very soon, Joey does not wish to be associated with the new version because although it includes some features which he is happy to see implemented, my use of dpatch and the hacks I had to devise to workaround svn-buildpackage do not fit with his workload patterns. Once tslib is removed from collab-maint, these hacks become redundant and I can use my normal packaging methods. Equally, his methods (in particular the lack of debian/patches/*) do not fit with my workload patterns and although I do not have as many packages as Joey, I have enough (when the 200 Emdebian source packages are also considered) to make the issue into a blocker. The new version of tslib uses the upstream SONAME and adds a -dbg package so it will spend some time in NEW. I am also likely to migrate it to CDBS once removed from collab-maint.
I suspect these issues will be revisited during discussions at Fosdem 2008 where I'll be presenting two talks - one in the Debian developer room and one in the Embedded developer room. Feel free to harangue me if you feel strongly that there is a sane way of cross building that does a better job than CDBS.

See #462456 and particularly #462007.
I have come across (what is to me) a non-obvious problem in the use of -dbg packages using dh_strip --dbg-package=libfoo-dbg. If a .install file exists for the -dbg package, dh_install copies the unstripped object into the -dbg build directory. When dh_strip --dbg-package=libfoo-dbg is then called, it silently omits the file from the call to objcopy --only-keep-debug (to prevent an objcopy error), resulting in an unstripped object file being retained in the -dbg package that has a complete (and fully functional) copy of the library embedded inside - as shown by the presence of a full Dynamic Section under objdump -p. Without the .install file, dh_strip takes care of copying the debug symbols into place directly - no .install file is actually needed.
The solution is to simply remove the debian/libfoo-dbg.install file. (Doh!)
However, the error goes undetected because dh_strip outputs no warnings, lintian does not check for it (yet) and there is no particular sign of a problem except the larger size of the files in the -dbg package. With a new library package (or the addition of a new -dbg package to an existing library source), this could easily be missed because all debugging operations using the -dbg package are unaffected (sponsors take note).

With the .install file present:

$ ls -l /usr/lib/debug/usr/lib/libqof*.so.*.*

-rw-r--r-- 1 root root  155585 2007-12-19 21:49 /usr/lib/debug/usr/lib/libqof-backend-qsf.so.0.0.7

-rw-r--r-- 1 root root   78554 2007-12-19 21:49 /usr/lib/debug/usr/lib/libqof-backend-sqlite.so.0.0.2

-rw-r--r-- 1 root root 1029686 2007-12-19 21:49 /usr/lib/debug/usr/lib/libqof.so.1.0.9

With the .install file removed:

$ debc | tail

-rw-r--r-- root/root    103217 2008-01-24 22:53 ./usr/lib/debug/usr/lib/libqof-backend-qsf.so.0.0.7

-rw-r--r-- root/root     47930 2008-01-24 22:53 ./usr/lib/debug/usr/lib/libqof-backend-sqlite.so.0.0.2

-rw-r--r-- root/root    728646 2008-01-24 22:53 ./usr/lib/debug/usr/lib/libqof.so.1.0.9

(results have been sorted to keep the same sequence)

The error is possible in any debhelper package, despite being found in a CDBS package. Not sure what made me think that a libfoo-dbg.install file was necessary but there you go.

Sadly, I can't seem to get things right re: Fosdem. I got the dates wrong for Fosdem and had to pay extra to change the bookings. Last year I got the flight wrong and had to pay extra to fly from Gatwick instead of Heathrow (and when I got to Brussels there was some bomb alert that had closed the airport, just to make things worse).
I will now be in Fosdem, on time but poorer than necessary.
I can't get to London in time to take the same Eurostar as many others and there isn't time get back home with the Sunday evening train so I'm staying until Monday morning.
Things are so much easier when public transport isn't involved.
Bah - there's always next year to get things right.

Working!

I've decided to replace the previous post rather than leave it in place when there is a solution available.

Fixing the problem

I've been considering a new laptop for weeks - mainly to get more RAM, more space but without adding to the actual size of the machine (or weight). I know, I should have taken more time over the selection, I should have found out more about the hardware, etc.etc.
I've ended up with an HP Pavilion dv6000 (dv6615ea) for the 2Gb RAM, 15inch screen, 250Gb hard drive to replace my ageing iBook 12inch with 128Mb RAM and 30Gb hard drive - all for barely an inch extra depth and very similar weight (and it was cheaper than the original price of the iBook). I thought I'd made a good choice. Yes, it was "NVidia Graphics" according to the sticker and yes, I could have spent more time (and money) finding a pre-installed lappy but I was hasty. (Much the same way as you should never go food shopping whilst hungry). I've managed with NVidia graphics before without using the horrid proprietary rubbish and I was prepared to put up with less-than-perfect graphics (I never use 3D anyway) because the free driver is at least stable with the graphics that I actually need.

Updated

The ethernet card is not recognised by the Debian Etch installer - after a comment placed on this blog after my original post, I tried the Lenny installer for amd64 with signficant success. Selecting the vesa driver for the graphics provided a usable X setup (1024x768). I've still spent a lot more time on this than it should really have required but I do now have a genuine amd64 Debian installation with GNOME. The only thing not working is wireless (oh and sound). The wireless appears to be a bcm43xx issue - the driver appears to let the card work (the orange light turns blue) and the device is created but scanning fails.
I'm probably still going to have to leave this new lappy behind and take my existing iBook to Fosdem in a few weeks, but I'm now happier with HP in general.
I'll try to post a longer review somewhere soon.
So, thanks for the tip, Julian!