Someone recently give me a link to a web picasa photo album. I wanted to download all the photo in good resolution, but the only official way to download it is by using the picasa proprietary software. Not only I'm not thrilled to install yet another unfree software, but Google refuse me to download it because "Picasa is not currently available for your operating system". Another solution exist, but need some research:

• You need a Grease monkey userscript that add links in the overview to download the image
• Then the DownThemAll extension will download all those link...

Some time, its great to be able to beat limitation of unfree software thanks to free software.

Sitting in the airport during a layover on my way back from DebConf is one of the few times of year that time and motivation come together and routinely lead me to blog. Each year's DebConf has been special in its own way. This year at DebConf 12, in addition to the usual routine of catching up with all my far-away Debian friends, and of making new Debian friends in a country I've never been before, I got a special treat: my first opportunity to experience the practice of medicine in a foreign country. Last Saturday after arriving in Managua, I discovered that the very pretty paving stones making up the hotel walkway were also very slippery when wet, and the thin rubber strips that had been helpfully put in place to make them less slippery did not measurably succeed in doing so. So as it was raining that afternoon (as it does nearly every afternoon this time of year in Nicaragua), I slipped, and made the critical error of not falling. Instead, I stopped my slide - as it happens, by using the big toe of my left foot as if it were a roller skate brake. I don't recommend this, particularly if, as in my case, you already had it on your todo list to consult a podiatrist after DebConf regarding an ongoing feeling of weakness in precisely that part of precisely that foot. So while everything seemed fine the next day, Monday I woke up early with excruciating pain in my foot which, having forgotten about the incident two days prior, seemed to come from nowhere. After favoring the foot for another day and trying to keep the pain at bay using just OTC drugs, by Tuesday my foot was quite swollen and a source of concern. So I visited the clinic on the university campus, where the doctor diagnosed me with a dropped arch plus cellulitis due to bacteria entering through some invisible cut. Conclusion: university campus clinics are equally useless the world over. But at least in addition to pointlessly prescribing antibiotics, the doctor also prescribed some anti-inflammatory drugs to help bring the swelling down. Nevertheless, my questionable mobility kept both me and Patty from attending the day trip on Wednesday, which was a real shame as I had been keen to climb a volcano that day with my fellow Debian Developers (which in the end didn't happen for anyone, but that's a story for someone else's blog). Instead I took it easy for the day at the hotel, together with a few others who had opted not to attend the day trip, catching up on email and other work and hoping matters would improve. But by the end of the day the swelling was as bad as ever, if not worse, and I had no idea what was going on. Was it broken? Was something dislocated? And so I decided that the following day I would go to the hospital. The nearest hospital, as given in the DebConf local information page, is the Hospital Militar. It's a strange sort of thing as an American who remembers the 1980s to be seeking medical care from a facility operated by the Nicaraguan military; but accompanied by Fitoria, my native escort from the local team I had nothing to worry about; and besides, as a frequent international traveler I long ago learned the secret truth that people are people everywhere, no matter what flag they were born under. The highlight of the hospital visit was definitely when a member of the hospital staff, in full military uniform, shooed me towards a chair instead of standing to talk to her because "every patient has the right to sit, no matter what country they're in". After six x-rays and a doctor's consult, the conclusion was that it's probably not a broken bone and that it will probably clear up in just a couple of days with an even-better anti-inflammatory prescription and taking care of it by not walking on it. And indeed, my foot was already feeling better by Friday and aside from a little tenderness is now just about 100%. There are plenty of other entries on Planet Debian talking about the conference itself, and I don't think I have much to add to what's already been said there. But as for Nicaragua, I can conclude that it must be one of the best countries in the world to break your foot in - between the help of the hotel staff, the top-notch medical professionals, and above all the support of the DebConf local team (with a very big thank you again to Fitoria!), this is one brand of socialized medicine I can appreciate.

Attachment	Size
La mochila viajera, 13 de julio del 2012: Migrantes y software libre	84.19 MB

In the past I used to argue that accurate desktop DPI was important, since after all otherwise you could print out a 12 point font and hold up the sheet of paper to your monitor and it would be different. I later gave up on the idea that accurate DPI measurement was generally useful to the desktop, but there's still something seductively attractive about the idea that a 12 point font should be the same everywhere, and someone recently wrote about that. Like many seductively attractive ideas it's actually just trying to drug you and steal your kidneys, so here's why it's a bad plan.

Solutions solve problems. Before we judge whether a solution is worthwhile or not, we need to examine the problem that it's solving. "My 12pt font looks different depending on the DPI of my display" isn't a statement of a problem, it's a statement of fact. How do we turn it into a problem? "My 12pt font looks different depending on which display I'm using and so it's hard to judge what it'll look like on paper" is a problem. Way back in prehistory when Apple launched the original Mac, they defined 72dpi as their desktop standard because the original screen was approximately 72dpi. Write something on a Mac, print it and hold the paper up to the monitor and the text would be the same size. This sounds great! Except that (1) this is informative only if your monitor is the same distance away as your reader will be from the paper, and (2) even in the classic Mac period of the late 80s and early 90s, Mac monitors varied between 66 and 80dpi and so this was already untrue. It turns out that this isn't a real problem. It's arguably useful for designers to be able to scale their screen contents to match a sheet of paper the same distance away, but that's still not how they'll do most of their work. And it's certainly not an argument for enforcing this on the rest of the UI.

