Hello This blog explains how next lcdproc package provide easier upgrader with automatic configuration merge. Here s the current situation: lcdproc is shipped with several configuration files, including /etc/LCDd.conf. This file is modified upstream at every lcdproc release to bring configuration for new lcdproc drivers. On the other hand, this file is always customized to suit the specific hardware of the user s system. So upgrading a package will always lead to a conflict during upgrade. User will always be required to choose whether to use current version or upstream version. Next version of libconfig-model-lcdproc-perl will propose user whether to perform automatic merge of the configuration: upstream change are taken into account while preserving user change. The configuration upgrade shown is based on Config::Model can be applied to other package. Current lcdproc situation To function properly, lcdproc configuration must always be adapted to suit the user s hardware. On the following upgrade, upstream configuration is often updated so user will often be shown this question:

Configuration file '/etc/LCDd.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** LCDd.conf (Y/I/N/O/D/Z) [default=N] ?

This question is asked in the middle of an upgrade and can be puzzling for an average user. Next package with automatic merge Starting from lcdproc 0.5.6, the configuration merge is handled automatically by the packaging script with the help of Config::Model::Lcdproc. When lcdproc is upgraded to 0.5.6, the following changes are visible:
* lcdproc depends on libconfig-model-lcdproc-perl
* user is asked once by debconf whether to use automatic configuration upgrades or not.
* no further question are asked (no ucf style questions). For instance, here s an upgrade from lcdproc_0.5.5 to lcdproc_0.5.6:

$ sudo dpkg -i lcdproc_0.5.6-1_amd64.deb 
(Reading database ... 322757 files and directories currently installed.)
Preparing to unpack lcdproc_0.5.6-1_amd64.deb ...
Stopping LCDd: LCDd.
Unpacking lcdproc (0.5.6-1) over (0.5.5-3) ...
Setting up lcdproc (0.5.6-1) ...
Changes applied to lcdproc configuration:
- server ReportToSyslog: '' -> '1' # use standard value
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Starting LCDd: LCDd.
Processing triggers for man-db (2.6.6-1) ...

Note: the automatic upgrade currently applies only to LCDd.conf. The other configuration files of lcdproc are handled the usual way. Other benefits User will also be able to:
* check lcdproc configuration with sudo cme check lcdproc
* edit the configuration with a GUI (see Managing Lcdproc configuration with cme for more details) Here s a screenshot of the GUI: More information * libconfig-model-lcdproc-perl package page. This package provides a configuration model for lcdproc.
* This blog explains how this model is generated from upstream LCDd.conf.
* How to adapt a package to perform configuration upgrade with Config::Model Next steps Automatic configuration merge can be applied to other packages. But my free time is already taken by the maintenance of Config::Model and the existing models, there s no room for me to take over another package. On the other hand, I will definitely help people who want to provide automatic configuration merge on their packages. Feel free to contact me on:
* config-model-user mailing list
* debian-perl mailing list (where Config::Model is often used to maintain debian package file with cme)
* #debian-perl IRC channel All the best
Tagged: config-model, configuration, debian, Perl, upgrade

The next version of Lintian, 2.5.22, is long overdue mostly because 2.5.21 FTBFS in sid. Besides fixing test failures, 2.5.22 also fixes:

• False-negative for most/all JAR related tags caused by file(1) changing its output for these files.
• A performance regression in checks/cruft.pm. For large source packages, this could severely affect performance of Lintian. This is #738342.
• A regression where lintian would not parse options appearing after file arguments.
• Some false-positives in the GFDL with invariants check.

Besides bug fixes, we also added a couple of new features/nice changes:

• The color option now defaults to auto instead of never .
• The homepage now links to the generated API-docs and thus, also the developer tutorial.
  • Patches extending/improving either/both are more than welcome.
• The test-suite runner now caches test artifacts meaning that subsequent test runs become vastly faster.
• The test-suite runner can now run tests under Devel::Cover , so we can now collect statistics about how much of the code is covered by the test suite.
• The html_reports tool (used e.g. on lintian.d.o) has been optimised. In particular, it only calls gnuplot twice, instead of once per data file (of which there was basically one per tag).
• The html-pages generated by the html_reports tool now uses content -based names for resources (e.g. images and the .css file). This allows them to be cached vastly longer, since any content changes will rename the resource and force browser to refetch them.
  • All resources handled this way are now stored in resources/ . As a side-effect, this means that images files are moved from images/ to resources/ .
  • A notable exception to this is the auto-generated (.svg) graphs.

