Until this time next month I'll be posting code-based discussions only. Recently I've been wanting to explore creating clustered services, because clusters are definitely things I use professionally. My initial attempt was to write an auto-clustering version of memcached, because that's a useful tool. Writing the core of the service took an hour or so:

• Simple KeyVal.pm implementation.
• Give it the obvious methods get, set, delete.
• Make it more interesting by creating a read-only append-log.
• The logfile will be replayed for clustering.

At the point I was done the following code worked:

use KeyVal;
# Create an object, and set some values
my $obj = KeyVal->new( logfile => "/tmp/foo.log" );
$obj->incr( "steve" );
$obj->incr( "steve" );
print $obj->get( "steve" ) # prints 2.
# Now replay the append-only log
my $replay = KeyVal->new( logfile => "/tmp/foo.log" );
$replay->replay();
print $replay->get( "steve" ) # prints 2.

In the first case we used the primitives to increment a value twice, and then fetch it. In the second case we used the logfile the first object created to replay all prior transactions, then output the value. Neat. The next step was to make it work over a network. Trivial. Finally I wanted to autodetect peers, and deploy replication. Each host would send out regular messages along the lines of "Do you have updates made since $time?". Any that did would replay the logfile from the given unixtime offset. However here I ran into problems. Peer discovery was supposed to be basic, and I figured I'd write something that did leader election by magic. Unfortunately Perls threading code is .. unpleasant:

• I wanted to store all known-peers in a singleton.
• Then I wanted to create threads that would announce and receive updates.

This failed. Majorly. Because you cannot launch the implementation of a class-method as a thread. Equally you cannot make a variable which is "complex" shared across threads. I wrote some demo code which works without packages and a shared singleton:

• https://github.com/skx/peer-discovery

The Ruby version, by contrast, is much more OO and neater. Meh. I've now shelved the project. My next, big, task was to make the network service utterly memcached compatible. That would have been fiddly, but not impossible. Right now I just use a simple line-based network protocol. I suspect I could have got what I wanted using EventMachine, or similar, but that's a path I've not yet explored, and I'm happy enough with that decision.

I was awarded the Free Software Foundation Award for the Advancement of Free Software this weekend[1]. I'd been given some forewarning, and I spent a bunch of that time thinking about how free software had influenced my life. It turns out that it's a lot.

I spent most of the 90s growing up in an environment that was rather more interested in cattle than in computers, and had very little internet access during that time. My entire knowledge of the wider free software community came from a couple of CDs that contained a copy of the jargon file, the source code to the entire GNU project and an early copy of the m68k Linux kernel.

But that was enough. Before I'd even got to university, I knew what free software was. I'd had the opportunity to teach myself how an operating system actually worked. I'd seen the benefits of being able to modify software and share those modifications with others. I met other people with the same interests. I ended up with a job writing free software and collaborating with others on integrating it with upstream code. And, from there, I became more and more involved with a wider range of free software communities, finding an increasing number of opportunities to help make changes that benefited both me and others.

Without free software I'd have started years later. I'd have lost the opportunity to collaborate with people spread over the entire world. My first job would have looked very different, as would my entire career since then. Without free software, almost everything I've achieved in my adult life would have been impossible.

To me, free software means I've lived a significantly better life than would otherwise have been the case. But more than that, it means doing what I can to make sure that other people have the same opportunities. I am here because of the work of others. The most rewarding part of my continued involvement is the knowledge that I am part of a countless number of people working to make sure that others can tell the same story in future.

[1] I'd link to the actual press release, but it contains possibly the worst photograph of me in the entire history of the universe

comments

This is a fairly small Perl module that provides a more convenient interface to the ANSI color escape sequences. The primary change in this release is interesting for me but not so much for anyone else. It's the first of my core Perl modules that I've converted to Module::Build and to the new Perl test infrastructure that's now maintained in rra-c-util. (Yes, I know that Module::Build is apparently going to be dropped from Perl core, but the package also generates a Makefile.PL for backward compatibility.) Starting with this release, all my subsequent package releases will start using the Lancaster Consensus environment variables to control whether to run non-default tests (namely AUTOMATED_TESTING, RELEASE_TESTING, and AUTHOR_TESTING). Hopefully this won't cause me too many problems. I'm currently setting AUTHOR_TESTING unconditionally, since I really want to see the results of those tests for all my code, but it's possible that will cause me too many problems with other people's code. (It would have been nice if the spec for AUTHOR_TESTING would let you set the value of the variable to the identity of the author whose tests you want run.) I like having all my release tests run by automated testing so that I can identify any problems with the code to conditionally skip them, so I enable all the release tests when AUTOMATED_TESTING is set. This is probably peculiar to me. The other changes in this release are all documentation and test suite fixes. There are no code changes in this release. Thanks to Olivier Mengu and David Steinbrunner for various bug reports. You can get the latest release from the Term::ANSIColor distribution page.

Loanwords can often appear more insightful than they really are. How prescient of another culture to codify such a concept into a single word! They surely must have lofty and perceptive discussions if it was necessary to coin and codify one. But whilst there is always the danger of over-inflating the currency of the loanword especially the compound one there must be a few that are worth the trouble. One such term is fingerspitzengef hl. Literally meaning "finger-tips feeling" in German, it attempts to capture the idea of an intuitive sophistication, flair or instinct. Someone exhibiting fingerspitzengef hl would be able to respond appropriately, delicately and tactfully to certain things or situations. Oliver Reichenstein clarifies the distinction from a personal taste:

Whether I like pink or not, sugar in my coffee, red or white wine, these things are a matter of personal taste. These are personal preferences, and both designers and non-designers have them. This is the taste we shouldn't bother discussing. Whether I set a text s line height to 100% or 150% is not a matter of taste, it is a matter of knowing the principles of typography. However, whether I set a text s line height at 150% or 145% is a matter of Fingerspitzengef hl; wisdom in craft, or sophistication.

Fingerspitzengef hl is therefore not innate and is probably refined over the years via subconscious rather than conscious study and reflection. However, it always flows naturally in the moment, not dissimilar to Castiglione's sprezzatura. Personally, I am particularly enamoured how this concept of a "trained taste" appears to blur the line between an objective and subjective aesthetic, putting me somewhat at odds with those who baldly assert that taste is "obviously" entirely individual.

Core Rendering with Glamor I ve hacked up the intel driver to bypass all of the UXA paths when Glamor is enabled so I m currently running an X server that uses only Glamor for all rendering. There are still too many fall backs, and performance for some operations is not what I d like, but it s entirely usable. It supports DRI3, so I even have GL applications running. Core Rendering Status I ve continued to focus on getting the core X protocol rendering operations complete and correct; those remain a critical part of many X applications and are a poor match for GL. At this point, I ve got accelerated versions of the basic spans functions, filled rectangles, text and copies. GL and Scrolling OpenGL has been on a many-year vendetta against one of the most common 2D accelerated operations copying data within the same object, even when that operation overlaps itself. This used to be the most performance-critical operation in X; it was used for scrolling your terminal windows and when moving windows around on the screen. Reviewing the OpenGL 3.x spec, Eric and I both read the glCopyPixels specification as clearly requiring correct semantics for overlapping copy operations it says that the operation must be equivalent to reading the pixels and then writing the pixels. My CopyArea acceleration thus uses this path for the self-copy case. However, the ARB decided that having a well defined blt operation was too nice to the users, so the current 4.4 specification adds explicit language to assert that this is not well defined anymore (even in the face of the existing language which is pretty darn unambiguous). I suspect we ll end up creating an extension that offers what we need here; applications are unlikely to stop scrolling stuff around, and GPUs (at least Intel) will continue to do what we want. This is the kind of thing that makes GL maddening for 2D graphics the GPU does what we want, and the GL doesn t let us get at it. For implementations not capable of supporting the required semantic, someone will presumably need to write code that creates a temporary copy of the data. PBOs for fall backs For operations which Glamor can t manage, we need to fall back to using a software solution. Direct-to-hardware acceleration architectures do this by simply mapping the underlying GPU object to the CPU. GL doesn t provide this access, and it s probably a good thing as such access needs to be carefully synchronized with GPU access, and attempting to access tiled GPU objects with the CPU require either piles of CPU code to de-tile accesses (ala wfb), or special hardware detilers (like the Intel GTT). However, GL does provide a fairly nice abstraction called pixel buffer objects (PBOs) which work to speed access to GPU data from the CPU. The fallback code allocates a PBO for each relevant X drawable, asks GL to copy pixels in, and then calls fb, with the drawable now referencing the temporary buffer. On the way back out, any potentially modified pixels are copied back through GL and the PBOs are freed. This turns out to be dramatically faster than malloc ing temporary buffers as it allows the GL to allocate memory that it likes, and for it to manage the data upload and buffer destruction asynchronously. Because X pixmaps can contain many X windows (the root pixmap being the most obvious example), they are often significantly larger than the actual rendering target area. As an optimization, the code only copies data from the relevant area of the pixmap, saving considerable time as a result. There s even an interface which further restricts that to a subset of the target drawable which the Composite function uses. Using Scissoring for Clipping The GL scissor operation provides a single clipping rectangle. X provides a list of rectangles to clip to. There are two obvious ways to perform clipping here either perform all clipping in software, or hand each X clipping rectangle in turn to GL and re-execute the entire rendering operation for each rectangle. You d think that the former plan would be the obvious choice; clearly re-executing the entire rendering operation potentially many times is going to take a lot of time in the GPU. However, the reality is that most X drawing occurs under a single clipping rectangle. Accelerating this common case by using the hardware clipper provides enough benefit that we definitely want to use it when it works. We could duplicate all of the rendering paths and perform CPU-based clipping when the number of rectangles was above some threshold, but the additional code complexity isn t obviously worth the effort, given how infrequently it will be used. So I haven t bothered. Most operations look like this:

Allocate VBO space for data
Fill VBO with X primitives
loop over clip rects  
    glScissor()
    glDrawArrays()
 

This obviously out-sources as much of the problem as possible to the GL library, reducing the CPU time spent in glamor to a minimum. A Peek at Some Code With all of these changes in place, drawing something like a list of rectangles becomes a fairly simple piece of code: First, make sure the program we want to use is available and can be used with our GC configuration:

prog = glamor_use_program_fill(pixmap, gc,
                               &glamor_priv->poly_fill_rect_program,
                               &glamor_facet_polyfillrect);
if (!prog)
    goto bail_ctx;

Next, allocate the VBO space and copy all of the X data into it. Note that the data transfer is simply memcpy here that s because we break the X objects apart in the vertex shader using instancing, avoiding the CPU overhead of computing four corner coordinates.

