Today is Debian's Birthday, and for a while I've wanted to do something special on this date. In order to raise the general motivation of the project, have a special day when everyone is invited to thank those that make our lives easier. However long I have wanted to do this, I haven't had that much time to prepare the site itself. I've spent the past two days getting it working, with the help of Maxy, Valessio and Raphael, but there's still a lot more work to do. In any case, it's already usable at: thank.debian.net. I invite you to use it to send thanks to those that work on Debian. The code is temporarily hosted at code.google.com, but I plan to move it to alioth as soon as I'm not so rushed to finish it. Bugs & Patches much appreciated!

SmoothWall Express is a GNU/Linux distribution geared towards firewalling, with an installer, a web interface, and some common software like squid that can be useful when running a small business router. It is theoretically the basis for the corporate products of SmoothWall Ltd., who happen to employ me; but all opinions here are my own, and I'm not speaking for them. Unfortunately, the SmoothWall Express kernel is somewhat "stable", which leads to problems installing the distro on modern hardware. There is a new version of Express in the works, but I'm afraid SmoothWall Ltd. currently has a bit of a "code dump" mentality with respect to delivering updates to their community, because they don't recall seeing any significant contributions from outsiders. At DebConf I created proof-of-concept Debian packages of two components of Express 3.0: the swe3 web interface, and the smoothd daemon which executes privileged commands. Currently these can show a basic web interface; some of the less complicated bits will even run, and I can shut down my laptop using the "shutdown" button via smoothd. (Note that I still need to add boring stuff like debian/copyright files, but I plan to release these as soon as I can.) In the near future, hopefully I can implement some of the more important features (like, er, firewalling), and add some other components like the traffic shaping and IM filtering daemon. I'm working towards a demonstration Debian Pure Blend that can show off some of the advantages of working with a third-party distribution as a base. If anyone would like to help me... send me patches. :) I expect I'll be blogging my progress occasionally.

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 supporting script for using cowbuilder with git-buildpackage came up at DebConf, which also meant more attention on the bug requesting that it be included in git-buildpackage. I've therefore done a few new releases over the last few days including additional features that the example script in git-buildpackage supported that my version of the script hadn't. Changes since 1.10 include adding support for update, create, and login options, which call cowbuilder with the corresponding flag instead of doing a build, and support for taking the distribution on which to act from the name of the script in case anyone wants to create symlinks to the script as supported by the git-buildpackage example script. I also switched the license to an MIT license instead of the same terms as Perl (which didn't make much sense, since it's not written in Perl). You can get the latest version of the script from my scripts page, and will also be included in the git-buildpackage package directly down the road. Thank you very much to Guido G nther for his discussion, willingness to include the script, and bug fixes.

Long before I took the train up to New York for DebConf10, I was sure that Eben Moglen's talk, the followup to his earlier, excellent "Freedom in the Cloud", would be a highlight of the conference. Even though it was scheduled for an ugly 9 am slot the morning after that other certain highlight, the wine and cheese party. I was not disappointed. The amazing DebConf video team has already put up the video of "How We Can Be the Silver Lining of the Cloud". Embedded below for those with html5. If you watch one video from DebConf, this should be it. <video controls="controls" src="http://meetings-archive.debian.net/pub/debian-meetings/2010/debconf10/high/1252_How_We_Can_Be_the_Silver_Lining_of_the_Cloud.ogv"></video> (Note that the audio stops cutting in and out after he switches mics a few minutes in.) In this talk, Eben goes far past the earlier "Freedom in the Cloud" talk, changing the focus from scraping Facebook, to laying down a concrete, detailed vision of the "FreedomBox", and how it could be a game changer. After the first standing ovation I can remember at a DebConf, given to the first speaker in a suit I can remember at a DebConf, many of us ended up in this huddle in the hall. Which turned into an impromptu BoF in a nearby room, which led to this wiki page, which was followed by seemingly everyone buzzing about it for the rest of the conference, and a second BoF that probably exceeded its room's occupancy limit. Which led to ... ??

