With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that s not enough in this case, GNOME 3 is not fully packaged yet and it s only in experimental for now. I asked Josselin Mouette (of the pkg-gnome team) when he expected it to be available and he could not really answer because there s lots of work left. Instead Roland Mas gently answered me Sooner if you help . First steps as a GNOME packager This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org. Still being a pkg-gnome rookie, I started by reading the documentation on pkg-gnome.alioth.debian.org. This is enough to know where to find the code in the SVN repository, and how to do releases, but it doesn t contain much information about what you need to know to be a good GNOME packager. It would have been great to have some words on introspection and what it changes in terms of packaging for instance. Josselin suggested me to start with one of the modules that was not yet updated at all (most packages have a pre-release version usually 2.91 in experimental, but some are still at 2.30). Packages updated and problems encountered (You can skip this section if you re not into GNOME packaging) So I picked up totem. I quickly updated totem-pl-parser as a required build-dependency and made my first mistake by uploading it to unstable (it turns out it s not a problem for this specific package). Totem itself was more complicated even if some preliminary work was already in the subversion repository. It introduces a new library which required a new package and I spent a long time debugging why the package would not build in a minimalistic build environment. Indeed while the package was building fine in my experimental chroot, I took care to build my test packages like the auto-builders would do with sbuild (in sid environment + the required build-dependencies from experimental) and there it was failing. In fact it turns out pkg-config was failing because libquvi-dev was missing (and it was required by totem-pl-parser.pc) but this did not leave any error message in config.log. Next, I decided to take care of gnome-screensaver as it was not working for me (I could not unlock the screen once it was activated). When built in my experimental chroot, it was fine but when built in the minimalistic environment it was failing. Turns out /usr/lib/gnome-screensaver/gnome-screensaver-dialog was loading both libgtk2 and libgtk3 at the same time and was crashing. It s not linked against libgtk2 but it was linked against the unstable version of libgnomekbdui which is still using libgtk2. Bumping the build-dependency on libgnomekbd-dev fixed the problem. In the evening, I took care of mutter and gnome-shell, and did some preliminary work on gnome-menus. Help is still welcome There s still lots of work to do, you re welcome to do like me and join to help. Come on #debian-gnome on irc.debian.org, read the documentation and try to update a package (and ask questions when you don t know). Installation of GNOME 3 from Debian experimental You can also try GNOME 3 on your Debian machine, but at this point I would advise to do it only if you re ready to invest some time in understanding the remaining problems. It s difficult to cherry-pick just the required packages from experimental, I tried it and at the start I ended up with a bad user experience (important packages like gnome-themes-standard or gnome-icon-theme not installed/updated and similar issues). To help you out with this, here s a file that you can put in /etc/apt/preferences.d/gnome to allow APT to upgrade the most important GNOME 3 packages from experimental:

Package: gnome gnome-desktop-environment gnome-core alacarte brasero cheese ekiga empathy gdm3 gcalctool gconf-editor gnome-backgrounds gnome-bluetooth gnome-media gnome-netstatus-applet gnome-nettool gnome-system-monitor gnome-system-tools gnome-user-share baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-system-log gstreamer0.10-tools gucharmap gvfs-bin hamster-applet nautilus-sendto seahorse seahorse-plugins sound-juicer totem-plugins remmina vino gksu xdg-user-dirs-gtk gnome-shell gnome-panel dmz-cursor-theme eog epiphany-browser evince evolution evolution-data-server file-roller gedit gnome-about gnome-applets gnome-control-center gnome-disk-utility gnome-icon-theme gnome-keyring gnome-menus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-terminal gnome-themes gnome-user-guide gvfs gvfs-backends metacity mutter nautilus policykit-1-gnome totem yelp gnome-themes-extras gnome-games libpam-gnome-keyring rhythmbox-plugins banshee rhythmbox-plugin-cdrecorder system-config-printer totem-mozilla epiphany-extensions gedit-plugins evolution-plugins evolution-exchange evolution-webcal gnome-codec-install transmission-gtk avahi-daemon tomboy network-manager-gnome gnome-games-extra-data gnome-office update-notifier shotwell liferea epiphany-browser-data empathy-common nautilus-sendto-empathy brasero-common
Pin: release experimental
Pin-Priority: 500
Package: *
Pin: release experimental
Pin-Priority: 150

