Participation and Results From June 15-17th we held a Debian BugSquashingParty in Salzburg, hosted and sponsored by conova communications GmbH. It was a fun and busy weekend, with 15-17 people from 5 countries being around, mainly working on RC bugs in Testing/Unstable. Gerfried Fuchs (rhonda) also worked on triaging the impact of RC bugs on the version in Squeeze, while Peter Palfrader (weasel) took care of Tor related things and Debian sysadmin work, including starting on the new bugs and udd hosts. Phillip Hug (hug) worked on the debian.ch infrastructure. Together with Miroslav Such from Red Hat Bernd Zeimetz (bzed) worked on the packaging of the necessary libraries and daemons to add (basic) Spacewalk client support to Debian. As soon as the packages passed NEW and #677871 was applied (thanks to the APT guys for working on that already), managing Debian clients with Spacewalk should work out of the box. Of course we also had a little keysigning party

Statistics

• about 68 bugs in unstable/testing were triaged/patched/fixed or at least pinged
• 54 bugs were tagged to show if they affect Squeeze, several other bugs were pinged to retrieve necessary information or to trigger an update in the next stable pointrelease.
• 5 packages were introduced into Debian (still in NEW, though) - the Spacewalk client related packages and libapache2-mod-auth-memcookie.

Accomodation Thanks to Debian funds we were able to provide accomodation for four participants in the JUFA youth hostel in Salzburg. We had paid in advance for eight, but changing to rooms with a higher category for only 4 people would have been equally or more expensive.

Press/Media coverage Additionally to being mentioned in the calendars on ProLinux and similar pages, we had some press coverage by the local newspaper and online magazines:

• Scan of Salzburger Woche / Stadt Nachrichten
• article on the Salzburger Nachrichten website
• meinbezirk.at
• Salzburg Cityguide - Photogallery

