Although I often don t agree with Erich (especially if GNOME is involved ;-), he recently posted something on Planet Debian which I found very helpful. I also own a netbook where disk space is sacre. It s an ASUS EeePC 701 with just 4GB disk space. And it runs Debian Sid, so dependencies change often, leaving packages installed which formerly had hard dependencies on, but are now left with just recommendations pointing to it. Quite a few times I asked myself if it s possible to find those packages and if so, how to do it. Well, I don t have to ask myself that anymore, since Erich recently posted the appropriate filter patterns for my favourite package manager aptitude for this task in his posting Finding packages for deinstallation . Thanks, Erich! Since those filters aren t very easy to remember, I d like to extend the usefulness of his posting towards the commandline. I for myself added the following aliases to my shell setup:

alias aptitude-just-recommended='aptitude -o "Aptitude::Pkg-Display-Limit=!?reverse-depends(~i) ~M !?essential"'
alias aptitude-also-via-dependency='aptitude -o "Aptitude::Pkg-Display-Limit=~i !~M ?reverse-depends(~i) !?essential"'

As youam suggested on IRC, I also added the filter !?essential since we won t touch essential packages when cleaning up the list of installed packages anyway. Hope this helps further.

The next 16 of april in hannover at the hotswup workshop we'll present a joint work with Roberto Di Cosmo prepared in the context of the mancoosi project. Since we used debian for our experiments, we're also very much interested in the feedback from the community regarding our method. However keep in mind that this is still work in progress and to be considered as research more then a proposal for a concrete application. This is part of our on-going effort of exploring different areas with the goal of providing tools and ideas to enhance the quality of FOSS distributions.

Abstract

  Upgrades in component based systems can disrupt other components.
  Being able to predict the possible consequence of an
  upgrade just by analysing inter-component dependencies can avoid
  errors and downtime. In this paper we precisely identify in a
  repository the components p whose upgrades force a large set of
  others components to be upgraded. We are also able to discriminate
  whether all the future versions of p have the same impact, or whether
  there are different classes of future versions that have different
  impacts.  We perform our analysis on Debian, one of the largest
  FOSS distributions.

---

you can find more info about this paper here

forked-daapd v0.15 is here! The database speedups did not make it into this release as they still need some more work. Now let s talk about what did make it into this release: AppleTV metadata support. When streaming to an AppleTV, you ll now get the cover art, artist, album, title and playback position displayed on your TV. This was made possible by a forked-daapd user who offered me one of the new AppleTVs, so thanks much to him! Although we haven t got the database speedups this time around, we ve got some other speedups:

• the code generating the song list was slightly reworked;
• hash tables of static data were replaced with static hash tables generated by gperf;
• the artwork code can now send out both PNG and JPEG to clients.

The first two items bring in a new build-dependency: gperf. I promise it s not some Java-based monstrosity ;) It s small and C++, so no issue getting that running on whatever your platform is. Pre-generated files are not provided for this. The last item means if your cover art is mostly JPEG, forked-daapd won t be spending time turning it into PNG before sending it out to the client. That s some CPU time that can be put to better use. Next release: when it s ready! For Squeeze users, I am providing backports on backports.debian.org; due to the update policy, they are lagging behind the releases. Tarballs available at http://alioth.debian.org/~jblache/forked-daapd/ ; GPG signatures made with my Debian key F5D65169.

I've got a Debian GNU/Linux lenny installation (2.6.26-2-vserver-amd64 kernel) running on a Dell Poweredge 2950 with BIOS 2.0.1 (2007-10-27). It has two Intel(R) Xeon(R) CPU 5160 @ 3.00GHz processors (according to /proc/cpuinfo, 8 1GiB 667MHz DDR2 ECC modules (part number HYMP512F72CP8N3-Y5), according to dmidecode, and an Intel Corporation 5000X Chipset Memory Controller Hub (rev 12) according to lspci. The machine has been running stably for many months. On the morning of March 31st, i started getting the following messages from the kernel, on the order of one pair of lines every 3 seconds:

Mar 31 07:04:38 zamboni kernel: [16883514.141275] EDAC i5000 MC0: NON-FATAL ERRORS Found!!! 1st NON-FATAL Err Reg= 0x800
Mar 31 07:04:38 zamboni kernel: [16883514.141278] EDAC i5000: 	NON-Retry  Errors, bits= 0x800

A bit of digging turned up a redhat bug report that seems to suggest that these warnings are just noise, and should be ignorable. Another link thinks it's a conflict with IPMI, though i don't think this model actually has an IPMI subsystem correction: this machine does have IPMI, though i am not making use of it. However, i also notice from munin logs that at the same time the error messages started, the machine exhibited a marked change in CPU activity (including in-kernel activity) and local timer interrupts: I also note that more rescheduling interrupts started happening, and fewer megasas interrupts at about the same time. I'm not sure what this means. A review of other logs and graphs on the system turns up no other evidence of interaction that might cause this kind of elevated activity. One thought was that the elevated activity was just due to writing out a bunch more logs. So i tried removing the i5000_edac module just to keep dmesg and /var/log/kern.log cleaner. Leaving that turned off doesn't lower the CPU utilization or change the interrupts, though. Any suggestions on what might be going on, or further diagnostics i should run? The machine is in production, and I'd really rather not take down the machine for an extended period of time to do a lengthy memory test. But i also don't want to see this kind of extra CPU usage (more than double the machine's baseline).Tags: i5000_edac, troubleshooting

thttpd is a simple, small, portable, fast, and secure HTTP server which supports both IPv4 & IPv6. However one noticable omission in the handling of requests for thttpd is support for the X-Forwarded-For header - which is even noted upo nthe thttpd wikipedia entry. There is a simple patch floating around which claims to fix this; but as I belatedly noticed tonight it only works for IPv4. If you look at libhttpd.h of the thttpd source you'll see this:

typedef union  
    struct sockaddr sa;
    struct sockaddr_in sa_in;
#ifdef USE_IPV6
    struct sockaddr_in6 sa_in6;
    struct sockaddr_storage sa_stor;
#endif /* USE_IPV6 */
      httpd_sockaddr;

As a quick hack I updated this structure to add the following member:

    char real_ip[200];

Now I could update that member when a client connects and later update it as a result of any X-Forwarded-For: headers which might be present in incoming requests. Finally I updated the logging to use this field rather than anything else and the job was complete. Without this work if you're running as a proxy and you receive an IPv6 connection you'll see it reported as 127.0.0.1. I'm sure my approach isn't as clean as it could be - due to the extra member- but it will suffice for now. ObQuote: "This gun you're holding belonged to your father; he could conduct a symphony orchestra with it. " - Wanted

Internship / APT stuff This week was a rather busy week. I m currently doing a (unpaid) 1 month internship as part of my education. Thanks to Michael Vogt and his boss at Canonical Ltd, this internship takes place in IRC and is dedicated to Debian and Ubuntu stuff, primarily APT-related things. The first two days were spent on multi-arch support in python-apt: On Monday, I released python-apt 0.7.100.3, introducing initial minimal multi-arch support (just enough to not break anymore, but no really new multi-arch-specific API). This release is also the base for the version going to be shipped in Ubuntu natty, which is one of the reasons to keep the changes such minimal. I also fixed an RC bug related to Python 3.2 modules in python-apt, and implemented nocheck build option and disabled test errors on hurd. On Tuesday, I released python-apt 0.8.0~exp1 to experimental. This release now has the old-style non-PEP8 API disabled and also introduces improved multi-arch support, by introducing bindings for APT s GrpIterator class, and supporting indexing the cache by (name, architecture) tuples. On Wednesday, I noticed a strange bug in APT (via python-apt s test suite) where what the cache considered the native architecture was not the configured one. David Kalnischkies and I debugged the problem, and he found the source of the problem and implemented a fix in his branch of APT. I also introduced multi-arch support for the aptsources module, fixed all Python 3.2 ResourceWarnings in python-apt, and prepared an NMU for python-debian, to adjust it to python-apt s new API. I also took over maintenance of software-properties in Debian, and did two uploads there (rebased on the Ubuntu package), both with python-apt 0.8 API support. On Thursday, I shifted a bit more to the Ubuntu side and fixed several bugs in APT and aptdaemon, resulting in the aptdaemon 0.41+bzr614-0ubuntu2 upload and apt 0.8.13.3ubuntu2. I also fixed software-properties KDE version in Debian, as I broke it the previous day. Today, on Friday, I fixed one more bug in APT. APT now treats Release files that cannot be verified identical to Release files without signature, that is, they are actually parsed now (no more missing Origin fields) see LP: #704595. dh-autoreconf 3 I uploaded dh-autoreconf 3, fixing all bugs in the BTS except for one (if someone knows why autopoint depends on git, please tell me, and I may fix this bug as well). For those who don t know dh-autoreconf, it is a tool to run autoreconf automatically during the package build, so no need for manual cleanup or autoreconf patches. I now thought about adding the option to automatically patch ltmain.sh to dh-autoreconf. As many know, ltmain.sh does not work correctly with -Wl, as-needed. Now, if the libtool maintainer cooperates and provides a patch file in the libtool binary package, dh-autoreconf could automatically apply it during build-time, thus fixing this problem as well. GNOME 3 I m now running GNOME 3, or the parts of it we have in Debian. Next week We ll probably see python-apt 0.8.0~exp2 next week with more improved multi-arch support and other fixes.
Filed under: Debian

Well, I still don t feel ready enough to go back to (real) work. So, once more, I had to get my fingers on something to hack and I picked the Buildd Status Pages once more. It s not my favorite project, but I decided to implement the few remaining ideas and get (temporarily) done with it. So, here we are with new features (and a few bug fixes):

• Add option to show (co-)maintained packages (Closes: #559515, #507782). It takes as input two files (Maintainers and Uploaders) to find the list of packages. Unfortunately, they contain binary packages (and particularly architecture all packages) that wanna-build doesn t know anything about. On buildd.debian.org, I don t have enough data (yet) to filter out that list manually. Ideally, my input should be a list of sources packages with at least one binary non architecture all packages only. Anyway now, if you enter an email address, the script should parse those files looking for your list. Then, it adds a link to DDPO using that email address and replaces it by the list of found packages in the form, so that you can manually filter it.
  Update: I ended up filtering manually the list of packages. I keep only packages that wanna-build knows something about, on at least one architecture.
• Escape special HTML characters when we fetch a log (Closes: #621739). No comment on this one please At least, it was very easy to fix.
• Add a raw option to fetch.php so that it outputs only what s in the log file, without any processing or escaping.
• Add a link to buildd.debian-ports.org, with the same list of selected packages and suite. Additionally, I ve made some changes so that the deployment there becomes a bit easier.
• Try to produce valid XHTML code. I just went through errors I ve seen and fixed them. The produced XHTML code is rather simple. So, I don t need a real library for that yet.
• Add support for tail of logs. If your package fails to build on some architecture, the script will show you the last 15 relevant lines below the status table.

In my opinion, this new set of features deprecates totally the old version, since all (and more) is now covered and working with this new version. So, I think we can remove pkg.cgi and friends and put some redirection to the new scripts. If you disagree, please tell us ! I ll submit a bugreport to QA folks asking them to change/remove links still present on the PTS and DDPO. I think that this is the last set of changes before a while (except fixes). I hope that you ll enjoy these new features as much as I do. If I still have some energy, I ll try to spend it on -release stuff where there are several ongoing transitions (and many others waiting for acks, hints, analysis, etc ).

On next Monday this cycle s Ubuntu Application Developer Week classes will start. The topic that kept me busy most in this cycle was Python gobject-introspection, and porting pygtk2 apps to PyGI (see my initial steps and my report from the PyGI hackfest.) To spread the love, there will be two talks about this next week: On Monday 17:00 UTC the very Tomeu Vizoso himself will explain what gobject-introspection ( GI ) is, why we need it, and how library developers use it to ship a good and useful GI binding ( typelib ) for application developers. I will then follow up on Tuesday 16:00 UTC about the app developer side, in particular how to use the GI typelibs in Python, and how to port PyGTK2 applications to PyGI. For the most part these sessions are distribution neutral (we don t have any special sauce for this in Debian/Ubuntu, it all happened right upstream ); only a very small fraction of it (where I explain package names, etc.) will be specific to Debian/Ubuntu, but shouldn t be hard to apply to other distributions as well. So please feel invited to join, and bombard us with questions!

It's incredible how many people are of the misguided belief that just because I happen to run a company, I am automatically interested in their newsletter about whatever it is that they are doing, no matter how far it is removed from the kinds of things my company actually does. Are these people spammers? Yes, definitely, and I don't want to do business with them. But there's a major difference between this kind of mails and your common nigerian scammer or counterfeit blue pill "salesperson". Unlike the latter, some newsletter spammers are interested in forming a genuine business relationship with my company. They're going about it the wrong way, but that doesn't necessarily mean they're trying to trick me into doing something that would not be in my best interest they're not just after my money. Although their methods are wrong, that does not mean they're entirely clueless. Some of these unwanted newsletters are sent with VERP-style return paths, which suggests that if the mail bounces at SMTP time, I would no longer receive their junk. So bouncing them is what I do. Exim makes this very easy:

acl_check_mail:
  deny
	message = Your domain has been blacklisted
	log_message = domain blacklisted
	condition = $ 
			lookup $sender_address_domain 
			wildlsearch /etc/exim4/blacklist-domains 
			 true 
			 false 
		      
  accept

What this does is use a wildlsearch lookup to verify whether the domain of the envelope sender (i.e., as specified in the MAIL FROM: SMTP command) exists in the /etc/exim4/blacklist-domains file. Since we use a wildlsearch, we can use the * as a wildcard *grep.be would mean 'grep.be, or any of its subdomains', whereas *.grep.be would mean 'any of the grep.be subdomains'. This is because at least one of the people I've blacklisted that way sends their newsletter through a distributed service, and the VERP-style header is based upon the server that actually communicates with my system; and others have a subdomain for the newsletter, but don't use it (or use a different one) for regular mail. If I'm not interested in their spam, I'm probably also not interested in their other mail, so therefore the wildcard (is this overkill? Maybe, but I don't care I don't do business with spammers). This ACL is then activated for the SMTP MAIL FROM: command (search for acl_smtp_mail variable in the exim specification). This makes it impossible for the spammer to reach postmaster@ from the same domain, too, but that doesn't matter; they can always use a different address. One might be wondering why I'm using this kind of domain-based blacklisting rather than a regular bayesian spamfilter, or anything of the sorts. The reason is fairly simple: because the general format of these newsletters is distinctly different from regular spam. For instance, some of these newsletter spammers are in fact competitors who didn't bother to check who they're sending mail to. As a result, their newsletters would contain key words that would appear in mails which I send to my regular customers, too; if I were to classify them as spam in my bayesian classifier, that would increase the chance of the classifier misclassifying a mail from an actual customer as spam. Most of these are very similar in format to newsletters that I did consciously subscribe to, and which are therefore not spam, etc. Finally, bouncing mail rather than blackholing it or filing it in a separate folder (as I have spamassassin do) has the added advantage of making it clear to a newsletter spammer that their junk is not wanted. Most (though certainly not all) will then remove me from their newsletter, saving me bandwith and processing power. And since we do this at MAIL FROM: time, rather than upon completion of the RCPT TO: or DATA commands, I'm not actually giving away any information that they don't have, either.

I just completed the release of apt-offline version 1.1. This release has many bug fixes, adds basic proxy support and has a new Advanced Options window for the Get operation.

Hello When a project comes with configuration files, project developers have to write configuration doc. Be it as man pages or as comments in configuration files. This is a boring, but necessary task to provide documentation to users. There s a way to get more with a similar effort. By writing this doc as models (i.e. in a format usable by Config::Model), you will get:
- generated man pages
- configuration GUIs
- configuration command line And with a little extra effort, you will also get:
- immediate validation data entered by user
- configuration upgrade tools But let s focus on generating documentation. A configuration model is more or less a list of configuration parameters with their constraints and description. In previous versions of Config::Model, the parameter description was used to generate online help in the GUI. Parameter description is now also used to generate configuration documentation. The constraints which are used to validate user input, are also used to provide more details to the documentation of the parameters. The help text in the model that will be used to generate doc can be plain text or contain pod markups to enhance the look of the doc (be it generated or displayed in the GUI). Here are some links to some example of models and the corresponding generated documents:

Debian::Dpkg::Source	model	generated doc
Debian::Dpkg::Copyright	model	generated doc
Sshd	model	generated doc

To generate these doc, a command like this one was added to the build process: config-edit -model Sshd -model_dir lib/Config/Model/models -gen_pod lib The generated pod files can then be converted to man pages, plain text, html depending on your needs. Feel free to send a mail on config-model users list (config-model-users at lists.sourceforge.net) if you need help. All the best

Reading GSoC applications is sometimes funny. This year I've decided to be active only in phpMyAdmin projects, but this still gives enough interesting texts. Some people definitely did not even care about looking at our name and think phpMyAdmin is written in C:

I assume this project would require C/C++ programming and, of course, SQL.

We ask people to tell us a little about their real life, in most cases this includes information where did the student study and so on, but sometimes it is just:

I'm a fairly standard guy.

In some cases people rather use some random file sharing service to post their CV and I'm too impatient to wait for several minutes till free download is available and I'm definitely not going to pay to download it. PS: As usual, the last day we receive most incomplete proposals over the time. Generally I think that the best proposals arrive at beginning and the quality lowers. This is probably heavily influenced by our requirements for students to know the code before and advertising GSoC early, so that the really interested ones are ready to submit proposals as soon as the interface is open, while others trying to catch train later.

Filed under: English Phpmyadmin 1 comments Flattr this!

Yesterday one of my free software halves was very, very happy, because after a lot of work, GNOME 3 was released!

I've been following GNOME 3.0's development since Debian got the first GNOME Shell snapshots uploaded to experimental. While my first experience, on an old, 2 or 3 generations behind Athlon 800MHz with 512MB of RAM was horrid due to the lack of features (it wasn't even an alpha!) and the incredible slowness due to the crappy Radeon 9200, I've seen it evolve to the gem that was released yesterday. I haven't been so excited about GNOME since GTK+ and GNOME 2.0 were released after their eternal development cycle, and was happy to see how positive the atmosphere in #gnome-hackers was last night when vuntz sent the email and everyone was able to relax after a very long sprint of hard work. Congratulations everyone, because not only this a great, solid release, but it's also a brave one. Change does not come without resistance, but I am very sure the path GNOME opened last night has a bright and innovative future. I will be delighted to walk this path to enjoy it!

Madeleines / Magdalenas (http://en.wikipedia.org/wiki/Madeleine_%28cake%29), home made, and Jolly Roger themed!
And Flan: 4 minutes, pressure cooker made, Cr me caramel (http://en.wikipedia.org/wiki/Cr%C3%A8me_caramel)
I adapted the recipes to make them healthier (fructose instead of sugar, whole brown flour instead of white, refined one).

Volume 40 of of the (electronic) Journal of Statistical Software just came out. It contains my short review of Josef Adler's already pretty popular R in a Nutshell from O'Reilly. You can my review as a pdf via this local preprint, or by visiting the JSS page of the review and its official copy.

Wouter says he's going to drive to DebConf this year (from Belgium to Bosnia). There's a number of folks from the UK looking to do the same thing, and there's time for more people to join us yet. Maybe we'll see you en route Wouter!

Another pure maintenance release, this time of RcppClassic, the package supporting the deprecated older classic Rcpp API defined in the earlier 2005 to 2006 releases, is now on CRAN It contains no new code, but smoothes one or two edges in the build process and noticed by the newest versions of R CMD check, just like yesterday's RcppGSL release. Courtesy of CRANberries, here are the changes to the previous release.

Diff between RcppClassic versions 0.9.0 dated 2010-12-20 and 0.9.1 dated 2011-04-07
 RcppClassic-0.9.0/RcppClassic/build                                                  only
 RcppClassic-0.9.0/RcppClassic/inst/lib                                               only
 RcppClassic-0.9.1/RcppClassic/ChangeLog                                                 17 ++++++
 RcppClassic-0.9.1/RcppClassic/DESCRIPTION                                                8 +--
 RcppClassic-0.9.1/RcppClassic/inst/doc/Makefile                                         25 ++++++----
 RcppClassic-0.9.1/RcppClassic/inst/doc/RcppClassic-unitTests.pdf                     binary
 RcppClassic-0.9.1/RcppClassic/inst/doc/RcppClassic.pdf                               binary
 RcppClassic-0.9.1/RcppClassic/inst/doc/unitTests-results/RcppClassic-unitTests.html  only
 RcppClassic-0.9.1/RcppClassic/inst/doc/unitTests-results/RcppClassic-unitTests.txt   only
 RcppClassic-0.9.1/RcppClassic/inst/unitTests/runit.RcppDate.R                           24 ++++-----
 10 files changed, 49 insertions(+), 25 deletions(-)

Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now Release manager , a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen. You could expect the release managers to have some rest after a big release, but it s not really the case. With the long freeze, loads of transitions have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions. He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam. Who are you? I m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf. As well as being on the release team, I m a member of the maintainer teams for devscripts and lintian. Can you describe your journey in Debian and in the release team? I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels. When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9. As most readers will be aware, we unfortunately reached a point during last year where we didn t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say How much time do you usually spend working for the release team ? I ve been trying to work out how to usefully answer this question. My initial answer was approximately two hours each day , but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I ve decided to stick with my initial answer. During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I m reliably informed that at that point the correct answer to the question is too much time . What s your own retrospective of the Squeeze release? What went well and what needs to be improved? Overall, I believe the release went well and that we should all be proud of the Squeeze release. The parts of the release cycle which highlighted the need for improvement all share, imo, a single root cause communication, particularly around freeze-related plans. We worked hard during the freeze itself to improve our communication with the rest of the project and want to continue in that vein during the Wheezy cycle. One thing that I personally found quite difficult at times before the freeze was keeping track of the transitions which were still waiting for a place in the queue; it s also something that we could improve on at this early stage of the Wheezy cycle. In order to help us keep a clear overview of requests for transitions, stable updates and binNMUs, it would be helpful if they could be filed as appropriately user-tagged bugs. This not only allows us to easily get an overview of the status of requests from the BTS but also aids transparency by allowing anyone else to do so; as a useful additional feature, it means that we can use the BTS s blocking functionality to indicate reasons why a request cannot be fulfilled right now. Are you in favor of time based freeze? I think there s merit in having a time frame that we can work towards in order to achieve the goals which we set ourselves for the release, as individual maintainers, maintenance teams and a project. I do have concerns that even with such a time frame in place there will still be uploads made very close to the proposed freeze point and transitions which may be unfinished, for example because of an unforeseen entanglement with or reliance on the transition of another package. One thing I m interested in is how exact and specific that time frame should be and the balance between predictability and being able to achieve everything we want for a great release; this is something we can cover in the debate on this subject which I know many people have strong opinions about. What are your plans for Debian Wheezy? The Wheezy to-do list I started before the final Squeeze release begins multiarch, multiarch, multiarch . It looks like we re finally going to get that achieved during this release cycle, thanks to a great deal of hard work from various people. I m also interested in seeing the C.UTF-8 locale standardised throughout Debian and continuing to work on our tools and processes to make tracking of transitions and stable updates simpler (or at least appearing to be so and more transparent. With my package maintenance hats on, I d like to help ensure that both devscripts and lintian are able to keep pace with changes in the development landscape in Debian (e.g. more useful package diffing for source format v3 packages) and continue to be tools that are an integral part of package development in Debian. Some people (including me) would like a rolling distribution constantly usable by end-users. Do you think that the release process currently geared towards producing stable can be accommodated to support this? I m not yet convinced that the concept of a rolling, constantly usable distribution can be easily integrated in to the workflow that exists around preparing stable releases in Debian. The testing distribution was created as, and continues to be used as, a tool to enable the release team to create the next stable release that it happens to be something that people can use every day for much of the time is mostly a happy side-effect of the fact that we don t gratuitously break it, but is by no means guaranteed to be the case early in the release cycle or during large, disruptive, transitions. It s been suggested that testing and rolling could be basically the same for most of the cycle, with rolling then continuing to be updated when testing is frozen. This would essentially mean an extra suite which is only used for a few months every couple of years or so, which is one of the things that testing was intended to avoid (i.e. the old frozen suite) and seems like a lot of overhead to introduce in order to reduce disruption to some users during the freeze. The early part of the release cycle also tends to include a number of larger transitions which often require packages to either be removed from testing or broken as part of migrating the transition, if they are not able to be successfully updated in time. What s the biggest problem of Debian? The thing that I ve been noticing myself becoming frustrated by recently is a tendency to debate the minor details of proposals, rather than concentrating on getting the key points right to begin with. Clearly for some projects such as multiarch the details may be as important as the big picture, but in most cases the people working on a development should be allowed to look after the smaller details themselves. That s not meant to imply that feedback from other parts of the project should not be welcomed, simply that if we consider Debian to be a do-ocracy then we need to permit people the freedom to do . Is there someone in Debian that you admire for their contributions? All previous release managers, for making the job look much easier than it seems when you re in the hot seat . Outside of the release team, Joey Hess for his contributions to various parts of the Debian development environment over the years, such as debhelper and debian-installer, and Colin Watson for his enviable willingness to tackle a wide variety of different projects within Debian.

---

Thank you to Adam for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Whenever I develop a little command line tool, I end up writing some boilerplate code. For example:

import optparse
p = optparse.OptionParser()
p.add_option('--output', metavar='FILE', help='write output to FILE')
...

Option parsing is one of those things that is easy to do, but doing it over and over again gets tedious. There's a bunch of things that pretty much all of my command line tools end up needing to do, even if they're throwaways:

• parse the command line, including option
• set up logging
• iterate over command line arguments
• open input files
• iterate over input lines

A while ago I decided that it was silly of me to write that code repeatedly, or to copy-paste things from project to project. Instead, I decided, I would write a framework that does things for me, and requires minimal setup code from me. cliapp is the result. Its API seems to now be stabilizing, so I thought I'd mention it publically, in case others might find it useful, too. So far, I've found it quite liberating to be able to crank out small scripts more easily than before. My threshold for switching from shell to Python is now quite a bit lower. I have one example online, to give flavor. The README has some explanation of what's going on. There's a Debian package on my code hosting site; see link from cliapp's home page. I'd welcome any feedback.