I will spend the next several months trying to find other things we can do to help make this suddenly happen. And believe me, to the rest of the world, this will happen very suddenly. We will disrupt a lot of games we would like to have disrupted.
-- Eben Moglen

---

My thoughts:

• Focusing on this is a tactical retreat from promoting free software on eg, desktops and cell phones. But Eben makes a good case for doing so in order to disrupt many things that are blocking free software elsewhere.
• Clearly there is much interest in Debian about helping with the FreedomBox. Many in the project have done a lot of work on supporting the target hardware, and supporting users who already do this kind of thing. If the software stack for the FreedomBox already existed, we'd be packaging and integrating it. Since it mostly doesn't, many of us are interested in developing parts of it.
• Eben seems to be looking for a technical project lead. Until someone steps up to provide some clarity and decision making, we're all sorta fumbling around the edges, in the dark. At least with the same goal in our heads. In other words, FreedomBox needs an "upstream", it can't just be done in Debian. This doesn't mean that someone (or a small group) from Debian couldn't become that project lead.

Dan Rosenberg pointed me to a paper from the 2010 WOOT conference that mentions my work to implement the CryptProtect function in Wine. Their research is awesome, and it was fun to compare my attempts at identifying the blob structure to what they discovered. Looks like I got the structure pretty well, but that was easy; they totally broke the encryption itself. Now those native blobs can be decrypted, opening the door to full NTFS interoperability, offline forensics of Windows encrypted files, etc. (For designers of future symmetric encryption methods: please don t store the keys (in any form) on disk with the cipher text ) What I found most alarming about this is a comparison to eCryptfs, and how it is implemented with the user s login passphrase. In both cases, a hash of the passphrase is used to perform additional work that results in keying the final encryption. In eCryptfs, this hash is calculated to unlock the main key that is used for eCryptfs and is then thrown away (it can always be regenerated when the user logs in). If the user changes their passphrase, they must decrypt and re-encrypt the eCryptfs key (this is done automatically by PAM). Under Windows, to deal with potential user login passphrase changes, they instead decided to store all prior (SHA1) hashes of the user s passphrases, even lacking a salt. So all the clear-text user login passphrases are recoverable with a standard rainbow table, in parallel. O_o

Here are my notes about the very insteresting BOF on distributed bugtrackers held at DebConf This is just some elements of report (some taken from the gobby edits, and written down by me after watching the video (unfortunately missing 2 mins of sound in the beginning of the video stream/recording)). This is not a full report of all the discussions, as some discussed elements weren t of interest IMHO. You ll find here many ideas of mine, links and pointers (resulting of our work in the context of the Helios project on similar topics), so this is in no way a report of what was said exactly during the BOF. Aspects of interest:

• for Debian bugs
  • Sharing state between upstream, downstream and sidestream
    • Forwarding upstream
  • Sharing comments between the same bugs
  • merging / conflict resolution (technically challenging, as well as in order to match people s habits/process)
• Same problem in general
  • distributed bug tracking
    • working offline (modify locally, push, etc.)
  • but also distributed version/commit tracking : tracking bug presence or fix along the branches of commits in distributed VCSes
• Interop with other bugtrackers:
  • method to pass data back and forth between different bugtrackers
  • standard method / format / API : lack of standard widely used
  • visibility of issues known upstream (or elsewhere) to Debian users while using reportbug
  • scraping other trackers

Note that these topics may in principle be discussed on the Distributed bug trackers mailing list: http://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs Tools / implementation ideas :

