Another week has been spent in a repetition course in the military. Readers of my blog will know that this means playing poker (I lost about CHF 7 this week — we just play for fun at CHF 5 for 50 chips) and watching movies. Tron and Kill Bill Vol. 1 from my collection, and the extremely funny Adams bler which I didn't know before. The story centers around a neo-nazi serving some time in some kind of rehab in a church where, it is soon discovered, the priest in charge of the whole thing is not that much in charge, even of himself. I'm told that I also should watch I Kina spiser de hunde by the Danish Anders Thomas Jensen (writer and director of Adams bler, writer of In China they eat dogs.) Also recently watched Casino Royale (the recent Bond movie. I haven't seen the 1967 one yet.) and The Gold Rush: the 1942 version with added spoken narrative and music by Chaplin. The DVD does contain the original 1925 silent movie, too, where especially the ending is a bit different. And finally lots of episodes of , ! (Nu, pogodi!), which was the Soviet equivalent to Tom and Jerry (not a clone, it is entirely different.) I can highly recommend this to everybody who likes cartoons.

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

I've been extremely busy with labwork lately, trying to get a second paper ready for submission in the coming months. It's taken an obvious toll on my free software work, but that's life I guess. The upside is that the other night I realized why a year and half's worth of experiments kept turning up with negative results that seemed to contradict our other results. It turns out that this experiment was conceptually flawed, and even though I wasted a year and a half on this I did learn something even from those negative results that should go in to the final paper. I'm actually relieved, because even though I don't have all the data yet I can really see how the paper will end up, so I can start writing soon. Oftentimes knowing why something is wrong so you can fix it is even more important than being right.

I set up an ikiwiki to help organize my lab data a few weeks ago, and it's been a huge win. Joey really did a fantastic job on the program and I can't imagine using a wiki that doesn't share a very similar design for any of my personal stuff. I showed my boss some of my data using it and now he wants me to set up a wiki for the lab. He actually wants me to show off my wiki to give my lab members a feel for the idea. Since ikiwiki doesn't seem to be appropriate for my lab members, I'm going to have to look in to the giant list of wikis to figure out the exact right one for my lab's requirements. This is something I never expected to be doing in grad school.

Because there's no way my brain can go without doing a little bit of programming, I finally sat down and wrote myself a small shell script that lets me grep through pdf's, which is something I couldn't find googling around. If you have a lot of pdf's like I do and don't something like beagle or tracker churning away in the background constantly just so you can search them, this is very helpful. It's obviously very crude, but it gets the job done nicely. It relies on the pdftotext program; hopefully it'll be of use to someone.

I've been digging in to my copy of UNIX Power Tools lately, trying to pick up new UNIX and vi arcana, which is something I haven't made a real serious effort to do in a long time. It's been surprisingly fun to try and replace old habits with things that I know are better but don't use. A good example is that I usually will fire off a new subshell in vim when I should really just suspend vim and use my original shell to save time. Re-examining the basics of how I use the system has been a lot of fun, and has made me a lot more comfortable with the simple day to day tasks.

Because of some modifications at my Real Life Orkplace, I decided to reduce other duties to get a better chance to deal with my new duties. So i requested help for my four packages in the Distribution

RFH: jove

My first package. A small, but powerful Emacs-relative, with all those uneeded things stripped which makes emacs fat. Maybe these days especially useful for small memory devices, as it gives you emacs-likeness for the price of nvi or ae. I have no idea how well it works in a real utf-8-environment.

RFH: milter-greylist

A greylist-milter which makes running a mailserver somehow possible for me. it keeps away about 2/3 of spam, which leaves me with only 400spams/day. I already have two contacts who want to help with that.

RFH: nn

No news is good news, but nn is better. This is a USENET reader, for those people who grow up with Webforums and Blogs: This could be still the most effective way to celebrate flamefests, gather information or communicate with people sharing same interests. And nn has in my opinion the best UI for it, and makes it easy and fast to find interesting articles and skip others. Well, Upstream Development has ceased to exist around 1994. I think if no one takes over, this package will become finally useless when IPv6 gets widely used (right after the release of 'Duke Nukem Forever') and it also doesn't deal well with non iso-8859-1-charsets. So best for this package would be to rewrite it from scratch (my dream: message/mime-handling/threading from mutt, scoring from slrn, and UI from nn) because the User Interface is much better than those of all still alive Newsreaders i tried.

RFA: synergy

This is my most popular package, which makes it possible to share one mouse and keyboard over many computers and displays. (It is available for UNIX/Linux, Windows and MacOS) This is a very very useful software, and i use it permanently. Sadly the Upstream Development mostly ceased to exist, and so i put this to RFA (instead of RFH) because many Debian-Users use it according to popcon. This software should be taken over by someone who is able to help Upstream. There is a RC-Bug, which caused the package be pulled from testing.

Interesting is that while filing those RFH/RFA all the same day, i only got responses for the packages which scores lowest in popcon, (24 for milter-greylist, 1196 for synergy).

Back in February, I worked on packages providing badly encoded changelog files. With the removal of gmanedit from testing and unstable (Gnome 1.x removal process) and the ack that perl wrongly changelog encoding is mostly upstream's changelog (which will be hopefully fixed), I think its OK, now, to announce that this lenny release goal is achieved. Thanks to Bas Zoetekouw who did the mass bug filing which helped a lot tracking this down. We could now imagine tracking down badly encoded debian/copyright files... PS: above, "badly" means "using national encoding"...which is generally ISO-stoneage^W8859-1.

One of the funniest things I've seen in a long time:

Electronic Road Signs and Me

I won’t be visiting the US in the forseeable future. For some time I have been concerned about the malfunctioning legal process and other related issues that arose from the so-called “War On Terror“. But the most recent news is that the TSA may just copy all the contents of your laptop or even steal it [1]. Law enforcement agents can search property if they see evidence of a crime in progress or if they have a search warrant. They can seize property as evidence in a trial, but if the property in question is not illegal then it will be returned afterwards. The TSA take property from travellers without any reason for doing so and do not return it. This is not law enforcement, it is banditry. It’s bad enough catching a late train while carrying a laptop and risking a junkie trying to steal it. When bandits have police protection (as the TSA do) then it becomes an unacceptable risk. The TSA have recently apologised for making people remove iPods and other devices from their luggage [2]. Strangely this has been interpreted by some people to mean that the TSA won’t be stealing data and hardware from travellers. I’m sure that if the TSA was going to stop searching laptop hard drives and confiscating laptops then they would have announced it. From now on I will avoid entering US territory (even for connecting flights), except in the unlikely event that someone pays me an unreasonably large amount of money such that I am prepared to travel without electronic gear. I know that some people in the US won’t like this (some people flip out when anything resembling a Boycott is mentioned). I am not Boycotting the US, merely avoiding bandits. If the fear of bandits hurts your business then you need to get a law enforcement system that can deal with the problem. On a related note, check out the TSA Gangstaz [3] video, funny.

• [1] http://www.washingtonpost.com/wp-dyn/content/article/2008/02/06/AR2008020604763.html


• [2] http://www.boingboing.net/2008/02/06/tsa-apologizes-to-bl.html


• [3] http://www.youtube.com/watch?v=z7AWw7t5zj0

Share This

Ubuntu package translation storage in Launchpad used to annoy me, primarily because the synchronization workflow between Launchpad and upstream was unclear. My questions have been partly answered on Launchpad Answers. Others working with translations in Launchpad might be interested in this information. Here's another tip for translation coordinators. I used to worry about translation pollution in Launchpad, until I found that you can clean up efficiently by sorting packages by the number of translations changed locally in Launchpad (to try it out, you can go here and click twice on the "Changed" column). Click on the number of changed translations in a given package and you will be presented with a list of the changed translations, which you can reset to upstream versions one by one by choosing "packaged" versions. It seems to be a good idea to perform such a cleanup once in a while, to keep the amount of cruft to a minimum.

So early this evening I looked for more bugs to fix in the Debian packages I use the most, instead of doing security work. (Because I'm waiting for buildds..) Anyway I figured I'd take a peak at the mutt-patched package - since I have my own patched backport for Etch these days. I'd like to get into the habit of making sure it stays current, but honestly I'll probably forget in a few months. One bug #464189 caught my eye. It is asking for a couple of patches, neither of which I'd heard of. One of them is obviously extremely useful though - it is designed to change the sidebar in such a way that it only displays mailboxes with unread messages in them. I hunted high and low for the patch and had to admit defeat. So I wrote my own, and now my backported package contains a suitable patch. In other news I made a new release of the chronicle blog compiler, which I'm now using in a few more places. All in all it has been a busy day and I got a fair amount of hacking done! The other thing, that I can speak about, which I did today was package the Perl Lingua::Identify module so that my spam filtering service can offer users the opportunity to reject mails written in, say, Russian, or Italian. I'm tempted to give them up to Sarah for adoption, as she was making noises at the weekend about joining Debian (then again so was Jacob Appelbaum). The only issue is that I think she should use the Debian Perl group to get involved, and I've not seen any sign of activity there from her since she first mentioned joining it. Sarah: Consider this a reminder! Update: Feel free to nominate any *crash* bugs you'd like me to attempt to fix. Providing they're not in video or audio playback code! Could be a fun challenge.. ObQuote: Cruel Intentions.

I finished reading the electronic advance reader’s copy last night. Overall, I’m glad I read it, though it was quite infuriating. The book is set about a decade in the future. In the book’s world, anthropogenic climate change and global warming turned out to be a hoax; instead, a global cooling (caused by solar variation) was beginning. At the same time, the bird flu (H5N1) became a major pandemic. The United States was governed by the democrats and “the bitch” (a thinly disguised demonisation of a certain democrat presidential candidate), who handled everything wrong. The book is a fictional autobiography (or a series of blog posts) by a US army officer who became famous during those turbulent times, first commanding a company finding its own way back home after being abandoned in the Middle East (the later stuff I won’t describe to avoid spoiling the book). The Last Centurions is a television propaganda show featuring his unit in action, intended to counterspin anti-military news reports. Several chapters early in the book are pure political ranting by the narrator: how anthropogenic climate change is false, how socialized medicine is bad (and causes lots of unnecessary deaths during a pandemic), how republicans are good and democrats are evil et cetera et cetera et cetera. (Then again, it’s a Ringo book, political ranting is a given.) Given my political persuasion, it was not easy to read: I kept yelling, “where are your footnotes!” I actually tried to verify some of the claims the narrator makes, and found nothing persuasive. Still… in the end, it all turned out to be justified. It explains the character, and it explains the world. Perhaps it should be a bit trimmed during editing (remember, I read the author’s submission draft which has not been through the usual editing and copyediting cycles), but a lot of it is necessary for the story. The premise that anthropogenic global warming is a false theory made it very hard for me to suspend disbelief. However, given that premise (and the premise of a totally incompetent government in the USA), the story is compelling and interesting. There’s a quite a bit of military action as we have become to expect from Ringo. The beginning grabbed me, – apart from the couple of chapters of exposition – held my attention tightly to the end, and left me shell-shocked. I especially liked the wife’s edits. I’m sorry that we didn’t get to see their courtship. I don’t know if I’ll ever want to re-read the book, but I’m still rating it at 5/5. The book is now available as an e-ARC, and will be released as a regular book in August. There is a companion site at www.thelastcenturion.com.

I think that Matt Hartley is spot on on his Top 10 Linux Desktop Hurdles. Commented:

1. Regression testing is hard. Assuring that hardware that worked will still work in the next version of the distribution is where many Linux distributions fall down. At least I think Debian here does better than some others.
2. Mobile devices. I've written about this already some months ago. I want to just plug in my smartphone and sync it with my calendar application. I don't think this is too much to ask.
3. Software compatibility. I don't do video editing and I'm comfortable with the Gimp, but I witness people having difficulties with OpenOffice.org all day. Mostly, it's because either they were MS Office power users and stuff like form letters are different between the packages, or it is because the state issues silly form/macro based MS Office documents.
4. Wireless. Hmm. I haven't had real problems with Wireless in quite some time. But then, I know that I need to watch what kind of hardware I buy, so YMMV.
5. Hardware compatibility lists. Debian doesn't have one, so that's apparently a good starting point ;-)
6. Compiling drivers. I don't understand this complaint. The user should never even come to the point where he needs to compile a driver. But I think here Debian with module-assistant is quite good.
7. The Patent Trap a.k.a. I Want To Watch DVDs. This is a serious issue, and will probably not be going away unless some heavy duty political stuff is happening. Organisations like PubPat and the new End Software Patents initiative will help. In my opinion, though, these are not taking it far enough. Patents are monopolies granted by the state — in all other areas (post, railways, telecommunications), it has been agreed that monopolies are bad, so why not just abolish the broken idea of patents, too?
8. Off the Shelf Software. Hmm. My clientele is not the lone Linux user at home but the business user who has an IT support dept, so I don't see this issue for me.

Issues #9 and #10 is just “the community sucks” in nicer words. He's not wrong as such, but I think Matt's view is pessimistic on these.

Sidney, Adelaide, Atlanta, Bangkok, Brisbane, Canberra, Chicago, Christchurch, Copenhagen, Dublin, Manila, Melbourne, Montreal, Odense, Ottawa, Perth, Phoenix, San Francisco, Suva, Tel Aviv, Toronto and Vancouver all turning off their lights for an hour in the name of fighting global warming.

NASA to take orbital photos of Earth Hour cities on March 29.

watch the video digg it!

---

Debian includes a package called “vrms - virtual Richard M. Stallman” which report the non-free packages you have installed on your Debian system. Running vrms on my workstations gives the following output:

makholm@makholm:~$ vrms
              Non-free packages installed on makholm
gcc-4.2-doc               documentation for the GNU compilers (gcc, gobjc, g++)
gcc-doc-base              several GNU manual pages
sun-java6-bin             Sun Java(TM) Runtime Environment (JRE) 6 (architecture
sun-java6-jre             Sun Java(TM) Runtime Environment (JRE) 6 (architecture
sun-java6-plugin          The Java(TM) Plug-in, Java SE 6
xsnow                     Brings Christmas to your desktop
  6 non-free packages, 0.4% of 1487 installed packages.
makholm@makholm:~$

Sun Java is a know evil and somebody really ought to reimplement xsnow, but having the virtual RMS declare GNU documentation non-free is a nice touch. Yeah, I know about the problems with GFDL. Update: Known problem: #221807, #297506, and #364971

dpkg-cross updates
uploaded to Debian unstable

   * General support for querying endianness of an architecture.

   * Update standards version (no changes)

   * Add Cvs-CVS field to debian/control

   * Reinstate detect_arch for improved build test checks in emdebian-

     tools

   * get_endianness: new function for Emdebian TDeb support

This provides support for architecture-dependent TDebs in Emdebian as well as adding detection of armel.

emdebian-tools 0.8.3
Uploaded to Emdebian

   * Interim Emdebian release.

   * emsecondstage: ensure cdebconf environment is setup before

     configuring packages

   * emdebian.gpe: Add extra packages needed to allow the gpe package set

     to boot.

   * Emdebian::Tools, (create_patches) : skip generated files.

     [*.debhelper, *.substvars, files]

   * em_installtdeb: support special modes via debian/xcontrol

   * Support unpack method in basic emsandbox rootfs

   * embootstrap: continue after some errors

   * Support unpack method in gtk emsandbox rootfs

   * Simplify basic empdebuild chroot and copy in hostname files

   * empbuilderlib: add support for creating skeleton versions of

     /etc/group and /etc/passwd.

   * empbuilderlib: add an approximate time set func for use when no

     network is available.

   * emsecondstage: configure cdebconf before others so that the database

     is ready

   * embootstrap: use the new support in empbuilderlib for group, passwd

     and date

   * Add --arch support to em_installtdeb

   * Depend on new support in libdebian-dpkgcross-perl

   * empdebuild: force the -S argument to apt-cross to prevent

     intermittent failures

   * empbuilderlib: parse the .list contents from dpkg

   * embootstrap: ensure buildplace is clean before starting a fresh

     debootstrap

   * emdebuild: use dpkg-cross support for detect arch to distinguish

     between arm and armel binaries

   * Emdebian::Tools. add parse_xcontrol function for easy queries of

     debian/xcontrol

   * pbuilder/emdebian.crossd gpe gtk : Tidy up the scripts with routine

     calls to the empbuilderlib library

   * pbuilder/empbuilderlib: Add some common routines to help make the

     rootfs bootable

   * pbuilder/emsecondstage: bring into line with other changes in the

   * empbuilderlib.3 : Add a manpage for the expanded set of common

     functions in empbuilderlib

   * Suggest file-roller for inspection of rootfs tarballs

   * emdebhelper.mk: sync with recent changes in CDBS for debhelper

     support

Reasoning
OK, so why upload emdebian-tools to Emdebian when it depends on the update to dpkg-cross in Debian?
Well, emdebian-tools is becoming a bit of a behemoth. I mean a package that has only existed for 12months and has had over 30 releases, increasing in size from 30kb to over 500kb (without counting dependencies) and which encompasses a gammut of scripts with different roles is just begging for a functional package split.
Package splits take time - not just the time in NEW but all the testing to ensure that each split can be installed separately without falling over "Unable to find foo in @INC" etc.
At the same time, emdebian-tools is both rapidly developing and becoming remarkably stable (which gives some indication of just how diverse it has become).
So I'm heading for a 1.0.0 release before Lenny and to achieve that, I want to split it:

1. emdebian-tools - umbrella package consisting of the core build scripts (perl) - these are becoming quite stable - that depends on all the others.


2. emdebian-archive-keyring - tiny package that just implements SecureApt for the Emdebian repository.


3. emdebian-rootfs - the rapidly developing (shell and perl based) root filesystem management scripts, based on debootstrap and pbuilder.


4. libemdebian-tools-perl - a standard perl module of common functions for the other packages.

This allows people to use the toolchains with the smallest package, prepare root filesystems from prebuilt binary packages with just three of the four and only those who build packages will need all four.
So the plan, overall, is to keep updating emdebian-tools in Emdebian unstable during the time that emdebian-tools 0.9.0 goes through NEW in Debian. Then, when 0.9.x is in testing and any issues from the split are resolved, 1.0.0 can be uploaded to Debian.

Package split issues in general
Something that bugs me with package splits is this stable vs development issue within the same source. I think it would be sensible to only upload emdebian-tools (the stable bit) if it changes but to upload emdebian-rootfs as often as necessary whilst still building from the same source.
This issue will also bite when Emdebian deploys other functional package splits and seeks to improve apt itself to handle many, many more binary packages.
It's also a similar idea to allowing translators to upload TDebs separately from normal package updates.
Why should I have to split the source in $RCS in order to upload package splits separately? Other upstream teams won't do that so Debian needs a solution.
Why should users have to download emdebian-tools 1.0.1 which is absolutely identical to 1.0.0 just because emdebian-rootfs needed lots of updates in 1.0.1. (Remember, emdebian-tools will depend on emdebian-rootfs so when emdebian-rootfs is updated, all users of emdebian-rootfs and all users of emdebian-tools will get the update. Yet I don't see why emdebian-tools itself needs to be touched.)
It is plain daft.
I've seen similar issues in other environments where, for various very good reasons, users need to limit the bandwidth and duration of apt downloads. For Emdebian, we also need to limit the total amount of data downloaded by apt-get upgrade simply because free space on the device can be severely restricted - my target device will have about 7Mb free space and that is regarded as "under-utilised". Downloading an entire package just to update /usr/share/foo/changelog.gz in such circumstances is just plain stupid. I know we can do better than that.
Apt needs to become much more intelligent and have a way of only downloading the changes in packages instead of the entire .deb - something along the lines of an rsync method. To get that working, the actual package names need to be munged so that rsync can compare foo_1.2.3-1_all.deb against foo_1.2.3-2_all.deb by having both symlinked as foo_current_all.deb. (dpkg-name can restore the original name if needed.)
Such a method must be possible and would have enormous benefits for packages like OOo where each upload can't be changing 100% of the code each time, yet we all have to download Mb after Mb of content that is identical to what dpkg is about to replace.
Am I just ranting or does this strike a chord on the lazyweb in general?
The slowest part of many desktop experiences of Debian could well be the time taken to download updates - not everyone has multi Mb broadband.

I have been maintaining several minor sites hosted at Dreamhost for about a year. And since over one month ago, my personal website is with them as well. And I must say, I am very pleased with them. No, not (well, not only) because they run Debian on their servers, nor because they are probably the cheapest game in town (I paid something like US$200 for a basically unlimited package , for three years), but because of their degree of responsability and personal service.
Responsability? Aren't they well-known for their network outages? Why, yes, of course - Today's example is paramount: Somebody edited the wrong firewall entry, and all of Dreamhost became unavailable. In general terms, Dreamhost has a great blog-like structured page where they inform customers of every network or server problem they have - No, you don't have to dig in to understand why your site is down: They bring it up to you. Upfront. And in a familiar, very non-formal style.
Whenever I have submitted an issue to their request tracker, I get prompt reply. Does it always solve the situation? no, by far. I'm often told to, basically, go screw myself if I really need such feature... But they are straightforward with that, they are good, nice BOFHs (if such thing ever existed), and they don't present you with corporate-minded studies backing up their solution. Yes, I know that in their servers, it's plainly their way or the highway. But hey, that's what I paid for, right?
That is what wins my heart. Yes, Dreamhost is no good for many, many tasks - including, for example, anything that requires a real RDBMS (forgodssake, they offer MySQL but not PostgreSQL, damnit! WTF!?), nor any legendary five-nines reliability. But they are great for the vast majority of the Internet sites' needs. They even exceed what a simple person like me would ever dream of.
So, my hat off to you guys. Again.
(No, and I'm not getting paid or discounted on services because of this blog post. Although maybe I should! ;-) )

$ notAptable --help
notAptable [--version] [--help] [-s/var/lib/dpkg/status] [-aptf/path/to/aptavail/equiv/file] [-aptx'apt-cache dumpavail'] [-ipackagename]
List packages which are installed on the system but are not known by apt.
Options:
-s Path to file to use when grepping for installed packages
-aptf Path to file to use when grepping for the apt-able packages
-aptx Same as above but instead of being a file the specified command is executed
-i Exclude a package that would otherwise be listed
When not overriden by an option the default files/data is up to grep-dctrl's defaults
This script is said to report packages that were removed from the archive
(except those listed in /home/raphael/.listNotAptable.ignore)

Copyright 2008 by Raphael Geissert <atomo64@gmail.com>

---

With this simple script I wrote I got rid of about 45 packages (libraries, programs, etc, etc) what are no longer in the archive.
My question is: on what package should this script be shipped? debian-goodies? devscripts?

Hope somebody else finds this script useful and puts it in their weekly cronjob as I did :)
Get it from http://alioth.debian.org/~atomo64-guest/notAptable until it is shipped in some package.