Updated 22/06/2012: Reference to Canonical's response

A couple of people have asked me about the Ubuntu ODM UEFI requirements, specifically the secure boot section. This is aimed at hardware vendors who explicitly want to support Ubuntu, so it's not necessarily the approach Canonical will be taking for installing Ubuntu on average consumer hardware. But it's still worth looking at.

In a nutshell, the requirements for secure boot are:

• The system must have an Ubuntu key preinstalled in each of KEK and db
• It must be possible to disable secure boot
• It must be possible for the end user to reconfigure keys

It's basically the same set of requirements as Microsoft have, except with an Ubuntu key instead of a Microsoft one.

The significant difference between the Ubuntu approach and the Microsoft approach is that there's no indication that Canonical will be offering any kind of signing service. A system carrying only the Ubuntu signing key will conform to these requirements and may be certified by Canonical, but will not boot any OS other than Ubuntu unless the user disables secure boot or imports their own key database. That is, a certified Ubuntu system may be more locked down than a certified Windows 8 system.

(Practically speaking this probably isn't an issue for desktops, because you'll need to carry the Microsoft key in order to validate drivers on any PCI cards. But laptops are unlikely to run external option ROMs, so mobile hardware would be viable with only the Ubuntu key)

There's two obvious solutions for this:

1. Canonical could offer a signing service. Expensive and awkward, but obviously achievable. However, this isn't a great solution. The Authenticode format used for secure boot signing only permits a single signature. Anything signed with the Ubuntu key cannot also be signed with any other key. So if, say, Fedora wanted to install on these systems without disabling secure boot first, you'd need to have two sets of install media - one signed with the Ubuntu key for Ubuntu hardware, one signed with the Microsoft key for Windows hardware.
2. Require that ODMs include the Microsoft key as well as the Ubuntu key. This maintains compatibility with other operating systems.

This kind of problem is why we didn't argue for a Fedora-specific signing key. While it would have avoided a dependence on Microsoft, it would have created an entirely different kind of vendor lock-in.

Update: Canonical have now provided their full plans. They won't be providing a signing service, but will be requiring that all Ubuntu-certified hardware ship with the Microsoft key

comments

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.

(This blog post is a more firm version of a series of tweets and forum posts I made a few weeks ago. This should also be considered a refresh of this post by Mirco Bauer a few years ago) It has been said that Mono is bloated, and that people should use lighter frameworks that don t pull in hundreds of meg . How much basis in reality is there for those comments? Well, let s do a little thought exercise. How much space is the minimum space needed for several languages to work? For this experiment, we will be looking at the required installation size on disk of several language frameworks, each time installing the bare minimum for a command-line hello world app in that language to run. For example, the Ruby result is the minimum install required to run:

puts 'Hello world'

and the Mono result is the minimum install required to run the following code, which has been compiled on a different machine using dmcs :

public class Hello1
 
   public static void Main()
    
      System.Console.WriteLine("Hello, World!");
    
 

Obviously, for dynamic languages like Ruby and Python, there is no compiler step needed. For languages like C# and Java, it is fair to compile these on a different machine as end-users of packages running these frameworks receive binaries, not source they do not need a development environment. So, on to the test environment. This is a bare bootstrapped AMD64 Debian Unstable system, as of today (i.e. debootstrap sid /tmp/badger ). Its install size is 275MB. So how much space? Ruby 1.9 Test code is as follows:

puts 'Hello world'

Install requirements are as follows:

root@dream:/# aptitude install ruby1.9.1
The following NEW packages will be installed:
  libffi5 a  libruby1.9.1 a  libyaml-0-2 a  ruby1.9.1 
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 4703 kB of archives. After unpacking 13.1 MB will be used.

OpenJDK 7 Test code is as follows:

class HelloWorldApp  
    public static void main(String[] args)  
        System.out.println("Hello world");
     
 

Install requirements are as follows:

root@dream:/# aptitude install openjdk-7-jre-headless
The following NEW packages will be installed:
  ca-certificates a  ca-certificates-java a  dbus a  fontconfig-config a  
  icedtea-7-jre-cacao a  icedtea-7-jre-jamvm a  java-common a  
  krb5-locales a  libavahi-client3 a  libavahi-common-data a  
  libavahi-common3 a  libcap2 a  libcups2 a  libdbus-1-3 a  libexpat1 a  
  libffi5 a  libfontconfig1 a  libfreetype6 a  libglib2.0-0 a  
  libglib2.0-data a  libgssapi-krb5-2 a  libjpeg8 a  libk5crypto3 a  
  libkeyutils1 a  libkrb5-3 a  libkrb5support0 a  liblcms2-2 a  libnspr4 a  
  libnss3 libnss3-1d a  libpcre3 a  libpcsclite1 a  libsystemd-login0 a  
  libxml2 a  openjdk-7-jre-headless openjdk-7-jre-lib a  openssl a  
  sgml-base a  shared-mime-info a  ttf-dejavu-core a  tzdata-java a  ucf a  
  xml-core a  
0 packages upgraded, 43 newly installed, 0 to remove and 0 not upgraded.
Need to get 51.5 MB of archives. After unpacking 137 MB will be used.

Python 3.2 Test code is as follows:

print ("Hello world")

Install requirements are as follows:

root@dream:/# aptitude install python3.2-minimal
The following NEW packages will be installed:
  file a  libexpat1 a  libffi5 a  libmagic1 a  mime-support a  python3.2 a  python3.2-minimal 
0 packages upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 4853 kB of archives. After unpacking 17.7 MB will be used.

Mono 2.10 (C#) Test code is as follows:

public class Hello
 
   public static void Main()
    
      System.Console.WriteLine("Hello world");
    
 

Install requirements are as follows:

root@dream:/# aptitude install mono-runtime
The following NEW packages will be installed:
  binfmt-support a  cli-common a  libmono-corlib4.0-cil a  libmono-i18n-west4.0-cil a  libmono-i18n4.0-cil a  
  libmono-security4.0-cil a  libmono-system-configuration4.0-cil a  libmono-system-security4.0-cil a  
  libmono-system-xml4.0-cil a  libmono-system4.0-cil a  mono-4.0-gac a  mono-gac a  mono-runtime 
0 packages upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 4383 kB of archives. After unpacking 11.5 MB will be used.

Of course, every time I try to make the argument that Mono is much leaner than what people propose as an alternative, the anti-Mono brigade go on the defensive and insist that nobody in their right minds uses Python or Ruby either everything ever should be written in Qt. So, hypothetically Qt 4.8 (C++) Test code is as follows:

#include <QTextStream>
int main(int argc, char **argv)
 
   QTextStream s(stdout);
   s << "Hello, world!\n";
   return 0;
 

Install requirements are as follows:

root@dream:/# aptitude install libqtcore4
The following NEW packages will be installed:
  libffi5 a  libglib2.0-0 a  libglib2.0-data a  libpcre3 a  libqtcore4 
  libxml2 a  sgml-base a  shared-mime-info a  xml-core a  
0 packages upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.3 MB of archives. After unpacking 27.8 MB will be used.

Presented without comment for your consideration. Edit: There are complaints that these numbers are misleading, because they show default package manager behaviour, rather than what happens when passing extra flags or config file settings to Apt. When disabling installation of Recommends: packages, the numbers change as follows:

• openjdk-7-jre-headless 137 MB -> 116 MB
• ruby1.9.1 13.1 MB -> 13.1 MB
• python3.2-minimal 17.7 MB -> 6.1 MB
• mono-runtime 11.5 MB -> 10.9 MB
• libqtcore4 27.8 MB -> 13.7 MB

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.

I will sound monothematic, but I have been devoting quite a bit of work to this topic lately: Trying to stop the advance of e-voting in Mexico, Latin America and the world. Why trying to stop it? Isn't technology supposed to help us, to get trustable processes? Yes, it's supposed to... but it just cannot achieve it, no matter how hard it is tried I won't get into explanations in this blog post, but there is plenty of information. Feel free to ask me for further details. Anyway Yesterday (Sunday, 2012-06-17) was the fifth simulated voting that will lead to the first wide-scale deployment of electronic voting booths in my country: About 10% of the population of the state of Jalisco (that means, ~500,000 people) will cast their votes on July 1st electronically. This particular case illustrates how simulated votings can be used to forge a lie: Pounce Consulting, the company that won the e-voting project for IEPC (Jalisco's voting authority), delivered their booths over 40 days late, just before the deadline for the project to be canceled. Oh, and by the way, it's the same company that just failed to deliver on time for another planned local authority (10% of the booths in the Federal District, where I live, where fortunately 100% of the votes will be cast on traditional, auditable and cheap paper). After this delay, five voting simulations were programmed, to get the local population acquinted with them. The first ones just failed to get the population's interest and had close to 40% failure rates (mainly regarding transmission). Several other "minor details" were reported, including mechanical details that allowed subsequent voters to see the vote of who had just left. Anyway, making long story short: The fifth and last simulation was held yesterday. Officially, it was finally successful (about time). As these booths include the "facilities" to communicate the results via the cellular network, but the populations where they are to be deployed do not yet have cellular coverage, 10% of the booths will have to be carried back to the Districtal Header (that can be a ~10hr trip) to be counted. Also, in all places, traditional paper stationery and paraphernalia will be printed just in case it is needed (and when will they now? When half of the votes are cast and lost?) Anyway... e-voting is still in its first stage in Mexico. Right now, I'm sure, no attempts to rig the election will be made (centrally). But every effort will be made (as it has been made) to dismiss the obviously big and nontrivial ways it has failed and will fail, and any problems will be labeled as "minor". And probably by 2018 we will be facing many more states (even nationwide) deployments. But propaganda fails to see the obvious: E-voting is more expensive, more complicated, leads to more possible failure states. E-voting should not be deployed in large-scale (i.e. more than a couple of hundred voters) elections. Electronic voting is insecure, violates secrecy, allows for fraud. No matter how many locks are put into it.

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.

