Since the introduction of the 3.0 (quilt) source format, it is now possible to integrate multiple upstream tarballs in Debian source packages. This article will show you how to do the same with your own package shall you need it. It s quite useful to easily integrate supplementary plugins, translations, or documentation that the upstream developers are providing in separate tarballs. Step by step explanation We ll take the spamassassin source package as an example. The upstream version is 3.3.1. The main upstream tarball is named as usual (spamassassin_3.3.1.orig.tar.gz) and contains the top directory of our source package. We already have a debian directory because the package is not new. Upstream provides spamassassin rules in a separate tarball named Mail-SpamAssassin-rules-3.3.1.r901671.tgz. We grab it, rename it to spamassassin_3.3.1.orig-pkgrules.tar.gz and put it next to the main tarball. The pkgrules part is the component name that we choose to identify the tarball, it s also the name of the directory in which it will be extracted inside the source package. For now that directory doesn t exist yet so we must create it.

$ mv Mail-SpamAssassin-rules-3.3.1.r901671.tgz spamassassin_3.3.1.orig-pkgrules.tar.gz
$ cd spamassassin-3.3.1
$ mkdir pkgrules
$ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz

This is already enough, the next time that you will build the source package, the supplementary tarball will be automatically integrated in the generated source package.

$ dpkg-buildpackage -S
[...]
 dpkg-source -b spamassassin-3.3.1
dpkg-source: info: using source format  3.0 (quilt)'
dpkg-source: info: building spamassassin using existing ./spamassassin_3.3.1.orig-pkgrules.tar.gz ./spamassassin_3.3.1.orig.tar.gz
dpkg-source: info: building spamassassin in spamassassin_3.3.1-1.debian.tar.gz
dpkg-source: info: building spamassassin in spamassassin_3.3.1-1.dsc

The supplementary tarball is now part of the source package but we re not making anything useful out of it. We have to modify debian/rules (or debian/spamassin.install) to install the new files in the binary package. A special case: bundling related software In very rare cases, you might want to create a bundle of several software (small perl modules for example) and you don t have any main tarball, you only have several small tarballs. Rename all the tarballs following the same logic as above and when building the source package you can ask dpkg-source to create an empty (and fake) main archive for you with the option --create-empty-orig:

$ dpkg-buildpackage -S --source-option=--create-empty-orig

Use with care as the version number you give to the bundle is what users will see and it s likely unrelated to the version number of each individual software. Common mistakes Forgetting to extract the supplementary tarball If you forget to extract the content of the supplementary tarball in the pkgrules directory, dpkg-source will emit lots of warnings about those files being deleted. In fact, you did not delete them but you only forgot to create them in the first place.

dpkg-source: warning: ignoring deletion of directory pkgrules
dpkg-source: warning: ignoring deletion of file pkgrules/20_fake_helo_tests.cf
dpkg-source: warning: ignoring deletion of file pkgrules/60_shortcircuit.cf
[...]

Using a bad version number for the supplementary tarball Sometimes the supplementary tarball has a version of its own that does not match the upstream version. You must still name the file in a way that matches the upstream version of the main tarball otherwise it will not be picked up by dpkg-source and it will generate a new patch in debian/patches/ containing the whole new directory. It s possible to encode the version number of the supplementary tarball in the component name (in our example above we could have picked pkgrules-r901671 as component name) but this means that the name of the associated directory will regularly change and you must adapt your packaging rules to cope with this. However this last trick has the benefit of being able to update the additional tarball without bumping the upstream version. A sourceful upload of a new revision of the package will be accepted by the archive: the main tarball is ignored since it s unchanged but the supplementary tarball is taken since it s a new file for the archive (it has a different filename). Be sure to move away old versions of the additional tarball when you do that if you don t want to upload several versions of the same tarball by mistake! Misextracting the supplementary tarball dpkg-source is very smart when it extracts the supplementary tarball and you should be as well when you manually extract it. If the tarball contains only a single top-level directory, that directory is extracted, renamed to match the component name and moved in the source package directory.
If the tarball contains several top-level files or directories, then the target directory is first created and the content of the archive is directly extracted into that directory. Here are commands to install the files in both cases (we re already in the source package directory):

$ mkdir pkgrules
# Archive contains a single top-level directory
$ tar -C pkgrules --strip-components=1 -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz
# Archive contains many top-level entries
$ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz

2 comments Support my work

This summer of 2010 has been memorable. It started with a difficult period following the hospitalization and death of my mother, a series of very intense and equally memorable conferences catapulting me out of my funk and ending with a trip to Ireland, perhaps one of my most pleasant trips ever. I have always wanted to go there, as I have some good Irish friends and I was also quite attracted to the place due to its history, so when the opportunity came for me to go, I did not hesitate to book my ticket. I was not left disappointed in any way, shape or form, although since I barely experienced the gray, misty, and rainy weather Irish is famous for, my experience may admittedly be a bit skewed. These are some of things I did and some of my fragmented thoughts about Ireland and some photos, proof that the weather was UnIrish Ireland and The Irish: Well I can t as no one can speak of The Irish as if they were some unitary group but I did learn a lot about Irish history and managed hang out with a number Irish folks (even a family) and one thing that seems to mark Ireland as distinct, what makes it stand out from the rest of its Western European brothers and sisters, is the pervasive sense of history bleeding into the ambiance, perhaps because it is so tragic. The short version of the history, if you don t know it, is that the Irish, especially the Catholics, got repeatedly screwed by the British monarchs/rulers/planters/government/ for nearly a thousand years, the last five hundred of those being particularly harsh and ugly, a cycle of slight gains crushed by various forms of tyranny and violence at least until part of the country achieved independence (Northern Ireland is a bit of a different story). I may have gone a bit out of my way to learn about Irish history, more than I have done for any other place, but this historical consciousness seemed to be inescapable, precipitating into all sorts of conversations and places. To take one example, I went to see Gaelic Football, one of the two beloved national sports (the other being hurling), and the minute you learn anything about this sport, you learn that it is intimately bound with the Irish fight for independence and nationalism. The Irish are also very warm, kind, and outgoing. They also seem to curse an awful lot as well, so much so cursing is a bit of a national pastime, which yes, I (f*cking) loved as I tend to have a bit of a foul mouth myself, curbed I will admit, in recent years and in the classroom. It crept up in a lot of places but was most pronounced during the All Ireland Semi-Final Gaelic football game when the ladies (not lads, mind you) behind me were constantly yelling at the referee, hurling the c-word (rhymes with trunk) whenever they made a call they disagreed with. EASA/Maynooth.: I went to Ireland to attend the largest Anthropological meetings in Europe, and in specific an all day panel on digital anthropology, which seemed like a great opportunity given we are a a bit of a minority. The conference was impressively large with roughly 1200 attendees (can you believe there are that many anthropologists?), smoothly run, and the all-day panel on digital media was quite lively and I got to meet some really interesting folks. I was a tad sad to find out Maynooth is the only university in Ireland with an Anthropology department (for crying shame lads!!!) but at least it is located in a darn stunning university: the old quarters of the campus are strikingly beautiful. Anonymous: I have done some work on Anonymous and well when I found out there was going to be a raid/protest at the Church of Scientology (a pretty dismal, and run down church), I got in contact with Irish anon to let them know I was coming. Although someone first decapitated me (at least in character with their norms, right?), when I showed up in person, they were not only civil but really quite hospitable (greeting me with one of my favorite songs). Overall it was a great day. I was reminded of important differences among Anons (Irish Anon s take their anonymity pretty seriously, the New York Anons do not) and also good to experience the social life and metabolism of a protest, especially one attended by folks who have lost family to the church. Dublin: Since I stayed with my friend and his family in Dublin, this is where I spent most of my time. I was able to hook up with various friends, including one from graduate school who just got back from years of fieldwork in Rwanda and hearing about his experiences and stunning but stunningly sad project made me feel like mine in comparison was Child s Play (in fact, it really was). I got to see the Debian crew (many who work at Google) and I finally paid a visit to the office, which was exactly how I imagined it to be (good and abundant food, good lighting, lots of toys and bikes, lots of Star Wars posters.. Yep, it could have been in Silicon Valley). But I was surprised at the young age of the marketing and sales folks who were hanging in their lounge when I ran into them. In fact when I saw them I thought like I was looking at my freshman class or something! It was great to see the Debian folks (though no one I met was actually Irish), as well, one of my favorite things to do whenever I visit a foreign city. I walked my heart out in the city getting a blister in a shoe that I thought was blister proof and while not as picturesque as some other European cities, it has a ton of character and no shortage of Guinness and pubs (no surprise there). My favorite places/things were: The National Library (great exhibit on Yeats, but make sure to use the multi-media as that is where all the information is stuffed), St. Stephen s Park (overflowing with chubby ducks and lovely flowers), the prison Kilmainham Gaol (would not advise a visit if you are feeling in any way down, there is some heavy shit you learn during the tour), the simple stained glass that seemed pretty common, and finally the Long Room in Trinity Church, which you enter after the Book of Kells (I realized just how much I adore books when I visited this old library stuffed from floor to ceiling with old old old books). The West Coast: I did not think I was going to head out west but after hurricane Earl started its burst along the eastern Seaboard and I was able to change my ticket for free so I stayed a few more days. I went to the Burren and the Cliffs of Moher both totally stunning, really majestic. As is often the case with these type of these natural wonders, I am often left elated and awed but such strikingly wondrous places also seem to subsequently spur a more melancholic state of mind and heart. Friends, Family, and Dogs: While in Dublin I stayed with my friend A. and his extremely hospitable family, which included, a brother, a father, and three Irish mutts, one of which, Buster (pitt bull/lab mix), pretty much stole my heart. Buster s true love, is food, so much so he almost poised himself to death a little while back snorting down something he shouldn t have costing the family a pretty penny to save him. My friend no longer lives there but came from Berlin and it was a real treat to not only spend days layered upon each other with a friend (it has been an awful long since I have done that outside of conferences) but also meet his family. You learn a lot about your friends that way and in this case, there is some serious and I mean serious intellectual jousting that happens, sometimes bordering on warfare but generally it plays out in more contained, civil and fascinating fashion. Now I understand why my friend is armed with seemingly endless knowledge: it was needed for purposes of defense at home. So in essence, a great, great trip and a fantastic way to end a memorable summer and transition into what I hope will be a bit of a monkish (I call it monk mode) period for this academic year. I am (so so so) fortunate enough to have a fellowship at the Institute for Advanced Study and am going to try my darnest to take advantage of the fact I am not teaching (Hell Yes!) and hide away and accomplish all that I have set out to do.

