BSP Paris 2010, during mini-DebConf The first mini-DebConf in Paris, France is just a few weeks away and about 150 persons have signed up as attendees (wow!). The days of the conference (October 30th-31st, 2010) will most likely see the Debian Squeeze release in its deepest possible freeze, fighting with the very very very few remaining RC bugs (right? right!). What's the most useful thing that a crowd of Debian hackers can do that close to a release?
A Bug Squashing Party, of course! Therefore please welcome: We now need to arrange a room for the BSP, in parallel with the talk rooms of the conference. Hence please sign-up on the wiki page if you plan to attend the BSP. Please do so even if you're already signed up as a conference attendee, as the rooms will be different.

My phone contract ends in a few months, so I m looking at getting a new Android phone. I want a big Android phone (in both physical size and resolution) that has a physical keyboard, a digital compass, A-GPS and at least a 5MP camera with geo-tagging. I want to be able to read PDF files and run ssh sessions, so a big screen is required and a physical keyboard avoids wasting screen space for a soft-keyboard. My pockets will fit something about 10.5cm wide by 17cm high but I don t expect anyone to manufacture such a large phone. High resolution is a good thing too, it seems that the best available at the moment is 854*480 (with 800*480 being reasonably common). I want Wifi and all the 3G and GSM data transfer standards. It would be ideal to have a phone with the dual networking stack needed to do both voice and data at the same time. I m not interested in anything that runs a version of Android older than 2.2 as native tethering is important. An option to upgrade to post 2.2 would be a really good thing. Here are the nearest options I could find:

Phone	Resolution	Screen Size (inches)	Camera Resolution	Notes
Motorola Milestone	854*480	3.7	5MP
Motorola Droid	854*480	3.7	5MP
LG VS 740	800*480	3.2	3.2MP	no GPS or compass
Lenovo LePhone	800*480	3.7	3MP	no GPS or compass

It seems that Motorola makes the phones that best suit my needs, does anyone know of any better options?

In the last two cases where I created FAI configurations for different systems I needed to install packages which are not part of the Debian repositories.
Unfortunately FAI does not provide a standard way to supply the installation with custom packages so I need to figure out a way on my own.

I have the following requirements in the solution:

• Packages can be configured in package_config files as usual
• Packages will be installed during the normal package installation, no crude hack (like 'dpkg -i' and 'apt-get -f install' after usual package installation)

It would be easy if a repository reachable by the installed system would already exist. Unfortunately it does not. But.. aha! So here is the idea:

1. In the FAI configuration space add a new directory
   'packages'
2. We will use reprepro for the repositiory. You should install it where ever you prepare the configuration space. It would also be an option to install it into the NFSROOT and run it from there, but I decided to pre-prepare it (but this would be a clean solution if one of the FAI developers decided to implement a standard way, I guess).
3. Create a directory packages/conf and therein a file distribution with this content:
   

   Origin: Debian
   Label: Debian-All
   Suite: stable
   Codename: lenny
   Version: 5.0
   Architectures: i386 amd64
   Components: main
   Description: Debian Lenny

   Obviously you should adapt at least the Architectures line to whatever you need. Otherwise adapt what you need.
   
4. Now you can add packages, with reprepro includedeb lenny /path/to/debfile from within that directory, so cd to it, before.
   The result is, that the packages directory becomes a full-fledged Debian APT repository which can be used with apt by creating a line similar to the following:
   

   deb file:/var/lib/fai/config/packages lenny main contrib non-free

6. And thats what we'll do. In order to make this happen before any software gets installed, we create a hook. It needs to be called instsoft.CLASS where CLASS is a class that is used for the fai install we are working on. It basically needs to contain something like (+ the usual shell script stuff):
   
   

   $ROOTCMD ainsl /etc/apt/sources.list "deb file:/var/lib/fai/config/packages lenny main contrib non-free"
   $ROOTCMD apt-get update

   This should add the repository the sources.list in the /target and run apt-get update.
   

Thats it. This should be all to make the repo available to the usual installation. That means if your package_config files contain packages which are only part of the custom repo they will now be able to be installed.

(This might probably not be a copy and paste howto. It just describes the rough steps needed to do and might contain errors. So don't blame me if it doesn't work 100% this way. ;-)