/* Set up the vertex buffers for the points */
v = glamor_get_vbo_space(drawable->pScreen, nrect * (4 * sizeof (GLshort)), &vbo_offset);
glEnableVertexAttribArray(GLAMOR_VERTEX_POS);
glVertexAttribDivisor(GLAMOR_VERTEX_POS, 1);
glVertexAttribPointer(GLAMOR_VERTEX_POS, 4, GL_SHORT, GL_FALSE,
                      4 * sizeof (GLshort), vbo_offset);
memcpy(v, prect, nrect * sizeof (xRectangle));
glamor_put_vbo_space(screen);

Finally, loop over the pixmap tile fragments, and then over the clip list, selecting the drawing target and painting the rectangles:

glEnable(GL_SCISSOR_TEST);
glamor_pixmap_loop(pixmap_priv, box_x, box_y)  
    int nbox = RegionNumRects(gc->pCompositeClip);
    BoxPtr box = RegionRects(gc->pCompositeClip);
    glamor_set_destination_drawable(drawable, box_x, box_y, TRUE, FALSE, prog->matrix_uniform, &off_x, &off_y);
    while (nbox--)  
        glScissor(box->x1 + off_x,
                  box->y1 + off_y,
                  box->x2 - box->x1,
                  box->y2 - box->y1);
        box++;
        glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, nrect);
     
 

GL texture size limits X pixmaps use 16 bit dimensions for width and height, allowing them to be up to 65536 x 65536 pixels. Because the X coordinate space is signed, only a quarter of this space is actually useful, which makes the useful size of X pixmaps only 32767 x 32767. This is still larger than most GL implementations offer as a maximum texture size though, and while it would be nice to just say we don t allow pixmaps larger than GL textures , the reality is that many applications expect to be able to allocate such pixmaps today, largely to hold the ever increasing size of digital photographs. Glamor has always supported large X pixmaps; it does this by splitting them up into tiles, each of which is no larger than the largest texture supported by the driver. What I ve added to Glamor is some simple macros that walk over the array of tiles, making it easy for the rendering code to support large pixmaps without needing any special case code. Glamor also had some simple testing support you can compile the code to ignore the system-provided maximum texture size and supply your own value. This code had gone stale, and couldn t work as there were parts of the code for which tiling support just doesn t make sense, like the glyph cache, or the X scanout buffer. I fixed things so that you could leave those special cases as solitary large tiles while breaking up all other pixmaps into tiles no larger than 32 pixels square. I hope to remove the single-tile case and leave the code supporting only the multiple-tile case; we have to have the latter code, and so having the single-tile code around simply increases our code size for not obvious benefit. Getting accelerated copies between tiled pixmaps added a new coordinate system to the mix and took a few hours of fussing until it was working. Rebasing Many (many) Times I m sure most of us remember the days before git; changes were often monolithic, and the notion of changing how the changes were made for the sake of clarity never occurred to anyone. It used to be that the final code was the only interesting artifact; how you got there didn t matter to anyone. Things are different today; I probably spend a third of my development time communicating how the code should change with other developers by changing the sequence of patches that are to be applied. In the case of Glamor, I ve now got a set of 28 patches. The first few are fixes outside of the glamor tree that make the rest of the server work better. Then there are a few general glamor infrastructure additions. After that, each core operation is replaced, one a at a time. Finally, a bit of stale code is removed. By sequencing things in a logical fashion, I hope to make review of the code easier, which should mean that people will spend less time trying to figure out what I did and be able to spend more time figuring out if what I did is reasonable and correct. Supporting Older Versions of GL All of the new code uses vertex instancing to move coordinate computation from the CPU to the GPU. I m also pulling textures apart using integer operations. Right now, we should correctly fall back to software for older hardware, but it would probably be nicer to just fall back to simpler GL instead. Unless everyone decides to go buy hardware with new enough GL driver support, someone is going to need to write simplified code paths for glamor. If you ve got such hardware, and are interested in making it work well, please take this as an opportunity to help yourself and others. Near-term Glamor Goals I m pretty sure we ll have the code in good enough shape to merge before the window closes for X server 1.16. Eric is in charge of the glamor tree, so it s up to him when stuff is pulled in. He and Markus Wick have also been generating code and reviewing stuff, but we could always use additional testing and review to make the code as good as possible before the merge window closes. Markus has expressed an interest in working on Glamor as a part of the X.org summer of code this year; there s clearly plenty of work to do here, Eric and I haven t touched the render acceleration stuff at all, and that code could definitely use some updating to use more modern GL features. If that works as well as the core rendering code changes, then we can look forward to a Glamor which offers GPU-limited performance for classic X applications, without requiring GPU-specific drivers for every generation of every chip.

Using the AWS donation, David Suarez and myself have been able to rebuild the whole archive with Clang 3.4.
The rebuild has been done January 10th but, with my new job, I did not find the time to publish the result.
Releases after releases, the results are getting better and better. Currently, 2193 packages in the archive are failing to build from source.
That is roughly the same number of build failures as with the precedent rebuild with Clang 3.3.
However, this is good news for two reasons:
* the number of new packages in Debian increased (18854 at time of the 3.3 release, 21204 for the 3.4)
* clang 3.4 has more checks and error detections. I also started to update clang to make it closer to gcc. For example, I transformed wrong usage of -O (> 6) error to be treated as regular warning. However, a critical bug has emerged during this release. When using -D_FORTIFY_SOURCE=2 (which is the case of many Debian packages), the binaries produced freeze (infinity loop in the ASM). This has been reported upstream as bug 16821 and concerns about 150 packages (including Firefox, gcc, LLVM, etc). Hopefully, this will be fixed in 3.5 (this is unlikely for 3.4.1). About the new build failures, now, Clang triggers an error (or warning + -Werror) on: * Wrong usage of the default argument (should be done in the definition)
16 occurrences * Usage of C++11 feature without the appropriate argument
7 occurrences * Unused static const declaration
5 occurrences * Recursive template instantiation exceeded
4 occurrences * Defitinion of a builtin function
3 occurrences * Read-only variable is not assignable
2 occurrences By the way, I proposed a Google Summer of Code Project to work faster on a support of Debian built by Clang. As requirements, I asked students to fix some bugs, they already did a great job.