Fun facts We consumed 2kg of Leberkas, a big plate of "Buchteln mit Vanillesosse", about 16000cm^2 of Pizza, about 80 litres of coke, juice, beer and wine and I guess we drank at least the same amount of water. We had coffee made of 1.5kg coffee beans and managed to empty the (formerly well filled) icemaker in the fridge. Also we had successful training sessions of a standard Debconf game (rules won't be explained here obviously). Maybe we even successfully spread the game to the employees of a commercial linux distribution

Release 0.9.11 of Rcpp arrived on CRAN this morning and in Debian later today. This is a somewhat incremental release with a few internal improvements and few new features. One interesting new development has been contributed by John Chambers who is extending 'Rcpp modules' into 'Rcpp classes' which allows R code to modify and extend C++ classes loaded via Rcpp modules; see help(setRcppClass) for more. This also lead to some changes in the code for loading modules which however requires the brand-new R version 2.15.1 released today as well. The complete NEWS entry for 0.9.11 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

0.9.11  2012-06-22
    o   New member function for vectors (and lists etc) containsElementNamed() 
        which returns a boolean indicating if the given element name is present
    o   Updated the Rcpp.package.skeleton() support for Rcpp modules by
        carrying functions already present from the corresponding unit test
        which was also slightly expanded; and added more comments to the code 
    o   Rcpp modules can now be loaded via loadRcppModules() from .onLoad(),
        or via loadModule("moduleName") from any R file 
    o   Extended functionality to let R modify C++ clases imported via modules
        documented in help(setRcppClass)
    o   Support compilation in Cygwin thanks to a patch by Dario Buttari
    o   Extensions to the Rcpp-FAQ and the Rcpp-modules vignettes
    o   The minium version of R is now 2.15.1 which is required for some of
        the Rcpp modules support 

Thanks to CRANberries, you can also look at a diff to the previous release 0.9.10. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

I ve begun work on desktop-base to get it ready for wheezy. As many of you know, we saw the SpaceFun theme with Squeeze, and currently Wheezy as well. Rather then see the same theme twice, I ve taken the liberty of updating desktop-base to use the Joy theme proposed for Wheezy. My announcement can be seen on lists.debian.org, and details can be found there. Rather then drone on, check out what s been done so far. We ll be going from this: To: Game on!

To continue in photography blog posts, let's document part of our last week trip around Slovakia. We've visited many nice places, starting at Mura sk planina, going trhough Slovensk r j and ending in Nizke Tatry. All pictures are taken in Slovensk r j (Slovakian paradise), where I've really enjoyed taking photos of waterfalls and wonderful streams:

Filed under: English Photography Travelling 2 comments Flattr this!

Two years ago, Jacob (then 3) and I built his first computer together. I installed Debian on it, but never put a GUI on the thing. It s command-line, and has provided lots of enjoyment off and on over the last couple of years. I ve written extensively about what our boys like to do, and the delight they have at learning things on the command line. The looks of shock I get from people when I explain, as if it s perfectly natural, that my child has been able to log in by himself to a Linux shell since age 3, are amusing and astounding. Especially considering that it is really not that hard. Instead of learning how to run an Xbox, he s learned how to run bash. I like that. Lately, Jacob (now 5) hasn t been spending much time with it. He isn t really at a stage where he wants to push his limits too far, I think, but yet also gets bored with the familiar. So I thought it was time to introduce a GUI in a limited fashion, perhaps to let him download photos and video from his Vtech toy camera (that takes real low-res photos and videos which can be downloaded over a USB1 link). He s familiar with the concept, at least somewhat, having seen GUIs on Terah s computer (Gnome 2) and mine (xfce4 + xmonad). So last night, Oliver (age 2) and I went down to the basement on a mouse-finding expedition. Sure enough, I had an old PS/2 mouse down there that would work fine. The boys both helped string it through the desk up on our play room, and were tremendously excited to see the red light underneath it when the computer came on. Barely able to contain the excitement, really. A bit like I remember being when I got my first mouse (at a bit of an older age, I suppose.) I helped him them in as root for the very first time. (Jacob typed root , and I typed the password, and provided the explanation for why we were telling the computer we were root .) Jacob and Oliver alternated typing bits of some apt-get command lines. Then while we waited for software to download, I had to answer repeated questions of how soon will the mouse work? and what does install mean? Finally it was there, and I told Jacob to type startx. I intentionally did not install a display manager; more on that later. He pressed Enter, the screen went blank for about 5 seconds, and then X appeared. Excited can t begin to describe how they acted. They took turns playing with the mouse. They loved how the trash can icon (I started with XFCE) showed trash IN the trash can. But they are just learning the mouse, and there s a lot about a typical GUI that is unfriendly to someone that isn t yet proficient with a mouse. The close buttons are disappointingly small, things can be too easily dragged on and off the panel and menus. When I sat down to think about it, the typical GUI design does not present a very good it always works the same interface that would be good for a child. And then it occurred to me: the perfect GUI for a child would be simply xmonad (a tiling window manager that can be controlled almost entirely by keyboard and has no need for mouse movements in most cases.) No desktop environment, no file manager in the root window. Just a window manager in the classic X way. Of course! So after the boys were in bed, I installed xmonad. I gave Jacob s account a simple .xsession that starts a terminal and xmonad. Today, Jacob informed me that he wanted his computer to look just like yours. Playing right into my hands, that was! But when he excitedly typed startx, he said it wasn t just like mine. Uh oh. Turns out he wanted the same wallpaper as my computer uses. Whew. We found it, I figured out that xli(1) loads it in the root window, and so I added a third line to .xsession. More delight unlocked! Jacob mastered the basics of xmonad really quickly. Alt-Shift-C to close a window. Alt-Shift-Q to quit back to the big black screen . Alt-Shift-Enter to get a terminal window. We launched thunar (the XFCE file manager) and plugged in his camera. He had a good deal of fun looking at photos and videos from it. But then I dropped the true highlight of the day for him: I offered to install Tuxpaint for him. That s probably his favorite program of all time. He watched impatiently as apt-get counted down 1m30s for tuxpaint and its libraries. Then we launched it, and he wanted to skip supper so he could keep playing Tuxpaint on my VERY OWN COMPUTER! I d been debating how to introduce GUIs for a very long time. It has not escaped my attention that children that used Commodores or TRS-80s or DOS knew a lot more about how their computers worked, on average, than those of the same age that use Windows or MacOS. I didn t want our boys to skip an entire phase of learning how their technology works. I am pleased with this solution; they still run commands to launch things, yet get to play with more than text-based programs. At bedtime, Jacob asked me, very seriously: Dad, how do I start tuxpaint again? First you log in and type startx. Then you can use the mouse. Jacob nods, a contemplative look on his face.. Then, I continue, you type tuxpaint in the terminal, and it comes right up. Jacob nodded very seriously a second time, as if committing this very important information to long-term memory. Then gave a single excited clap, yelled Great! , and dashed off.

2000, Bordeaux, France. 2001, Bordeaux, France. 2002, Ottawa, Canada. 2003, Oslo, Norway. 2004, Porto Alegre, Brazil. 2005, Helsinki, Finland. 2006, Oaxtepec, Mexico. 2007, Edinburgh, United Kingdom. 2008, Mar del Plata, Argentina. 2009, C ceres, Spain. 2010, New York, United States. 2011, Banja Luka, Bosnia and Herzegovina. 2012, Managua, Nicaragua. 2013, Vaumarcus, Switzerland. We have gone to all different latitudes (although not yet longitudes!). We have had very hot and very cold weather. Great cities and small villages have hosted us. What will be the next addition to this great list? As we approach DebConf12 (10 days to DebCamp and counting, yay!), we should keep the future in mind. So, as every year in recent history, we will once again have a DebConf session presenting possible venues for the next year. Organizing DebConf in your city means a lot of hard work. It also means one of the greatest personal experiences you can imagine. And it is a great way to contribute to Debian. The decision process for every DebConf venue starts two years before, with presentations during DebConf(n-2). That means, if you consider presenting a bid for DebConf14, now is the moment to act! Do you have to be present at Managua to propose your bid? No. You can proxy via somebody I d suggest to do it via somebody who knows the location you are suggesting, but basically, choose a friend that you trust that trusts you. Of course, you can participate in the presentation session via IRC. Do you have to be a Debian Developer to propose a bid? No. For DebConf9, none of the C ceres guys was a DD; for DebConf10, some of the people most involved from the local New Yorkers were not DDs. For DC11, none of our hosts in Bosnia are DDs. And for DC12, the dear and overworked Nicaraguan crew is also made from people interested in getting closer to the Debian project, but not DDs. Do you have to decide now? No. This is just a call for a first presentation, but the decision regarding DC14 will be taken probably around March 2013. However, giving a nice presentation at DebConf helps a lot, gives you visibility, and will get the ball rolling. Is there a geographical bias? Slight. So far, and since the second DebConf, we have kept the tradition not to repeat continents on two successive DebConfs. This is not a hard condition, however! While there is some probability that DebConf14 will be somewhere in America (the continent, of course), it depends on the proposals more than on any pseudo-rule. What do you need to start thinking about? Go visit our prospective location checklist. You can also look at what other teams have historically presented. And of course, go to the DebConf14 wiki planning page Register there, even if you are just in the early phases of finding data.

Sarah and I are running in the 5K Packard Summer Scamper on Saturday. Sarah's been working on her fitness for a few months now, and I belatedly started working on mine about a 6 weeks ago. (Sarah's fund raising, so if you'd like to sponsor her, her page is here) I've been using the Couch to 5K program to get my fitness up, but I haven't managed to stick to it exactly, due to a combination of injury and wet weather. I have still managed to get myself to the point where I can run for 28 minutes solidly, which is close to 5K (I'm doing my last training run tomorrow, so I'll see what the distance comes out to). I've been doing up to three runs a week at lunchtime around the Shoreline Amphitheatre area, using my Galaxy Nexus and some Bluetooth headphones, and I've got a pretty nice little setup. I'm using Pandora for some music to listen to, C25K Pro for the actual running intervals. It has voice prompts that tell me when to run, or to start a walk interval. Finally, I'm using Strava Run for recording the run and getting some additional statistics during the run (kilometre markers, split times and time elapsed). These also come through as voice prompts. I'm not currently wearing a watch, and I want to keep track of the wall time, so I've also found Audio Clock, which verbally announces the time (I've set it to do it every 15 minutes that a Bluetooth headset is connected). What I really like about all of this is that I get spoken voice prompts and information, seamlessly mixed in with the music from Pandora, all while I'm running. I've got my phone strapped to my arm, and I don't have to look at it during the run, and there's no wires. I'm a huge personal metrics junkie, and that was why I previously eschewed running outdoors. I wanted that information on the treadmill display so I could push myself that little bit further. Sure, I'm not getting the constant information as much as if I had a treadmill display in front of me the whole time, but I'll settle for running in the great outdoors and getting some feedback every kilometre (if I get really desperate, Strava will do it every half kilometre). Not to diss optical augmented reality efforts too much, but I'd rather go for a combination of discreet audio announcements through a Bluetooth earpiece, perhaps complemented with something I choose to look at like a Pebble watch, than an in-your-face pair of glasses. My Bluetooth headphones are the around the back of the head variety that aren't going to bounce off during a run. I've really enjoyed doing the runs during the week, and when I was doing the full 3 runs a week of a given week of the Couch to 5K program, I'd really notice a difference by run number 3. I'm currently planning on sticking with doing a 5K run hopefully at least twice a week after this weekend. It's certainly done wonders for my waistline.