Debian 6.0 squeeze will be the first GNU/Linux distribution release ever to offer comprehensive support for magnetic resonance imaging (MRI) based neuroimaging research. It comes with up-to-date software for structural image analysis (e.g. ants), diffusion imaging and tractography (e.g. mrtrix), stimulus delivery (e.g. psychopy), MRI sequence development (e.g. odin), as well as a number of versatile data processing and analysis suites (e.g. nipype). Moreover, this release will have built-in support for all major neuroimaging data formats.

Please see the Debian Science and Debian Med task pages for a comprehensive list of included software and the NeuroDebian webpage for further information.

NeuroDebian at the Society for Neuroscience meeting 2010

The NeuroDebian team will run a Debian booth at the Society for Neuroscience meeting (SfN2010) that will take place November 13-17 in San Diego, USA. The annual meeting of the Society for Neuroscience is one of the largest neuroscience conferences in the world, with over 30,000 attendees. Researchers, clinicians, and leading experts discuss the latest findings about the brain, nervous system, and related disorders.

If you are a Debian enthusiast (developer, contributor, evangelist) and reside near San Diego (or have time and funds for travel/lounge), or already planing to attend SfN 2010, please help us to make the Debian booth at SfN shine. Please contact the NeuroDebian team at team@neuro.debian.net

If you are going to SfN2010, come talk to us at booth #3815.

Contributed by: Michael Hanke and Yaroslav Halchenko

A conffile is a configuration file managed by dpkg, I m sure you remember the introductory article about conffiles. When your package stops providing a conffile, the file stays on disk and it s recorded as obsolete by the package manager. It s only removed during purge. If you want the file to go away, you have to remove it yourself within your package s configuration scripts. You will now learn how to do this right. When is that needed? dpkg errs on the side of safety by not removing the file until purge but in most cases it s best to remove it sooner so as to not confuse the user. In some cases, it s even required because keeping the file could break the software (for example if the file is in a .d configuration directory, and if it contains directives that are either no longer supported by the new version or in conflict with other new configuration files). What s complicated in rm ? So you want to remove the conffile. Adding an rm command in debian/postinst sounds easy. Except it s not the right thing to do. The conffile might contain customizations made by the administrator and you don t want to wipe those. Instead you want to keep the file around so that he can get his changes back and do whatever is required with those. The correct action is thus to move the file away in the prerm, to ensure it doesn t disturb the new version. At the same time, you need to verify whether the conffile has been modified by the administrator and remember it for later. In the postinst, you need to remove the file if it s unmodified, or keep it under a different name that doesn t interfere with the software. In many cases adding a simple .dpkg-bak suffix is enough. For instance, run-parts ignore files that contain a dot, and many other software are configured to only include files with a certain extension say *.conf. In the postrm, you have to remove the obsolete conffiles that were kept due to local changes and you should also restore the original conffile in case the upgrade obsoleting the conffile is aborted. Automating everything with dpkg-maintscript-helper Phewww that s a lot of things to do for a seemingly simple task. Fortunately everything can be automated with dpkg-maintscript-helper. Let s assume you want to remove /etc/foo/conf.d/bar because it s obsolete and you re going to prepare a new version 1.2-1 with the appropriate code to remove the file on upgrade. You just have to put this snippet in the 3 relevant scripts (preinst, postinst, postrm):

if dpkg-maintscript-helper supports rm_conffile 2>/dev/null; then
    dpkg-maintscript-helper rm_conffile /etc/foo/conf.d/bar 1.2-1 -- "$@"
fi

You can avoid the preliminary test if you pre-depend on dpkg (>= 1.15.7.2) or if enough time has passed to assume that everybody has a newer version anyway. You can learn all the details in dpkg-maintscript-helper s manual page. I hope you found this article helpful. You can follow me on Identi.ca, Twitter and Facebook. 5 comments Support my work

I am really struggling with all this anti-Obama rhetoric, coming from both the right and the left. From where I sit, while he hasn t been perfect, he s accomplished quite a bit for us since he s been president. Consider:

• Obama got through the most comprehensive healthcare program we ve ever had, which will provide a needed safety net to many, and yet will save the government money.
• The bailout (TARP) happened when Bush was president, and consisted of loans and asset purchases. Current forecasts are that the government will get 90% of that money back.
• The recovery & reinvestment act passed by Obama has exceeded the estimates of 3 million jobs saved or created, as graded by non-partisan groups. Most economists argue it should have been bigger to make a better change in the economy. It s widely credited with having stopped the bleeding.

