Last night was the kick-off concert in a series the Chicago Symphony has been preparing (and pushing) for the last little while: United Sounds of America: A Journey through Musical Roots. Five concerts featuring New York (last night), Chicago/Route 66 (tonight), New Orleans (tomorrow), Detroit (next Friday) and Austin (next Saturday). The New York evening was organized by pianist Bill Charlap (wikipedia) who also headlined and MC-ed the first set. Covering the birth of Jazz until early post-war bebop in chronological fashion, it was a pretty decent jazz set with a very nice band featuring Kenny Washington (dr), Peter Washington (b), Jeremy Pelt (tp), Jimmy Greene (ts) and Ken Peplowski (cl) --- and local favourite Kurt Elling (wikipedia) who was simply outstanding with the classic songbook material. Having seen him live once before a few years ago, I happened to listen a lot to Elling of late, following the random find of this stream from a live concert in February as well as his two most recent records, the Grammy-winning Dedicated to You (which retakes the wonderful Coltrane/Hartman album from 1963) and the simply amazing very recent The Gate (which you should go and buy right now). And I was not disappointed. He has a great four-octave-spanning baritone voice and great stage presence. The second set was dedicated to post-war folk and singer/songwriter material and organized by Suzanne Vega. That was neat too, if somewhat different in format and more like your standard (rock-ish) concert. Vega brought her own band featuring Gerry Leonard (g), Mike Visceglia (b), Graham Hawthorne (dr) along with guest appearances by Tom Paxton (g, vocals) and Richard Julian (g, vocals). Somehow Vega seems a little trapped in her own success in the 1980s and rehashed a lot of old hits. Nothing wrong that per se as it is good material (more on that below). Only during three encores did she provide new material which was ... excellent. So maybe some rebalancing towards new stuff was neat. Also nice was the additiona of four string players from the Chicago Symphony which had joined the band for a Simon and Garfunkel's song The Boxer. Oh, and of course seeing Vega perform Tom's Diner was nice, especially in such a fast and rocking version, even enhanced by the those strings. Just a few months ago I had gone over the passage from the original a-capella version of Tom's Diner to the various beat-box remixes which were then remixed by Vega in various live performances (e.g. videos of a capella, rockish, another rockish and beatboxish versions). Good fun, and it is nice to see she is playing along and enjoying it as well. All told, a really nice iniative by the CSO. If you're in Chicagoland, go and see some of the remaining shows.

It's been a long time since I last took some time to read First Monday A great online publication, if you are not familiar with it, that I would categorize (and no, I'm not probably well-informed in it to be authoritative) as dealing with social, psychological aspects of the cultural shifts the online world has brought upon us (often dealing with topics related to Free Software communities, the reason I first met the publication). Firstmonday is an Open Access champion from early on. It follows an approachable but academic format (this means, it is peer-reviewed, its articles give extensive lists of references, and the articles are not the short reads we have got used to finding on the net, but, quoting from their audience profile, English is not the first language of many First Monday readers; A large percentage of First Monday readers are not a part of academia; Cultures, educational backgrounds, and fields of study vary greatly among First Monday readers.) This means, it's at least a great publication for me to follow :) Anyway After a long time not following it, I have just read Reading revolutions: Online digital text and implications for reading in academe, by Barry W. Cull; First Monday, Volume 16, Number 6 - 6 June 2011 Nice, interesting read. As I was planning on telling about the article to a couple of friends more into the subjects than myself, I'll comment+quote some bits on it. Before going any further: The article makes several references to Maryanne Wolf. No relation to her I'm not lulling my (two? are you both still reading?) readers towards her work ;-) The article talks about the differences social, even dips into some physiological aspects that the activity of reading is sustaining due to the shift from an activity done mainly from books (or other similar printed material) to the computer screen. Of course, we all know from our own experience many of the basic traits Shorter attention spans, a different reading pattern (skimming instead of reading; browsing through several related items instead of in-depth reading a single text as a knowledge unit). The article begins with an overview of reading and humankind. Cull quotes Maryanne Wolf's phrase, despite the fact that it took our ancestors about 2,000 years to develop an alphabetic code, children are regularly expected to crack this code in about 2,000 days . An interesting point I never thaught of is the start of reading as a purely mental activity, detaching reason from verbalization, ~1200 years ago:

Interestingly, these early scribes first did their work by reading out loud to themselves. Not until the ninth century did monastic regulations begin requiring silent reading. By the thirteenth century the practice of men reading silently and alone became commonplace. This shift to silent reading was a profound change, one that Darnton suggested involved a greater mental adjustment than the shift to printed text

. One last important point in this older history, that I'm quoting because I know I'll need the reference later on for one of my texts is about reading as a social activity Yes, also related to the quietness I just mentioned:

Interestingly, with the democratization of the printed text, there was a return to reading aloud. Reading was a solitary silent process only for the educated elite who could afford to buy books. For the rest of the population, as Darnton pointed out, reading was a social activity which took place in workshops, barns, and taverns [and] while children played, women sewed, and men repaired tools.

After this introduction (obviously one of the most interesting parts to me), Cull gives numbers showing how reading is evolving (in the USA and Canada), and quotes some prediction on how the future will end up adapting. Of course, I live in a place with a very different society, so I cannot comment much. Then he confronts some studies regarding specifically leisure reading, as it is a much more trustable factor than just literacy (in a world as highly literate as ours is, many people only read when they have to and have never or very seldom experienced the pleasure of reading just for the sake of it), bringing into the discussion the Internet (and computers in general) usage patterns. I found also very interesting the next section, regarding the pattern changes many libraries are facing now, specially academic/research-oriented libraries:

For several millennia, right up until just two decades ago, the central role of a library was to collect and house physical texts: from clay tablets, to scrolls, to printed books (Battles, 2003; Manguel, 2006). While printed text remains essential to most academic libraries, today s libraries have also become a core conduit via which researchers access scholarly texts online. Just within the last few years, Canadian academic libraries, in a situation similar to libraries throughout the Western world, have reached an interesting tipping point librarians now spend the majority of their collections budgets on electronic instead of printed texts.
( )
Libraries are convinced that digital text, now in its infancy, is likely to have a long future. Not only do they purchase electronic texts, but most academic libraries have also become publishers of electronic texts, whether they are digitizing large portions of their book holdings, or focusing on scanning a relatively small number of archival documents from their unique special collections.

And yes, doing some work with our Institute's library, I can confirm this trend. About e-books: I have got quite into that topic since the Kindle won my heart (and my money!) half a year ago. The little device completly changed my reading habits, I have read lots more since I carry it. And yes, I have never considered a full tablet-like device The article talks long about the difference, about the disadvantage that multitasking means to the human brain (oh, do I suffer from it!) I liked this snippet, quoting Steve Jobs a couple of years ago, regarding an Apple e-book reader question:

When Apple was rumoured to be working on an e book reader a few years ago, CEO Steve Jobs expressed his lack of interest: It doesn t matter how good or bad the product is, the fact is that people don t read anymore, he reportedly said, continuing by stating that 40 percent of the people in the U.S. read one book or less last year. The whole conception is flawed at the top because people don t read anymore (Markoff, 2008). Nicholas Carr (2010) has summed up Apple s involvement in the tablet phenomenon this way: Jobs is no dummy. As a text delivery system, the iPad is perfectly suited to readers who don t read anymore .

The issue for me is, I do enjoy reading, but I am an information addict. I know that if I have parallel information flows, my attention will surely dilute between them. Of course, as I read this article on-screen, it was hard for me to take the needed discipline not to be distracted by IMs or IRC highlights during the whole reading (which was also as an excercise for myself ;-) ). I am surprised to see this on student preferences (and even more surprised to see this data comes from my university):

In a study of students at the Universidad Nacional Aut noma de M xico (UNAM), the majority of students preferred print, and 63 percent reported that they could bear reading a document on a computer screen for no more than one hour (Ram rez Leyva, 2003). When it comes to course textbooks, a marked student preference for paper over e books has recently been found (Woody, 2010).

As we approach the end, it talks about another important topics I have often tried (and often failed) to communicate to my users: That of paratext, the meaning of the different texts, covers, items, layouts, etc. that are not part of the text itself but do shape the way we face it. To some of us, this seems obvious. To others, it is so hard to understand It closes with two more topics I will refer to. One is the permanent connectivity. All the time, more people are connected virtually all of their waking time. This affects not only learning habits but priorities. Will this near constant access to information interfere with students desire to comprehend and remember information, necessary to the educational process of turning it into knowledge? Author and university business school lecturer Don Tapscott recently suggested that students might not have to stress about the details those you can check Finally, regarding the continuity and ellaboration found in texts that are each time more common He quotes Maryanne Wolf:

I am worried about kids who are immersed in digital culture. They will get to college and they will have been Twittering so much that they won t have the patience to read those really long cognitively convoluted and complex sentences. They may not have developed those rich networks which are required in order to read at a high level of sophistication. The effort is what we are going to lose. They are becoming not so much a lazy reader, but an atrophied reader

As you can see, not only this post is meant to tell my couple-of-interested-friends to read the article, but it's mainly meant as a mental placeholder for myself. I will be surely refering to some of these items.

Philipp is a Debian developer since 2005 and a member of the release team since 2008. Since he took the responsibility of Stable Release Manager, the process has evolved for the best. I asked him to explain how the release team decides what s fit for stable or not. His work on the buildd infrastructure is also admirable but I ll let him describe that. My questions are in bold, the rest is by Philipp. Who are you? I m a 24 year old Computer Science student, living in Karlsruhe, Germany. As a student assistant I m currently in two jobs: one is taking care of getting our university IPv6 network in shape, or rather generally getting fringe technologies into the network. The second is taking care of a s390x machine in the basement which my faculty got sponsored recently. In my spare time I tend my Debian duties and I m active in the student council (Fachschaft) as a sys-admin, software developer and until recently as treasurer. I got accepted as a Debian Developer in 2005. I m only really active since I was invited to join the Release Team in early 2008 after I contributed rewrites of some scripts that got lost in a disk crash of ftp-master. In late 2008 I also took on wanna-build/buildd duties. What s your notable achievement within Debian? For one I worked on the deployment of a single buildd/sbuild combination over all of our buildds and I rebased it on the sbuild in the archive several times already. All buildds basically look the same on all architectures, with only few variations. The chroots are now also created in a mostly predictable manner. Then we finally got build autosigning after years of constant poking. However the policy decision to allow it was made by the ftp-masters anyway, for which I m grateful, as it eases the workload of the buildd maintainers, the Security Team and the Release Team quite a bit. On the release side there s the integration of volatile into the proper structures of Debian. But there I m guilty for choosing the bad name squeeze-updates is, in comparision with security s squeeze/updates. Let s see if we can improve that for wheezy. The policy for stable updates have changed over time. Can you summarize what kind of updates are allowed nowadays? All the changes that were made to the policy were driven by the aim to keep stable (and to some lesser degree oldstable) usable throughout its lifetime. I have to admit that we got slightly more liberal in what we accept since I took over. The previous stable update policy included the fixes of critical bugs that break the system in interesting ways and security fixes. We also opened up the possibility of including important fixes for annoying bugs on a case-by-case basis. The whole don t update that much part of the stable release management is rooted in let s don t change the behaviour of a running system and let s have as few regressions as possible . We currently try to counter that with a review process that only allows self-contained fixes that were tested in unstable first, if applicable. In the future I d also like to have a feedback process that includes the users of the packages to report problems more early. In fact that s also why we now send calls for testing to debian-stable-announce one week in advance (see this mail as an example). So stable is updated through point releases that happen roughly every two months for stable and roughly every four for oldstable. They are accompanied by announcements and new CD/DVD sets. To be able to push some updates with less delay to our users and to avoid that they have to pick them from proposed-updates, there is stable-updates. The current policy for this suite is available in this post on debian-devel-announce. It boils down to everything urgent like tzdata, regression fixes and volatile packages. We noticed that some packages in stable just weren t useful anymore when they got updated through volatile. Hence those are folded into stable, too. We also relaxed the rules a bit so that leaf packages like clive, that rely on external websites not to change their URLs, can be updated too. If somebody wonders what happened to the and a half releases Those were intended to mark the inclusion of new hardware support (mostly by including a co-installable new kernel version). This kind of flag point release is thankfully no longer needed because our marvellous kernel team now backports certain hardware drivers to the kernel version in stable. They have some trouble soliciting test feedback for them, though. It would be cool if more people using stable could respond to their calls for testing. What are your plans for Debian Wheezy? Luckily the wanna-build/buildd side isn t much dependent on release cycles. The stable release management also just takes care of what gets dumped on them by the testing RMs. The near-term goals are certainly:

• getting d-i to use some development process in the archive that s compatible with the normal flow of packages into testing and
• hopefully getting wanna-build to use a sane SQL layout and hence better performance

Apart from that my work is mainly squashing the bugs on buildd.debian.org for the wanna-build part, so if you want something fixed, you need to report it, I m afraid. You have several roles within Debian, in particular stable release manager and member of the wanna-build team. Which role do you enjoy more and why? So the regular duties of the SRM, apart from setting up policies, are reviewing requests for uploads to proposed-updates, accepting them, chasing builds and scheduling point releases. It s mainly steady work. As for the Release Team it s working in a fabulous team where everyone s doing an awesome job. For me the wanna-build role is holding the things together and fixing up stuff that breaks while the world continues to evolve. And occassionally taking a stab at the ftp-masters. So rather different. My heart is probably siding with the buildd side because it s infrastructure but release work is fun, too. What s the biggest problem of Debian? Mainly that we re not quick in picking up new technologies and that we got slow on innovation. Distro-wide changes are usually a very big effort to coordinate and to finally complete. I guess people should be able to push fixes for release goals more eagerly into the archive. Also it seems to me that many DDs are actually disengaging from the release process, especially during the freeze but also before, which makes me a bit sad. However I m still not sure how we could counter that. As we re all volunteers you can t suddenly make others love the idea of releasing something together, I guess. Do you have wishes for Debian Wheezy? It s getting old, but there s certainly multiarch. Also a usable Python 3 is something I d really appreciate. Is there someone in Debian that you admire for their contributions? Peter Palfrader did an awesome job of getting a nicely working team together for DSA and got many tasks as automated as they are now. It s a pleasure to work with them and setting up a new buildd is, for example, a real breeze. He also developed a sane archive snapshot service, kudos for that.

---

Thank you to Philipp for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

A random co-worker was looking for someone to look after her son's pet gecko for 5 weeks while they went to Hawaii, and I thought it'd be something fun and non-permanent to do, so we now have a female 1 year old Afghan leopard gecko named Speck, and a large supply of crickets in our possession. I note that the Wikipedia page is lacking a photograph. We might have to try and fix that...

Just added a TDeb test build branch for multistrap to test out the changes in the next version of the emdebian-tdeb binary package - specifically:

Move em_installtdeb into the emdebian-grip-server package so that the emdebian-tdeb package can be slimmed down to only contain what will become useful for other maintainers to use in their debian/rules files and for translators when the time comes to implement DEP-4. CDBS rules / patches to follow... bug reports against dpkg and debhelper to follow ...

DEP-4 itself is being restarted and refreshed but with some problems on alioth currently, I'm going to (try and) keep the document up to date via SGML and people.debian.org.

The changes are now in Emdebian SVN and I'm starting testing with my own packages first. Multistrap for PO and po4a-build testing, dpkg-cross for debconf testing, some others for testing with build systems other than CDBS, then the discussions will restart on debian-devel and I'll upload the TDeb support scripts to unstable.

There are a variety of things which need to happen before these scripts become useful, including:

• dpkg support for XC-Package-Type: tdeb
• debhelper support for dh_gentdeb,
• inevitable bug fixing in emdebian-tdeb

Why is the package called emdebian-tdeb? Simple - that's where the scripts have lived until now and the hope is that dpkg-gentdeb can migrate into dpkg-dev and dh_gentdeb into debhelper - eventually.

