Handling concurrent update-apt-xapian-index runs
So, update-apt-xapian-index takes a bit of a long time to run.
When you install the package, if the index isn't there then
postinst will rebuild it in background, good.
Now, suppose you have an advanced package manager that after
installing apt-xapian-index, detects that it's installed, detects
that there is no database and runs an update with a nice GUI
feedback. If this happened while the update is running in the
background, the usual thing to do would be to abort the update;
however, the package manager wouldn't be able to know when the
indexing has finished and it can enable the advanced features.
Let's not do the usual thing, then:
lockfd = os.open(XAPIANDBLOCK, os.O_RDWR os.O_CREAT)
lockpyfd = os.fdopen(lockfd)
try:
fcntl.lockf(lockpyfd, fcntl.LOCK_EX fcntl.LOCK_NB)
progress = ServerProgress(progress)
except IOError, e:
if e.errno == errno.EACCES or e.errno == errno.EAGAIN:
progress.notice("Another update is already running: showing its progress.")
childProgress = ClientProgress(progress)
childProgress.loop()
sys.exit(0)
else:
raise
What happens here is that if the upload is in progress, the
second update-apt-xapian-index will not be able to lock a lockfile.
But instead of exiting, it connects to the other indexer via a unix
socket, and shows the progress just as if it were the one doing the
indexing.
So, now, suppose I run
update-apt-xapian-index:
# update-apt-xapian-index
Reading Debtags database: done.
Rebuilding Xapian index... 20%
And suppose I run another one:
# update-apt-xapian-index
Another update is already running: showing its progress.
Rebuilding Xapian index... 20%
And suppose I run yet another one:
# update-apt-xapian-index --batch-mode
notice: Another update is already running: showing its progress.
begin: Rebuilding Xapian index
progress: 19/100
progress: 20/100
And suppose I run yet another one (running with -q shows
nothing, but it will wait until the master indexer has
finished):
# update-apt-xapian-index -q
This way, the advanced package manager (
adept 3
does this) will show a progress indicator and correctly let the
user know when indexing has finished... only, if an update is
already running, the progress indicator will not start at 0%
because the update was already in progress, and the user will
think: "wow, I've been lucky!".
The server side of the socket only uses nonblocking I/O, so
there's no risk of slave indexers causing the master indexer to
hang.
It's been simple to implement, and brillant. It is in
apt-xapian-index 0.15, which I have just uploaded to
sid. Shame it's a bit late for lenny.
When I gave a Revealing Errors talk at Lug Radio Live USA, I had the
misfortune of being up against Robert Love's talk on Android which many
people at the conference wanted to see -- myself included! One person
who showed up to my talk anyway was Allison Randall. She was
apparently entertained enough to invite me to give a short version of
the talk as one of the keynote presentations at OSCON 2008!
In the talk, I covered the ideas behind my Revealing Errors project
and quickly walked through a few examples that showcase what I'm trying
to do. I'm happy with the result: a couple thousand people showed up for
the talk despite the fact that it was at 8:45 AM after the biggest
"party night" of the conference!
For those that missed it for whatever reason, you can watch a video
recording that O'Reilly made and that I've embedded below.
A larger version of the Flash video as well as a QuickTime version is
over on blip.tv and I've created an OGG Theora version for all
my freedom loving readers.
When working on mailservers, I’ve noticed that Yahoo’s mailservers seem to “punish” others by sending code 421 (service not available) for a few minutes for a first report of spam that originated from there, longer for a second report and so on. 
So it is currently possible to use simple library calls in
glib-based code to run something as root, by taking
advantage of the gksu policykit mechanism:
For those of you wondering how is the battle against the 
Update:
New testing version of Gammu was just born. It brings quite a lot of
fixes and changes API a bit (some things will also change in next
testing release).
Full list of changes:
It is nice when you work for a company where you can say:
The next thing was to ensure that the machine had RAID-6 (I have been convinced that that using only RAID-5 verges on professional malpractice). As the machine is rented from a hosting company there was no guarantee that they would follow my clear written instructions involving running RAID-6.
The machine is a HP rack-mounted server with a CCISS RAID controller, so to manage the array the command /usr/sbin/hpacucli is used.
The command hpacucli controller all show reveals that there is a “Smart Array P400 in Slot 1“.
The command hpacucli controller slot=1 show gives the following (amongst a lot of other output):
This morning's newspaper featured a front page article reporting that 
As always, we’re doing lots of interesting and significant things and have more good ideas than we have people to do the work. If you have an Eee PC or are planning to get one, or are otherwise interested in our work, some of which has uses beyond just the Eee, here are some highlights:
Earliest Eee models supported in Lenny
Lenny will release with the atl2 ethernet driver and the non-free madwifi-source now works with the earliest Eee models as well, so our patched version is no longer needed. This means Lenny will work with all of the earliest models of the Eee PC: 701 (2G and 4G surf, 4G, 8G) and 900! All we need now for full support in Lenny is to replace the non-free wireless driver with the free ath5k driver when it is ready.
Free drivers
Nick Kossifidis has 
Coincidentally, I had the opportunity to poke at a machine that actually does deliberately treat Linux differently in its ACPI tables today.