I don t get it. Liberals are claiming he s not doing enough, but look at what he s got to work with: Republicans filibustering just about everything in the Senate. I don t think that s Obama s fault. And the conservatives, as far as I can tell, are just yelling. I can t figure this out. They want to cut taxes, cut the deficit, and increase defense spending. Good luck with that.

Review: Thinking in Java, by Bruce Eckel

Publisher:	Prentice Hall
Copyright:	2006
Printing:	October 2009
ISBN:	0-13-187248-6
Format:	Trade paperback
Pages:	1461

Thinking in Java has gone through multiple editions. This review is of the 4th edition, which is targetted at Java 5 (with some minor updates for Java 6, released as it was going to press). Prior to reading this book, I'd never written code from scratch in Java and had never learned anything about Java in a structured fashion. My CS degrees come before the era of ubiquitous Java; the most I'd ever done with the language was look over and make some minor fixes to code other people had written, using general programming knowledge. I choose this book as my introduction because I was looking for a ground-up introduction with good reviews and was avoiding books that contained a printed version of the Java library documentation. I can get that myself on-line. I kept a set of notes on my impressions of the Java language itself separately and will not get into that here. This is, instead, a review of Thinking in Java as a book and as a training tool for someone who wants to pick up the language. First off, this is a remarkably well-titled book, much more so than the typical programming language book. Eckel is not just teaching Java as one programming language among many. He tries hard to teach the reader to think in Java, with a lot of attention to idiomatic use of the language and natural ways to use its expressiveness. This is exactly what I was looking for I don't want to just write C or Perl in Java syntax and I was very satisfied with the result. The book is also very heavy on source code examples; this is much of the reason why it's 1,461 pages. Eckel illustrates everything with Java code, generally complete functioning short programs. Even exploratory musings and experiments are implemented as Java code. I don't think there's any significant thought in this book that isn't shown in both text and in explained Java code. Eckel has also clearly put significant effort into choosing good examples and designing his sample programs. I have some past (mild) experience with object-oriented design, and a lot of experience with higher-level system design, and I was satisfied and occasionally intrigued by the object structures and design tips that Eckel provides. He uses design pattern language heavily, but not in a confusing way, and he takes some time to explain typical design patterns and illustrate them repeatedly. This is a solid introduction to good object-oriented program design as well as an introduction to Java. One oddity of this book, though, is that Eckel introduces the language from the ground up, starting with syntax and basic types, and is very careful not to use any concepts before he introduces them. The result is a very thorough introduction to the Java language, but it means that it takes 900 pages (!) before Eckel introduces I/O and the possibility of writing a useful program based on just the information in the book. This is for entirely sound conceptual reasons: I/O in Java relies on lots of concepts, like exceptions and generics, that require extensive introduction and discussion. However, it does mean that through well more than half of a monumental tome the reader is learning the language through rather artificial programs. I have extensive prior programming background and a high tolerance for more abstract examples (I have a master's degree in software theory), so I could deal with this, but even with that background I was starting to feel like my head was getting too full and too crowded with concepts without being able to make them concrete. It probably would have helped to work through some of the exercises, but I dislike exercises that aren't grounded in some problem I personally want to solve. If you're someone who only learns languages through practical application, this approach to teaching the language may drive you nuts, and you may want to look for another book that compromises conceptual progression to get you started faster. Related to this, Thinking in Java is not about the standard library. It's about the language, and the vast majority of this book is focused directly on the language level: inheritance, information hiding, generics, exceptions, introspection, concurrency, annotations, serialization, and so forth. The only parts of the standard library that Eckel covers in depth are the container classes, I/O, and a somewhat odd and misplaced final chapter on Swing. There is nothing about databases, essentially nothing about web applications or containers, no network programming, and very little in the way of practical, applied problems. As you might guess from the combination of that limitation of scope and the length of this book, that means it is extremely comprehensive; I doubt there are many corners of the basic language semantics, including around generics, that Eckel leaves unexplored. This is exactly what I wanted (I know how to read library documentation myself and all language core libraries start looking mostly the same after you've programmed in five or six languages), but it's very different from the typical approach of a programming language book. Don't be surprised. This biggest problem with Thinking in Java from my perspective is that it defers many interesting topics to Eckel's web pages and to free companion books and material that is supposedly found there, to the point of advertising that on the cover. This is a good way to allow the reader to explore extra topics that are of specific interest while skipping others, provided that one actually delivers on that promise. However, Eckel's web site is dire. The first time I looked at it earlier this year I was unable to find most of the supplemental material the book promises is there, and now www.mindview.net doesn't resolve in DNS. I've found copies of some of that material hosted elsewhere in Google searches, but this is a rather frustrating experience if one was relying on that supplemental material to fill in the gaps. And the book is clearly written expecting people to go look at the web materials; Eckel refers to them probably a hundred times over the course of the book. Less of a serious problem, and more of a quirk, is the closing chapter on Swing. This chapter really doesn't fit much with the book. I suppose Eckel felt obligated to put in at least one chapter on some concrete applied topic (I personally would have preferred databases be that topic, but oh well), and it does serve a useful purpose in showing how concurrency, inner classes, inheritance, and introspection all work together in a significant Java library. But it's not presented as just an example, and it fits in oddly with the rest of the book. It also has an inexplicable middle section about Flash programming. I ended up mostly skimming this. But this isn't much of a flaw in the book; if one ignores 100 pages out of 1,450, that's not much of a loss. Eckel comes from a C++ background (he was a founding member of the C++ standardization committee), which shows up most prominantly in the generics chapter. It's a solid, thorough introduction to Java generics, but it also has an extensive exploration of all the problems with the Java erasure model and many, many examples of the things that one would find intuitive from C++ that don't work the same way in Java. If you come from a C++ background, this is quite possibly useful; if, like me, you don't care about C++, it's at best mildly interesting and gets a touch tedious. There are a few other places where Eckel pokes surprisingly sharp sticks at the Java designers, but taken in context I think this is a quirk of the book's conversational style (which is otherwise a feature). Eckel's love of Python is also somewhat entertaining (particularly the long advertisement for Python in the introductory chapters of a book on Java), but has little impact on the book. I think the largest drawback of it is that all the examples in this book are tested using a Python framework, which isn't so much a problem with them as a lost opportunity. They're annotated with metadata used by Eckel's Python test framework, and in a Java book I would have been much more interested in a good Java test framework built on top of something like JUnit. Oh well. Overall, this is a very solid book which, despite being enormous, does not feel pointlessly padded. It's thorough and exhaustive on its topic, but there's a point to nearly everything in here. It was also exactly the Java book I wanted: an introduction to the language, built on a firm foundation of object-oriented program design, with discussion and pointers on how to think idiomatically in the language and use it to its fullest potential, and without mindlessly reproducing the standard library documentation. If that's also what you're looking for in a Java book, I recommend it highly. Just know going in what sort of book you're getting, since its pacing and order of presentation may frustrate some learning styles. Rating: 8 out of 10