I have published PowerDNS version 3.1-1.0 on https://ivanova.notwork.de/~mh/debian/pdns/ This is a preliminary package and a release candidate to be 3.1-2 in Debian. If you re interested in PowerDNS on Debian, please test this package. I plan to upload next week. This package will vanish from the web server once the package is visible in Debian.

Debian is such a universal system:

# apt-get install wine and cheese
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  brasero brasero-common cheese-common desktop-file-utils evolution-data-server-common gcr gir1.2-atk-1.0 gir1.2-clutter-1.0 gir1.2-clutter-gst-1.0 gir1.2-cogl-1.0
  gir1.2-coglpango-1.0 gir1.2-evince-3.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-gst-plugins-base-0.10 gir1.2-gstreamer-0.10 gir1.2-gtk-3.0 gir1.2-gtkclutter-1.0
  gir1.2-gtksource-3.0 gir1.2-json-1.0 gir1.2-pango-1.0 gnome-desktop3-data gnome-icon-theme gnome-keyring gnome-sushi gnome-video-effects gstreamer0.10-plugins-ugly gvfs
  gvfs-backends gvfs-common gvfs-daemons gvfs-libs hwdata libbrasero-media3-1 libburn4 libcamel-1.2-29 libcap2-bin libcdio-cdda1 libcdio-paranoia1 libcdio13 libcheese-gtk21
  libcheese3 libclutter-1.0-0 libclutter-1.0-common libclutter-gst-1.0-0 libclutter-gtk-1.0-0 libclutter-imcontext-0.1-0 libcluttergesture-0.0.2-0 libcogl-common libcogl-pango0
  libcogl9 libebook-1.2-12 libecal-1.2-10 libedataserver-1.2-15 libedataserverui-3.0-1 libevdocument3-4 libevview3-3 libexempi3 libgck-1-0 libgcr-3-1 libgcr-3-common libgee2
  libgjs0b libglib2.0-data libgnome-desktop-3-2 libgssdp-1.0-3 libgupnp-1.0-4 libgxps2 libisofs6 libjson-glib-1.0-0 libjte1 libmozjs185-1.0 libmpg123-0 libmx-1.0-2 libmx-bin
  libmx-common libnautilus-extension1a libpam-cap libpam-gnome-keyring libpoppler-glib8 libpoppler19 libquvi-scripts libquvi7 libsidplay1 libt1-5 libtotem-plparser17
  libtracker-sparql-0.14-0 libwine libwine-alsa libwine-bin libwine-gecko-1.4 libwine-gl nautilus nautilus-data nautilus-sendto wine-bin
