As some may have seen, zack put out a note about the GNOME OPW. The GNOME OPW program, as some of you may know, is the GNOME Outreach Program for Women. Debian has been considering participating this year, and I think it s something we should focus on this year. So, please, if you have ideas, please feel free to send along ideas on that thread it d be amazing to get this going (in conjunction with) GSoC this year. Also, if you have any GSoC ideas, please do also add those! GNOME OPW allows for things that are non-technical, so feel free to post non-technical things too (publicity team, www team, I m looking at you!)

We have asked Moray Allan, one of the three candidates for DPL elections 2013, to tell our readers about himself and his ideas for the Debian Project. You can also read the interviews to the other two candidates: Lucas Nussbaum and Gergely Nagy.

---

Please tell us a little about yourself. I'm Moray Allan, from Edinburgh in Scotland. I'm 32. After working in academic research for a few years, I'm now working freelance on a wide mixture of topics, with recent projects in Indonesia, Romania and Kuwait. When I'm not working, I'm likely to be found walking through a city or the countryside, or otherwise relaxing at home reading a novel in French or Spanish. What do you do in Debian and how did you started contributing? In recent years, most of my Debian time was taken up organising the annual Debian conferences. But I still have a load of packages, mostly connected to an upstream Linux-on-handheld-computers project I was working on before I joined Debian to create packages for it. Why did you decide to run as DPL? I've been involved in Debian for about 10 years now, including working for the last few years in DebConf in a way similar to how the DPL acts within overall Debian. Previously I'd ruled out running due to lack of time, but currently I'm in a more flexible work situation. It seems the right time to put myself forward, and see if the ideas in my platform interest project members. Three keywords to summarise your platform. Transparency, communication, openness. (Three ways I'd like us to think about teams in Debian.) What are the biggest challenges that you envision for Debian in the future? I think the biggest challenges are for free software in general.
End-users are moving to more closed hardware -- will our software be able to run on the phones and tablets people are shifting towards? At the same time, end-users and server users are moving to "the cloud", and often depending more heavily on non-free infrastructure outside their own control. What are, in your opinion, the areas of the project more in need of technical and/or social improvements? In my platform I give a few ideas about teams and delegations, coordination and mediation, and both internal and external communication, including more organised fundraising. These are areas where I think relatively simple changes can give big benefits. Why should people vote for you? I have proven leadership experience within Debian, as I've been working on coordination and mediation tasks for some years already. At the same time, I do regular packaging work, and work in other parts of Debian like the press and publicity teams, so I'm in touch with the experience of normal Debian contributors. People should vote for me if they support my platform, which is about coordination-level changes that I would have no mandate or authority to push through unless I am elected. Name three tools you couldn't stay without. APT, emacs, ssh. What keep you motivated to work in Debian? I've used Debian on all my computers for a long time, and by now working on the distribution myself feels a natural part of that.
Fortunately I'm constantly positively surprised by Debian and by the Debian community. Are there any other fields where you call yourself a geek, besides computers? Certainly history (such as the eastern Mediterranean region in late antiquity), languages (including dead ones) and music (especially Josquin to Monteverdi).

We have asked Lucas Nussbaum, one of the three candidates for DPL elections 2013, to tell our readers about himself and his ideas for the Debian Project. You can also read the interviews to the other two candidates: Gergely Nagy and Moray Allan.

---

Please tell us a little about yourself. Hi! I'm a 31 years old french computer geek. In my day job, I'm an assistant professor (Ma tre de Conf rences) of Computer Science at Universit de Lorraine. What do you do in Debian and how did you started contributing? Like many, I started contributing to Debian by creating and maintaining packages for my own software, in the Ruby team. Then, I discovered that, even if it's not so obvious from the outside, there are a lot of areas in Debian that could use more contributors. So I just started to contribute to more and more things. There's a list of things I did in Debian in my platform. What I have been doing recently is:

• rebuild all packages in Debian on a regular basis in order to identify packages that can no longer be built, and file bugs accordingly. In order to do that efficiently, I use cluster and cloud resources (more info)
• develop and maintain Ultimate Debian Database, a data aggregator that collects data in most Debian services so that it is possible to expose it in interesting ways (e.g. find release-critical bugs affecting popular packages).
• write and maintain a Debian Packaging tutorial, (packaging-tutorial package), to provide an easy-to-read introduction to packaging in Debian.

Why did you decide to run as DPL? Two main reasons:

• Most of my Debian contributions aim at addressing problems at the distribution scale (cross-distro collaboration, Quality Assurance, data-mining). Being DPL is a great way to contribute to Debian at this level.
• the DPL campaign is a great time in Debian where we discuss the project's problems, politics and visions. Being a candidate is in itself a way to contribute to Debian (though it would be better if we had those discussions outside DPL campaigns too).

Three keywords to summarise your platform. (re-)make Debian the center of the Free Software ecosystem; foster innovation inside Debian; reduce barriers to contributions What are the biggest challenges that you envision for Debian in the future? I often have the impression that the project is losing momentum, positive energy, and slowing down. It feels like we are living on the benefits of the past. A lot of very cool things happen in the Debian ecosystem, but very often outside the Debian project (in derivative distributions). Debian should aim at reinforcing its position in the center of the Free Software ecosystem: it should be the main active intermediary between upstream projects and final users. To achieve that, we need to reinforce the visibility and the impact of Debian. This is extremely important because the values we fight for as a project are often neglected by our derivatives. What are, in your opinion, the areas of the project more in need of technical and/or social improvements? Fostering innovation inside Debian: we should be more welcoming towards innovation and experiments inside the project. Often, we merely tolerate them, and bureaucracy makes them hard and slow to conduct. As a result, people tends to innovate outside the Debian project. Making it easier to contribute to Debian: we compete with more and more projects to attract contributors. While we are already quite good at welcoming new contributors with good documentation and mentoring (much better than people usually think), there's still a lot of room for improvement. Why should people vote for you? A great thing in Debian's voting system is that you don't vote "for" or "against" a specific candidate. Instead, due to our use of the Condorcet method, you rank candidates (and also indicate those who you consider suitable for the role by ranking a virtual "None of the above" candidate). Why am I a good candidate? My previous contributions to Debian show that I have a pretty good understanding of the inner workings of the project, and that I have a track record of managing projects successfully inside Debian. I think that those are two required qualities for a DPL. Name three tools you couldn't stay without. vim, mutt, ssh. What keep you motivated to work in Debian? Debian is a fantastic project from a technical point of view (focus on technical excellence, lots of interesting challenges), but also from a social point of view: the Debian community is a great community where I have lots of good friends. Also, what's great when you contribute to Debian is that your work has a real impact, and that you see people using stuff you worked on everywhere. Are there any other fields where you call yourself a geek, besides computers? I'm not sure this really qualifies as "besides computers", but I've gotten very interested in the OpenStreetMap project lately. I very much enjoy exploring unmapped areas on a mountain bike. It feels like being Christopher Columbus or Marco Polo, but 20 minutes from home. ;) The OpenStreetMap and Debian projects also share many values, such as a great attention to quality and details.

We have asked Gergely Nagy, one of the three candidates for DPL elections 2013, to tell our readers about himself and his ideas for the Debian Project. You can also read the interviews to the other two candidates: Lucas Nussbaum and Moray Allan.

---

Please tell us a little about yourself. I was born in Hungary, a little bit over three decades ago, as a son of a biochemist and a pharmacist, who gave me the name Gergely Nagy (however, online - and offline too by now - I'm mostly known by my nickname, algernon). I went on to study human arts (hungarian grammar & literature, in particular), and to support this passion, I work as a software engineer, one who gets paid to work on free software. As such, I'm in a fortunate situation where my hobby supports my passion, and my hobby aligns well with my Debian work too. What do you do in Debian and how did you started contributing? At the moment, apart from maintaining a few packages, I'm doing a few other, mostly invisible things, like reassigning misfiled bugs so they don't end up being forgotten; or review newly uploaded packages before they enter the archive, making sure we are allowed to distribute them, and that their quality is up to our standards. I used to do quite a lot of other things, but I chose to spend the past year mostly invisible, learning. I started contributing by packaging an editor I was using at the time, but quickly ended up adopting another package - things escalated from there quickly. Why did you decide to run as DPL? There were two reasons that motivated me to run: one is that I believe I can bring something new to the table, that I can help Debian expand in new directions. The other reason is that I'm always on the lookout for new ways to contribute back to Debian, and being the project leader is a position where I believe I could contribute most at this point in time. Three keywords to summarise your platform. Non-technical contributors. What are the biggest challenges that you envision for Debian in the future? The biggest challenge is growing up, to become more than a group of computer geeks creating an amazing distribution. To become a community of a wide variety of people, where both computer geeks and art geeks feel equally at home. Yet, at the same time, where we as a project, keep our focus straight, and be the champions of Free Software. We just need to realize that there's much more to Free Software than the software itself. What are, in your opinion, the areas of the project more in need of technical and/or social improvements? I believe that while we do have many areas where we could use technical improvements, we are reasonably safe there, because we do have very skilled technical people to help us solve these problems. We can make our tools better, we can develop our infrastructure better to aid us even more - and so on and so forth. While we need work on many areas, we're on the right track there. However, when it comes to social issues, we're at a loss. We have serious trouble keeping certain topics civilised on mailing lists, we have trouble attracting women, and we have trouble reaching people who are not naturally exposed to Debian (or Free Software). We could really use a more diverse community, but that requires us to overcome quite a lot of social roadblocks, so to say. Outreach is one particular area where we need much more technical and social improvements. Why should people vote for you? People should vote me, because they found my platform, my answers on debian-vote@, and my ideas and goals convincing and worthy to pursue. People should vote me, because they trust I'll be able to serve the project well. Name three tools you couldn't stay without. Emacs, git and a pencil. Because with these three, I can pretty much do anything. What keep you motivated to work in Debian? The community. Over the years, I had the good fortune to meet with a lot of people I hold in high esteem, whose enthusiasm and motivation I found inspiring. For any other common goals Debian and I may share, in the end, it is the people within Debian that keep me motivated. Are there any other fields where you call yourself a geek, besides computers? I'm not quite there yet, but I'm working hard on becoming a human arts geek, or at least a geek of the hungarian language.

remctl is the client/server protocol that we use for basically all our middleware connections at Stanford. It uses Kerberos GSS-API for authentication and privacy and is designed to be as simple as possible, just running a command on the server with the provided arguments. We've found this design to be extremely effective and a significant improvement over trying to put web servers everywhere to use something like REST. The primary feature in this release is a new Net::Remctl::Backend Perl module that automates a lot of the work of creating remctl backend scripts written in Perl. Over the years, we've developed a lot of conventions for things like help output and command-line processing, and this rolls those conventions into a module that handles a lot of the work of formatting help output and handling command dispatch. This is just the first cut, but it already supports argument validation, handling standard input, formatting help output, and handling per-option command-line flags. Later versions will feature better integration with Kerberos and hopefully better integration into the new remctl help and summary features. Also in this release are new C APIs contributed by Jeffrey Hutzelman that allow one to start a remctl connection over an existing sockaddr, a list of struct addrinfo results, or an open socket. In the bug fix department, this release removes all the prototypes from Net::Remctl functions following current Perl best practices (prototypes cause weird context issues and behave in surprising ways), and rejects the empty command to remctl_command rather than trying to malloc 0 bytes. You can get the latest version from the remctl distribution page.

procps-ng version 3.3.7 was released today. It has some new and interesting features in the top program that Jim has been busy working on. There is a new filter feature which can exclude fields that match a value for example. The remainder of the changes are small bug fixes and getting the compile warnings count down with -Wall enabled. The library revision was updated but this did not involve an API or ABI change. procps-ng can be downloaded off the sourceforge page which has the current and previous releases stored there. Alternatively you can visit our gitorious page if git fetch is more your thing. Debian packages will be going into experimental until the freeze is over and we get things unblocked.

kadmin-remctl is a remctl wrapper around the kadmin protocol that we use at Stanford to provide an easier API to Kerberos administration (for Java applications in particular, but also somewhat for humans) and to use a finer-grained ACL than Kerberos kadmin provides. This package is still kind of a mess, with some Stanford-specific bits and a whole lot of messy Perl code, but we had some serious bugs that I needed to deal with. So this is mostly a bug-fix release without the much-delayed cleanup. (More on that in a moment.) The primary problem this release addresses is a very annoying network problem that we've been having at Stanford. Some interaction between our new OpenFlow fabric and our current firewalls causes some number of TCP connections to just be dropped under heavy load. Since we do a lot of kadmin queries (although we're working on various caching strategies to cut down on that), kadmin sees this a lot, which results in failures that cause user-noticable problems in various applications. After some experimentation, though, we found that most of the failures were on the original connection, so catching connection failure and retrying works around most of the problem (at the cost of a delay). That was only the beginning of the odyssey, however. When I added the retry code, I found that we were improperly configuring Heimdal::Kadm5 to actually throw exceptions. And then, even after fixing that, I found that error messages were still printed to standard error. It turns out that the underlying Heimdal libraries print warnings to standard error by default unless the application directs the log messages somewhere else, and Heimdal::Kadm5 doesn't have a look available to do that. So I ended up adding a bunch of ugly code to close standard error while doing the initial connection. This release also cleans up a bunch of the error handling, including going back to the behavior that the code always should have had: check_passwd returns a non-zero status if the password is rejected. I lost an argument with a co-worker about that years ago, but they've since left and I still think that's the right thing to do. The new code also uses IPC::Run to run commands, which makes for much shorter and saner code, and improves error reporting when trying to change the password of a disabled account with Heimdal's kpasswd. It also strips whitespace from the username in passwd_change. At some point, I'm going to rewrite this software completely, but what that really needs is a much saner underlying Kerberos module. One of the problems with all existing Kerberos Perl modules is that they all use various hacks to try to build with different Kerberos libraries within the ExtUtils::MakeMaker framework, which is totally inadequate. (That's also why there aren't any Perl modules linked with the server version of the kadmin libraries, so they're all painfully slow and require a keytab even when running directly on the KDC.) I think the answer is a brand new Perl module that incorporates my portability layer on top of Kerberos libraries and a configure script that does proper probing for Kerberos library functionality, and then integrates that Autoconf probing into a Module::Build infrastructure. There are some bits on CPAN that one could start with, but not all the proper glue, so this is a bit of a project. I also have to figure out how to link different extensions in the project with different libraries, since having separate distributions for the server and client kadmin modules (which share 95% of their code) is dumb, but they have to be separately linked with the appropriate library. Sometime, when I have some time, I'll do that, and then rebuild a remctl interface on top of that infrastructure with a much better protocol. In the meantime, you can get the latest version of kadmin-remctl from the kadmin-remctl distribution page.