It's again that time of the year for the Debian Project: the elections of its Project Leader! Starting on March 31st, and during the following two weeks, the Debian Developers will vote to choose the person who will guide the project for one year. Among this year's candidates there is the current DPL, Lucas Nussbaum, who admits that "the workload involved in being the DPL is just huge," and motivates his nomination with the need for stability in the project in this release cycle, especially after the difficult decision about the default init system. In his platform, Lucas speaks of technical and social steps to improve the project: from reproducible builds for a more secure archive to a renewed effort to run Debian on new platforms (especially smartphone and tablets); from a more welcoming approach to prospective contributors to an easier collaboration with organizations. The only other candidate left after Gergely Nagy withdrew his nomination, is former Release Manager Neil McGovern. Neil's platform focuses mainly on the need to "ensure that we cater to our users, and there's millions of them. From those running the latest software in unstable, to people who simply want a rock solid core release." In his opinion "the size of Debian is increasing, and will reach a point where we're unable to guarantee basic compatibility with other packages, or the length of time it takes to do so becomes exponentially longer, unless something changes." To fix this problem, Neil proposes the implementation of PPAs (Personal Package Archives), the modernisation of the current build and infrastructure system as well as generally supporting the various teams. The campaigning period will last until March 30th: the candidates are already engaged in debates and discussions on the debian-vote mailing list where they'll reply to questions from users and contributors.

I know, I know, I should resist saying this. But every time I see it, I wonder why it happens, and I should just get this off my chest. The difference between "its" and "it's" is something that many people, even native english speakers, seem to miss. Yet, it's so extremely simple that I, a non-native english speaker, have been baffled about that common mistake for as long as I can remember. The apostrophe (') in any sentence usually means that something at the location of that apostrophe is gone out to lunch. In this particular case, it means that the " " and the "i" in the phrase "it is" were hungry. So rather than "it is", we contract that to "it's", and allow the space and the i to enjoy their meal while the apostrophe keeps their seats warm. Practically, what that means is that every time you want to write "it's", you should consider whether you can replace it with "it is" without making the sentence sound like junk. If you can't, you probably meant to write "its" rather than "it's". For instance, consider the following sentence: "It's not possible to repair this car within the budget that its owner wants to pay" It's perfectly possible to say "it is not possible" here, so we need to have the apostrophe keep a seat warm for the space and the i. It makes no sense to say "it is owner", unless you're trying to speak a much deformed form of english, so that makes it a possessive pronoun (similar to "hers", "his", "theirs", etc) and you shouldn't use an apostrophe. Speaking of food, it's time for lunch now.

I was going to put out some of these changes in a 4.5.6 release late last year, but that didn't happen, and then more things kept coming up. So this release is rather large. The major new feature is a new WebAuthCookiePath directive for mod_webauth, which allows path-scoped WebAuth cookies so that different portions of a site can maintain separate authentication credentials. There are various caveats, and support will get better later, but it's a beginning. There are two bug fixes from Benjamin Coddington: WebAuthOptional should now work with Apache 2.4, and internal notes management in the module is now done better, which should prevent some cases where the user was redirected to WebLogin twice. Eventually, the things WebAuth uses notes for should become request context data, but that's for a later change. There are multiple changes to keyring handling to let mod_webauth and mod_webkdc work properly with the ITK Apache MPM, which allows each virtual host to run as a different user. Previously, all virtual hosts shared one in-memory keyring, which meant leaking authentication keys between virtual hosts. Now, each virtual host gets its own, lazily loaded from the keyring on disk when it's first needed. This allows ITK users to configure separate keyrings for each virtual host. To make this easier, keyring files are now locked for write, and writing a keyring preserves the ownership and permissions if possible. WebLogin now supports a new remctl-based password change protocol, which I developed for Stanford to work around some problems with the kpasswd when password change takes too long. All the tools for this will eventually be available outside of Stanford when I have a chance to polish them up and release them. There are a few other, more minor bug fixes. mod_webauth and WebLogin are now more aggressive about telling web browsers to really not cache pages. WebLogin also now uses the authenticated identity returned by the WebKDC for multifactor, since it may have canonicalized the user's identity. The correct template variable is now set when the user doesn't enter a code on the WebLogin multifactor page. Better error messages are returned for invalid principals and unknown realms. The workaround for invalid XML returned by the WebKDC should now actually work. And WebLogin logs a more detailed error message on password change failures. You can get the latest release from the official WebAuth distribution site or from my WebAuth distribution pages.

I'm back home from the MiniDebConf Barcelona 2014 (and I've had a full night of uninterrupted sleep! :) ), so it's time to thank everybody who were there (both in person and via IRC) and especially the organizers who did a great job at creating a welcoming environment and a smooth experience for all of us.

It was my first @Debian community experience (although I had already met a few of the members in various occasions) and it made me glad of my decision to start contributing to the project. (I realize that I've probably met a sanitized and newbie-friendlier version of the community, but it's also made up of people who are working to improve the not-so-friendly parts.)