Suggested packages:
  libdvdcss2 gnome-video-effects-frei0r libcap-dev sidplay-base xsidplay wine-doc libwine-cms libwine-sane libwine-ldap libwine-print libwine-openal libwine-gphoto2 eog
  xdg-user-dirs tracker pidgin gajim ttf-mscorefonts-installer winbind avscan klamav clamav 
The following NEW packages will be installed:
  and brasero brasero-common cheese cheese-common desktop-file-utils evolution-data-server-common gcr gir1.2-atk-1.0 gir1.2-clutter-1.0 gir1.2-clutter-gst-1.0 gir1.2-cogl-1.0
  gir1.2-coglpango-1.0 gir1.2-evince-3.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-gst-plugins-base-0.10 gir1.2-gstreamer-0.10 gir1.2-gtk-3.0 gir1.2-gtkclutter-1.0
  gir1.2-gtksource-3.0 gir1.2-json-1.0 gir1.2-pango-1.0 gnome-desktop3-data gnome-icon-theme gnome-keyring gnome-sushi gnome-video-effects gstreamer0.10-plugins-ugly
  gvfs-backends hwdata libbrasero-media3-1 libburn4 libcamel-1.2-29 libcap2-bin libcdio-cdda1 libcdio-paranoia1 libcdio13 libcheese-gtk21 libcheese3 libclutter-1.0-0
  libclutter-1.0-common libclutter-gst-1.0-0 libclutter-gtk-1.0-0 libclutter-imcontext-0.1-0 libcluttergesture-0.0.2-0 libcogl-common libcogl-pango0 libcogl9 libebook-1.2-12
  libecal-1.2-10 libedataserver-1.2-15 libedataserverui-3.0-1 libevdocument3-4 libevview3-3 libexempi3 libgck-1-0 libgcr-3-1 libgcr-3-common libgee2 libgjs0b libglib2.0-data
  libgnome-desktop-3-2 libgssdp-1.0-3 libgupnp-1.0-4 libgxps2 libisofs6 libjson-glib-1.0-0 libjte1 libmozjs185-1.0 libmpg123-0 libmx-1.0-2 libmx-bin libmx-common
  libnautilus-extension1a libpam-cap libpam-gnome-keyring libpoppler-glib8 libpoppler19 libquvi-scripts libquvi7 libsidplay1 libt1-5 libtotem-plparser17 libtracker-sparql-0.14-0
  libwine libwine-alsa libwine-bin libwine-gecko-1.4 libwine-gl nautilus nautilus-data nautilus-sendto wine wine-bin The following packages will be upgraded:
  gvfs gvfs-common gvfs-daemons gvfs-libs   
4 upgraded, 95 newly installed, 0 to remove and 974 not upgraded.   
Need to get 100 MB/104 MB of archives.
After this operation, 250 MB of additional disk space will be used.

Thanks to Zobel, who pointed me to this one....

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...

