On Cancun's Success and Wikileaks The success of the international climate conference in Cancun appears to be a great (and desperately needed) leap forward in the struggle to preserve our climate. At least news sources in Germany marvel at the very much unexpected and bigger-than-hoped outcome of the final declaration. However, I keep wondering whether this could also be the first big success of Wikileak's power: what if Cablegate's timely leakage of the US and China's double-game at the Kopenhagen summit has scared their delegations so much they did not dare to repeat the backstabbing of the climate conference a second (or thrice?) time - in fear of their actions being defaced another time next year? If this was the case, one could either call this Diplomacy by Fear or Diplomacy by Transparency - I choose to pick the latter. And if it indeed turns out Wikileaks had been the prime source behind a success for our planet, nominating the organization for the Nobel Peace prize does not look so absurd to me as it did last week.

The two first interviews were dedicated to long-time Debian developers. This time I took the opposite approach, I interviewed David Kalnischkies who is not (yet) a Debian developer. But he s contributing to one of the most important software within Debian the APT package manager since 2009. You can already see him in many places in Debian sharing his APT knowledge when needed. English is not his native language and he s a bit shy, but he accepted the interview nevertheless. I would like to thank him for the efforts involved and I hope his story can inspire some people to take the leap and just start helping My questions are in bold, the rest is by David. Who are you? I am David Kalnischkies, 22 years old, living in the small town Erbach near Wiesbaden in Germany and I m studying computer science at the TU Darmstadt. Furthermore I am for more than half a decade now young group leader of my hometown. I never intended to get into this position, but it has similarities with my career in this internet-thingy here. I don t remember why, but in April 2009 I was at a stage that some simple bugs in APT annoyed me so much that I grabbed the source, and most importantly I don t know why I did it but I published my changes in Mai with #433007, a few more bugs and even a branch on launchpad. And this public branch got me into all this trouble in June: I got a mail from Mr. package managment Michael Vogt regarding this branch A few days later I joined an IRC session with him and closely after that my name appeared for the first time in a changelog entry. It s a strange but also addicting feeling to read your own name in an unfamiliar place. And even now after many IRC discussions, bugfixes and features, three Ubuntu Developer Summits and a Google Summer of Code in Debian, my name still appear in places I have never even thought about e.g. in an interview. What s your biggest achievement within Debian? I would like to answer MultiArch in APT as it was my Google Summer of Code project, but as it has (not much) use for the normal user at this point will hopefully change for wheezy I chose three smaller things in squeeze s APT that many people don t even know yet:

• MMap run out of room , the most famous error related to the APT::Cache-Limit option is gone. The DynamicMMap in APT now deserves its name
• Download and usage of multiple Translations of Descriptions
• crazy stuff like apt-cache show ^apt-.*$/experimental works

If your impression is now that I only do APT stuff: that s completely right, but that s already more than enough for me for now as the toolchain behind the short name APT contains so many tools and use cases that you always have something different. You re an active member of the APT development team. Are there plans for APT in Debian Wheezy? What features can we expect? That s very hard to answer, as the team is too small to be able to really plan something. I mean, you can have fancy plans and everything and half a second later someone arrives on the mailing list with a small question which eats days of development time just for debugging But right now the TODO list contains (in no particular order):

• MultiArch managing packages built for different architectures like i386 on amd64 to ease the usage of packages which only work on specific architectures or cross-compiling.
• rewriting the subsystem responsible for downloading files to e.g. enable tools like apt-file or debtags to reuse the infrastructure by plugging into it.
• splitting long descriptions out of the Packages file to possibly decrease the size to download on an apt-get update . Includes mostly pulling the button only to enable it by the archive masters
• backporting popular features of some frontends to enable all frontends to use them, e.g. apt-get changelog or apt-get download
• support research on resolver improvements by implementing support for a distribution independent upgrade problem format (CUDF).
• an additional single binary for users wrapping apt-get, apt-cache and co.
• getting in contact (again) with various forks like apt-rpm and derivatives like maemo or telesphoreo to join forces instead of splitting them by working on different (and possibily very old) heads of the dragon

We will see what will get real for wheezy and what is postponed, but one thing is sure: more will be done for wheezy if you help! If you could spend all your time on Debian, what would you work on? I would spend it on APT s debbugs count zero would be cool to look at! We make progress in this regard, but with the current velocity we will reach it in ten years or so. Reading more mailing lists would be interesting, as I am kind of an information junky. Maintaining a package could be interesting to share the annoyance of a maintainer with handcrafted dependencies just to notice that APT doesn t get it in the way I intended it to be. Through, to make it feel real I need to train a few new APT contributors before so they can point my mistake out, but this unfortunately doesn t depend so much on time but on victims Maybe I could even be working on getting an official status. Beside that, I would love to be able to apt-get dist-upgrade the increasing mass of systems I and many others carry around in their pockets. In regards to my phone, this is already fixed, but there is much room for improvements. What s the biggest problem of Debian? You need to be lucky. You need to talk at the right time to the right person. That s not really a debian-only problem as such, but in a global project full of volunteers you can see it clearly as there are plenty of opportunities to be unlucky. For example, it s unlikely that an interview would be made with me now if Michael had not contacted me in June 2009. In a big project like Debian, you are basically completely lost without a mentor guiding you, so things like the debian-mentors list are good projects, but I am pretty certain they could benefit from some more helping hands. The other thing which I consider a problem is that and I read from time to time some people don t care for translations. That s bad. Yes, a developer is able to read English, otherwise s/he couldn t write code or participate on the mailinglists. Still, I personally prefer to use a translated application if I have the chance as it s simply easier for me to read in my mother tongue, not only because I am dyslexic, but because my mind still thinks in German and not in English. Yes, I could personally fix that by thinking in English only from now on, but its a quite big problem to convince my family which is not really familiar with tech-stuff to use something if they can t understand what is written on screen. It was hard enough to tell my mother how to write an SMS in a German interface. My phone with English words all over the place would be completely unusable for her despite the fact that my phone is powered by Debian and better for the task from a technical point of view. You are not yet an official Debian developer/maintainer, but you re already perceived in the community as one the most knowledgeable person about APT. It s a great start! What s your advice to other people who want to start contributing to Debian in general, and to APT in particular? It was never a goal in my life to start contributing . My goal was and still is to make my life easier by letting the computer work for me. At some point APT hindered the success of this goal, so it needed to be fixed. I didn t expect to open pandora s box. So, my advice is simple: Just start. Ignore the warning signs telling you that this is not easy. They are just telling you that you do something useful. Only artificial problems are easy. Further more, contribution to APT, dpkg or any other existing package is in no way harder than opening an ITP and working on your own, and it s cooler as you have a similar minded team around you to talk to. APT didn t accept release codenames as target release was one of the first things I fixed. If I had asked someone if that would be a good starting point the answer would have been a clear no , but I didn t search for a good starting point As a kid I can start playing football by just walking on the field and play or I can sit near the field, watching the others play, while analyzing which position would be the best for me to start ruling out one by one as the technical requirements seem too high Oh bicycle kick that sounds complicated I can t do that Julian Andreas Klode is working on a APT replacement, there s also Cupt by Eugene V. Lyubimkin. Both projects started because their authors are not satisfied with APT, they find APT s code difficult to hack partly due to the usage of C++. Do you share their concerns and what s your opinion on those projects? I don t think C++ is a concern in this regard, after all cupt is currently rewritten to C++0x and APT2 started in vala and is now C + glib last time I checked at least. I personally think that something is wrong if we need to advertise an application by saying in which language it is written The major problem for APT is probably that the code is old : APT does its job for more than 12 years now, under different maintainers with an always changing environment around it: so there are lines in APT which date from a time when nobody knew what a Breaks dependency is, that packages can have long descriptions which can be translated or even that package archives can be signed with a gpg key! And yet we take all those for granted today. APT has proven to adapt to these changes in the environment and became in this process very popular. So I don t think the point is near (if it will come at all) that APT can go into retirement as it is completely replaced by something else. The competitors one the other hand have their first 12 years still to go. And it will be interesting to see how they will evolve and what will be the state of the art in 2022 But you asked what I think about the competitors: I prefer the revolution from inside simply because I can see effects faster as more users will profit from it now. Cupt and co. obviously prefer the normal revolution. The goal is the same, creating the best package manager tool, but the chosen way to the goal is different. aptitude and cupt have an interactive resolver for example: that s something I dislike personally, for others that is the ultimate killer feature. cupt reading the same preference file as APT will have a different pinning result, which we should consider each time someone mentions the word drop-in replacement . APT2 isn t much more than the name which I completely dislike currently from a user point of view, so I can t really comment on that. All of them make me sad as each line invested in boilerplate code like configuration file parsing would be in my eyes better be spent in a bugfix or new feature instead, but I am not here to tell anyone what they should do in their free time But frankly, I don t see them really as competitors: I use the tools I use, if other do that too that s good, if not that s their problem. The thing that annoys me really are claims like plan is to remove APT by 2014 as this generates a vi vs. emacs like atmosphere we don t need. If some people really think emacs is a good editor who cares? I really hope we all can drink a beer in 2022 in Milliways, the restaurant at the end of the package universe, remembering the good old 2010 Is there someone in Debian that you admire for his contributions? No, not one, many! Michael Vogt who has nearly the monopole of package manager maintainer by being upstream of APT, synaptics and software center to name only the biggest and still has the time to answer even the dumbest of my questions. Jason Gunthorpe for being one of the initial developers behind deity who I will probably never meet in person beside in old comments and commit logs. Christian Perrier for caring so much about translations. Obey Arthur Liu as a great admin for Debian s participation in Google s Summer of Code. Paul Wise for doing countless reviews on debian-mentors which are a good source of information not only for the maintainer of the package under review. I guess I need to stop here because you asked for just one. So let s end with some big words instead: I am just a little cog in the big debian wheel