We just need to do some final tweaks and get the tag descriptions reviewed before we are ready to release the next version.

Aldi Mobile has made a significant change to their offerings. They previously had an offer of $35 for unlimited calls and 2.5G of data in a month for which they had to publicly apologise for misleading customers as 2500 minutes of calls a month (83 minutes per day) is no-where near unlimited [1]. They also had an offer of $15 for 2G of data. In an email about this Aldi said Many of our customers are using a lot less than what is included in our current $35 plan. So we will soon be introducing new Value Packs with more flexible options; meaning you only pay for what you really need and they start from just $10. . That is grossly misleading, if they offered new plans in addition to the old ones and allowed customers to choose the plan that is the best match then it would be useful to some customers. But removing the supposedly unlimited plan and the $15 for 2G of data option is removing affordable options for people who want to use their phones for lots of calls or very few calls but moderate amounts of data use. New Plans The base rate for calls on Aldi pre-paid is $0.12 per minute and $0.12 per SMS, consider every mention of minute in this section to be minute or SMS . The Aldi Newplans page [2] starts with a $10 per month plan which offers 100 minutes of calls which would be $12 at the previous rate of $0.12 per minute. That is OK value when compared to just using the pre-paid calls if you consistently use more than 83 minutes of calls per month. However if you don t use 84 minutes of calls (EG you don t speak much on the phone and use Google Hangouts instead of SMS) then it s not good value. Also the advertised data use is $5 per 100MB, which is way below what is needed for a typical user with an Android phone. My mother in law was barely able to stick within a limit of 300MB/month when that was her limit, but while using the Aldo 2G/month bolt-on she s increased her data usage. The smallest of the new plans costs $20 per month, it provides 300 minutes of calls and includes 300MB of data. For an extra $7 you can get another 300MB of data. For my mother in law it seems that the cheapest option on the new plans would be $27 per month, that would cover the 60 minutes of calls she might make and the 450MB of data she s probably using. That s significantly more expensive than her previous cost of $15 for 2G of data and $7.20 for calls and has the additional difficulty that I would have to be more involved in helping her avoid excessive data use. The 2G data bolt-on was really good for some of my relatives, when they use that and configure their phones not to update software over 3G they never had to ask me about any problems related to excess data use. So my mother in law is facing an extra $5 per month (or maybe more depending on data use) and more time spent calling me for tech support. The data bolt on that Aldi is going to offer in future is $30 for 3G of data to replace the previous offer of $15 for 2G of data. The cost will be unchanged for anyone who uses between 2G and 3G a month, for everyone who uses less than 2G or more than 3G the data bolt-on will cost more. There is simply no possibility for any Aldi data-only customer to save on data use. The only way someone who uses a moderate amount of data could save money is if they use more than 160 minutes of calls and less than 1G of data. Disclaimer My analysis above is based on interpreting the Aldi web site. As with most telcos they aren t trying to make things easy in this regard, it seems that the consensus of opinion among telcos is to use complex pricing to make it difficult to compare and reduce competitive pressure. I blame any inaccuracies in my analysis on the Aldi web site. Why Aldi Shouldn t Mislead Customers Aldi isn t primarily a mobile phone company, their main business is running a supermarket. The trust of customers is important to them, raising prices when competition goes away is one thing, but misleading customers about it is another. If Aldi were to honestly say now that Kogan Mobile no longer exists there is nothing forcing us to have low prices then I d have a lot more respect for their company and be more inclined to shop at their supermarket. It s a sad indictment of our society that I need to include a why lying is wrong section in such a blog post.

• [1] https://www.aldimobile.com.au/corrective-notice
• [2] https://www.aldimobile.com.au/newplans

I will try to report my Debian activities here. I am trying to retake them and as I'm usually busy at work, I have limited amount of time to do so, they stand small for now. A new mailing list, debian-astro, has been created. This was requested to create a space to allow a discussion space around astronomy for Debian, both for professionals and amateurs, to potentially look into a blend, and in general to talk about packaging and development of astronomy-related tools into Debian. Thanks to those interested on making this happen. Go subscribe today!

That's it, I'm going to do it: I have now committed myself to writing a scalable, caching, reverse HTTP proxy. The biggest question right now is implementation language; obviously "threading" of some kind is required so it is a choice between Perl's anyevent, Python's twisted, Rubys event machine, or node.js. I'm absolutely, definitely, not going to use C, or C++. Writing a a reverse proxy in node.js is almost trivial, the hard part will be working out which language to express the caching behaviour, on a per type, and per-resource basis. I will ponder.

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.