BEGIN PGP SIGNED MESSAGE
Hash: SHA256 , During the month of June, we experienced a service interruption which
has caused our mutual customer, School, an
inability to initiate outgoing calls. CenturyLink has also caused the
interruption of the school s DSL Internet service. During the interim
period, I have installed a VoIP phone and tied in to one of my backup
providers so that the school can function during the CenturyLink outage. My understanding is that will begin paying CenturyLink
directly for its service again due to the service interruption. Until
such time as I receive acknowledgment from you, we will continue paying
roughly $27/mo for the school s phone service. Once the transfer has
been completed to the satisfaction of the school board, Collier
Technologies LLC will discontinue payment for the DID - - ,
leaving a single DID, - - . I expect that the DID will be
moved back into the school s name within the next week. Please confirm
this or provide information as to why this will not happen. I have CC d
and , who represent the school board on this
email. Please include them in the reply. Since the DSL service has been interrupted at both the School s address
and at ours, and since CenturyLink has failed to provision the remaining
two $14.99/mo 10Mbit DSL circuits which Collier Technologies LLC has
been paying for despite their un-provisioned state, we will be reducing
the monthly payment from $150 to $70. My understanding is that $70 will
be more than sufficient to cover the two voice lines, inside wire
maintenance and regulatory fees. If this is not the case, please keep
us appraised of the situation. Do note that our decision to stop payment for service which is not being
provided does not, in our estimation, relieve CenturyLink from the three
year contract period negotiated verbally by you on its behalf on October
4th 2011. We currently consider CenturyLink to be in breach of
contract. Sincerely, C.J. Adams-Collier BEGIN PGP SIGNATURE
Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJP3TqdAAoJEEyimPmPQm23qqoH/jRmiIVHNCnH8EqgzsNQiUIm
LVrFg7kvpRIM692mzrGgkZTxG9KlVK+1/dZl1aPsmMP5Q6ni3NigzRDnywJZI53a
yTwTZhid8B4Tf+JOrhUhKPpmm+2YoHTYaobwgxk+rRgUGUHEMCZMPnjKNGGPDCgO
2jNz5fSnI6IinRz4nXwhAtGQRUXVJWXGrUCX1kQXGH4pNvjbgE8n6yAsC6sixlPa
ljDaNjxUEjUY4PmQdKNetkzQLxlq/OGJgRHZXHzfg37cJEF4L28DJBYvf8CHbt2K
87ELXGs6nDn54yI4q4ojODln9k/GzC+NY6MDXYdof7dNbeEPujvjQCiyRgjLc9E=
=uLKs
END PGP SIGNATURE

I am transitioning my GPG key from an old 1024-bit DSA key to a new 4096-bit RSA key. The old key will continue to be valid for some time but I prefer all new correspondance to be encrypted with the new key. I will be making all signatures going forward with the new key. I have followed the excellent tutorial from Daniel Kahn Gillmor which also explains why this migration is needed. The only step that I did not execute is issuing a new certification for keys I have signed in the past. I did not find any search engine to tell me which key I have signed. Here is the signed transition statement (I have stolen it from Zack): For easier access, I have also published it in text format. You can check it with: To avoid signing/encrypting with the old key who share the same email addresses than the new one, I have saved it, removed it from the keyring and added it again. The new key is now first in both the secret and the public keyrings and will be used whenever the appropriate email address is requested. I now need to gather some signatures for the new key. If this is appropriate for you, please sign the new key if you signed the old one.

For two years I have been very fortunate indeed to be fully sponsored for travel and accommodation at DebConf once on the Newbies programme, and once from normal funds. However, considering the cost this year (at least $1,000 in travel expenses) and of personal circumstances, which are not favourable, I am reliant on sponsorship this year even more than others. However, although I have accommodation sponsorship this year I am still waiting to hear about travel. The local team have said they hope to provide details by 20th June, but it s really too late by then there is time off from work to arrange, flight tickets to purchase, vaccinations to have, and of course I could really do with not having to lay out that much money in the first place, even if it s to be reimbursed later. So at this stage at least, I am sad to say that I think it unlikely I will be there. I m looking forward to Switzerland though; this time there might be two of us.

---

I m probably not going to DebConf12 is a post from: jwiltshire.org.uk Flattr

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.