By all means play with the scripts and follow the example multistrap branch above to see what kind of changes might be needed in your own packages. I'll post again when I've worked out the changes needed in packages like dpkg-cross which only need TDebs for debconf support. (This is the easiest mode of TDeb usage but it's also the most useful during a release cycle - maintainers make a single change and then a nominated i18n boss-person - take a guess who - can update the all your debconf translations in one upload without a binary build - eventually possibly not even needing any bug reports, just a simple email advance warning.

What I've got to work on still is how the generation of an updated TDeb creates a new debian diff / debian.tar.gz to accompany the upload. For that I need XC-Package-Type: tdeb support in dpkg....

Sample output from the viewpoint of a translator updating a package already converted to support a TDeb:

neil@sylvester:tdeb-test$ dpkg-gentdeb -t

Set the changelog message to version 2.1.15+t0 first, closing any relevant bugs!

 dch -v 2.1.15+t0 

neil@sylvester:tdeb-test$ dch -v 2.1.15+t0 TDeb test

neil@sylvester:tdeb-test$ dpkg-gentdeb -t

Building TDeb update: 2.1.15+t0

 (192 entries)

Discard doc/pod/1/da/multistrap (65 of 177 strings; only 36.72% translated; need 50%).

Discard doc/pod/1/da/device-table.pl (5 of 19 strings; only 26.31% translated; need 50%).

Processing untranslated files for pod/multistrap (1) . . .

Processing untranslated files for device-table.pl (1) . . .

Processing de translations for pod/multistrap (1). . .

Processing de translations for device-table.pl (1). . .

Processing fr translations for pod/multistrap (1). . .

Processing fr translations for device-table.pl (1). . .

Processing pt translations for pod/multistrap (1). . .

Processing pt translations for device-table.pl (1). . .

dpkg-gencontrol -pmultistrap-tdeb -Pdebian/multistrap-tdeb -cdebian/control

dpkg --build debian/multistrap-tdeb ../multistrap-tdeb_2.1.15+t0_all.tdeb 

dpkg-deb: building package  multistrap-tdeb' in  ../multistrap-tdeb_2.1.15+t0_all.tdeb'.

neil@sylvester:tdeb-test$ dpkg -c ../multistrap-tdeb_2.1.15+t0_all.tdeb

drwxr-xr-x root/root         0 2011-06-08 21:06 ./

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/pt/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/pt/LC_MESSAGES/

-rw-r--r-- root/root      6427 2011-06-08 21:06 ./usr/share/locale/pt/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/vi/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/vi/LC_MESSAGES/

-rw-r--r-- root/root      6963 2011-06-08 21:06 ./usr/share/locale/vi/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/fr/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/fr/LC_MESSAGES/

-rw-r--r-- root/root      6789 2011-06-08 21:06 ./usr/share/locale/fr/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/da/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/da/LC_MESSAGES/

-rw-r--r-- root/root     16311 2011-06-08 21:06 ./usr/share/locale/da/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/pt/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/pt/man1/

-rw-r--r-- root/root     33963 2011-06-08 21:06 ./usr/share/man/pt/man1/multistrap.1

-rw-r--r-- root/root      4471 2011-06-08 21:06 ./usr/share/man/pt/man1/device-table.pl.1

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/vi/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/fr/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/fr/man1/

-rw-r--r-- root/root     33969 2011-06-08 21:06 ./usr/share/man/fr/man1/multistrap.1

-rw-r--r-- root/root      4708 2011-06-08 21:06 ./usr/share/man/fr/man1/device-table.pl.1

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/da/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/da/man1/

I'm also going to DebConf11



On the RoadTrip! all the way hrough France, Belgium, Netherlands, Germany, Austria, Slovenia, Croatia, Bosnia-Herzegovina (Banja Luka) in an MX5.

I've got a lot of things to talk to people about @ DebConf this year... you won't be able to tell if I'm just buying you a beer or trying to badger you about your packages!! Just note that TDebs have been already agreed (in terms of how TDebs work in the archive) with ftp-master at a previous meeting in Extremadura and I'm being badgered by a Release Manager and an ex-DPL to get TDebs implemented real soon now, so it is going to happen and hopefully in time for Wheezy - it's just a matter of fixing the bugs. The quicker everyone has a look at the new scripts (which have been completed re-written and immensely simplified since I first tried a dumb conversion of em_installtdeb) and the likely changes needed in packages, the quicker I can get the bugs out of the scripts.

More documentation to follow, I'll be updating the SGML whenever practical and the actual DEP just as soon as I get commit access back.

It s been a few months since Zack and I announced the DEX project, which aims to improve the Debian ecosystem by working jointly with derivative distributions. Our first milestone The goal of our first project, nicknamed ancient-patches, was to clear out an old batch of a few hundred Ubuntu patches whose status was unclear. We couldn t tell which ones had been merged into Debian, which were waiting in the BTS, and which had yet to be submitted to Debian. All of them were several years old. I m pleased to announce that this project is now complete. Thanks to help from David Paleino, Colin Watson, Nathan Handler and Steve Langasek, we were able to clear over 95% of the patches in a matter of days. These were the easy ones: patches which were obsolete, or had already been applied. We discussed the remainder, and resolved all of the patches whose status was still unclear. This left the harder ones: patches stalled in the BTS, and patches where there was no consensus about what to do with them. One of the stalled patches was merged into Debian via an NMU, eliminating the delta between Debian and Ubuntu. Another had been submitted to Debian by a third party, but was no longer shipping in Ubuntu, so we considered it obsolete for purposes of this project. This has left only two patches out of the original list of 277. Both of them are filed in the BTS and have been discussed with the relevant maintainer team. One of them is expected to be obsoleted when a new upstream version is packaged, which implements similar functionality. The other is being discussed with the upstream developers, but there is no conclusion yet about whether it can be merged upstream or in Debian. Conclusions Although we weren t quite able to clear the whole list, we still consider the project to be a success because:

• We ensured that all of the patches received due consideration for inclusion in Debian
• We proved the concept of DEX, with developers from Debian and derivatives cooperating on a common goal and sharing tools
• Most importantly, we learned from the experience

What s next In the most recent DEX update on debian-derivatives, I highlighted a few important events for DEX:

• Our second major project, nicknamed big-merges , will begin soon. Our goal is to identify the few packages which are most diverged between Debian and Ubuntu, and work to get them as close to identical as possible. If you have suggestions for packages to focus on, let us know!
• Allison Randal is beginning a DEX project to implement the Python 2.7 transition across Debian and Ubuntu
• Nathan Handler is working on a Summer of Code project to develop specialized tools to help with this kind of cross-distribution teamwork
• Zack is organizing a derivatives BoF at DebConf 11

We re looking forward to seeing DEX develop further. If you d like to get involved, come and join us on the debian-derivatives mailing list or IRC (#debian-derivatives on freenodeOFTC). Matt Zimmerman and Stefano Zacchiroli

Disclaimer: There is a huge discussion going on right now in the debian-devel mailing list, about different ways to rearrange how Debian development happens, and maybe to provide a Debian users with an additional release. This blog entry is not a comment on that discussion, which I am ignoring. The discussion did, however, prompt a dent about "test driven development". That prompted a short exchange of thoughts with Tom Marble, and this blog post is a cleaned up version of my part in that discussion.

Currently Debian development happens roughly like this: all packages are uploaded to a part of the Debian archive called unstable. Once they've been in use for a while without serious problems, they get automatically copied into another part called testing. Every year or two, testing is frozen and any remaining problems are fixed, after which all of testing gets copied into yet another part of the archive called stable, and that's the actual release. There is a little bit of automatic testing, but only a little. Almost all testing is done by people, by them using unstable or testing on their usual computers. If they have problems, they report them. Contrast this with development using Test Driven Development, or TDD, and other modern development methodologies. Here's a rough summary of what I do when I write (much) of my software.

• first write one or more automatic tests (unit or functional ones)
• write the actual code, enough to make all tests pass
• add more tests
• write more code, or change existing code
• repeat this until tests describe all the behavior desired of the code

In addition, I measure coverage to make sure all parts of the code gets tested. I usually aim for 100% coverage, except for those parts that very hard or quite pointless to test. (That's easier to achieve than you'd think, but that's the topic of another blog post.) This all sounds like a lot of bureaucratic nonsense, but what I get out of this is this: once all tests pass, I have a strong confidence that the software works. As soon as I've added all the features I want to have for a release, I can push a button to push it out. (Well, actually there's a little bit more to it.) This does mean I never have bugs in my software. Of course I do. However, there's a lot fewer of them. In fact, there's so few of them, after tests pass, that I would almost be happy to make an automatic release after every successful run of "make check". Another aspect of the way I do development is distributed version control. The relevant feature is powerful branching and merging. Most things I develop happen in short-lived single-purpose branches: whenever I start work on a feature or bugfix, I create a branch for it. (Unless I'm feeling particularly lazy, which happens more often than you'd think.) When I've finished the feature, or fixed the bug, I merge the branch back into the trunk branch. This way, the trunk is always in releaseable state. It might not have all the features I want for the next release, but the features that are there, do work. The branch probably has bugs, but if I've written tests that are good enough, I know the software works well enough. Or that's the idea. Sometimes things go wrong. Then I write more tests and the next time goes better. (It doesn't have to be perfect, as long as it gets better every time.) See the contrast between automatic tests with good coverage, and the Debian style of relying on user feedback? There's no need to wait for user feedback with automatic tests. This speeds up development, makes releasing easier, but most importantly takes away any reason to fear making changes, even big changes. Automatic tests and good test coverage are easy achieve in small projects. For a system as huge as Debian, good test coverage is quite hard to achieve. The thing about automatic tests, though, is that even a little bit of it is helpful, and after you have a few tests, it gets easier to add more. The first test is the hardest to get done, since you need to set up all the infrastructure for it. Debian does do a bit of automatic testing already. (See lintian, piuparts, autopkgtest, edos, etc.) I don't want to belittle that, but I think we could do better. Here's what I would love to see:

• we have a part of the archive that corresponds to a trunk branch, i.e., it is always in a releasable state (the "testing" area was originally meant to be that; we could make it so now)
• releaseable state is determined by two things:
  • an automatic test suite
  • user feedback, particularly in the form of bug reports (as now)
• whenever changes are made, they happen in "branches"
  • the branch is not affected by changes elsewhere in the archive, except by manual synching ("merge from trunk")
  • individual package uploads, as well as groups of packages such as for transitions, are each in their own branch
  • this is sort of similar to a PPA, but more powerful
• when a branch is to be merged into trunk, the automatic tests must first pass (or at least no new failures in them can be introduced)
  • tests can also be run for any other branch, of course, so that those developing the branch know if they're ready to push their changes into trunk
• there's a culture of writing tests for bugs (whenever that is feasible), and for new features
  • particularly release goals should be expressed as automatic test suites
• there's a culture of sharing tests with upstreams, and with other distributions

Since full test coverage is going to be impossible for Debian, some subset should be targeted. Perhaps something like this would suffice to start with:

• a version of debian-installer is generated from a branch
• test installation of a new system from scratch
  • with a large set of tasks selected
• test upgrade from previous stable release to the branch
  • with a large set of packages installed (as many as possible, actually)
• test upgrade from trunk branch to branch to be merged
  • ditto large set of packages
• test with lintian, reject on specific tests failing
• test with piuparts
• test the whole system for specific functionality
  • ssh access from outside
  • sudo access for a logged in user
  • sending mail with SMTP
  • web server
  • possibly test specific web applications
  • possibly test Samba and NFS services
  • possibly test printing services (CUPS)
  • possibly test essential desktop functionality (automatic login, at least)
• if package comes with package specific tests, run those too

These tests would not guarantee that a set of changes would not break Debian, but they would give a high confidence that at least basic stuff would still work after the changes. Now, obviously implementing all of this I'm dreaming of (it is just past midnight, after all) is going to be impossible. There's way too much work to do, there's not enough tools for writing tests, and it would require too much computing power to run, and so on and so forth. But it's late, and I've had a bad day, and I might as well dream of something nice. Anyway, anyone interested in these things should perhaps help drive DEP8.

I m just back from spending a few days volunteering with the tornado recovery effort in Joplin, MO. The biggest image that remains in my mind is of the first time I saw a person picking through a large pile of rubble. The person was standing on top of what used to be a house. Now it was a pile of wood, glass, carpet, siding, and roofing material. I m sure there was hope for finding some treasure or other maybe a photo album or videos of children. In any case, it made me feel so lucky, even unfairly lucky, to have not had to go through that. This scene was repeated several times, but mostly the houses that devastated appeared abandoned by the time we were there, now two weeks after the event. But I heard stories, and lots of them. The victims of the storm, who were perhaps trying to rebuild that part of their house that got smashed by a tree or a pickup, or trying to get their intact belongings out before abandoning the house, or whatever, were mostly surprisingly upbeat. They were working out in 95-degree heat, many without electricity, running water, or sewer service. Almost every person I met that suffered a loss from the tornado wanted to tell their story. Many also told of their plans for the future, which were full of hope and even upbeat. These were people doing a hard job in terrible conditions and still showing hope. Another testament to the disaster was the most unusual set of vehicles you ve ever seen parked at any hotel you can care to think of, for at least an hour-and-a-half radius in the direction I came from. Besides the usual cars and minivans, there might be FEMA vehicles, electric company trucks, Red Cross vans, construction trucks of every kind, police and law enforcement from all over, etc. There was quite obviously an influx of people helping out in Joplin. My primary task there was to provide communications support for the effort as an amateur radio operator. Amateurs (or hams ) are something of a volunteer first responder of sorts during times of crisis; most of us own and are very familiar with operating equipment that can communicate over very long distances without the need for any on-site infrastructure. Amateur radio was the only method of communication for some Joplin hospitals in the immediate aftermath. The communications emergency is over, but the response isn t. I was assigned to work with the Salvation Army. They were doing a lot of things in Joplin, and had hundreds of volunteers working with them. I don t think I even know what many of them were doing I do know they had set up several warehouses across the city working with donating clothing, food, etc. The part I was involved with was primarily the canteen operation. The SA sent in food service trucks from several parts of the country. These trucks would roam up and down the streets in the damaged area, trying to get past every single street several times a day. Anybody that we could see would be offered food and water. No strings attached, no questions asked. This included homeowners, electric line workers, construction crews, sanitation workers, and quite a few nonprofit groups that sent well-meaning and useful volunteers into the area but didn t think to provide them with a large supply of water due to sending them into an area without any. Oops. In any case, with extreme heat and no running water, conditions were dangerous. The canteens also knew of certain at-risk families that were living in homes that were mostly intact in the disaster areas, and made a special point to check in on them. They also generally looked to make sure that people looked like they were healthy. Each canteen also had a counselor on board that would visit with people while we quickly prepared their meal they all seemed to welcome that. Amateur Radio s Role The operation of this size had quite a logistics challenge. I d hear of things like an unexpected need of 70 lunches, or a semi showing up with donations before there was space, or an unexpected but very welcome donation of a large quantity of ice cream without a place to store it (so the canteen trucks, which have freezers, needed to pick it up quickly). That s where us hams came in. Each canteen had an amateur radio operator on board. Each major location also had a ham stationed there, and the head of operations also often had a shadow a ham that would follow him around wherever he went to relay messages back and forth. We also had hams with pickups (with radios in them, of course) that could transport things around the city to places that needed them, hams at headquarters managing all the communication and generally investigating questions that didn t have immediately obvious answers, etc. Radios were used instead of cellphones for a few reasons. One big one is that everybody on the operation can hear what everyone else s needs are, since it s a group communications situation rather than one-to-one. It s easy to give a general alert to everyone ( come get your ice cream now please! ) and people that have suggestions can chime in. This came in extremely handy more than once. Also, it frees the people doing other jobs from having to spend time chasing someone s voicemail, finding phone numbers, etc; that gets delegated to us in some cases. I heard from the head of canteen operations, for whom this was the first disaster he d worked that had amateur radio support, how wonderful it was to have this going on. I also heard a secondhand report that some police officers that were also amateurs had listened to our operation and reported that we sound more professional than 911 dispatch and do a better job. On Sunday I was assigned to a canteen. This meant I didn t have a lot of radio traffic to pass, so although I had it in my ear all day, I wasn t actively talking on the radio very much. So I rode in back, helping hand out water, carry meals to people, and so forth. On Saturday, I was the shadow for the head of operations. That was a difficult task, because he barely ever moved at a pace slower than a run, sometimes would abruptly zip out somewhere, etc. But it was also enlightening and vital. He was a real get it done sort of guy, and was the key to quite a few things. Having someone available to relay questions to and from him was a good thing. And today I worked as a transport person and at headquarters. Due to not having a pickup there, I didn t actually get called on much to transport things, but in general between jobs the whole time I d act as a runner if needed, or simply try to figure out the details of how things were run for next time. I wound up taking net control (being the control operator at headquarters, and generally managing communications so that people don t talk over each other and such) for about an hour. So I got to do a little of just about every amateur radio task. Thoughts I am thankful for the opportunity to go, and the good feeling of helping people in need the first I ve ever had the chance to do that in a disaster. It s a good feeling to have a skill that is useful and appreciated. Sometimes it felt like handing out food and water is something pretty small in the scheme of things. But on the other hand, it gives people a chance to have contact with someone that cares, an opportunity to have people that can notice problems drive by a few times a day, and an opportunity to help meet people s basic needs. And sometimes in a fluid situation, there might be more volunteers than are needed, so I did spend some time sitting waiting for the next task. But overall, I m convinced that the work I helped facilitate was a good thing and provided a good and needed service in Joplin. This has been quite the experience and I m sure it s changed me too, though I don t yet know how.

DECLARATIVE DIVERSIONS ====================== Introduction A diversion is when it is possible to have dpkg not overwrite a file when it reinstalls the package it belongs to, and to have it put the file from the package somewhere else instead. Declarative diversions involves a new control file with a declarative syntax which dpkg will parse and process directly as part of the package unpack and removal phases, eliminating the problems resulting from non-atomic handling of diversions. Topics There are a number of topics involved in implementing this kind of project * What syntax do we use for the new control file? * What dpkg does with the control file * How do we handle diversions to a non-existant directory? * How do we order unpacking a new package which adds a diversion? * How do we order unpacking a new package that removes a diversion? * How do we order removing a package which had a diversion? * How do we handle errors? * What happens to dpkg-divert? Details - Control File Syntax - It will conform to RFC2822 style with the following format: * Divert-From: * Divert-To: * Blank lines and lines beginning with # will be comments Divert-To will be optional and if it is ommitted then files being diverted will have their filename changed to file.distrib The above style has it s advantages, one of the main ones being that there is no need to escape whitespace within filenames. It also allows for more commands to be added at a later date. Details - Control File Handling - Within control.tar.gz the file should be named diversions This file is then copied to /var/lib/info/$package.diversions We need to store the control file for the currently-installed package so that we can detect declarative diversions that have been removed from the control file between versions (On-disk version and the to-be-unpacked version). If there is no previous version of a control file then all current diversions within the package are left in place and any new ones declared within the control file are added. If there is a previous version of the control file then the diversions listed within the file are compared with the diversions currently in place. If a diversion exists that is no longer listed in the control file then it is removed. If there is a diversion listed in the control file that doesn t currently exist then it is added. Details - Handling Diversions to non-existant directories - Diverting files to directories that don t exist can cause a number of problems. If the package does not own the directory it may be left orphaned on removal of the package The package is responsible for ensuring the availability of the target directory in the unpack phase. If a declarative diversion attempts to divert a file to a folder that neither exists already on the filesystem at unpack time, nor is shipped within the package, dpkg will return an error at unpack time. Details - Ordering Requirements - =>Unpacking a new package that adds a diversion *1. Check if package has a previous diversion control file *2. Copy control file to tmp directory *3. Calculate diversions to be added *4. Unpack folders *5. Add diversions *6. Unpack files *7. Copy control file to /var/lib/dpkg/info/$package.diversion *Performing diversions this way avoids trouble with creating folders and accidentally overwriting the wrong version of files. *Another major problem would be extracting a new version of the file and overwriting the old one. *This might cause the wrong version of the file to be diverted and the package to break. =>Unpacking a new package that removes a diversion *1. Check if package has a previous diversion control file *2. Copy control file to tmp directory *3. Calculate diversions to be removed *4. Check if dropped diversion results in a file conflict and abort the unpack if it does. *5. Unpack folders *6. Unpack files *7. Remove old files no longer needed in the package *8. Remove diversions *9. Copy control file to /var/lib/dpkg/info/$package.diversion *If a package has no previous diversion control file then no diversions will be removed and existing diversions can only be removed using dpkg-divert. *If removing a diversion results in a file conflict then dpkg will return an error at unpack time before anything is unpacked and the unpack is aborted. =>Removing a package which had a diversion *1. Remove files *2. Remove diversions *3. Remove folders *4. Remove control file at /var/lib/dpkg/info/$package.diversion *This ensures that all files, diversions and folders are removed correctly Details - Error handling Errors in diversions will have to handled with a great deal of care due to the fact that if they are not the package could be broken. This means that a great deal of checks must be done to ensure that all the files can be diverted properly before any actual diverting takes place. If they can t the package installation/update must be stopped and rolled back to avoid the package being installed incorrectly or broken. Details - dpkg-divert - When we impliment the new diversion method we should keep the current dpkg-divert. This allows maintainers to catch up with the new method without breaking their packages. It also allows maintainers to perform some operations that aren t support by the new method. All current functionality of dpkg-divert will be left intact for use by sysadmins and for maintainers to catch up with the new system. The two systems will work together without directly conflicting with each other. Example Usage #1 The file to be diverted is /usr/share/foo It needs to be moved to /usr/share/bar The syntax of the control file would be: #Start File Divert-From: /usr/share/foo Divert-To: /usr/share/bar #End File Example Usage #2 In this example the maintainer doesn t want to move the file to any specific folder The syntax of the control file would be: #Start File Divert-From: /usr/share/foo #End File This would divert the file to /usr/share/foo.distrib Footnotes - RFC2822 Guide: * http://www.faqs.org/rfcs/rfc2822.html First Email Thread on Declarative Diversions (First Message in Thread): * http://lists.debian.org/debian-dpkg/2011/05/msg00102.html Email thread on first design draft (First message in Thread): * http://lists.debian.org/debian-dpkg/2011/06/msg00019.html Declarative Diversions Wiki: * http://wiki.debian.org/SummerOfCode2011/DeclarativeDiversions My Blog for this Project: * http://blog.sam-dunne.com

(First posting to Pl net Commandline! Tag: pcli) Vutral asked in IRC how to synchronise two shells environment while they re running. As you may know, POSIX systems cannot change a process environment vector after it has been started, only the process itself can. Well, the shell can, and we ll use a variety of things for this. This trick assumes you have $HISTFILE set to the same pathname in both shells (obviously, they run under the same user). It uses export -p to render the current list of exported variables, then transforms the list from newline-separated to a single big one-line export statement.
Then it transforms all remaining newlines (which will be part of a single-quoted string, since that s mksh(1) s export format) into the sequence '$'\n'' which means: terminate current single-quoted string, append $'\n' and open up a new single-quoted string immediately; concatenate these three.
Now, $'\n' is just a fancy way of saying newline, and part of mksh because David Korn (yes, the Korn in Korn Shell) strongly suggested to me that this functionality be included but, as we can see here, it pays off.
Finally, the so transformed string is prepended by unset \$(export); which, when executed, will cause the shell to unset (and unexport) all currently exported variables. The shell parameters that are not exported, i.e. not in the environment, are not affected by this code (except for $x and $nl, but whatever).
This string is then passed to read -s (plus -r and clearing IFS to enable raw mode), which means, read into the parameter $REPLY (which we conveniently don t use but it s trashed too, thus) but store into history at the same time. Ah hah! Now, the persistent history feature comes into effect! After running the below statement in the source shell, switch into the terminal running the destination shell, press Enter once on the empty line (Ctrl-U to empty it if it wasn t), then Cursor-Up ( ) to recall voil , an insanely large line with the previously created string sorta expanded and press Enter again to run it. Now your set of exported parameters is the exact same (minus if you exported IFS, nl, x or REPLY) as in the source shell.

I ve added extra spaces and a linewrap below, this is really just one big line:

Of course, this makes a nice function, for your ~/.mkshrc or somesuch.

jffnms 0.9.1 has the database extracts and updates missing from 0.9.0 This is the most problematic part of the project release; ensuring that the database updates correctly. Version 0.9.1 is functionally the same as 0.9.0, it is just with less bugs!

As I write this, it's the morning of June 5th, 1981. A few people scattered across the US are waking up, going in to work, sitting down at their terminal with a coffee, and reading Usenet. Usenet is only getting a trickle of posts each day -- it's still in that period where it's easy to read every message posted to it. Many things lie in Usenet's future. It's still running A-News, which doesn't even have a real From header yet. Later this year it will switch over to B-News, and volume will begin to increase. In 1987 there will be The great renaming. And of course in 1994, the first spam will be posted to Usenet. But that's all a long way off, here in 1981. Right now, they're talking about 500 mb disk drives that only cost $38000. And rms is inciting flames about nuclear proliferation. And Postel is publishing an RFC for the new Mail Transfer Protocol. Good morning, Usenet. Who knows what will come next in this fledgeling electronic communications medium! a ten year real-time historical exhibit This morning, I'm announcing a new site: Olduse.net It's Usenet, updated in real time as it was thirty years ago. Planned to be available for the next ten years, unless I run out of inodes (again). If you missed it the first time around, this is your chance to follow Usenet's flowering. made possible by

• Henry Spencer at the University of Toronto, Department of Zoology, who archived Usenet. Back when it was really uncool and really expensive. Our view onto Usenet is thus slightly centric to Canada and Zoology, but that's ok.
• David Wiseman, who hauled 141 magtapes in a pickup truck.
• Many who worked to rescue data off the tapes. Including from the deleted stuff at the ends.
• Rich Skrenta, who somehow got a copy of the archive out from under the Google borg. Although one of the tar files is truncated. Just saying.
• The creator of Telehack, who pointed me in the right direction, ending my multi-year quest to find the archive. And if you think this is neat, Telehack will blow you away.
• The developers of Haskell, which enabled me to whip up a B-News to C-News converter, a custom uucp, date parsers for every crazy date format ever used on Usenet, and suitible queue data structures in a rock solid, maintainable way, in 500 lines of code written over 12 hours. When I realized I also needed an A-News to B-News converter, I knew it was worth it to have done things right, because that took only 43 more lines, and worked 100% on the first run! My code repository for olduse.net is here.

---

PS: You can post to olduse.net, but it won't show up for at least 30 years. :)

Erich Schubert's blog post reminded me that I've been meaning to writeup a post detailing how I'm keeping parts of my $HOME in git repositories. My goal has been to keep my home directory in a version control system effectively. I have a number of constraints however. I want the system to be modular. I don't always need X related config files in my home directory. Sometimes I want just my zsh related files and my emacs related files. I have multiple machines I check email from, and on those want to keep my notmuch/offlineimap files in sync, but I don't need these on every machine I'm on, expecially since those configurations have more sensitive data. I played around with laysvn for a while, but it never really seemed comfortable. I more recently discovered that madduck had started a "vcs-home" website and mailing list, talking about doing what I'm trying to do. I'm now going with madduck's idea of using git with detached work trees, so that I can have multiple git repositories all using $HOME as their $GIT_WORK_TREE. I have a script inspired by his vcsh script that will create a subshell where the GIT_DIR, GIT_WORK_TREE variables are set for me. I can do my git operations related to just one git repository in that shell, while still operating directly on my config files in $HOME, and avoiding any kind of nasty symlinking or hardlinking. Since I am usually using my script to allow me to quickly "move in" to a new host, I named my script "movein". It can be found here. Here's how I'll typically use it:

    stew@guppy:~$ movein init
    git server hostname? git.vireo.org
    path to remote repositories? [~/git] 
    Local repository directory? [~/.movein] 
    Location of .mrconfig file? [~/.mrconfig] 
    stew@guppy:~$ 

This is just run once. It asks me questions about how to setup the 'movein' environment. Now I should have a .moveinrc storing the answers I gave above, I have a stub of a .mrconfig, and an empty .movein directory. Next thing to do is to add some of my repositories. The one I typically add on all machines is my "shell" repository. It has a .bashrc/.zshrc, an .alias that both source and other zsh goodies I'll generally wish to be around:

    stew@guppy:~$ ls .zshrc
    ls: cannot access .zshrc: No such file or directory
    stew@guppy:~$ movein add shell
    Initialized empty Git repository in /home/stew/.movein/shell.git/
    remote: Counting objects: 42, done.
    remote: Compressing objects: 100% (39/39), done.
    remote: Total 42 (delta 18), reused 0 (delta 0)
    Unpacking objects: 100% (42/42), done.
    From ssh://git.vireo.org//home/stew/git/shell
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .zshrc
    .zshrc

So what happened here is that the ssh://git.vireo.org/~/git/shell.git repository was cloned with GIT_WORK_TREE=~ and GIT_DIR=.movein/shell.git. My .zshrc (along with a bunch of other files) has appeared. Next perhaps I'll add my emacs config files:

    stew@guppy:~$ movein add emacs       
    Initialized empty Git repository in /home/stew/.movein/emacs.git/
    remote: Counting objects: 77, done.
    remote: Compressing objects: 100% (63/63), done.
    remote: Total 77 (delta 10), reused 0 (delta 0)
    Unpacking objects: 100% (77/77), done.
    From ssh://git.vireo.org//home/stew/git/emacs
     * [new branch]      emacs21    -> origin/emacs21
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .emacs
    .emacs
    stew@guppy:~$ 

My remote repositry has a master branch, but also has an emacs21 branch, which I can use when checking out on older machines which don't yet have newer versions of emacs. Let's say I have made changes to my .zshrc file, and I want to check them in. Since we are working with detached work trees, git can't immediately help us:

    stew@guppy:~$ git status
    fatal: Not a git repository (or any of the parent directories): .git

The movein script allows me to "login" to one of the repositories. It will create a subshell with GIT_WORK_TREE and GIT_DIR set. In that subshell, git operations operate as one might expect:

    stew@guppy:~ $ movein login shell
    stew@guppy:~ (shell:master>*) $ echo >> .zshrc
    stew@guppy:~ (shell:master>*) $ git add .zshrc                                       
    stew@guppy:~ (shell:master>*) $ git commit -m "adding a newline to the end of .zshrc"
    [master 81b7311] adding a newline to the end of .zshrc
     1 files changed, 1 insertions(+), 0 deletions(-)
    stew@guppy:~ (shell:master>*) $ git push
    Counting objects: 8, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (6/6), done.
    Writing objects: 100% (6/6), 546 bytes, done.
    Total 6 (delta 4), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/shell.git
       d24bf2d..81b7311  master -> master
    stew@guppy:~ (shell:master*) $ exit
    stew@guppy:~ $ 

If I want to create a brand new repository from files in my home directory. I can:

    stew@guppy:~ $ touch methere
    stew@guppy:~ $ touch mealsothere
    stew@guppy:~ $ movein new oohlala methere mealsothere
    Initialized empty Git repository in /home/stew/git/oohlala.git/
    Initialized empty Git repository in /home/stew/.movein/oohlala.git/
    [master (root-commit) 7abe5ba] initial checkin
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 mealsothere
     create mode 100644 methere
    Counting objects: 3, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 224 bytes, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/oohlala.git
     * [new branch]      master -> master

Above, the command movein new oohlala methere mealsothere says "create a new repository containing two files: methere, mealsothere". A bare repository is created on the remote machine, a repository is created in the .movein directory, the files are committed, and the new commit is pushed to the remote repository. New on some other machine, I could run movein add oohlala to get these two new files. The movein script maintains a .mrconfig file, so that joeyh's mr tool can be used to manage the repositories in bulk. Commands like "mr update", "mr commit", "mr push" will act on all the known repositories. Here's an example:

    stew@guppy:~ $ cat .mrconfig
    [DEFAULT]
    include = cat /usr/share/mr/git-fake-bare
    [/home/stew/.movein/emacs.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/emacs.git' 'emacs.git' '../../'
    [/home/stew/.movein/shell.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/shell.git' 'shell.git' '../../'
    [/home/stew/.movein/oohlala.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/oohlala.git' 'oohlala.git' '../../'
    stew@guppy:~ $ mr update
    mr update: /home/stew//home/stew/.movein/emacs.git
    From ssh://git.vireo.org//home/stew/git/emacs
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: /home/stew//home/stew/.movein/oohlala.git
    From ssh://git.vireo.org//home/stew/git/oohlala
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: /home/stew//home/stew/.movein/shell.git
    From ssh://git.vireo.org//home/stew/git/shell
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: finished (3 ok)
    stew@guppy:~ $ mr update        

There are still issues I'd like to address. The big one in my mind is that there is no .gitignore. So when you "movein login somerepository" then run "git status", It tells you about hundreds of untracked files in your home directory. Ideally, I just want to know about the files which are already associated with the repository I'm logged into.

Erich Schubert's blog post reminded me that I've been meaning to writeup a post detailing how I'm keeping parts of my $HOME in git repositories. My goal has been to keep my home directory in a version control system effectively. I have a number of constraints however. I want the system to be modular. I don't always need X related config files in my home directory. Sometimes I want just my zsh related files and my emacs related files. I have multiple machines I check email from, and on those want to keep my notmuch/offlineimap files in sync, but I don't need these on every machine I'm on, expecially since those configurations have more sensitive data. I played around with laysvn for a while, but it never really seemed comfortable. I more recently discovered that madduck had started a "vcs-home" website and mailing list, talking about doing what I'm trying to do. I'm now going with madduck's idea of using git with detached work trees, so that I can have multiple git repositories all using $HOME as their $GIT_WORK_TREE. I have a script inspired by his vcsh script that will create a subshell where the GIT_DIR, GIT_WORK_TREE variables are set for me. I can do my git operations related to just one git repository in that shell, while still operating directly on my config files in $HOME, and avoiding any kind of nasty symlinking or hardlinking. Since I am usually using my script to allow me to quickly "move in" to a new host, I named my script "movein". It can be found here. Here's how I'll typically use it:

    stew@guppy:~$ movein init
    git server hostname? git.vireo.org
    path to remote repositories? [~/git] 
    Local repository directory? [~/.movein] 
    Location of .mrconfig file? [~/.mrconfig] 
    stew@guppy:~$ 

This is just run once. It asks me questions about how to setup the 'movein' environment. Now I should have a .moveinrc storing the answers I gave above, I have a stub of a .mrconfig, and an empty .movein directory. Next thing to do is to add some of my repositories. The one I typically add on all machines is my "shell" repository. It has a .bashrc/.zshrc, an .alias that both source and other zsh goodies I'll generally wish to be around:

    stew@guppy:~$ ls .zshrc
    ls: cannot access .zshrc: No such file or directory
    stew@guppy:~$ movein add shell
    Initialized empty Git repository in /home/stew/.movein/shell.git/
    remote: Counting objects: 42, done.
    remote: Compressing objects: 100% (39/39), done.
    remote: Total 42 (delta 18), reused 0 (delta 0)
    Unpacking objects: 100% (42/42), done.
    From ssh://git.vireo.org//home/stew/git/shell
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .zshrc
    .zshrc

So what happened here is that the ssh://git.vireo.org/~/git/shell.git repository was cloned with GIT_WORK_TREE=~ and GIT_DIR=.movein/shell.git. My .zshrc (along with a bunch of other files) has appeared. Next perhaps I'll add my emacs config files:

    stew@guppy:~$ movein add emacs       
    Initialized empty Git repository in /home/stew/.movein/emacs.git/
    remote: Counting objects: 77, done.
    remote: Compressing objects: 100% (63/63), done.
    remote: Total 77 (delta 10), reused 0 (delta 0)
    Unpacking objects: 100% (77/77), done.
    From ssh://git.vireo.org//home/stew/git/emacs
     * [new branch]      emacs21    -> origin/emacs21
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .emacs
    .emacs
    stew@guppy:~$ 

My remote repositry has a master branch, but also has an emacs21 branch, which I can use when checking out on older machines which don't yet have newer versions of emacs. Let's say I have made changes to my .zshrc file, and I want to check them in. Since we are working with detached work trees, git can't immediately help us:

    stew@guppy:~$ git status
    fatal: Not a git repository (or any of the parent directories): .git

The movein script allows me to "login" to one of the repositories. It will create a subshell with GIT_WORK_TREE and GIT_DIR set. In that subshell, git operations operate as one might expect:

    stew@guppy:~ $ movein login shell
    stew@guppy:~ (shell:master>*) $ echo >> .zshrc
    stew@guppy:~ (shell:master>*) $ git add .zshrc                                       
    stew@guppy:~ (shell:master>*) $ git commit -m "adding a newline to the end of .zshrc"
    [master 81b7311] adding a newline to the end of .zshrc
     1 files changed, 1 insertions(+), 0 deletions(-)
    stew@guppy:~ (shell:master>*) $ git push
    Counting objects: 8, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (6/6), done.
    Writing objects: 100% (6/6), 546 bytes, done.
    Total 6 (delta 4), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/shell.git
       d24bf2d..81b7311  master -> master
    stew@guppy:~ (shell:master*) $ exit
    stew@guppy:~ $ 

If I want to create a brand new repository from files in my home directory. I can:

    stew@guppy:~ $ touch methere
    stew@guppy:~ $ touch mealsothere
    stew@guppy:~ $ movein new oohlala methere mealsothere
    Initialized empty Git repository in /home/stew/git/oohlala.git/
    Initialized empty Git repository in /home/stew/.movein/oohlala.git/
    [master (root-commit) 7abe5ba] initial checkin
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 mealsothere
     create mode 100644 methere
    Counting objects: 3, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 224 bytes, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/oohlala.git
     * [new branch]      master -> master

Above, the command movein new oohlala methere mealsothere says "create a new repository containing two files: methere, mealsothere". A bare repository is created on the remote machine, a repository is created in the .movein directory, the files are committed, and the new commit is pushed to the remote repository. New on some other machine, I could run movein add oohlala to get these two new files. The movein script maintains a .mrconfig file, so that joeyh's mr tool can be used to manage the repositories in bulk. Commands like "mr update", "mr commit", "mr push" will act on all the known repositories. Here's an example:

    stew@guppy:~ $ cat .mrconfig
    [DEFAULT]
    include = cat /usr/share/mr/git-fake-bare
    [/home/stew/.movein/emacs.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/emacs.git' 'emacs.git' '../../'
    [/home/stew/.movein/shell.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/shell.git' 'shell.git' '../../'
    [/home/stew/.movein/oohlala.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/oohlala.git' 'oohlala.git' '../../'
    stew@guppy:~ $ mr update
    mr update: /home/stew//home/stew/.movein/emacs.git
    From ssh://git.vireo.org//home/stew/git/emacs
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: /home/stew//home/stew/.movein/oohlala.git
    From ssh://git.vireo.org//home/stew/git/oohlala
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: /home/stew//home/stew/.movein/shell.git
    From ssh://git.vireo.org//home/stew/git/shell
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: finished (3 ok)
    stew@guppy:~ $ mr update        

There are still issues I'd like to address. The big one in my mind is that there is no .gitignore. So when you "movein login somerepository" then run "git status", It tells you about hundreds of untracked files in your home directory. Ideally, I just want to know about the files which are already associated with the repository I'm logged into.

DECLARATIVE DIVERSIONS ====================== Introduction A diversion is when it is possible to have dpkg not overwrite a file when it reinstalls the package it belongs to, and to have it put the file from the package somewhere else instead. Declarative diversions involves a new control file with a declarative syntax which dpkg will parse and process directly as part of the package unpack and removal phases, eliminating the problems resulting from non-atomic handling of diversions. Topics There are a number of topics involved in implementing this kind of project * What syntax do we use for the new control file? * What dpkg does with the control file * How do we handle diversions to a non-existant directory? * How do we order unpacking a new package which adds a diversion? * How do we order unpacking a new package that removes a diversion? * How do we order removing a package which had a diversion? * How do we handle errors? * What happens to dpkg-divert? - Details - Control File Syntax - It will conform to RFC2822 style with the following format: * Divert-From: * Divert-To: * Blank lines and lines beginning with # will be comments Divert-To will be optional and if it is ommitted then files being diverted will have their filename changed to file.distrib The above style has it s advantages, one of the main ones being that there is no need to escape whitespace within filenames. - Details - Control File Handling - Within control.tar.gz the file should be named diversions This file is then copied to /var/lib/info/$package.diversions This is ensuring we have a copy of the control file just in case it is needed. Any input on this subject would be appreciated. - Details - Handling Diversions to non-existant directories - Diverting files to directories that don t exist can cause a number of problems. If the package does not own the directory it may be left orphaned on removal of the package The package is responsible for ensuring the availability of the target directory in the unpack phase. - Details - Ordering Requirements - =>Unpacking a new package that adds a diversion *1. Unpack folders *2. Add diversions *3. Unpack files ==Notes== Performing diversions this way avoids trouble with creating folders and accidentally overwrtiting the wrong version of files. If we don t use this method the problems that can occur include creating folders before the package itself would create them which may cause permission errors. Another major problem would be extracting a new version of the file and overwriting the old one. This might cause the wrong version of the file to be diverted and the package to break. =>Unpacking a new package that removes a diversion *1. Unpack folders *2. Add diversions *3. Unpack files ==Notes== =>Removing a package which had a diversion *1. Remove files *2. Remove diversions *3. Remove folders ==Notes== This ensures that all files, diversions and folders are removed correctly Details - Error handling Errors in diversions will have to handled with a great deal of care due to the fact that if they are not the package could be broken. This means that a great deal of checks must be done to ensure that all the files can be diverted properly before any actual diverting takes place. If they can t the package installation/update must be stopped and rolled back to avoid the package being installed incorrectly or broken. - Details - dpkg-divert - When we impliment the new diversion method we should keep the current dpkg-divert. This allows maintainers to catch up with the new method without breaking their packages. It also allows maintainers to perform some operations that aren t support by the new method. Example Usage #1 The file to be diverted is /usr/share/foo It needs to be moved to /usr/share/bar The syntax of the control file would be: #Start File Divert-From: /usr/share/foo Divert-To: /usr/share/bar #End File Example Usage #2 In this example the maintainer doesn t want to move the file to any specific folder The syntax of the control file would be: #Start File Divert-From: /usr/share/foo #End File This would divert the file to /usr/share/foo.distrib - Footnotes - RFC2822 Guide: * http://www.faqs.org/rfcs/rfc2822.html First Email Thread on Declarative Diversions (First Message in Thread): * http://lists.debian.org/debian-dpkg/2011/05/msg00102.html Declarative Diversions Wiki: * http://wiki.debian.org/SummerOfCode2011/DeclarativeDiversions My Blog for this Project: * http://blog.sam-dunne.com

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work, then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. I have been Doing some work towards Debian Rolling At the start of the month, the discussions about Debian rolling were still very active on debian-devel. Declaring that testing would be rolling did not make it (as I hoped), the argument that some RC bugs last for far too long in that distribution carried the discussion and thus the most consensual proposition ended up being the one of Josselin Mouette were rolling would be testing plus a few selected cherry-picked packages from unstable. I believe it s a workable solution if we only care about a subset of architectures. Otherwise the same reasons that keep the fixed packages out of testing would probably also apply for rolling. Given this, I did setup britney (the software that controls testing) on my laptop to investigate how we can create rolling. It turns out britney is a very specialized software with very few configuration knobs. At the same time Joachim Breitner made a proposition that immediately grabbed my attention. He suggests to use SAT solvers to find out the set of packages that should migrate from unstable to testing. I thought that rolling would be a good testbed for this new implementation of britney (which he calls SAT-britney) so I jumped right in this project. I was not at all familiar with this science field, so I looked up quite some documentation: I learned that all SAT solvers expect the problem to be presented in CNF form, and that DIMACS was the file format of choice to represent those boolean constraints. Several SAT solvers are available in Debian and picosat appears to be one of the best. Then I started some early coding/prototyping to play with the concept. You can find the result in this git repository, you can grab a copy with git clone git://git.debian.org/~hertzog/sat-britney.git. There s not much yet, except some Python code to generate a SAT problem that can be fed to a SAT solver. But I really look forward to this project. Representing Debian during Solutions Linux During the second week, I spent 3 days in Paris to help manage the Debian booth at Solutions Linux. We have responded to lots of queries but most visitors already knew Debian, and many of them use it at work and/or at home. We tried to recruit those people as new members for Debian France, the local association. We also sold all our remaining goodies. The Ubuntu people were interviewed by France 3 (an important TV channel) and we took this opportunity (with the consent of the Ubuntu guys) to show our Debian t-shirts in the background: you can watch the video here (in French), you can see me with Carl Chenet at 1:21. We have also been interviewed by Intelli n TV: here and here (both in French). I m not very good at this exercise. Improving dpkg triggers The third week was a vacation week, in theory I should have stayed away from my computer but I really wanted to take this opportunity to improve the state of dpkg triggers in Debian. I already covered my work in another article: Trying to make dpkg triggers more useful and less painful. The result is not merged yet, I just asked a question to all package maintainers who are using triggers to be able to decide whether I ll merge it as is, or if I can make the new behavior the default one. Supporting users after Alioth s migration When I came back from my vacation, many services provided by Alioth.debian.org were non-functional after a migration to a new setup that involves two machines instead of one. Given that I used to be an Alioth admin, I know that in those periods you tend to be get bogged down on many user support requests. So I re-joined #alioth on IRC and tried to help a bit. I did investigate some of the reported problems and prepared fixes (updated scripts, configuration files, etc.) for some of the issues. I also created a list of remaining issues that should have lasted only a few days but that s still active because there are still regressions left. The most important things still missing are:

• proper support for delegation of rights. We used ACL setup by the admins in the past. With the new FusionForge, each project admin should be able to delegate rights to external roles . There s a Debian Developer role already but trying to grant him right fails
• access to the Ultimate Debian Database. Many tools rely on this database to work.
• anonymous FTP access to download project files.
• clear guidelines on how we re supposed to deal with websites that are updated by VCS hooks.
• clear guidelines on how we re supposed to deal with personal git repositories

Improving the 3.0 (quilt) source format I have made some proposals to change the way the new source format would work. The goals are to be less painful for packagers who are using a VCS, and to avoid unexpected changes slipping through a new patch generated by dpkg-source. It seems that the proposals are relatively consensual so I ll implement them at some point. Missing in action on my blog I did a lots of stuff for Debian between travel and vacation, and in the remaining time, I did not manage to write many articles for my blog. In fact, besides the article on my triggers work mentioned above I only published one interview: People behind Debian: Steve Langasek, release wizard. I ll try to do better this month! Thanks Many thanks to the people who gave me 151.61 in May. See you next month for a new summary of my activities.

One comment Liked this article? Click here. My blog is Flattr-enabled.

The Event I just attended a lecture by Dr Ziggy Switkowski (see the above picture) on the topic of nuclear power, for a long time Ziggy has been the most prominent advocate of nuclear power in Australia, so naturally the talk was pro-nuclear. The lecture was free for alumni of Swinburne University and introduced by Swinburne s Chancellor who described Ziggy as a friend. Before the lecture started I handed out flyers for Beyond Zero Emissions [1] with a plan for zero carbon use in Australia by 2020. That was more difficult than handing out Greens polling cards on election day. The people who attended were there for a purpose and they could see the free food and wine on offer inside the building so getting them to stop and take a brochure wasn t easy. There were also people from Friends of the Earth [2] and some other anti-nuclear organisations giving out brochures. There were also some anti-nuclear protesters dressed as Uranium miners and the specter of nuclear contamination, they made for an interesting picture (which is amazingly good for a phone camera 20 minutes after sunset), but got in the way when I was handing out brochures. There were a few university security people at the door trying to keep the opposition away who were a bit annoying. There was also one policeman in attendance who was quite friendly, he asked whether there was a competition between the different groups as there is when handing out how-to-vote cards on election day. 15 minutes before the lecture was due to start I quit handing out the brochures and went inside for free food and drink (food always tastes better when the other team pays the bill). The Lecture I felt that Ziggy did a poor job of advocating nuclear power. There were a number of gaping flaws in his argument, but I have to commend him for his honesty in his appraisal of how hard it would be to develop a nuclear industry in Australia. Most nuclear advocates are a lot more optimistic about the process of building nuclear power plants and training all the people to run them. I will write a post tomorrow rebutting some of Ziggy s arguments. After the Lecture Immediately after the lecture the vice-chancellor stated that 500 people registered which made it the best attended such lecture that they have held. I don t know how many of the 500 attended, but I did notice that about 1/4 of the seats in the lecture hall were empty. It s rather sad that they can t get more people to such lectures, is TED.com stealing the audience? When I got out of the building I started handing out brochures to people as they left. I noticed that they were a lot friendlier than they were on the way in. I believe that people who left the lecture had greater interest in renewable energy because Ziggy just failed to make a good case for nuclear power. I expect that anyone who hadn t already made up their mind would immediately want to research the alternatives after watching Ziggy s lecture.

• [1] http://beyondzeroemissions.org/
• [2] http://www.foe.org.au/

Well jffnms 0.9.0 was a, well, its a good example of what can go wrong without adequate testing. Having it written in PHP makes it difficult to test, because you can have entire globs of code that are completely wrong but are not activated (because the if statement proves false for example) and you won t get an error. It also had some database migration problems. This is the most difficult and annoying part of releasing versions of JFFNMS. There are so many things to check, like:

• What has changed between this version of the database?
• Does the development database have all the new fields?
• Will importing an old database and using the diffs give me the same result as importing the new database
• Does the structure field match the object which matches the database table

I ve been looking at sqlalchemy which is part of turbogears. It s a pretty impressive setup and lets you get on with writing your application and not mucking around with the low-level stuff. It s a bit of a steep learning curve learning python AND sqlalchemy AND turbogears but I ve got some rudimentary code running ok and its certainly worth it (python erroring on un-assigned varables but not forcing you to define them is a great compromise). The best thing is that you can develop on a sqlite database but deploy using mysql or postgresql with a minor change. Python and turbogears both emphasise automatic testing. Ideally the testing should cover all the code you write. The authors even suggest you write the test first then implement the feature. After chasing down several bugs, some of which I introduced fixing other bugs, automatic testing would make my life a lot easier and perhaps I wouldn t dread the release cycle so often.

Related articles

• I m beginning to hate PHP? (abdulapopoola.wordpress.com)
• pTest: PHP Unit Tester in 9 Lines Of Code (blogs.sitepoint.com)
• PHP to the Rescue! (blogs.sitepoint.com)

Network effects are such a pernicious thing. They give us the internet, but they also give us an internet full of monopolistic worse-is-better players that use network effects to stifle improvements and competition. Sometimes the best you can manage is to be a parasite. facebook So I'm back on facebook ... sort of. My strategy for facebook is to be as near to a featureless datapoint as I can. I won't post anything. I entered as bad quality information as I could get away with. I turned all privacy controls off, on the theory that this way I don't have to worry about facebook eroding privacy since everything about me on facebook is aggressively public. By never posting anything to facebook, I am trying to fight the network effect; trying to avoid increasing the value of facebook due to me being on it. I've adblocked the text entry field on facebook just to avoid the temptation. I want to erase the Like buttons too. Technologically, I think a good approach would be a browser plugin that does these things while extracting all available content and optionally sending it to a RECAP-type system. I only friend people who I need to keep up with and who have little or no other internet presence. This is because I am aware that each person I friend still propels facebook's network effect a little bit; even though they'll never see any useful information from me, they will know that they are able to talk to me via facebook. I only log into facebook once a week or so (this is easy when you're not interacting with it anyway), and read whatever sample of farmville and other posts facebook selects as "important" (worse than usual probably since I never give it feedback). So people I friend can't rely on me reading everything they do, which reduces the value a little more. I will probably delete this account occasionally, and then re-add it later. Just often enough to be really annoying. twitter Similarly, I no longer gate my identi.ca account to twitter, and have deleted as many tweets as I could stand to (one click and one keypress per tweet; no mass-delete; ugh!), and protected my account to avoid accidential new tweets leaking out. Since twitter is not quite as evil as facebook I feel slightly less bad about exposing more of my social graph there. Only the folks who are too lame to get on an OpenMicroBlogging site like identi.ca. phone Of course there was a network effect with the telephone as well, and while it got deregulated it's still pretty bad, and also a technology that I mostly dislike using. Oddly my phone behavior is backwards to the other two networks; I only make outgoing phone calls, never answering the phone (unless real life intervenes very severely). I listen to some random fraction of my voice mail and read whatever ones manage to get machine-transcribed.

I was invited to be part of one of the panels to be present this Thursday (June 2) in a forum that promises to be interesting. The forum is organized by the Science and Technology comission of the Senate of the Republic (of Mexico ;-) ), Universidad Aut noma Metropolitana and Mozilla M xico. The day will be opened by Sen. Francisco Javier Castell n Fonseca and Richard Stallman; starting at 10:00, we will have thematic panels on:

• Education
• Government
• Industry
• Civil society

The full program (as well as details of interest of those that can physically attend) is attached to this post. I am looking forward to this forum. Not only it is a good opportunity to get our work known in one of those places where it matters, but it's also being organized by several interesting people I'm sure will have something interesting to contribute. And of course, we lacked time to build a better, more complete and more coherent proposal but there is a good probability we will have further such contacts. You might find interesting to read on the list we have been discussing; subscription seems to be open (although access to the archives is not Maybe it will be later on? In any case, I'm saving a mbox ;-) )

Attachment	Size
Activity program	352.37 KB