The GSoC student application period is over, and the last two days were pretty interesting. For a few years now, Olly Betts has provided us with a spreadsheet to graph the number of applicants to an organization over time. Here s the graph for Debian this year: (Historical graphs: 2013, 2012. Spreadsheet available from Olly s blog) On Wednesday, I was thinking hmm, 30 applicants, this is a slow year . Well, the number of proposals more than doubled in the last two days, to conclude on a whooping 68 applications! The last one was submitted just three seconds before the deadline If you want to take a look at the proposals, head over to the Debian wiki. Time to get on reviewing! The final student acceptances will be published in just less than a month, on April 21st.

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.

Keeping your DVD collection safe from scratches and curious children fingers while still having it available when you want to see a movie is not straight forward. My preferred method at the moment is to store a full copy of the ISO on a hard drive, and use VLC, Popcorn Hour or other useful players to view the resulting file. This way the subtitles and bonus material are still available and using the ISO is just like inserting the original DVD record in the DVD player. Earlier I used dd for taking security copies, but it do not handle DVDs giving read errors (which are quite a few of them). I've also tried using dvdbackup and genisoimage, but these days I use the marvellous python library and program python-dvdvideo written by Bastian Blank. It is in Debian already and the binary package name is python3-dvdvideo. Instead of trying to read every block from the DVD, it parses the file structure and figure out which block on the DVD is actually in used, and only read those blocks from the DVD. This work surprisingly well, and I have been able to almost backup my entire DVD collection using this method. So far, python-dvdvideo have failed on between 10 and 20 DVDs, which is a small fraction of my collection. The most common problem is DVDs using UTF-16 instead of UTF-8 characters, which according to Bastian is against the DVD specification (and seem to cause some players to fail too). A rarer problem is what seem to be inconsistent DVD structures, as the python library claim there is a overlap between objects. An equally rare problem claim some value is out of range. No idea what is going on there. I wish I knew enough about the DVD format to fix these, to ensure my movie collection will stay with me in the future. So, if you need to keep your DVDs safe, back them up using python-dvdvideo. :)

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'm currently a contractor, working for/with Dyn, until April the 11th. I need to decide what I'm doing next, if anything. In the meantime here are some diversions:

Some trivial security issues

I noticed and reported two more temporary-file issues insecure temporary file usage in apt-extracttemplates (apt), and libreadline6: Insecure use of temporary files - in _rl_trace. Neither of those are particularly serious, but looking for them took a little time. I recently started re-auditing code, and decided to do three things:

• Download the source code to every package installed upon this system.
• Download the source code to all packages matching the pattern ^libpam-, and ^libruby-*.

I've not yet finished slogging through the code, but my expectation will be a few more issues. I'll guess 5-10, given my cynical nature.

NFS-work

I've been tasked with the job of setting up a small cluster running from a shared and writeable NFS-root. This is a fun project which I've done before, PXE-booting a machine and telling it to mount a root filesystem over NFS is pretty straight-forward. The hard part is making that system writeable, such that you can boot and run "apt-get install XX". I've done it in the past using magic filesystems, or tmpfs. Either will work here, so I'm not going to dwell on it.

Another year

I had another birthday, so that was nice. My wife took me to a water-park where we swam like fisheseses, and that tied in nicely with a recent visit to Deep Sea World, where we got to walk through a glass tunnel, beneath a pool FULL OF SHARKS, and other beasties. Beyond that I received another Global Knife, which has now been bloodied, since I managed to slice my finger open chopping mushrooms on Friday. Oops. Currently I'm in that annoying state where I'm slowly getting used to typing with a plaster around the tip of my finger, but knowing that it'll have to come off again and I'll get confused again.

Linux Distribution

I absolutely did not start working on a "linux distribution", because that would be crazy. Do I look like a crazy-person? All I did was play around with GNU Stow, and ponder the idea of using a minimal LibC and GNU Stow to organize things. It went well, but the devil is always in the details. I like the idea of a master-distribution which installs pam, ssh, etc, but then has derivitives for "This is a webserver", "This is a Ruby server", and "This is a database server". Consider it like task-selection, but with higher ambition.

There's probably more I could say; a new kitchen sink (literally) and a new tap have made our kitchen nicer, I've made it past six months of regular gym-based workouts, and I didn't die when I went to the beach in the dark the other night, so that was nice. Umm? Stuff? Have a nice day. Thanks.