Carla Schroder wrote a piece for linux.com on secure boot, which gives a reasonable overview of the technology and some of the concerns. It unfortunately then encourages everyone to ignore those legitimate concerns by making the trivially false claim that secure boot is just security theatre.

Security isn't some magic binary state where you're either secure or insecure and you can know which. Right now I'd consider my web server secure. If someone finds an exploitable bug in Apache then that would obviously no longer be the case. I could make it more secure by ensuring that Apache runs in a sufficiently isolated chroot that there's no easy mechanism for anyone to break out, which would be fine up until there's also a kernel exploit that allows someone to escalate their privileges enough to change their process root. So it's entirely possible that someone could right now be breaking into my system through bugs I don't even know exist. Am I secure? I don't know. Does that mean I should just disable all security functionality and have an open root shell bound to a well known port? No. Obviously.

Secure boot depends on the correctness of the implementation and the security of the signing key. If the implementation is flawed or if control of the signing key is lost then it stops providing security, and understanding that is important in order to decide how much trust you place in the technology. But much the same is true of any security technique. Kernel flaws make it possible for an unprivileged user to run with arbitrary privileges. Is user/admin separation security theatre? SSL certificate authorities have leaked keys. Is it security theatre for your bank to insist that you use SSL when logging in?

Secure boot doesn't instantly turn an insecure system into a secure one. It's one more technology that makes it more difficult for attackers to take control of your system. It will be broken and it will be fixed, just like almost any other security. If it's security theatre, so is your doorlock.

Why is this important? Because if you tell anyone that understands the technology that secure boot adds no security, they'll just assume that you're equally uninformed about everything else you're saying. It's a perfect excuse for them to just ignore discussion of market restrictions and user freedoms. We don't get anywhere by arguing against reality. Facts are important.

comments

Hello!

Here comes my short post on the blog for this week :D

Thinks are going better now, in the last days, I have done some testing and I do believe that now I should not have anymore problems with debconf and that I am on the right way. What I have tried was to scan the wireless interface and list all the available networks names. After that I have tried to do this while using debconf to display the messages. Everything worked just fine for this part, but it took me a while to figure out how to scan the interface. Now I think I've got it.

I have done separate tests for cdebconf and scanning and after that merged them into a third test, containing the scanning part with some basic, very simple templates just to get an idea of how it should/could look in the end. It's not in its final version yet, but I think it will work.

I have pushed all my attempts into some personal repository on github, but do not expect much, those are just some tests. You can find it here [1].


[1] https://github.com/sorinasandu/testing