(For Those Who Care About An Introduction: Christine Spang gave a talk during DebConf10 about Simple Defects (SD), and blogged about it later on.) Folks maintaining Debian packages are already able to partially-clone bugs.debian.org s bug database thanks to the local-debbugs tool. But what about upstream s bug tracker? Taking a (shamelessly self-centered) example: X.Org packages are hosted on FreeDesktop.org s bugzilla. Thanks to SD, it s possible to fetch bugs from there as well! Here s the obligatory picture: This means that you can browse/search them locally while being offline (or well-connected, but without having to use that !$\ %$^ bugzilla web interface). Many of the replica types support both reading and writing, meaning you can also queue some changes locally, and push them later. Currently, sd help sync says that read-write support is available for RT, Hiveminder, Trac, Google Code, and GitHub. There s also read-only support for redmine. Debbugs is being worked on, see Christine s blog post about her SD talk for more info. Given there was no support for bugzilla, I had a quick look and reported my findings. The main point being: \o/ Bugzilla s XMLRPC \o/ A little while later (I m not exactly fluent in Perl ), I came up with a tentatively-mergeable branch adding preliminary read-only support for bugzilla. There s still a lot of work, but I m trying to work on it on a regular basis, adding support for more properties, and fixing bugs (tests should be written some day, too).

Here in the UK we've had a bank holiday weekend. Usually I would have gone to Cambridge for the Debian BBQ, but this year I joined forces with Thomas Adam for some SmoothWall Express on Debian hacking. There are several challenges involved in moving the SWE3 code from its native distribution to Debian; this weekend we worked around some of the permissions problems. On SWE3, the web server and most of the service daemons run as the user 'nobody'. This means that the web server can write out configuration files as the same user as everything else; it can also read the system log files. When the web interface needs to run a privileged action (like setting firewall rules), it sends a command to 'smoothd', which is a daemon running as root. (Admin ssh access is always directly as the root user.) However, web servers in Debian tend to run as user 'www-data', which does not have permission to read log files. Similarly, writing out configuration files as that user would mean that any cgi script (not just ones in the swe3 package) could modify them. I would prefer to run the swe3 cgi scripts as a separate user, and grant this user permission to view logs etc. This debian-webapps thread makes it sound very easy, but if you want to do that with cgi scripts rather than fastcgi, I think you have to run a separate web server for each user. On Sunday afternoon, in a dramatic display of corner-cutting, I gave up on that approach and added www-data to the 'adm' and 'proxy' groups in the postinst. Thomas heroically patched all the cgis to call the "config writers" via smoothd, although I'm wondering whether some careful use of the chgrp command in the postinst might be better than running that code as root. Another hack: in order to actually start a firewall, we needed to know which network card is the "RED" interface, in SWE3 terms; i.e. which one is meant to be the public-facing network device. It's also nice to know which one is "GREEN". So two debconf questions and some hardcoded magic numbers later, we have a basic firewall init script. Lovely. Oh, and at some point I removed the htaccess file, so any user on your network can mess with your firewall. Should probably fix that. Today I started some awful scripts which use Simple-CDD to build an iso containing all the packages we want. We are going to need to extend the networking configuration in the installer to set up multiple network cards. Then we need to figure out a nicer way of assigning IP addresses to devices; unlike on the proprietary version of the product, there seems to be no web configuration of network settings in Express. I've not figured all of this out yet. So, in summary: we are deliberately trading some technical debt in order to quickly produce an initial release that might interest people. (But please note the disclaimer of warranty in the README file in that directory.) And in other news, I've been working at Smoothwall Ltd. for just over one year. Hmm. So this is what they call 'experience'.

Debian and Ubuntu have a set of official membership roles that can be granted to regular contributors. Those roles come with rights that enable the contributors to do their work and to participate in the project governance (elections and other official decision-making processes). It s also a way for the distributions to acknowledge the work done: most contributors are proud of the status they reached. The membership structure plays an important role in the development of a distribution: it defines the kind of contributors that are welcome in the project, it sets expectations of the project towards its contributors and defines their rights. In the end, this shapes the project s ability to recruit new contributors to keep the project alive and kicking. This article introduces the existing statuses in Debian and Ubuntu, and defines the sometimes confusing jargon associated with them. The Debian Case Debian only has two types of official members: Debian Developers (DD) and Debian Maintainers (DM). The rights of the developers are codified in the Debian Constitution while those of the maintainers have been defined in a general resolution of 2007. The Debian Maintainer status is still mostly documented in a wiki page. The integration of this new status in Debian s official processes has been slow to come largely because it was introduced at that time without enough negotiation with the involved parties. Nowadays, it is preferred that people get the DM status before applying for DD. DM is a very limited role: maintainers can only upload packages that already have their name on them (either in the Maintainer or Uploaders field) and a specific flag (DM-Upload-Allowed: yes) that only Debian Developers can add. They have no other rights and limited access to Debian s resources. Besides those official roles, there are also maintainers of packages that have no official status within Debian except that they are listed in the Maintainer field of the package. They are doing the maintenance work but all uploads are done by a Debian Developer after verification of the work done (this is called sponsorship and is the only way to start with official packaging work). Once the DD trusts the maintainer, the developer will typically ask the maintainer to apply for DM status in order to be relieved from the sponsorship work. In the end, that makes three different kind of package maintainers and a lot of confusion when you discuss membership issues in particular when the New Maintainer process is the path that you follow to become a Debian Developer. Don t be fooled by the names when reading Debian s documentation! The Ubuntu Case Ubuntu had, from the start, an official Ubuntu Member status that includes all contributors: developers of course, but also documentation writers, artists, translators, etc. This status notably grants the right to vote in elections of the Community Council, the right to participate on Planet Ubuntu, and the @ubuntu.com email alias. For developers, the situation is more complicated: the wiki page lists no less than five different statuses. Initially, developers were split between Ubuntu Core Developers and the MOTU (Masters Of The Universe). The latter were responsible of the universe/multiverse sections of the archive while the former also had upload rights for the main/restricted sections. But, inspired by the Debian Maintainers concept and facing concrete problems in terms of archive management, they changed their infrastructure to offer more fine-grained control on package uploads. Ubuntu can now grant upload permissions on a package-per-package basis, but it can also delegate the right to grant upload permissions with the same granularity. This lead to the new Per-Package Uploader status which is simply an Ubuntu Member with upload rights on a limited set of packages where they have a specific expertise. The more generic Ubuntu Developers status now encompasses members of various development teams that have been delegated the right to manage upload permissions on a (usually large) package set (the current teams are Ubuntu Desktop, Mythubuntu, Kubuntu, and Edubuntu). Those teams can define their own policy to add new members provided they follow the basic rules defined by the Developer Membership Board (see this wiki page). Ubuntu Contributing Developer is an intermediate status for someone who is not yet ready for one of the other developer statuses but who has still shown enough commitment to be an Ubuntu Member. All those statuses can be obtained in a similar way: you prepare a wiki page listing your past contributions, you collect testimonials from existing members that you have worked with, you add yourself in the agenda of the next meeting of the board (or council) that grants the status that you seek, and you attend the meeting. The members of the board will decide whether you are ready for the status (or not) based on what you provided in the wiki, based on your answers during the meeting (and on a mailing-list for developers), and based on what others have to say about you. The most important boards are usually elected by the community while others are commonly appointed by the community council. Those governance bodies include Canonical employees but not as many as one would expect: two out of eight in the Developer Membership Board, two out of eight in the Community Council, but all six members of the Technical Board. The last figure, while not intended, is not surprising given the high expectations set on potential members of the technical board. Mark, as the founder, is the only person to have a permanent seat on both the Community Council and the Technical Board. Comparison of the Statuses Between Debian and Ubuntu The following table summarizes the rights given to each developer role in the two projects (Put the mouse over the abbreviations to know what they are referring to).