It was also my first time speaking to an international audience; I believe it went overall well: I'm happy with what I said and how, not so much with what I forgot to say (e.g. mentioning testing and other non-packaging skills in my answer to Enrico's question "what skills are needed in the 3dprinter team", or actually showing the last slide with reference urls at least this one will be available as soon as I'll send the slides to be uploaded to the site).

Random mentions:

We had free software, and also free beer, from one of the sponsors (I didn't catch which one), but the venue had to remain beer free, which encourages bad puns of the kind I love :)

Contrary to what some people was fearing, the cake was real and not a lie! (also, it tasted like banana bread with chestnut flour).

Video team duty is fun and something I'll do again (and try to use in our local community what I learn in the process), but I don't think I'll let the Galadriel in my mind bully me into subtitling stuff, sorry.

To ease worries of package mistreatment, the cows in the arriero slides looked more like they were moving between pastures in transhumance rather than being led to be slaughtered.

There are curves in B ziers, France (and also bad coffee and great pastries: definitely a better place_with_geek_name to have breakfast than Perl, Germany)!

The stickers with "May I sign your PGP keys" were a nice idea, although they didn't work as well as they could (possibly because there was little time and lots of things to do). I did manage to reduce my dependency on Enrico's key to find trustpaths, however, which is nice :)

I like the idea to draw a pentacle on the floor, and forcing speakers to remain inside, as suggested by a meeting of videoteaming italian cabal members.

Lots of other things I'm forgetting to mention, but now it's time to stop writing this and start work on my todolist where a few things received a priority bump during the conf. :)

To provide geolocation-aware answers with BIND, a common solution is to use a patch adding GeoIP support. A client can be directed to the closest (and hopefully fastest) web server: However, an end user does not usually talk directly to authoritative servers. They proxy the query to a third-party recursor server which will query the authoritative server on their behalf. The recursor also caches the answer to be able to serve it directly to other clients. On most cases, we can still rely on the recursor GeoIP location to forward the client to the closest web server because it is located in the client s ISP network, as shown on the following schema:

1. Juan is located in China and wants to know the IP address of www.example.com. She queries her ISP resolver.
2. The resolver asks the authoritative server for the answer.
3. Because the IP address of the resolver is located in China, the authoritative server decides to answer with the IP address of the web server located in Japan which is the closest one.
4. Juan can now enjoy short round-trips with the web server.

However, this is not the case when using a public recursor as provided by Google or OpenDNS. In this case, the IP address of the end client and the source IP address of the recursor may not share the same locality. For example, in the following schema, the authoritative server now thinks it is in relation with an European customer and answers with the IP address of the web server located in Europe: Moreover, caching makes the problem worse. To solve this problem, a new EDNS extension to expose the client subnet has been proposed. When using this extension, the recursor will provide the client subnet to the authoritative server for it to build an optimized reply. The subnet is vague enough to respect client s privacy but precise enough to be able to locate it. A patched version of dig allows one to make queries with this new extension: In the above example, a client located in France gets a reply with two IP addresses located in France. If we now are an US client, we will get IP addresses located in the US: The recursor is expected to cache the two different answers and only serve them if the client matches the appropriate subnet (the one confirmed in the answer from the authoritative server). With this new extension, the authoritative server knows that Juan is located in China and answers with the appropriate IP address: Not many authoritative servers support this extension (PowerDNS and gdnsd, as far as I know). At Dailymotion, we have built a patch for BIND. It only works when BIND is configured as an authoritative server and it doesn t expose no configuration knobs. Feel free to use it (at your own risk). Once installed, you need to register yourself to OpenDNS and to Google to receive queries with the extension enabled.

As announced in the "Bits from the Security Team" (LWN copy) email a couple of weeks ago, it is possible that Debian squeeze will have Long Term Support, primarily in the way of security updates.

The news have made it to Softpedia and reddit and even though it has not been announced how long it would be supported, what use cases are planned, etc., the answer I can give is that it depends solely on people contributing to it.

I'd like to add that no, the LTS announcement is not related to the use of Debian on the ISS laptops, as mentioned in reddit - at least not that we are aware of. And to avoid possible confusion from the Softpedia article, the plan is LTS for the squeeze release.

From the emails we have received in response to the announcement, I do wonder however where are the people who expressed interest and signs of engagement last time there was a discussion about providing LTS for Debian.

Perhaps it wasn't stressed enough in the email, but those who are interested in benefiting from (and therefore contributing to) long term support, please do contact the security team NOW.

After all, the clock keeps ticking and Debian squeeze is going to reach its End of Life in less than two months otherwise.