I ve read quite a few articles about the value of a degree. Most of them come from the US where the combination of increasing tuition fees and uncertain job market makes a degree seem like a risky investment. I think that most analysis of the value of a degree are missing some important points. The Value of Money at Different Times The value of money is different at various stages of your life. The impression that I get is that when a married couple have their house fully paid off and they either don t/won t have children or their children are old enough to leave home the amount of money that they earn seems to matter a lot less. Doing a university degree involves 3 or 4 years not earning money (or more if doing post-graduate studies), which is usually starting at the age of 18. Effectively getting a degree involves giving up some money while young for the opportunity to earn more when older. Any analysis based on directly comparing the money spent on the degree to the amount of financial return without considering when money is needed is not very useful. I think that a reasonable analysis would exclude income earned after the age of about 45. By that age most people have either achieved a solid financial position and learned to live within their means or messed up their finances so badly that they won t live long enough to recover. A Degree as a Signal The Wikipedia page on economic signalling gives education as an example of a signal. A signal in this case means something that doesn t inherently mean anything but which signifies something else. So completing a degree doesn t necessarily mean that you learned anything relevant to work, but if you are able to do it then it means that you can probably also do things which are economically useful for an employer. This raises the question of how else one might signal their ability to work. One obvious answer is by working, someone who has remained steadily employed for 3 or 4 years has demonstrated their ability to work reliably and get along with other people which should be at least as useful as a signal. It s Not Only the Degree Most analysis seem to compare average income of people with degrees with the average of income with people who didn t attend university. That is based on the assumption that the degree was the only difference. When I was young my parents spent a moderate amount of money on a full set of paper encyclopedias (about 2 meters of shelf space). I m sure that this gave me some educational benefit as they intended, and it was something that was apparently quite rare I don t recall seeing a full encyclopedia in anyone else s house before the Wikireader [1]. My parents also bought me quite a lot of computer gear (back when hardware was really expensive), were always available to drive me to computer users group meetings etc, and did everything else that seemed likely to have an educational benefit. The value of such learning opportunities is significant. I think that almost everyone who had similar learning opportunities to me when they were young will probably have experienced similar support and pressure to attend university. I also think that almost everyone who receives such opportunities will be able to earn more than the median income even if they don t attend university. To a large extent people who are going to be successful attend university. A university degree doesn t make anyone successful if they couldn t succeed without a degree. There are some careers that just aren t options if you don t have a relevant degree (such as medicine and law). But I believe that anyone who is capable of completing a difficult course such as medicine or law (or any other career that has legal requirements for a degree) is capable of being successful without a degree in many other fields. So comparing the wages of a doctor or a lawyer to an average person doesn t make sense, it makes more sense to try and compare their wages to someone of similar skill who didn t have such a qualification. Conclusion It seems to me that the question is, of the people who had great learning opportunities when they were young and who wanted to succeed, would they have earned much less if they hadn t attended university? The next question is, of the people who might earn significantly less without getting a degree, would that salary difference really have mattered, or would it just be a matter of earning some luxury money when they are too old to really need it?

• [1] http://etbe.coker.com.au/2010/11/25/the-wikireader/

Related posts:

1. Ideas for a Home University There seems to be a recent trend towards home-schooling. The...
2. university degrees Recently someone asked me for advice on what they can...
3. Microsoft Hires University Drop-Out for Recruiting Campaign news.com.au reports that MS has hired former Miss Australia Erin...

Well this isn t Edinburgh. This is London calling. More from kohacon later. Today I was at OKFN s bibliohack . There were several interesting projects there and it was a good opportunity to get back into coding, metadata and APIs after thinking about conference practicalities for too long. BibSoup and its biblioserver software was my chosen hack. I didn t really make the most of it because I had to workaround broken wifi drivers that I hadn t noticed before, and I had to fix a broken java install that I did know about. BibSoup is mostly python and I think web.py, but it uses elasticsearch which is java. Oh and it s python 2.7 with virtualenv which is, erm, entertaining to get working on debian 6.0, as far as I can tell: I installed python2.7 from testing, backport python-virtualenv and I don t think anything broke. The approach to a hackfest was very different to kohacon s. Whereas people at kohacon hackfest were gathered around tables, moving to the talks table(s) when there was a talk they wanted, bibliohack started off classroom-style and didn t gather into workgroups until after coffee. The so-called non-coders were shunted off elsewhere after the welcome to do I-don t-know-what (maybe Library Co-op will write about it) and weren t seen again until the day s end. There were some nudging comments about being able to hack late into the night, which I m not sure is healthy if you ve done a full day. I left feeling a bit unsettled and disconnected from reality, although I got what I wanted from it playing with some new tech that we can maybe do good things with: thanks OKFN!

I ve been working on Poshto a bit, and after a few shots at getting it right, I ve started another rewrite. The code started getting pretty krufty, so a rewrite was in order. To keep a clear head, I ve also removed all the front-end code I had. I m breaking it into a sync routine and a front-end. It s seeming to work OKish so far, but hopefully there will be even more progress soon.

Just as a little reminder, the Bug Squashing Party in Salzburg will start in three days. We still have sponsored accomodation for five four people left, so don't hesitate to come! Squashing as many RC bugs for Wheezy as possible is on the TODO list for the weekend! Also we'll work on making Debian a proper Spacewalk client. This might be a bit too late for Wheezy, but there will be backports See YOU in Salzburg!