The Debian Security Team announced in the bits from their last meeting that they're considering to ask for the addition of a new suite to provide long term support (LTS) for Squeeze. Quoting their announcement:

• It needs to be pointed out that for this effort to be sustainable actual contributions by interested parties are required. squeeze-lts is not something that will magically fall from the sky. If you're dependent/interested in extended security support you should make an effort to contribute, either by contributing on your own or by paying a Debian developer/consultant to contribute for you. The security team itself is driving the effort, NOT doing it. Some team members will contribute to it individually, however.
• Anyone interested in contributing, please get in touch with team@security.debian.org. We'll setup an initial coordination list with all interested parties. All policies / exact work will be sorted out there.

This means this is still not something settled and if you or your company is insterested in joining this effort, you should contact the security team ASAP. So they can see if there is enough people and resources to launch the LTS.

Web cookies are meant to store user preferences for a website, but they are often misused for evil purposes, such as tracking him, sometimes across distinct websites.For the user, there is a simple solution to that problem: set up his browser to refuse cookies by default, and use an extension such as Cookie Monster to accept them on trusted websites where they are known to be useful. Unfortunately, that reveals another problem: some shitty websites will just not work at all without cookies. Well, there is a Firefox extension that brings the solution to that: Self-Destructing Cookies. It works in a fairly simple way: cookies for each are accepted for each website, but destroyed when the user leaves it. So, does EvilCorp want to use a cookie, and refuse to work without it? No problem, here it is. Want to retrieve it on next visit? No way.

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.

Today was a very busy day for me. First up, I had my chiropractic adjustment. Then I had my half-yearly dental checkup. Then I got stuck into cleaning the house. Fortunately I'd done a bit the afternoon before, otherwise I'd never have gotten it done before my massage. I'm starting to seriously consider getting a cleaner. I can make much better use of the limited time I get than cleaning the house. Zoe's Kindergarten has a Parent Advisory Group or something like that, which meets monthly. I wasn't able to attend the first one, but the second one was today, about an hour before pickup, so I grabbed a quick lunch after my massage and biked over to Kindergarten early. The meeting wasn't particularly interesting. The majority of it revolved around fund raising. At pickup time, Zoe was fast asleep again, and had another massive meltdown when I woke her up. It took forever to get her out. She wanted to give Megan a hug, but Megan had long gone. Then, rather fortuitously, Megan's Dad texted me to tell me they were in the playground on the neighbouring school grounds, so I managed to use that as an incentive to get Zoe moving. I didn't know until today, but at the foothill of the neighbouring primary school, there's some play equipment. A few of the Kindergarten kids seem to have a play over there after Kindergarten. Megan and Zoe played there for a bit before it was time to go. Once we got home, we unpacked and then walked down to the Hawthorne Garage to get some vegetables, and then, after buying some milk from the corner store and another grumpy meltdown, I figured a quiet afternoon was in order, so Zoe watched a DVD for a bit while I prepared dinner. I'd bumped into the mother of Zoe's friends Eva and Layla from her old day care while I was at the dentist in the morning, and arranged for her to drop by to pick up a copy of the photos I'd taken at their 4th birthday party. I'd hoped that she'd bring the girls with her, and had told Zoe they'd be dropping by, but unfortunately she came on the way to picking them up from day care, so Zoe was a bit disappointed. We did arrange to have them over for dinner next Friday, so I'm sure that will be very exciting. After that, we had dinner, and a fairly uneventful bedtime. It's hot again, so I hope that doesn't mess with her sleep.

The lack of journal updates recently is due to a lot of work chaos combined with getting obsessed with various leisure activities (to blunt the work stress) that don't result in public writing. Normalcy seems to be slowly returning, but it will be a while yet. This release of my collection of utility libraries and scripts only has updates to some of the Perl test infrastructure. Testing Perl scripts for strictness, warnings, and syntax errors now supports listing a set of modules required for meaningful script testing. This converts failures to skipped tests if the reason for the syntax check failure is that a required module is not installed. This release also works around two problems with Perl::Tidy 20130922 related to its new log (mis)feature. Perl::Tidy now attempts to create a log file in the current directory whenever it runs unless this is explicitly turned off, and the Perl::Critic policy doesn't know to do that. (Debian bug #742004) I now unlink that file if it exists, after the test completes, and skip the Perl critic testing if the source directory is read-only (since failure to create the log file is treated by Perl::Tidy as a fatal error). You can get the latest version from the rra-c-util distribution page.

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.