Last night, I released xen-tools 4.2 and also uploaded it to Debian Unstable. It also should become part of the upcoming Debian stable release called Squeeze. (Thanks, Mehdi!) For those who are missing xen-tools in Ubuntu 10.04 Lucid Lynx or Ubuntu 10.10 Maverick Meerkat, there s now a xen-tools PPA containing the current stable package for both Ubuntu releases. Major changes since the 4.2 release candidate 1:

• Tons of documentation improvements
• Preliminary support for Ubuntu 11.04 Natty Narwhal and Debian 7.0 Wheezy (Closes #597521)
• More robustness on exotic combinations of command-line options

Major changes since 4.2 beta 1:

• Uses GeoIP for Debian mirrors: Default Debian mirror is now cdn.debian.net
• Uses apt-config to parse Dom0 s apt.conf. (Closes #560011)
• With --verbose, the output of commands called by xen-tools (e.g. debootstrap) is not only logged, but also printed to STDOUT. (Closes #513126)
• Adds btrfs support.

New Team Member I d also like to welcome St phane Jourdois as member of the xen-tools development team who contributed quite a lot of the new code in 4.2. See GitHub s Impact Graph or Ohloh s List of Contributors. Roadmap If there s no need for a bug fix release, the next release will be 5.0 and will be the result of some heavy refactoring. Our aim is:

• less code duplication
• more modularity
• more consistency over all included scripts and hooks

We will probably also use Perl::Critic to improve the code consistency and quality further. (Thanks Ren e for the idea!)

As a follow up on my report from last month about bidi status in openoffice.org 3.3, today was a very good day for bidi in openoffice.org. The short story: two important bugs were fixed for 3.3, and we now have the bidi keyword for IssueZilla system. It began with the fix to a cosmetic bug in the openoffice.org main screen which caused the icons to repaint improperly. While this isn t critical at all, it just looks really bad to have it on the main screen. And I don t want people to get the wrong impression. Thanks you Philipp Lohmann for fixing #97556. The second bug was that AutoFilter isn t working for RTL sheets (regards whether the UI is LTR or RTL). This issue was reported yesterday and got fixed in 24 hours. Thank you Niklas Nebel for fixing #114944. It took us longer to isolate the bug than to get a patch for it. I wish this will happen more (: For closing, and in response to the bidi meta issue, a new keyword was created in the issuezilla: bidi. Till now, there was a bidi sub component in the UI, but this isn t always helpful as sometimes it s better to report against the actual component. The keyword will help us to better tag the issues for easy listing. The thank you list is long, as there were more than a few people behind the scenes today. I ll only mention Netanel, my partner to the Hebrew l10n team.
Filed under: Israeli Community, LibreOffice, Openoffice.org Tagged: bidi, openoffice

I ve been keeping up with my amateur radio activities lately. The big news is that I passed the amateur extra exam at a hamfest in Wichita on Saturday. That s the highest level of amateur radio licensing available, and only about 17% of hams have it. I passed it with 100% correct, as I did with my other two exams as well. Pretty happy with that. I m also getting ready to get a radio installed in my car. My FT-857D, which I ve been using in the house, is really a mobile. I picked up antennas and cables for that at the Wichita hamfest. My brother, who is great with cars, will probably help me do that. I m excited about that. I also think I can get radio going on my bicycle. I need a half-wave vertical antenna to mount on it. Really the only challenge is how to attach that to the bicycle, as there isn t exactly a thriving antenna mount industry for bicyclists.

I've just uploaded git-dpm 0.3.0-1 packages to experimental. Apart from many bugfixes (which I will also take a look if I can make an 0.2.1 version targeting squeeze, though the freeze requirements tend to get tighter and tighter, so I may already be too late), the biggest improvement is the newly added git-dpm dch command to spawn dch and then extracts something to be used for the git commit message (I prefer to have more control over debian/changelog, so I prefer this way over the other direction).

Many people know Ultimate Debian Database already, and do use of it to create useful QA tools, or other Debian related activities. There is another database which is widely used by all of us, every day, and runs behind the scenes without being noticed. It is called projectb, the huge database of the Debian archive. projectb is the place where dak stores all the information it needs to run the archive (including but not limited to source packages, related binaries, suite definitions and associations, overrides, and so on), and it tells dak to hit you with a REJECT if you try to upload a package twice, or if you do something The Wrong Way. OK OK, it eventually allows your packages to be accepted too, sometimes it also behaves good projectb is hosted on ftp-master.debian.org. Most fellow Debian Developers cannot login over there because access is restricted to FTP and Release people only, but can enjoy its clone on merkel.debian.org ^[1]. Please note that clone is synced on a regular basis, but it could be a little bit not up-to-date with the very latest changes. Just run the following: psql -d projectb -p 5433 Now that you have access to it, you could want look at its structure to start looking at it. I just provide a couple of trivial examples of what you can do with it, your imagination is the limit ^[2] This query displays which dpkg version known suites ship:
SELECT s.source, max(s.version) AS version, su.suite_name AS suite
FROM source s
JOIN src_associations sa ON sa.source = s.id
JOIN suite su ON su.id = sa.suite
WHERE s.source = 'dpkg'
GROUP BY s.source, su.suite_name
ORDER BY version; This query displays changelog entries for debhelper which versions are greater than 8:
SELECT changelog
FROM changelogs
WHERE source = 'debhelper'
AND version > '8'; Working with projectb means working with real Debian archive data, so you are sure to always get solid information. You can also experience a limited (but functional) dak session on merkel. You cannot do much, data is read-only, but this is not a limit for a couple of commands. The most interesting is dak rm, where you can simulate a package removal, and discover reverse dependencies in advance, to save some work to your lovely FTP Team Just run the following:
dak rm -n -R -m "Don't worry, it's a Dry Run" your_behated_package Wait a little bit, and you will be prompted with removal report. Just remember to always use -n and -R flags, though. Want even more? Join FTP Team, and you will given the chance to learn a lot more about Debian! DISCLAIMER: if you plan to write a tool, or perform an activity which relies on current projectb implementation, PLEASE TALK TO FTP TEAM FIRST. Internal structure can change a lot over times, and it is way better let FTP Team to handle exporting/parsing its data for day-by-day tasks. ^[1] This is probably supposed to change, as merkel is going to be decommissioned soon. ^[2] If you need a new feature, just talk to FTP Team.

I had this topic in mind for quite a long time, but it got more recently more attention because of discussions on gammu-users mailing list. Gammu should use some library for do basic stuff like strings or date manipulations, logging and so on. The reason is that having own implementation of all that is not really useful and just source of another amount of bugs. Currently mi intention is to use GLib, simply because I don't know any C alternative (though there are probably lot of C++ cross platform libraries). Of course the biggest question is how to make the change, because it will be obviously intrusive and making such big changes will probably lead to several months of work without really making another release. Even if it will be done on separate branch (what would be most likely the case), developers will spend most of time on this issue and not much time will be spent on bug fixes (and backporting them).

Filed under: Coding Gammu 2 comments

It s often said that KDE and GNOME are too bloated, too complex, too slow, or whatever. I won t deny that these critics are often justified, and some parts of the code are badly designed. But there can also be reasons behind this bloat: they are called features. When you want to mount an encrypted USB disk, you can write your own script and even write your own udev rules so that it can be mounted with autofs. It looks fun to find a way to use software that has been obsolete and useless for 10 years, in a way that requires administrator rights just to add a new model of USB disk to your system, and puts the private key in a place that is readable for anyone stealing the hardware. But while it will turn out as an interesting read for those willing to understand how the device mapper and cryptsetup work, I think it s a bit abusive to present it as a correct implementation of an encrypted disk mounting setup. Discover gnome-disk-utility In etch, GNOME shipped with pmount, a nice utility, still included in Debian, that allows to mount your keys, encrypted or not. In lenny, it shipped with HAL, and allowed to store LUKS passphrases securely in the GNOME keyring. Whenever you plug a LUKS-encrypted disk on a lenny system running GNOME, it is immediately made accessible, and that s all. In squeeze, things go much farther thanks to udisks (the backend) and gnome-disk-utility (the frontend). Roland rightly pointed out that the g-d-u documentation is nonexistent - it consists only in a screenshot, which is outdated. Nevertheless, you will find it practical if you want to encrypt a USB drive, since you can format it, partition it, create encrypted volumes and the filesystems on them, in a few clicks and without root permissions. If you use nautilus, it will also mount them automatically using the same backend when you plug them. I don t know for you, but I think it is worth a few CPU cycles of my 3GHz processor and a few dozen megabytes of my 500GB drive.

Proposed timeline of the Release Team

We hope to have sorted out all the details and resolved the remaining blockers by the end of October, with the focus during November being on translation updates, testing and coordination with different teams to prepare the new release.
This means that it s possible to have a release out in time for Christmas, but to do this we need YOUR help. Please, squash bugs, write release notes, squash bugs, support our translators and squash some bugs.

I recently invested some time to work on several cool features in Deb-o-Matic.
I plan to release 0.9 version soon, so I wanted something new for its users I merged some patches by Alessio Treglia, who implemented a couple of nice things:

• Mailer support, to send build status notifications to the uploader
• Blacklist support, to temporarily limit builds for a given distribution

Then, I worked on some changes I really wanted to have:

• Rebuild support, to redo build of a package already in distribution archive
• Improved lock system, to avoid random build hangs which affect older code
• Fix pyinotify loop, which prevented Deb-o-Matic to quit in interactive mode

Now that the big part of the planned features is committed, I am going to test them to spot major issues, and add some minor improvements to have a shiny release Last but not least, your help is appreciated to complete translations! There are really a few strings to process, and several languages are already half-completed, so if you can spend five minutes (or even less!), I will be grateful

You have a computer. You're afraid of it being stolen by baddies or raided by the police, so you've encrypted its hard disk with LUKS. You also want to carry around some of your crypto keys (SSH and/or GPG), or any kind of sensitive data, on an USB key, so you can restore a normal activity in case the computer gets stolen or becomes untrustworthy. You like things that Just Work, including automounting with autofs (no GUI popups, no need to manually unmount and so on). But of course, you can't very well just mount the drive and store your keys on it in the clear. Well, actually you can (I did it for way too long), but let's assume you want to do without. Because USB keys get stolen or lost, too. autofs just handles the mounting of the drives, not their unlocking, and there's no hook in there specifically for LUKS. There is, however, a more generic way of running arbitrary commands on mounting: the program maps. It's all described in the documentation, so I'll just paste the relevant parts of my /etc/auto.removable, with a few comments. Remember to make it executable and reference it in /etc/auto.master.

 #! /bin/sh
 volume=$1
 autoluks ()  
   dev=/dev/$1
   cryptname=$ 1 _crypt
   cryptdev=/dev/mapper/$cryptname
   keyfile=/etc/private/$cryptname.key
   options=$2
   [ ! -e $dev ] && exit 0
   if [ -b $cryptdev ] && ! cryptsetup status $cryptname   grep -q device:.*$dev ; then
       cryptsetup remove $cryptname   logger
   fi
   cryptsetup --key-file $keyfile luksOpen $dev $cryptname   logger
   [ -b $cryptdev ] && echo $options :$cryptdev   true
  
 case "$volume" in
   # LUKS-encrypted volumes
   lacie-keys)
       autoluks lacie-keys -fstype=ext4,ro,noatime,nodev,noexec,nosuid
       ;;
   lacie-keys-rw)
       autoluks lacie-keys -fstype=ext4
       ;;
   lacie-backups)
       autoluks lacie-backups -fstype=ext4
       ;;
   # Non-encrypted volumes
   cd)
       echo -fstype=iso9660,ro,nodev,nosuid            :/dev/cdrom
       ;;
   floppy)
       echo -fstype=auto,sync,nodev,nosuid             :/dev/fd0
       ;;
 esac