The list might not be exhaustive and sometimes you will have to give supplementary hints to apt for the upgrade to succeed, but it s better than nothing. I hope you find this useful. I m enjoying my shiny new GNOME 3 desktop and it s off for a good start. My main complaint is that hamster-applet (time tracker) has not yet been integrated in the shell.

21 comments Liked this article? Click here. My blog is Flattr-enabled.

As already blogged by Riku, getting replaced by script is really great! Until now, I ve had a crontab fetching my supporting-very-big-mails (up to 100MB or so) mailbox every few minutes, and looking into my =incoming-buildd/ maildir on a very regular fashion. With some simple mutt maildir hooks, replying to a Successful log would trigger extracting the changes file from there, setting some options, like PGP inline signing, and the mail would be ready to go back to the buildd. That part was just about being a GPG-signing monkey, so really not a funny part. Since we no longer have to worry about this boring and time-consuming task, I ve switched to a crontab firing up 4 times a day, and I try to deal with all incoming mails at once. Coupled with the new filters (e.g. on out-of-date packages on the buildd status page), I started using my time to file FTBFS bugs again, so that maintainers notice their packages fail to build without having to wait for a non-happening testing migration. After 10 days, the following mutt filter in =debian-bts/ lists 69 bugs:

~s "Bug#.*FTBFS" ~P ~d 01/04/2011-

(Subject contains Bug#.*FTBFS, mails from me, starting from 01/04/2011.) Figuring out whether that s due to another package s bug, an outdated chroot, a temporary glitch, etc. might take some time; that s why it s a bit hard to stay on top of things; and when the backlog grows up, motivation to go through this tedious task can be pretty low, especially when one sees repeated mistakes. I hope the amount of (possible) use cases for #620686 will decrease over time; instead, I d be very happy if maintainers could at least check what s mentioned in configure.ac/configure.in. Keeping an eye on its diff between upstream versions should be easy enough. ;)

About a week ago, I wrote about doing cross package checks in Lintian. At that time I had only played with looking up manpages in direct dependencies, which I hope will greatly improve the current binary-without-manpage stats (around 677 packages and 2750ish tags incl. overrides). Today, I decided to take on another challenge. Detection of circular dependencies between binary packages (created from the same source). We already have a little library for building dependency relationships; however I ended up not using it, since it has an important limitation. It cannot tell how the circular dependencies relate to each other. Let me demonstrate what I mean with an example. Suppose we have a couple packages that depend on each other like this:
pkg-core => pkg-A, pkg-D
# circle 1: A, B, C
pkg-A => pkg-B
pkg-B => pkg-C
pkg-C => pkg-A # circle 2: D, E, F
pkg-D => pkg-E
pkg-E => pkg-F
pkg-F => pkg-D
In this case, our current tool will be able to tell that all packages (possibly except root I did not check) are in a circular relationship. However, we can find better results by pretending we are trying to find Strongly Connected Components (actually that is exactly what we are trying to do here). So today, I implemented Tarjan s algorithm in Perl to solve this particular issue and committed it to my Lintian branch. If this branch is merged into the Lintian master branch, we can close #316283.

At about 12:45 today, I completed my third Paris Marathon and my 7th marathon overall (incl. 2 unofficial ones, ran alone). As I wrote earlier, the challenge this year was not breaking a record. I wanted to complete two long races in only two week, as a gift for my birthday that happened between both. So, after Paris Paris Ecotrail 55km race, I ran my beloved Paris Marathon. So, I ended up in 3h54'37", 5 minutes more than last year and 14 minutes more than my personal best The heat was the ennemy, today. A wonderful sun was shining over Paris, which is nice....but brings the temperature up to 23 C. So, the solution had to be "drink, drink, drink". I think I drank something like 4 liters, today. I was planning to start around 5'25/km but finally ended up with about 5'20", which I sustained up to km 25 and the terrible Louvre tunnel (1km in a tunnel on the right bank speedway, under Quai du Louvre). That one was a killer this year and many runners blew up in it. I then decided to use the opportunity to walk a little bit, eat my mid-marathon glucides and slow down slightly later on for the upcoming tunnels (two more...though less long). That was in some way the famous 30km wall, which, for me, was moved to km28..:-) Later on, as usual, courage enters the game and I roughly managed to keep a 5'30"-5'45" pace up to the end of the race. Cramps signs appeared around km 35 but, here again, a wise slowdown and some walking, a lot of drinking helped me in controlling them. Finally, the result is about what I intended to do. Over 4h, I would have been disappointed even if happy to finish (as everybody tells me that my challenge was kinda crazy). Abandoning would have been the real defeat. I did not..:-) And, thanks, of course, to my beloved Elizabeth who again managed to deal with his "Kiki" logistics, includiung waking up at 6am on a Sunday. Now, my running schedule will slow down a little with only training for 5 weeks. Next race: Trail des Cerfs, a 35km trail in Rambouillet Forest close to home. I may again schedule a solo marathon, at training pace, end of May, in Versailles Castle park. Next marathon: Berlin, Sept 25th. Here, the goal is breaking the personal best and head up to 3h35.