Rights	Debian		Ubuntu
	DM	DD	UM	PPU/UD	MOTU	UCD
Package maintenance via sponsorship	Y	N/A	Y	Y	Y	N/A
Official email alias	-	Y	Y	Y	Y	Y
Participate in votes for members	-	Y	Y	Y	Y	Y
Participate in votes for developers	-	Y	-	Y	Y	Y
Upload rights restricted to pre-approved packages	Y	-	-	Y	-	-
Upload rights restricted to a section of the archive	-	-	-	-	Y	-
Unlimited upload rights	-	Y	-	-	-	Y
Number of contributors (as of 2010-07-27)	117	904	462	27	85	63

Please note that the number of contributors are not 100% accurate for Ubuntu. A contributor can have multiple statuses (direct membership to a launchpad group) granted over time (while gaining experience). The problem has been mostly avoided by calculating differences between number of members of the various groups but it s not perfect and it can t be: some MOTU are also PPU for packages in main and it s legitimate (but I only counted them as MOTU and not as PPU). Another limitation is that members of some administrative teams are included indirectly in many teams and thus appear in the count while they should not. Anyway, this simple table makes it obvious that Ubuntu s structure offers a broader choice of statuses. They acknowledge the work of all contributors from the start while still giving the most critical rights only to those who have proven that they deserve them. Despite this difference, Debian still has a significant advantage in terms of number of developers. That number does not tell the whole story though: the Ubuntu contributors include many Canonical employees (e.g. 36 out of 63 core developers have a @canonical.com email registered on their launchpad account) that are likely to spend more time working on the distribution than the average Debian member. But even if comparing person-hours would be a challenging thought experiment, in practice it s of not much interest if both projects continue to cooperate and if more and more of the contributions flow in both directions. Debian is aware of the shortcomings of its structure. Changes to better accommodate non-packagers have been discussed several times already. The last efforts in that direction were unfortunately perceived as a solution ready to go rather than a proposal to be discussed, and the project got quickly buried by a general resolution (GR). Even if that resolution invited for further discussion and a new proposal, the truth is that when someone s initiative is corrected by way of GR, it usually kills any motivation to go forward. Possible Evolution? On the Ubuntu side, the infrastructural changes were completed recently and they don t expect any further change in the near future. They do plan, however, to expand usage of those new features so that more teams benefit from the possibility to control upload rights on packages that are relevant to them, and so that more individuals developers apply to become Per-Package Uploaders on packages that they know very well. On the Debian side, a recent discussion on the debian-project list brought back the topic of the bad terminology and it was agreed that the New Maintainer process should be renamed into something else ( New Developer process has been suggested). But Christoph Berg Debian Account Manager and hence heavily involved in the New Maintainer Team suggested that Debian would be better off implementing the long-awaited membership changes before trying to update all the documentation. It would certainly imply some more vocabulary updates. Later in the discussion, he confirmed that membership reform is on the top of the TODO list of the new maintainer team (just after the rewrite of the nm.debian.org website). What can be expected from this reform? The following answers are my own guesses based on my experience of Debian, but the project hasn t decided anything yet.

• First of all: a new status for contributors that are not packagers. The tricky part will be defining the process to follow and the rights granted.
• Changes to the technical implementation of the DM status. The current implementation does not allow to give upload rights to a single DM if two are listed in the Uploaders field of a package (and both might not have the same experience for that package). Furthermore, it suffers from annoying restrictions like the inability to upload new binary packages.
• A change of the Debian constitution to integrate those new statuses is almost unavoidable.
• Other more invasive changes have been proposed like replacing the NM process by a simple designation by other DD, but it s unlikely to happen. The NM process can already be greatly simplified by the application manager if the applicant can show good testimonials from other developers and if he has a track record of real contributions (e.g. as witnessed by changelog entries in Debian packages).

Almost two years have elapsed since the previous efforts in that direction, the new maintainer team has recruited new members and is in a general better shape. Hopefully, the next episode of this saga will have a better outcome.

This article was first published in Linux Weekly News. In a comment, Mark Shuttleworth tried to explain how the Ubuntu community is being setup.

10 comments Support my work

After a long time, I decided to write again. I decided to start with software I wrote for my own usage that could be usefull for other people. I'll start with python-dvdvideo, a DVD-Video reader written in Python 3, and the reference tool dvd-video-backup-image, a generic DVD-Video dumper. Lets see, if this blog will see more postings in the future.

mksh was merged into Android (both AOSP and Google s internal master tree) in the night 24/25th August, and is expected to be the one shell to rule them all, for Gingerbread. mksh(1) now also has a cat builtin, for here documents mostly. It calls the cat(1) command if it receives any options. The shell is nevertheless smaller than yesterday because of improved string pooling. There s another reason to use the MirOS OPTU-16 encoding instead of PEP 383, on which I already wrote: try passing a wide-char filename to a function such as MessageBoxW, or create a filename on a system using wide chars, such as FAT s LFN or ISO 9660 s Joliet, or one that only allows Unicode (canonically decomposed u out of all things) like HFS+. OPTU-8 at least maps to somewhat reserved codepoints (would, of course, be better to get an official 128 codepoint block, but the chance s small of getting that in the BMP). Still. Oh well, the torrents. I ve remade them all, using one DHT seed node and OpenBitTorrent as tracker and put them on a very rudimentary BT page that will be completely redone soonish. Please re-download them. I currently do not believe f.scarywater.net will return. Finally, I fell victim to a selling-out and may have just bought a Windows Mobile 6 based phone (Glofiish X650) and an SDHC card and an extra battery with double capacity. Well, at least it s said to run CacheWolf well. I still would like to have something like Interix, Cygwin, UWIN, coLinux, or maybe some qemu-for-WinCE variant that runs Android, Maemo, Debian/armhf (or armel or arm) at near-native speed (and is usable the device sadly doesn t have a hardware keyboard, but it comes with SiRFstar GPSr). It only has 64 MiB RAM, like the Zaurus SL-C3200 and the jesusPhone, though. Any chance to get MirWorldDomination onto that device as well?

My last post discussed the year-to-year budgeting of DebConf. This post discusses what makes budgeting difficult within one particular DebConf. Since every DebConf is unique in its arrangements, the particular difficulties always vary year-to-year. For example, DebConf10 was easy in that Software in the Public Interest was in the same country so that we had easy access to bank accounts, but more difficult venue payment logistics. I'll use DebConf10 as an example below.
For DebConf10, we get our venue "for free" thanks to the support of the Columbia Computer Science department. However, we had to pay for guard costs after building hours, and custodial costs. For custodial costs at least, we had to go through many layers of bureaucracy, and people kept insisting it would be more than they quoted. (It ended up being about half, since DebConf attendees were so responsible!)DebConf sponsors many attendees. This means that all their food and accommodation costs are paid by us. We have sponsored registration and reconfirmation deadlines to set a maximum of the number of people we have to sponsor, but people are continually dropping out and it's hard to know just how many people to reserve for. Sponsored people won't always eat every meal with us, and usually won't decide until the day before - so figuring out food amounts is hard, too. Furthermore, we have unsponsored people who will want food and accommodations (paying themselves) which we must somehow plan for.Different venues operate on different payment rules. This year, CU Housing was fairly strict on asking for attendee counts and room assignments two weeks in advance. Then, as time gets closer, they got more flexible, and in the end told us that they will, in fact, only charge based on number of people actually attending - a huge win for us. Similarly with CU Dining, we had to go through great lengths to make sure that we would pay only for meals we ate. At CU, food had to be paid in advance, but accommodation and other costs are paid afterwards.We have to guess how much will be spent on miscellaneous supplies once DebConf starts. We have to then decide how much to spend on extras such as the day trip or conference dinner, and how to sponsor those, if possible.Debian (and thus DebConf) has money held in trust in many currencies in different accounts. Different sponsors will pay to different currencies, depending on what is convenient for them. This means that we need to consider fluctuating currency conversion rates, and decide if and when to transfer money. In general, DebConf hasn't transfer money just to make sure the DebConf-tagged money gets spent first. Some surpluses are best left in other countries to help pay future travel sponsorship since it is expensive to move money out of the country. Some conferences may result in a net movement of money from USA to Europe (more donors in one, more expenses in the other), some the other way around.Travel sponsorship is in the form of reimbursement. These can take many months to have the documentation received from attendees and the reimbursements all sent out, and thus finalizing the budget and surplus for next year.The overall principle we've tried to stick to is plan for a balanced budget in the worst case scenario, and then be happy when it ends up better than that.
At the DebConf&Debian BOF, someone mentioned how budgeting for any (free software) conference is hard. I think that's certainly true. Some of the registration fluctuations could be made easier by being less flexible, but DebConf wants to serve our attendees even if it is a bit of extra work for us. Each DebConf will have its own ways budgeting is difficult, but things have always work out, and usually with a bigger surplus than we were expecting.Tags: debconf

