I never met my father's father, as he died many years before I was born. He was a soldier in the British Army and was killed in an accident in Burma in the 1950s. I'm told that back then the Army did not repatriate casualties as a matter of course like they do today, so none of the family got to see his funeral or even visit the grave. Like many of the military casualties in the Far East, he was buried in the Colonial Cemetery in Hong Kong. A few photographs were sent to my grandmother of the ceremony and the headstone, but that's all we ever saw.

Fast forward to 2012. I travelled to Hong Kong for a conference (Linaro Connect, more about that later...). I looked up the details of where grandad was laid to rest, and found a major coincidence. He was killed on 27th May 1952, almost exactly 60 years ago! I resolved to go to find him on 27th May 2012 to make the most of this lucky anniversary. Wikipedia told me that in the intervening years the Colonial Cemetery had been renamed to Happy Valley Cemetery, then simply Hong Kong Cemetery, and repurposed from military to civilian use. Jo and I bought some flowers and headed over to Happy Valley on Hong Kong Island on Sunday afternoon. We found a very large cemetery with a helpful map posted to show the different sections, but nothing to tell us where we should be looking. One of the attendants at the office on site looked at the details we had and shrugged to say "sorry, can't help". Ah well, nobody said this was going to be very easy... What we found after a few minutes was that the graves weren't laid out in any obviously logical fashion. In any given small area, you'd find people buried from roughly the same period, but people for any given period could (and would) be scattered across multiple sections at all corners of the site. Great, time for an exhaustive search then. I started combing the site, checking all the markers I could find that looked anything like the tiny grainy black and white photo we had of grandad's headstone.

Almost two hours later, I eventually found him. Two hours of heavy work: the cemetery is built on the side of quite a steep hill, and the prevailing weather was very hot with 100% humidity. But, I forgot all that as we eventually stumbled across the correct grave in (no exaggeration!) the very last part of the last section of the site, 20a.

I was relieved at this point: as things had taken so long, I had started to worry that maybe the grave had been moved or the headstone damaged and lost. But no, I found the man who had gone off to war leaving my dad and aunt as small children. We took some photos and took note of where we had found the final resting place of Sergeant William Alexander McIntyre of the Royal Signals, a man I never met in life but clearly a very important member of our family.

My curiosity was definitely nookd by this story. While this doesn't seem to have been an act of censorship or anything nefarious by Barnes and Noble itself, this does point to just how terrifying ebooks can be if we aren't careful. In the future, when we are dealing with the entirety of human knowledge, we better be careful with the find and replace function. And we better make sure we control our computer systems so that other people can't nook us without our permission. See also:

• War and Nookd
• Nookd

As someone who read War and Peace in paper form, much of it in bed, I definitely empathized with this:

Some weeks ago I decided that I wanted to read Tolstoy's War and Peace. Lou Ann loaned me her copy. At more than 1100 pages, reading it in bed required as much strength as balancing a box of bricks in my hands. In my senior years I have developed arthritis in my thumbs, which made the effort not only difficult, but painful.

