As Christian said in a very nice summary of the issue, this is the day the DADVSI law (which is a transposition of the EUCD, the European DMCA) will be examined by French parliament. I would really like to share Christian's optimism. So far, the EUCD.INFO initiative succeeded in bringing the issue to the public (120k signatures, mostly from French residents) and to several MP. Good news are that a lot of amendments has been submitted to mitigate effects of the DADVSI law. Bad news is that we also had terrible press cover: we had articles in most national newspapers and TV, but a lot of them are completely missing the point and are comparing us to champions of piracy against copyright. Even worse, Christian Vanneste (conservative MP responsible of the law) keeps spreading lies. Today, members of the EUCD.INFO initiative went to the parliament to talk to MP and to show their concerns. Some friends and I went too even if we were just there to watch the debate. I'm quite disappointed to see that left wing was totally absent (like less than 10 MP out of 160!). Right wing was more represented but MP supporting our amendments are a minority group. Debate starts again at 21 local time. We will be there and I hope I'm wrong, but I really fear we loose more than we gain.

So the final implementation detail in the embargoing scheme is providing a tool to move stuff from the embargoed and unembargoed queues into the archive. The existing tool the security team use is called “amber” (after the inimitable Amber Benson). amber’s pretty simple: it takes a DSA number, and the .changes files you’re looking at; then asks for confirmation, accepts the packages into the archive, regenerates Packages and Release files, fills out a template advisory with details from the deb and mails that off, and uploads the files to ftp-master for inclusion in the next stable release. There are a few problems with that. One is it doesn’t allow for rejections. Another is it doesn’t provide the security team with the opportunity to edit advisories while the packages are being prepared. Another issue is that the entire program has to run under sudo with full archive priveleges. Enter “dak dsa” aka “newamber”. The new tool aims to do more or less the same thing, but with a little more style. First, it provides a small interactive interface, so that processing an advisory now looks like:

$ newamber DTSA-25-1 smb4k_*.changes
Create new advisory DTSA-25-1? y
Advisory: DTSA-25-1
Changes:
 smb4k_0.6.4-0.0etch1_alpha.changes
 smb4k_0.6.4-0.0etch1_hppa.changes
 smb4k_0.6.4-0.0etch1_i386.changes
 smb4k_0.6.4-0.0etch1_m68k.changes
 smb4k_0.6.4-0.0etch1_mips.changes
 smb4k_0.6.4-0.0etch1_mipsel.changes
 smb4k_0.6.4-0.0etch1_s390.changes
 smb4k_0.6.4-0.0etch1_sparc.changes
Packages:
 smb4k 0.6.4-0.0etch1 (alpha, hppa, i386, m68k, mips, mipsel, s390, source, sparc)
Approve, [E]dit advisory, Show advisory, Reject, Quit? 

Choosing edit will grab a copy of the template and run vi – the template will only be filled out when you approve the upload though, since the values might change before then. Accept will do more or less what old amber did; though instead of mailing the filled in advisory draft it’ll just leave it in the filesystem instead. Of course, running vi (well, $EDITOR) generally means you can get a shell too, so running the command with full archive priveleges is a bit much – at least if you’re trying to have any sort of granularity to your security regime, which was, after all, the whole point of this exercise. So instead of running the entire command as the katie user, “dak dsa” instead has to escalate its own priveleges, in this case using sudo and specific options, such as sudo dak dsa -A -- foo.changes to approve foo.changes. Fortunately sudo and the apt argument parser are cooperative enough to allow “dak dsa” users to invoke “dak dsa -A – *” as katie, and thus have only the very limited access we’re trying for. Obviously the above is taken from the testing-security team – it’s the same source and i386 packages, recompiled on other architectures by the security.debian.org testing autobuilders. It’s shown up a few flaws in the autobuilding for etch: (a) the amd64 autobuilder isn’t active; (b) the arm buildd can’t seem to find its chroot in between running apt-get install and apt-get remove; (c) the s390 buildd only works if the source is on ftp-master; (d) of the five m68k buildds that will take packages for security.debian.org updates to testing, only two will succeed (a400t and poseidon). There’s also the notable problem that the chroots for the functional buildds have gotten out of date and that builds break somewhat obscurely as a consequenece. One of the test updates is also failing on hppa due to space restrictions. And of course, the above list is after a chunk of other problems have already been fixed. It’s worth noting that even if the above isn’t fixed for testing now; we’ll still need etch chroots for security.debian.org when we release, so those problems have to be dealt with at some point. And that the brokenness is the result of six months’ divergence from sarge; after a year and a half when etch releases – or the three years between woody and sarge’s release – it’s probably fair to expect worse breakage. Anyway, that’s just about it from me on this topic. Micah Anderson from the testing-security group is currently checking out the unembargoed facility, and has redone a couple of DTSAs on security.d.o. So presumably those guys will start working out whether security.d.o is something they want to make use of, and if so, working out what changes/tweaks are necessary for that. Though, unsurprisingly, I also still have to do some committing to CVS…