When I installed Debian on my MacBookAir4,1 in 2012, there was no way to do it without manual intervention yet. I followed a tutorial on how to boot GRUB from the EFI Boot option in the MacBook EFI Menu. I did not want to fiddle with rEFIt, and I didn't want to boot GRUB by default. When I want to boot Linux, I press the Option key during power up and select EFI Boot from the Apple boot menu. Unfortunately, I neglected to collect notes about how I did it manually. However, Linux 3.2 is getting a bit old, so I finally wanted to replace my manual boot configuration with something handled by the package system. In case you don't have /boot/efi in /etc/fstab yet, you need to mount /dev/sda1 on /boot/efi for the following to work. The documentation I found on the net suggested to just reinstall grub-efi-amd64 and everything should work. That is not quite true. When I do Nothing changes in /boot/efi. I sort of expected that /boot/efi/EFI/debian would be created, and the EFI image should be placed in there. However, that did not happen. Why is that? It turns out that when I installed grub-efi-amd64 manually in 2012, I created /boot/efi/EFI/boot/bootx64.efi which is the EFI fallback location, and apparently exactly what I want on this MacBook which does not support multiple boot options. Matthew Garrett posted an interesting article called Booting with EFI which sheds light on this issue, go and read it. Looking at /var/lib/dpkg/info/grub-efi-amd64.postinst revealed that /boot/efi/EFI/debian needs to be created manually first. If this directory does not exist, grub-efi-amd64 basically does nothing on reinstall. Running grub-install will actually create a new EFI image. However, it is being created in the wrong place for this machine. does the trick. Now /boot/efi/EFI/debian/grubx64.efi gets created. However, since I don't want to make GRUB the default, there is yet another manual step to do: Now I can select EFI Boot after pressing the Option key during startup. GRUB is loaded and Linux 3.13 gets booted. Strike! Looking more closely reveals that there is actually a way to tell grub-install that it should install to the fallback location directly. The --removable option does that. For the faint of heart, what does grub-install actually do on an EFI system? It does not directly write to the disk, therefore it does not need a device specified. It looks for files in /boot/efi and assumes the EFI partition is mounted there. So for my use case, the correct way to upgrade to a current GRUB EFI image should have been: Meanwhile I've been made aware of Bug#708430. I guess it would be nice to have an option in /etc/default/grub which would indicate that installation to the fallback location is desired. While this is a rather ugly hack to work around a stupid limitation, it is still what I'd like on this MacBook. At least since I don't have a triplle boot situation. Fallback location works fine with just two OSes coexisting.

Zoe's Kindergarten had a Pupil Free Day today. I think there's only that impacts the days Zoe attends Kindergarten for the whole year. I'd wanted to make the most of the fact that her friend Mackensie wasn't in Kindergarten on a Monday either, and have a play date with her at Southbank, but her little sister was having sleep issues, and her mother wanted her to nap at home today, so we had to scratch those plans. Given the forecast maximum temperature was going to be over 30 C today, I thought ice skating would be a great way to escape the heat, but the rink didn't have their open session until 1pm, so we had to do something in the morning to kill time. I decided we should go shoe shopping. Before we went to Westfield Carindale, we went to Officeworks to print out some more photos. Zoe really enjoys helping me with the self-serve printing kiosk, and is happy amusing herself at the kid's colouring table otherwise. I wanted some unusual size prints, so it involved one of the staff doing some additional faffing around with Photoshop for me. I'm rather amazed they'll spend the staff time doing that, when I only spend a couple of dollars on prints. After that, we headed out to Carindale. Zoe's in that limbo between size 3 and 4 at the moment. I bought her some new size 4 Autumn/Winter clothes the other weekend, and after that, went through her wardrobe and did a big cull of all her size 2 stuff and any size 3 stuff that didn't fit terribly well. That just left shoes and jumpers to sort out, so we concentrated on them today. First things first, we grabbed some morning tea at Muffin Break. They did a nice babyccino in a little china espresso cup, so Zoe enjoyed that, and we split a muffin between us. Zoe took a fancy to some ballerina pumps she saw at Cotton On Kids. We bought a few pairs of socks and a pair of size 10 pumps, and she wanted to wear them from that point on, so we wore them to the shoe shop. Almost as soon as we walked out of the store, she ran into heel problems on one foot, so after a few rounds of taking a couple of steps and needing to refit the heel of one shoe, I convinced her to go barefoot the remainder of the way. At Shoes and Sox she got properly measured for some light up closed-toe shoes. Zoe absolutely loved them, and wanted to wear them from that point on. Next we went to Target, and got a couple of jumpers. The kid's entertainment area was both a blessing and a curse. It was great for keeping her occupied when I needed to dash off and get some socks for myself for ice skating, but it was a negotiation challenge to get her away from it when it was time to leave. Toy Story 3 conveniently finished at just the right time. We dropped into Pumpkin Patch to get some boots. Despicable Me was playing there. Zoe is absolutely hooked on it at the moment. I managed to prime her to leave at the end of a scene though. She did score a couple of stickers while we were sitting there chilling out watching the movie though, so that was nice. I love Pumpkin Patch, but my God, it is expensive. I could have dropped $50 on a dress I really liked there, but I managed to resist. We decided to go back to Cotton On Kids to exchange the ballerina pumps. They didn't have any more of the style she'd chosen in her size, so we switched from gold glittery ones to red ones, which she wore out of the store. Cotton On Kids was also showing Despicable Me, so Zoe was very pleased. Shoes are horrendously expensive in Australia. The Sketchers and the boots set me back $60 each. The pumps were a bit more reasonably priced. I think they were about $20. I hope her feet don't grow too fast. After that shopping extravaganza it was lunchtime, and we split a spinach pide and had a quick fool around in the outdoor kid's play area and by then it was already after 1pm, so it was time to head to the ice skating rink. We got to the rink by about 1:45pm, and I changed Zoe into something a bit warmer. She was so excited, because we've talked about going ice skating on and off for a while, but it's just not something we've gotten around to doing yet, because neither of the two rinks are particularly convenient to home, and they have slightly odd hours. The rink had these slightly shorter than waist-height penguins that you could rent for little kids, so I rented one of them and Zoe pushed it around the rink, and got progressively better on her skates as time passed. We could also turn the penguin around and she could stand on the "feet" and I could push the penguin around by its head, which was fun for her, because we could get more speed up. By the end of the session, she was confident enough to have a few stints without the penguin, and stayed up pretty well. She was pretty buzzed afterwards. Going during the week was great, because there were maybe 20 people on the ice, tops, so it was nice and quiet. Zoe wasn't much of a hazard to anyone. She loved watching a couple of guys speed skate, and a lady do some figure skating. I'd booked myself a cut-throat razor shave at The Emporium Barber as a bit of a splurge, for 4:30pm, so we headed over there next. We got there a bit early, so I had a coffee, and Zoe had a juice while we waited. Then we discovered this dance apparel place a couple of doors down, that also had lots of fairy dresses and dress up dresses and whatnot. I asked on the off chance if they had ballet shoes, and of course they did, so we grabbed a pair of them while we were there, which was most serendipitous. Zoe has a trial dance class on Friday. She wants to do ballet or something of that ilk as her activity next term. Zoe was really good while I had my shave, and kept herself amused with my phone, and then we headed home, where Sarah was waiting to pick up Zoe. So it was really a rather non-stop, but nicely paced day. I'm looking forward to capping it off with a yoga class.

