What do you do when you have a technical question that you're embarrassed to ask? The first Sunday of Debconf, I led a birds of a feather (BoF) session called Debian for Shy People. The conference team scheduled it on "Debian Day," a pre-conference day that was open to the public and still had plenty of Debian Developers in attendance. I just uploaded the slides to the "Penta" page for the talk. I led it because of my own experience. In 2004 or so, I saw Debian as the cool kids' club, that awesome project that I wished I could be a part of. By 2006, I managed to get over myself, read the New Maintainer's Guide, and find a way to get involved. As of mid 2009, I am a full-blown Debian Developer. I have real ultimate power. But I sometimes do still feel hesitation akin to "Imposter Syndrome". (A bunch of people at Debconf didn't really believe I'm "shy," since I asked a lot of questions at the conference. At core, I don't naturally believe that the things I say are worth hearing, but I patch over this hesitation. Sometimes I speak too much, and then I feel ashamed of burdening everyone. But anyway, this is about Debconf not, me -- so moving on....) In the past year of being a Developer, one thing I've seen is that other contributors ask me privately for help. Rather than blast the public lists like debian-mentors, they email or IRC private-message me, or SMS me, or find me at a Linux Users Group event. I'm lucky to know these people, and they're lucky to have me as a safe person to ask questions of. Moreover, Debian is better because these people could move past their confusion to make a technical contribution. I began the BoF session by talking about when someone asked me for help. Then I asked, "How many of you have someone you can ask embarrassing questions of?" Of the forty people crammed into Schapiro 414, two people' raised their hands. One person put it plainly, "I don't know anyone else who does Debian." It reminded me of a fact that Karen discovered when she was doing market research for us at OpenHatch: the vast majority of free software programmers know zero other people who do free software. I had seen the figure; we even used it in a talk to try and convince venture capitalists to fund OpenHatch last year. But I didn't really feel it until I heard it from a room full of Debian contributors. I structured the BoF in two parts: First, I talked in front of some slides to set the tone properly, and then we enjoyed open discussion. As I was preparing thoes slides, Daniel Morais asked me, "What's the point of having the session? Why not just come up with some ideas, implement them, and not bother also talking about it at the conference?" I had considered this; I decided I wasn't self-confident enough to start implementing ideas without talking to people to make sure I wasn't the only one who saw a problem. But I discovered another benefit of giving the talk: people who want to make Debian more welcoming knew to reach out to me. So here are some thoughts that came from our discussion (and later discussions during the conference):

• We need better mentorship in Debian. Truly, mentorship is a personal relationship. Perhaps matching people up into one-on-one groups would be a good idea. KiBi said that doing so using OpenHatch (if we add mentorship-oriented features!) would be a reasonable way to do it.
• I've heard from quite a few people who would be willing to have more one-on-one relationships with mentees.
• Everyone (except Manoj) knows that Debian contributors are not born experts. It takes a process of learning and teaching to bring them up to speed.

I set up an Etherpad document on cjb's OpenEtherpad.org. This is what we learned together:

• "If your level of understanding might be low, but you want development help, then you might not know if #debian-devel is only for people who are already super involved and know everything and therefore you should feel embarrassed."
• People get anxious over their ability to speak English.
• Bikeshedding over patches can be a major detractor.
• "Asheesh talks too fast."