The astute reader will have noticed that the keys volume is mounted either read-only or read-write with the same mechanism. This volume contains SSH keys that I use quite regularly, that filesystem is going to be mounted and unmounted very often. USB keys, and flash memory in general, don't really like repeated writes. Fortunately, the SSH keys are mostly read, and very rarely written to, so I can afford to mount the partition read-only and save the write cycles for when I generate new keys (the mere action of mounting a partition read-write changes it, even if the files in it are never modified). The backups volume is mostly accessed in write mode, and much less frequently anyway, so there's no need for a distinction there. This supposes that the partitions on the USB key appear as /dev/lacie-keys and /dev/lacie-backups. Due to the dynamic naming of devices, you may like to use rules similar to the following in /etc/udev/rules.d/local.

 KERNEL=="sd[a-z]1", ATTRS idProduct =="1027", ATTRS idVendor =="059f", ATTRS manufacturer =="LaCie", ATTRS product =="LaCie iamaKey", SYMLINK+="lacie-keys"
 KERNEL=="sd[a-z]2", ATTRS idProduct =="1027", ATTRS idVendor =="059f", ATTRS manufacturer =="LaCie", ATTRS product =="LaCie iamaKey", SYMLINK+="lacie-backups"

You'll also need to initialize LUKS on the partitions, save the key, make the filesystems, and so on. If you're still with me, you probably know what I'm talking about, then I don't need to explain about that. This setup works for me, but there's no guarantee and so on. Based on a tutorial found on the Debian Administration website (great resource, by the way). Update: I'm told a large part of the script could be replaced with pmount. If you like short scripts, you may want to investigate that too. Update 2: Josselin points out a different solution using Gnome, udisks, gnome-disk-utility and Nautilus. It's worth checking out, for those who like to run all that and click around. I can't test it right now (Gnome/Nautilus currently refuses to mount any USB key, for some presumably transitional reason), but I have no reason to believe it's inherently broken. I just don't like having to do anything when I plug my key or before I unplug it, and I'm not always running a graphical session with a desktop.