Recently I was surprised to find that many of the rules I took for granted when dealing with an OpenPGP keyring, and the other activities associated with a web of trust, were new to some people I spoke to. These rules are born from a mixture of experience, accepted good practice, and wider reading, with a small dose of paranoia thrown in for good measure.

• Protect your secret keyring with file permissions. For GPG, your ~/.gnupg directory should not be readable by anybody else, including root (even though he could break in if he wanted). Mine is octal 700, and the secret keyring itself is 600.
• Create a revocation certificate, and keep online and offline copies (gpg --gen-revoke <keyid>). The revocation certificate is published to key servers by you in the event that you detect key compromise or loss. It s important that this is also well-protected, because the secret key is not required to upload it. Print a copy in bold and on good quality paper, so it will last a long time, and preferably keep them both off-site in a trusted location. Typing all those characters back in is a bore, but if your online copy fails it s better than being impersonated.
• Use a good pass-phrase, not a password. A pass-phrase is actually easier to remember than a string of random characters, without risk. It can be long enough to make brute-force attacks pointless, and if you re using the key a lot and can t be bothered to type it all the time, gpg-agent is a handy and safe tool. Your login password is not an acceptable pass-phrase for your secret key!
• Regularly refresh your public keyring from a well-connected keyserver. I detailed this in an earlier post; it s a case of calling gpg --refresh-keys once a week or so. This is the first line of defence against other people s keys being compromised, since without it you ll never know that your messages to them are now vulnerable. A well-connected server, like those in pool.sks-keyservers.net, matters since not all servers synchronise predictably.
• Rotate encrypting sub-keys regularly. This reduces the effect of a compromised key: if you rotate keys annually, a compromise only opens one year of mail. Small comfort, but every little helps. Don t delete the old keys though, just revoke them otherwise you won t be able to open mail from those senders who don t refresh their public keyrings.
• Keep your key offline and make a separated signing sub-key for day-to-day use. There isn t room to go into detail here, but you can export a signing sub-key with a relationship to your primary key material, so if it is compromised you can revoke it without losing all those carefully-collected signatures. The same goes for encrypting sub-keys. Adrian von Bidder has a guide to this, but he warns that it should be taken with a pinch of salt, so this isn t so much a rule as an interesting idea. I have not experimented with this yet.

And some rules about signing and signatures:

• Don t place too much store by signing parties. Parties are great for rapidly building a web of trust, but a part of that trust is to do with how the other party checks identities. I don t believe it s possible to establish that with just a few minutes chat and an identity check, so I never make a sig2 or sig3 on a key I met at a party. I m usually happy to do that later when I have an established relationship with the key holder, of course.
• Never upload your own signature to a key server. Apart from the fact that the key holder might not want their key published, you also have no way to prove that the key holder has access to the email address on their UID. It s much better to send the signature to them encrypted, which demonstrates that they the both key and can read mail at the address (the caff program is ideal for this).
• Give personal trust (the trustdb) carefully. Getting that message Good signature from in your mail client is really nice, but not at the expense of giving away trust where it is not deserved. In the same vein as not placing too much trust at signing parties, you should avoid the temptation to over-trust keys in your personal trustdb. Reputation on a mailing list is absolutely no substitute for observing the party taking care over their verifications when doing face-to-face signings.

Do you have other rules or guidelines that you use when dealing with keys and signatures?