Well, Christmas came early for me at work. I was given a brand spanking new IBM Thinkpad R50e. The one with the DVD Ram drive \o/

It came pre-installed iwth WinXP (urgh!), so I quickly set about installing Debian on it.
I'm very impressed iwth teh level of support that Thinkpads have in Linux. Not everything worked out of the box, but it was fairly easy to set things up.
tpb is used to make things like the 'Access IBM' button work, which launches a xterm for me :)
Suspend to disk isn't working yet, but that's mainly due to my own lazyness in getting suspend2 working.
I do have one issue. The wireless is a pain with 2.6.14. The ipw2200 drivers are just *not* happy with the ieee80211 module. This seems to be due to Bug#33761. Interestingly, if I follow the advice in that report and cp the ieee80211 files to /lib/modules/2.6.14-2-686/ it works just fine, until I restart. Not sure what's going on there. Ho hum.

Repeating and following up to my post on -devel yesterday, I think that the biggest hurdle for Linux on the desktop is indeed that there are no provisions that allow an ordinary user to mount USB drives or access the sound devices. There are a bunch of workarounds that work reasonably well for single unmanaged systems, namely adding an entry to the fstab and using a suid program. Both of those are neither foolproof nor secure. The solution I'm proposing is to go through X, where a number of system services connect to the X server and allow access to the devices they control to all clients. The filesystems would live in userspace, thus allowing the user to plug their own.

It’s more than a year since the first development release of Backup Manager, this easy-to-use tool for archiving your data under Linux. Version 0.6 which has just been released, provides a set of features for letting you implement your own backup strategy.
Backup Manager is able to use any existing infrastructure for achieving this goal: FTP or SSH accounts, CD/DVD burning devices…
A couple of different backup methods are available: tarballs (incremental or not), dumps (MySQL, SVN) and a generic method which uses content sent on stdout by an arbitrary command. An effort has been given regarding localisation, the program is now translated in 5 languages: French, German, Spanish, Italian and Vietnamese. The user guide has been writen and is available in different formats. Hopefully, the debian package will come very soon…

I am making arrangements to go to New Caledonia on my travels from Saturday. So I won’t be packaging imminent releases of:

• Maradns 1.2
• Wordpress 2.0