Apple released Remote 2.0, which doesn t work with forked-daapd. We are looking into it and trying to find out what the problem is. There are also more changes needed to support Remote 2.0 properly, so this will take some time. Remote 2.0 also introduces support for the iPad, with very different features and new requests. I don t have an iPad, so this won t be supported. For now, you should stick to the old version of Remote (1.3.3) until we get 2.0 working, at which point we ll probably pull support for the previous version in an attempt to maintain everybody s and the codebase sanity. In other news, I have a few changes pending that I want to get in before I cut a new release.

does it? You might have read elsewhere that Debian has squeezed out Chromium. As of today, Debian has also squeezed Chromium back in. Does that mean that Debian Developers change their mind too often? Surely not. Rather, it means that the noise around the "squeeze out" has been a bit exaggerated and it would be similarly exaggerated to make noise about the "squeeze in" now. To avoid being incoherent with the latter intention, let me move to my main point here. As I've commented yesterday:

The lesson to learn here is that, as long as Squeeze (or any other Debian suite, FWIW) is not released, there is still a margin of variability in the software it contains. If that margin weren't there, then the suite would have been released in the first place. The point of a freeze, in Debian, is to stop package acceptance in the suite by default and undergo a thorough scrutiny of what goes in and what gets out.

Such a scrutiny helps stabilize a release fixing RC bugs affecting it and improves Debian quality. You really need to thank the Release Team for such a thorough scrutiny work. In "exchange" for that, you might also want to take part in the Debian gift economy by help fixing RC bugs: do NMU if you are a DD, provide patches if you are a developer, help triaging bugs if you are a user, organize a Bug Squashing Party if you have organization skills, etc. Those are the activities that will boost the Squeeze release.