DebConf continued until Saturday, but Friday the 6th was my last day as I left New York that evening. I m a bit late in getting this summary written up. Making Debian Rule, Again (Margarita Manterola) Marga took a bold look at the challenges facing Debian today. She says that Debian is perceived to be less innovative, out of date, difficult to use, and shrinking as a community. She called out Ubuntu as the elephant in the room , which is taking away from Debian. She insists that she is not opposed to Ubuntu, but that nonetheless Ubuntu is to some extent displacing Debian as a focal point for newcomers (both users and contributors). Marga points out that Debian s work is still meaningful, because many users still prefer Debian, and it is perceived to be of higher quality, as well as being the essential basis for derivatives like Ubuntu. She conducted a survey (about 40 respondents) to ask what Debian s problems are, and grouped them into categories like motivation and communication (tied for the #1 spot), visibility (#3, meaning public awareness and perception of Debian) and so on. She went on to make some suggestions about how to address these problems. On the topic of communication, she proposed changing Debian culture by:

• Spreading positive messages, celebrating success
• Thanking contributors for their work
• Avoiding escalation by staying away from email and IRC when angry
• Treating every contributor with respect, no matter how wrong they are

This stimulated a lot of discussion, and most of the remaining time was taken up by comments from the audience. The video has been published, and offers a lot of insight into how Debian developers perceive each other and the project. She also made suggestions for the problems of visibility and motivation. These are crucial issues for Debian devotees to be considering, and I applaud Marga for her fortitude in drawing attention to them. This session was one of the highlights of this DebConf, and catalyzed a lot of discussion of vital issues in Debian. Following her talk, there was a further discussion in the hallway which included many of the people who commented during the session, mostly about how to deal with problematic behavior in Debian. Although I agreed with much of what was said, I found it a bit painful to watch, because (ironically) this discussion displayed several of the characteristic people problems that Debian seems to have:

• Many people had opinions, and although they agreed on many things, agreement was rarely expressed openly. Sometimes it helps a lot to simply say I agree with you and leave it at that. Lending support, rather than adding a new voice, helps to build consensus.
• People waited for their turn to talk rather than listening to the person speaking, so the discussion didn t build momentum toward a conclusion.
• The conversation got louder and more dense over time, making it difficult to enter. It wasn t argumentative; it was simply loud and fast-paced. This drowned out people who weren t as vocal or willful.
• Even where agreement was apparent, there was often no clear action agreed. No one had responsibility for changing the situation.

These same patterns are easily observed on Debian mailing lists for the past 10+ years. I exhibited them myself when I was active on these lists. This kind of cultural norm, once established, is difficult to intentionally change. It requires a fairly radical approach, which will inevitably mean coping with loss. In the case of a community, this can mean losing volunteer contributors cannot let go of this norm, and that is an emotionally difficult experience. However, it is nonetheless necessary to move forward, and I think that Debian as a community is capable of moving beyond it. Juxtaposition Given my history with both Debian and Ubuntu, I couldn t help but take a comparative view of some of this. These problems are not new to Debian, and indeed they inspired many of the key decisions we made when founding the Ubuntu project in 2004. We particularly wanted to foster a culture which was supportive, encouraging and welcoming to potential contributors, something Debian has struggled with. Ubuntu has been, quite deliberately, an experiment in finding solutions to problems such as these. We ve learned a lot from this experiment, and I ve always hoped that this would help to find solutions for Debian as well. Unfortunately, I don t think Debian has benefited from these Ubuntu experiments as much as we might have hoped. A common example of this is the Ubuntu Code of Conduct. The idea of a project code of conduct predates Ubuntu, of course, but we did help to popularize it within the free software community, and this is now a common (and successful) practice used by many free software projects. The idea of behavioral standards for Debian has been raised in various forms for years now, but never seems to get traction. Hearing people talk about it at DebConf, it sometimes seemed almost as if the idea was dismissed out of hand because it was too closely associated with Ubuntu. I learned from Marga s talk that Enrico Zini drafted a set of Debian Community Guidelines over four years ago in 2006. It is perhaps a bit longand structured, but is basically excellent. Enrico has done a great job of compiling best practices for participating in an open community project. However, his document seems to be purely informational, without any official standing in the Debian project, and Debian community leaders have hesitated to make it something more. Perhaps Ubuntu leaders (myself included) could have done more to nurture these ideas in Debian. At least in my experience, though, I found that my affiliation with Ubuntu almost immediately labeled me an outsider in Debian, even when I was still active as a developer, and this made it very difficult to make such proposals. Perhaps this is because Debian is proud of its independence, and does not want to be unduly influenced by external forces. Perhaps the initial growing pains of the Debian/Ubuntu relationship got in the way. Nonetheless, I think that Debian could be stronger by learning from Ubuntu, just as Ubuntu has learned so much from Debian. Closing thoughts I enjoyed this DebConf very much. This was the first DebConf to be hosted in the US, and there were many familiar faces that I hadn t seen in some time. Columbia University offered an excellent location, and the presentation content was thought-provoking. There seemed to be a positive attitude toward Ubuntu, which was very good to see. Although there is always more work to do, it feels like we re making progress in improving cooperation between Debian and Ubuntu. I was a bit sad to leave, but was fortunate enough to meet up with Debian folk during my subsequent stay in the Boston area as well. It felt good to reconnect with this circle of friends again, and I hope to see you again soon. Looking forward to next year s DebConf in Bosnia

This post concerns Romanian politics, internal affairs and improper direction of public funding for new hideous churches in spite of education, culture, health, technic development and old monuments. Thus I will write this in Romanian. Curious foreigners can try to read the text via Google's translation.

---

Din cauz c suntem n secolul XXI i consider c e o prostie imens s b g m bani n biserici n detrimentul educa iei, culturii, s n t ii, dezvolt rii tehnice i a vechilor monumente, iar politicul din Rom nia pare dornic s dea bani cultelor, am ajuns la concluzia c este cazul s -i scriu reprezntantului meu (teoretic) n Parlament, Deputatul Florin Iordache. Am aflat de ce colegiu apar in uit ndu-m aici i apoi n lista oficial cu deputa ii.




I-am trimis textul de mai jos:

M numesc Petri or Eddy i sunt unul dintre cei pe care i reprezenta i n Parlamentul Rom niei. Este pentru prima dat c nd scriu unui parlamentar care m reprezint n conducerea statului rom n i o fac pentru a-mi exprima n mod clar i r spicat ideile i opinia n ceea ce prive te subiectul pe care l voi discuta mai jos. Am 30 de ani, sunt programator, am muncit i mi-am pl tit taxele de c nd am fost angajat, din anul 4 de facultate p n n prezent, adic de vreo 6-7 ani. Nu, acest mesaj nu este un strig t de ajutor, nu a tept pomeni, nu am milogit niciodat , mereu am muncit de i v d c pentru unii parazitismul fiscal a devenit un mod de via . Din acest motiv sunt revoltat.

Sunt revoltat pentru c :
- de i pl tesc taxe i impozite care ajung la peste 60% din venitul brut, nu primesc n schimb nici un fel de servicii, nici un fel de infrastructur , nici un fel de respect, nici un fel de eficien
- de i lucrez de ceva timp, am observat c pe unde am lucrat competen a i performa a erau o necesitate; n aparatul de stat nu este cazul
- de i sunt destui ca mine care pl tesc taxe i impozite, vocile noastre sunt ignorate i banii no tri sunt arunca i pe fereastr de cei ce administreaz fondurile colectate.

Domnule deputat sunt revoltat c de 15 ani de zile dispar n medie aproximativ 4 coli zilnic i apare, tot n medie, o biseric la fiecare 2 zile, iar asta se nt mpl cu accep iunea aparatului politic. Spitalul din Caracal, ca orice alt spital din Rom nia, e prost dotat, nu exist personal suficient, nu are fonduri pentru medica ie pentru pacien i, pe scurt, este un dezastru care e pe cale s se nt mple. i cu toate astea, banii se duc spre biserici. Se fac dona ii de coli i terenuri c tre biseric , n mod ilegal i abuziv chiar n jude ul Olt.

Ultima perioad n care religia a condus lumea s-a numit Evul Mediu i cred c orice om care a tr it m car 5 ani n secolul XXI poate s observe c nu religia ne-a adus mari beneficii, ci tiin a i tehnologia. n Evul Mediu tratamentul se f cea prin s nger ri , t ieri sub limb , scoaterea argintului viu i tot felul de alte supersti ii f r nici un efect pozitiv sau chair cu efecte negative.

ntre timp umanitatea a progresat i am descoperit medicina, curentul electric, am explorat universul, am aterizat pe Lun , am pus zeci de sateli i artificiali pe orbit , am aflat foarte multe despre univers i lumea care ne nconjoar , am inventat noi materiale (plasticul, p nzele impermeabile, kevlarul), am investigat lumea f r idei preconcepute dup metoda tiin ific , iar lucrul acesta ne-a mbun t it via a n toate aspectele ei. Sperant de via a crescut de la aproximativ 30-40 de ani n Evul Mediu, la 70-80 de ani n prezent, totul datorit tiin ei aplicate. Datorit tehnologiei i tiin ei pot s v scriu aceste cuvinte i tiu c vor ajunge la dumneavoastr , nu datorit unor incanta ii sau ritualuri, nu datorit telepatiei, de i mediul sta de transmisie se apropie foarte mult de ceea ce define te ca fiind telepatie :-) . Cu toate astea, unii consider c religia trebuie finan at pentru c e religie, nici m car pentru c ar avea programe sociale, contribu ii cuantificabile reale, nu, doar pentru c este religie.


Am citit foarte multe articole din pres , articole bine documentate, i am senza ia c tr iesc ntr-o lume incon tient c nd v d cum banii care ar trebui s ajung n drumuri, coli, spitale, cercetare, medicamente, programe sociale cu real impact, ajung n noi i noi biserici de beton n timp ce monumentele istorice, bisericile din lemn, m n stirile cu adev rat valoroase sunt l sate n paragin . Asist cu o senza ie de dezgust continuu la felul n care ne batem joc de cei ce ne salveaz vie ile, medicii, de cei ce ar trebui s ne fac educa ia, profesorii, de cei ce ne sting casele dac iau foc, pompierii, i, de felul n care ridic m misticismul religios la rang de virtute. Este de-a dreptul jignitor i aberant ca alfabetizarea tiin ific n secolul XXI s fie at t de joas nc t s avem 42% din popula ie care cred c Terra este centrul universului, s avem oameni care cred c astrologia este tiin ific , s NU avem nici m car o universitate n top 500 n lume, este jignitor s fim n permanen n coada tuturor clasamentelor pozitive i n fruntea tuturor celor negative.

Recent money.ro a publicat un articol n care esitma foarte conservator c averea Bisericii Ortodoxe Rom ne se nv rte la peste 3 miliarde de euro, are scutiri de impozite, are zeci de afaceri i cu toate acestea, statul continu s scuteasc cultele de impozite, ba chiar le ofer bani ntr-una. La o asemenea avere nu cred c mai poate fi vorba de necesitatea finan rii de c tre stat. Oamenii pot decide s doneze direct c tre bisericile lor bani i nici nu mai implic pierderile inerente ce apar datorit administr rii fondurilor de c tre stat.


Statul nu este un organ aparte, statul trebuie s munceasc pentru mine, cet eanul, iar eu sunt mpotriva acestui tip de batjocorire i napoiere voluntar a noastr ndreptat mpotriva noastr . Alexandru Ioan Cuza a secularizat averile m n stirilor nchinate celor de la muntele Athos, deci unor ter i extreni rii, a a cum afl m din scrierile istoricului A.D. Xenopol, deci nu exist nici o obliga ie a statului s finan eze o institu ie anacronistic :

A.D. Xenopol Domnia lui Cuza Vod Vol.I , CAP. VIII. AI doile minister Cogalniceanu Secularizarea , pagina 291:

Nu vom atinge de c t mprejur rile care au condus la redob ndirea averilor, ajunse n st p nirea c lug rilor str ini, ating nd chestiunea nchin rei m n stirilor p n ntene c tre acele din R s rit, numai ntru c t va fi de nevoie, spre a n alege m sura seculariz rei nsu i.

Din aceste motive i multe altele, deoarece sunte i i reprezentantul meu n Parlamentul Rom niei, v cer ca s vota i pentru proiectul de lege ini iat de domnul Prigoan n ceea ce prive te t ierea finan rii personalui clerical de c tre stat i c t i a altor legi care ar putea duce la eliminarea privilegiilor pe care le au cultele, n condi iile n care singurul motiv real i corect pentru care o entitate ar putea beneficia de scutiri de taxe sau privilegii fiscale sunt doar cele ce nu urm resc interesul financiar i, totodat , au un impact social cuantificabil n mod clar.