One idea I had before the BoF was to create a discussion area that was safe for all questions, even if they seem silly. We talked for a while about what name that would take, if it were to become a new IRC channel. We reached something of a conclusion, but in the conference that followed Emmet Hickory offered to help make the debian-mentors IRC channel friendlyer. I think that's the best direction to take things, so the next step is for him and me to write up what we want and send a note to the debian-mentors email list explaining our vision. In the Etherpad document, people discussed the idea of doing Debian discussion over XMPP (also known as Google Talk, also known as Jabber). We weren't sure how such a place would get critical mass; someone briefly mentioned the idea of an IRC/XMPP gateway. I actually think this discussion is along a very reeasonable path, namely discovering what discussion method(s) Debian contributors want to use. (That might explain why I'm now an admin on forums.debian.net.) We also briefly discussed the idea of an anonymous question-answering service. I realize now that I'm not going to be able to have time to run that, but I still think it'd be a really cool idea. Biella would remind me that Debian is already successful at bringing in new contributors. I agree! As a free software project, we have an enormous number of participants. This is a really good thing, and we're clearly doing something right. The purpose of this talk was to figure out how to make contributing to Debian less stressful for those who participate. Truly, a "Debian for Shy People" effort isn't about shy people. It's about the moments of self-doubt we all have in which we don't know what to do and are too embarrassed to ask. I think that if the project more friendly, we can find more participants, make better use of our current ones, and see improvements to our diversity. Whew, that was long. What do you think of all this?

On my last night in New York, I didn't sleep much. At 6am, I said farewell to Central Park by running round the reservoir, which I hadn't yet done. There was a very nice red sunrise to be seen from the west side. Unfortunately I didn't sleep much on the flight home either. The British accents sounded quite unusual when we landed in Heathrow, and it was quite confusing not being able to find a Starbucks. Once I was back home, I crashed, and woke up at 10pm. I spent last night clearing the pkg-perl review queue - gregoa is taking a short break after DebConf. Then I went running at sunrise again. This is quite a different experience to Central Park - first, you have to run 2.5km just to get to Southampton Common, and secondly it is raining quite heavily. I dug out some winter gear that had turned out to be completely inappropriate for New York.

You might remember that I started to work on closing RC bugs for stable. This effort hasn't died off so I joined the RC Bug Squashing Contest that was going on during the Debian conference (which I was unable to attend). The rules did permit it, even though I was aware that it can't (and shouldn't) be compared to the unstable/testing squashers and thus it was split of into its own Special category. There still seems to be a lot of confusion on how our BTS works, especially with respect to version tracking. I was even accused of falsely claiming bug closing because the bug has been closed by someone else already. This wasn't the case, otherwise the bugs would had been archived a long time ago already^[1] given that I had expected that person to know how bug archival works and also given the sheer amount of bugs that I simply had closed for stable, I guess it is needed to shine a light upon why some bugs won't get archived as expected. If you followed my IRC talk on BTS usage last month you might already have an idea of what's going on. There might be several different reasons why bugs aren't marked for archival yet. I'll try to explain them as I understand it (given that I neither have taken a look at the debbugs code nor am involved with its development) through my working on bugs over the last 10 years.

• Usually bugs are marked for archival when they are not affecting testing or unstable. That means, for a bug filed against a version that is only in unstable and closed in unstable, an immediate archival process is started (actually, it's not that immediate: It requires the package to be in sync on all architectures it's available for, too); otherwise the fix has to enter testing before bugs are considered for archival.
• Sometimes the bug is still considered affecting unstable though, even when the fixing package version already moved over to testing. This is the case when the hurd-i386 package is outdated in unstable and can be checked in the unstable overview of the package on packages.debian.org at the end of the page, it will have red entries next to the green ones (you can ignore red entries for debports architectures, though!). You have to file an arch specific removal request for those bugs to get them archived.
• For packages in experimental it's quite the similar situation, because that packages from experimental don't transition anywhere, so those will stay unarchived for the time being if they also affect unstable.
• So what can be the reason when the fix is already available in testing and unstable but the bug still doesn't get archived? Those cases mean that the bug is considered as affecting stable and has to get addressed there, too. Bugs that are considered for that are of a release-critical severity, bugs with lower severity aren't considered for stable because they are unlikely to get fixed in stable and thus get archived. So what can we do about them?
  • Do they actually really affect stable? Working on those is what I did over the last months. There are often enough bugs filed for library transition issues, FTBFS for toolchain changes, or other things that aren't applicable for stable. Those are easy to close in stable:
    • If the version information got lost (through reassigning or similar), the only thing needed is to re-add the found versions, given that it is a higher one than the one in stable.
    • If the version information is proper (because it had still the same version in unstable at the time of the reporting) tagging them with + squeeze sid will tell the BTS to consider them only for those releases, so not thinking it affects lenny, too.
  • Some do affect stable but still aren't severe enough to warrant an update in stable (like for documentation corrections in debian/copyright or similar). If you found one of those please talk to the release-team about getting them tagged lenny-ignore, don't do that yourself because that tag is meant to be set by the release-team themself only!
  • If they actually affect stable (like security issues that though are considered to be too minor by the security team to warrant a DSA, or other severe usability issues), please try to backport the relevant fix, propose a diff to the release-team on their mailinglist and have it uploaded to lenny-proposed-updates to be fixed in the next point release.

I hope this will get others also interested to fix stuff for stable. Actually when I see something that potential falls into the last group I ping the maintainers of those packages to let them know about having them fixed. Some of you might already have received such a ping and I am thankful for those that received them well and actually already fixed some of those, too. Thanks for making stable a better place! Coming back to the RCBC, it was an interesting small competition (if only in my brain) between myself and the testing/unstable RC squashers going on. It would had been nice to get at least as many bugs in stable addressed as in testing/unstable because the amount is still a lot higher, but I can still be happy about the things done. And it is good to know that not everything seems to think that it's wasted effort to work on getting the RC count lower for stable, too (like I also was told about my effort). So thanks from that point of view!

---

^[1] There are currently 2688 bugs still unarchived that were closed last year already! This UDD query helps you:
select count(*) from bugs where status = 'done' and last_modified <= '2009-12-31';

/debian permanent link Comments: 0

When I started working on WebKitGTK+ I was a web developer, writing IT applications using Python and Django, and building features for content portals running Plone (argh). Even though I was an Epiphany user ever since it was forked off Galeon, I still had to use Firefox for my work, because I couldn t really live without Firebug. It should come as no surprise, then, that one of my first patches to WebKitGTK+ was actually making the awesome Web Inspector work in our port. After the initial support, though, not a lot has been done to further improve it, partly because it was already good enough for many uses, partly because I somehow started doing non-web development again ;). These last weeks, through my R&D efforts in Collabora, I have been able to push Web Inspector features and integration a bit further. A simple change that boosts the Inspector s usability quite a bit is having the nodes that are being hovered highlighted. Along with that, the ability to attach the inspector to Epiphany s window should make it easier to use for poking the DOM. The Web Inspector has a number of settings that control its behaviour. Since, for instance, enabling javascript debugging may slow down javascript performance, the inspector usually has it disabled by default, and provides a button to enable it. It also provides an option for always enabling that feature, but that does not work right now, because we are not saving/restoring the relevant settings. A solution to that is in the works using the GSettings infrastructure that was recently merged into glib. Here s a simple screencast, showing these improvements in action (click the video to check it out in full size): <video controls="controls" src="http://kov.eti.br/media/webkit/inspector.ogv" width="400"></video>

Nearly at the end of the week already - time flies! As always, it's been a great event. The orga folks have done a wonderful job, and New York is a cool place. Well, rather more of a hot place at the moment with the weather... :-) The highlight for me, as always, has been meeting up with people during the conference. Old friends like Lars, Joey, Marga, Bdale (and many more than I can mention here!). And finally getting to say hi to people whom I feel I know well from their blogs via Planet, and their Debian work that I benefit from every day. It was great to see John Goerzen at the baseball on Wednesday night and thank him in person for his offlineimap development. Even if I didn't recognise him directly, but via the photos of his two sons that he's been posting over the last few years *grin*

On some machines, we have enough cpus to run more than one build in parallel. However, as of now, this isn't supported by buildd. What needs to be done is to change the following code to have up to n builds happening in parallel (including of getting the next package if there is a free slot).

    while( 1 )  
        $self->check_restart();
        $self->read_config();
        my ( $dist_config, $pkg_ver) = get_next_REDO($self);
        $self->do_build( $dist_config, $pkg_ver) if $pkg_ver;
        next if $pkg_ver;
        ( $dist_config, $pkg_ver) = get_next_WANNABUILD($self);
        $self->do_build( $dist_config, $pkg_ver) if $pkg_ver;
        next if $pkg_ver;
        # sleep a little bit if there was nothing to do this time
            $self->log("Nothing to do -- sleeping " .
                       $self->get_conf('IDLE_SLEEP_TIME') . " seconds\n");
            my $idle_start_time = time;
            sleep( $self->get_conf('IDLE_SLEEP_TIME') );
            my $idle_end_time = time;
            $self->write_stats("idle-time", $idle_end_time - $idle_start_time);
     

Any takers? The full code is available from git://git.debian.org/buildd-tools/sbuild.git in the file lib/Buildd/Daemon.pm (and I'm happy to try out appropriate patches). Update The code above lives in the git branch buildd, and not master. Also, I already have one proposal in my mail.

I don't usually talk about personal stuff here, but I'll make an exception: I got tired of telling our two year old daughter the same old stories about children lost in forests, bears, witches, evil stepmothers and so on, so I turned to some other material I know fairly well. I started recounting simplified bits and pieces of the first Star Wars movie over the course of a week. She thought it was great fun, what with wookies and robots and a princess and lots of adventures, and now, every evening, asks for "Skywalker story!". I'm quite proud, although my wife rolls her eyes a bit.

On some machines, we have enough cpus to run more than one build in parallel. However, as of now, this isn't supported by buildd. What needs to be done is to change the following code to have up to n builds happening in parallel (including of getting the next package if there is a free slot).

    while( 1 )  
        $self->check_restart();
        $self->read_config();
        my ( $dist_config, $pkg_ver) = get_next_REDO($self);
        $self->do_build( $dist_config, $pkg_ver) if $pkg_ver;
        next if $pkg_ver;
        ( $dist_config, $pkg_ver) = get_next_WANNABUILD($self);
        $self->do_build( $dist_config, $pkg_ver) if $pkg_ver;
        next if $pkg_ver;
        # sleep a little bit if there was nothing to do this time
            $self->log("Nothing to do -- sleeping " .
                       $self->get_conf('IDLE_SLEEP_TIME') . " seconds\n");
            my $idle_start_time = time;
            sleep( $self->get_conf('IDLE_SLEEP_TIME') );
            my $idle_end_time = time;
            $self->write_stats("idle-time", $idle_end_time - $idle_start_time);
     

Any takers? The full code is available from git://git.debian.org/buildd-tools/sbuild.git in the file lib/Buildd/Daemon.pm (and I'm happy to try out appropriate patches).

Science and Math Track at DebConf10 This year's DebConf10 (which is great, by the way) at Columbia University, New York will feature Tracks for the first time. We had a Community Outreach track on Debian Day (to be continued by more awesome talks over the rest of the week), a Java track on Monday and an Enterprise track yesterday. Tomorrow, Thursday afternoon, the S cience and Math track (which I am organizing) will take place in the Interschool lab on level 7 of Schapiro Center. The Track will start at 14:00 with a short welcome from me, followed by presentations of debian-science by Sylvestre Ledru and debian-math by David Bremner. At 15:00, Michael Hanke and Yaroslav Halchenko will present their talk on "Debian as the ultimate platform for neuroimaging research". This will be followed at 16:00 by three mini-talks on "New developments in Science Packaging". Adam C. Powell, IV will talk about MPI, Sylvestre Ledru will present linear algebra implementations in Debian and finally Michael Hanke and Yaroslav Halchenko will discuss the citation/reference infrastructure. At the end of track, the annual debian-science round-table will happen at 17:00, where David Bremner (mathematics), Michael Hanke (neuro-debian), Sylvestre Ledru (debian- science/pkg-scicomp), Adam C. Powell, IV (debian- science/pkg-scicomp) and myself (debichem) will discuss matters about cross-field debian-science and math related topics. If afterwards there are still outstanding matters to be discussed, we can schedule ad-hoc sessions for science or math matters on Friday or Saturday. See you at the science track tomorrow!

My rule to see if a framework is worth of attention I came up with a little rule:

In order to be worth of any attention, a framework must be stable enough that I can charge money to train people to use it.

This probably applies to other kinds of software stacks, libraries, development environments and, well, to most software applications. In the context of python web frameworks, this means that:

• If it changes API all the time it is not worth of attention, because my customers won't get value for their money, as they'd continuously need retraining and rewriting their software.
• If I see lots of DeprecationWarnings it is not worth of attention, because my customers will see them and blame me for teaching them deprecated stuff.
• If fixes for bugs affecting the stable version are only distributed "in a recent git" or "in the next development version", and they are not backported into a new bugfix-only stable release, then it is not worth of attention, because:
  • my customers' business is to develop their own products based on the framework.
  • My customers' business is not to be maintaning in-house stable updates of the framework. Although if the framework's community is nice enough they might end up giving a hand.
• If it requires virtualenv or can only be obtained through easy_install it is not worth of attention, because:
  • my customers are not interested in maintaning custom deployment environments over time.
  • My customers are not interested in tracking each and every single library's upstream development to keep their production system free of bugs.
  • My customers are used to getting software through a proper distribution which also takes care of security updates.
  • I am paid to teach them how to use a framework, not a custom python-only package management system.
  • In my experience, if distributions have trouble keeping packages up to date, upstream is doing something fundamentally wrong.

In light of this rule, I regret to notice that I see very few python web frameworks worth of any attention.

It s widely regarded that to solve reliability problems you can just install a cluster. It s quite obvious that if instead of having one system of a particular type you have multiple systems of that type and a cluster configured such that broken systems aren t used then reliability will increase. Also in the case of routine maintenance a cluster configuration can allow one system to be maintained in a serious way (EG being rebooted for a kernel or BIOS upgrade) without interrupting service (apart from a very brief interruption that may be needed for resource failover). But there are some significant obstacles in the path of getting a good cluster going. Buying Suitable Hardware If you only have a single server that is doing something important and you have some budget for doing things properly then you really must do everything possible to keep it going. You need RAID storage with hot-swap disks, hot-swap redundant PSUs, and redundant ethernet cables bonded together. But if you have redundant servers then the requirement for making one server reliable is slightly reduced. Hardware is getting cheaper all the time, a Dell R300 1RU server configured with redundant hot-plug PSUs, two 250G hot-plug SATA disks in a RAID-1 array, 2G of RAM, and a dual-core Xeon Pro E3113 3.0GHz CPU apparently costs just under $2,800AU (when using Google Chrome I couldn t add some necessary jumper cables to the list so I couldn t determine the exact price). So a cluster of two of them would cost about $5,600 just for the servers. But a Dell R200 1RU server with no redundant PSUs, a single 250G SATA disk, 2G of RAM, and a Core 2 Duo E7400 2.8GHz CPU costs only $1,048.99AU. So if a low end server is required then you could buy two R200 servers that have no redundancy built in which cost less than a single server that has hardware RAID and redundant PSUs. Those two servers have different sets of CPU options and probably other differences in the technical specs, but for many applications they will probably both provide more than adequate performance. Using a server that doesn t even have RAID is a bad idea, a minimal RAID configuration is a software RAID-1 array which only requires an extra disk per server. That takes the price of a Dell R200 to $1,203. So it seems that two low-end 1RU servers from Dell that have minimal redundancy features will be cheaper than a single 1RU server that has the full set of features. If you want to serve static content then that s all you need, and a cluster can save you money on hardware! Of course we can debate whether any cluster node should be missing redundant hot-plug PSUs and disks. But that s not an issue I want to address in this post. Also serving static content is the simplest form of cluster, if you have a cluster for running a database server then you will need a dual-attached RAID array which will make things start to get expensive (or software for replicating the data over the network which is difficult to configure and may be expensive), so while a trivial cluster may not cost any extra money a real-world cluster deployment is likely to add significant expense. My observation is that most people who implement clusters tend to have problems getting budget for decent hardware. When you have redundancy via the cluster you can tolerate slightly less expected uptime from the individual servers. While we can debate about whether a cluster member should have redundant PSUs and other expensive features it does seem that using a cheap desktop system as a cluster node is a bad idea. Unfortunately some managers think that a cluster solves the reliability problem and therefore you can just use recycled desktop systems as cluster nodes, this doesn t give a good result. Even if it is agreed that server class hardware is used for all servers so features such as ECC RAM are used you will still have problems if someone decides to use different hardware specs for each of the cluster nodes. Testing a Cluster Testing a non-clustered server or some servers that use a load-balancing device at the front-end isn t that difficult in concept. Sure you have lots of use cases and exception conditions to test, but they are all mostly straight-through tests. With a cluster you need to test node failover at unexpected times. When a node is regarded as having an inconsistent state (which can mean that one service it runs could not be cleanly shutdown when it was due to be migrated) it will need to be rebooted which is sometimes known as a STONITH. A STONITH event usually involves something like IPMI to cut the power or a command such as reboot -nf , this loses cached data and can cause serious problems for any application which doesn t call fsync() as often as it should. It seems likely that the vast majority of sysadmins run programs which don t call fsync() often enough, but the probability of losing data is low and the probability of losing data in a way that you will notice (IE it doesn t get automatically regenerated) is even lower. The low probability of data loss due to race conditions combined with the fact that a server with a UPS and redundant PSUs doesn t unexpectedly halt that often means that problems don t get found easily. But when clusters have problems and start calling STONITH the probability starts increasing. Getting cluster software to work in a correct manner isn t easy. I filed Debian bug #430958 about dpkg (the Debian package manager) not calling fsync() and thus having the potential to leave systems in an inconsistent or unusable state if a STONITH happened at the wrong time. I was inspired to find this problem after finding the same problem with RPM on a SUSE system. The result of applying a patch to call fsync() on every file was bug report #578635 about the performance of doing so, the eventual solution was to call sync() after each package is installed. Next time I do any cluster work on Debian I will have to test whether the sync() code seems to work as desired. Getting software to work in a cluster requires that not only bugs in system software such as dpkg be fixed, but also bugs in 3rd party applications and in-house code. Please someone write a comment claiming that their favorite OS has no such bugs and the commercial and in-house software they use is also bug-free I could do with a cheap laugh. For the most expensive cluster I have ever installed (worth about 4,000,000 UK pounds back when the pound was worth something) I was not allowed to power-cycle the servers. Apparently the servers were too valuable to be rebooted in that way, so if they did happen to have any defective hardware or buggy software that would do something undesirable after a power problem it would become apparent in production rather than being a basic warranty or patching issue before the system went live. I have heard many people argue that if you install a reasonably common OS on a server from a reputable company and run reasonably common server software then the combination would have been tested before and therefore almost no testing is required. I think that some testing is always required (and I always seem to find some bugs when I do such tests), but I seem to be in a minority on this issue as less testing saves money unless of course something breaks. It seems that the need for testing systems before going live is much greater for clusters, but most managers don t allocate budget and other resources for this. Finally there is the issue of testing issues related to custom code and the user experience. What is the correct thing to do with an interactive application when one of the cluster nodes goes down and how would you implement it at the back-end? Running a Cluster Systems don t just sit there without changing, you have new versions of the OS and applications and requirements for configuration changes. This means that the people who run the cluster will ideally have some specialised cluster skills. If you hire sysadmins without regard to cluster skills then you will probably end up not hiring anyone who has any prior experience with the cluster configuration that you use. Learning to run a cluster is not like learning to run yet another typical Unix daemon, it requires some differences in the way things are done. All changes have to be strictly made to all nodes in the cluster, having a cluster fail-over to a node that wasn t upgraded and can t understand the new data is not fun at all! My observation is that the typical experience of having a team of sysadmins who have no prior cluster experience being hired to run a cluster usually involves learning experiences for everyone. It s probably best to assume that every member of the team will break the cluster and cause down-time on at least one occasion! This can be alleviated by only having one or two people ever work on the cluster and having everyone else delegate cluster work to them. Of course if something goes wrong when the cluster experts aren t available then the result is even more downtime than might otherwise be expected. Hiring sysadmins who have prior experience running a cluster with the software that you use is going to be very difficult. It seems that any organisation that is planning a cluster deployment should plan a training program for sysadmins. Have a set of test machines suitable for running a cluster and have every new hire install the cluster software and get it all working correctly. It s expensive to buy extra systems for such testing, but it s much more expensive to have people who lack necessary skills try and run your most important servers! The trend in recent years has been towards sysadmins not being system programmers. This may be a good thing in other areas but it seems that in the case of clustering it is very useful to have a degree of low level knowledge of the system that you can only gain by having some experience doing system coding in C. It s also a good idea to have a test network which has machines in an almost identical configuration to the production servers. Being able to deploy patches to test machines before applying them in production is a really good thing. Conclusion Running a cluster is something that you should either do properly or not at all. If you do it badly then the result can easily be less uptime than a single well-run system. I am not suggesting that people avoid running clusters. You can take this post as a list of suggestions for what to avoid doing if you want a successful cluster deployment.

The new roaming workstation profile in Debian Edu/Squeeze is fairly similar to the laptop setup am I working on using Ubuntu for the University of Oslo, and just for the heck of it, I tested today how hard it would be to integrate that profile into the university infrastructure. In this case, it is the university LDAP server, Active Directory Kerberos server and SMB mounting from the Netapp file servers. I was pleasantly surprised that the only three files needed to be changed (/etc/sssd/sssd.conf, /etc/ldap.conf and /etc/mklocaluser.d/20-debian-edu-config) and one file had to be added (/usr/share/perl5/Debian/Edu_Local.pm), to get the client working. Most of the changes were to get the client to use the university LDAP for NSS and Kerberos server for PAM, but one was to change a hard coded DNS domain name in the mklocaluser hook from .intern to .uio.no. This testing was so encouraging, that I went ahead and adjusted the Debian Edu scripts and setup in subversion to centralise the roaming workstation setup a bit more and avoid the hardcoded DNS domain name, so that when I test this tomorrow, I expect to get away with modifying only /etc/sssd/sssd.conf and /etc/ldap.conf to get it to use the university servers. My goal is to get the clients to have no hardcoded settings and fetch all their initial setup during installation and first boot, to allow them to be inserted also into environments where the default setup in Debian Edu has been changed or as with the university, where the environment is different but provides the protocols Debian Edu uses.

The problem: Splitting patches As a Debian maintainer, I often work with patches (files listing changes to text files), for example when tracking the modification I make to some software before I upload the package to Debian. To manage these patches, quilt is a nice tool: It helps you maintain a stack of patches on top of the original code and encourages you to keep your variously modifications separate. One use case is not supported by quilt at all: Splitting patches. One often has a large patch containing several independent changes. This might happen after you fix a few problems in the upstream code and then run dpkg-buildpackage, which will create one patch of your changes and put it in debian/patches. Before, I had to manually edit the patch and write the hunks, which are the building blocks of patches, into separate file. Where it already works There is no such problem when using a version control system, such as Darcs. Especially Darcs is rightly famous for its user-friendly interface and powerful hunk-selection features. You can even split a single hunk (which could be a change to one line) into two separate steps! Have a look at the HunkEditor page on the Darcs wiki to see how that works.
Let s steal a feature Well, it is not stealing if it is Free Software... Darcs has these nice capabilities and provides them in the context of version control systems, while we need them in the context of patch files. But Darcs is providing an API to its code, so shoudn t it be possible to create a program that uses the Darcs code to split patch files? As a matter of fact, it is possible: You can see that program in action on this 3min Ogg Theora-Video or directly here if your browser supports HTML5: Nice, can I use it? The code is a working proof of concept. What you see works. You do not see how it handles patches that create or delete files, patches that do not apply cleanly or are already applied or any kind of error handling. That does not work yet. If you still want to try it, you can grab the code from the Darcs repository at http://darcs.nomeata.de/ipatch, but you need to build the latest development state of the Darcs library first. I think ipatch could become a very useful and powerful tool with applications in areas where nobody would think of using Darcs. I definitely want some integration into quilt, replacing the splitted patch in the series by the replacing patches automatically. Maybe even a git plugin could be created? But I don t think I can push this project far enough on my own. So this is an invitation to join me and make ipatch a great tool. This invitation goes especially to the Darcs developers: Please have a look how the code uses the Darcs API and help to improve the collaboration here. I think we can use the darcs-users mailing list until there is need for a dedicated mailing list.

Linux 2.6.35 has been a fairly interesting release from an ASoC point of view, with several notable framework enhancements:

• Support for keeping audio paths through the CODEC up during system suspend, primarily intended for use with devices where the Linux system is one of several independent systems running on the device and the other systems (like the cellular modem in a phone) can maintain useful audio paths even when the Linux system is inactive.
• Enhancements to the jack detection infrastructure, including the addition of notifiers on jack status changes (allowing better integration of physical jack detection with electronic methods) and snd_soc_dapm_force_enable_pin() (which allows DAPM managed supplies such as microphone biases to be forced on). For example, jack status change notifications can be used to enable microphone detection via bias current sense only when a microphone is physically present.
• Support for knot and continuous PCM rates in the core.
• SMDK6410 5.1 audio support, TI SDP4030 audio support, and basic support for playback on the 1133-EV1 PMIC module for Freescale i.MX31ADS systems (currently limited by the support for the SSI interface on the i.MX31).
• Support for DaVinci integrated voice CODECs, Philips UDA1345 CODEC, SuperH FSI2 interfaces, TI OMAP4, TWL6040 CODECs, WM9090 audio subsystem.

I've uploaded git-dpm version 0.2.0. Most noteable change and the one which could need some testing is the new git-dpm import-dsc, which will import a .dsc file and try to import the patches found into git.<\p>

This week, I am attending DebConf 10 at Columbia University in New York. The first day of DebConf is known as Debian Day. While most of DebConf is for the benefit of people involved in Debian itself, Debian Day is aimed at a wider audience, and invites the public to learn about, and interact with, the Debian project. These are the talks I attended. Debian Day Opening Plenary (Gabriella Coleman, Hans-Christoph Steiner) Hans-Christoph discussed Debian and free software from a big picture perspective: why software freedom matters, challenging the producer/consumer dichotomy, how the Debian ecosystem hangs together, and so on. Steps to adopting F/OSS in government (Andy Oram) Andy discussed FLOSS adoption in governments, drawing on examples from Peru, the city of Munich, the state of Massachusetts. He covered the reasons why this is valuable, the relationship between government transparency and software freedom, and practical advice for successful adoption and deployment. Pedagogical Freedom (panel, Jonah Bossewitch et al) The panelists discussed the use of technology in education, especially free software, some of the parallels between free software and education, and what these communities could learn from each other. This is a promising topic, though the perspectives seemed to be mostly from the education realm. There is much to be learned on both sides. Google Summer of Code 2010 at Debian (Obey Arthur Liu) This talk covered the student projects for this year s Summer of Code. Most of the students were in attendance, and presented their own work. They ranged from more specialized projects like the Hurd installer, to core infrastructure improvements like multi-arch in APT. Beyond Sharing: Open Source Design (Mushon Zer-Aviv) Mushon gave an excellent talk on open design. This is a subject I ve thought quite a bit about, and Asheesh validated many of my conclusions from a different angle. I ve added a new post to my todo list to go into more detail on this subject. Some points from his talk which resonated with me:

• When collaborating on code, everyone must reason with one collaborator: the computer. This forces a level playing field and a common encoding.
• Collaborating on other types of creative work is more difficult in part because of the differences encoding/decoding information between different individuals
• Making this easier for design work requires improving motivational factors and language as well as tools and processes
• Many design decisions are actually rational, and are compatible with a group consensus project. Too often, I hear that design can t be done collaboratively, citing too many cooks in the kitchen analogies, but I have never believed it.
• Mushon s own project, shiftspace.org, seems to be a browser-plugin-based system for collaboratively remixing web applications. I haven t looked at it yet.
• Leadership and openness are not mutually exclusive. This is another pet peeve of mine, and there are so many examples of open leadership in the free software community that I don t see how anyone can think otherwise.
• Mushon s presentation is available in revision control so that it can be freely used and improved

How Government can Foster Freedom in Technology (Hon. Gale Brewer) Councillor Brewer paid a visit to DebConf to tell us about the work she is doing on the city council to promote better government through technology. Brewer seems to be a strong advocate of open data, saying essentially that all government data should be public. She summarized a bill to mandate that New York City government data be public, shared in raw form using open standards, and kept up to date. It sounded like a very strong move which would encourage third party innovation around the data. She also discussed the need for greater access to computers and Internet connectivity, particularly in educational settings, and a desire to to have all public hearings and meetings shared online. Why is GNU/Linux Like a Player Piano? (Jon Anderson Hall, Esq.) Jon is a very engaging speaker. He drew parallels between the development of player pianos, reproducing pianos, reed organs, pipe organs and free software. He even tied in Hedi Lamarr s work which led to spread spectrum wireless technology. To be quite honest, I did not find that these analogies taught me much about either free software or player pianos, but nonetheless, I couldn t help but take an interest in what he was saying and how he presented it. DebConf Opening Plenary (Gabriella Coleman) Biella and company explained all the ins and outs of the event: where to go, what to do (and not do), and most importantly, whom to thank for all of it. Now in its 11th year, DebConf is an impressively well-run conference. I m looking forward to the rest of the week!

Hi! First, sorry not to have posted anything in the last two weeks! I was on vacation, and so, did less work on the project. But in no means it is dead, and development continues! First week of my vacation was (apart from resting, and vacation stuff) almost entirely dedicated to make my build environment work without internet access. Here, I was lucky to have made a complete debian/main mirror using reprepro before leaving! However, I had to fight a bit with debian-installer: first, for an unknown reason (if someone knows why, speak up!) it didn't search for the debian-installer section and I had to specify 'main/debian-installer' instead of 'main' in sources.list.udeb.local. Second, because I'm lazy, my reprepo repo isn't signed, and so, I had to pass some apt options to make when building d-i. After this first week, I've been able to work on uboot-installer, that you can find in pkg-fso/d-i.git. Originally written by my co-mentor Per, this package/script is meant to update the device's U-Boot env so it can boot Debian. It installs the uboot-envtools package, tries to read the U-Boot environment to make sure everything is ok, determines the new boot command, and shows/write it in the uboot env. When working on uboot env modification, I ran in a strange issue: I can read the env without problem using fwprintenv, modify it, and read it back, but U-Boot then fails, saying the environment is corrupted. In fact, this is because I've enabled CONFIGMTDNANDS3C2410_HWECC in config.s3c24xx, and it appears to cause invalid ECC values to be written on the flash. Switching it off solved the issue. Apart from that, I've made some minor modifications in the installation script, and I've (re)installed Debian countless times on my FR, and everything seems to work fine so far (although my kernel is non-installable at the moment because of version mismatch with what's in my repo). Building d-i for the FR So, you're welcome to test! Everything is available in the three (pkg-fso/d-i.git, pkg-fso/linux-2.6.git, and usbboot (hg)) repositories. You can rebuild the d-i image and packages the following way:

mkdir ~/incoming/
cd d-i.git/packages/
cd flash-kernel && debuild -uc -us && cd .. && mv *.*deb ~/incoming
cd base-installer && debuild -uc -us && cd .. && mv *.*deb ~/incoming
cd hw-detect && debuild -uc -us && cd .. && mv *.*deb ~/incoming
cd libdebian-installer && autoreconf -i -v && debuild -uc -us && cd .. && mv *.*deb ~/incoming
cd partman/partman-auto && debuild -uc -us && cd .. && mv *.*deb ~/incoming && cd ..
cd arch/armel/uboot-installer && debuild -uc -us && cd .. && mv *.*deb ~/incoming && cd ../..
# For some reason, I had to rebuild installation-locale too
cd installation-locale && debuild -uc -us && cd .. && mv *.*deb ~/incoming

Then, copy everything that is in ~/incoming to your repo. Alternatively, you can use localudebs and add the following lines to pkg-lists/netboot/network-console/armel/s3c24xx.cfg:

mmc-modules-$ kernel:Version 
mmc-core-modules-$ kernel:Version 
crc-modules-$ kernel:Version 
md-modules-$ kernel:Version 
ext2-modules-$ kernel:Version 
ext3-modules-$ kernel:Version 
flash-kernel-installer
base-installer
hw-detect
libdebian-installer4-udeb
partman-auto
uboot-installer
installation-locale
# For some reason, flash-kernel-installer brings live-installer in,
# disable it explicitly as we don't want it
live-installer -

Now that you have built every needed package, you can build the d-i image:

make clean_s3c24xx_network-console
# The SECOPTS thing is only needed if you are using an unsigned repository
make build_s3c24xx_network-console SECOPTS="--allow-unauthenticated"

Now, you can find the ready-to-use u-boot image in dest/s3c24xx/network-console/uImage-multi! There are a few differences between the pre-built image and the one you have generated. Those differences are: the kernel in use (2.6.32 for the pre-built image, 2.6.34 if you follow the steps above), the network config (192.168.42.202 for the pre-built image, 192.168.0.202 for your own), security (unauthenticated repositories are allowed in the pre-built image!), and uboot-installer (some changes are still staging on my local working copy). Testing d-i on your FR Beware, those images are only for testing (especially the pre-built one, which accepts unauthenticated repositories). It should not harm your device, but use with care anyway. Now that you have built your u-boot image multi (if you don't want to, you can use the pre-built one), you are welcome to follow the steps described in the How to Boot article. Now, follow the instructions that appears on the FR screen and you should be able to install Debian like you would on any machine. The equivalent of grub-installer is divided into two steps (the two are needed, but each provides bootable-system, yes, that's a bug): flash-kernel ("Make the system bootable") and uboot-installer ("Modify U-Boot environment on flash"). (Note: SSH password is "install") What's coming next/has to be done? I've just arrived at DebConf 10, and some intensive testing should be done here. Apart from that, there are quite a few things left to do (right now, or in a distant future):

• Merge uboot-installer into flash-kernel, or give it a life on its own
• Get changes merged into d-i
• Continue with upstreaming kernel changes (drivers and gta02 machine definition)
• Make a FSO task, investigate how to run nodm for a normal user
• Try to get a kernel working on HTC G1
• Resolve some bugs like #586427
• Work on MTD support for partman?
• g-i for the FR?

So for one day a few days ago, I wasn't Wouter Verhelst, Debian Developer, but rather the above. I'm not usually very much interested in doing touristy things, but then on the other hand I'm of the opinion that you can't really claim to have been somewhere if all you've seen is the inside of a certain specific university campus. So, well, touristy things. I took the subway to about 10 blocks away from the very south of Manhattan, and then walked. I passed by city hall and what used to be the world trade center, but there wasn't much to see there construction sites are the same everywhere in the world. I moved on to "the battery", the south tip of Manhattan, and had an... interesting look at the Statue of Liberty in the distance. I thought about going there, but the tickets were sold out, so scratch that. Instead, I walked on to the Brooklyn Bridge (passing by Wall Street on the way), spent some time looking for the pedestrian's entrance to that bridge (which was slightly harder than would've thought it to be), and walked partway up the bridge. I wasn't interested in crossing over to Brooklyn, but it's an interesting bridge to walk on, and I had an interesting time. When I left the bridge again, it started raining. I don't mind a few drips on a warm day like that day, but this was more than that, and it started to bother me. So, rather than walking to the Empire State building, as I'd been planning, I decided to take the subway there. This did mean I missed out on the SOHO area, which I would've liked to see, but well, you can't have it all. The Empire State building is something you grow up hearing about, and I'd seen pictures of it. It has a somewhat distinctive silhouette, shown on several comparative graphics of high-profile skyscrapers. But none of that is even close to the real thing. Not that it's higher than I expected; on the contrary. But it does look different; its color is much lighter than I thought, and the distinctive silhouette isn't as distinctive once you're standing right next to the building. But, well, going up the building clearly shows that it is the tallest building of New York. There are other skyscrapers, but most of those seem to be little dwarves in comparison. The view is nice, up there, and I took some interesting pictures. The tickets aren't very cheap ($20), but not insanely expensive either. I don't regret doing this. (in case you were wondering: yes, the above picture is in the point of view of the one above that, and vice versa) By that time it was around 4 pm already, and I thought about going back to the Columbia campus. As I checked out my map for the most efficient route, I found that it probably would've been easier to walk to Times Square and take the number 1 train there which stops right in front of Columbia (but below the surface, obviously). So since I was going to have to go there, I figured I could just visit Times Square while I was at it. I must say I'm not very impressed by it. For starters, Times Square isn't actually a square, at least not as I'm used to that word. Broadway and 7th avenue happen to cross at a, for Manhattan, uncharacteristically sharp angle, which results in more space between buildings than usual. But it's still fairly small as a "square". They've fenced off a part of that space and put a bunch of chairs and tables there. This would be a cosy and inviting, "gezellig" place, if not for the very audible noise of the traffic still going on all around it, and the fact that everywhere you see, there's three layers of brustling and visually noisy adverts. It could have been a relaxing oasis in the middle of the city, but instead it's just as busy as everywhere else in Manhattan. But then, I guess that's what New York City is all about. At any rate, after spending about half an hour or so there, I walked over to the subway to get back to the venue just in time for dinner. The end of a nice, touristy, day.

I'm going insane in this country - the accents, the jaywalking, the food, the money, the poverty in the heart of Manhatten... suddenly I appreciate the UK much more. So I have purchased an electric kettle, and set it up in the Carman basement, for the moment. I have also splashed out on a teapot, and one mug. (So far I haven't found any other mugs in the place, so bear that in mind if you wish to join me - $2.49 from the homeware store across the street.) I have brought two boxes of Twinings tea from the UK, and in the unlikely event that it runs out there are some brand names I recognise in the Westfield Market. In the spirit of US philanthropy, I intend to donate this equipment for the betterment of Columbia University when I leave.