So "It'll look different on the screen and paper" isn't really a problem, and so that's not what this is a solution for. Let's find a different problem. Here's one - "I designed a UI that works fine on 100DPI displays but is almost unusable on 200DPI displays". This problem is a much better one to solve, because it actually affects real people rather than the dying breed who have to care about what things look like when turned into ink pasted onto bits of dead tree. And it sounds kind of like designing UIs to be resolution independent would be a great solution to this. Instead of drawing a rectangle that's 100 pixels wide, let me draw one that's one inch wide. That way it'll look identical on 100dpi and 200dpi systems, and now I can celebrate with three lines of coke and wake up with $5,000 of coffee table made out of recycled cinema posters or whatever it is that designers do these days. A huge pile of money from Google will be turning up any day now.

Stop. Do not believe this.

Websites have been the new hotness for a while now, so let's apply this to them. Let's imagine a world in which the New York Times produced an electronic version in the form of a website, and let's imagine that people viewed this website on both desktops and phones. In this world the website indicates that content should be displayed in a 12pt font, and that both the desktop and phone software stacks render this to an identical size, and as such the site would look identical if the desktop's monitor and the phone were the same distance away from me.

The flaw in this should be obvious. If I'm reading something on my phone then the screen is a great deal closer to me than my desktop's monitor usually is. If the fonts are rendered identically on both then the text on my phone will seem unnecessarily large and I won't get to see as much content. I'll end up zooming out and now your UI is smaller than you expected it to be, and if your design philosophy was based on the assumption that the UI would be identical on all displays then there's probably now a bunch of interface that's too small for me to interact with. Congratulations. I hate you.

So "Let's make our fonts the same size everywhere" doesn't solve the problem, because you still need to be aware of how different devices types are used differently and ensure that your UI works on all of them. But hey, we could special case that - let's have different device classes and provide different default font sizes for each of them. We'll render in 12pt on desktops and 7pt on phones. Happy now?

Not really, because it still makes this basic assumption that people want their UI to look identical across different machines with different DPI. Some people do buy high-DPI devices because they want their fonts to look nicer, and the approach Apple have taken with the Retina Macbook Pro is clearly designed to cater to that group. But other people buy high-DPI devices because they want to be able to use smaller fonts and still have them be legible, and they'll get annoyed if all their applications just make the UI larger to compensate for their increased DPI. And let's not forget the problem of wildly differing displays on the same hardware. If I have a window displaying a 12pt font on my internal display and then drag that window to an attached projector, what size should that font be? If you say 12pt then I really hope that this is an accurate representation of your life, because I suspect most people have trouble reading a screen of 12pt text from the back of an auditorium.

That covers why I think this approach is wrong. But how about why it's dangerous? Once you start designing with the knowledge that your UI will look the same everywhere, you start enforcing that assumption in your design. 12pt text will look the same everywhere, so there's no need to support other font sizes. And just like that you've set us even further back in terms of accessibility support, because anyone who actually needs to make the text bigger only gets to do so if they also make all of your other UI elements bigger. Full marks. Dismissed.

The only problem "A 12pt font should be the same everywhere" solves is "A 12pt font isn't always the same size". The problem people assume it solves is "It's difficult to design a UI that is appropriate regardless of display DPI", and it really doesn't. Computers aren't sheets of paper, and a real solution to the DPI problem needs to be based on concepts more advanced than one dating back to the invention of the printing press. Address the problem, not your assumption of what the problem is.

comments

After reading Jakub s pet peeve about debhelper build-dependencies I decided to check my own and sponsored packages to see how they fare. Oops! Something to fix in all subsequent releases.

It appears I didn't get around to make any blogposts this year, so to fix that and given that that the internet can always use more pictures of cats: What Zappa was working on will likely always remain a mystery.

One week. One long week. One beautiful week. One of the two major weeks of the year has passed since my previous post. Surely, we are in the middle of the two Major Weeks of the year, in the yearly schedule I have upheld for almost(!) ten years: DebConf+DebCamp. Yesterday, DebConf officially started. For the first time ever, we had a DebConf track targetted at the local (for a wide definition of local: All of the Central American countries) communities, which I chaired. We had the following talk lineup during this track:

• Empaquetando software para Debian (Gunnar Wolf)
• Introduction to Debian translation workflow and processes (Christian Perrier)
• OpenPGP discussion and skillshare (Daniel Kahn Gillmor)
• Empaquetando colaborativamente con git y collab-maint (Ulises Vitulli)
• Uso del sistema de manejo de errores de Debian (Hector Colina)
• Building free software communities (Leandro G mez

I believe it was a great success, and I hope the talks are useful in the future. They will be put online soon thanks to the tireless work of our work team. Today we sadly lost the presence of our DPL due to very happy circumstances he will surely announce himself. But DebConf will continue nevertheless - And proof of that is our anual, great, fun and inviting Cheese and Wine Party! After a series of organizational hiccups I hope nobody notices (oops, was I supposed not to say this?), today we had a beautiful, fun and most successful cheese and wine party, as we have had year after year since 2005. As many other people, we did our humble contribution for this party to be the success it deserves. There is lots of great cheeses, great wines, and much other great stuff we have to thank to each of the individuals who made this C&W party the success it was. Yes, it might be among the least-academic parts of our conference, but at the same time, it's one of its most cherished -and successful- traditions. And above all else, we have to thank our Great Leader^W^WCheeseMaster (who we still need to convince to play by our Great Leader's mandates - And no, I don't mean Zack here!) Hugs and thanks to my good and dear friend Christian Perrier for giving form to one of DebConf's social traditions that makes it so unique, so different from every other academic or communitary conference I have ever been part of. We still have most of the week to go. And if you are not in Managua (and are not coming soon), you can follow our activities following our video streams. Remember, debian/rules, now more than ever! And even given the (perpetual) heat in Managua: Wheezy is frozen, whee! [ all photos here taken by regina ]

Attachment	Size
100_2110.JPG	1.53 MB
100_2119.JPG	1.49 MB
100_2121.JPG	1.52 MB
100_2135.JPG	1.49 MB
100_2144.JPG	1.11 MB
100_2146.JPG	1.53 MB
100_2145.JPG	1.08 MB
100_2122.JPG	1.51 MB

It's almost seven years now since I wrote/published Mermaids. It was an important step in my life, confessing publicly what I've found out about myself, how I feel and identify myself. It definitely has been a certain turning point in my life. A year later, there was the Debconf6 in Mexico, which was just as important. I was wearing a skirt for the first time, and that for the whole duration of the two weeks. It was an enormous feeling of freedom, and I knew I was feeling at home. That was also the time I shaved off my beard. And since? Well, I sort of limited myself to these two weeks every year. Debconf is my haven, Debconf is my home. Here I allow myself to be myself. Debian is my family. And like in every family, there are people who won't understand, but that doesn't matter. I feel comfortable to express myself in this crowd in the way I feel. Being abroad seems to help with the confidence, and it seems like it also shines through. I haven't had lots of strange looks. To the contrary, when I went with a skirt to a homosexual acceptance event at home in Vienna, there was a group of gays who were pointing and laughing. Quite an interesting experience, one would assume that people who are wanting more acceptance would be more acceptable and tolerant themselves... But, I don't think I will ever take the step toward actually turning my body into a female one. It was an important step for me to find out about my inner self, and it actually managed to make me accept my male body; even though I can totally relate to people not being able to understand this both people not in the situation and people being in the situation and needing the physical adjustment to be able to be happy again. But this is what and how I am: Contents may vary from packaging. This though has an inherited problem: as I am not (usually) heading for a female appearance (besides my skirt during Debconf), people keep addressing me with a male pronoun, even, or rather especially when using my nick Rhonda. This is something that I consider a fair bit disturbing, especially when it comes from people that I consider to address with the term friends. One would assume that people who you share a fair bit of private life with would be the ones who can understand and relate better than others. But that's where we are, and I also can understand the troubles: I'm not giving them much visual help for fixing their thoughts. I found the confidence in my body, and like most of you know, I have a son I dearly love (and miss like hell these two weeks), so I know how to use the tools it comes with, frankly spoken. But I won't go the road to adjust my body to be a female one instead, just to convince people that I really am the female person that I identify as. It might be hard for you to understand that, it might be hard for you to accept it it is also hard for me, to fight for the acceptance that I thought are an inherent part of the term friendship. I have deepest respect for the people who feel the requirement and have the strength to adjust their body to their mind. It though just isn't the road for me. I already have enough uncertainties in my life to cope with, and I don't need another one to deal with, related to that I might not be able to accept my body after the transition than I am able to accept it now. It's just not important enough for me to find my place. My place is here, my home is Debconf.

/personal permanent link Comments: 4 Flattr this

Since last November, I've been participating in and coordinating Iron Blogger: a drinking club where you pay $5 to a "beer" pool if you fail to blog weekly. The revival of Iron Blogger in Boston has been a big success. Even more exciting, however, is that Iron Blogger concept has spread. There are now two other Iron Blogger instances: in San Francisco coordinated by Parker Higgens, and in Berlin run by Nicole Ebber and Michelle Thorne. Yesterday, we convened a virtual meeting of the Global Iron Blogger Council (i.e., an email thread) and we all agreed a new on iron blogger rule that might sweeten the deal for jet-setting prospective Iron Bloggers: any paid-up member of any Iron Blogger club can attend meet-ups in any other Iron Blogger cities if they happen to be in town for one. Because We Are One. If you want to join us in Boston, we have some room through attrition. Rust bloggers, perhaps? If you'd like to join, you should contact me. And if you'd like to set up your own in a different city, the code is in git. One warning, however. As those of us that have set it up have figured out, the documentation for the software to run Iron Blogger is between poor and non-existent. If you do want to set up your own instance, please get in touch. I'm happy to give you some pointers that you'll probably need but, more importantly, I'd like to work with the next brave soul to put together documentation of the setup process along the way.

Over a year ago when I was considering my first Android phone purchase I setup a test account on my mail server so that I could test email clients on phones and tablets. I used a short password because I didn t want to type a lot on small screens and because typing a password into a random system owned by someone else isn t particularly secure anyway. Then I forgot about the account until I noticed that my mail server was sending out spam. Next time I setup such a test account I ll put rules similar to the following in my Postfwd [1] configuration to stop Postfix from sending such messages. That will prevent the test account from receiving mail from outside or sending mail out of the server. The former is optional (getting a few thousand spam messages in an unused test account is no big deal) but the latter is needed to prevent getting my server blacklisted. id=R_test_recipient ; recipient==test@coker.com.au ; sender!~.*@coker.com.au ; action=REJECT
id=R_test_sender ; sender==test@coker.com.au ; recipient!~.*@coker.com.au ; action=REJECT

• [1] http://postfwd.org/

Related posts:

1. email disclaimers Andre Pang blogs about the annoyance of email disclaimers. For...
2. Email Passwords I was doing some routine sysadmin work for a client...
3. Some Postfix Scripts for dealing with Outbound Spamming I ve just written some small scripts to help me manage...

I got a few emails about the status panel I'd both toyed with and posted. The end result is that the live load graphs now have documentation, look prettier, and contain a link to the source code. Apart from that this week has mostly involved photographing cute cats, hairy dogs, and women in corsets. In Debian-related news njam: Insecure usage of environmental variable was closed after about 7 months, and I reported a failure of omega-rpg to drop group(games) privileges prior to saving game-state. That leads to things like this:

skx@precious:~$ ls -l   grep games
-rw-r--r--   1 skx games   14506 Jul  8 15:20 Omega1000

Not the end of the world, but it does mean you can write to directories owned by root.games, and potentially over-write level/high-score files in other packages leading to compromises. ObQuote: "Your suffering will be legendary, even in hell! " - Hellraiser II (Did you know there were eight HellRaiser sequels?)

I keep using a Neo Freerunner with Qtmoko in a Debian Squeeze (+ some Wheezy) chroot as my daily phone. It also works well for SMS, GPS, MUA, IM, IRC and some Web browsing with Aurora (using both Wifi and GPRS). Last weekend I managed to play a little with VoIP possibilities in Qtmoko and ended with a functional SIP client in my hands. I want to share some points which may be useful for other brave freerunners:

• Qtmoko has a native VoIP client but it seems to be broken. Its sipagent uses port 5060. I couldn't find a way to disable it at qpe startup, so I had to setup my client to use another port.
• Choosing the application: Ekiga takes 93.4MB of additional disk space. Qutecom takes 212MB. Too much for a 256MB rootfs. Twinkle is ok on this point, it uses about 40MB of additional space, but it fails in the capture (mic) quality. I've tried many setups in my voip-handset state file with no success. Perhaps it's something related to the codecs and/or default parameters. I didn't go deeper on this and gave Linphone a try. This package also uses about 40MB of additional space and finally made my day.
• Linphone gui is called by linphone-3, which has a character not supported by /opt/qtmoko/etc/qx/profiles.conf and /opt/qtmoko/etc/qx/favourites.conf. So if you want to have some setup here you need to create a link/wrapper/whatever without this dash.
• You can edit your preferences directly in your ~/.linphonerc . Remember to change the sip_port entry to any other than 5060.
• I use a basic VoIP service from diamondcard.us. It's cheap and works properly. This company gives financial support to Ekiga and Twinkle projects.
• I was not able to have default Freerunner headset working on an acceptable quality. Help will be very welcome.
• Here is my current config:
• /opt/qtmoko/etc/qx/profiles.conf
• /opt/qtmoko/etc/qx/favourites.conf
• .linphonerc
• /usr/share/openmoko/scenarios/voip-handset.state (please share your improvements!)

UPDATE: I didn't make clear that I get a very nice audio quality using internal mic/speaker with the above voip-handset state file. The issue is only when using the headset, which demands understanding and setting up a proper state file. Enjoy some shots:

Included in Debian Edu / Skolelinux is a large collection of end user and school specific software. It is one of the packages not installed by default but provided in the Debian archive for schools to install if they want to, is a system to automatically plan the school time table using information about available teachers, classes and rooms, combined with the list of required courses and how many hours each topic should receive. The software is named FET, and it provide a graphical user interface to input the required information, save the result in a fairly simple XML format, and generate time tables for both teachers and students. It is available both for Linux, MacOSX and Windows. This is the feature list, liftet from the project web site:

• FET is free software, licensed under the GNU GPL v2 or later. You can freely use, copy, modify and redistribute it
• Localized to en_US (US English, default), ar (Arabic), ca (Catalan), da (Danish), de (German), el (Greek), es (Spanish), fa (Persian), fr (French), gl (Galician), he (Hebrew), hu (Hungarian), id (Indonesian), it (Italian), lt (Lithuanian), mk (Macedonian), ms (Malay), nl (Dutch), pl (Polish), pt_BR (Brazilian Portuguese), ro (Romanian), ru (Russian), si (Sinhala), sk (Slovak), sr (Serbian), tr (Turkish), uk (Ukrainian), uz (Uzbek) and vi (Vietnamese) (incompletely for some languages)
• Fully automatic generation algorithm, allowing also semi-automatic or manual allocation
• Platform independent implementation, allowing running on GNU/Linux, Windows, Mac and any system that Qt supports
• Flexible modular XML format for the input file, allowing editing with an XML editor or by hand (besides FET interface)
• Import/export from CSV format
• The resulted timetables are exported into HTML, XML and CSV formats
• Flexible students structure, organized into sets: years, groups and subgroups. FET allows overlapping years and groups and non-overlapping subgroups. You can even define individual students (as separate sets)
• Each constraint has a weight percentage, from 0.0% to 100.0% (but some special constraints are allowed to have only 100% weight percentage)
• Limits for the algorithm (all these limits can be increased on demand, as a custom version, because this would require a bit more memory):
  • Maximum total number of hours (periods) per day: 60
  • Maximum number of working days per week: 35
  • Maximum total number of teachers: 6000
  • Maximum total number of sets of students: 30000
  • Maximum total number of subjects: 6000
  • Virtually unlimited number of activity tags
  • Maximum number of activities: 30000
  • Maximum number of rooms: 6000
  • Maximum number of buildings: 6000
  • Possibility of adding multiple teachers and students sets for each activity. (it is possible also to have no teachers or no students sets for an activity)
  • Virtually unlimited number of time constraints
  • Virtually unlimited number of space constraints
• A large and flexible palette of time constraints:
  • Break periods
  • For teacher(s):
    • Not available periods
    • Max/min days per week
    • Max gaps per day/week
    • Max hours daily/continuously
    • Min hours daily
    • Max hours daily/continuously with an activity tag
    • Respect working in an hourly interval a max number of days per week
  • For students (sets):
    • Not available periods
    • Begins early (specify max allowed beginnings at second hour)
    • Max gaps per day/week
    • Max hours daily/continuously
    • Min hours daily
    • Max hours daily/continuously with an activity tag
    • Respect working in an hourly interval a max number of days per week
  • For an activity or a set of activities/subactivities:
    • A single preferred starting time
    • A set of preferred starting times
    • A set of preferred time slots
    • Min/max days between them
    • End(s) students day
    • Same starting time/day/hour
    • Occupy max time slots from selection (a complex and flexible constraint, useful in many situations)
    • Consecutive, ordered, grouped (for 2 or 3 (sub)activities)
    • Not overlapping
    • Max simultaneous in selected time slots
    • Min gaps between a set of (sub)activities
• A large and flexible palette of space constraints:
  • Room not available periods
  • For teacher(s):
    • Home room(s)
    • Max building changes per day/week
    • Min gaps between building changes
  • For students (sets):
    • Home room(s)
    • Max building changes per day/week
    • Min gaps between building changes
  • Preferred room(s):
    • For a subject
    • For an activity tag
    • For a subject and an activity tag
    • Individually for a (sub)activity
  • For a set of activities:
    • Occupy a maximum number of different rooms

I have not used it myself, as I am not involved in time table planning at a school, but it seem to work fine when I test it. If you need to set up your schools time table, and is tired of doing it manually, check it out. A quick summary on how to use it can be found in a blog post from MarvelSoft. If you find FET useful, please provide a recipe for the Debian Edu project in the Debian Edu HowTo section.

I ve spent some more time on Debian Maintainer Dashboard (DMD), a maintainer/team-centric dashboard relying on Ultimate Debian Database. Done:
- added tabs (jquery really rocks) see example
- added a hacking.html file that describes how to setup a development environment
- created a pad (http://debian.titanpad.com/DMD) to store ideas. TODO:
- recruit contributors ;)

Hello, Internets! After a bit of a disappointment with Lenovo, they ve come through with flying colors, My 520i s palmrest fractured in a couple of really gnarly ways. The machine was still usable, but the fractures were really bad, looked really gnarly and creaked a bit when I put any pressure around it. After having fancyhands call them a few times, each time returning a different part number, I complained on twitter only tagging @lenovo as an afterthought which (to my surprise) got a fast response and helpful email service. Here I am, 3 days later with a replaced palmrest. Nice ending, but I hope it won t happen again :)

