Wireless mesh networks are self organising and self healing networks that can be used to connect computers across small and large areas, depending on the radio technology used. Normal wifi equipment can be used to create home made radio networks, and there are several successful examples like Freifunk and Athens Wireless Metropolitan Network (see wikipedia for a large list) around the globe. To give you an idea how it work, check out the nice overview of the Kiel Freifunk community which can be seen from their dynamically updated node graph and map, where one can see how the mesh nodes automatically handle routing and recover from nodes disappearing. There is also a small community mesh network group in Oslo, Norway, and that is the main topic of this blog post. I've wanted to check out mesh networks for a while now, and hoped to do it as part of my involvement with the NUUG member organisation community, and my recent involvement in the Freedombox project finally lead me to give mesh networks some priority, as I suspect a Freedombox should use mesh networks to connect neighbours and family when possible, given that most communication between people are between those nearby (as shown for example by research on Facebook communication patterns). It also allow people to communicate without any central hub to tap into for those that want to listen in on the private communication of citizens, which have become more and more important over the years. So far I have only been able to find one group of people in Oslo working on community mesh networks, over at the hack space Hackeriet at Husmania. They seem to have started with some Freifunk based effort using OLSR, called the Oslo Freifunk project, but that effort is now dead and the people behind it have moved on to a batman-adv based system called meshfx. Unfortunately the wiki site for the Oslo Freifunk project is no longer possible to update to reflect this fact, so the old project page can't be updated to point to the new project. A while back, the people at Hackeriet invited people from the Freifunk community to Oslo to talk about mesh networks. I came across this video where Hans J rgen Lysglimt interview the speakers about this talk (from youtube): I mentioned OLSR and batman-adv, which are mesh routing protocols. There are heaps of different protocols, and I am still struggling to figure out which one would be "best" for some definitions of best, but given that the community mesh group in Oslo is so small, I believe it is best to hook up with the existing one instead of trying to create a completely different setup, and thus I have decided to focus on batman-adv for now. It sure help me to know that the very cool Serval project in Australia is using batman-adv as their meshing technology when it create a self organizing and self healing telephony system for disaster areas and less industrialized communities. Check out this cool video presenting that project (from youtube): According to the wikipedia page on Wireless mesh network there are around 70 competing schemes for routing packets across mesh networks, and OLSR, B.A.T.M.A.N. and B.A.T.M.A.N. advanced are protocols used by several free software based community mesh networks. The batman-adv protocol is a bit special, as it provide layer 2 (as in ethernet ) routing, allowing ipv4 and ipv6 to work on the same network. One way to think about it is that it provide a mesh based vlan you can bridge to or handle like any other vlan connected to your computer. The required drivers are already in the Linux kernel at least since Debian Wheezy, and it is fairly easy to set up. A good introduction is available from the Open Mesh project. These are the key settings needed to join the Oslo meshfx network:

Setting	Value
Protocol / kernel module	batman-adv
ESSID	meshfx@hackeriet
Channel / Frequency	11 / 2462
Cell ID	02:BA:00:00:00:01

