(This blog has slept since I wrote the previous post. That post had to wait for a year to be made public! Anyway, here I go again ) One of the ways people characterise science and technology is by saying that science is about prediction and technology is about design. This is not wrong but I feel that it misses something. An astrologer too claims to predict the future and claims to tell you how to re-design your future. So the above explanation of science and technology could make it indistinguishable from magic! One thing that does distinguish science is that the prediction and design is done by calculation ; this is not restricted to mathematical calculation but includes recipes like mix so much of this reagent with so much of that solvent . In fact, the notion of calculation can be expanded to anything that I can teach someone else to do even an idiot like a computer. This leads us to the view that science is not only about making predictions and designing things but also about teaching others to do the same. At the very first level, this is done by providing formulas which other people can use to make predictions and design things. However, this is not quite far enough, since it would still make the act of creating these formulas a magical thing! So we must take this a step further and be able to teach others how to create their own formulas. In other words, we want to provide formulas for creating new formulas. It does look as if we could be in infinite regression here, for who will then create formulas to provide formulas for creating new formulas! Luckily, the monadic thinking of Turing helps us here. He realised that formulas for creating new formuals are themselves just (slightly more complicated) formulas. Just as a gift-wrapped box containing a gift can be thought of as just a box containing a gift.

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?

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:

Those old school ones among us that still need a printer who are new school enough to want to get rid of HAL should try system-config-printer from experimental. After replacing hal-cups-utils by system-config-printer-udev aptitude tells me:

    The following packages will be REMOVED:
      hal u  hal-info u  
    0 packages upgraded, 2 newly installed, 2 to remove and 121 not upgraded.

Which means faster startup times and one daemon less on Squeeze's GNOME desktop. The new version also uses PolicyKit instead of gksu for finer grained permission control.

Mum's been to the hospital today for some test results and apparently they've found some cancer. This is a bit of a shock for all of us, as you might imagine. The doctors now need to do some more tests to help find out what they can do. We're waiting with fingers crossed now...

I know I have not updated this blog in quite a long time now, but something caught my attention today: canonical-census.

As slashdot.org reports Canonical begins with tracking their (OEM) installations. Now it's obvious that people are uncomfortable with a program running on their system which phones back to their OS vendor, that's why I have had a quick look at what exactly canonical-census does.

Firstly however, I would like to point out that the report on slashdot.org is very clear about which information is being gathered, being "the number of times this system previously sent to Canonical [...], the Ubuntu distributor channel, the product name as acquired by the system's DMI information, and which Ubuntu release is being used". And it's perfectly correct. After getting the canonical-census Debian source package (using dget -u https://launchpad.net/ubuntu/+archive/partner/+files/canonical-census_0.1.dsc) the source package shows, besides the Debian packaging information, two scripts:

• census (written in Python) and
• send-census (a GNU bash script).

3 interesting small things happened in the weekend. Due to the hard work of mostly Florian Reinhard and George Kiagiadakis, Bluedevil is now available. Bluedevil is a new and improved bluetooth handling thing targetted the KDE Workspaces. The Debconf people have uploaded the Qt Debconf frontend that I blogged about a while ago, so now it should be available. Last, but not least, applications now has more accurate data for if they are online or not, by using the ntrack library. This was especially problematic for people having some interfaces defined in /etc/network/interfaces, and other interfaces managed by NetworkManager.
This feature will be committed to upstream KDE whenever Will gets around to do it. As a added bonus, KDEBindings in Debian has seen a release critical bugfix (python plugins, e.g. plasma widgets, related), and the brokenness of Konsole (libkpty) on the kFreeBSD-arches have been tracked down to a libc issue and a patch has been made. All of this is expected to be part of next stable Debian release, codename Squeeze.

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.

So, DebConf time is over once again. The two weeks worth of fifty weeks waiting are left behind once again, and it's back to get back to normal. DebConf was great Yes, it always is, and that's what we are all saying, but hey - Seriously! Being in the same building than 300 crazed developers is always fun, and it's always better than last year's fun. A good highlight this year is that, given the number of Free Software and Free Culture groups that exist in USA's north-eastern coast, we had the opportunity to join a large crowd which has never been part of DebConf. Also, I must agree that the USA bid for DebConf was aiming to attract as many Debian people (developers, maintainers, or just happy users) which had not yet been to a DebConf before as possible. And it was a great success! I finally met several people I have long read in the mailing lists, in blogs or in IRC. A much higher proportion than usual, I'd venture to say. Another interesting phenomenon /methinks is that this year's DebCamp started much more staffed than usual: I arrived on the first day, Sunday 25, and there were ~40 people there already; I don't have the actual numbers, but we quickly grew, and the number started to stabilize past mid-week, only to (sharply) rise in the weekend, in time for DebianDay and DebConf start. Great time! But, they say, nobody can go to the USA without buying some sweet toys, right? Well, being the proud owner of six very hairy cats, I have thought into entering the looming and weaving industry... But cat hair, while abundant, I have heard is untreadable... Maybe due to the indisciplined, natural and independent personality of the cats (catonality should I say?)... So I had two choices: Clean up my home quite often, or live in a literally hairy mess. Enter choice #3: The Roomba! I had been waiting to buy this thing for several years, as they refuse to send to Mexico or charge Mexican cards. So, I walked across Manhattan and got my very own robot cleaner! For my further surprise, although I have not yet tried it (I don't even have a suitable cable yet), I found this: Yay, the Roomba is actually hackable (via a 7 pin miniDIN serial port)! Wikipedia says that:

Roomba comes with a Mini-DIN TTL serial interface, which is incompatible with standard PC/Mac serial ports and cables, both electrically and physically. However, third-party adapters are available to access the Roomba's computer via Bluetooth, USB, or RS-232 (PC/Mac serial). New, 500-series, and 410/420 series Roombas upgraded with the OSMO hacker device allow the user to monitor Roomba's many sensors and modify its behavior. The Roomba Open Interface (formerly "Roomba Serial Command Interface") API allows programmers and roboticists to create their own enhancements to Roomba. ( )

My first impressions? Well, the Roomba lazily charged its battery throughout the day today, and was hungry and ready when I arrived home. It is a but louder than what I expected, and of course my cats were not thrilled by the presence of a eighth animated and apparently sentient being at home. Their initial reaction was of course to be verrry alert of the thing. Twelve eyes were constantly pointing at the Roomba while mine alternated between them. As they measured the thing's speed and (I guess) inferred its movement patterns, they started escaping upstairs A flat, round thing with no legs to be seen will not likely be able to climb the stairs. And they were completely right. At first, only Chupchic remained downstairs. After a bit, I went up to show them the Roomba didn't jump on us to eat our brains, and after a bit, Santa and Macusa joined. The Roomba roombed for maybe 90 minutes (this space is large, and decided it was enough... And slowly, the rest of them started coming down. I would not say Roomba's cleaning is perfect, of course. Its room discovery algorithm is funny, and it even seems it's based on the mere chance of covering most (never all) of the space it has to clean. I had, of course, not fully studied it (after a single run, how could I?). It does make a honestly good attempt at cleaning under coaches, chairs and tables. It collected a fair amount of dust (on a house that seemed quite clean to me, I cannot imagine what would happen on a messy one). I have not yet played with the virtual walls (infrared transmitters which limit rooms as if a door was closed), but given the size of this house (and that I don't want it to clean around the cats' designated bathroom area), I guess I will end up using them regularly. During DebConf, I heard one bad (stupid useless noisy thing) and two very good (it has radically changed my life) comments on the Roomba. I hope to shift the balance towards 3/4 and not towards 2/2! Anyways... Thanks to each and every one of you. DebConf is great. Always great. Always a success. I cannot even thank specific teams. Debian Rules, and DebConf Rocks!

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.

A fresh release of RQuantLib is now on CRAN and in Debian. RQuantLib combines (some of) the quantitative analytics of QuantLib with the R statistical computing environment and language. This follows the 0.3.3 release from last week and has again a number of internal changes. All uses of objects from external namespaces are now explicit as I removed the remaining using namespace QuantLib;. This makes things a little more verbose, but should be much clearer to read, especially for those not yet up to speed on whether a given object comes from any one of the Boost, QuantLib or Rcpp namespaces. We also generalized an older three-dimensional plotting function used for option surfaces -- which had already been used in the demo() code -- and improved the code underlying this: arrays of option prices and analytics given two input vectors are now computed at the C++ level for a nice little gain in efficiency. This also illustrates the possible improvements from working with the new Rcpp API that is now used throughout the package, Full changelog details, examples and more details about this package are at my RQuantLib page.

rainbow-mode had a big success and good feedbacks when I released it for the first time a couple of months ago. Several users asked to me request its inclusion into Emacs. Therefore, some days ago, I proposed to merge it inside Emacs trunk. My request has been denied, but the mode has been added to the Emacs 24 package repository. In the mean time, I've added support for hsl() and hsla() support, and added CSS 3/SVG color names.

Recently I've been jumping upon the LDAP bandwagon, with one of my aims to consolidate a lot of different login systems. Configuring Linux, Apache, OpenVPN and similar things to authenticate against an LDAP server was almost painless. Unfortunately OpenBSD is being a bit more painful, primarily because it doesn't use PAM. Instead you have two choices:

• Configure login to authenticate against a RADIUS server, telling that server to authenticate against a (remote) LDAP server.
• Use login_ldap to do authentication, but fetch all things via YP.

Neither solution is particularly pleasant, but the former is marginally less effort. The downside? I still have to run "adduser" to add the user to the system - which makes me think "why did I bother in the first place?" Otherwise I spent the tail end of last week in York, taking pictures of ducks, geese, the city walls and similar things of fun. ObQuote: "Well, well I see we have visitors... " - Hot Fuzz

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. :)

DebConf was really an awesome conference. I m happy that I have finally met so many of the fellow Debian people I only knew from the mailing lists or planet. There where lot s of interesting talks, the hacklabs where always busy, and the overall atmosphere was very good. Now that I m back in Berlin, I m already missing it I m by the way also missing my luggage which is apparently still at the JFK airport. This was my first DebConf, but definitively not my last. I encourage people who never made it to DebConf: Get your butt up and register for the next conference! You don t know what you re missing. If money is an issue: there is a sponsoring which you can apply for and chances are good that you ll get at least partially sponsored. Big thanks to all the volunteers who helped to organize and run this conference and to SPI for sponsoring my trip, food and accommodation! I m looking forward seeing some of you again in three weeks at Steve s place in Cambridge for a nice BBQ and the rest of you next year in Bosnia and Herzegovina!

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>

If you haven't seen it, try to. Amazing this movie did not get any major awards. Maggie Gyllenhaal is well worth looking out for in other movies.

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.