Dac dori i, a fi bucuros s v r spund la eventualele ntreb ri sau neclarit i n ceea ce am scris, dac este nevoie.

V mul umesc anticipat!

L-am trimis joi, nc n-am primit r spuns de nici un fel. Pasul doi e s sun. M car s nnebuneasc dac tot sunt nesim i i. A a c , pute i afla de ce colegiu apar ine i i apoi pute i identifica pe cel/cea ce v reprezint n Parlament. Scrie i-le, suna i-i, a venit momentul m car s se enerveze, dac nu s - i fac m car o poleial de datorie.

There is apparently some MS-Windows software for navigating light aircraft in Australia. It takes input from a GPS device and knows the rules for certain types of common tasks (such as which direction to use when approaching an airport). My first question when I heard of this was so if the Windows laptop crashes does your plane crash? . But I ve been assured that paper maps will always be available. The requirement is for a touch-screen device because a regular laptop in the open position won t leave enough room for the control stick. So the question is, what is the best touch-screen Windows laptop? It must be relatively rugged spinning media for storage is unacceptable due to the risk of damage in turbulence, it should be relatively cheap (less than $1000), and can apparently have a somewhat low resolution for the screen. The pilot who asked me for advice on this matter is currently thinking of the ASUS Eee T91 which runs Windows XP home, has 16G of solid-state storage and a 1024*600 screen. I am concerned about the reliability of that system as the rotatable screen design seems inherently weak. The Smartbook concept sounds appealing, I don t expect that you would want to wait for a typical OS to boot while flying a plane. But those devices mostly use ARM CPUs and thus can t run MS-Windows. One particularly interesting device is the Always Innovating Touchbook [1] which has a detachable keyboard which would be handy for non-airline use. Unfortunately it seems that Always Innovating aren t doing production at the moment, they say The current Touch Book production is in stand-by and will resume in the summer when we will release our newest and craziest innovation well summer is almost over in the northern hemisphere so I guess that means there won t be anything from them for another 9 months. A device such as an iPad would also be a good option for looking at static documents. The pilot is considering using a MS-Windows PC to generate images and then viewing them on such a device. But he s not really enthusiastic about it. Are there any good and cheap touch-screen devices that run MS-Windows? Are there any particularly noteworthy PDF reader devices which would be better than an iPad for viewing maps while flying a plane? Is it possible to run a MS-Windows application that uses a GPS under Wine on a Netbook?

• [1] https://www.alwaysinnovating.com/touchbook/

Many team maintained packages in Debian are maintained in Subversion which makes a lot of sense if people agreed on a common workflow. If you want to use git to work on these packages you can still do so with a bit of configuration without changing anything for the other team members. Let's take system-config-printer as example. git-svn can be used to checkout the svn repository:

git svn clone svn+ssh://svn.debian.org/svn/pkg-gnome/ -T packages/unstable/system-config-printer -t tags/system-config-printer system-config-printer

Since the pkg-gnome team keeps all the packages in one huge SVN repository and splits the directories by release first and then by package the above command uses -T to point git-svn to system-config-printer's trunk and -t to point it to the tags directory. In simpler repositories where trunk, branches and tags are subdirectories of the same base directory using --stdlayout instead is enough. Since in SVN based packaging the upstream sources usually aren't kept in the repository git-buildpackage needs to know where to find them and how to combine things in the build-directory:

cd system-config-printer
cat <<EOF >.git/gbp.conf
[git-buildpackage]
# Build in a separate build-area
export-dir = ../build-area/
# Look for tarballs in ../tarballs
tarball-dir = ../tarballs/
# Overlay the upstream sources on top of it
overlay = True
# Don't use pristine-tar
pristine-tar = False
# Compression type of the tarball
compression = bzip2

Like with svn-buildpackage the orig-tarball is expected to be found in ../tarballs where you should put it now e.g. using the get-orig-source target of debian/rules (yes, git-buildpackage should support this implicitly). You can then work on the package as usual using all the nifty git commands like git-rebase, etc. and build the package (in this case using git-pbuilder):

git-buildpackage --git-pbuilder

or if you don't want to export the current branch's HEAD of your git repository but your working copy (which might contain uncommitted changes) to the build-area instead use:

git-buildpackage --git-pbuilder --git-export=WC

The built packages can then be found in ../build-area. Once the package is ready pushing the changes into the SVN remote repository is as simple as:

git svn dcommit
git svn tag -m"Tagging system-config-printer (1.2.3-0.2)" 1.2.3-0.2

The last command appropriately tags the new version. This saves a bit of typing. In order to fetch changes others have made use:

git svn rebase

DebConf10 ended 2 weeks ago, I m back in Bosnia and I needed some time to recalculate everything that happened to me in last month This was my third time in NYC, and NYC as a city never left me empty handed, in every possible sense! And am seriously considering option of moving back one day, whether to get my Masters/phD or just do work we ll see what future holds for me DebConf10 I was in organization team for DebConf10, but if you put me aside, what s particularly interesting is that there was a total number of 7 Bosnians on DebConf10, two of which were government officials. I must note this wasn t our complete team, and what s most important of all is that they all pretty much volunteered as much as they could, of course, besides good will to help Debian, but also to at least somehow prepare themselves for organization of DebConf11. It s also worth noting that this was their first DebConf, and I as a leader of the team must say I m proud on how well they performed. I m sure by being highly active in volunteering they have learned as much as they could when it comes to how it s done and were able to see good and bad sides of DebConf10 organization team. Of course, I d also like to thank DebConf10 team for their superb work, perfect Venue selection, their hospitality and being incredibly friendly and helpful to all of us. As I said in one of my lectures, it s kinda unwritten rule that every next DebConf has to top the previous one, and that being said it s going to be almost impossible to compete with this year bid, but being Bosnians we re up for the challenge My DebConf10 Pictures: Semi-private album FaceBook public link (no registration required) DebConf11 DebConf10 was busy period for all of us, but I don t want to start complaining since even though we ve done enormous amounts of work so far, the real challenge lays ahead of us. With DebConf10 behind us, the thing we should process now is it s our turn now, we re next Before anything, I d like to thank Government of Republika Srpska for their full financial support, which was one of the preconditions to even get this bid. With their full support + sponsors, we ll be able to get great amount for sponsorships, for you to come to Banja Luka from the most remote places, and also in case you need visa for them to help you in getting one. Government support is just too precious in any way you want to take it. We would also like to invite you to DebConf11 in Bosnia (Banja Luka) next summer, we also invite all of you to our communication channels (mailing list, irc) since we would really like to get involved as many people as we can. Besides all of you enjoying DebConf11 next year, we would like you to help us in giving directions since we re a young team Besides Debian people, I d like to invite anyone who think he/she could help, or want to get involved, especially individuals/organizations/LUG from whole region! It s also important to stress that in all of our communication means, we do speak English, so please do not hesitate if you have any sort of question/suggestion/whatever. For those interested in next DebConf11, most important page you should follow is our wiki page, where you can find all information and which we keep updated in timely manner: http://wiki.debconf.org/wiki/DebConf11/BanjaLuka Communication/Links Languages we officially support are: English, Bosnian, Serbian and Croatian Mailing list:
http://lists.debconf.net/mailman/listinfo/debconf11-bosnia IRC:
#debconf11-bosnia on irc.debian.org / irc.oftc.net Twitter:
#debconf11 tag
http://twitter.com/absinthesyringe (shameless self promotion ) Facebook:
Official DebConf11 FaceBook group DebConf10 Adnan Hodzic DebConf11 in Bosnia (Introduction and Invitation):
Lecture video high quality (205mb)

See you next year!

After reading Do It Tomorrow, I was inspired to try some of the techniques that Mark Forster proposes. I commented in the review about the closed list system, which I'm still mostly using with some success. But I also started playing with the initiative slot. In his system, the initiative slot is first thing in the morning each (eligible) morning, which is used for a special project that you want to make forward progress on. There are several criteria for choosing a task for the initiative slot. One of the strongest is dealing with a backlog. Since I'd been feeling guilty about the backlog of Debian Policy work that had built up, that seemed like a good choice. I picked up Debian Policy backlog clearing as my initiative starting at the beginning of June after the AFS and Kerberos Best Practices Workshop, with a goal of getting the open bug count below 100. This has been very instructive, both from a time management perspective and from a Debian Policy perspective. Here are a few things that I learned on the Policy side:

• The open bugs against Debian Policy by and large represent real work that we should tackle in the Policy document. They're not all fully thought-out proposals, but I didn't find much that I could simply close (apart from a set of bugs requesting additional common-licenses, once I had an analysis tool). From time to time, we've thought about timing out old bugs that have not made any forward progress, but this experience leads me to think that would serve us poorly.
• It takes me about an hour on average to resolve a Policy bug. That includes all the fast five-minute typo bugs (well, ten minutes; I need to improve my Policy workflow to be a bit more efficient in the commit process). Some bugs take easily ten hours or more, such as #504880. I think this is on par with or a bit slower than resolving typical bugs in compiled software I package, and much slower than Lintian, where bugs take about a half-hour on average to resolve, I think.
• Most Policy bugs are making no forward progress because no one has written wording and started iterating on that wording. There are some exceptions, and this process seems to go better for me than it has for some other contributors, but if I pick up a bug and start drafting wording changes, I can usually bring the bug to resolution in about a week, often less. This implies to me that our process for making Policy changes is reasonable but we need more targetted help. This was discussed at the BoF at DebConf and on the list afterwards and I now have three people who have volunteered to supply some of that targetted help and need to get more organized to make use of that offer.
• The normative (rule-affecting) versus informative (informational and documentary) distinction in Policy is tricky and unclear, and most bugs end up becoming normative. While I think our system for dealing with normative bugs is reasonable, this does slow down fixes. I can commit informative changes without review and then tweak them if people object, and it would be nice to fix more wording issues that way, but it's hard to avoid getting tangled up in normative issues.

Things I learned on the time management side:

• I didn't work from a closed list, which is frowned on for dealing with backlogs. I'm not sure if this ended up being a problem or not. The correct approach, in theory, is to work out a system for dealing with new incoming work, make sure that system is in place, and then process backlog independently of all new work. I never did that. I never separated out the backlog into a closed list that would get smaller. I suspect I should have, although I'm not sure of a good way to do that in the BTS in an area where we're already using usertags for another purpose.
• The point of the initiative slot is to unblock something or to clear a backlog, but the initiative slot is supposed to rotate. It's not a good way to deal with something that's going to take a long time to resolve. In retrospect, I was excessively ambitious with my goal. Even apart from not working from a closed list, I can average about a half-hour a day on the initiative slot, which at an hour a bug and a starting point of 160 bugs would mean 120 days to reach my goal. That's too long for one task to dominate the initiative slot.
• The initiative slot really works. We brought the bug count on Policy down from about 160 to 126 over the course of those two months, and I don't think much changed other than my level of activity and of course the normal effect of other people getting more involved when someone is visibly doing work. The bug graph is impressive. It's very obvious when I started working, and also very obvious when the ramp-up to DebConf started and I stopped having time to have a daily initiative slot.
• Doing something that's unrelated to my day job in the initiative slot creates an odd tension, and I'm not sure how to deal with that. On one hand, one of my standard time management failure modes is to spend too much time on work and not enough time on non-work tasks. On the other hand, that's partly because I'm hypersensitive to not focusing enough on work and overcompensate, and taking time each morning to do non-work things doesn't help that. I'm not yet sure what to do about this.
• One of the failure modes of initiative slots that I'm already noticing is that when I move something out of that slot, rather than continuing to work on it at a normal pace, I have a tendency to stop working on it altogether. This doesn't work, particularly if it was used for backlog clearing. I just build up another backlog and then have to use the slot to clear it again. This means I need to give more attention to my time management outside of that slot.

I stopped using the initiative slot while travelling and haven't gotten back into the hang of regular time management since I've gotten back. I haven't yet decided whether to leave Policy work in the initiative slot for right now but change the goal, or whether to swap it out for something else. I'd like to keep momentum, but I'd also like to start using that slot for other things. Still pondering.

Debconf10 has come and gone and its effects are still with me. This is not so surprising as this year I was not only a participant but on the local team. When we first started to hold in person meetings, I was a totally overwhelmed knowing that with each passing month, the demands on my time would grow and then explode. Then I got news that I landed a year long fellowship that would relieve me of all teaching for the 2010-2011 year and was able to breathe a little and enjoy what I don t get to do all that often in my academic job: work collectively. As Debcamp started, I was not sure whether I would enjoy the conference given that I had to pay attention to the nuts and bolts of the conference. I got my answer the first day as folks started to pour in hack lab. Due to the pressure cooker nature of my job, I did not attend the last two Debconfs. Seeing friends that I only see during these fairly intense weeks stirred up a lot of inside of me. It felt really good to be back . This was also my first Debcamp, and now I understand why people enjoy it so much. It gives you a chance to meet new folks instead of gravitating to those you already know and still get some work done. It also allows the orga team to hammer out some final details and test run some stuff before the swarm descends into the venue. One of the things I enjoyed the most during the week were the take out dinners. Logistically it was a bit of nightmare but it aligned very much with the culinary culture of NY and we had some nice outdoor picnics on the Columbia campus and one in Riverside Park. The pace picked up a lot during Debconf, which we kicked off with Debian Day. We managed to get a lot of NYC folks it was one of the best attended Debian Days. One of the highlights was Gale Brewer s talk. She is a public servant in the full sense of the word, dedicating thirty years of her life to this job and really understands what technology can and cannot due for New Yorkers. It was very inspirational talk. Aside from a few moments, such as the day trip and the wine and cheese party (btw, party does not capture the quantity of cheese featured and consumed ), Debconf itself has already become a bit of a blur, it all happened so quickly and under sleep deprived conditions. Nearly every vessel of time was filled, overflowing, at times bursting. I enjoyed a number of the talks Eben Moglen s, Joey Hess s CUT proposal, Marga s talk on Making Debian Rule, Zack s Bits from the DPL, the derivates BOF, and others. I also enjoyed preparing and moderating the welcome talk, which is not yet online (only the last bit is and the sound is distorted so I sound like a mouse). My sense is that the relationship between Ubuntu and Debian is improving, which is important. We need alliances and allies, not foes in the world of F/OSS (watch Eben s talk to get a sense of why this is so). I mostly ate on campus but managed two African based dinners with friends (Ethiopian and Senegalese) and only wished we had a little more time to talk. The late nights in the Carman lounge were pretty epic, if somewhat collegiate and during the end, hot and humid. Here are a few of the pictures I managed to take. I love Debconf for it so perfectly conjoins the comfort of the familiar with the thrill of the new. For those who experience it in its full intensity, it can be an artistic moment, at least in the way described by the poet John Keats: The excellence of every Art is its intensity, capable of making all disagreeables evaporate, from their being in close relationship with Beauty . . . And now, I am, of course, totally beat

Debconf10 has come and gone and its effects are still with me. This is not so surprising as this year I was not only a participant but on the local team. When we first started to hold in person meetings, I was a totally overwhelmed knowing that with each passing month, the demands on my time would grow and then explode. Then I got news that I landed a year long fellowship that would relieve me of all teaching for the 2010-2011 year and was able to breathe a little and enjoy what I don t get to do all that often in my academic job: work collectively. As Debcamp started, I was not sure whether I would enjoy the conference given that I had to pay attention to the nuts and bolts of the conference. I got my answer the first day as folks started to pour in hack lab. Due to the pressure cooker nature of my job, I did not attend the last two Debconfs. Seeing friends that I only see during these fairly intense weeks stirred up a lot of inside of me. It felt really good to be back . This was also my first Debcamp, and now I understand why people enjoy it so much. It gives you a chance to meet new folks instead of gravitating to those you already know and still get some work done. It also allows the orga team to hammer out some final details and test run some stuff before the swarm descends into the venue. One of the things I enjoyed the most during the week were the take out dinners. Logistically it was a bit of nightmare but it aligned very much with the culinary culture of NY and we had some nice outdoor picnics on the Columbia campus and one in Riverside Park. The pace picked up a lot during Debconf, which we kicked off with Debian Day. We managed to get a lot of NYC folks it was one of the best attended Debian Days. One of the highlights was Gale Brewer s talk. She is a public servant in the full sense of the word, dedicating thirty years of her life to this job and really understands what technology can and cannot due for New Yorkers. It was very inspirational talk. Aside from a few moments, such as the day trip and the wine and cheese party (btw, party does not capture the quantity of cheese featured and consumed ), Debconf itself has already become a bit of a blur, it all happened so quickly and under sleep deprived conditions. Nearly every vessel of time was filled, overflowing, at times bursting. I enjoyed a number of the talks Eben Moglen s, Joey Hess s CUT proposal, Marga s talk on Making Debian Rule, Zack s Bits from the DPL, the derivates BOF, and others. I also enjoyed preparing and moderating the welcome talk, which is not yet online (only the last bit is and the sound is distorted so I sound like a mouse). My sense is that the relationship between Ubuntu and Debian is improving, which is important. We need alliances and allies, not foes in the world of F/OSS (watch Eben s talk to get a sense of why this is so). I mostly ate on campus but managed two African based dinners with friends (Ethiopian and Senegalese) and only wished we had a little more time to talk. The late nights in the Carman lounge were pretty epic, if somewhat collegiate and during the end, hot and humid. Here are a few of the pictures I managed to take. I love Debconf for it so perfectly conjoins the comfort of the familiar with the thrill of the new. For those who experience it in its full intensity, it can be an artistic moment, at least in the way described by the poet John Keats: The excellence of every Art is its intensity, capable of making all disagreeables evaporate, from their being in close relationship with Beauty . . . And now, I am, of course, totally beat