Monthly DPL bits, fresh from the oven^W^W^W hot from DebConf12, and just posted to d-d-a.

---

Howdy from DebConf12. It's hot, but it's also time to bother you again with a (not so) brief DPL activity report, this time for June 2012. Time-based freeze: DONE, short freeze: TODO Two highlights for this month. First, you've probably noticed Wheezy is now frozen, YAY. This is huge achievement for the release, but also for the project. It's the first time we do a time-based freeze, and it took some quite heated discussion at the beginning of the release cycle to decide to do this. And we did it properly: respecting the planned month and narrowing down the period later. This exercise has hopefully helped both DDs in their package planning and our upstreams in targeting Wheezy with stable releases of their software. Kudos to the release team for their coordination work! Now we've the second part still TODO: releasing Wheezy, without RC bugs, with a freeze period as short as possible. See the beginning of my last "bits from the DPL" mail for my usual song and dance on how to deliver that, together. DebConf12 A lot of us will attend DebConf12. Enjoy it! ... and take the chance to both have fun and make great plans for Debian's future. But remember that "if it didn't happen on a mailing list, it didn't happen". Not all of us will be lucky enough to attend DebConf (in person or remotely). Make sure that those who don't can take part in your team decisions and get informed of what is going to happen here. Politics

• After discussion (and consensus) on debian-boot, I've asked to join FSF campaign on secure boot.
• Since OIN was seeking comments on their Linux System definition (not really openly though: I learned about it last minute from people directly in touch with OIN representatives), I've contacted them proposing to include all "Debian main" packages in their definition. I haven't yet hear back from them, but I doubt they'll accept the idea. It'd be nice to have an official answer about why, though.