I m currently using BTRFS on most systems that I can access easily. It s not nearly reliable enough that I want to install it on a server in another country or an embedded device that s only accessible via 3G, but for systems where I can access the console it s not doing too badly. Balancing and Space Allocation # btrfs filesystem df /
Data, single: total=103.97GiB, used=85.91GiB
System, DUP: total=32.00MiB, used=20.00KiB
Metadata, DUP: total=1.78GiB, used=1.31GiB
# df -h /

Filesystem	Size	Used	Avail	Use%	Mounted on
/dev/disk/by-uuid/ac696117-473c-4945-a71e-917e09c6503c	108G	89G	19G	84%	/

Currently there are still situations where it can run out of space and deadlock on freeing space. The above shows the output of the btrfs df command and the regular df command, I have about 106G of disk space used by data and metadata in BTRFS while df shows that the entire filesystem (IE the block device) is 108G. So if I use another 2G of data or metadata then the system is at risk of deadlocking. To avoid that happening I have to run btrfs balance start / to start a balance which defragments the space use and frees some blocks. Currently there is a bug in BTRFS (present in all Debian/Unstable kernels) which prevents a balance operation from completing when systemd is used in a default configuration (there s something about the way systemd accesses it s journal files that triggers a BTRFS bug). This is really inconvenient, particularly given that there s probably a strong correlation between people who use experimental filesystems and people who use experimental init programs. When you get to the stage of the filesystem being deadlocked you can sometimes recover by removing snapshots and sometimes by adding a new device to the filesystem (even a USB flash drive will do). But I once had a filesystem get into a state where there wasn t enough space to balance, add a device, or remove a snapshot so I had to do a backup/format/restore. Quota Groups Last time I asked the developers (a few weeks ago) they told me that quota groups aren t ready to use. They also said that they know about enough bugs that there s no benefit in testing that feature. Even people who want to report bugs in BTRFS shouldn t use quotas. Kernel Panics with Kmail I ve had three systems develop filesystem corruption on files related to Kmail (the email program from KDE). I suspect that Kmail is triggering a bug in BTRFS. On all three systems the filesystem developed corruption that persisted across a reboot. One of the three systems was fixed by deleting the file for the Outbox, the others are waiting for kernel 3.14 which is supposed to fix the bug that causes kernel panics when accessing the corrupted files in question. I don t know whether kernel 3.14 will fix the bug that caused the corruption in the first place. Conclusion As I don t use quotas BTRFS is working well for me on systems that have plenty of storage space and don t run Kmail. There are some systems running systemd where I plan to upgrade the kernel before all the filesystem space is allocated. One of my systems is currently running SysVinit so I can balance the filesystem. Apart from these issues BTRFS is working reasonably well for me. I haven t yet had it s filesystem checksums correct corrupted data from disk in any situation other than tests (I have had ZFS correct such an error, so hardware I use does benefit from this). I have restored data from BTRFS snapshots on many occasions, so that feature has been a major benefit for me. When I had a system with faulty RAM the internal checks in BTRFS alerted me to the problem and I didn t lose any data, the filesystem became read-only and I was able to copy everything off even though it was too corrupted for writes.

As I posted some weeks ago, I have been playing with my CuBox-i4Pro, a gorgeous little ARM machine by SolidRun, built around an iMX6 system-on-a-chip. My first stabs at using it resulted in my previous post on how to get a base, almost-clean Debian distribution to run (Almost? Yes, the kernel requires some patches not yet accepted upstream, so I'm still running with a patched 3.0.35-8 kernel). After writing this step by step instructions, I followed them and built images ready to dd to a SD card and start running (available at my people.debian.org space. Now, what to do with this little machine? My version is by no means a limited box: 4 ARM cores, 2GB RAM make a quite decent box. In my case, this little machine will most likely be a home storage server with little innovation. However, the little guy is a power server, at only 3W consumption. I wanted to test its capabilities to do some number crunching and aid some of my friends The obvious candidate is building a Blender render farm. Right, the machines might be quite underpowered, but they are cheap (and look gorgeous!), so at least it's worth playing a bit! Just as a data point, running on an old hard disk (and not on my very slow SD card), the little machine was able to compile the Blender sources into a Debian package in 89m13.537s, that is, 5353 seconds. According to the Debian build logs (yes, for a different version, I tried with the version in Wheezy and in a clean Wheezy system), the time it took to build on some other architectures' build daemons was 1886s on i386, 1098s on PowerPC, 2003s on AMD64, 11513s on MIPS and 27721 on ARMHF. That means, my little machine is quite slower than desktop systems, but not unbearably so. But sadly, I have hit a wall, and have been unable to do any further progress. Blender segfaults at startup under the Debian armhf architecture. I have submitted bug report #739194 about this, but have got no replies to it yet. I did get the great help from my friends in the OFTC #debian-arm channel, but they could only help up to a given point. It seems the problem lies in the Python interpreter in armhf, not in Blender itself... But I cannot get much further either. I'm sending this as a blog post to try to get more eyeballs on my problem How selfish, right? :-) So, slightly going over the bug report, blender just dies at startup: After being told that strace is of little help when debugging this kind of issues, I went via gdb. A full backtrace pointed to what feels like the right error point: I'm not pasting here the full bug history (go to the bug report for the full information!), but it does point me to this being a problem in Python-land: It points to something not found at line 59 of Python/errors.c. And what I understand from that line is that some kind of unknown exception is thrown, and the Python interpreter does not now what to do with it. The check done at line 59 is the if (exception != NULL ** ....: So... Dear lazyweb: Any pointers on where to go on from here? kthxbye.