After I finished an re-read my epic post describing my first day and a half at Debconf10 I suddenly realised that if I continue to describe the rest of 13 days here in such style and verbosity this would become a book, a boring one at that, so I decided to limit myself to 2 posts for Debcamp and then a post a day for the Debconf. But about the first half of the Debcamp week there are things that are as usual and there are things that are not. Let s start with the usual bits: more people arriving every day, evening parties are getting more and more fun and wild (or so people say) and the Internet and power at the hacklabs magically becomes more and more reliable day by day, the cabling mess grows organically trying to spread out evenly and not overload any individual socket, extension cords with non-local plugs appear and spread the load some more, people stress out, volunteer, crash out and repeat. All in all nothing can stop the freight train of few hundred Debian developers determined to have fun. With out own DFSG-free definition of fun. (But this year we appear to be running very close to the edge on volunteers if we run out of those, there will be a train-wreck, so please volunteer!) Now off to the unusual stuff. The City is well it is cool and very, very impressive. It is not terribly different to me at least I am used to such structure of the city: grid based layout of the downtown city (with some parks) and then branching out to separate, but different across-the-river districts and then sprawling out to slightly chaotic suburbs. Riga is very much like New York in the design. The difference is that New York is 10-20 times larger: the areas are 10 times larger, the buildings are 3-4 times higher on average, the streets are 2-3 times wider and yet have more traffic and there are far, far more shops, shows and restaurants. Also there is the subway. It is a great thing in that it hides the size of the city take a bus downtown once, to find out what I mean it takes ages to drive the distance that takes 20 minutes on the subway. I like this city, I am getting a feeling, that I could live here without much problem for me. So far I ve only had this feeling in Riga and Berlin. On the other hand this is USA. I ve so far only encountered one bad thing about it, but it is a pretty big one food. Basically all food that I ve tried so far in the USA has been crap. It was tasty salt, sugars and fat took care on my brain thinking it s food, but underneath that it was pretty crap: there was no texture, no content, no soul. The John Jay cafeteria where we are eating lunch and dinner is better than the most other options, because it is an all-you-can-eat buffet where you can choose your poison and it was also the place where I had the best piece of food in USA so far a slice of pepperoni pizza, that had a bit of taste behind the fat. Also, surprisingly, the fast food options (McDonalds, Burger King, ) are better than the equivalents in Europe, far better. In fact the fast food is cheap and in some cases tastes better than regular food, so there is no wonder why people might prefer it in some situations. So it is easy to see how people just accept shoving bland fast food or bland all-you-can-eat food into their mouths and not think much about it and thus become fat and put undue stress on their health. I expect the average weight of Debian developers to increase by 5 kg by the end of the conference. If you want to prove me wrong, running with bubulle would help you a lot with that. Events downtown. New York is a huge city with a lot of events going on every day, so everyone should be able to find something of interest for them. For me it was the free tickets for tapeings of The Daily Show and The Colbert Report. I got into both of those and for me The Colbert Report was by far the better experience. For one you can not get into Daily Show without a ticket (some tickets show up on the web site on the morning of the shoot around 11am), while 18 people from the stand-by list at Colbert Report got in. At The Daily Show you stand in a live line with ticket holders in one line and stand-by line separate. If you have tickets and arrive around 3pm you should be fine any later than that and you risk to be standing outside even with a ticket. You find that out around 4.30pm when they hand out physical tickets you have one, you get in. If not you might rush over to Colbert Report where a more humane system is used a staffer takes down your name and email on a numbered list and then you can walk around until 5.30pm then they let the ticket holders in and after that call the names of stand-by people that get in. The Colbert Report studio is brighter, more colourful and closer to the action, also it is very rare that cameras block the view from the audience (which is common on The Daily Show). It might have also been my luck when I got on the most boring The Daily Show episode I can remember, ever. The best joke was a woman asking John is she could get a ticket for her friend in August. The warm-up act and crowd control at The Colbert Report was also way better: Colbert staff was hyper, security was ever-present, warm-up was funnier and very engaging (he grilled me for several minutes and I replied making the audience laugh very hard explaining that Latvia was like India of Eastern Europe in regards to IT exports) and Colbert himself was very gracious talking to us out-of-character before the show for a good 10 minutes. Location, location, location. The talk rooms and event rooms and hacklabs are spread out across multiple buildings and there is a lot of other activities going on in those buildings besides Debconf, so moving between place might be confusing for the first day or two. Also the rooms are quite dark that might cause a noise problem for me and the video team as we ll have to up the sensitivity settings on our gear. The video team is working on fixing that by throwing a bit more light on to the speakers. Elevators are wicked fast, but can also be confusing, because the ground floor is on a different number for different buildings it can be G, 1 or even 4. Usually on campus there is a star next to the level with the exit. The dorms. I am in the Carman building and it looks like its interior has not been updated since it was built large ceramic bricks with very visible gaps (for the interior walls), raise-to-open windows, huge aircon fans that take up the whole bottom of the window, plumbing from the 60ies (at least). The security is weird on one hand you have to give your room card to the guard when entering the building, but on the other hand the room cleaning crew can simply forget to close your door after they are done. Like this Thursday I returned to the dorm just before lunch only to find the door of my room open. No one was around and nothing was missing, but it s still worrying. In any case I am steadily uploading photos from Debconf 10 to my Flickr page and new stuff should show up every day.