Sorry. I am pissed with Debian the last couple of days. Boiling. Yes I’m stressed, yes Debian is my scapegoat. My unstable system is completely b0rked. :( I tried. Honestly. I tried. I am running the 2.4 kernel which no matter how many modules I insert can’t seem to get X running with mouse support. I expected perhaps I need to dpkg-reconfigure xserver but then that reported I had a broken installation. WTF! Thanks mate. Paging around the end of virtual consoles in 2.4 which I have to do now, also does not bloody work. If I go off the edge it gets stuck. ALT+arrows don’t work. CTRL+ALT+F-keys don’t either. Nightmare. Reboot. Fsck errors. Fuck. dpkg -i of a 2.6.14 kernel just bombs out too while trying to make a mysteriously complicated initrd. I can’t really debug this problem as I don’t have Internet connectivity with my laptop either. Internet connectivity problems aren’t to do with Debian. That’s Australia’s fault. To add to my miseries I’ve caught a cold. I’ve also been playing around with sed all morning, trying to parse Debian LDAP output. Nightmare. To think I wanted to do my Debian New Maintainer stuff this month. Moray got back to me last month (or the month before that?) saying he was too busy (again). I’ve written to debian nm frontdesk for another AM and I’ve yet to hear from them. Oh well, I’m going to roast my ass in the tropics for a while and try forget computers ever existed.

grep-dctrl has proven, at least for me, an utterly useful tool; I suspect this will probably be the case for many others as well. (As I side comment, I believe it’d be nice for AMs to make sure their applicants do at least know about the existance of grep-dctrl, and ideally have basic knowledge about how to use it.) Many times, though, using its grep-available form is not fine-grained enough, and one needs full control over the distribution to make the search in. A valid workaround for this is to run grep-dctrl over /var/lib/apt/lists/whatever; I’ve been using this for some time now, with shell aliases like grep-sid or grep-s-etch (for sources), but sometimes I wanted a grep over two dists, or several components (e.g., main and contrib), or a set of arches. For this, I decided to write a grep-dctrl wrapper that, relying on the structure of a normal mirror, allows to run a search over any combination of dist/component/arch. At home, where I do not have a local mirror, I have populated /org/ftp.root/debian/dists with a pool of symlinks towards /var/lib/apt/lists, and whenever I need more than i386/source, I can run it on any debian.org machine with a local mirror, e.g. merkel. For example, to know which packages in sid but also present in testing are still kdelibs4c2a-untransitioned, but ignoring hppa and m68k, I’d run on merkel the following:

  % grepd sid:main,contrib:alpha,arm,i386,ia64,mips,mipsel,powerpc,s390,sparc \
          -Fdepends -e 'kdelibs4(c2)?(  , $)' -ns source,package  
    unique-sources   xargs madison -s testing   awk ' print $1 '

In case somebody finds it of interest, the script is available here, together with the dirty hack that is unique-sources, needed since not all binary packages have a Source header (sigh). NP: Jacques Brel, Au suivant

I am fully aware that the current state of the mISDN packages sucks. The big problem with updating them is that the kernel ABI has changed, and the userspace has not completely followed yet, so updating the package to the current state will break other stuff like asterisk-chan-misdn.
If you have a good idea how to fix the situation, I'd be glad to hear it.

Well, it's certainly the most amusing spam I've seen in a while. Sent to debian-security@l.d.o:

"Please pardon the intrusion. You are receiving this invitation because at one time or another, you expressed an interest in music on the internet. Since then, we paid someone for your email address. It's that simple."

Given that the perennial, uh, “discussion” about GNOME’s features is on us again, I thought I’d share the method I use to remove options from Quod Libet. I break them, and see how long it takes people to notice. Well, no, not really, but the amount of brokenness in an option is a good metric for whether or not people change it. One of the first options in QL was a checkbox for “Show album cover”. Sometime around 0.7 or it became impossible to turn this off, and I didn’t notice until I was redoing the preferences dialog for 0.11. Rather than fixing it, I just removed a few dozen lines of code and made it always on. No one has ever asked for it back (though someone probably will now). This has happened a couple of times. On a related note, three months ago Bram Cohen made an interesting post about configuration in software, which has been rolling around in my head picking up smaller objects since. There’s a lot of “configuration” that we don’t think of as configuration — for example, the volume in an audio player is stored in basically the same place (same file, GConf tree, whatever) as, say, where the program looks for files. But we only think of the later as part of our “configuration.” That’s because we control the volume “nearby,” in the same place we view it, but the location to look for files in a very different spatial place (an entirely separate window). No one would be crazy enough to put a volume control in a Preferences dialog. So “configuration” becomes synonymous with “hard to find”. The answer to configuration creep, then, is to provide as much direct manipulation as possible. At least from the UI perspective. You’re still screwed from the combinatorial explosion on the implementation side. Beyond that, one thing I’d really like is for context menus to be more common. That is, users should be able to expect to right-click on a widget, and change changable aspects of that widget. This also means making right-click involve no surprises — it shouldn’t activate buttons, shouldn’t delete things, etc. Otherwise people will be too afraid to right-click to try configuring. This feels like a good substitute for when direct manipulation isn’t really possible, because the most direct form of manipulation is already taken up by the widget’s primary purpose. Anyway, Quod Libet is going to be moving in this direction in the future. We already have plugins configurable in the same dialog where you turn them on and off. In 0.16 the tray icon has become an interface almost unto itself, and so it has a separate Preferences dialog now, launchable only from the icon. (It also only has one thing to configure, but that might change. Most importantly, it can grow, without getting in the way of people who don’t care about the tray icon.) For 0.17 I’m probably going to fulfill the common “display remaining time” feature request by putting a radio context menu on the time display. And so on. Fixing Real Bugs
But enough about UI wankery. Does anyone know of a nice C parser for Python? Inspired by a bug he found in mmapmodule, Michael’s written a tool to find type signature issues in CPython functions, but its usefulness is lessened by the fact it returns a ton of false positives and probably also misses many things as well. You Are All Self-Absorbed
My project for a class this semester involved trying to extract useful categories from the link structure of weblogs. Unfortunately it turns out weblogs are all about navel-gazing, and the link structure isn’t at all useful. The majority of shared links on Planet Perl,Debian,GNOME,Python pointed to perl,debian,gnome,python .org, and the majority on MSDN Blogs pointed to microsoft.com. Only about 10% of links pointed to a post on another weblog. Given that additionally weblogs tend to not have comments (and even if they do, people reply in another weblog post anyway), that’s kind of sickening. Can you imagine how much email would suck if only one out of every 10 mails got a reply? I wouldn’t be able to spend all day reading about how Debian’s FTP masters are doing their job properly.

Yes, you can surely tell I am no guru when it comes to describing sounds - maybe that's because in Spanish every letter has one, or at most two, sounds? Anyway, Christian, that's the way to say it - The O sometimes sounds a little bit U-ish, in some places you could see this same sound (coming from N huatl, Mexico's main indigenous language) as huaks. The k (in the x) is usually pronounced, but quite soft - sometimes we just refer to the place as "Oastepec", and nobody gets hurt (or worse, sent to Oaxaca (Huajaka - yes, the X is the only letter whose sound truly changes (and that is because Spaniards used it as a wildcard for S, KS, SH, J - In fact, M xico is pronounced M jico, but never (EVER) spelt that way besides what other Spanish speakers say. The original sound, though, was closer to M shico)))
And, yes, I am also one of many thousands of people longing to ride through the Copper Canyon. It's supposed to be really, really beautiful. Too bad Chihuahua is ~20 hours away from Mexico City :(
And about Oaxtepec's location: It's 60km south of Mexico City, not of Downtown Mexico (that would still be out of the city, but not by that much). The best route is not straight, so from my house (in South-Western Mexico City, ~15m away from where the Cuernavaca highway begins) it's about 90 minutes. The highway is _very_ good and safe, don't worry. I do expect people coming by car from the USA. Here you have a good map of Morelos state. Oaxtepec is on the third column, second row, near Cuautla. Just for completeness sake, just North of Morelos you have Distrito Federal, where Mexico City (partly) lies. The airport, where most of you will arrive is again in the second row, third column (hmmm... A pattern starts to emerge! Lets see what that means...) - We are working so we don't have to explain to you all how to get from there to Oaxtepec, I hope we can provide buses covering the route, at least in the days with most arrivals.

“unstable is just that” is what some dork says to me on #debian when I said:

i’ve nuked my machine from a dist-upgrade from unstable last night. It won’t boot. The shell doesn’t look right. help. :)

To make matters worse. Last night I did some house cleaning and ripped out all my old kernels to save space. My 6.5G root partition (everything except home) was full!

1. Ok, try dpkg or apt news on #debian. Nothing.
2. How about blog postings on Debian Planet? Bah…
3. I quickly page in mutt and see if debian-devel has talked about it. Hmmm, seemingly no.
4. Perhaps debian-user via the lurker interface. Hmmm no.
5. Ok, people in #debian-devel will hate me, but I’ll ask there.
6. They point to the topic: FUCKED: yaird/kernels (#343042/#343048) Aha!

Ok, I need a rescue CD. Which one I wonder? Let’s try this one grml. Wouldn’t it be nice to have some sort of Web page like status.debian.org/unstable telling about current high priority problems that will probably affect most Debian users? Right now, I have to look all over the place. Very tiring.

Josselin Mouette has thrown down the gauntlet -- Subversion is the One True Revision Control System and we should all just Stop Worrying and Learn To Love The Handcuffs. In particular:

[...] just use subversion, and if you feel it's missing features, please contribute them. By standardizing on subversion, we lower the barrier for people wanting to contribute, instead of increasing it by asking them to install and understand new tools.

Quick thought experiment, Josselin: replace "subversion" with "Java". Or "Perl", or "C", or even "Python" or "Ruby". Or any other language. It doesn't matter which one. Even if the language you substitute is a good one, and one you happen to like, it's still a fairly obviously braindead idea -- that there can possibly be One True Programming Language for all problems, and that there can never be any improvement that can't be bolted into the existing OTPL. Revision control isn't so much different from programming languages. Different systems will provide different advantages and disadvantages. There's also incremental and revolutionary improvement that will take place over time -- machine code to symbolic to procedural to object oriented -- that can never take place within the established framework. I happen to really like the distributed model -- it reduces (though, naturally, cannot eliminate) the division between the Blessed and the Peons in a project (those with direct commit access vs. the rest of us). You can get disconnected operation for (almost) free. Also, despite the assertions contained in your article, the "barrier to entry", ironically, is actually lower with a good distributed RCS than with Subversion. The barrier isn't what you think, though -- sure, using an unfamiliar RCS is troublesome, but it's a lot less hassle than learning a new language, and people do that on occasion to hack on a particularly interesting problem. The real barrier to entry is forcing anyone who isn't blessed with direct access to The One And Only Repository to use inferior development support tools. "An example!" I hear you cry. Gladly. This morning (literally) I got enough of a handle on the internals of Ruby on Rails to actually track down a bug that was irritating the crap out of me. Being a good developer, I wanted to use revision control to track my changes. In the All Subversion, All The Time "utopia", that would involve getting an anonymous checkout, making a copy, hacking on the copy, then (when all was done) running diff -urN between the original and the copy, and sending it all upstream with a manually-created log message (assuming I could remember everything I'd done). You also need to manually remember (or encode it in your directory or something) the source of your tree, so upstream can merge it reliably (and compare it against other equivalent work that may have been done in the meantime). Doing it better, I could do an anonymous checkout, and then import it all into a new Subversion repository (or directory) of my very own, and hack on it in there. Benefit: revision control of my changes. But it's non-trivial to create a new repo and import everything into it, and there's still no automatic record made of the upstream source of my new repo. Wanting to make a second change is even worse -- I either have to make a whole new copy of my source tree (disk is cheap, but this is getting silly) or just keep forging ahead with changing my existing tree -- so this second set of changes can end up being dependent on the first (which is Not So Great if upstream don't merge your first patch). In the "new repo" scenario, you can branch from the root of your new repo and continue hacking on your newly created branch, which is a good start, but it's still icky. And good luck having the system track new commits from upstream while you're working, too. If the project was using a DRCS, in contrast, the problem would reduce to making a branch into your local archive, hacking (committing at will), updating with new upstream commits as you go along, and then publishing your changes to a public place for reintegration (or, in some cases, sending your changeset via e-mail). Oh, and before anyone starts screaming "if anyone can branch, it will encourage forking!", consider which is more likely to result in a permanent fork (rather than a temporary independent line of development): a local set of changes in a tarball or local subversion repo, both of which are hard for anyone else to collaborate on without major pain; or a branch in a simple-to-publish (or push) designed-to-be-shared DRCS archive, which automatically keeps all of your interesting metadata intact and coherent across archives, merges, time, and space (and possibly even dimensions). This utopia doesn't really exist, and is hampered by everybody having their own Pet DRCS, but the problem, I'm fairly sure, is transient, and my main point isn't even so much against the choice of Final Ultimate Solution, or even the problem space, but more about the attitude that everyone should get behind Any One System and stay there. I can't imagine the world of pain we'd be in if Josselin had posted his message a few years ago (but with s/subversion/CVS/i, naturally) and everyone had followed his advice -- can you imagine per-file changesets with no effective merge capability for the rest of eternity? <shudder />

Xen

I updated the script I wrote to create new Xen instances of Sarge.

• http://www.debian-administration.org/articles/304/create-xen-image.pl.txt

It is still pretty nasty but it can now create a new Sarge installation with networking, OpenSSH, users and groups all in the space of a few minutes:

./create-xen-image.pl --hostname=vm01 \
  --ip=192.168.1.245 \
  --gateway=192.168.1.1
  --dir=/home/xen/

Unfortunately it doesnt live in a CVS module of its own, rather one I dedicated to hosting resources associated with articles on the d-a.org website. Maybe time to revisit that?

MouseTrap

Whilst in a quiet mood, waiting for my tea to cook, I decided to amuse myself by playing mousetrap - something I’ve not touched for a month or two. In a fit of enthusiasm I imported mousetrap into CVS - comments/feedback welcome. [Simplistic arcade game, uses SDL, Debian Sarge package available.]

SableVM SDK 1.13 released! The most important change in this version is the update of the class library to the GNU Classpath 0.19 release. The difference in usability is huge, because SableVM SDK 1.12 used GNU Classpath 0.16 and since its release there's been plenty of improvements to GNU Classpath (Swing being probably still the most visible to a user). Way to go guys! SableVM SDK is meant as a relatively complete replacement of a Java Software Development Kit. An important goal is also the ease of installation. To achieve it all the separate software pieces have been integrated into one source archive that (once its build-time dependencies are fulfilled) can be simply installed all at once. Just a short reminder about what's inside:

• SableVM and SableVM Classpath (based on GNU Classpath 0.19)
• CP-Tools (javap, javah, serialver, ...)
• Fastjar
• GJDOC (javadoc drop-in replacement)
• Jikes
• LibFFI and LibPOPT (now part of SableVM)

Have fun with it! And don't forget to let us know of your experiences!

Thomas, don't feel bad if your Spanish doesn't work out sometimes. You'll remember how badly mine sucked. But nothing compares to the last time I was in a non-English-speaking country: I was at a bar, and pointed to the postmix Coke tap with the Coke logo on it, and said 'Coca-Cola'. Got asked small or large, figured I'd succeeded, motioned large with my hands. What I ended up with was the largest cappucino-like drink I've ever seen in my life, which was exactly what I wasn't looking for. Next time at the same place, I was a little more careful when asking what I wanted, and the dude behind the counter, without batting an eyelid, said, 'oh, you want Coke?' in a pretty flawless accent. Egads.

Sigh, I'm not Debian:
Which OS are You?

So yeah this is old, but it's funny. My favorite question was:

Your spouse complains about a large painting on your living room wall which is hanging crooked. Do you:

• Move the painting so the top-edge is flush with the ceiling, ensuring it's level.
• Bust out your toolbox, complete with laser-level, chalk-line, square, plumb-bob, and pneumatic brad-nailer, and form a committee on the best approach to fixing it.
• State that the deviance from level is well within desired parameters.
• Tilt all other wall-hangings and furniture to match the pitch.
• Tell him/her to go get you another beer.

Scary thing is, I really do have a laser level, and really do use it to align things hanging on the wall...