Thanks to Google, for some years now there has been the so-called Google Summer of Code programme. Quite an interesting project it is.

However, how many of the slots assigned to Debian have resulted in successful projects? how many of them were actually completed by the student and not by the mentor or somebody else? are those projects in fact used or useful at all?

All these questions occurred to me while wondering what would have happened if Joey Hess' git-annex-related kickstarter project had instead been a GSOC project. His kickstart was very successful by the way. Joey: many congratulations!

Not trying to point my finger to the (IMHO many) failed or unsuccessful Debian-related gsoc projects, but I wonder how many successful projects are developed outside the get-paid-in-exchange model. I suspect most, at least in Debian.

What's done for those who actually "deliver" while working on projects as a hobby? is it really worth having GSOC slots for Debian?

After upgrading a mail server to Debian/Unstable (which will soon be released as Wheezy) I started getting SASL errors. 535 5.7.8 Error: authentication failed: no mechanism available The SMTP protocol gave the above error for both LOGIN and PLAIN methods. SASL LOGIN authentication failed: no mechanism available The postfix/smtpd process logged messages like the above in syslog. It turned out that the auxprop_plugin: mysql line had to be removed and replaced with the following two lines due to a change in the way SQL plugins are managed: auxprop_plugin: sql
sql_engine: mysql Also the SQL query needed to have %u replaced with %u@%r because we now have user and realm provided separately. Related posts:

1. MySQL security in Debian Currently there is a problem with the MySQL default install...
2. Kernel issues with Debian Xen and CentOS Kernels Last time I tried using a Debian 64bit Xen kernel...
3. new release of postal Today I have released a significant new version of my...

Upgrading the local version of subversion against a large subversion repository has so far taken three DAYS. It goes through this multi-gigabyte repository in no perceivable order, it goes through every single directory in every single tag and every single branch and refuses to run in any sub-directory. (Even after clearing out some older tags, the tags/ directory is still nearly 8Gb and that doesn't include any binary files.) Each tag within tags/ is 500Mb and contains nearly 6000 sub-directories. Yes, it's large but svn upgrade should still be able to handle it without crippling every machine.

I can't image how svn is going to manage when the server finally gets upgraded. Probably be quicker to dump the entire repo and reimport it.

When I finally give up the will to proceed or simply need to use this LAPTOP for something else, I have to interrupt it with Ctrl-C at which point is starts all over again!

This isn't a slow machine, it's a i5 quad-core T410 with 8Gb of RAM and 1Tb of storage - and svn has made it crawl for days. The only way to pair down the working copy is to delete every tag and branch which means losing data like old build logs and old packages. The repository is this large because it's tracking the development of multiple commercial products which share common code but which also have numerous releases and release updates.

I can't even use svn st on this repo without this completing - I haven't been able to work on this repo since this started. Absolutely insane.

Pondering filing an RC bug on the basis of unjustifiable data loss. We have many machines at work with this repository checked out and if we ever migrate to Wheezy, it's going to mean a WEEK of lost work!!

subversion                    1.7.5-1

So, a warning for anyone else using subversion 1.7.5 with a very large repository: DELETE ALL TAGS and BRANCHES and any other directory anywhere in every single working copy tree on every machine which ever wants to use that copy again before even thinking about upgrading to 1.7.5.

The tags directories don't even need to be upgraded because we only use those to rebuild the code as it was in chroots.

Unspeakably furious about such a completely dumb tool being thrown into the mix DAYS before the Wheezy freeze. Now I have to kill it AGAIN just so that I can suspend the laptop. IDIOTS.

I have an interesting problem: How do I shoehorn "hired by The Internet for a full year to work on Free Software" into my resume? Yes, the git-annex Kickstarter went well. :) I had asked for enough to get by for three months. Multiple people thought I should instead work on it for a full year and really do the idea justice. Jason Scott was especially enthusiastic about this idea. So I added new goals and eventually it got there. Don Marti thinks the success of my Kickstarter validates crowdfunding for Free Software. Hard to say; this is not the first Free Software to be funded on Kickstarter. Remember Diaspora? Here's what I think worked to make this a success:

• I have a pretty good reach with this blog. I reached my original goal in the first 24 hours, and during that time, probably 75% of contributions were from people I know, people who use git-annex already, or people who probably read this blog. Oh, and these contributors were amazingly generous.
• I had a small, realistic, easily acheivable goal. This ensured my project was quickly visible in "successful projects" on Kickstarter, and stayed visible. If I had asked for a year up front, I might not have fared as well. It also led to my project being a "Staff Pick" for a week on Kickstarter, which exposed it to a much wider audience. In the end, nearly half my funding came from people who stumbled over the project on Kickstarter.
• The git-annex assistant is an easy idea to grasp, at varying levels of technical expertise. It can be explained by analogy to DropBox, or as something on top of git, or as an approach to avoid to cloud vendor lockin. Most of my previous work would be much harder to explain to a broad audience in a Kickstarter. But this still appeals to very technical audiences too. I hit a sweet spot here.
• I'm enhancing software I've already written. This made my Kickstarter a lot less vaporware than some other software projects on Kickstarter. I even had a branch in git where I'd made sure I could pull off the basic idea of tying git-annex and inotify together.
• I put in a lot of time on the Kickstarter side. My 3 minute video, amuaturish as it is, took 3 solid days work to put together. (And 14 thousand people watched it... eep!) I added new and better rewards, posted fairly frequent updates, answered numerous questions, etc.
• I managed to have at least some Kickstarter rewards that are connected to the project is relevant ways. This is a hard part of Kickstarter for Free Software; just giving backers a copy of the software is not an incentive for most of them. A credits file mention pulled in a massive 50% of all backers, but they were mostly causual backers. On the other end, 30% of funds came from USB keychains, which will be a high-quality reward and has a real use case with git-annex. The surprising, but gratifying part of the rewards was that 30% of funds came from rewards that were essentially "participate in this free software project" -- ie, "help set my goals" and "beta tester". It's cool to see people see real value in participating in Free Software.
• I was flexible when users asked for more. I only hope I can deliver on the Android port. Its gonna be a real challange. I even eventually agreed to spend a month trying to port it to Windows. (I refused to develop an IOS port even though it could have probably increased my funding; Steve's controlling ghost and I don't get along.)
• It seemed to help the slope of the graph when I started actually working on the project, while the Kickstarter was still ongoing. I'd reached my original goal, so why not?

I've already put two weeks work into developing the git-annex assistant. I'm blogging about my progress every day on its development blog. The first new feature, a git annex watch command that automatically commits changes to git, will be in the next release of git-annex. I can already tell this is going to be a year of hard work, difficult problems, and great results. Thank you for helping make it happen.

A post by Gunnar reminded me that I wanted to blog about this: e-voting in Belgium is going to change slightly. Previously, e-voting worked with a computer with a lightpen on which you would enter your vote, a magnetic card that would contain your vote in encoded form, and a magnetic card reader that would count the votes. After more than a decade when I was first eligible to vote back in 1996, it had already been implemented in the city of Antwerp, where my vote would be cast, so I've never voted on paper it had still not been rolled out everywhere, and some of the computers used for the voting were now starting to show their age. A few days ago on the news, they reported that the e-voting system was to change so that rather than magnetic cards, it would use pieces of paper. This way, voters would be able to check that the information on the piece of paper conforms with their vote. Investigating what this means, I found this website by the federal government, where they have some pictures of a test run of the new system which they ran in October last year. Rather than using magnetic cards, the new system uses paper slips with the voted information in two forms: once as a (huge) QR code, and once as a human-readable text. In theory, this is a more transparent system than using a magnetic card, and that's a good thing; additionally, it allows for a traditional recount (by people, not computers) should the need ever arise. However, I do still see some problems:

• The website says you need to first fold the slip, and then unfold it when you get at the scanner so you can scan your barcode. This risks violating the secrecy of the vote, as people will be able to glance what other people have voted as they unfold the slip. I'm not sure how this can be fixed.
• If the vote is printed on the paper slip in two forms, you need to be able to guarantee in some way that the two forms are the exact same information. People with smartphones can scan the QR code and compare it to the human-readable code, but not everyone has one of those.

Having said that, I do think the new system is an improvement over the old (in fact, it's exactly the kind of system I had thought about myself earlier when thinking about ways to improve e-voting); and if the two problems are solved in some way (it's not impossible to do that, just requires some clever thinking), I believe it has potential as a way to implement electronic voting in a good way.

here's my weekly list of RC bugs that I've worked on:

• #665234 src:libpoe-component-client-mpd-perl: "libpoe-component-client-mpd-perl: FTBFS: tests hang"
  upload new upstream release (pkg-perl)
• #666351 src:openr2: "openr2: FTBFS: dh_install: libopenr2-bin missing files (etc/openr2/*.conf), aborting"
  fix build* targets in debian/rules, upload to DELAYED/3