But you can t just tar.gz up the bare repositories on the server and hope for the best. Maybe a given repository will be in a valid state; maybe it won t.

-- Jeff Mitchell in a followup to the recent KDE near git disaster This was a surprising statement to me. I seem to remember that one of (many) selling points for git talked about back in the day was that it avoided the problem that making a simple cp (or backup) of a repository could lead to an inconsistent result. A problem that subversion repositories had, and required annoying commands to work around. (svnadmin $something -- iirc the backend FSFS fixed or avoided most of this issue.) This prompted me to check how I handle it in ikiwiki-hosting. I must have anticipated a problem at some point, since ikisite backup takes care to lock the git repository in a way that prevents eg, incoming pushes while a backup is running. Probably, like the KDE developers, I was simply exercising reasonable caution. The following analysis has probably been written up before (train; limited network availability; can't check), but here are some scenarios to consider:

• A non-bare repository has two parts that can clearly get out of sync during a backup: The work tree and the .git directory.
  • The .git directory will likely be backed up first, since getdirent will typically return it first, since it gets created first . If a change is made to the work tree during that backup, and committed while the work tree is being backed up, the backup won't include that commit -- which is no particular problem and would not be surprising upon restore. Make commit again and get on with life.
  • However, if (part of) the work tree is backed up before .git, then any changes that are committed to git during the backup would not be reflected in the restored work tree, and git diff would show a reversion of those changes. After restore, care would need to be taken to reset the work tree (without losing any legitimate uncommitted changes).
• A non-bare repository can also become broken in other ways if just the wrong state is snapshotted. For example, if a commit is in progress during a backup, .git/index.lock may exist, and prevent future commits from happening, until it's deleted. These problems can also occur if the machine dies at just the right time during a commit. Git tells you how to recover. (git could go further to avoid these problems than it does; for example it could check if .git/index.lock is actually locked using fcntl. Something I do in git-annex to make the .git/annex/index.lock file crash safe.)
• A bare repository could be receiving a push (or a non-bare repository a pull) while the backup occurs. These are fairly similar cases, with the main difference being that a non-bare repository has the reflog, which can be used to recover from some inconsist states that could be backed up. Let's concentrate on pushes to bare repositories.
  • A pack could be in the process of being uploaded during a backup. The KDE developers apparently worried that this could result in a corrupt or inconsistent repository, but TTBOMK it cannot; git transfers the pack to a temp file and atomically renames it into place once the transfer is complete. A backup may include an excess temp file, but this can also happen if the system goes down while a push is in progress. Git cleans these things up.
  • A push first transfers the .git/objects, and then updates .git/refs. A backup might first back up the refs, and then the objects. In this case, it would lose the record that refs were pushed. After being restored, any push from another repository would update the refs, even using the objects that did get backed up. So git recovers from this, and it's not really a concern.
  • Perhaps a backup chooses to first back up the objects, and then the refs. In this case, it could back up a newly changed ref, without having backed up the referenced objects (because they arrived after the backup had finished with the objects). When this happens, your bare repository is inconsistent; you have to somehow hunt down the correct ref for the objects you do have. This is a bad failure mode. git could improve this, perhaps, by maintaining a reflog for bare repositories. (Update: core.logAllRefUpdates can be set to true for bare repositories, but is disabled by default.)
• A "backup" of a git repository can consist of other clones of it. Which do not include .git/hooks/ scripts, .git/config settings, and potentially other valuable information, that strangely, we do not check into revision control despite having this nice revision control system available. This is the most likely failure mode with "git backups". :P

I think that it's important git support naive backups of git repositories as well as possible, because that's probably how most backups of git repositories are made. We don't all have time to carefully tune our backup systems to do something special around our git repositories to ensure we get them in a consistent state like the KDE project did, and as their experience shows, even if we do it, we can easily introduce other, unanticipated problems. Can anyone else think of any other failure modes like these, or find holes in my slightly rushed analysis?

---

PS: git-annex is itself entirely crash-safe, to the best of my abilities, and also safe for naive backups. But inherits any problems with naive backups of git repositories.

So. following up on my previous post about implementing a libravatar server, this will be an announcement of a quick Qt5 based client library for libravatar so that everyone can put avatars everywhere! Get it while it is hot on
git.kde.org There isn t much screenshots to show off, given it is effectively just converting a string with an email into a URL for a image. And thanks to Martin Sandsmark for coming up with such a great name. Now I expect him to show off what it can be used for. Another thanks goes to Andreas Hartmetz for going thru the code & api.

A few days ago, during a discussion in EFN about interesting books to read about copyright and the data retention directive, a suggestion to read the 1968 short story Kod mus by Tore ge Bringsv rd came up. The text was only available in old paper books, and thus not easily available for current and future generations. Some of the people participating in the discussion contacted the author, and reported back 2013-03-19 that the author was OK with releasing the short story using a Creative Commons license. The text was quickly scanned and OCR-ed, and we were ready to start on the editing and typesetting. As I already had some experience formatting text in my project to provide a Norwegian version of the Free Culture book by Lawrence Lessig, I chipped in and set up a DocBook processing framework to generate PDF, HTML and EPUB version of the short story. The tools to transform DocBook to different formats are already in my Linux distribution of choice, Debian, so all I had to do was to use the dblatex, dbtoepub and xmlto tools to do the conversion. After a few days, we decided to replace dblatex with xsltproc/fop (aka docbook-xsl), to get the copyright information to show up in the PDF and to get a nicer <variablelist> typesetting, but that is just a minor technical detail. There were a few challenges, of course. We want to typeset the short story to look like the original, and that require fairly good control over the layout. The original short story have three parts/scenes separated by a single horizontally centred star (*), and the paragraphs do not contain only flowing text, but dialogs and text that started on a new line in the middle of the paragraph. I initially solved the first challenge by using a paragraph with a single star in it, ie <para>*</para>, but it made sure a placeholder indicated where the scene shifted. This did not look too good without the centring. The next approach was to create a new preprocessor directive <?newscene?>, mapping to "<hr/>" for HTML and "<fo:block text-align="center"><fo:leader leader-pattern="rule" rule-thickness="0.5pt"/></fo:block>" for FO/PDF output (did not try to implement this in dblatex, as we had switched at this time). The HTML XSL file looked like this:

<?xml version='1.0'?> 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version='1.0'>
  <xsl:template match="processing-instruction('newscene')">
    <hr/>
  </xsl:template>
</xsl:stylesheet> 

And the FO/PDF XSL file looked like this:

<?xml version='1.0'?> 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version='1.0'>
  <xsl:template match="processing-instruction('newscene')">
    <fo:block text-align="center">
      <fo:leader leader-pattern="rule" rule-thickness="0.5pt"/>
    </fo:block>
  </xsl:template>
</xsl:stylesheet> 

Finally, I came across the <bridgehead> tag, which seem to be a good fit for the task at hand, and I replaced <?newscene?> with <bridgehead>*</bridgehead>. It isn't centred, but we can fix it with some XSL rule if the current visual layout isn't enough. I did not find a good DocBook compliant way to solve the linebreak/paragraph challenge, so I ended up creating a new processor directive <?linebreak?>, mapping to <br/> in HTML, and <fo:block/> in FO/PDF. I suspect there are better ways to do this, and welcome ideas and patches on github. The HTML XSL file now look like this:

<?xml version='1.0'?> 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version='1.0'>
  <xsl:template match="processing-instruction('linebreak)">
    <br/>
  </xsl:template>
</xsl:stylesheet> 

And the FO/PDF XSL file looked like this:

<?xml version='1.0'?> 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version='1.0'
  xmlns:fo="http://www.w3.org/1999/XSL/Format">
  <xsl:template match="processing-instruction('linebreak)">
    <fo:block/>
  </xsl:template>
</xsl:stylesheet> 

One unsolved challenge is our wish to expose different ISBN numbers per publication format, while keeping all of them in some conditional structure in the DocBook source. No idea how to do this, so we ended up listing all the ISBN numbers next to their format in the colophon page. If you want to check out the finished result, check out the source repository at github (future/new/official repository). We expect it to be ready and announced in a few days.

I've made two new designs for Trunk Tees, my Cafepress store. Thank you to Richard Braakman for suggesting the .* one. Here's all the older designs as well:

I ve been using this process for debugging the installer while launched from a Debian Live desktop. Having a full live environment at your disposal during install is a boon to debugging because you don t have to work within the constraints normally imposed upon you by the limited debian-installer environment. Caveat: running debian-installer from the debian-installer-launcher still has one or two unresolved issues, so unless you re specifically working on live integration issues like I am, compare with a conventional d-i image install to gain the added confidence the install is the same in both environments. There are no longer active maintainers working on debian-installer-launcher and live-installer, and I think it s really important for wheezy to release with solid support for live installs, so I ve been using this setup to try to solve #702335. So far, progress is slow because I m new to this. If anyone is interested in collaborating in this work, give me a shout. I am SynrG @ irc.oftc.net and can be found on #debian-live and #debian-boot if you would like to drop in. Overview:

1. Use images/lxde-desktop config from live-images.git and build your own image with live-build >=3.0.1-1. Just add -b hdd in auto/config before starting your build, as having a read/writable image is handy for this exercise.
2. Boot the live medium. You may prefer to do this in a VM for convenience, having prepared a blank virtual disk image as your target in advance.
3. Make any small changes you want to the installer before launching it. A quick hack I ve used is to sudo vi /usr/sbin/debian-installer-launcher and near the end on the line after prepare right before run , open a new line and add bash so an interactive shell will be opened after the installer is extracted but before it is launched. For larger changes (e.g. inclusion of updated udebs, etc.) add them to your live image configuration before building as described in live-manual.
4. Open two root terminals and do debian-installer-launcher -t debug in one and tail -f /lib/live/installer/var/log/syslog in the other. If you ve added the hack from step 3, don t forget to exit the interactive shell after making changes. Now you can watch debug output as you go through the steps of the installer. If you like, you may append additional boot prompt parameters (e.g. preseeds) to the debian-installer-launcher command.
5. During the install, you may modify other parts of the unpacked installer under /lib/live/installer (e.g. to add set -x to some scripts) prior to executing steps that would call them.

Following up on using Debian on the WeTab with GNOME Shell I figured accelerated video using the built in CrystalHD to save battery power and CPU cycles would be nice to have. There's even a Debian package available but not for gstreamer 1.0 (which is used by GNOME 3.6) so I had a look at gstreamer's plugin writers guide and porting guide and updated the driver. Packages are here until there's a new upstream version or Debian package release. This blog is flattr enabled.

The Standalone Sysadmin asks, How do you manage database server instances? :

Do you have one (or a few) centralized database servers, either standalone or clustered, or do you spread the load like we are currently?

His argument for centralisation is one of easing the management burden of configuration and backups, whereas the distributed approach eliminates a central point of failure and performance degradation. I go for distributed, all the way. For a start, we run so many databases for so many customers that there s no way on earth we could stand up a small number of database servers and handle all the load (hell, we ve got single customers who consume a cluster of machines with 384GB of RAM and all the SSDs you can eat). Security and permissions is a whole other kettle of fish; the contortions we d have to do to allow customers the level of management they need with a centralised database system would be immense. Then there s the need of some customers for MySQL, some for PgSQL, different performance tuning for different workloads nope, centralised DBs don t work for us. Given this, we ve bitten the bullet and solved pretty much all of the management problems. Installation and configuration is all handled via Puppet, and backups are trivial the same system that installs the DB server itself also drops a hook script that the backup agent uses to know that it has to dump a database server. Monitoring that this backup is taking place successfully is also automatically provisioned, so we know that we re not missing anything. Ultimately, this same approach applies to practically anything that you re tossing up between centralised and distributed. At scale, you can never rely on centralisation, so you may as well bite the bullet and learn how to do it distributed pretty much from the start. That saves some serious system shock when you discover what your hardware vendor wants for the next step up in big iron hardware

(btw, the source is on github) During the sprints at PyCon in a spare moment after some awesome OpenGov hacking, I ended up doing the unthinkable: rpython support in Hy. Yes. That s right. Lisp > Python > C > x86 instructions. The thanks here goes to Romain Guillebert - who is a really funny rpythonista and took the time to sit down and help me with this frankly insane idea. It works, though. I filed a bug on shipping rpython bits from PyPy s Debian package (hi, tumbleweed!), which should make building this a skitch easier. Finally, and unrelatedly, I also just got a .hy > .pyc compiler working (huzzah!) which means no one will ever know we wrote anything in Lisp, ever. As always, play with the REPL, star the code or have a laugh with it. Let me know what you hack up! I ll post the lightning talk I gave after it s posted :)

I just pushed out a new python-dbusmock release 0.6. Calling a method on the mock now emits a MethodCalled signal on the org.freedesktop.DBus.Mock interface. In some cases this is easier to track than parsing the mock s log or using GetMethodCalls. Thanks to Lars Uebernickel for this. DBusMockObject.AddTemplate() and DBusTestCase.spawn_server_template() can now load local templates from your own project by specifying a path to a *.py file as template name. Thanks to Lucas De Marchi for this feature. I also wrote a quite comprehensive template for systemd s logind. It stubs out the power management functionality as well as user/seat/session objects, and is convincing enough for loginctl. Some bits like AttachDevice is missing, as this sounds unlikely to be required for D-BUS mock tests, but please let me know if you need anything else. The mock processes now terminate automatically if their connected D-BUS goes down, as advertised in the documentation. You can get the new tarball from Launchpad, and I uploaded it to Debian experimental now. Enjoy!