---

Thank you to David Kalnischkies for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

As I mentioned recently, the Ubuntu Technical Board is reviewing the most popular topics in Ubuntu Brainstorm and coordinating official responses on behalf of the project. This means that the most popular topics on Ubuntu Brainstorm receive expert answers from the people working in these areas. This is the first batch, and we plan to repeat this process each quarter. We ll use feedback and experiences from this run to improve it for next time, so let us know what you think. Power management (idea #24782) Laptops are now outselling desktops globally, and laptop owners want to get the most out of their expensive and heavy batteries. So it s no surprise that people are wondering about improved power management in Ubuntu. This is a complex topic which spans the Linux software stack, and certainly isn t an issue which will be solved in the foreseeable future, but we see a lot of good work being done in this area. To tell us about it, Amit Kucheria, Ubuntu kernel developer and leader of the Linaro working group on Power Management, contributed a great writeup on this topic, with technical analysis, tips and recommendations, and a look at what s coming next.

I am going to attempt to summarize the various use profiles and what Ubuntu does (or can do) to prolong battery life in those profiles. Power management, when done right, should not require the user to make several (difficult) choices. It should just work providing a good balance of performance and battery life.

IP address conflicts (idea #25648) IP addressing is a subject that most people should never have to think about. When something isn t working, and two computers end up with the same IP address, it can be hard to tell what s wrong. I was personally surprised to find this one near the top of the list on Ubuntu Brainstorm, since it seems unlikely to be a very common problem. Nonetheless, it was voted up, and we re listening. There is a tool called ipwatchd which is already available in the package repository, and was created specifically to address this problem. This seems like a further indication that this problem may be more widespread than I might assume. The idea has already been marked as implemented in Brainstorm based on the existence of this package, but that doesn t help people who have never heard of ipwatchd, much less found and installed it. What do you think? Have you ever run into this problem? Would it have helped you if your computer had told you what was wrong, or would it have only confused you further? Is it worth considering this for inclusion in the default install? Post your comments in Brainstorm. Selecting the only available username to login (idea #6974) Although Linux is designed as a multi-user operating system, most Ubuntu systems are only used by one person. In that light, it seems a bit redundant to ask the user to identify themselves every time they login, by clicking on their username. Why not just preselect it? Indeed, this would be relatively simple to implement, but the real question is whether it is the right choice for users. Martin Pitt of the Ubuntu Desktop Team notes that consistency is an important factor in ease of use, and asks for further feedback.

So in summary, we favored consistency and predictablility over the extra effort to press Enter once. This hasn t been a very strong opinion or decision, though, and the desktop team would be happy to revise it.

Icon for .deb packages (idea #25197) Building on the invaluable efforts of Debian developers, we work hard to make sure that people can get all of the software they need from Ubuntu repositories through Software Center and APT, where they are authenticated and secure. However, in practice, it is occasionally necessary for users to work with .deb files directly. Brainstorm idea 25197 suggests that the icon used to represent .deb packages in the file manager is not ideal, and can be confusing. Matthew Paul Thomas of the Canonical Design Team responds with encouragement for deb-thumbnailer, which makes the icon both more distinctive and more informative. He has opened bug 685851 to track progress on getting it packaged and into the main repository.

I have reviewed the proposed solutions with Michael Vogt, our packaging expert. Solution #1 is straightforward, but we particularly like solutions #5 and #10, using a thumbnailer to show the application icon from inside each package.

Keeping the time accurate over the Internet by default (idea #25301) It s important for an Internet connected computer to know the correct time of day, which is why Ubuntu has included automatic Internet time synchronization with NTP since the very first release (4.10 warty ). So some of us were a little surprised to see this as one of the most popular ideas on Ubuntu Brainstorm. Colin Watson of the Ubuntu Technical Board investigated and discovered a case where this wasn t working correctly. It s now fixed for Ubuntu 11.04, and Colin has sent the patches upstream to Debian and GNOME.

My first reaction was hey, that s odd I thought we already did that? . We install the ntpdate package by default (although it s deprecated upstream in favour of other tools, but that shouldn t be important here). ntpdate is run from /etc/network/if-up.d/ntpdate, in other words every time you connect to a network, which should be acceptably frequent for most people, so it really ought to Just Work by default. But this is one of the top ten problems where users have gone to the trouble of proposing solutions on Brainstorm, so it couldn t be that simple. What was going on?

More detail in GNOME system monitor (idea #25887) Under System, Preferences, System Monitor, you can find a tool to peek under the hood at the Linux processes which power every Ubuntu system. Power users, hungry for more detail on their systems inner workings, voted to suggest that more detail be made available through this interface. Robert Ancell of the Ubuntu Desktop Team answered their call by offering to mentor a volunteer to develop a patch, and someone has already stepped up with a first draft. Help the user understand when closing a window does not close the app (idea #25801) When the user clicks the close button, most applications obediently exit. A few, though, will just hide, and continue running, because they assume that s what the user actually wants, and it can be hard to tell which has happened. Ivanka Majic, Creative Strategy Lead at Canonical, shares her perspective on this issue, with a pointer to work in progress to resolve it.

This is more than a good idea, it s an important gap in the usability of most of the desktop operating systems in widespread use today.

Ubuntu Software Centre Removal of Configuration Files (idea #24963) One feature of the Debian packaging system used in Ubuntu is that it draws a distinction between removing a package and purging it. Purging should remove all traces of the package, such that installing and then immediately purging a package should return the system to the same state. Removing will leave certain files behind, including system configuration files and sometimes runtime data. This subtle distinction is useful to system administrators, but only serves to confuse most end users, so it s not exposed by Software Center: it just defaults to removing packages. This proposal in Ubuntu Brainstorm suggests that Software Center should purge packages by default instead. Michael Vogt of the Ubuntu Foundations Team explains the reasoning behind this default, and offers an alternative suggestion based on his experience with the package management system.

This is not a easy problem and we need to carefully balance the needs to keep the UI simple with the needs to keep the system from accumulating cruft.

Ubuntu One file sync progress (idea #25417) Ubuntu One file synchronization works behind the scenes, uploading and downloading as needed to replicate your data to multiple computers. It does most of its work silently, and it can be hard to tell what it is doing or when it will be finished. John Lenton, engineering manager for the Ubuntu One Desktop+ team, posts on the AskUbuntu Q&A site with tools and tips which work today, and their plans to address this issue comprehensively in the future. Multimedia performance (idea #24878) With a cornucopia of multimedia content available online today, it s important that users be able to access it quickly and easily. Poor performance in the audio, video and graphics subsystems can spoil the experience, if resource-hungry multimedia applications can t keep up with the flow of data. Allison Randal, Ubuntu Technical Architect, answers with an analysis of the problem and the proposed solutions, an overview of current activity in this area, and pointers for getting involved.

The fundamental concern is a classic one for large systems: changes in one part of the system affect the performance of another part of the system. It s modestly difficult to measure the performance effects of local changes, but exponentially more difficult to measure the network effects of changes across the system.

I'm using GTK+ in my paid work, which is being cool because I like this library. It's not the first time I use it for paid work, and I like these opportunities to learn more about it and possibly report bugs. It's not easy to find bugs in such a widely used library, so much of them end up being simple cosmetic mistakes, like this one. Some others are only a question of interpretation, like this other, which even when I submitted a patch, it was not applied. Yesterday I couldn't make popup-menu create a, well, popup menu. It was working with button-press-event, but not with popup-menu. I created a small code sample to illustrate this problem and asked about it in #pygtk@irc.gimp.org --- yes, I'm using Python:

import gtk
import gobject
def menu():
  item = gtk.ImageMenuItem('gtk-add')
  item.show()
  menu = gtk.Menu()
  menu.add(item)
  return menu
def on_view_popup_menu(obj, *data):
  print 'popup-menu'
  menu().popup(None, None, None, 0, 0)
def on_view_button_press_event(obj, *data):
  print 'button-press-event'
  menu().popup(None, None, None, 0, 0)
store = gtk.ListStore(gobject.TYPE_STRING)
store.append(('teste',))
view = gtk.TreeView(store)
view.append_column(gtk.TreeViewColumn('Coluna', gtk.CellRendererText(), text=0))
view.connect('button-press-event', on_view_button_press_event)
view.connect('popup-menu', on_view_popup_menu)
view.show()
window = gtk.Window()
window.add(view)
window.show()
gtk.main()

When I clicked in the window, with any button in this case, 'button-press-event' is printed to stdout and the menu is displayed. When I press the Menu key, or Shift+F10, 'popup-menu' is printed to stdout, but the menu is not displayed. After getting no response in #pygtk, I decided to try #gtk+. Before that, I thought about trying the same problem in C to see if it was not a problem in the bindings, or in how I was using it. The code:

#include <gtk/gtk.h>
GtkMenu *menu()  
  GtkImageMenuItem *image_menu_item =
      GTK_IMAGE_MENU_ITEM(
          gtk_image_menu_item_new_from_stock(GTK_STOCK_ADD, NULL));
  gtk_widget_show(GTK_WIDGET(image_menu_item));
  GtkMenu *menu = GTK_MENU(gtk_menu_new());
  gtk_container_add(GTK_CONTAINER(menu), GTK_WIDGET(image_menu_item));
  return menu;
 
void on_tree_view_popup_menu(GtkWidget *widget, gpointer user_data)  
  printf("popup-menu\n");
  gtk_menu_popup(
      menu(), NULL, NULL, NULL, NULL, 0, gdk_event_get_time(NULL));
 
void
on_tree_view_button_press_event(
  GtkWidget *widget, GdkEventButton *event, gpointer user_data)  
  printf("button-press-event\n");
  gtk_menu_popup(
      menu(), NULL, NULL, NULL, NULL, 0, gdk_event_get_time(NULL));
 
int main(int argc, char **argv)  
  gtk_init(&argc, &argv);
  GtkListStore *list_store = gtk_list_store_new(1, G_TYPE_STRING);
  GtkTreeIter iter;
  gtk_list_store_append(list_store, &iter);
  gtk_list_store_set(list_store, &iter, 0, "teste", -1);
  GtkTreeView *tree_view =
      GTK_TREE_VIEW(
          gtk_tree_view_new_with_model(GTK_TREE_MODEL(list_store)));
  gtk_tree_view_append_column(
      tree_view,
      gtk_tree_view_column_new_with_attributes(
          "Coluna", gtk_cell_renderer_text_new(), "text", 0, NULL));
  g_signal_connect(
      tree_view, "popup-menu", G_CALLBACK(on_tree_view_popup_menu), NULL);
  g_signal_connect(
      tree_view,
      "button-press-event",
      G_CALLBACK(on_tree_view_button_press_event),
      NULL);
  gtk_widget_show(GTK_WIDGET(tree_view));
  GtkWindow *window = GTK_WINDOW(gtk_window_new(GTK_WINDOW_TOPLEVEL));
  gtk_container_add(GTK_CONTAINER(window), GTK_WIDGET(tree_view));
  gtk_widget_show(GTK_WIDGET(window));
  gtk_main();
 

Wow. The difference between the codes is impressive. I'm not that used to code in GTK+ using C, and I may have missed something here, but the C code is so verbose that I get tired only by looking at it. I'm glad we have other languages, and GTK+ bindings for them. As expected, the behavior was the same, and I asked in #gtk+ and got no answer. Yes, I did read the documentation before asking, and no, I didn't read it carefully enough. Maybe because of coming from Python, I didn't checked very much the type of the callback function for the signals, and didn't notice the point about the return value: "Returns: TRUE if a menu was activated". And that was not where I was looking for the problem, since I thought the return value was usually related to the treatment of the signal by another functions. Anyway, I changed the type of on_tree_view_popup_menu to return gboolean and returned TRUE. It works! I also updated the type of on_tree_view_button_press_event to do the same, just for compliance. In Python, a simple return True would do it. I know I could use the event parameter in on_tree_view_button_press_event, but the point was exactly to run the same code and see if it would work in one case and not in the other, as happened.

I disagree with Lars. Respect needs to be earned. It should not be a default, and it should not be demanded either on one's own behalf or for others, or you are conflating it with something incredibly ignoble. When you do not respect someone, and you show that person respect, you are being deceitful. Of this I disapprove.

Argh. So of course there's a difference between CONFIG_USB_SERIAL=y and CONFIG_USB_SERIAL=m, and that would explain the behavior I'm seeing. Thanks Ben Hutchings. I guess I'm recompiling my kernel again. Kill me now.

Seriously, the amount of yak shaving I'm doing these days... So I discover this CONFIG_USB_SERIAL_CONSOLE config option. I proceed to edit my .config, throw it in there and rebuild my kernel. (For the record, I hate building kernels). I'm about to reboot into said new kernel, and I thought I'd just double check the resulting config-2.3.36 file to check that CONFIG_USB_SERIAL_SERIAL did indeed get enabled. It's not there. I spend a few minutes WTFing, and assume I've been an idiot and should have run a make oldconfig or some such thing after hand-editing my .config file. So I try that. The additional line vanishes again afterwards. More WTFing ensues. I fire up make menuconfig, and go looking for the menu entry for the option. It's not there. The plot thickens. I hand-edit drivers/usb/serial/Kconfig and change depends on USB_SERIAL=y to just depends on USB_SERIAL, and rerun make menuconfig, and lo and behold, the option appears! So now I'm off rebuilding the kernel again. Sigh.

As a first step on the road to evaluating different configuration management systems, I set up two VMs to test out puppet. Puppet is conveniently packaged within Debian so client and server installation was very simple. By default, puppet clients will look for a host named puppet on the local network, so by naming the server sensibly the two started talking to each other. puppetca --sign [client hostname] on the server started the ball rolling. My first test configuration was to add a user to the sudoers file. With CF Engine 2, I would have achieved this by using editfiles to check for a regular expression and insert a line if necessary. I stumbled across some CF Engine-style definitions for puppet in a Debian Administration article (taken originally from puppet's own wiki, which have since been moved/deleted) and achieved it using

append_if_no_such_line   sudo:
  file => "/etc/sudoers",
  line => "jon ALL=(ALL) ALL"
 

I'm a little concerned that this approach to problem solving is no better than CF Engine 2, and in fact worse than how I'd do it with CF Engine 2: if the host had a line with a different quantity of whitespace, such as jon ALL=(ALL) ALL, it won't match exactly and a duplicate line will be appended, whereas with CF Engine 2 I would have checked for something like ^jon \+ALL=(ALL) \+ALL$. I set up my work laptop as another test node, and used puppet to install some packages that I commonly use:

class jon-desktop  
  package   ['icedove', 'git-core', 'vim-gnome', 'vinagre', 'build-essential',
             'devscripts', 'subversion', 'git-buildpackage', 'mutt',
             'offlineimap', 'ascii', 'gitk', 'chromium-browser'
            ]: ensure => installed  
 

This worked fine, but is a little verbose and the package list is awkward to maintain buried inside the puppet syntax. I spent some time trying to see whether I could populate a puppet list based on the contents of a file: then I could list the packages one-per-line in a separate file. I haven't found a way of doing that yet. Using my laptop as a second node also exposed some interesting puppet client behaviour. Once I went off-site, the laptop tried to look up puppet on foreign networks (such as my home network). I would have assumed that, once the strong SSL association had been made, the client would try to connect to the FQDN of the server. This probably isn't a serious problem in practice, as we probably won't need to rely on nodes off-site talking to the configuration server, but I hope that the client doesn't trust any host that happens to answer to puppet... I fixed this by hacking my hosts file to include an entry for puppet. I could maintain this hack using Puppet itself, which would protect me against stale definitions if any renumbering takes place. I could also have added a line

server = puppet.fqdn.example.org

in /etc/puppet/puppet.conf, which is a more robust way of solving the problem.

Guillermo Garron of Go2Linux enjoys a lot the People behind Debian interviews that I make. That s why he interviewed me (with somewhat similar questions) and published the result on his blog. Click here to read the full interview. I speak of my Debian projects, of the Ubuntu-Debian relationship, and more. The question that I would like to highlight is What s the biggest problem of Debian? . I answered this:

Our project identity is somewhat minimalistic. It evolves around the social contract and the Debian Free Software Guidelines. Both documents answer the question of what we re doing but we lack a clear answer to the question of how we re supposed to work towards our goals. It would be great if Debian could agree on some principles concerning topics like goal setting, collaboration, team work, politeness, respect. We could then advertise those and build on them while recruiting volunteers.

PS: The interview also hit LinuxToday.

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

A continuation of my intermittent series on Emdebian. This time covering how Emdebian changes component behaviourin Emdebian Grip.
Debian divides packages principally between those which comply with the DFSG (main), those which do not (non-free) and those which could but depend on those which do not (contrib). This leads to an enormous bias towards packages in main, which is good in terms of DFSG compliance but not so good for the size of the Packages files which every machine has to download to be able to install new stuff or upgrade existing stuff.
Emdebian is as concerned about the runtime space requirements of the system as much as the install time space requirements. Little point gaining 20Mb by removing stuff from packages if the next apt-get update adds 30Mb of cache data.
Therefore, Emdebian Grip sub-divides main (we don't have contrib or non-free packages at this time). This gives most users the smallest cache data size whilst allowing other users to add the extra components and get the full list of packages provided in Emdebian.
Alongside this division, the aim with emdebian-grip-server is to help others run secondary Emdebian Grip build machines which have a different range of packages. This allows one server to focus on XFCE and one to use other desktops or no desktops.
Components in Grip
Grip subdivides Debian main into main (~60%), dev (~30%), java, debug and doc components. The main emphasis, therefore, is that most Emdebian Grip machines will not be used to actually build other packages. I covered some of the theory on this step on the debian-embedded mailing list in 2009.
Component allocation
Packages are allocated to particular components by three main mechanisms:

1. Package name suffix - -dev packages into dev, -dbg packages into debug, -doc packages into doc.
2. Section names - devel goes into dev, java goes into java
3. Override files which are visible via the emdebian website.

Override files cover situations where a package is in a problematic Section (e.g. dbus is in Section: devel when it is almost impossible to have a netbook or graphical Debian installation without it). Once Squeeze is released, I might take up these overrides with ftpmaster to see if some rationale can be constructed to make things easier.
Sources
The use of components means that an Emdebian Grip device can choose a range of components in the apt sources line. Any permutation as long as main is preserved.

deb http://www.emdebian.org/grip squeeze main dev debug java doc

More on Filtering
I mentioned last time that Emdebian does not carry all packages available in Debian. As well as filtering the files contained within packages, Emdebian Grip filters the list of packages which are allowed into the repository for each server. This is why Emdebian Grip has under 3,000 packages to be released alongside Squeeze. (Emdebian Grip 1.0 based on Lenny had some 1,000 packages.)
Filtering the list of packages means that the maintainer of the server gets to choose their package set in a similar way to how tasksel can be used to select a functionally complete set of packages at installation time. (Indeed, Emdebian Grip provides some bespoke tasks which optimise the combination of tasksel and repository filtering.) Processing packages for Emdebian Grip takes a finite amount of time per package, per architecture and restricting the total number of packages in Grip has several advantages:

1. Further reductions in cache size - less files in the Packages file, less Packages data to download and cache.
2. Less processing time which makes it easier to maintain an Emdebian Grip server
3. Less data to mirror which makes it attractive for admins already running a full Debian mirror to consider squeezing in Emdebian Grip alongside.

Combining component changes and filters needs a little bit of careful handling in the server side code so that packages remain installable. Override files need to be adjusted manually, library transitions mean that once libfoo0 has been replaced by libfoo1, anything depending on libfoo1 is broken in Emdebian Grip until libfoo1 can be added to the repository (which is also a manual task). I'm glad that edos-debcheck is regaining a machine-parseable output format because this will add the chance to make at least some of these transition additions automatic. Other than these tasks, emdebian-grip-server is almost entirely automated and runs as a cron task creating verbose log files each run.
The server task runs edos-debcheck for each supported architecture and for each suite, carefully combining the various Packages files from the available components. As an alternative assessment, Debian Weather runs edos-debcheck over the Packages file for the main component only, for each suite and each architecture in Emdebian Grip. The combination of the two provides invaluable data to spot missing packages.
Equally, there are times when packages disappear from Debian. Currently, the automated scripts don't handle this aggressively but manual support scripts are available, usually for use before a release when the suites are changing less frequently.
I'll cover migrations between suites next time. In the meantime, if you want to prepare your own package set for Emdebian Grip, install emdebian-grip-server from experimental and file bugs to improve the documentation.
Thanks to those who took on the Herculean task of translating the emdebian-grip-server manpages into German and French - more translations are always welcome. POT file contained inside the source package.

This is the second post about distcheck. I want to give a quick overview of the differences between edos-distcheck and the new version. First despite using the same sat solver and encoding of the problem, Distcheck has been re-written from scratch. Dose2 has several architectural problems and not very well documented. Adding new features had become too difficult and error-prone, so this was a natural choice (at least for me). Hopefully Dose3 will survive the Mancoosi project and provide a base for dependency reasoning. The framework is well documented and the architecture pretty modular. It's is written in ocaml, so sadly, I don't expect many people to join the development team, but we'll be very open to it. These are the main differences with edos-debcheck .

Performances distcheck is about two times faster than edos-debcheck (from dose2), but it is a "bit" slower then debcheck (say the original debcheck), that is the tool wrote by Jerome Vouillon and that was then superseded in debian by edos-debcheck. The original debcheck was a all-in-one tool that did the parsing, encoding and solving without converting the problem to any intermediate format. distcheck trades a bit of speed for generality. Since it is based on Cudf, it can handle different formats and can be easily adapted in a range of situation just by changing the encoding of the original problem to cudf. Below there are a couple of test I've performed on my machine (debian unstable). The numbers speak alone.

$time cat tmp/squeeze.packages edos-debcheck -failures > /dev/null
Completing conflicts... * 100.0%
Conflicts and dependencies... * 100.0%
Solving * 100.0%

real 0m19.515s
user 0m19.193s
sys 0m0.276s

$time ./distcheck.native -f deb://tmp/squeeze.packages > /dev/null

real 0m10.859s
user 0m10.669s
sys 0m0.172s

Input The second big difference is about different input format. In fact, at the moment, we have two different tools in debian, one edos-debcheck and the other edos-rpmcheck. Despite using the same underlying library these two tools have different code bases. distcheck basically is a multiplexer that convert different inputs to a common format and then uses it (agnostically) to solve the installation problem. It can be called in different ways (via symlinks) to behave similarly to its predecessors. At the moment we are able to handle 5 different formats

1. deb:// Packages 822 format for debian based distributions
2. hdlist:// a binary format used by rpm based distribution
3. synth:// a simplified format to describe rpm based package repositories
4. eclipse:// a 822 based format that encoded OSGi plugings metadata
5. cudf:// the native cudf format

distcheck handles gz and bz2 compressed file transparently . However if you care about performances, you should decompress your input file first and the parse it with distcheck and it often takes more time to decompress the file on the fly that run the installability test itself. There is also an experimental database backend that is not compiled by default at them moment.

Output Regarding the output, I've already explained the main differences in an old post. As a quick reminder, the old edos-debcheck had two output options. The first is a human readable - unstructured output - that was a handy source of information when running the tool interactively. The second was a xml based format (without a dtd or a schema, I believe) that was used for batch processing. distcheck has only one output type in the YAML format that aims to be human and machine readable. Hopefully this will cater for both needs. Moreover, just recently I've added the output of distcheck a summary of who is breaking what. The output of edos-debcheck was basically a map of packages to the reasons of the breakage. In addition to this information distcheck gives also a maps between reason (a missing dependency or a conflict) to the list of packages that are broken by this problem.This additional info is off by default, but I think it can be nice to know what is the missing dependency that is responsible for the majority of problems in a distribution... For example, calling distcheck with --summary :

$./distcheck.native --summary deb://tests/sid.packages
backgroud-packages: 29589
foreground-packages: 29589
broken-packages: 143
missing-packages: 138
conflict-packages: 5
unique-missing-packages: 52
unique-conflict-packages: 5
summary:
-
missing:
missingdep: libevas-svn-05-engines-x (>= 0.9.9.063)
packages:
-
package: enna-dbg
version: 0.4.0-4
architecture: amd64
source: enna (= 0.4.0-4)
-
package: enna
version: 0.4.0-4
architecture: amd64
source: enna (= 0.4.0-4)
-
missing:
missingdep: libopenscenegraph56 (>= 2.8.1)
packages:
-
package: libosgal1
version: 0.6.1-2+b3
architecture: amd64
source: osgal (= 0.6.1-2)
-
package: libosgal-dev
version: 0.6.1-2+b3
architecture: amd64
source: osgal (= 0.6.1-2)

Below I give a small example of the edos-debcheck output compared to the new yaml based output.

$cat tests/sid.packages edos-debcheck -failures -explain
Completing conflicts... * 100.0%
Conflicts and dependencies... * 100.0%
Solving * 100.0%
zope-zms (= 1:2.11.1-03-1): FAILED
zope-zms (= 1:2.11.1-03-1) depends on missing:
- zope2.10
- zope2.9
zope-tinytableplus (= 0.9-19): FAILED
zope-tinytableplus (= 0.9-19) depends on missing:
- zope2.11
- zope2.10
- zope2.9
...

And an extract from the distcheck output (the order is different. I cut and pasted parts of the output here...)

$./distcheck.native -f -e deb://tests/sid.packages
report:
-
package: zope-zms
version: 1:2.11.1-03-1
architecture: all
source: zope-zms (= 1:2.11.1-03-1)
status: broken
reasons:
-
missing:
pkg:
package: zope-zms
version: 1:2.11.1-03-1
architecture: all
missingdep: zope2.9 zope2.10
-
package: zope-tinytableplus
version: 0.9-19
architecture: all
source: zope-tinytableplus (= 0.9-19)
status: broken
reasons:
-
missing:
pkg:
package: zope-tinytableplus
version: 0.9-19
architecture: all
missingdep: zope2.9 zope2.10 zope2.11
...

Future The roadmap to release version 1.0 of distcheck is as follows:

1. add background and foreground package selection. This feature will allow the use to specify a larger universe (background packages), but check only a subset of this universe (foreground packages). This should allow users to select packages using grep-dctrl and then pipe them to discheck . At the moment we can select individual packages on the command line or we can use expression like bash (<= 2.7) to check all version of bash in the universe with version greater than 2.7.
2. code cleanup and a bit of refactoring between distcheck and buildcheck (that is a frontend for distcheck that allow us to report broken build dependencies)
3. consider essential packages while performing the installation test. Here there are few things we have to understand, but the idea would be to detect possible problems related the implicit presence of essential packages in the distribution. At the moment, distcheck performs the installation test in the empty universe, while ideally, the universe should contain all essential packages.
4. finish the documentation. The effort in underway and we hope to finalize shortly to release the debian package in experimental.

If you want to provide a wiki but want to leave the authentication to one or more external identity providers, like an identity federation, Dokuwiki and simpleSAMLphp are a good combination. However, the existing documentation is lagging behind on developments in these software packages (i.e. doesn't work anymore), so here's what worked for me. Ingredients:

A Debian 5.0 Lenny system.

Dokuwiki Debian Lenny package (0.0.20080505-4+lenny1).

simpleSAMLphp Debian squeeze package (1.6.2-1).

SSP is not available in Lenny yet but the package from Squeeze installs cleanly on Lenny.

simpleSAMLdokuwiki integration package.

Note that I'm linking to a bug report - you need the file version included in the bottom of that bug report, because the released versions are outdated.

I assume you have read the Dokuwiki and simpleSAMLphp documentation for information on how to install and configure either one; this article purely focuses on the integration part; not on e.g. how to connect an IdP to simpleSAMLphp.

• Install the Debian packages and make sure they work; dokuwiki is accessible and simpleSAMLphp is accessible and configured for your IdP. The simpleSAMLphp website is a good resource for this.
• Put the simplesamlphp.auth.class downloaded from the bug report somewhere on the system, e.g. /opt/simplesamldokuwiki
• Enable the authentication class:

  cd /usr/share/dokuwiki/inc/auth && ln -s /opt/simplesamldokuwiki/simplesamlphp.auth.class

• Add the following to /etc/dokuwiki/local.php (tune attribute names, add more Dokuwiki settings as desired of course):

  $conf['authtype'] = 'simplesamlphp';
  $conf['simplesamlphp_path'] = '/usr/share/simplesamlphp';
  $conf['simplesamlphp_attr_user']     = 'urn:mace:dir:attribute-def:eduPersonPrincipalName';
  $conf['simplesamlphp_attr_name']     = 'urn:mace:dir:attribute-def:cn';
  $conf['simplesamlphp_attr_mail']     = 'urn:mace:dir:attribute-def:mail';
  $conf['simplesamlphp_attr_grps']     = 'groups';
  

• In /etc/simplesamlphp/config.php, set the following so they can share a cookie:

          'session.phpsession.cookiename'  => 'DokuWiki'
  

I also provided a patch to the simplesamldokuwiki class cited above to enable the IdP to not pass a 'mail' attribute: see bug report.

We ve come a long way since the times when you needed to configure 2 X servers in XDM just to be able to use 2 X sessions at once. However there was still some way to go until recently. A number of bugs that could be wrongly attributed to bugs in the X server or in the desktop environment were actually caused by the display manager doing crap. GDM up to 2.20 Since the introduction of the flexible X servers feature, GDM hadn t evolved much on the matter of user switching. What it used to do was pretty straightforward:

• a specific protocol can be invoked by the gdmflexiserver command;
• the gdm daemon spawns a new X server on an empty console;
• it initiates another login process in it;
• when the session exits, or if the user clicks on Quit instead of logging in, the X server exits.

It is interesting to note that VT (console) switching is purely handled by the X server. When starting, the new server switches the current VT to where it is. When exiting, it automatically switches back to the VT from which it was launched. While very simple, this idea fails to work correctly every time you try to do something more complicated than starting a temporary session for a guest and exiting it. For example, if you start two of them, there is a chance that, when the X server switches back to the console it was run from, there is nothing left running in this console, leaving you with the funny Control-Alt-Fn shortcuts to find your way back to a X server. You will also meet interesting race conditions when trying to switch back to an existing session from the login window. GDM 2.28 and above In the process of rewriting the code entirely, the GDM developers tried to address a number of those shortcomings, making use of D-Bus and ConsoleKit. The new design is slightly more complicated, however.

• The gdmflexiserver tool will first try to look for an existing login window in another X server, and just switch to the VT it is in if it finds one.
• Otherwise, the daemon starts a new slave process with a new X server and a new login window, in a very similar way to what older versions did.
• When logging in as a user with an existing session, it switches to the VT it is in, but leaves the login window and its X server running.
• When going into a new session, the X server is simply left to die at the end of the session, and to switch back to the VT from which it was launched.

Not killing the X server in some cases partly addresses the problems caused by letting it switch back to the original VT when exiting. However in several ways the cure is worse than the disease.

• First of all, it will leave unused X servers, with all processes used by the login window - and that makes quite a number of them, with GDM now using a minimal GNOME session.
• When there is such a login window remaining, ConsoleKit will refuse to let you shut down your computer, being lured into thinking there is someone else using it.
• It doesn t solve the inconsistency issue. When you leave a session, you can find either of: a login window, a screensaver unlock dialog, or a black screen.

Getting it to work The modular architecture of GDM makes it possible to improve the situation. (Possible but not easy because of the millefeuille of classes.) However, it is merely a band-aid unless you fix the root issue: the X server knowing better than you which VT it should switch to when exiting. Fortunately Xorg now features an option to avoid that behavior: -novtswitch. So the first step is to enable it, and let the GDM daemon (or slave) handle VT switching through ConsoleKit. With that, the following changes are possible.

• When switching to an existing session, don t leave a X server behind. You can now kill it safely without risking a VT switch.
• On the opposite, when exiting a session, always respawn a login window on the same VT.
• The last step is to stop making a difference between the first launched X server (called a static server) and the flexible servers. The only remaining difference between a static display and a flexible one is that the static one honors automatic login/timed login settings.

The result With all these changes the behavior of the display manager is finally completely consistent.

• When exiting a session, regardless of it, you always find the same login window.
• There is never an unused process left.
• You will never find yourself facing a black screen with only keyboard shortcuts to leave you out of it.

Interestingly enough, this is very similar to what user switching looks like on Vista or MacOS X. So what now? These changes are stabilized for Debian squeeze, but of course it has been long overdue to get them accepted upstream, along with the very large number of Debian-specific changes that still lie in our packages.

I have been helping with an overdue web app project lately, and the project uses ASP.NET MVC, so I have had to use Windows for most of my day. Since I had been using GNU/Linux almost exclusively since 2003, this is quite an adventure (imagine trying out GNU/Linux after a seven year break). It is not nearly as bad as I thought it would be, even though I am using the not-so-well-liked Windows Vista which came pre-installed with my computer.

The first thing that struck me is how much less important the OS is when compared to the situation a few years ago: a lot of the applications I depend on are web-based (GMail, Google Calendar, Google Docs, Springpad), and the ones that are not web-based are multiplatform and installable with a few clicks (GVim comes to mind). In fact, I do not think there is a single piece of software that I really missed in Windows. (An interesting corollary of this observation is that it should be equally easy to migrate to GNU/Linux nowadays.)

The one thing where the operating system matters is hardware support, and I do not think I have to say much here. After years of whack-a-mole GNU/Linux upgrades which would fix support for one component but break another (for things as essential as video and sound), it was absolutely weird having all hardware work properly at the same time (sound after suspend! no video glitches! high quality webcam picture!). There is no point recounting the reasons why hardware support in Linux is as it is, but now I am starting to think that Linux users do tend to suffer from a sort of Stockholm syndrome regarding hardware support; I know I did.

The other important thing that operating systems do is resource management, and I did not have problems here either. In fact, I liked the virtual memory behaviour much better: when Windows ran out of memory (I had filled up the smallish Windows partition and there was no space left for the swap file to grow), it started rejecting malloc calls from applications, but the system was kept alive and responsive, and I could close apps and clean up the mess without much trouble. In Ubuntu, with the default settings, whenever a runaway process ate too much RAM, the system would start thrashing so hard that it would be very difficult to fix. My standard procedure (switch to text console, log in, find and kill app using command line tools) would take minutes and was so annoying that I would sometimes just reset the computer instead. And in the end, even if I did not reset, an important app would possibly be killed anyway. I know there are kernel parameters for tweaking this behaviour (swappiness?), but I never got around to figuring them out as this situation does not arise that frequently, and testing is painful.

I did not like the Windows FS security model. ACLs are much more complicated and thus less transparent that the Unix approach, even though they are more powerful. My main gripe with them is that I do not know a good way to display them easily (as with ls -l in Unix). I have not had to deal with them much though.

Here at mancoosi we have been working for quite a while to promote and advance solver technology for FOSS distributions. We are almost at the end of the project and it is important to make the mancoosi technology relevant for the community. On goal of the project is to provide a prototype that uses part of the results of mancoosi that can based to install/remove/upgrade packages on a user machine. We certainly don't want to create yet another meta installer. This would be very time consuming and certainly going beyond the scope of the project. The idea is to create a prototype, that can work as an apt-get drop in replacement that will allow everybody to play with different solvers and installation criteria. A very first integration step is a small shell script apt-mancoosi that tries to put together different tools that we have implemented during the project. Roberto wrote extensively about his experience with apt-mancoosi a while ago showing that somehow the mancoosi tools are already usable, as proof of concept, to experiment with all solvers participating to the Misc competition. On notable obstacle we encountered with apt-mancoosi is how to pipe the result of an external solver to apt-get to effectively install the packages proposed as solution. Apt-mancoosi fails to be a drop-in replacement for apt-get exactly for this reason. The "problem" is quite simple : The idea at the beginning was to pass to apt-get, on the command line, a request that effectively represents a complete solution. We expected that, since this was already a locked-down solution, apt-get would have just installed all packages without any further modification to the proposed installation set. Of course, since apt-get is designed to satisfy a user request, and not just to install packages, we quickly realized that our evil plan was doomed to failure. The only option left, was to use libapt directly, but the idea of programming in c++ quickly made me to desist. After a bit of research (not that much after all), I finally found a viable solution to our problems in ''python-apt'' that is a low level and wrapper around libapt. This definitely made my day. Now the juicy details. the problem was to convince apt to completely bypass the solver part and just call the installer. First a small intro. python-apt has an extensive documentation with a couple of tutorials. Using python-apt is actually pretty easy (some snippet from the python-apt doco) : here we open the cache (apt.Cache is a wrapper around the low level binding in the apt_pkg module), then we update the package list. This is equivalent to apt-get update . Installing a package is equally easy : Now, the method mark_install of the module package will effectively run the solver to resolve and mark all the dependencies of the package python-apt. This is the default behavior when apt-get is used on the command line. This method has however three optional arguments that are just what I was looking for, that is autoFix, autoInst and fromUser . The explanation from the python-apt doco is quite clear. What we want is to set autoFix and autoInst to false to completely bypass the solver. So imagine that an external solver can give use a string of the form : bash+ dash=1.4 baobab- that basically asks to install bash to the newest version, dash at version 1.4 and remove baobab. Suppose also that this is a complete solution, that is, all dependencies are satisfied and there are no conflicts. The work flow of mpm (mancoosi package manager) is as follows :

• init apt-get,
• convert all packages lists + status in a cudf description,
• pass this cudf to an external solver,
• get the result and set all packages to add/remove in the apt.cache of python-apt
• download the packages
• commit the changes (effectively, run dpkg)

We already have a first prototype on the mancoosi svn. It's not released yet as we are waiting to do more testing, add more options and make it stable enough for testing. Maybe one day, this will be uploaded to debian. This is the trace of a successful installation of a package in a lenny chroot. The solver used here is the p2 solver I think we'll keep working on this python prototype for a while, but this is not certainly what we want to propose to the community. The mancoosi package manager is probably going to be written in Ocaml and integrated with dose3 and libcudf. This will allow us to gain speed and have a solid language to develop with (nothing against python, but we don't feel that a scripting language is suitable for an essential component as a package manager). Time will tell. For the moment this is just vapor-ware ...

At the end of September, things were quite exciting as we had our first project meeting. At that meeting those in the room saw a demonstration of the Moonshot GSS EAP mechanism and we discussed a number of open issues and began to plan for our test infrastructure. We ve made significant progress on the specification front and on explaining Moonshot to important communities since then. However there has been little public progress on the implementation front. Unfortunately, getting the necessary legal clearance and agreements to release code often takes longer than anyone would like; that is what is happening here. We re all eagerly awaiting final approval from the lawyers and JANET(UK) management. However, things have been moving behind the scenes. Throughout much of October, Luke Howard and Linus Nordberg were working on their respective parts of the code. I ve also been working on putting together the test and build infrastructure. As we discussed at the meeting, we re going to use Debian and Ubuntu as the basis for our testing. For example, we hope to release virtual machine images for these platforms for the major Moonshot components. Thus the primary build environment for our testing and virtualization will be for Debian. I ve been putting together that here. Right now, that branch will pull together packages of the SAML infrastructure that we need. I ve also been looking into virtualized test frameworks and believe I ve found one that meets our needs. I ve also put together some primitive build infrastructure that is independent of packaging available here. I ve set up a buildbot that builds both environments. So, as the code becomes available we ll be in a good position to start making it available.

AltOS 0.8 New Software and Firmware for Altus Metrum Devices Bdale and I are pleased to announce the release of AltOS version 0.8. AltOS is the core of the software for all of the Altus Metrum products. It consists of cc1111-based microcontroller firmware and Java-based ground station software. AltosUI New Features in the AltusMetrum Ground Station AltOS version 0.8 contains significant upgrades to the ground station software, AltosUI:

• Post-flight graphing tool. This lets you explore the behaviour of your rocket after flight with a scroll-able and zoom-able chart showing the altitude, speed and acceleration of the airframe along with events recorded by the flight computer. You can export graphs to PNG files, or print them directly.

• Real-time moving map which overlays the in-progress flight on satellite imagery fetched from Google Maps. This lets you see in pictures where your rocket has landed, allowing you to plan recovery activities more accurately.

• Wireless recovery system testing. Prep your rocket for flight and test fire the deployment charges to make sure things work as expected. All without threading wires through holes in your airframe.
• Optimized flight status displays. Each flight state now has it s own custom tab in the flight monitoring window so you can focus on the most important details. Pre-flight, the system shows a set of red/green status indicators for battery voltage, apogee/main igniter continutity and GPS reception. Wait until they re all green and your rocket is ready for flight. There are also tabs for ascent, descent and landing along with the original tabular view of the data.
• Monitor multiple flights simultaneously. If you have more than one TeleDongle, you can monitor a flight with each one on the same computer.
• Automatic flight monitoring at startup. Plug TeleDongle into the machine before starting AltosUI and it will automatically connect to it and prepare to monitor a flight.
• Exports Google Earth flight tracks. Using the Keyhole Markup Language (.kml) file format, this provides a 3D view of your rocket flight through the Google Earth program.

Continuing Features AltOS version 0.8 continues to provide the following features:

• Receive and log telemetry from a connected TeleDongle device. All data received is saved to log files named with the current date and the connected rocket serial and flight numbers. There is no mode in which telemetry data will not be saved.
• Download logged data from TeleMetrum devices, either through a direct USB connection or over the air through a TeleDongle device.
• Configure a TeleMetrum device, setting the radio channel, callsign, apogee delay and main deploy height. This can be done through either a USB connection or over a radio link via a TeleDongle device.
• Replay a flight in real-time. This takes a saved telemetry log or eeprom download and replays it through the user interface so you can relive your favorite rocket flights.
• Reprogram Altus Metrum devices. Using an Altus Metrum device connected via USB, another Altus Metrum device can be reprogrammed using the supplied programming cable between the two devices.
• Export Flight data to a comma-separated-values file. This takes either telemetry or on-board flight data and generates data suitable for use in external applications. All data is exported using standard units so that no device-specific knowledge is needed to handle the data.
• Speak to you during the flight. Instead of spending the flight hunched over your laptop looking at the screen, enjoy the view while the computer tells you what s going on up there. During ascent, you hear the current flight state and altitude information. During descent, you get azimuth, elevation and range information to try and help you find your rocket in the air. Once on the ground, the direction and distance are reported.

AltOS Firmware Update AltOS version 0.8 contains a minor firmware update for TeleMetrum to resolve an issue with main deployment. A mis-feature in the igniter firing code would delay main deployment by 2 seconds in some cases. Thanks to our contributors! We had a lot of help with this release:

• Anthony Towns wrote both the new data graphing interface and the moving map display.
• Bob Finch helped clean up our documentation, and provided flight testing for the firmware updates.

Future Plans A number of features are implemented or in process in the sources available in our publicly visible repository that are not part of the current stable release.

• A Kalman-filter based approach to apogee detection using more than just the baro sensor, so that we can safely control apogee ejection on flights to altitudes beyond the range of our baro sensor alone. Unlike the other items on the list, this will be a significant change to the in-rocket TeleMetrum firmware. It may therefore be a while before this becomes part of a stable firmware release.
• Motor characterization. Because TeleMetrum contains a high-resolution, high-frequency accelerometer, it is possible to take the data from that and compute an accurate thrust curve for the motor.
• Comprehensive PDF and/or HTML -based flight report. Construct a complete report of the flight suitable for publication on the web that includes graphs of the flight and details about motor performance etc.
• Publish flight data to the Altus Metrum web site. This will allow you to share your flight data with others, and let you download flights published by others.

There are any number of additions that could be made to this list; feel free to send along ideas that you ve got. Of course, all of this software is licensed under the GNU General Public License, so you can get the source and hack on it in the comfort of your own home.

Ever wondered how to easily convert e.g. 10 seamiles into kilometres? Use units:

$ units 
2411 units, 71 prefixes, 33 nonlinear units
You have: 10 seamiles
You want: km
        * 18.288
        / 0.054680665
You have: ^C
$

Of course this is interactive. There s also a non-interactive mode:

$ units '10 seamiles' 'km'
        * 18.288
        / 0.054680665
$ 

The line with the asterisk means that 10 seamiles are 18.288 kilometres or 1 kilometre is the 0.054680665th part of 10 seamiles. This quite non-intuitive output is caused by the fact that unit is designed to be used with units only:

$ units seamiles km
        * 1.8288
        / 0.54680665
$

Now this makes more sense: You have to multiply seamiles with 1.8288 to get kilometres and you have to multiply (not divide) kilometres with 0.54something to get seamiles. But this output is still a little bit cumbersome, and annoying if you want to use it in shell scripts. But for luck, units knows some nice options, especially -v ( verbose ) and -t ( terse ):

$ units -v '10 seamiles' km
        10 seamiles = 18.288 km
        10 seamiles = (1 / 0.054680665) km
$ units -t '10 seamiles' km
18.288

Now that s way easier to read and script! You can also script more complex things like

$ units -v '100 attoparsec/microfortnight' m/s
        100 attoparsec/microfortnight = 2.5509901 m/s
        100 attoparsec/microfortnight = (1 / 0.39200466) m/s

Unfortunately not all common units are unambiguous for units:

units -v '100 km/h' m/s
conformability error
        100 km/h = 1.5091905e+38 s / kg m
        m/s = 1 m / s

Well, h seems not to be units unit for hours , so lets tell it explicity that we want km per hour:

units -v '100 km/hour' m/s
        100 km/hour = 27.777778 m/s
        100 km/hour = (1 / 0.036) m/s

Looks more like what I expected. units behaves though a little bit strange when I try to convert litres per 100 kilometres into miles per gallon:

$ units -t '6L/100km' 'mpg'
conformability error
6e-08 m^2
425143.71 / m^2
$

Interestingly changing the verbosity helps already in this case:

$ units -v '6L/100km' 'mpg'
        reciprocal conversion
        1 / (6L/100km) = 39.202431 mpg
        1 / (6L/100km) = (1 / 0.025508622) mpg

Greetings from the Debian booth at LinuxDay.at and thanks to Y_Plentyn, rhalina and bzed for example ideas and the suggestion to write a blog posting about units. :-)

This week it has been harder for me to start on this but KiBi s post Debian XSF News #1 pushed me to continue. Thanks for the cheers!

• #331637 ping Xrandr disabled while Xorg log says the opposite.
• #321357 tagged wontfix xset behaves as intended, there is no easy way to set keyboard autorepeat for single key
• #242442 close xclock -rv looks visible to me.
• #427346 close was already tagged unreproducible, I couldn t reproduce it either so I closed it.
• #169239 ping 8 year old wish probably too late ?
• #431449 ping xmodmap errors when launched by keyboard shortcut.
• #202923 close xorg has timestamps in server log messages.
• #252214 tagged wontfix Andrew Pimlott (reporter) said This bug probable needs a NOBODYCARES tag. so wontfix will do it.

The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.