• #666654 src:apt-dpkg-ref: "apt-dpkg-ref: FTBFS: cp: cannot stat apt-dpkg-ref.pdf': No such file or directory"
  manual close
• #667764 strongswan-starter: "strongswan-starter: package must not include /var/lock/subsys"
  create lock directory in init script instead of shipping it, upload to DELAYED/3
• #669433 src:grafx2: "grafx2: FTBFS: fileformats.c:30:17: fatal error: png.h: No such file or directory"
  add build dependency on libpng-dev, upload to DELAYED/2
• #669559 src:xserver-xorg-video-mach64: "xserver-xorg-video-mach64: FTBFS: cp: cannot stat debian/tmp/usr/share/man': No such file or directory"
  manual close
• #670221 plptools: "plptools: fails to install due to insserv rejecting the script header"
  fix init script as proposed by Andreas Beckmann, upload to DELAYED/2
• #671962 src:freerdp: "freerdp: FTBFS: dh_install: libfreerdp1 missing files (usr/lib/*.so.*), aborting"
  send patch from Ubuntu / Michael Terry to the BTS
• #674761 src:gpx2shp: "Build-depend on obsolete proj package"
  fix build dependency, upload to DELAYED/2

A copy of this post is sent to soc-coordination@lists.alioth.debian.org as well as to debian-bootstrap@lists.mister-muffin.de. Diary June 4 I added the first version of basenocycles.ml to git. Given an initial set of cross built packages, it tries to compile as much as possible on the resulting system in multiple rounds. June 5 During June 3, I discovered and error in my program that would only come up when using the Debian Sid package lists as the input:

Fatal error: exception Assert_failure("common/edosSolver.ml", 610, 11)

On this day, June 5, I wrote a minimal test case for this problem. The same day, Pietro figured out that this is a bug in dose which will be fixed in the next release. Begin writing code to figure out how important a binary package is for the further build process. Try to use Depsolver.edos_install to find out what packages are needed to make debhelper available. Restructure basenocycles.ml, exclude source packages that already have been built, still trouble with already existing binary packages and Cudf.mem_installed, comment stuff better. June 6 I wrote some crude code (only estimate, not correct, fixed later) that would give a rough overview of how often a given binary package is directly required as a build dependency. Debhelper came out as the most needed package. It is architecture:all, so it does not have to be built but it has unfulfilled runtime dependencies. To make those packages available, 13 (actually 11, fixed later) packages have to be compiled on Ubuntu Natty. But those packages all (except gettext) require debhelper itself to be built. The first dependency cycle. This dependency cycle (actually, the 12 cycles) can be broken by either cross compiling those source packages or by making them build without debhelper. One goal of the program is to help decide what the easier option is, but this is not yet implemented. To play around a bit, I created the possibility to specify a list of packages that are additionally to the minimal set of cross compiled packages also cross compiled. I added the 13 packages found above to the list, thus making the binary packages they build available. This made debhelper available in the system. As a result, 1625 out of 3339 source packages can be built with just a minimal build system (priority:essential packages plus build-essential) and debhelper available. The next package that blocks the most other source packages from being built is cdbs. The next nine packages in that list also require cdbs so it seems to be the next important package to be available. Pietro's suggestions make me:

 - do not open BootstrapCommon but ExtLib, Common, Algo, Debian
 - do proper option parsing and logging
 - use Debcudf.ignore_essential = true
 - do Debcudf.init_tables (binlist@srclist)
 - use @ with shorter list first
 - use more List.rev_append instead of @
 - use CudfAdd.who_provides to find if a package is available