As Jan has previously announced, the Debian project is maintaining a booth at Chemnitzer Linux-Tage 2014, which is also organized by him. This year we will have merchandising at the booth, which is provided by Alexander Wirt and of course a demo system with Debian wheezy BabelBox as the past years. I'll drop it tomorrow, as I have a conflicting appointment on Saterday, maybe I can attend later on Sunday. In case you have spare time at the weekend ahead, it may be worth to spend it with great lectures and meet nice people over there.

phpMyAdmin has been accepted for Google Summer of Code 2014. So if you are a student and thinking about how to spend this summer, you might want to join us. As usual, we have prepared dozen of ideas, so in case you are interested, it's really the time to start to work on your application. We require you to contribute before GSoC, so that we can see you can handle the code and our tools. All details you might need are available in our applicant guide. Our requirements might sound strict, but without them, we would drown in hundredths of applications with no clue how to decide, so do your homework and prepare perfect application. If you have any questions, get in touch with us on mailing list and submit the application to to GSoC website.

Filed under: English phpMyAdmin 0 comments Flattr this!

Zoe had Playgroup this morning. We had a little bit of time to kill between when Sarah dropped her off and it was time to bike over to Playgroup, so we went for a little walk to the post box to mail a letter. It was a beautiful morning, so the walk was nice. We biked over to Playgroup. Today I learned from the mother of the boy who was causing issues last week, that he was extremely allergic to everything. They couldn't use egg cartons for their craft activities, for example, because he was allergic to eggs, and even the empty cartons would cause a problem, apparently. That's quite the allergic sensitivity. I'm glad Zoe outgrew her egg allergy. Zoe wanted to do the craft activity first up, so she made another crown, this time for Mummy. I helped roll scraps of crepe paper into balls, and she very carefully glued them onto the points of the crown. She seems to really enjoy mucking around with Clag glue pots. I'll have to get a bottle for home. It reminds of my early primary school days. After that, we just generally mucked around for the rest of Playgroup. She loved the dress up pink lacy skirt again, and wanted to fool around on stage for a bit. One of my ex-co-workers has an occasional yum cha or laksa lunch with a bunch of his ex-co-workers, and I was invited along to laksa at Super Bowl. I figured that since Zoe loves any opportunity to use her chopsticks, and generally loves a good noodle soup, that this could be something I could bring her along to. So straight after Playgroup, we biked over to the Bulimba ferry terminal, locked up the bike, took the ferry across to Teneriffe and jumped on a City Glider bus to Fortitude Valley. We ended up getting there about 30 minutes earlier than everyone else, so I just ordered Zoe some wonton noodle soup and let her have at it while we waited for everyone else to arrive. We all had a BBQ pork laksa, which I personally found a little bit too spicy for my liking, but it was doable. Lunch went well. Zoe was really well behaved, so I'll definitely bring her along again. The next one is supposed to be yum cha, so I think she'll enjoy the selection. Zoe was looking pretty tired by the end of lunch, and we reversed our way back, and biked home from Bulimba. Once we got home, she practically put herself to bed for a nap. Since she was napping pretty late, I didn't let her nap for too long, and she woke up happy. After her nap, I thought we'd do some baking. I wanted to try and make some oatmeal cookies like our friend Bri used to make, so I found a recipe and adapted it to the Thermomix, and we got stuck into it. The joys of having a small child help is that not always do the ingredients wind up where they're supposed to. We had to mill a cup of raw sugar down to white sugar, and I had the cup's worth of sugar in a bowl and asked Zoe to tip the sugar into the Thermomix bowl. Unfortunately, she didn't line up very well, so some of the sugar made it into the Thermomix, but about as much went all over the Thermomix, the counter, the floor, the Guidecraft kitchen helper, everywhere. I've become quite good at taking these sorts of things in my stride, and didn't bat an eyelid. I was actually more bothered by Zoe asking me if I still loved her. After I reassured her I still loved her, even if she accidentally spilled sugar everywhere, and we cleaned up the sugar together, we continued to the point where I realised the dough was supposed to chill in the fridge for at least an hour. This would have meant the cookies wouldn't be ready to hit the oven until right around when Sarah was due to pick up Zoe, so I figured we'd just leave the dough in the fridge and bake the cookies tomorrow. Zoe watched some TV while I cleaned up the kitchen, and then Sarah arrived to pick her up.