The Backports Team is pleased to announce the availability of a new suite on backports: lenny-backports-sloppy. Please read carefully before considering using or uploading to it what this entails. The Background You might want to ask: What's that? Let me explain it. During the etch release discussions popped up on the backports list with two clashing groups:

• One that expected to always be able to upgrade from sarge + sarge-backports to etch without backports,
• others that wanted new versions of packages flowing in even after the release and were happy to upgrade from sarge + sarge-backports to etch + etch-backports.

The standing at that time was to accept packages that were in testing after the release, which wasn't etch anymore but lenny. The same discussion started again before the lenny release, and given that we are facing the upcoming squeeze release we started internally to discuss how to noise down these long and tedious discussions, because both groups of people had valid opinions that shouldn't get ignored. So this is where the idea for lenny-backports-sloppy comes from. The Change lenny-backports-sloppy will please the group that is happy to upgrade from lenny + lenny-backports to squeeze + squeeze-backports. lenny-backports is meant only for packages from squeeze, even after the release. Technically that means it will get locked down for uploads after the release of squeeze and require manual approval (for e.g. point release update versions, or security updates that happen during the squeeze release cycle), while lenny-backports-sloppy will accept packages from wheezy. Uploading to lenny-backports will have to get approved by the Debian Backports Team after the squeeze release, just like uploads to lenny are currently approved by the Release Team. While lenny-backports-sloppy is created already and working we ask you to not upload packages there without prior discussion with the Backports Team. This is meant to ensure that the Uploader is aware about the expectations that come along with that: The package should have a good chance to get included in the next Debian release aka wheezy, and that the Uploader is willing to look after the package in the upcoming squeeze-backports suite after the release of squeeze to ensure upgradability. In case of questions, feel free to ask either directly on the debian-backports@lists.debian.org mailinglist, or contact team@backports.debian.org privately. We are also pleased to announce that the first upload to lenny-backports-sloppy already happened. From now on you will be able to install Postgresql 9.0 (which is not targeted at squeeze) from lenny-backports-sloppy. How to use If you want to use lenny-backports-sloppy you will have to add both lenny-backports and lenny-backports-sloppy to your sources.list. Backports from lenny-backports-sloppy may depend on packages in lenny-backports.

  deb http://backports.debian.org/debian-backports lenny-backports   main
  deb http://backports.debian.org/debian-backports lenny-backports-sloppy main

About Backports You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in. Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. It is recommended to pick out single backports which fit your needs, and not to use all available backports. Thanks for reading this far, and enjoy!
Rhonda in the name of the Backports Team

/debian permanent link Comments: 1