June 7 Pietro and Patrick suggest that for solving the debhelper cycles, one could provide a minimal debhelper version so that the above list of 12 packages can be built without debhelper. I try to figure out how to get a list of packages that are missing to make a package installable/buildable. This functionality should be provided in dose but I fail to find it. June 8 Lacking a solution of the problem of June 7, I write a mail to Pietro. I start my first graphs in ocaml using the ocamlgraph library. The graph I generate, starts off at a binary package. For each binary package it connects new vertices as its runtime dependencies. If a binary package is not arch:all and also not yet otherwise compiled, its source package is also added. The result is a graph in which set of source packages in it will make the initial package available, if those source packages would be cross compiled. The graph is extended further than the source packages. June 9 I refine a couple of functions, make univ_get_pkg_by_name return the package with the highest version number. I wrote a rather lengthy (1027 words) email to the list that explains my status as of this day. I can create graphviz dot files with ocaml, can create node and edge types and create the graph by an imperative pattern that I saw a lot in Pietro's code. Disjunctions are not yet handled correctly (see mail from June 8). The graphs generated look like the following: http://mister-muffin.de/p/8nyc.png June 11 I write a test case which shows how CudfAdd.who_provides doesnt find virtual packages. Automate the process of finding the packages that, if cross compiled, would make another package available. Add more predicates (identifying source packages) and improve input file reading code. Move build_compile_rounds which compiles as many source packages as it can in multiple rounds on a given minimal system a toplevel function and thereby abstract it more. Create a rudimentary text based menu to choose different actions to take for an analysis. Start writing an extended version of simple_dependency_graph for deeper analysis. Use xdot to show graphs from the text menu. Allow saving those graphs to a file. June 12 Move functionality from the extended version of simple_dependency_graph over to the normal version and delete the extended version. Add the new Closure vertex type. Create extended_dependency_graph which is supposed to not contain single binary package vertices but handle a package and its installation set as one vertex. The output of extended_dependency_graph is optionally reduced to the biggest (non degenerate) strongly connected component. User gets the option of choosing the exploration depth. June 13 Pietro replies to my mail from June 8 but apparently I failed to express myself well enough in my last mail, so I rephrase my question. Pietro replies to my email from June 11 and explains how the effect I see is due to "a nuisance of the debian to cudf encoding". As a result I change my code accordingly. June 14 Another lengthy (1130 words) email to the list. I explain what was done in the past days, what parts work and how they work. I list some rationales on why I did things the way I did them. The most important observation is, that after improving my code again and again, I ended up representing the dependency cycle problem in the same (very similar) way that Pietro suggested in the beginning. This is probably a good discovery. Lots of data of that email is now of only little use as of June 16, I make lots of improvements in correctness. As I dont have an answer to my other email to Pietro from June 13, I implement a very crude way to get an answer to the question of what packages are missing for a package to be available/compileable. I called it flatten_vpkgformula_best_effort and it suffers from many faults including disjunctions and package conflicts. Patrick spots a problem. As a result, I make sure that at no point, the source package of an arch:all package can be listed. June 15 As a reply to my mail from June 13, Pietro creates a new branch in the git and adds the code I needed to get a proper installation set. June 16 As a result of Pietro's efforts from June 15, I make great advancements on all fronts. Details of the current status follow in the next section. Results A big leap was made on June 16 due to Pietro's great help on making me understand how Depsolver.listcheck can be used for my purposes. My difficulties in finding the solution myself are rooted in many parts of the dose framework being poorly commented but Pietro did already a couple of documentation commits whenever things were unclear for me. Using Depsolver.listcheck makes it possible to be more distribution agnostic and I dont have to handle vpkgs, virtual packages and constraints myself anymore. The code also doesnt suffer anymore by wrongly analyzed dependencies and conflicts. The only thing that is not yet taken care of, is that Depsolver.listcheck only chooses one out of several possible installation set. A final version should be able to take into account that a different installation set could provide a better solution. Overall, in comparison to two weeks ago, I can now properly build, traverse and analyze graphs, can choose an installation set properly, understand more about dependencies, closures, dose and ocaml in general. Finding the importance of binary packages for building When calculating how many source packages are depending on the availability of a binary package I originally flattened the pkg.Cudf.depends list twice for a rough overview. This is of course wrong due to disjunctions and conflicts and also doesnt provide a deep dependency inspection. The new method is to calculate an installation set that is necessary to compile a source package for every source package. The resulting list of binary packages is then used to find out how often a binary package appears in an installation set. I see three drawbacks though:

• calculating an installation set for each source package in the archive is very slow
• if X packages build depend on A then also X packages will build depend on the installation set of A, resulting in lots of duplication
• only one installation set is selected though there are many

Removing simple graph The simple graph which contained single binary and source packages was removed. I realized it doesnt really serve any purpose to look at it. As a result, Bin vertices and InstallDep edges are also not part of the graph anymore. Since it was responsible for generating the list of source packages that have to be cross built to make a package available, I created a new function get_cross_source_packages which uses an installation to serve the same purpose. Fix extended_dependency_graph extended_dependency_graph now uses installation sets for generating the list of packages that is needed to compile a source package or install a binary package. The list of build dependencies does not include packages that are already installable. The list of runtime dependencies does not include packages that are otherwise available (cross built, arch:all...). Instead of checking for list membership all the time, I created hash tables for the list of installable as well as for the list of available binary packages. Future There are two big tasks for the next two weeks: Task one is to find a way to give hints on which packages to best consider for having reduced build dependencies. This would then probably finally make use of Pietro's cycle algorithms. Task two is to find a way to break cycles and create a build-DAG from a list of packages that already have staged build dependency information. Patrick is currently working on patching dpkg with Build-Depends-StageN dependencies as making perl cross compilable. If he doesnt need the ability to decide which packages to modify to have staged build dependencies in the near future, then task one is probably less urgent and therefor of less importance right now? On the other hand, I can easily generate fake reduced build dependencies so that doing task two right now would not be a problem. Also, having the solution for task two will make it possible to show the user what effect it would have to add reduced build dependencies to a package. For the reasons above (it's not urgent, task one profits from task two being solved) I will go and implement task two first (if there are no objections from my mentors). Another idea, that I discussed with wookey and Patrick yesterday, was that due to multiarch being used for more and more packages, there should exist a set of packages that is cross compilable without any change to the package. We agreed that I make a list of packages that, if cross compiled, would break dependency cycles and make other packages available. I created such a list of about 160 packages for Ubuntu Natty that, if cross compiled, made it possible to have 87% of Natty available (those numbers have to be treated with caution as I did not yet use the proper way of installation sets when generating that list, but the order of magnitude should be correct). Wookey can then try to cross compile those packages. If some packages of those "crucial" source packages are found to be cross compilable, then they should be cross compiled because it means that no work has to be done to break some cycles. Cross compiling all packages that are cross compilable out of the box is no solution, as only natively compiled packages can go into the archive. This is why the list of potentially additionally cross compiled source packages has to be kept as small as possible.