Zack's spring tour I spent a significant part of June doing Debian talks ins some sort of "spring tour" between Italy and France. In particular:

• I've taught a lenghty class about the Debian Project at the Insubria International Open Source Summer School in Como, Italy (see slides)
• I've delivered the opening keynote at the yearly Free Software conference in Ancona, Italy, ConfSL'12 (see slides)
• I've delivered the opening talk at the Debian for Scientific Facilities Days event organized by the European Synchrotron Radiation Facility (ESRF) in Grenoble, France (see slides)

Many thanks to the organizers of these events for inviting and sponsoring me (as well as other Debian people, in the ESRF case) and for their interest in Debian. Sprints

• I approved (for a budget of ~2'000 EUR) and helped hosting the i18n sprint in Paris. As a (great!) result of it, the i18n infrastructure has now been moved on DSA administered machines. A more detailed report is available. Thanks to all attendees and in particular to Christian Perrier for the organization work.
• as part of the "Debian for Scientific Facilities" event, a Debian Science sprint also took place at ESRF. Report is pending
• a BSP took place in Salzburg in June, see the report posted by Bernd Zeimetz. I've approved using some Debian money (~350 EUR) to pay for lodgement of some of the attendees

Assets

• DSA have been working on seting up the first machines we bought as part of the yearly revamping plan of Debian hardware. As one of the first user visible changes, UDD has been moved to a new, faster, machine. I single this out because, if you're doing RC bug squashing (as you should! :-)), you'll notice that the bugs search interface is now much faster, hopefully making your release work less frustrating. Similar improvements are forthcoming for other machines, while DSA (thanks!) migrate other services to newer hardware.
• Last April I mentioned that we're aiming at publishing comprehensive Debian budget reports for the past couple of years and that one of the blocker is access to our transaction information at SPI. This is still a blocker, unfortunately. And we still don't have an ETA on when it'll be fixed.
• The current owner of debian.eu has let us know that he is willing to hand over the domain to us. Finally.
• The European part of our Madrid protocol application for the Debian trademark has been vetted by the European trademark office. Meaning: Debian trademark is now officially protected in Europe.
• DuckDuckGo sent me a first report of the "donation" they're ready to make, based on our agreement with them. The aument is still unclaimed, as we're aiming at invoicing twice per year (to keep the papwerwork low). It isn't a stellar amount: 32.55 USD for the month of May.

Discussions Some relevant discussions for project evolution has been going on in June and I took part into them. You might want to have a look at them:

• proposal to change the way DM permissions are handled
• proposal to change the policy ruling the debian.net domain
• we've been discussing debconf12 budget at length, including how to deal with travel sponsorship requests in the future:
• in the "debian account on github" thread, I've proposed a general policy for presence of accounts named "debian" on non-free services
• the long quest on how to choose Wheezy artwork has come to an end, and we have a very nice theme now, thanks to contributions by many artist and integration work by Paul Tagliamonte. Not all went well in the process, but there are useful lessons for the future.

Misc

• I got quite some feedback about the debate with debian-multimedia.org I mentioned last month. My take away message from that feedback is that many users have no idea about the multimedia capabilities (and in particular of codecs availability) of recent Debian releases. We should probably invest some communication energies into that.
• as planned, another tech-ctte IRC meeting has happened. I took part into it, mostly asking to prioritize long standing issues, such as the Python maintenance one. Minutes of the meeting are available.

Cheers.

---

PS the boring day-to-day activity log for June is available at master:/srv/leader/news/bits-from-the-DPL.txt.201206

In the NUUG FiksGataMi project (Norwegian version of FixMyStreet from mySociety), we have discovered a problem with the municipalities using Zimbra. When FiksGataMi send a problem report to the government, the email From: address is set to the address of the person reporting the problem, while envelope sender is set to the FiksGataMi contact address. The intention is to make sure the municipality send any replies to the person reporting the problem, while any email delivery problems are sent to us in NUUG. This work well in most cases, but not for Karm y municipality using Zimbra. Karm y is using the vacation message function in Zimbra to send an automatic reply to report that the message has been received, and this message is sent to the envelope sender and not the address in the From: header. This causes the automatic message from Karm y to go to NUUGs request-tracker instance instead of to the person reporting the problem. We can not really change the envelope sender address, as this would make it impossible for us to discover when there are problems with the MTAs receiving problem reports. We have been in contact with the people at Karm y municipality, and they are willing to adjust Zimbra if something can be changed there to get a better behaviour. The default behaviour of Zimbra is as far as I can tell according to the specification in RFC 3834, which recommend that vacation messages are sent to the envelope sender and not to the From: address. But I wonder if it is possible to adjust or configure Zimbra to behave differently. Anyone know? Please let us know at fiksgatami (at) nuug.no.

A copy of this post is sent to soc-coordination@lists.alioth.debian.org as well as to debian-bootstrap@lists.mister-muffin.de.

Diary

June 18 Pietro suggests a faster way to generate installation sets for a list of packages. In my case, I need an installation set for every source package in the archive to find out how often a binary package is needed to build a source package. As a result, the speed is doubled in contrast to the original approach.

June 19

• adapt code to work with new dose release 3.0
• remove unneeded parts of code
• add different possibilities to find amount of source packages that need a binary package
• add code to get multiple installation sets using Depsolver_int.solve

June 20

• add ~global_constraints:false to Depsolver.listcheck, Depsolver.trim and Depsolver.edos_install calls
• adapt output graph to limited xdot capabilities

June 21 I formulate an email to the list, reporting of dependency graphs of debhelper, cdbs, pkg-config and libgtk2.0-dev. My current technique gets an installation set for a source package, removes all those that are already installable and adds the others as a dependency of that source package. This dependency will include an installation set of that binary as well minus all packages that are already available. The problem with that approach are dependency cycles created by long dependency chains. Example: src:A needs B needs C needs A. B and C would both be added as a dependency of src:A. B as well as C would also include their installation set which in both cases includes A. So now there are two cycles: src:A->B->A and src:A->C->A. For a real life example, look at the following situation of cdbs and src:sqlite3. It is created because src:sqlite3 needs cdbs needs python-scour needs python needs python2.7 needs libsqlite3-0. Therfor libsqlite3-0 is in the installation set of cdbs, python-scour, python and python2.7. This creates five cycles in the graph even though there is only one. It would be better to reduce the dependencies added to src:sqlite3 to its direct dependency which is cdbs. Package dependencies are disjunctions from which the solver chooses one or the other to build an installation set. To solve the problem above I would need to know which disjunction the solver chose and then only add the direct dependency of a package to the dependency graph.

• improve build_compile_rounds performance
• big overhaul of menu structure
• fix subgraph extraction code

June 22

• do not create a universe if not needed - use hashtables instead
• for sorting packages, generating difference of package sets and otherwise comparing packages, always use CudfAdd.compare
• as a custom list membership function, use List.exists instead of trying List.find
• more speedup for build_compile_rounds
• the number of source packages that can be built does NOT include the cross built packages
• print closure members in graph
• refactor code and move common functions to bootstrapCommon.ml
• add breakcycles.ml for future code to break cycles using staged build dependencies
• use more extlib functionality
• extended package list input format

June 23 After several emails with Pietro I learn about syntactic dependency graphs. To document my progress and prove my efforts I committed the code as commit 6684c13. But this code was soon found out to be unecessary so it will be removed later and just serves as documentation.

June 24 I came up with another (better?) solution to get the chosen disjunctions. It simply uses the calculated installation set to decide for each disjunction which one was taken by the solver. I reported that important step and the open questions involved with it in an email to the list. The problem always was, that an installation set can easily contain more than one package of a disjunction. In this case it is not clear which branch was chosen by the solver. I found, that in Ubuntu Natty there are only 6 such packages and for each of them the situation can be solved. It can be solved because in all of those cases it is that either one package of a disjunction provides the other or that both packages depend upon each other, which means that both have to be included.

June 27

• use installation set to flatten build dependencies of source packages
• refactor code and move common functions to bootstrapCommon.ml

June 25 I have to have an algorithm that finds all circuits in a given graph. This is necessary so that:

1. cycles can be enumerated for huge dependency graphs where cycles are hard to see
2. cycles can be enumerated to find a cycle that can be broken using staged build dependencies

It seems that Johnson's algorithm is the best way to do this complexity wise and Pietro already blogged about the problem together with an implementation of the algorithm in ocaml. Unfortunately it turns out that his code doesnt implement the algorithm correctly and hence misses out on some cycles. The fix seems not to be too trivial so I'm still investigating it.

June 28

• add crosseverything.ml to obtain a list of source packages that, if cross compiled, would make the whole archive available

Results While the first week was productive as usual, I had to work some time on a University project during the second week as well as attend a family meeting. I will catch up with the lost time over the course of the next week.

dose3 Using dose 3.0 (which fixes a bug about essential packages) the output of the algorithms is now likely less wrong then before.

performance Performance was improved in the generation of installation sets as well as in the code that tries out how many packages can be built in multiple rounds. This was achieved by more caching, less unnecessary operations in looping constructs, replacing lists with hashtables, not creating universes where not necessary.

user interface The main program, basenocycles.ml now has a much better menu structure.

input format The programs take two package file inputs. The list of source packages that has to be cross built for a minimal build system and the list of source packages that was chosen to be cross compiled in addition to that. Both files list one source package per line and now allow comments.

refactoring As more and more scripts are added, more and more functionality is moved to bootstrapCommon.ml which makes each script much cleaner.

what to test for cross building As discussed in the "Future" section of the last report, I now automated the process of finding out which packages, if they were cross compiled, would make the whole archive available because they break all cycles and allow native compilation of the rest. The outcome: to build 3333 out of 3339 packages in natty natively, at most 186 source packages must be cross compiled. The other six cannot be compiled because of version mismatches in the Natty Sources.bz2 and Packages.bz2. The code can be run from crosseverything.ml.

limit source dependencies to direct dependencies Reducing the dependencies of source packages from their full installation set to their direct dependencies by finding out which disjunction of their dependency list were taken, greatly simplifies the dependency graphs. The dependency graph created for libgtk2.0-dev could be reduced from 491 to 247 vertices for a depth of three. For cdbs it is now clearly visible that cdbs depends on libsqlite3-0 which builds from src:sqlite3 which depends on cdbs. Before: After: For pkg-config the graph also has been reduced to the one single cycle that matters: src:pkg-config needs libglib2.0-dev which depends on pkg-config which builds from src:pkg-config. Before: After:

Future I will prepare content for wookey's debconf talk on crossbuilding and bootstrapping. As this will include directions how to use the current code, I will kill two birds with one stone and write some proper documentation for my current source. The following two lists will be displayed after a dependency graph is calculated and reduced to its scc:

• those source packages that have the least build dependencies not fulfilled. Those might be candidates for easy staged build dependencies. Since the source package is part of the scc, it will definitely be involved in some cycle somewhere.
• those binary packages that most source packages depend upon. Those could be candidates for cross compilation as it might be easier to cross compile the source package than using staged build dependencies.

Patrick managed to cross build packages with sbuild now. So the list of packages that crosseverything.ml produces can now be checked efficiently for cross buildability. With this list, potentially more cycles can be broken out of the box. A feature will be added that allows the user to remove all packages from a dependency graph that can be cross compiled without any additional effort. Version mismatches between source and binary packages in Sources.bz2 and Packages.bz2 respectively in Ubuntu make the scripts fail and/or produce wrong results. Debian (even Sid) doesnt have this problem so I should find out where to report this problem to Ubuntu. I need to write a working version of Johnson's algorithm because much functionality depends upon it. I have the option to improve Pietro's version or write one from scratch. Writing one from scratch might be easier as I have Pietro's code as template as well as a Java implementation of Johnson's algorithm which seems to work. The following functionalities need working cycle enumeration:

• given source packages with staged build dependencies, an enumeration of cycles is needed to find out which cycles can be broken by building packages staged. It makes less sense to blindly build a package stage and then check if this makes more packages available.
• display cycles of a dependency graph to the user. After obtaining all cycles in the graph it makes sense to sort them by their length. The user would then investigate the situation of the smallest cycles first. This makes sense because breaking small cycles can potentially break bigger cycles. Since in the end, all cycles have to be eliminated anyway, it makes sense for the user to first tackle the small ones.
• display the feedback arc set to the user. The packages in the feedback arc set might be very good candidates for reduced build dependencies or cross compilation.

For the last 10 years, I've been working on many Free Software projects. From Debian to OpenStack, through awesome, Emacs, XCB and many more. This obviously allowed me to enhance my technical skills, but it also taught me about Free Software and Open Source development processes, and how to work with and close to the community. Working for almost 6 years at Easter-eggs taught me how to work in an autonomous manner, how to lead and manage a project. And how to run a company, thanks to the cooperative status of this great one. These are the reasons why I decided to leave my latest job and run my own company to work as a freelance consultant & developer specialized in Free Software, starting today. Therefore, I am now able and available to provide expertise and development on Free Software, including upstream contribution. Especially on projects I already worked on recently, like OpenStack.