• First, there s a wiki resource about lots of software tools : http://dist-bugs.kitenet.net/software/
• SD (presented later by Christine Spang see my other blog post about her great presentation)
• LaunchPad s tracker already knows about lots of other bugs in other distros including Debian bugs (through bug tasks )
• bts-link watches links between bugs and status changes (mainly through scraping)
• Generic scraping tools could be used :
  • Scraperwiki (http://scraperwiki.com/)
  • or WebReformatter (http://code.google.com/p/webreformatter/
• Virtuoso spongers to perform on the fly conversion of bugs XML feeds to RDF to inject them in a RDF store (ex: search bugzilla inside http://www.openlinksw.com/dataspace/dav/wiki/Main/RDFMappersUseCases)

Storage of repositories / databases of remote bugs :

• Mail lots of suggestions, but to be discarded IMHO
• in users Virtuoso RDF stores, eventually in an integrated way with the Semantic Desktop (KDE 4.4 / Tracker / Zeitgeist) which may be an option (integrating bugs in other desktop tools aware of the semantic desktop).
• through desktopcouch (as used by the bughugger client for LP tracker see the bughugger presentation at RMLL/LSM 2010)

About such storage, and the RDF store option, here s a prototype of ours that exposes UDD s bug facts through a SPARQL interface, allowing to publish bug facts as RDF (setup in the frame of the Helios project). It includes both Debian and Ubuntu bugs, and allows interlinking them in a standard way (with Semantically described links in RDF). See http://testforge.int-evry.fr/d2r-server/resource/spackage/evolution for an example. The problem is not how to distribute (distributed database systems exist), but the semantics of bug properties, and the different implementations of interfaces of different tools : which standard to implement, or how many converters are necessary if no standard ? We believe that navigation/referencing/tracking of external bugs would be much easier if bugs were LinkedData citizens, i.e. they would be exposed with (standard) formats like Semantic Web ontologies served with Semantic Web standards (like RDF). The worst case is currently to have to perform web scraping on bugtracker interfaces. How to avoiding scraping ? A solution could be to publish RDFa / microformats using common standard semantics, directly from the bugtracker pages at bugs URLs (see my wishlist for debbugs on that subject : 590931: Would be great to integrate RDFa metadata into debbugs pages). Now some pointers to historical details on the same subject and Debian (old posts by Lars Wirzenius) :

• Distributed bug tracking
• Bug exchange format

Overall, the discussion was quite interesting, but didn t reach any sensitive progress regarding the state of the art. Much needs to be worked on, mainly on standardizing APIs, semantic descriptions of bugs, and implementation in tools like SD for instance. Stay tuned for more progress.

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

This is a quick report and notes about the great presentation made at DebConf on Distributed bug tracking for Debian with SD by Christine Spang (http://penta.debconf.org/dc10_schedule/events/591.en.html) Hopefully, the slides are gonna be published soon, but in the meantime, you have them in the video recording (see link above). For those who don t know SD, they may refer to a talk given by its author, Jesse Vincent, at the recent RMLL/LSM 2010 : Peer to peer issue tracking with SD and Prophet (video recording coming soon : EDIT: a premiere recording is available here). She draws 2 main use cases in her speech, which is exactly the kind of features we ve been thinking about for fetchbugs4.me :

• as a Debian maintainer : SD may be used to clone into your local SD repository all tickets related to your activity on your packages in debbugs.
• or as both a Debian maintainer and upstream developper, you d combine bugs from Debian s debbugs and upstream s bugtracker in one same bug database.

What would be even better is to be able to link all of these bugs to each-other but I m not sure this is yet possible. Christine started implementing debbugs (Debian s bugtracker) support in SD. For reference, there s a wishlist about it in 590156 : sd: Provide sync-ing with debbugs. The implementation is still in alpha state, in read-only mode only. Christine has implemented a new method get_{machinereadablebuglog}() for debbugs SOAP interface. It seems to send some Perl Data::Dumper output, which is probably fine for SD as SD is written in Perl, like debbugs but it may be better if it was some more generally accepted format, like JSON maybe. Among the topics discussed, was the absence of any standard API to connect to bugtrackers, meaning that SD needs to include many different client code modules for each of the trackers different APIs over different kinds of protocols. I ve raised (through my IRC comments, watching the presentation through the stream), that there s a proposal for such a standard that exists : OSLC-CM. Still, it s not widely implemented, in particular in Open Source tools (see another post of mine on the subject). I think it would be great if SD could be a client of OSLC-CM compatible trackers, hence I ve filed a wishlist. Also, I suggested that maybe it would be interesting to be able to browse the mail threads of comments on Debian bugs, much like with bts mbox show 12345 command (which opens mutt on the bugs thread, for me), when in offline mode, with SD. Maybe the bts command could just use SD as a backend for all its operations. Another very interesting feature may be to allow transfering a Debian bug to an upstream bugtracker, through SD. Dunno if that will be possible. Finally the code may be found : in github. I m looking forward to testing it.

Already available in both Maverick and Debian sid, it provides many interesting features. I m talkin about Font Manager, a small application written in C and Python by Jerry Casiano, which allows users to easily install, remove and compare font files on own system. Here are few nice screenshots:

To install the application, as usual type:

sudo apt-get install font-manager

Let me know what you think!

Links

• Project s homepage
• Debian PTS page

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

Just in case I forget the link again: 7 weeks ago (says git) I merged upstream 2.8.11.0 into the Debian packaging git. The changes are available at a personal alioth repo if anybody cares. Edit: I just wanted to file a bug, only to notice that I did this weeks ago. Need more memory!

Remember when I said Epiphany worked out of the box with Youtube s WebM? Well, Google has recently decided to deny us WebM, like it did before with Wave, the Pacman doodle, and who knows what else? \o/ Wouldn t it be nice if Google practiced what they preach? Update: so it looks like my message went through to the people who needed to see it, and they found a filtering error in the User Agent sniffing code that made it think Epiphany was a too old Safari - I m told the change will land in Youtube soon, thanks for those paying attention, and working on this! User Agent sniffing keeps being a problem, of course, and there are other stuff to fix, so I will probably still push my patch to spoof the user agent to google services which are still mishandling Epiphany, but it s good to see some progress being made! Update2: I started shipping a patch to send the Chrome user agent string to google domains in the Debian package for WebKitGTK+, when the enable-site-specific-quirks setting is enabled (which is the case for Epiphany); I already found something we were missing out on =D Google Images seems to have been greatly improved, and now faking being Chrome we are also able to enjoy it:

In all my born days, I never thought I'd be saying that. I've been a happy customer of Sonic.net for the entire time I've been in the US, but I recently became aware of an offer through work with Comcast Business that I couldn't refuse. So I've gone from to this You really can't beat it. I'll still recommend Sonic to all and sundry, but if you want some real speed (and with baby photos and videos galore to upload, I was really more interested in additional upload capacity), it's time to give DSL the flick.

As reported earlier, the last few days I have looked at how Debian Edu clients are configured, and tried to get rid of all hardcoded configuration settings on the clients. I believe the work to be mostly done, and the clients seem to work just fine with dynamically generated configuration. What is the point, you might ask? The point is to allow a Debian Edu desktop to integrate into an existing network infrastructure without any manual configuration. This is what happens when installing a Debian Edu client here at the University of Oslo using PXE. With the PXE installation, I am asked for language (Norwegian Bokm l), locality (Norway) and keyboard layout (no-latin1), Debian Edu profile (Roaming Workstation), if I accept to reformat the hard drive (yes), if I want to submit info to popcon.debian.org (no) and root password (secret). After answering these questions, the installer goes ahead and does its thing, and after around 50 minutes it is done. I press enter to finish the installation, and the machine reboots into KDE. When the machine is ready and kdm asks for login information, I enter my university username and password, am told by kdm that a local home directory has been created and that I must log in again, and finally log in with the same username and password to the KDE 4.4 desktop. At no point during this process did it ask for university specific settings, and all the required configuration was dynamically detected using information fetched via DHCP and DNS. The roaming workstation is now ready for use. How was this done, you might wonder? First of all, here is the list of things that need to be configured on the client to get it working properly out of the box:

• IP address/netmask and DNS server.
• Web proxy URL.
• LDAP server for NSS directory information (user, group, etc).
• Kerberos server for PAM password checking.
• SMB mount point to access the network home directory. (*)
• Central syslog server to send syslog messages to. (*)
• Sitesummary collector URL to submit info to central server. (*)

(Hm, did I forget anything? Let me knew if I did.) The points marked (*) are not required to be able to use the machine, but needed to provide central storage and allowing system administrators to track their machines. Since yesterday, everything but the sitesummary collector URL is dynamically discovered at boot and installation time in the svn version of Debian Edu. The IP and DNS setup is fetched during boot using DHCP as usual. When a DHCP update arrives, the proxy setup is updated by looking for http://wpat/wpad.dat and using the content of this WPAD file to configure the http and ftp proxy in /etc/environment and /etc/apt/apt.conf. I decided to update the proxy setup using a DHCP hook to ensure that the client stops using the Debian Edu proxy when it is moved outside the Debian Edu network, and instead uses any local proxy present on the new network when it moves around. The DNS names of the LDAP, Kerberos and syslog server and related configuration are generated using DNS information at boot. First the installer looks for a host named ldap in the current DNS domain. If not found, it looks for _ldap._tcp SRV records in DNS instead. If an LDAP server is found, its root DSE entry is requested and the attributes namingContexts and defaultNamingContext are used to determine which LDAP base to use for NSS. If there are several namingContexts attibutes and the defaultNamingContext is present, that LDAP subtree is used as the base. If defaultNamingContext is missing, the subtrees listed as namingContexts are searched in sequence for any object with class posixAccount or posixGroup, and the first one with such an object is used as the LDAP base. For Kerberos, a similar search is done by first looking for a host named kerberos, and then for the _kerberos._tcp SRV record. I've been unable to find a way to look up the Kerberos realm, so for this the upper case string of the current DNS domain is used. For the syslog server, the hosts syslog and loghost are searched for, and the _syslog._udp SRV record is consulted if no such host is found. This algorithm works for both Debian Edu and the University of Oslo. A similar strategy would work for locating the sitesummary server, but have not been implemented yet. I decided to fetch and save these settings during installation, to make sure moving to a different network does not change the set of users being allowed to log in nor the passwords required to log in. Usernames and passwords will be cached by sssd when the user logs in on the Debian Edu network, and will not change as the laptop move around. For a non-roaming machine, there is no caching, but given that it is supposed to stay in place it should not matter much. Perhaps we should switch those to use sssd too? The user's SMB mount point for the network home directory is located when the user logs in for the first time. The LDAP server is consulted to look for the user's LDAP object and the sambaHomePath attribute is used if found. If it isn't found, the home directory path fetched from NSS is used instead. Assuming the path is of the form /site/server/directory/username, the second part is looked up in DNS and used to generate a SMB URL of the form smb://server.domain/username. This algorithm works for both Debian edu and the University of Oslo. Perhaps there are better attributes to use or a better algorithm that works for more sites, but this will do for now. :) This work should make it easier to integrate the Debian Edu clients into any LDAP/Kerberos infrastructure, and make the current setup even more flexible than before. I suspect it will also work for thin client servers, allowing one to easily set up LTSP and hook it into a existing network infrastructure, but I have not had time to test this yet. If you want to help out with implementing these things for Debian Edu, please contact us on debian-edu@lists.debian.org. Update 2010-08-09: Simon Farnsworth gave me a heads-up on how to detect Kerberos realm from DNS, by looking for _kerberos TXT entries before falling back to the upper case DNS domain name. Will have to implement it for Debian Edu. :)

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>

Today I bought a box of fries from The Lord of the Fries [1]. I bought it from their new stand at Flinders St station because I was going past and saw no queue. In the past I had considered buying from their store on Elizabeth St but the queues were too long. The fries were nice probably among the best fries that I ve had from local fish and chip shops. Way better than any other fries that you can find in the center of Melbourne. The range of sauces is quite good if you like that thing (I just like vinegar on mine). However it should be noted that the quantity of chips that you would get for the same price at a local fish and chip shop is usually a lot greater. Overall I was a bit disappointed, sure it s nice to have someone hand-cut fresh potatoes and to actually care about making a quality product. But when compared to the other options for relatively fast food in the CBD it didn t seem that great to me. I m never going to join a queue that has more than 20 people to buy them! But I probably will buy from them on occasion if they don t have big queues. It seems to me that the best thing that they have done is to create a strong commitment to food quality and document it on their web site. I hope that this will inspire other fast-food companies to do the same thing and result in an overall increase in the food quality. On a related note Jamie Oliver has an IDEO project running with the aim of getting kids into fresh food [2].

• [1] http://www.lordofthefries.com.au/
• [2] http://blog.ted.com/2010/08/02/help-jamie-oliver-gets-kids-into-fresh-food-with-openideo/

Well, I m back in Kansas after a bit over a week in New York for Debconf. I didn t have time to write much, so I ll probably be posting about it a few times. I already wrote about the trip to New York, and now will say just a bit about the time there and trip back home. I have to start with a quote from Jacob. We went on the Q train from Coney Island a few stops down to Brighton Beach. It s elevated, and provides an excellent view of the amusement park. Jacob s excited comment, face pressed to window, was: Wow! I see lots of everything! Which, come to think of it, sums up NYC itself pretty well. Speaking of faces pressed to windows: this was Jacob s default mode of operating in NYC. Get into any subway car, bus, whatever and he wants to stand on the seat nearest the window and look out it. It s a real problem if no such seats are available. More than once, though, we ll get on the subway and he ll run to the nearest window seat to claim it, no matter who will be his neighbors for the next few minutes. And after a few days of this, Oliver started picking up on it. Pretty soon both boys wanted to be pressed to the windows watching interesting things (to me, it was a dark tunnel with occasional lights, but interesting to them) go by. Which brings me to today. Today was Oliver s first time flying, and Jacob s second though he was an infant the first time he flew and doesn t remember it. Jacob has been perhaps cautiously optimistic about flying. The idea of it was exciting, but then again it s something completely new, which he doesn t care for so much. So we had no idea what to expect. What was got was excitement. And lots of it. From the La Guardia terminal, Dad, is this our plane? No, not that one. Well, is THIS our plane? No, not that one either. Well, is *THIS* our plane? At this point, a parent has to confront the question: which is worse, causing serious disappointment to a 3-year-old and possibly inviting a meltdown in the middle of the D concourse, or a bit of harmless encouragement that might not be 100% literally true? Uhmm . that might be it (Ah, so I went for the literally true but still exciting route ) YAY!! *jumping and clapping* Terah reminds me at this point of our security adventure. I, wearing socks, carried Oliver (1 year old) through the security checkpoint at La Guardia. But oh! I failed to remove his shoes (not really shoes). TSA made me go back through, put them in the bowl, and run them through the scanner. A nearby pilot, getting screened, noticed this and made this ironic comment well within TSA earshot: Look at his face! He s gonna get us all! Good thing you re checking his shoes! Terah and the pilot both just about bust up laughing. Meanwhile, I m carrying Oliver through, and the agent that made me take off his shoes had this look of I m sorry, I know this is stupid, but I have to. (For an excellent pilot s rant about TSA, read this). Anyhow, we got on the plane, and of course Jacob nabbed the window seat. There was plenty interesting to see. At each step of the way, I told him what was going to happen next, so there wouldn t be any surprises. I told him once we got in the air, and got a breathy Woooooooow .. I told him, Jacob, we are flying! And his reply has to be his best quote of the week:

Dad, I don t know that I ve ever been a butterfly before!

I pointed out that we were above the clouds, which was also exciting. About every 5 minutes, he d poke me, and say, Dad, look out the window. Look down. WE ARE UP IN THE SKY! Meanwhile, Oliver slept. On the second flight, Jacob slept (and was in a very foul mood when he woke up on the ground) while Oliver tried his best to squirm out of the seat and onto the ground. Now, to wind up this post, I would like to leave you with some statistics and photos comparing my home with New York.

Item	NYC	Marion County, KS
Land Area	469 sq mi	954 sq mi
Population	8,391,881	12,952 (6871 excluding the 3 largest towns quite some distance away)
Population Density	27,532/sq mi	14/sq mi (7 if excluding large towns)

I think of this as a wonderful difference! I ve said before how much fun it is to spend some time in NYC, where we can just walk to a fruit stand, any number of grocery stores, restaurants, etc. And finally, I leave you with two street scenes. The first is from our hotel s front door. That s our fruit guy there, and the bagel and roll place is across the street by the RadioShack. Now, the street view from our front door after we got home: OK, so that s sort of misleading. You can t actually see the street scene because it s on the other side of the hill. That s just our driveway to get to the street. (Not that the street looks much different. It has the weeds growing on the sides instead of in the middle, as one notable difference.) We loved New York and I m certain we ll go back again. It s also nice to be home and enjoy the peace of the countryside. Thanks to Debconf for a wonderful conference a topic I ll have more to say about in the coming days.

A few days ago, I tried to install a Roaming workation profile from Debian Edu/Squeeze while on the university network here at the University of Oslo, and noticed how much had to change to get it operational using the university infrastructure. It was fairly easy, but it occured to me that Debian Edu would improve a lot if I could get the client to connect without any changes at all, and thus let the client configure itself during installation and first boot to use the infrastructure around it. Now I am a huge step further along that road. With our current squeeze-test packages, I can select the roaming workstation profile and get a working laptop connecting to the university LDAP server for user and group and our active directory servers for Kerberos authentication. All this without any configuration at all during installation. My users home directory got a bookmark in the KDE menu to mount it via SMB, with the correct URL. In short, openldap and sssd is correctly configured. In addition to this, the client look for http://wpad/wpad.dat to configure a web proxy, and when it fail to find it no proxy settings are stored in /etc/environment and /etc/apt/apt.conf. Iceweasel and KDE is configured to look for the same wpad configuration and also do not use a proxy when at the university network. If the machine is moved to a network with such wpad setup, it would automatically use it when DHCP gave it a IP address. The LDAP server is located using DNS, by first looking for the DNS entry ldap.$domain. If this do not exist, it look for the _ldap._tcp.$domain SRV records and use the first one as the LDAP server. Next, it connects to the LDAP server and search all namingContexts entries for posixAccount or posixGroup objects, and pick the first one as the LDAP base. For Kerberos, a similar algorithm is used to locate the LDAP server, and the realm is the uppercase version of $domain. So, what is not working, you might ask. SMB mounting my home directory do not work. No idea why, but suspected the incorrect Kerberos settings in /etc/krb5.conf and /etc/samba/smb.conf might be the cause. These are not properly configured during installation, and had to be hand-edited to get the correct Kerberos realm and server, but SMB mounting still do not work. :( With this automatic configuration in place, I expect a Debian Edu roaming profile installation would be able to automatically detect and connect to any site using LDAP and Kerberos for NSS directory and PAM authentication. It should also work out of the box in a Active Directory environment providing posixAccount and posixGroup objects with UID and GID values. If you want to help out with implementing these things for Debian Edu, please contact us on debian-edu@lists.debian.org.