My project. This part of this post assumes that the reader has read my last post. This post contains embarassing news: In my effort to organize the patches to make it easier to run a script that benchmarks each change to see how it affects performance, I made a very simple mistake, which mostly would disable Immix. This was done in the first patch of the stack, so all patches were compromised. I noticed this while I was attending Simon Marlow s request of measuring how many lines are being freed and allocated, and notice that it was none. My error was simply to set two different constants with the same value: BF_MEDIUM and BF_SWEPT. After the correction, I noticed two more errors that were introduced in this period, and that were not corrected because, as Immix was not activated, they were not causing any harm. Now, with everything in the stage I was before: a memory corruption that happens ocasionaly only in the nofib/real/maillist benchmark. As described in this link, I ve tried already a lot of different techniques to debug this one, but it s being hard. In the mean time, I m measuring again the stack of patches, in a lab using the complete nofib (except for nofib/real/maillist) and nofib/gc, and in my laptop only fibheaps, fulsom and constraints, from nofib/gc, which were used in my last post.

---

Debconf was great. I ve stayed in New York with my family doing tourism for some days before it, and New York city is fantastic. A very diverse architecture and people from all around the world. It s really impressive. I arrived in DebCamp on Friday and it was not easy for me to find where to check-in, and where to go after unpacking my stuff. I assume I haven t paid much attention to the e-mails explaining this, but I tried to search them when I got there, without success. It was good, on the other hand, to walk on Columbia searching: it s a very nice campus, not comparable to anything we have here in Brazil. During DebConf I tried to help the organization as much as I could, being Talk-meister in some talks, helping a little bit with food organization and participating in the video team. All of this was very fun. There were some talks that I couldn t attend to, and I watched the videos, or part of them, here on Monday: Making Debian rule again, FreeBSD, Anti-features I still want to watch some, like the Analysis of Debian mailling lists using machine learning, and there are others that I wanted to see but are not recorded, like the one about notmuch. I got my key signed by a lot of people, which certainly was not the case before, and it the GPG best practices BoF was great. And there was the proposal to host DebConf12 in Brazil, maybe in my city, Belo Horizonte. Which reminds me: Tomorrow Betim will host the Debian Day BH, in parallel to another event: FSL-BH. A BoF related to the organization of DebConf12 in Belo Horizonte is scheduled. See you there.

This blog post is actually a response to a talk that was given at the debconf last week. It was marga's talk about Making Debian Rule, again. Now that the beta versions of the talks are available for download I'm able to proper quote what I want to respond to: Is there a reason why we haven't yet updated the website?, perhaps someone can answer. I feel the need to respond to this as I am the main person driving that effort. Unfortunately the question was asked in a talk with no-one involved in that work around instead of addressing those people directly, and the question wasn't brought to my attention before the talk so that I could have provided an answer to offer in the presentation already. Also, as disclaimer, this is my personal story for it and doesn't need to get shared by the other people involved. I hope it can be seen as an answer anyway. As a little of background, Kalle's proposal went a long path before even I found out about it. I was simply in awe in several ways about it because it wasn't just a great mockup of the page (which it actually is, IMHO) but was accompanied by thoughts about not only the main site but also about several sub sites. Also, it was accompanied by patches, so it was seemingly ready to get deployed right ahead. I started working on it, got accused of being discouraging while doing that, got told that it would require a proper vote for a decision and can't happen just as, but those are just the Debian way of communication. I nevertheless did set up several test sites for some over the time to play with it. Some did work out better (like the git one, though this one came last and Kalle improved the CSS over time a fair bit), some weren't ready yet (like wiki, missing e.g. the coloring for the version diff, or the packages one where the separation between the different sections isn't that visible yet). Time passed, other things demanded their attention too. Like the thing where our system administrators did send me a request along about a new www-master server that needs to get set up from scratch. Given that the documentation about the required packages for the website was lacking a fair bit (to say the least) it did require a lot of attention, especially when doing things from scratch the wish to document the dependencies properly is just natural. There are still some issues with that as can e.g. be seen on this page in the empty table at the bottom. The same issue also appears on my testsite for the new design. The last part though is currently the biggest blocking issue for both efforts. There is no way to move forward with either without having that addressed. Simon Paillard did a great job on helping the move along so far, keeping the thread about the server move requirements that I started on the debian-www mailinglist updated with information about what's still pending. Unfortunately Kalle, Simon and me are also facing some private time constraints (amongst other duties that require attention) which weren't helping to move forward at a bigger pace. Unfortunately not very many people actually has shown interest in helping out neither, after all it's easier to go and ask questions about why it's not done yet to the completely wrong audience. My plan is to switch many sites at the same time instead of one after the other simply for the effect but also for less distraction for our users, including less people repeatedly pestering about when this or that site gets done, too. At least we need a final discussion on what should go into the header links and what should be at the bottom before a switch can be made anyway. And for some there is still the opinion that such a switch is nothing that we are rightfully allowed to decide without a vote, so that's also part of the reason to not just deploy it. I hope this answers the question to some extend and like said, if only I would had been addressed about this before the talk was given an answer to it would had been ready for presentation right ahead instead of having a pretty terse statement getting relayed through IRC (thanks, Yoe!) because I was fortunate enough to be around and watching the talk at that time. Feel free to discuss it further or offer your help on debian-www, especially if you are familiar with working on CSS files.

/debian permanent link Comments: 3

As far as I recall the standard for naming Linux Ethernet devices has always been ethX where X is a number starting at 0. Until fairly recently the interface names were based on the order that device drivers were loaded or the order in which the PCI bus was scanned. This meant that after hardware changes (replacing network cards or changing the BIOS settings related to the PCI bus) it was often necessary to replace Ethernet cables or change the Linux network configuration to match the renumbering. It was also possible for a hardware failure to cause an Ethernet card to fail to be recognised on boot and thus change the numbers of all the others! In recent times udev has managed the interface naming. In Debian the file /etc/udev/rules.d/70-persistent-net.rules can be edited to change the names of interfaces, so no matter the scanning order as long as an interface retains it s MAC address it will get the correct name or at least the name it initially had. One of the down-sides to the way this operates is that if you remove an old Ethernet card and replace it with a new one then you might find that eth1 is your first interface and there is no eth0 on the system this is annoying for many humans but computers work quite well with that type of configuration. I ve just renamed the interfaces on one of my routers by editing the /etc/udev/rules.d/70-persistent-net.rules file and rebooting (really we should have a utility like /sbin/ip with the ability to change this on a running system). I have decided to name the Ethernet port on the motherboard mb0. The PCI slots are named A, B, and C with A being the bottom one and when there are two ports on a PCI card the one closest to the left side of the system (when viewed from the front the right side when viewed from the read) is port 0 on that card. So I have interfaces pcia0, pcia1, pcib0, pcib1, and pcic0. Now when I see a kernel message about the link going down on one of my ports I won t have to wonder which port has the interface name eth4. I did idly consider naming the Ethernet devices after their service, in which case I could have given names such as adsl and voip (appending a digit is not required). Also as the names which are permitted are reasonably long I could have used names such as mb0-adsl, although a hyphen character might cause problems with some of the various utilities and boot scripts I haven t tested out which characters other than letters and digits work. I may use interface names such as adsl for systems that run at client sites, if a client phoned me to report Internet problems and messages on the console saying things like adsl NIC Link is Down then my process of diagnosing the problem would become a lot easier! Does anyone else have any good ideas for how to rename interfaces to make things easier to manage? I have filed Debian bug report #592607 against ppp requesting that it support renaming interfaces. I have also filed Debian bug report #592608 against my Portslave package requesting that provide such support although it may be impossible for me to fix the bug against Portslave without fixing pppd first (I haven t looked at the pppd code in question for a while). Thanks to Rusty for suggesting this feature during the Q/A part of my talk about Portslave for the Debian mini-conf in LCA 2002 [1].

• [1] http://www.linux.org.au/conf/2002/debiancon.html