It s almost the Wheezy freeze time and I ve been working frantically to get things working properly. Policy Status At the moment I m preparing an upload of the policy which will support KDE (and probably most desktop environment) logins and many little fixes related to server operations (particularly MTAs). I would like to get another version done before Wheezy is released, but if Wheezy releases with version 2.20110726-6 of the policy that will be OK. It will work well enough for most things that users will be able to use local changes for the things that don t work. One significant lack with the current policy is that systemd won t work. I ve included most of the policy changes needed, but haven t done any of the testing and tweaking that is necessary to make it work properly. I would like to see policy support for systemd in a Wheezy update if I don t get it done in time for the first release. If I don t get it done in time for the release and if the release team don t accept it for an update then I ll put it in my own repository so anyone who needs it can get it. /run Labelling One significant change for Wheezy is to use a tmpfs mounted on /run instead of /var/run. This means that lots of daemon start scripts create subdirectories of /run at boot time which need to have SE Linux labels applied for correct operation. The way things work is that usually the daemon will write to the directory immediately after the init script has created it, so I can t just have my own script recursively relabel all of /run. Some packages that need to be patched are x11-common #677831, clamav-daemon #677686, sasl2-bin #677685, dkim-filter #677684, and cups #677580. I am sure that there are others. [ -x /sbin/restorecon ] && /sbin/restorecon -R $DIR Generally if you are writing an init script and creating a directory under /run then you need to have some shell code like the above immediately after it s created. Also the same applies for directories under /tmp and any other significant directories that are created at boot time. Upgrading Currently there are some potential problems with the upgrade process, I m working on them at the moment. Ideally an apt-get dist-upgrade would cleanly upgrade everything. But at the moment it seems likely that the upgrade might initially go wrong and then work on the second try. There are some complications such as the selinux-policy-default package owning a config file which is used by mcstransd (which is part of the policycoreutils package), when the config file format changes you get order dependencies for the upgrade. Kernel Support My aim when developing a new SE Linux release for Debian is that the policy should work as much as possible with the user-space from the previous release. So if you upgrade from Squeeze to Wheezy you should be able to start the process by upgrading the SE Linux policy (which drags in the utilities and lots of libraries). This means that if you have a server running you don t have to put it out of action for the entire upgrade, you can get the policy going and then get other things going. I haven t tested this yet but I don t expect any problems (apart from all the dependencies). Also the policy should work with the kernel from the previous release. So if you have a virtual server where it s not convenient to upgrade the kernel then that shouldn t stop you from upgrading the user-space and the SE Linux policy. I ve tested this and found one bug, the sepolgen-ifgen utility that you need to run before audit2allow -R won t work if the kernel is older than the utilities #677730. I don t know if it will be possible to get this fixed. Anyway it s not that important, you can always copy the audit log to another system running the same policy to run audit2allow, it s not convenient but not THAT difficult either. The End Result I think that the result of using SE Linux in Wheezy will be quite good for the people who get the upgrade done and who modify a few init scripts that don t get the necessary changes in time. I anticipate that someone who doesn t know much about SE Linux will be able to get a basic workstation or small server installation done in considerably less than an hour if they read the documentation and someone who knows what they are doing will get it done in a matter of minutes (plus download and install time which can be significant on old hardware). At the moment I m in the process of upgrading all of my systems to Unstable (currently Testing has versions of some SE Linux packages that are too broken). While doing this I will keep discovering bugs and fix as many of them as possible. But it seems that I ve already fixed most things that affect common users. Also BTRFS works well. Not that supporting a new filesystem is a big deal (all that s needed is XATTR support), but having all the nice new features on one system is a good thing. Now I just need to get systemd working. Related posts:

1. SE Linux Status in Debian 2012-01 Since my last SE Linux in Debian status report [1]...
2. SE Linux Status in Debian 2012-03 I have just finished updating the user-space SE Linux code...
3. SE Linux Status in Debian 2011-10 Debian/Unstable Development deb http://www.coker.com.au wheezy selinux The above APT sources.list...

You know what really pisses me off? Idiots in takeaways... More to the point, racist, idiotic, drunken idiots in takeaways - having just been to one of the few places still open at "silly o'clock" i.e. a place that's open after the pub has shut, it's really annoying and disappointing in the human race, to hear someone refer to the staff as a "paki bastard". I'm disgusted with the customer in question. I mean, WTF, how absolutely fucking stupid have you got to be to both be racist and do it loud enough to not only piss off the staff, but piss off any customer that actually just views people as people - we're in this world together ffs, stop being such fucking moronic, racist cunts. It's not difficult. People are people. All of them. The whole world. (apologies for bad language in the post, it's just, well, as the title says, something that really pisses me off).

I made it..:-) Despite quite horrible weather conditions (heavy rain before the race, strong rain during the first 1/2h, light rain up to half-marathon....and wind during the first 25 kilometers), I managed to break my personal best in a marathon, down to 3h38'45". Not a huge improvement (1'35") but, given that this race is not the easiest ever (the last 17 kilometers are made of ups and downs, for a total 150 meters positive slope and 60 meters height difference between start and finish), a very good result indeed. This has been my first "negative split" marathon, with a second half faster than the first. Also I managed to keep the same speed all along the race, each kilometer being 5'02" and 5'16" except one at 5'23 because of the steepest hill there. Final kilometer in 4'50"! As I was hoping, training gives results... Now, I'm heading to a summer without races, but probably great runs during DebConf in Nicaragua. Next "big" race : Seine-Eure marathon, in Val de Rueil, France, on October 20th. Here, I again expect to break my PB as this is a very flat race (the place where I set my previous PB, indeed)

KiBi is my hero of the day. I ve long wondered why I couldn t select fixed-misc as font on my workstation at the dayjob, which is running Kubuntu Hardon Heroin. (Luckily, I managed to avoid upgrading to Prolonged Pain.) Now I guess that ll work again. My work laptop (running testing) also has got this X.org thingy. My keyboard layout now has got a grml branch (named after the person who first cursed about the insane idea of those toy-breaking boys to rearrange the keycodes) that works with it. Since Debian is marginally more sane than Kubuntu, in contrast to the gnu branch I use on my orkstation, the grml branch still has Meta on the left Alt key, not Mode_switch, as it still works in uxterm, which reduces the diff between the MAIN branch (HEAD) on XFree86 and this beast.

