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.
Of course, trying to block the Brazilian Internet Surveillance Bill is something we are really focused on doing. But as more people with political skills join us on convincing the Deputies this bill is just plain wrong, the rest of us, geek guys, are investigating Tor deployment.
I d have to study the bill deeper than I have already, and probably ask some lawyer about it, but I think that the bill effectively makes unlawful to deploy Tor in Brazil as an end router. Via article 22 of the bill, providing an end-point Tor router can be considered providing access to a worldwide computer network , thus would require to keep three years of logs, what would render pointless having a Tor router in the first place.
What can save an end-point Tor router is the wording of this very article. It states that just commercial or public sector providers are entangled by it. What if I make a free (as in free beer) end-point Tor router available? It is not public sector , since it s not tied to the government It s not commercial, since I am not selling access to it. But then, someone can argue that it s commercial activity with zero-price Brazilian law is just so confuse
Anyway if we can get it straight with the lawyers, I think we ll watch a proliferation of end-point Tor routers in Brazil. This would assure that, even if this bill passes, it will not be easy for the government to peek on the citizens traffic. Geeks always having to fix what politicians break so easily
One of the things I've wanted to do since I discovered that 
A few notes/reactions from the talks I attended today from the very, very
back of the room. (AKA the skivvies and/or backyard track.)
(
It's more or less four months since I proposed to
Otavio has updated kernel-wedge in SVN to 2.6.26, so I updated ARM and MIPS
today. The udebs built after minor modifications and I can also build
installer images after having fixed some bugs in the build process. I
tested a 2.6.26 based image on the QNAP TS-409 (armel) as well as in QEMU
(mipsel).
2.6.26 will bring major improvements on ARM. Orion support is much better
and our 2.6.26 has a number of patches from Marvell that help with
performance on Orion. Our 2.6.26 also has Riku Voipio's LED driver for
Thecus N2100 which has been accepted for the 2.6.27 mainline kernel.
I haven't actually uploaded the udebs yet because I'm waiting for the
go-ahead as well as for the new version of the 2.6.26 kernel package to
build. But at least we're getting closer to having 2.6.26 as the kernel
for lenny.
in seven hours DebConf8 will officially begin, you can participate by watching the live video streams as described on the 
Debcamp is nice. Talking to people in person rather than having to do
IRC to get anything done is a breeze, really.
One thing I haven't been particularly happy about is the fact that
there aren't any good statistics on what the build capacity of an
architecture is; i.e., you don't know you're low on build capacity until
you suddenly start backlogging and it's too late. So, since J rg
Jaspert, Mark Hymers, and Steve Gran were there, I asked them whether
it'd be possible to add some data to the projectb database about
installing a binary. One additional column with a default now()
option later, and we now have interesting data that I can make
statistics of. Of course, since that column was only added four days
ago, during one of which the link to ftp-master.debian.org was down
(meaning, no uploads), there's not much data there yet; but I can start
making some graphs now.
Of course, the hard part is trying to figure out how to present the
data in a manner that one can actually get useful conclusions from,
which is harder than it seems. Anyhow, I'm trying. For now, on 
First complete day after a full day travelling and I'm just about over the jet lag. Progress so far:
One of our most popular products at 
Imagine you have a device, such as a linux phone, that allows login via ssh, e.g. when on a wireless network. You don t want to set a password with the (limited) phone UI. On the other hand, you don t want to allow passwordless root logins into your phone. But you do want the ability to login via ssh, after all that s why you have bought a linux smartphone. This led me to the idea of a pam module and corresponding UI piece that asks the currently logged in user: Hey, someone tries to login. Is that ok or not? This might also be useful for guest accounts on regular laptops. For more on that, see