The reason for setting ad-hoc wifi Cell ID is to work around bugs in firmware used in wifi card and wifi drivers. (See a nice post from VillageTelco about "Information about cell-id splitting, stuck beacons, and failed IBSS merges! for details.) When these settings are activated and you have some other mesh node nearby, your computer will be connected to the mesh network and can communicate with any mesh node that is connected to any of the nodes in your network of nodes. :) My initial plan was to reuse my old Linksys WRT54GL as a mesh node, but that seem to be very hard, as I have not been able to locate a firmware supporting batman-adv. If anyone know how to use that old wifi access point with batman-adv these days, please let me know. If you find this project interesting and want to join, please join us on IRC, either channel #oslohackerspace or #nuug on irc.freenode.net. While investigating mesh networks in Oslo, I came across an old research paper from the university of Stavanger and Telenor Research and Innovation called The reliability of wireless backhaul mesh networks and elsewhere learned that Telenor have been experimenting with mesh networks at Gr nerl kka in Oslo. So mesh networks are also interesting for commercial companies, even though Telenor discovered that it was hard to figure out a good business plan for mesh networking and as far as I know have closed down the experiment. Perhaps Telenor or others would be interested in a cooperation? Update 2013-10-12: I was just told by the Serval project developers that they no longer use batman-adv (but are compatible with it), but their own crypto based mesh system.

This is a quick bug-fix release, since of course there was a significant bug in the recent 2.0 release. In this case, it was a problem with the build: if you configured the package without CDB support, it didn't build. Apparently I didn't retest that after doing some refactoring. I have good test suite techniques for reasonable code coverage, but not for testing various variant configurations at the Autoconf level. This is what a continuous build infrastructure would be good for, I know. We even have one sitting around; someday, I should invest in hooking my projects up to it. Anyway, also in this release is the start of an Autoconf fix so that --with-tinycdb without an argument works correctly, but I have more Autoconf work to do (also affecting rra-c-util). I also tweaked the error messages returned by the non-CrackLib portions of krb5-strength so that they would hopefully be more comprehensible to users while still being technically accurate. You can get the latest release from the krb5-strength distribution page.

Almost every time he got off the bus for the past month and a half, Jacob started his afternoon in the same way. Before toys, before his trains and his toy bus, before anything indoors, he went for our cats. Here he is, cradling his favorite, Tigger: Laura and I both grew up around cats. We had been talking about kittens, and shortly after we got engaged, one of my relatives offered us some free kittens. We went to his place one evening and selected two of them one calico and one tiger-colored. Since what is now my place will soon be our place, they came to live with me. Our cats were one of the first things we did to prepare for our lives together. Oliver wanted to name them some rather impractical sentence-long names ( The Cat Who Always Likes To Run ), so Laura and I suggested some names from one of their favorite books: Tigger and Roo. They both liked the names, but Oliver thought they should be called Tigger the Digger and Roo the Runner . Never mind that they were just 6 weeks old at the time, and not really old enough to either dig or run. Here s Oliver with Roo, the day after the kittens arrived here. I have always had outside cats, both because I m allergic to cats so I need them to be outside, and because they sometimes literally quiver with joy of being outdoors. Tigger and Roo often chased insects, wrestled with each other, ran up (and slowly came back down) trees, and just loved the outside. Sometimes, I have taken my laptop and wireless headset and work from the back porch. The kittens climb up my jeans, inspect the laptop, and once Roo even fell asleep on my lap at one of those times. Jacob has been particularly attached to Tigger, calling him my very best friend. When Jacob picks him up after school, Tigger often purrs while cradled in Jacob s arms, and Jacob comments that Tigger loves me. Oh dad, he knows I am his friend! The kittens have been growing, and becoming more and more comfortable with their home in the country. Whenever I go outside, it isn t long before there are two energetic kittens near my feet, running back and forth, sometimes being very difficult to avoid stepping on. I call and I see little heads looking at me, from up in a tree, or peeking out from the grain elevator door, or from under the grill. They stare for just a second, and then start running, sometimes comically crashing into something in their haste. Yesterday when I went to give them food, I called and no cats came. I was concerned, and walked around the yard, but at some point either they come or they don t. Yesterday afternoon, just after the bus dropped off Jacob, I discovered Tigger on the ground, motionless. Once Jacob was in the house, I went to investigate, and found Tigger was dead. As I was moving his body, I saw Roo was dead, too. Both apparently from some sort of sudden physical injury a bit mysterious, because neither of them were at a place where they had ever gone before. While all this was happening, I had to also think about how I was going to tell the boys about this. I tried to minimize what he could see, Jacob had caught an unavoidable glimpse of Tigger as we were walking back from the bus, but didn t know exactly what had happened. He waited in the house, and when I came back, asked me if Tigger was dead. I said he was. Jacob started crying, saying, Oh Dad, I am so sad , and reached up for a hug. I picked him up and held him, then sat down on the couch and let him curl up on my lap. I could quite honestly let him know he wasn t alone, telling him I am sad, too. Oliver arrived not long after, and he too was sad, though not as much as Jacob. Both boys pretty soon wanted to see them. I decided this was important for them for closure, and to understand, so while they waited in the house, I went back out to arrange the kittens to hide their faces, the part that looks most unnatural after they die. The boys and I walked out to where I put them, then I carried both of them the last few feet. We stood a little ways back close enough to see who was there, far enough to not get too much detail and they were both sniffling. I tried to put voice to the occasion, saying, Goodbye, Tigger and Roo. We love you. Oliver asked if they could hear us. I said No, but I told them what I felt like anyway. Jacob, through tears, said, Dad, maybe they are in heaven now. We went back inside. Jacob said, Oh dad, I am so sad. This is the saddest day of my life. My heart is breaking. Hearing a 7-year-old say that isn t exactly easy for a dad. Pretty soon he was thinking of sort of comfort activities to do, saying I think I would feel better if we did So they decided to watch a favorite TV program. Jacob asked if Laura knew yet, and when I said no, he got his take-charge voice and said, Dad, you will start the TV show for us. While we are watching, you will send Laura an email to tell her about Tigger and Roo. OK? What could I say, it wasn t a bad idea. Pretty soon both boys were talking and laughing. It was Big Truck Night last night, at a town about half an hour away. It s an annual event we were already planning to attend, where all sorts of Big Trucks firetrucks, school bus, combine, bucket truck, cement truck, etc show up and are open for kids to climb in and explore. It s always a highlight for them. They played and sang happily as we drove, excitedly opened and closed the big door on the school bus and yelled All Aboard! from the top of the combine. We ate dinner, and drove back home. When we got home, Jacob mentioned the cats again, in a sort of matter-of-fact way, and also wanted to make sure he knew Laura had got the message. A person never wakes up expecting to have to dump a bowl of un-eaten cat food, or to give an impromptu cat funeral for little boys. As it was happening, I wished they hadn t been around right then. But in retrospect, I am glad they were. They had been part of life for those kittens, and it is only right that they could be included in being part of death. They got visual closure this way, and will never wonder if the cats are coming back someday. They had a chance to say goodbye. Here is how I remember the kittens.

As I mentioned earlier, the information in the documents released by Edward Snowden show a clear pattern of corporate and government abuse of the information networks that are now deeply intertwined with the lives of many people all over the world. Surveillance is a power dynamic where the party doing the spying has power over the party being surveilled. The surveillance state that results when one party has "Global Cryptologic Dominance" is a seriously bad outcome. The old saw goes "power corrupts, and absolute power corrupts absolutely". In this case, the stated goal of my government appears to be absolute power in this domain, with no constraint on the inevitable corruption. If you are a supporter of any sort of a just social contract (e.g. International Principles on the Application of Human Rights to Communications Surveillance), the situation should be deeply disturbing. One of the major sub-threads in this discussion is how the NSA and their allies have actively tampered with and weakened the cryptographic infrastructure that everyone relies on for authenticated and confidential communications on the 'net. This kind of malicious work puts everyone's communication at risk, not only those people who the NSA counts among their "targets" (and the NSA's "target" selection methods are themselves fraught with serious problems). The US government is supposed to take pride in the checks and balances that keep absolute power out of any one particular branch. One of the latest attempts to simulate "checks and balances" was the President's creation of a "Review Group" to oversee the current malefactors. The review group then asked for public comment. A group of technologists (including myself) submitted a comment demanding that the review group provide concrete technical details to independent technologists. Without knowing the specifics of how the various surveillance mechanisms operate, the public in general can't make informed assessments about what they should consider to be personally safe. And lack of detailed technical knowledge also makes it much harder to mount an effective political or legal opposition to the global surveillance state (e.g. consider the terrible Clapper v. Amnesty International decision, where plaintiffs were denied standing to sue the Director of National Intelligence because they could not demonstrate that they were being surveilled). It's also worth noting that the advocates for global surveillance do not themselves want to be surveilled, and that (for example) the NSA has tried to obscure as much of their operations as possible, by over-classifying documents, and making spurious claims of "national security". This is where the surveillance power dynamic is most baldly in play, and many parts of the US government intelligence and military apparatus has a long history of acting in bad faith to obscure its activities. The people who have been operating these surveillance systems should be ashamed of their work, and those who have been overseeing the operation of these systems should be ashamed of themselves. We need to better understand the scope of the damage done to our global infrastructure so we can repair it if we have any hope of avoiding a complete surveillance state in the future. Getting the technical details of these compromises in the hands of the public is one step on the path toward a healthier society. PostscriptLest I be accused of optimism, let me make clear that fixing the technical harms is necessary, but not sufficient; even if our technical infrastructure had not been deliberately damaged, or if we manage to repair it and stop people from damaging it again, far too many people still regularly accept ubiquitous private (corporate) surveillance. Private surveillance organizations (like Facebook and Google) are too often in a position where their business interests are at odds with their users' interests, and powerful adversaries can use a surveillance organization as a lever against weaker parties. But helping people to improve their own data sovereignty and to avoid subjecting their friends and allies to private surveillance is a discussion for a separate post, i think.Tags: cryptography, nsa

Announcement After a very long work, over the course of 4 months, I have finished packaging the first RC1 of OpenStack. This comes on time, just 9 days before the official Havana release. Please do try this RC1 before the official 2013.2, code name Havana, is released, and hopefully uploaded to Debian. All of the packages are available from Debian Experimental, keeping Grizzly in Sid. However, there is also some private repositories that I maintain, holding Wheezy backports: deb http://havana.pkgs.enovance.com/debian havana main deb http://archive.gplhost.com/debian havana-backports main The first repository holds the packages maintained within the Alioth group. These are built directly from my Jenkins machine, on each git push. The 2nd repository is holding backports from Sid to Wheezy for the packages that I don t actively maintain (though a lot of them are in the Python module team, in which I do a lot of packaging and updates as well). A few numbers A few numbers about this now. I had to work on 145 source packages: at least backport them to Wheezy, and push them in the GPLHost archive repository above. This generates 360 binary packages. Out of these, I maintain 77 source packages within the Alioth OpenStack group, generating 209 .deb files. That s a lot of stuff to deal with (and I feel sometimes a bit dizzy about it). While OpenStack is a big jigsaw puzzle to solve for the users, it is even more for someone who has to deal with all the (sometimes buried in the the code) Python dependencies. I hope others will come and join me in this packaging effort, since over the time, there s more and more work to be done, as the project grows. Note that most of the work is unfortunately done on packaging (and updating) the Python dependencies, working on the packages themselves is done last, at the end of the cycle. Other things not packaged (yet) Before the release (and the forthcoming Hongkong summit on the 5th of November), I hope to be able to finish packaging TripleO. TripleO is in fact OpenStack on OpenStack, which works with nova-baremetal. I have no idea how to test or install this, though it sounds like a lot of fun. There are 6 source packages that need to be done. Also, pending on the FTP masters NEW queue, is Trove: Database as a Service. I hope this one can get through soon. There is, also, Marconi, which is an incubated project for a new message queuing service, which probably will replace RabbitMQ (I m not sure yet what it does, and I will be happy to hear about it at the summit). Lastly, there s Ironic, which will at some point, replace nova-baremetal. That is, it does cloud computing over bare metal, without virtualization. All of these new projects are still in an incubation stage, and are not part of the official release yet. Though, I have learned over the course of this past year, that with OpenStack, it s never early enough to start the packaging work. Thanks to my sponsor! Please note that all of this wouldn t be possible without eNovance sponsoring my packaging work. A big up to all of them for supporting and loving Debian! You guys rox. Also a special thanks to Mehdi / Sileth, for his work testing everything with the Tempest functional tests and the CI platform.

Just as last year, BalaBit applied to become a mentoring organisation for this year's Google Summer of Code, but like the year before, were not accepted. Instead, the openSUSE project was kind enough to give us two slots of their own, similarly to the year before - we are very thankful for this, and this year, both of the projects we took were closed successfully! So much so, that one of them was already merged into syslog-ng 3.5.0beta2, and the other one is being prepared for getting merged into the Incubator. I also helped out a little with Clojure & Leiningen packaging, although my contributions there were minimal at best.On the whole, I really liked this year's programme, our students accomplished a lot, and the whole summer was a great experience in itself, I learned a lot about mentoring, and about working with other people, people who are very new to the codebase they're working on. I would like to summarise what I learned and observed this year, in the hopes that others may find them useful too.This year, we set fairly ambitious goals for our students: they had to write a Redis and a MySQL destination, both of which presented interesting challenges to the students. None of them had prior experience with the syslog-ng source code, and their programming knowledge was mostly in C#, not plain old C which syslog-ng is written in. They also had to dabble a bit in the bowels of our overly complex configure.ac and a few Makefiles. Wasn't an easy task.In the beginning, we tasked the students to write proof of concept code, to get familiar with the libraries they will need to use - no syslog-ng involved at this point. This sounded like a good idea on paper, but without clear goals and milestones, a lot of time was spent on this task, and the students ran into a few dead-ends which could have been avoided, if we, the mentors, were more careful. This resulted in a reasonably poor first term, frustration and caused many a sleepless nights. We had to change our approach if we wanted to see the projects succeed.So we sat down with the students, and took one big leap: in person, we explained some of the internals of syslog-ng, did code reviews with them, and so on. But the best thing we did was what my colleague (and the main mentor), Viktor Tusa, came up with: we wrote a test script, that started syslog-ng, configured it, and ran tests against it. Students had to make their code pass the test by the next in-person meeting. This helped tremendously, and increased the speed they worked at by an order of magnitude at least. We kept developing the test script further, and so did the projects improve.ConclusionsThere are a couple of conclusions I arrived at as the programme concluded, things we (or other mentors, as I plan to participate as a student next year) will need to improve upon in the coming years.

• We need milestones at the time of announcing the project, not later, but by the time we put a project online, we need clear milestones.
• We need a way to help students track their own progress. We can't always be there for them, and that's OK. They need to be able to see how they're doing, though. Automated tests, whenever possible, are a great aid.
• In person meetings, with code reviews and explaining idiosyncrasies of the existing code-base are a great help to students, and also help us better understand how others would like to use our APIs, which in turn makes it easier to write APIs that are actually good.
• Lack of experience in the programming language is no big deal, experience can be gained during the programme, if the student is dedicated. We should not be afraid of involving smart, but less experienced students. As a consequence, requiring code samples may not be the best idea. That's a very high barrier to jump over. I would rather have a talk - in person, preferably - with the student, and see if they have the potential to bring the project to the finish line.
• We need to start preparing for next year soon, if we want to participate on our own. Can't wait for the last minute, starting just a month before the application period for organisations open is already too late.
• Involving the students in the project, letting them do useful work that gets merged during the programme is a huge accomplishment. Both our students expressed interest in not only participating next year too, but also continuing their work after GSoC. We need to keep this up in the coming years too!

A new version of the code behind http.debian.net was deployed a few days ago. It has proved to be far more stable, faster, and scalable compared to the previous mod_perl-based deployment.

There were a couple of glitches during the earlier roll-out for IPv6 users, fixed thanks to the reports by Cyril Brulebois, Michael Stapelberg and Robert Drake.

What's behind?
The redirector is now a plack application (with no middlewere) running under the Starman server with an apache fronted. Requests are processed faster than before and there mod_perl-induced system overload is finally gone.

The redirector is now easier to test and develop. Deploying the live instance is not yet fully streamlined, but it has seen a lot of improvement. Some important changes to the way the redirector works are already on their way to see the light and I am going to be announcing them when they do. Fork the repository and hack a few changes, contributions are welcome :)

It's probably time to move it under debian.org, and finish making it the default everywhere. It's even made its way into the installation manual.

Review: Grimspace, by Ann Aguirre

Series:	Sirantha Jax #1
Publisher:	Ace
Copyright:	March 2008
ISBN:	0-441-01599-9
Format:	Mass market
Pages:	312

Sirantha Jax is a jumper: a person with the rare genetic ability to jump spaceships through the shortcut dimension of grimspace. It's a science fiction idea with a long pedigree. It creates a separate in-group for the characters to belong to, a society with its own rules, and sets up tension with the rest of the institutions of the world. In Aguirre's version, jumpers can provide the transition but direction in grimspace has to be done by a pilot, and the jumper and the pilot develop a deep psychic bond. Jax had been jumping with her husband piloting, but on their last trip their ship crashed, killing everyone on board except her. As Grimspace opens, Jax is in a treatment facility that's much more like a prison. In theory, they're trying to figure out whether she's still able to (and safe to allow to) jump. In practice, something quite a bit more sinister is going on, a fact that the reader senses early but only learns more about after Jax is helped to escape. Scarred, deeply depressed, and nearly suicidal, she's pulled into the subversive plans of a small ship of renegades who are trying to break open the Corp monopoly on grimspace travel and their tight hold over every jumper. But she's not sure whether she trusts them, or whether she cares enough about their crusade to truly join in. Grimspace follows well-trod SF paths of special cadres of pilots and navigators, lawless corners of space with local warlords, and rebellion against smothering centralization, but its first-person protagonist and point of view have more in common with urban fantasy. It's written in first-person and, at times, nearly stream of consciousness from Jax's perspective, and Jax displays plenty of profanity, acidic commentary, and emotional angst. If her special ability were shapeshifting or magic instead of jumping spaceships, one could easily see her as the typical burned-out urban fantasy detective. I liked that. It's a fun point of view when it's written well, and it felt fresh when applied to a science fiction background instead of the more typical fantasy. That said, Grimspace has a rather rough start. Jax isn't sure what's going on at first and also isn't sure she cares, and I thought that carried over to the reader's experience. The first section of the book is rough and jagged, with staccato bursts of character introduction, world-building that doesn't quite cohere, and an extended stop on a very odd outback planet that felt to me like a repurposed stage from a western. Part of the early problem is that Jax and the reader are being intentionally kept in the dark about the real goal of this group, but part of the problem is also that none of the characters start off as very likable. That includes Jax, who is a complete mess and who is both scared and despairing to the point of being almost nihilistic. The world-building unfortunately does not carry the reader through that part of the story, and at about eighty pages in I wasn't sure I was going to like this book. It does, however, get much better. For one, Jax calms down and starts making emotional connections with the rest of the crew, and that lets her demonstrate skills as a fearless problem solver. For another, while the goal of the group of people she's fallen in with isn't exactly deep, it does make sense and it does slowly become a cause the reader (and Jax) can believe in. The frenetic pace of introduction and discovery also slows down, the cast stabilizes, and the surroundings get a bit less weird (and a bit more conventional for a science fiction novel). I didn't care for the alien baby subplot I rarely do but the rest of the story slowly pulled me in. One thing Aguirre did extremely well was surprise me. There are several points later in the book where Jax gets put in a fairly typical high-stress position and does something very atypical in reaction to it, twisting the story into a shape quite a bit unlike what I had been expecting. That made Jax feel like a true free agent, establishing her independence and her desire to control her own life, and that appealed to me. Aguirre also palms one card exceptionally well, setting up an ending that I thought was the best set of scenes in the whole book, and that had me thoroughly engrossed. One can see the bones of the urban fantasy heroine inside Jax's character, but they're fresh and interesting in an SF world, and they work better than I would have expected. There is a romance, in fitting with the urban fantasy inspiration, and it didn't quite work for me, but Aguirre also builds in a reason why it might not make sense and makes it spiky and fragile without being too cliched. By the end of the book, I was, if not entirely persuaded, at least willing to go along for the ride. And that's the best summary of Grimspace, I think. Parts of it don't make a great deal of sense, and parts of it are quite choppy. But I liked Jax once she starts getting a handle on her trauma, the other characters grew on me, and the plot surprised me in some interesting ways. It's not the smoothest or most polished SF novel I've read, but it has a lot of energy and an unusual genre mix. I think I'll stick along for the ride. Followed by Wanderlust. Rating: 7 out of 10

Quite a bit of work has gone into ctioga2 since my last post. Among the most interesting features, ctioga2 now features:

• full windows support, including proper file types associations
• fill syntax as powerful as gnuplot's
• an impulses plot style
• unclipped plot elements along with full control of the curves depth: in front of axes, behind background lines...
• control of symbol size through a Z axis

The latter feature proved actually instrumental in a research project under way in my lab (which is why I wrote it in the first place). It is demonstrated in the image above, made using this code.I've also started the gnuplot versus ctioga2 gallery I was speaking about in my last post, where I try to reproduce most of gnuplot's examples using ctioga2; it can be found here. While I don't like so much the look of the gnuplot graphs, and I try to keep the look of ctioga2's as close as possible to that look, it proved invaluable in detecting small bugs, fixing small glitches and providing inspiration for new features.In the meantime, my todo-list for ctioga2 doesn't seem to get any smaller. Let's hope I'll implement them fast enough ! Keep posted...

First day of hackweek did not really go as planned. I had to spend too much time on tasks which I did not now I will have to do in advance. I've started with releasing Weblate 1.7. As a part of that I update SUSE Studio images with Weblate. Unfortunately this turned out to be more challenging than usual as with new version the build script always failed but without any obvious error. After some time, I've realized that it just does not show whole output, so the last (and most important) lines are missing. Then it was easy to spot that the problem is in Whoosh version and it's just matter of providing newer version. After fixing the image, I could finally focus on Weblate's issue tracker and resolved few issues and questions. I've also improved some of the in application documentation and links to documentation or other resources. Meanwhile I could also setup translation hosting for monkeysign, happy translating!

Filed under: English SUSE Weblate 0 comments Flattr this!

I m using GNU Screen daily for definitely more than a decade and I became maintainer of Debian s screen package nearly exactly two years ago. Nevertheless it still happens occassionally that I discover features yet unknown to me. Recently I had one of these moments again: I looked for a specific line in the long output of a command which has run inside a Screen session. For that I entered Screen s copy mode with Ctrl-A [ and scrolled around with arrow keys and page-up and -down keys. But didn t find it. I thought, it would be cool if I can search for the string I m looking for. Intu tively I typed /, the search string and pressed enter. And it worked! It jumped to the next occurrence of that string. Of course I immediately had to check if tmux has such a feature, too. And it indeed has, but it seems to be a less sophisticated implementation:

Feature	Key-binding in GNU Screen	Key-binding in Tmux
Switch into copy/scroll mode (needed for the remainder)	Ctrl-A [	Ctrl-B [
Search for string once, forward	/ + string + Enter	Ctrl-S + string + Enter
Search for string once, backward	? + string + Enter	Ctrl-R + string + Enter
Search for string again, forward	/ Enter	Ctrl-S Enter
Search for string again, backward	? Enter	Ctrl-R Enter
Incremental search for string, forward	Ctrl-S + string	-
Incremental search for string, backward	Ctrl-R + string	-
(Incremental) search for next occurrence, forward	Ctrl-S again	-
(Incremental) search for next occurrence, backward	Ctrl-R again	-

Being able to do incremental search like with GNU Emacs gave me yet another reason for continuing to use Screen and not to switch Tmux. ;-)

not much activity around RC bugs on my side in the last weeks; & the ones I worked on were all in the Debian Perl Group:

• #722332 libcommon-sense-perl: "libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say()."
  ensure same version of perl at build and runtime (pkg-perl)
• #723917 src:libcatalyst-dispatchtype-regex-perl: "FTBFS: Module::Build version 0.4004 required--this is only version 0.4003 at Build line 41."
  fix build dependencies (pkg-perl)
• #723927 src:libdancer-plugin-auth-extensible-perl: "FTBFS: POD error"
  add patch to fix POD (pkg-perl)
• #723933 src:libemail-mime-perl: "FTBFS: test failures in t/ct_attrs.t"
  upload new upstream release (pkg-perl)
• #724109 src:libmoosex-getopt-perl: "libmoosex-getopt-perl: FTBFS: Tests failures"
  upload new upstream release (pkg-perl)
• #724111 src:libtemplate-declare-perl: "libtemplate-declare-perl: FTBFS: Tests failed"
  upload new upstream release (pkg-perl)
• #724196 src:libmldbm-sync-perl: "libmldbm-sync-perl: FTBFS: make[1]: *** No rule to make target /usr/local/lib/perl5/5.6.1/i686-linux/Config.pm', needed by Makefile'. Stop."
  re-create Makefile in clean target (pkg-perl)
• #724235 src:libio-compress-lzma-perl: "FTBFS: IO::Compress::Base version 2.061 required--this is only version 2.060"
  fix alternative dependencies (pkg-perl)
• #724303 src:libvideo-fourcc-info-perl: "libvideo-fourcc-info-perl: FTBFS: fails t/99kwalitee.t: no license information"
  don't run author tests during build (pkg-perl)
• #725393 libhttp-server-simple-psgi-perl: "libplack-perl and libhttp-server-simple-psgi-perl: error when trying to install together"
  add versioned Breaks/Replaces (pkg-perl)
• #725585 src:libhttp-request-params-perl: "libhttp-request-params-perl: FTBFS: Tests failed"
  add patch from CPAN RT (pkg-perl)

on an unrelated note: following the discussion on debian-project, I finally revoked my old opengpg key 0x00F3CFE4 which served me well from 1998 until 2009. since then, I've only been using 0x8649AA06 anyway ...

Review: Captain Vorpatril's Alliance, by Lois McMaster Bujold

Series:	Vorkosigan #14
Publisher:	Baen
Copyright:	November 2012
ISBN:	1-4516-3845-0
Format:	Kindle
Pages:	432

This is the fourteenth book in the long-running Vorkosigan series (not counting a few side works). It shifts viewpoint characters, following Ivan Vorpatril instead of either Miles or Cordelia, and could be read on its own since the necessary background is at least briefly explained. But it's probably best read in its proper context in the larger series, since otherwise many of the prior events mentioned here won't have much resonance. Ivan Vorpatril, Miles's cousin, has appeared in multiple previous books along with the rest of Miles's extended family, but he's stayed out of the center of the plot. And he clearly likes it that way. Ivan is not at all ambitious, tries to avoid politics, and just wants to live a quiet life (insofar as that's possible in the Barrayan military), sleep with a few women, and stay out of trouble. But given his relations and his job as aide-de-camp to an admiral this doesn't always work. In this book, the not working comes in the form of Byerly, ImpSec (Imperial Security, the Barrayan equivalent of the CIA), and a request to find out more about a woman who seems to be the target of a bounty. Fairly quickly, Ivan finds himself hopelessly entangled in both politics and in someone else's complex life, and is not entirely sure what to do about either. It's been months since I read this book and I'm only now writing a review, in part because I find it hard to know what to say about it. While Ivan doesn't have Miles's manic energy, the tone of this book is very similar to the rest of the Vorkosigan series, as is the plot and most of the characters. Ivan tries a more laid-back approach and doesn't actively seek danger the way that Miles does, but his persistent efforts to do the right thing in the face of unexpected events lead mostly to the same places. There's a bit of humor, a bit of danger, some galactic politics, some scheming, and a slow process of understanding other people better in short, Captain Vorpatril's Alliance is very similar to the thirteen books that proceeded it. This is obviously not a bad thing. If you've read this far in the series, more of the same is probably just fine. I enjoyed the book. Bujold is great at telling stories, the plot mostly moved right along, and I quite liked the two women Ivan meets over the course of the story. But there wasn't much about the story that grabbed me or, I suspect, that I will find particularly memorable. One reason for my somewhat "meh" reaction is that the core of this story is a romance, and while much of that romance is well-done, there is a large segment in the middle of the book where the suspense of the plot derives mostly from one of the two characters refusing to confide in the other. This is Bujold, so this isn't as much of a train wreck as it might be in the hands of another author, and it is for valid plot reasons. But even with those justifications, I never like that plot element. There were about a hundred pages where I wanted to grab Tej and shake some sense into her, which doesn't endear a character to me. And the leads in a romance, at least this sort of romance, should be endearing. I think one reason why Bujold went for that approach to building tension is that there weren't a lot of options available. The basic outlines of what's going to happen are obvious from early in the book and essentially forced by the structure of the series. We know from past books that Ivan is both trustworthy and related to a staggering variety of powerful people, almost all of whom are highly competent and honorable. It's fairly obvious that, as soon as the necessary people trust Ivan and let him and his family solve their problems, all the problems will be solved. It's also fairly obvious how the romances will play out, and that all the new characters will end up a little in awe of how competent and trustworthy all the Barrayans are (a few misdirections aside). Therefore, much of the book, for a long-time reader of the series, involves waiting until those things happen, and meanwhile getting increasingly annoyed at characters who refuse to trust obviously trustworthy people. All that said, I still quite liked the beginning of the book, because Tej and Rish are a wonderful pair and have a great interpersonal dynamic, and the very end of the book once everyone gets past the communication problems and the plot can deliver on its promises. Both together make up for some noticeable sagging in the middle section of the book. Captain Vorpatril's Alliance is not up to the standards of the most memorable books of the series, but it's a solid dose of "more of the same" and provides its money's worth of entertainment. I'm still hoping for more Ekaterin and more fireworks in the next book, though. Rating: 7 out of 10

This is a reply to Roman Cheplyaka s post Why PVP doesn't work , where he argues that Haskell packages should not per default put upper bounds on their build dependencies (as mandated by the Package Versioning Policy), at least not without good reason. I disagree, and I d like to explain why. I assume that you are packaging your libraries and programs not only for your fellow developers, but also for users. Hackage has turned not only into a hub for developers sharing their libraries, but also for users to conveniently download stuff from. And when I say users, I include xmonad users (although they write a bit of Haskell for their configuration) and beginners (who we certainly don t expect to understand and make sense of error messages that occur if some obscure crypto-related dependency of their favourite web framework fails to build). And for their benefit we should try hard to make sure cabal install either succeeds (great) or fails early with an error message that the user can understand as I could not find a package configuration of which the maintainers believe with good confidence that it works. Please talk to them. I speak with some experience, because as a maintainer of the >666 Haskell packages in Debian, I am, in a sense, a very heavy user. In the years after the PVP got commonly accepted, we could noticeably reduce the number of build failures that we encounter on our machines and the Debian build farms, simply because the meta data (which we transfer to the Debian package level) prevented such builds from being attempted. We now even have a build compatibility prediction system: We maintain a text file with all Haskell packages in Debian, together with a directory of patches (where we sometimes indeed override the packages Cabal file), and a script that runs cabal-install s dependency checker against this day. This way, when I want to upgrade a package, I can simply change the version in the file and know what packages will be broken. So I change their version until I either find a fixed-point (and only then actually upload packages to the user) or find a problem, which I then report to the maintainers or start cooking up my own patches. This works really well, but it only does because most maintainers are following the PVP. That s why I argue: Please continue to do so. (What we would probably need instead of less using the PVP is more tools in helping us with it. I could imagine a build bot that finds packages on Hackage with an upper bound on a package where a newer version exists, fetches those and automatically tries to build against the new version, and if it succeeds, sends a message to the maintainer: Your dependency on bar in foo also builds against version 0.42 of bar; please check for incompatibilities that are not expressed in the type system and upload a new version of foo allowing bar-0.42. Isn t that something the Stackage infrastructure can be used for?) (What we could probably use as well (and is probably a stepping stone towards what I just said) is a way to tell cabal-install to ignore a certain build dependency version bound. This way we still prevent normal users from trying a dependency version that the maintainer did not test, but nevertheless make it as easy as possible for the advanced user to try nevertheless, and then hopefully report about it to the maintainer. Of course, other had that idea before, someone just has to make it happen.)

I wish I had known about that quote from Michael Graves before now. I would have perhaps had an answer to some recent visitors to makespace.

There are regular scheduled visits to makespace where people can come and view our facilities, and perhaps start the process of becoming a member if they decide they like what they see.

However, we sometimes get people who just turn up at the door. If a member feels charitable they may choose to give a short tour rather than just turn the person away. I happened to be in one Friday afternoon recently varnishing a folding chair when two such people rang the doorbell. There were few other members about and because watching varnish dry was dull I decided to be helpful and do a quick tour.

I explained that they really ought to return for a scheduled event for a proper tour, gave the obligatory minimal safety briefing, and showed them the workshops and tools. During the tour it was mentioned they were attending a certain local higher education establishment and were interested in makespace as an inexpensive studio.

Before they left I was asked what I was working on. I explained that I had been creating stools and chairs from plywood. At this point the conversation took a somewhat surreal turn, one of them asked, well more demanded, who my principle influence had been in designing with plywood.

When I said that I had mainly worked from a couple of Google image searches they were aghast and became quite belligerent. They both insisted I must have done proper research and my work was obviously influenced by Charles and Ray Eames and Arne Jacobsen and surely I intended to cite my influences in my design documents.

My admission that I had never even heard the names before and had no design documents seemed to lead to a distinctly condescending tone as they explained that all modern plywood design stemmed from a small number of early 20th century designers and any competent designers research would have revealed that.

At this point in proceedings I was becoming a bit put out that my good deed of showing off the workshop had not gone unpunished. I politely explained that I designed simply by generating a requirement in my head, maybe an internet search to see what others had done, measuring real things to get dimensions and then a great deal of trial and error.

I was then abruptly informed that my "design process was completely invalid and there were well established ways to design furniture correctly and therefore my entire design was invalid" and that I was wasting time and material. I thanked them for their opinion and showed them out, safe and well before anyone gets any ideas.

I put the whole incident out of my mind until I finished writing up the final folding chair post the other day. It struck me that perhaps I had been unknowingly influenced by these designers. It was certainly true I had generated ideas from the hundreds of images my searches had revealed.

I did some research and it turns out that from the 1930s to the 1950s there were a string of designers using plywood in novel ways from the butterfly stool by Sori Yanagi through formed curvy chairs by Alvar Aalto and eero saarinen.

While these designers produced some wonderfully iconic and contemporary furniture I think that after reviewing my initial notes that two more modern designers Christian Desile and Leo Salom probably influenced me more directly. Though I did not reference their designs beyond seeing the images along with hundreds of others, certainly nothing was directly copied.

And there in lies an often repeated observation: no one creates anything without being influenced by their environment. The entire creative process of several billion ape descendants (or Golgafrincham telephone sanitisers if you prefer) is based on the simple process of copying, combining and transforming what is around us.

I must accept that certain individuals at points in history have introduced radical improvements in their field, people like Socrates Galileo Leonardo Newton Einstein. However, even these outstanding examples were enlightened enough to acknowledge those that came before. Newtons quotation "If I have seen further it is by standing on the shoulders of giants" pretty much sums it up.

In my case I am privileged enough to live in a time where my environment has grown to the size of the world thanks to the internet. My influences, and therefore what I create, is that much richer but at the same time it means that my influence on others is similarly diminished.

I have joined the maker community because I want to create. The act of creation teaches me new skills in a physical, practical way and additionally I get to exercise my mind using new techniques or sometimes things I had forgotten I already knew. I view this as an extension of my previous Open Source software work, adding a physical component to a previously purely mental pursuit.

But importantly I like that my creations might provide inspiration for someone else. To improve those chances in the wider world I force myself to follow a few basic rules:

Release

Possibly one of the hardest things for any project. I carefully avoided the word finish here because my experience leads me to the conclusion that I always want to improve my designs.

But it is important to get to a point in a project where you can say "that is good enough to share", this is more common in software but it really applies to any project.

Share

If your aim here is to improve your society with your contribution sharing your designs and information is important. I think there is nothing better than someone else taking one of your designs and using it and perhaps improving on it, remember that is what you probably did in one way or another better to make it less hard for that to happen.

Ensure your design files are appropriately licensed and they are readily accessible. I personally lean towards the more generally accessible open source licences like MIT but the decision is ultimately yours.

Licencing is important, especially in the current copyright happy society. I know it sounds dull and no one takes that seriously, right? Sorry, but yes they do and it is better for you to be clear from the start, especially if there is a software component to your project. Oh one personal plea, use an existing well known licence, the world simply does not need another one!

Write about it

The blog posts about the things I have made sometimes take almost as much time as the creation. The clear recording on my thoughts in written and photographic form often gives me more inspiration for improvements or other projects.

If someone else gets pleasure from the telling then that can only be good. If you do not do this then your voice cannot be heard and you wasted an opportunity to motivate others.

Feedback

If you do manage to get feedback on your creation, read it. You may disagree or not be interested for the current project but the feedback process is important. In software this often manifests as bug reports, in more physical projects this often becomes forum or blog comments.

Just remember that you need a thick skin for this, the most vocal members of any society are the minority with inflammatory opinion, the silent majority are by definition absent but there is still useful feedback out there.

Create again

By this I simply mean that once you are satisfied yourself on a project move on to the next. This may sound a little obvious but once you have some creative momentum it is much easier to keep going project to project than in you leave time between.

Also do not have too many projects ongoing, by all means have a couple so you do not get stuck waiting for materials or workshop time but more than three and four and you will never be able to release any of them.

Those students were perhaps somewhat misguided in how they stated their opinions, but they are correct that in the world in which we find ourselves we are all influenced. Though contrary to received wisdom those influences are more likely to be from the internet and our peers in the global maker society than historical artists.

We learn to code by actually writing code and we did it because we enjoyed it. Now it is my day job and I get to do it a lot more. The only difference being its a lot more Java now. Jaseem and I have decided to take up a pet project of ours and finish it in a week. Jaseem is writing Conway s Game of Life in Elisp and I will be implementing a single player AI powered Reversi game in Erlang. I have been learning and writing Erlang for some time now it is something I enjoy. I believe actor model is one of the best ways to express concurrency primitives and the functional way of things is beautiful in itself, but I digress. Back in college we used to write code because it was something we enjoyed. Now there is not much that I write, apart from what I do at my day job, and this is an exercise in bringing those glory days back. Now read about this in his words.

This is my monthly summary of my free software related activities. If you re among the people who made a donation to support my work (86.18 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Package Tracking System^U Distro Tracker Marko Lalic implemented quite a few interesting features in the last weeks of the Google Summer of Code (support of teams most notably). Unfortunately he didn t deploy (yet) the latest changes on pts.debian.net. Given the good work he made over the summer, I marked him as successful in his GSOC. Hopefully he will stick around and continue to contribute, he promised to try to handle some mass renaming that we agreed upon. Effectively, after much bike-shedding, I decided that the software would be called Distro Tracker . Once those last-minute cleanups are done, I plan to request tracker.debian.org to Debian System Administrators. This means that it will be deployed in parallel to the current PTS at least until we re at feature parity in the new codebase. The new codebase should be much more easy to get started with, so I should do some promotion and invite people to contribute to it possibly by writing some short how to get started documentation. I started by creating a dedicated wiki page: http://wiki.debian.org/qa.debian.org/distro-tracker
Misc packaging I got two REJECTs from ftpmasters this month (one for galette, one for dolibarr). I took care of fixing the various issues in galette and the package has been promptly accepted afterwards. For dolibarr, I mentored the upstream maintainer about the various problems and got him to fix it. It took a bit more time and the package is thus still in NEW. I packaged wordpress 3.6, and then wordpress 3.6.1 (security update). python-django also had multiple security updates this month, I took care of one or two uploads but Luke Faraone dealt with most of them (including backports to Squeeze!). I packaged Publican 3.6.1 and uploaded dh-linktree 0.4 to fix a FTBFS issue introduced with Perl 5.18. Of anecdotal importance, but I also filed bug #721849 after seeing how much energy was spent to ensure debian/rules didn t contain an improper copyright statement. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

I just received an USB headset from Plantronics. Since it has a keypad on it, with buttons to mute the microphone and to adjust the volume, it appears as both a sound card and a keyboard. Problem: that keyboard sends a mouse ButtonPress 1 (yes, a mouse button event, do not ask me how that is materially and logically possible) when the microphone is muted, and only sends the corresponding ButtonRelease 1 when it is unmuted. As a result, the pointer behaves as if the mouse button was pressed continuously, rendering the desktop quite unusable.This situation has been the object of many discussions and bug reports. All of them always suggest the same solution: making X.Org ignore the keyboard associated to the headset, with an important side effect: volume adjustment will no longer be possible using the headset buttons. Microphone muting will still be available though, since it is implemented directly in the headset. There is a better solution however: remap the mouse button 1 of that keyboard (yes, the idea that a keyboard has mouse buttons is quite funny) to disable it. To do that temporarily:

 $ # Get the identifier of the Plantronics keyboard
$ xinput --list
  Virtual core pointer            id=2  [master pointer  (3)]
      Logitech USB Optical Mouse  id=10 [slave  pointer  (2)]
  Virtual core keyboard           id=3  [master keyboard (2)]
      Power Button                id=6  [slave  keyboard (3)]
      Logitech USB Keyboard       id=8  [slave  keyboard (3)]
      Plantronics .Audio 400 DSP  id=11 [slave  keyboard (3)]
$ # Remap its mouse button 1 to 0 (disable)
$ xinput --set-button-map 11 0

And to do it permanently, create a file /etc/X11/xorg.conf.d/plantronics.conf and restart X.Org:

 Section "InputClass"
    Identifier "Plantronics"
    MatchVendor "Plantronics"
    Option "ButtonMapping" "0"
EndSection

This way, the mouse button 1 events from the headset keyboard are ignored, while all the other events it generates, that is KeyPress/KeyRelease XF86AudioLowerVolume and XF86AudioRaiseVolume, are not.

Weblate, a free web-based translation management system, of course also needs to be translated. Now it's right time to complete translation into your language before Weblate 1.7 will be released. The release is currently planned on Monday, to have clean table before hacking on Weblate during Hackweek. There is not much time left so jump in right now and start translating :-).

Filed under: English SUSE Weblate 0 comments Flattr this!

For a while I have been eyeing with the TI eZ430 Chronos watch, a slightly bulky sports watch that not only comes with a built-in thermometer, barometer and accelerometer, but also a freely programmable micro controller (from the TI MSP430 family hence the name). In addition it has a small radio chip included and can communicate wirelessly with the computer, or possibly other devices. All in all, a very geeky toy. A week ago I managed to buy one quite cheaply via eBay (30 including shipping). It took me a while to get an overview of the various resources about the device. Here is what I have learned.

• Hardware: I have the new edition (the included debug board and wireless access point are white). This means that I cannot update the software of the watch via the wireless connection, and it means that most software written for it does not support the new altimeter sensor (yet).
• Development: Debian is a very suitable development platform; the packages mspdebug and gcc-msp430 provide all I need to compile (make config && make) and upload (mspdebug rf2500 "prog ../foo.txt") new software.
• Code: Besides the original software that comes with the device (which supports the new hardware), there are two main lines of community-driven developments: OpenChronos and openchronos-ng. The former is (as the name suggests) older and maintained mostly by forks in various places. The latter is newer, its UI deviates further from the original software and seems to be slightly more active.
• Communication: Both of these have their own mailinglists (openchronos, where I did not get a reply yet, and ti-chronos-development, where my messages are still waiting for moderation). I found only one IRC channel, #openchronos on freenode, with similarly little activity.

After I found that out, I tried to hack a bit on the various software. The first issue I had (and still have) is that I cannot use the buttons of the device while it is attached to the debug board. They do work if forget to take out the battery, but supposedly that is bad for the battery. So my compile-upload-test-cycle becomes a compile-upload-detach-insert-battery-test-remove-battery-attach-cycle. I could not find out how to emulate button presses using mspdebug. Any suggestions are welcome. The other problem was the new altimeter hardware: Neither OpenChronos nor openchronos-ng support that yet. I originally planned to port the driver from the official software to a random OpenChronos fork when I read that Richard Rondu did that to openchronos-ng yet. I found the code in a month-old merge-request. I tried it, it worked, and I started to clean up the code a bit and add a variometer mode to it, e.g. displaying the current rate of climb my ultimate goal is to use this as a surprisingly cheap variometer for paragliding. After a day of hacking and quickly lifting the watch from the room floor to the room ceiling and back I believe that it works okish, although quite a few parameter can benefit from more tweaking: sample rate (currently 20Hz), length of history (currently 2s) and the linear regression method (currently simply the difference between the average of the samples of the current second with the samples of the last second). As always, patches welcome, the code is in my fork on sf.net.
Next to do would be to enable some buzzing noise depending on the rate of change; during flight I don t want to decipher a low-contract LCD screen. But it is questionable whether the buzzer is loud enough we ll see. I was also happy to hear that there are other zE430-hackers in Karlsruhe, one of them for example tries to make the alarm clock sleep-cycle-aware.