Registrations for DebConf11 are now open!

Dear guests, attendees and contributors, we are happy to announce that registrations for this year s Conference are now open. The instructions for registration process can be found under Register page. While the basic registrations will not close until the end of the Conference, sponsored registrations however, have the deadline. If you would like to apply for sponsored attendance, then it is imperative that you do it before 8th May! Should you have any further questions regarding registrations, please mail them at registration@debconf.org.

Call for Contributions!

We invite submissions of proposals for papers, presentations, discussion sessions and tutorials for Debconf11. Submissions don t have to be limited to traditional talks, you could propose a performance, art installation, debate, or anything else. Official submissions will be accepted until May 8th 2011, 23:59 UTC. For more information, please visit Call for contributions page.

I am going to Berlin to give a talk at Re:Publica and will be there from Monday through Thursday (11th-14th of April). I am interested in getting together with Debian developers so please contact me if interested. Feel free to leave a comment about your favorite things to do in Berlin as well as I might have a day or two to check out the sites.

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

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.

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

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!

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.

• the hello part:

(from http://lists.debconf.org/lurker/message/20110213.040506.1beb418f.en.html)

To: debconf-video

Subject: [Debconf-video] Announcing debian/watch, the Debian Miro Community Hi all,

With help of dc-video people I've just finished generating RSS feeds from penta data and published all Debconf(5-10) available videos to our new Miro Community page: http://debian.mirocommunity.org/

Soon I'll upload the feeds to dc-video repository. The process had to be semi- automated since I noticed some inconsistencies in penta which I'll point later.

I've written the following description for this channel: http://debian.mirocommunity.org/about/ (english language fixes / suggestions are welcome!)

Other nice Miro Community channels for reference:

http://gnome.mirocommunity.org/ http://ubuntu.mirocommunity.org/ [...]

• the bye part:

(from a recent email message to Debian Miro Community admins)

Your Site is Now Running Miro Community 1.2!

Hi,

We have just migrated http://debian.mirocommunity.org/ to the latest version of Miro Community. From here forward, we're asking our heaviest users to help support ongoing software development and server costs by upgrading to a paid account, which is very easy to do!

This release limits some features you currently use. You will have 2 weeks to upgrade your account or you will no longer be able to use the following features.

* You have more than one administrator. If you choose to remain at the Basic account level, the following administrators will lose admin privileges: valessio tiago

* You have 556 published videos. If you do not upgrade your account, we will unpublish the oldest videos to keep you within the 500 video limit. You can also cull videos you no longer want at http://debian.mirocommunity.org/admin/bulk_edit/ [...]

Although I understand Miro Community needs of releasing paid accounts, I think the features are now too restricted for non-premium users.So, at the end I have to thank Valessio for his amazing CSS work on this and Holger for warning me in time to not announce Debian Miro Community as an official channel for Debconf videos.It seems Miro will unpublish 56 videos from our channel in two weeks. I'm thinking about keeping there only Debconf videos, which should then fit on their new quota... At least until we find another place to publish them. Suggestions are very welcome. Debconf and other Debian videos are currently hosted at http://video.debian.net. Debconf videos feeds are available at http://tiagovaz.org/videoteam/ and corresponding thumbnails at http://tiagovaz.org/thumbs/.

I realized I never announced this on the blog, so without further ado.... Rcpp Workshop in Chicago on April 28, 2011 This year's R/Finance conference will be preceded by a full-day masterclass on Rcpp and related topics which will be held on Thursday, April 28, 2011, on the University of Illinois at Chicago campus. Join Dirk Eddelbuettel and Romain Francois for six hours of detailed and hands-on instructions and discussions around Rcpp, inline, RInside, RcppArmadillo and other packages---in an intimate small-group setting. The full-day format allows to combine a morning introductory session with a more advanced afternoon session while leaving room for sufficient breaks. There will be about six hours of instructions, a one-hour lunch break and two half-hour coffee breaks. Morning session: "A hands-on introduction to R and C++" The morning session will provide a practical introduction to the Rcpp package (and other related packages). The focus will be on simple and straightforward applications of Rcpp in order to extend R and/or to significantly accelerate the execution of simple functions. The tutorial will cover the inline package which permits embedding of self-contained C, C++ or Fortran code in R scripts. We will also discuss RInside to embed R code in C++ applications, as well as standard Rcpp extension packages such as RcppArmadillo for linear algebra and RcppGSL. Afternoon session: "Advanced R and C++ topics" This afternoon tutorial will provide a hands-on introduction to more advanced Rcpp features. It will cover topics such as writing packages that use Rcpp, how 'Rcpp modules' and the new R ReferenceClasses interact, and how 'Rcpp sugar' lets us write C++ code that is often as expressive as R code. Another possible topic, time permitting, may be writing glue code to extend Rcpp to other C++ projects. We also hope to leave some time to discuss problems brought by the class participants. Prerequisites Knowledge of R as well as general programming knowledge; C or C++ knowledge is helpful but not required. Users should bring a laptop set up so that R packages can be built. That means on Windows, Rtools needs to be present and working, and on OS X the Xcode package should be installed. Registration Registration is available via the R/Finance conference at

http://www.RinFinance.com/register/

or directly at RegOnline

http://www.regonline.com/930153

The cost is USD 500 for the whole day, and space will be limited. Questions Please contact us directly at RomainAndDirk@r-enthusiasts.com.

Imagine a conversation where some people would like to try to make Debian better, and several people say things like this:

as soon as you make this particular change, I will stop using Debian and all my customers will stop using Debian too

Quite a number of different possible responses pop up in my head immediately.

• you're trying to blackmail us; we're better off without you, regardless of who you or your customers are
• you're about four years old
• you're delusional: Debian is too hard a habit to get rid of, so you're going to be using Debian anyway, regardless of what we do

More seriously: should this kind of behavior be acceptable on the Debian mailing lists? Not only is it insulting and anti-social, but trying to influence purely technical decisions by threats is not going to make Debian better.

So, I'm in a bit of an odd situation where I've got 2 (sometimes 3) stateless ipv6 configurations hitting my laptop a lot of the time - I need to prefer only one of them for the default route, but obviously I'm getting served default routes all over the shop (because each radvd on that network is advertising itself as a default route too)... Now, on my laptop I actually deliberately set one of my own machines as a DNS server on the bringing up of a certain interface which happens to be v6 only, the problem is that only does recursive if you come from a fixed set of IPs, so I get sporadic dns failures if the laptop decides to use one of the other default v6 routes. Now, being spoilt as I usually am by the kernel, I thought "Hmmm, obvious way to get round this would be to tell the kernel that $interface should have a default routing metric for the default route of 512 rather than 1024". Apparently that was a pipe dream, from what I can tell from the kernel source, routes added are given a metric of 256 if they are a directly advertised prefix, and 1024 if they are a default route, I couldn't see a way that you could at any point change that. As this doesn't actually exist, and I just realised that I could advertise the route to the dns server (which is on a different /64 to the vpns /64), I'm now advertising that route - note, however, that for this to work you have to have enable a sysctl option to let it accept router advertisements for things that aren't the prefix it's getting or the default. The way to enable that is

sudo sysctl net.ipv6.conf.interface.accept_ra_rt_info_max_plen=64

Which will enable anything up to a /64 prefix to be advertised at us. Looking at how the kernel handles default routing tables, what would be really useful (to me at least) would be to be able to set default metrics per interface so that when a route is advertised at it it used the per interface metric rather than the (sortof) hardcoded kernel metrics.

aero snap was one of the launch features of Windows 7 that was quickly copied into other desktop systems (most recently, gnome 3). I've written about it before. Essentially, dragging windows to hot regions of the screen resizes those windows to occupy some area of the screen. To the top: the whole window area (maximize). To the left or right, 50% of the width of the window area, all of the height. This is a pretty useful feature that I wanted to steal for myself. There is a somewhat fragile-looking (but functional) way of achieving this using compiz and some embedded shell scripts which I used for a while, but has several drawbacks: there's no visual indication that resizing will occur; resizing occurs after a time interval and not in response to you releasing the window from its drag; it's therefore very easy to accidentally resize windows (focussing a window adjacent to an edge and parking the mouse pointer in the edge region is sufficient). Aero snap is not without its own shortcomings: whilst having side-by-side windows is great for comparing two documents, you can't arrange two windows top-to-bottom, each occupying half of the vertical height of the screen. This is very useful for working on two spreadsheets. A less interactive but more functional way of achieving this is the grid plugin for compiz and keyboard shortcuts. The grid plugin can be found in the Debian package compiz-fusion-plugins-extra.

Alright. If you ever come into the same situation I was in and need a newer kernel (2.6.32 or up, perhaps also 2.6.31) on some system with old iptables package (versions below 1.4.0 I think, 1.3.5 in my case: CentOS5/RHEL5), you might get this helpful error message when using the iprange module in your iptables rules: iptables: Unknown error 18446744073709551615 Or even more helpful, if you use iptables-restore to load your rules, you will get an error in the line containing the COMMIT statement (iptables-restore: line X failed). The reason for this is that the netfilter guys have removed an interface to the iprange module in kernel version 2.6.31 or 2.6.32 (see my bug report at #711 of the netfilter bugzilla). Just posting this so it might hopefully help others if they get into the same situation.

Looking at current state of some phpMyAdmin translations, I came to conclusion that some are not worth shipping, because they really do not translate reasonable amount of the interface. The problematic question is where to draw the line. For 3.4.0-rc1 I drew it at 50% of messages, what means that 25 languages currently pass. It might look too strict and the threshold will most likely change for final 3.4.0, but we need to start somewhere. While discussing this topic on mailing list, Tyron Madlener came with idea to tell users of incomplete translations about it and point them to information how to contribute. I quickly implemented this idea and it is now in git and live on demo server. I deliberately decided not to remove incomplete translations on demo server, maybe they will attract new contributors thanks to new warning on main page.

Filed under: English Phpmyadmin 2 comments Flattr this!