New PostgreSQL microreleases with two security fixes and several bug fixes was just announced publically. I spent the morning with the packaging orgy for Debian unstable and experimental (now uploaded), Debian Wheezy (update sent to security team), Ubuntu hardy, lucid, natty, oneiric, precise (LP #1008317) and my backports PPA. I tested these fairly thoroughly, but please let me know if you encounter any problem with these.

I have been avoiding #629247 for quite a while. Not because I think we couldn t use a better shell parser, but because I dreaded having to write the parser. Of course, #629247 blocks about 16 bugs and that number will only increase, so someone has to solve it eventually Unfortunately, that someone is likely to be me . So I managed to scrabble down the following Perl snippet. It does a decent job at getting lines split into words (which may or may not contain spaces, newlines, quotes etc.). It currently tokenizes the <<EOF -constructs (heredocs?). Also it does not allow one to distinguish between EOF and EOF (the former ends the heredoc, the latter doesn t.). Other defects includes that it does not tokenize all operators (like >& ). Probably all I need is a list of them and all the special cases (Example: >& can optionally take numbers on both sides, like >&2 or 2>&1 ). It does not always appear to terminate (I think EOF + unclosed quote triggers this). If you try it out and notice something funny, please let me know. You can also find an older version of it in the bug #629247 and the output it produced at that time (that version used instead of as token marker).

#!/usr/bin/perl
use strict;
use warnings;
use Text::ParseWords qw(quotewords);
my $opregex;
 
  my $tmp = join( " ", map   quotemeta $_   qw (&&     ; ));
  # Match & but not >& or <&
  # - Actually, it should eventually match those, but not right now.
  $tmp .= ' (?<![\>\<])\&';
  $opregex = qr/$tmp/ox;
 
my @tokens = ();
my $lno;
while (my $line = <>)  
  chomp $line;
  next if $line =~ m/^\s*(?:\# $)/;
  $lno = $. unless defined $lno;
  while ($line =~ s,\\$,,)  
  $line .= "\n" . <>;
  chomp $line;
   
  $line =~ s/^\s++//;
  $line =~ s/\s++$//;
  # Ignore empty lines (again, via "$empty \ $empty"-constructs)
  next if $line =~ m/^\s*(?:\# $)/;
  my @it = quotewords ($opregex, 'delimiters', $line);
  if (!@it)  
  # This happens if the line has unbalanced quotes, so pop another
  # line and redo the loop.
  $line .= "\n" . <>;
  redo;
   
  foreach my $orig (@it)  
  my @l;
  $orig =~ s,",\\\\",g;
  @l = quotewords (qr/\s++/, 1, $orig);
  pop @l unless defined $l[-1] && $l[-1] ne '';
  shift @l if $l[0] eq '';
  push @tokens, map   s,\\\\",",g; $_   @l;
   
  print "Line $lno: -" . join ("- -", map   s/\n/\\n/g; $_   @tokens ) . "-\n";
  @tokens = ();
  $lno = undef;
 

Here is a little example script and the tokenization of that script (no, the example script is not supposed to be useful).

$ cat test
#!/bin/sh
for p in *; do
    if [ -d "$p" ];then continue;elif
    [ -f "$p" ]
    then echo "$p is a file";fi
done
$ ./test.pl test
Line 3: -for- -p- -in- -*- -;- -do-
Line 4: -if- -[- --d- -"$p"- -]- -;- -then- -continue- -;- -elif-
Line 5: -[- --f- -"$p"- -]-
Line 6: -then- -echo- -"$p is a file"- -;- -fi-
Line 7: -done-

Probably by the time you read this, I ll be on the road to kohacon12. It s been a fun week or so with the final arrangements on top of our other planned work and some unexpected work too, but I think we ve done enough and it will all come together. (There are still a few places left if you d like to register, but not lots.) The most nerve-wracking bit has been the sponsorship. Kohacons are free to attend and funded entirely by sponsors, which is great in so many ways. It s a bit scary for the host organisation(s), but I think the community has helped so much that it ll break even. We won t know for sure until the final reckoning in a month or so. One unneeded worry was Paypal freezing our account for a couple of weeks and sending us contradictory and absurd demands for information. Why isn t there an easier way to get money out of the USA (and Australia and NZ, actually) that isn t either slow (cheques) or expensive (wire)? Once again, I m left feeling that banks are being a big problem for business. The best bit has been the spirit of the volunteers. Our co-op couldn t have done this without them. Some of them have gone a really long way to help metaphorically, bailing us out while Paypal was chewing up our time, and sometimes physically, flying around the world I ll be raising a glass to all of them, whether they re in Edinburgh or not. So, next update should be from Edinburgh!

A lot of people interested in free software, and user autonomy and network services are very worried about Facebook. Folks are worried for the same reason that so many investors are interested: the networks effects brought by hundreds of millions of folks signed up to use the service. Network effects -- the concept that a good or service increases in value as more people use it -- are not a new problem for free software. Software developers target Microsoft Windows because that is where the large majority of users are. Users with no love for Microsoft and who are otherwise sympathetic to free software use Windows because programs they need will only run there. Folks worried about Facebook are afraid for similar reasons. Sure, you can close down your Facebook account and move to Diaspora. But who will you talk to there? You can already hear people complaining about Facebook the same way they've been complaining about Windows or Office for years. People feel that their hands are tied and that their software, and their social network, will be determined by what everybody is doing. I'm worried about Facebook. But I'm not too intimidated by Facebook's network effects for two reasons. First, using Facebook doesn't preclude using anything else. Twitter has enormous overlapping functionality with Facebook. Sure, people use the systems very differently. But they both ask you to create lists of friends and followers and are designed around sending and receiving short status messages. Millions of people do both and both systems are thriving. For the millions of people who use both Facebook and Twitter, the two services have had to negotiate their marginal utility in a world they share with the other one. People decide that Twitter is for certain types of short messages and Facebook is for others. But these arrangements shift over time. And the relationships between services aren't always peaceful coexistence. Remember Friendster? Remember Orkut? Remember Tribe? Remember MySpace? MySpace, and all the others, are great examples of how social networks die. They very slowly fade away. MySpace users signed up for Facebook accounts and used both. They almost never just switched. Over time, as one platform became more attractive than the other, for many complicated reasons, attention and activity shifted. People logged in on MySpace less and Facebook more and, eventually, realized they were effectively no longer MySpace users. Anyone that has been on the Internet long enough to watch a few of these shifts from one platform to another knows that they're not abrupt -- even if they can be set in motion by a particular event or action. Users of social networking sites simply don't have to choose in the way that a person choosing to boot Windows and GNU/Linux does. I'm sure the vast majority of people with Diaspora accounts use Facebook actively. This is not a problem for Diaspora. It is how Diaspora -- or whatever else eventually achieves what many of us hoped Diaspora would -- could win. Second, Facebook is for the ephemeral. Facebook is primarily used for information that was produced very recently. This week if not today. If not this hour. Facebook has an enormous amount of data that users have fed it that may be hard to get out and move somewhere else. But most people don't care very much about having any regular access to the large majority of this information. What people care deeply about is having access to the data that they and their friends created today. And that data can just as easily be created somewhere else tomorrow. Or, with the right tools, created just as easily in both places. Compare this to something like Windows where moving away would require learning, converting, and perhaps even writing, new software. Perhaps even in new programming languages that most developers don't know yet. Compared to Windows, a migration away from Facebook will be easy. Facebook's photo galleries are an example of an important place where this holds less well. Social network information -- i.e., the list of who is friends with who -- is another example of something that is persistently valuable. That said, people really enjoy the act of finding and friending. Indeed, this process was part of the initial draw of Facebook and other social networks. None of this means that Facebook is over. It doesn't even mean that its ascendancy will be slowed. What it does mean is that Facebook is vulnerable to the next thing more than many technology firms that have benefited from network effects in the past. If users are given compelling reasons to switch to something else, they can with less trouble and they will. That compelling reason might be a new social network with better features or an awesome distributed architecture that allows freedom for users and the ability of those users to benefit from new and fantastic things that Facebook's overseers would never let them have and without the things Facebook's users suffer through today. Or it might be a sexier proprietary box to store users' private information. It doesn't mean that I'm not worried about Facebook. I remain deeply worried. It's just not very hard for me to imagine the end.

I just uploaded the online banking application AB-Transfers to Debian. This is not a finance management application like Gnucash or KMyMoney (i.e. it is not able to keep track of your incomes and expenses). Instead it is mainly intended as a companion that you can use for online transactions that these applications don't support yet. If you were using QBankmanager in the past for this purpose, please take a look at AB-Transfers and consider switching to it. As QBankmanager seems to be abandoned by the upstream author, I consider AB-Transfers the better choice for a pure online transaction application.

since most of the gcc 4.7 bugs are fixed by now, I looked again at the general RC bugs too this week. here's the usual short report:

• #650060 snort: "snort: FTBFS with multiarch libmysqlclient-dev"
  apply patch from Ubuntu / Jean-Louis Dupond, upload to DELAYED/2, then used in a maintainer upload
• #664933 src:fceu: "fceu: FTBFS: file.c:157:20: error: request for member 'have' in something not a structure or union"
  add patch from Sebastian Ramacher, upload to DELAYED/2
• #666225 src:deja-dup: "configure:3028: error: xmllint not found"
  update build dependencies, upload to DELAYED/2
• #666337 src:euler: "euler: FTBFS: gcc: error: unrecognized option '-V'"
  sponsor NMU prepared by Sebastian Ramacher, upload to DELAYED/2
• #667111 bcov: "bcov: ftbfs with GCC-4.7"
  second attempt, extend patch, upload to DELAYED/1
• #667391 telepathy-qt4: "telepathy-qt4: ftbfs with GCC-4.7"
  add patch from Cyril Brulebois, upload to DELAYED/2
• #667886 src:textedit.app: "textedit.app: FTBFS with GCC-4.7"
  apply patch from Yavor Doganov, upload to DELAYED/2
• #672356 libspread-perl: "libspread-perl: DynaLoader now requires versions to be numbers, Spread.pm uses a string."
  add patch from Andrew Ruthven, do a QA upload
• #674330 src:clamav: "clamav: FTBFS: llvm/lib/ExecutionEngine/JIT/Intercept.cpp:69:67: error: 'lseek64' was not declared in this scope"
  apply upstream patch (missing include), upload to DELAYED/2

My olduse.net exhibit has now finished replaying the first year of historical Usenet posts from 30 years ago, in real time. That was only twelve thousand messages, probably less than many people get on Facebook in a year.. but if you read along this year, you probably have a much better feel for what early Usenet was like. If you didn't, it's not too early to start, 9 years of Usenet's flowering lie ahead. I don't know how many people followed along. I read .. not every message, but a large fraction of them. I see 40 or so unique NNTP connections per day, and some seem to stick around and read for quite a while, so I'm guessing there might be a few hundred people following on a weekly basis. If you're not one of them, and don't read our olduse.net blog, here are a few of the year's highlights:

• After announcing the exhibit it hit all the big tech sites like Hacker News and Slashdot, and Boing Boing. A quarter million people loaded the front page. For a while every one of those involved a login to my server to run tin. I have some really amusing who listings. Every post available initially was read an average of 100 times, which was probably more than they were read the first go around.
• Beautiful ascii art usenet maps were posted as the network mushroomed; I collected them all. In a time-delayed collaboration with Mark, I produced a more modern version.
• We watched sites struggle with the growth of usenet, and followed along as B-news was developed and deployed.
• In 2011, Dennis Richie passed. We still enjoy his wit and insight on olduse.net.
• We enjoyed the first posts of things like The Hacker's Dictionary and DEC Wars.
• Some source code posted to usenet still compiles. I haven't found anything to add to Debian, yet. :)

I will probably be expiring the first year's messages before too long, to have a more uncluttered view. So if you wanted to read them, hurry up!

I've been using a Google account since years, but having a "more serious" one along. The time has come to make the switch and elect the other as main one.

Google has a lot of services, and I'm using several of them, so changing the main account requires to migrate data of those services to the new account, given it's not possible to merge two accounts. To know the full list of services your account is signed in, go to your Account Product page. Some migrations are easy, others hell no: so I'm writing this post to keep track of the migration as it's going on.

First of all, there's a really good post about this migration at LifeHacker: it contains a lot of info I'm using here, but not all the services I need. Additionally, Google has a list of services and methods to migrate from one account to another.

Just to be generic, I'll call AccountSRC the original account and AccountDST the one I want to migrate to.

Migrate GMail

GMail is probably the most important service I have, and also the most difficult one to migrate. I have a lot of filters, so the first step is to migrate them:

1. Login into GMail for AccountSRC
2. Gear icon > Settings > Labs
3. Enable the "Filter import/export" plugin
4. Reload GMail to enable the plugin (if not done automatically)
5. Gear icon > Settings > Filters
6. At the bottom of the page, Select all
7. Export: this will download an XML file with the filters in it
8. Login into GMail for AccountDST
9. Enable "Filter import/export" plugin
10. Load the file containing the saved filters
11. Import all (or select which one) filters; this will also create automatically the labels defined in the filters.

I currently have a forward rule from AccountDST to AccountSRC: so let's revert the forward direction: from AccountSRC to AccountDST. This will allow the new account to receive the mails sent to the old one.

1. Login into GMail for AccountDST
2. Gear icon > Forwarding and POP/IMAP > Disable forwarding: this will stop redirecting mails from AccountDST to AccountSRC
3. Login into GMail for AccountSRC
4. Gear icon > Forwarding and POP/IMAP > add a forwarding address
5. Enter AccountDST as the address to forward mails to
6. A verification code is sent to AccountDST and you'll need to enter that code in AccountSRC to verify you have access to both mailboxes
7. Once verified, select "Forward a copy of incoming mail to" to AccountDST and to delete the GMail copy on AccountSRC

Migrate Contacts

Contacts are available inside GMail:

1. Login into GMail for AccountSRC
2. On the combobox on top-left, select Contacts
3. More > Export
4. Export all the contacts in Google CSV, since it's specific to be re-imported
5. Login into GMail for AccountDST
6. Contacts > More > Import
7. Select the previously saved file and import it

Migrate Reader

Migrating Reader subscriptions is easy:

1. Login into Reader for AccountSRC
2. Reader Settings -> Import/export
3. Export your subscriptions in OPML format
4. Now login into Reader for AccountDST
5. Reader Settings -> Import/export
6. And import the saved OPML file

Migrate Blogger

Login to Blogger for AccountSRC; then, for each blog you have there do this dance:

1. Select the blog
2. Go into Settings > Permissions
3. Add AccountDST as a new author: this will send an email to AccountDST GMail account
4. Accept the invitation (this will ask you to create a new Blogger account for AccountDST if you don't already have one)
5. Go back to to Blogger with AccountSRC
6. Blog > Settings > Permissions
7. Grand admin rights to AccountDST

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 May 21

• Cloned Dose3 and made it build
• Retrieved bootstrap.ml and bootstrap2.ml from old revisions as they were deleted
• Compiled, tested and investigated the functionality of bootstrap.ml and bootstrap2.ml on a theoretical level as no test data was available

May 22

• Pietro sends me a tarball with his current version of bootstrap.ml and dummy as well as real test data
• Created a gitorious account, project and repository
• Compiled, tested and investigated his code
• Ran into several runtime problems with the supplied dummy examples
• Created Makefile to automatically fill ./examples/real/
• Found that .dot files are too big to be rendered
• Trying to figure out how hints work, how base-system was generated and why execution takes hours

May 23

• Pietro made examples work which let me understand the code much more
• Improvement of .dot output and output formatting
• Refactored code into bootstrapCommon.ml for shared functionality and bootstrap.ml for option parsing and main()

May 24

• Play with xdeb.py
• Generate dot graphs with bootstrap.ml and analyze them with sccmap
• Try to find a way to have a reduced package selection other than main archives of ubuntu/debian
• Initial work on trying to find the list of minimal source packages that have to be cross compiled
• Create debian-bootstrap@lists.mister-muffin.de mailinglist

May 25

• Implement a replacement for apt-rdepends and grep-dctrl functionality in ocaml, both working on Package files
• Retrieve list of packages with priority:required
• Retrieve their runtime dependencies
• Retrieve the packages that are added with build-essential and dependencies
• Retrieve the list of source packages that are needed to build the above
• Retrieve list of binary packages that are build from the source packages in addition
• some more functionality in the Makefile

May 29

• Depsolver.dependency_closure replaces homebrew functionality in a better and faster way
• Only consider those binary packages that can actually be installed, given the limited amount of available packages using Depsolver.edos_install
• Create proper list diff by correctly comparing Cudf.package members

May 30

• Big code restructuring
• consider arch:all packages to be available by default
• Got helpful sourcecode comments by Pietro

May 31

• Use Depsolver.trim to reduce a universe to the installable packages
• Compile with dose 2.9.17

June 1

• Basebuildsystem now also writes output to min-cross-sources.list and base-system.list
• Begin work on basenocycles.ml to see how much the minimal system can build without cycle breaking

June 2

• Use Depsolver.trim to find source packages that can be built given the restricted universe
• Find the final list of packages that are available without solving staged build dependencies for Natty
• Many code simplifications

Results I learned a good chunk of ocaml and how to use dose3 and libcudf. I created a gitorious project and a git repository for all the sourcecode.

git clone git://gitorious.org/debian-bootstrap/bootstrap.git

The git as of now contains 30 commits and 1197 lines of ocaml code. So far, 62 emails have been exchanged between me and Pietro and Wookey. I created a mailinglist for this project where all email exchange so far is publicly accessible in the archives. You can also download all of the email exchange in mbox format. Everybody is welcome to join and/or read the list. What seems to be finished: the program that finds the minimal amount of source packages that have to be cross compiled to end up with a minimal build system. What it does is:

1. get all essential packages
2. get their runtime dependencies
3. get build-essential plus runtime dependencies
4. get all source packages that are necessary to build 1.-3. those are the packages that have to be cross compiled
5. get a list of all packages that are built by source packages from 4.
6. add all packages from 1.,2.,3. and 5. plus all arch:all packages to a universe
7. use Depsolver.trim on that universe to figure out which of those packages are actually installable

The result of 7. will then contain a list of packages that are available automatically on the foreign system due to cross compiled source packages and arch:all packages. For Debian Sid, the output of my program is:

# (1) number of packages with priority:required: 62
# (2) plus, number of dependencies of priority:required packages: 20
# (3) plus, build-essential and dependencies: 31
# number of source packages to build the above: 71
# number of additional packages built from the above source packages: 292
# (4) number of packages of those plus arch:all packages that are installable: 6421
# total number of installable packages (1)+(2)+(3)+(4): 6534

For Ubuntu Natty it is:

# (1) number of packages with priority:required: 96
# (2) plus, number of dependencies of priority:required packages: 7
# (3) plus, build-essential and dependencies: 31
# number of source packages to build the above: 87
# number of additional packages built from the above source packages: 217
# (4) number of packages of those plus arch:all packages that are installable: 2102
# total number of installable packages (1)+(2)+(3)+(4): 2236

So for Debian, 71 source packages definitely have to be made cross compilable while for Natty, the number is 87. The last two days I was toying around with these minimal systems to see how big the number of source packages is, that can be built on top of them without running into dependency cycles. After installing the binary packages that were built, I checked again until no new packages could be built. For Natty, I was only able to find 28 additional packages that can be built on top of the 2236 existing ones. This means that a number of dependency cycles prevent building anything else. In the coming two weeks I will focus on coming up with a tool that cleverly helps the user to identify packages that would be useful to have for building more packages (probably determined by how many packages depend on it - debhelper is an obvious candidate). The tool would then show why that crucial package is not available (in case of debhelper because some of its runtime dependencies are not available and require debhelper to be built) and how the situation can best be resolved. The possible methods to do so are to identify a package that is part of a cycle and either cross compile it or let it have staged build dependencies.

When packaging software for Debian, there exist two important assumptions:

1. Compilation is done natively
2. Potentially all of Debian is available at compile time

Both assumptions make the life of a package maintainer much easier and they do not create any problem unless you are one of the unlucky few who want to run Debian on an architecture that it does not yet exist for. You will then have to use other distributions like OpenEmbedded or Gentoo which you compiled (or retrieved otherwise) for that new architecture to hack a core of Debian source packages until they build a minimal Debian system that you can chroot into and continue natively building the rest of it. But even if you manage to get that far you will continue to be plagued by cyclic build and runtime dependencies. So you start to hack source packages so that they drop some dependencies and you can break enough cycles to advance step by step. The Debian ports page lists 24 ports of Debian, so despite its unpleasant nature, porting it is something that is not done seldom. The process as laid out above has a number of drawbacks:

• The process is mostly manual and reinvented every time it is done.
• You need another distribution for the bootstrapping process. Debian itself should be sufficient.
• Its complexity and manual nature prevents architectures with little workforce behind them from catching up to the main archive.
• It also avoids that Debian exists in CPU optimized sub-arch builds.

If Debian would provide a set of core packages that are cross-compilable and which suffice for a minimal foreign build system, and if it would also have enough source packages that provide a reduced build dependency set so that all dependency cycles can be broken, building Debian for a yet unknown architecture could be mostly automated. The benefits would be:

• Putting Debian on a foreign architecture would (in the best case) boil down to making the code cross-compile for and native-compile on that architecture.
• Debian would not need any other distribution to be ported to a different architecture. This would make Debian even more "universal".
• Lagging architectures can be more easily updated or rebooted than when they were initially created.
• Debian optimized for specific CPUs (Raspberry Pie, OpenMoko...) would be more attractive.

With three of this year's GSoC projects, this dream seems to come into reach. There is the "Multiarch Cross-Toolchains" project by Thibaut Girka and mentored by Hector Oron and Marcin Juszkiewicz. Cross-compiling toolchains need packages from the foreign architecture to be installed alongside the native libraries. Cross-compiler packages have been available through the emdebian repositories but always were more of a hack. With multiarch, it is now possible to install packages from multiple architectures at once, so that cross-compilation toolchains can be realized in a proper manner and therefor can also enter the main archives. Besides creating multiarch enabled toolchains, he will also be responsible for making them build on the Debian builld system as cross-architecture dependencies are not yet supported. There is also the "Bootstrappable Debian" project by Patrick "P. J." McDermott and mentored by Wookey and Jonathan Austin. He will make a small set of source packages multiarch cross-compilable (using cross-compilers provided by Thibaut Girka) and add a Build-Depends-StageN header to critical packages so that they can be built with reduced build dependencies for breaking dependency cycles. He will also patch tools as necessary to recognize the new control header. And then there is my project: "Port bootstrap build-ordering tool" (Application). It is mentored by Wookey and Pietro Abate. In contrast to the other two, my output will be more on the meta-level as I will not modify any actual Debian package or patch Debian tools with more functionality. Instead the goal of this project is threefold:

1. find the minimal set of source packages that have to be cross compiled
2. help the user to find packages that are good candidates for breaking build dependency cycles through added staged build dependencies or by making them cross-compilable
3. develop a tool that takes the information about packages that can be cross compiled or have staged build dependencies to output an ordering with which packages must be built to go from nothing to a full archive

More on that project in my follow-up post.

She s awesome!


# dpkg --add-architecture kfreebsd-amd64
# dpkg -i libc0.1-dev_2.13-32_kfreebsd-amd64.deb
Selecting previously unselected package libc0.1-dev.
(Reading database ... 446113 files and directories currently installed.)
Unpacking libc0.1-dev (from libc0.1-dev_2.13-32_kfreebsd-amd64.deb) ...
dpkg: error processing libc0.1-dev_2.13-32_kfreebsd-amd64.deb (--install):
trying to overwrite '/usr/include/_G_config.h', which is also in package libc6-dev 2.13-32
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
libc0.1-dev_2.13-32_kfreebsd-amd64.deb
Before multiarch the bug was not existing, and of course none of libc6-dev and libc0.1-dev are marked as Multi-Arch: something. People wanting to delay the release of Wheezy, I am sure you can find much more RC bugs like that.

Users of Debian sid will have noticed: the final (and interesting) bits of GNOME 3.4 have landed and if all looks as good as it does now, they should migrate to wheezy in about a week. 3.2 3.4 hasn't been as complicated as the previous horrible transition, but still had some complications due to Cogl/Clutter incompatibilities. Other than that, our major problem has been manpower, but this isn't new for many other Debian teams. We've also seen new incarnations of Linux-only technology is now mandatory which makes our lives a bit more miserable due to kfreebsd-* and hurd-i386, but for now we've still been able to dodge it. It seems wheezy+1 will be fun in that regard though, and we might need to take drastic approaches. If all goes well and the current lot (GNOME Shell, Control Center, Settings daemon, Mutter...) transitions without additional problems, we should be wrapping up our transitions for wheezy with Evolution and friends (currently sitting in experimental), and hopefully GDM 3.4. As we get many questions regarding the status of GDM in Debian, let's add a short note on this. Packaging GDM, at least in its current upstream form, is not a matter of unpacking a new tarball and editing debian/changelog. When Joss works on a new major version, the amount of tweaking to break away from stuff that works on other distros but is not so simple in Debian is outstanding (see, for example, the current unfinished work for GDM 3.2 in our SVN repo). In our case, to handle our GDM defaults, we even need changes to the underlying configuration system, dconf. This evidently takes some effort to do, and unfortunately our GDM expert has had little time for Debian lately, but we're confident we'll end up with a GDM in wheezy that is on par with Debian standards. We are, as always, reachable at #debian-gnome in the OFTC IRC network. Have fun!

I needed to resize about 300 images and couldn t find an easier way to do this than with help of node + CoffeeScript. So here s my script, it requires you to install (via npm) imagemagick and underscore: <script src="https://gist.github.com/2862235.js?file=resize.coffee"></script> Grab it if you want, is under Do Whatever You Want license. As you can see from the shebang (that s the first line of the script, with the #!) I ran it from my command-line, this was not used in a website, although it could without too much modifications (the magic of JavaScript).

Back in 2010, Mike Gabriel showed up on the Debian Edu and Skolelinux mailing list. He quickly proved to be a valuable developer, and thanks to his tireless effort we now have Kerberos integrated into the Debian Edu Squeeze version. Who are you, and how do you spend your days? My name is Mike Gabriel, I am 38 years old and live near Kiel, Schleswig-Holstein, Germany. I live together with a wonderful partner (Angela Fu ) and two own children and two bonus children (contributed by Angela). During the day I am part-time employed as a system administrator and part-time working as an IT consultant. The consultancy work touches free software topics wherever and whenever possible. During the nights I am a free software developer. In the gaps I also train in becoming an osteopath. Starting in 2010 we (Andreas Buchholz, Angela Fu , Mike Gabriel) have set up a free software project in the area of Kiel that aims at introducing free software into schools. The project's name is "IT-Zukunft Schule" (IT future for schools). The project links IT skills with communication skills. How did you get in contact with the Skolelinux/Debian Edu project? While preparing our own customised Linux distribution for "IT-Zukunft Schule" we were repeatedly asked if we really wanted to reinvent the wheel. What schools really need is already available, people said. From this impulse we started evaluating other Linux distributions that target being used for school networks. At the end we short-listed two approaches and compared them: a commercial Linux distribution developed by a company in Bremen, Germany, and Skolelinux / Debian Edu. Between 12/2010 and 03/2011 we went to several events and met people being responsible for marketing and development of either of the distributions. Skolelinux / Debian Edu was by far much more convincing compared to the other product that got short-listed beforehand--across the full spectrum. What was most attractive for me personally: the perspective of collaboration within the developmental branch of the Debian Edu project itself. In parallel with this, we talked to many local and not-so-local people. People teaching at schools, headmasters, politicians, data protection experts, other IT professionals. We came to two conclusions: First, a technical conclusion: What schools need is available in bits and pieces here and there, and none of the solutions really fit by 100%. Any school we have seen has a very individual IT setup whereas most of each school's requirements could mapped by a standard IT solution. The requirement to this IT solution is flexibility and customisability, so that individual adaptations here and there are possible. In terms of re-distributing and rolling out such a standardised IT system for schools (a system that is still to some degree customisable) there is still a lot of work to do here locally. Debian Edu / Skolelinux has been our choice as the starting point. Second, a holistic conclusion: What schools need does not exist at all (or we missed it so far). There are several technical solutions for handling IT at schools that tend to make a good impression. What has been missing completely here in Germany, though, is the enrolment of people into using IT and teaching with IT. "IT-Zukunft Schule" tries to provide an approach for this. Only some schools have some sort of a media concept which explains, defines and gives guidance on how to use IT in class. Most schools in Northern Germany do not have an IT service provider, the school's IT equipment is managed by one or (if the school is lucky) two (admin) teachers, most of the workload these admin teachers get done in there spare time. We were surprised that only a very few admin teachers were networked with colleagues from other schools. Basically, every school here around has its individual approach of providing IT equipment to teachers and students and the exchange of ideas has been quasi non-existent until 2010/2011. Quite some (non-admin) teachers try to avoid using IT technology in class as a learning medium completely. Several reasons for this avoidance do exist. We discovered that no-one has ever taken a closer look at this social part of IT management in schools, so far. On our quest journey for a technical IT solution for schools, we discussed this issue with several teachers, headmasters, politicians, other IT professionals and they all confirmed: a holistic approach of considering IT management at schools, an approach that includes the people in place, will be new and probably a gain for all. What do you see as the advantages of Skolelinux/Debian Edu? There is a list of advantages: international context, openness to any kind of contributions, do-ocracy policy, the closeness to Debian, the different installation scenarios possible (from stand-alone workstation to complex multi-server sites), the transparency within project communication, honest communication within the group of developers, etc. What do you see as the disadvantages of Skolelinux/Debian Edu? Every coin has two sides: Technically: BTS issue #311188, tricky upgradability of a Debian Edu main server, network client installations on top of a plain vanilla Debian installation should become possible sometime in the near future, one could think about splitting the very complex package debian-edu-config into several portions (to make it easier for new developers to contribute). Another issue I see is that we (as Debian Edu developers) should find out more about the network of people who do the marketing for Debian Edu / Skolelinux. There is a very active group in Germany promoting Skolelinux on the bigger Linux Days within Germany. Are there other groups like that in other countries? How can we bring these marketing people together (marketing group A with group B and all of them with the group of Debian Edu developers)? During the last meeting of the German Skolelinux group, I got the impression of people there being rather disconnected from the development department of Debian Edu / Skolelinux. Which free software do you use daily? For my daily business, I do not use commercial software at all. For normal stuff I use Iceweasel/Firefox, Libreoffice.org. For serious text writing I prefer LaTeX. I use gimp, inkscape, scribus for more artistic tasks. I run virtual machines in KVM and Virtualbox. I am one of the upstream developers of X2Go. In 2010 I started the development of a Python based X2Go Client, called PyHoca-GUI. PyHoca-GUI has brought forth a Python X2Go Client API that currently is being integrated in Ubuntu's software center. For communications I have my own Kolab server running using Horde as web-based groupware client. For IRC I love to use irssi, for Jabber I have several clients that I use, mostly pidgin, though. I am also the Debian maintainer of Coccinella, a Jabber-based interactive whiteboard. My favourite terminal emulator is KDE's Yakuake. Which strategy do you believe is the right one to use to get schools to use free software? Communicate, communicate, communicate. Enrol people, enrol people, enrol people.

In case this went unnoticed, Iceweasel ESR has been available in squeeze-backports for a few weeks, now. I highly recommend anyone using Iceweasel on the Debian stable release to upgrade to that version, at the very least. Even newer versions are available through the pkg-mozilla archive.

So, I m taking vacation this week and next. Here s a (partial) list of tasks that are left to do:

• Visit BC for NANOG 55
• Work with Threshold Communications to verify interop is working as well as it seems to be
• Make sure the UTC has acknowledged receipt of our 2012 filing
• Complete move of storage from old chassis to new-ish hot-ish-ness
• Bring one of these chassis online to handle VoIP for the wireless L2 segment
• Bring a 1600 online at our Bartel POP
• Take the disk image created for the above and duplicate it 3x for California-based 44Net nodes
• Bring the VMs whose storage was being provisioned via iSCSI back online
• get the ATA and DSLAM online and hook up the customers who are demanding service.
• Call CenturyLink and explain to them that I WILL report them to the consumer protection department of the Utilities and Transportation Commission if they do not take action to correct their failure in regard to contract negotiation and accounting.

That s probably enough, if not too much. Here s some of the bits I ve done this week:

• Re-establish IPv6 connectivity for many of my hosts
• Twiddled quite a few bits on the BIG-IPs
• Set up a home brew provisioning server for some 1120E hardware SIP phones I ve got laying around (DHCP + TFTP + a bunch of twiddly firmware bits and config files ping me if you want them)
• Did a lot of updates to the DNS infrastructure. We have slave DNS servers in all of our DCs now
• hung out on IRC a lot
• Started accepting IPv4 HTTP requests for web.colliertech.org in Bothell instead of Tukwila
• Put together some perl & php for the WA NGB to help with their online recruiter finder
• Reduced size of SAN base OS (squeeze) to something that fits on a CF
• Moved disks from old SAN chassis to the new one.
• Booting from CF now instead of first partition of first disk in array
• Discovered small (~3k bytes) disk error on one of the RAID members
• Made complete backup of entire array using dd
• Replaced failing disk and began recovery, with great thanks to the linux-raid list

  md0 : active raid5 sdg2[6] sdc2[4] sdb2[3] sdd2[2] sdf2[1] sde2[0]
        4864240640 blocks level 5, 64k chunk, algorithm 2 [6/5] [UUUUU_]
        [=========>...........]  recovery = 46.9% (456668928/972848128) finish=1461.9min speed=5884K/sec
  

• Brought up 802.11g AP for wireless VoIP service
• Configured asterisk to accept 24 SIP lines from GrandStream ATA
• Brought GrandStream ATA online. Currently sending SIP/RTP calls over OpenVPN tunnel to avoid NAT issues. This will be corrected when the new asterisk server is brought online. I ll have it connect to the core with IAX, and it will be on the same physical L2 as the GrandStream and 1120Es
• recovered RAID-1 array on laptop
• made sure KE7KMO is still functioning

And probably some other stuff ;-)

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:	1412
Affecting Wheezy:	977
Wheezy only:	272
Remaining to be fixed in Wheezy:	705

Of these 705 bugs, the following tags are set:

Pending in Wheezy:	51
Patched in Wheezy:	118
Duplicates in Wheezy:	57
Can be fixed in a security Update:	24
Contrib or non-free in Wheezy:	9
Claimed in Wheezy:	2
Delayed in Wheezy:	4
Otherwise fixed in Wheezy:	99

Ignoring all the above (multiple tags possible) 427 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 867 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.