And finally: X.org defaults to a black screen and disabled mouse pointer until an application first requests it. Totally unacceptable for evilwm(1) users, and letting people think it crashed, to boot. The Arch Linux guys found this, among others; the fix is: startx(1) users edit /etc/X11/xinit/xserverrc to add -retro behind the X, or copy the file to ~/.xserverrc and change it there:

For display managers,similar files exist in /etc/kde4/kdm and related places.

Today, my workstation sent me this email:

The following warning/error was logged by the smartd daemon:
Device: /dev/sda [SAT], 1 Currently unreadable (pending) sectors

and then a little later, this one:

The following warning/error was logged by the smartd daemon:
Device: /dev/sda [SAT], 1 Offline uncorrectable sectors

From the hard disk s SMART data, this is a clue that the drive is failing or will soon. Sigh. Incidentally, if smartmontools isn t installed on your machine, whether it s a laptop, desktop, or server, it should be. Although most of you know I run Linux on the metal on my machines almost exclusively, I do maintain a small drive with a Windows installation that I boot into every few months for various reasons. This is that drive. The drive is non-redundant (no RAID), and although it is backed up, the backup is made via backuppc from the NTFS filesystem mounted on Linux, and is a partial backup backing up certain data, not the OS. There are, of course, bare metal Windows backup solutions, but I generally don t want to back up Windows from within Windows on this machine. Restoring Windows isn t quite as simple as an mkfs, an untar, and a grub-install, either. So my first thought is: immediately save whatever of the drive I can. So I ran apt-get install gddrescue to install the GNU ddrescue tool. ddrescue is somewhat similar to dd, but deals much more intelligently with bad blocks on the drive. It will try to read them repeatedly, with decreasing block sizes, in an effort to get every last good byte off the disk that it can. If it ultimately fails to get certain bytes read, it will write placeholder data to the output file in place of the missing data, so that the output file maintains proper size and alignment. It also saves a log file that notes what it found (see info ddrescue for more on that.) So I created an LVM volume for the purpose (not enough free space on /home, and didn t want to have to shrink it somehow later), and ran:

ddrescue /dev/sda /mnt/sdasave.ddrescue /mnt/sdasave.logfile

Then I went to dinner. When I got back, I discovered there were 1 or 2 bad sectors, about halfway through the disk, but everything else was fine. So now, the question became: did I lose any data? If so, what? I needed to know if I had to revert to a backup for anything or not. To answer THAT question, first I had to figure out the offset of the bad spots on the disk. That s not too hard; the logfile gives it to me:

# Rescue Logfile. Created by GNU ddrescue version 1.15
# Command line: ddrescue /dev/sda /mnt/sdasave.ddrescue sdasave.logfile
# current_pos  current_status
0x3BBB8BFC00     +
#      pos        size  status
0x00000000  0x3BBB8BF000  +
0x3BBB8BF000  0x00001000  -
0x3BBB8C0000  0x38B5346000  +

what we see is that the bad sector starts at byte 0x3BBB8BF000 (256549580800 decimal) and extends for 0 1000 bytes (4096 decimal). Both the drive and NTFS use 512-byte sectors. So dividing by 512, we get sector 501073400 501073407 (4096 bytes is 8 sectors). As a check, I ran grep sector /var/log/kern.log and turned up a bunch of lines like this: Jun 14 21:39:11 hephaestus kernel: [35346.929957] end_request: I/O error, dev sda, sector 501073404 Which is within my calculated range. But this is an absolute sector on the disk. We need the sector within the partition, so for that, we have to enlist fdisk to make that calculation. fdisk shows, among other things:

Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   976771071   488384512    7  HPFS/NTFS/exFAT

So the Windows partition starts at disk sector 2048. Let s just confirm that. If I use dd if=/dev/sda1 bs=512 count=1 hd head, I see a line beginning with .R.NTFS . Exactly the same as with dd if=/dev/sda bs=512 count=1 skip=2048 hd head, so I read the partition table information correctly. Subtract offset of 2048 from the earlier values, and I get relative sectors 501071352-501071359. That s enough to get some solid info from the filesystem via ntfscluster, part of Debian s ntfs-3g package. I pass -s to it, and ignoring some irrelevant stuff, get my answer:

ntfscluster -s 501071352-501071359 /dev/sda1
Inode 190604 /System Volume Information/ b4816feb-b609-11e1-a908-50e549b934f7 3808876b-c176-4e48-b7ae-04046e6cc752 /$DATA

I even reran it with a much larger sector range, just to be absolutely sure I had wiggle room in case calculations had an off-by-one error or something somewhere. This is really great news, because the file in question is pretty much useless I believe it s a system restore point, which I won t be needing anyhow. So at this point, all that remains is to reinstall this on a different drive. For that, I could just use my ddrescue image. I thought I would take a second image, just to be very extra careful, and use that; I used:

partclone.ntfs --rescue -c -s /dev/sda1 -o sda1.partclone

although ntfsclone would work just as well. This captures only the partition; I ll need the partition table as well, and perhaps also the space between the partition table and the first partition. I could capture it separately with dd, but it s already in the ddrescue image, so there s no need. (GRUB is installed on this drive, but there is no Linux filesystem on it, so it may well exceed the size of the MBR). Note that for Linux ext[234] filesystems, debugfs can provide the same (and more) info as I got from ntfscluster. I happen to have a drive of the right size sitting here, which I was about to install in a different machine. So a wipe and a swap and a restore later, and I should be good to go. This scenario is commonplace enough that I thought I d post how I dealt with it, in case anyone else ever has hard drive issues.