Enigma is a great game, with a unique mixture of puzzles with mouse skills and action. If you know the discontinued game Oxyd originally on the Atari ST in the 90s (also on Amiga and one version on DOS), then you know the principle of Enigma. Except that it has tons of more levels and is Open Source.

Some weeks ago, I uploaded a 1.10 pre-release (approximately milestone 5) to Debian experimental. This is the soon-to-be-released new version, using a new level file format (with a much extended API to make level development even easier, ~50% less code per level now), new levels (of course), updated graphics (including support for new graphics modes), ...

Unstable still contains version 1.01; the reason is simple that I knew there would be another 1.01 maintainance release coming. However I believe it doesn't offer much against the current unstable version; it largely marks an upstream release containing patches already in the Debian package (since communication with upstream is really good).

So I have now two choices: refreshing the Debian unstable package to the "probably last" 1.01 release upstream, or going straight for the 1.10 milestones to give enigma some extra testing.

Just a short reminder that the application phase for the Google Summer of Code 2009 is running.

So far, we have quite few applications. Deadline is April 3rd, 19:00 UTC. Usually applications arrive rather late, but still I have the impression that we have much less than the previous years. But less copy & paste, too.

If you are interested in doing a GSoC project at Debian:

• Check the Debian Wiki which has all kind of relevant information.
• Talk to Debian people
• Make sure it's related to Debian (and not just "runs on Linux")
• Talk to Debian people
• Make sure your application shows your genuine interest and has some original ideas, copy & paste will not be sufficient
• Talk to Debian people

P.S. as far as I can tell, current Debian Developers can be eligible as well, although it has also always been a goal of the project to get new contributors involved.

Congratulations to all developers (DDs or not, we have sponsored uploads, Debian contributors and such, too!) who contributed to the release of Debian GNU/Linux "lenny" 5.0. I must admit that I've been largely inactive recently, I just managed to keep the bugs on my remaining packages low. Funnily, just the day lenny was released I learned about a bug in Enigma on AMD64 that is probably worth fixing through proposed updates ...

From Roderich Schupp I received the following instructions:

cp /usr/share/doc/hal/examples/10-x11-input.fdi /etc/hal/fdi/policy/

And in order to set a default keymap:

<deviceinfo version="0.2">
  <device>
    <match key="input.xkb.rules" contains="base">
      <merge key="input.xkb.layout" type="string">de</merge>
      <merge key="input.xkb.variant" type="string">nodeadkeys</merge>
    </match>
  </device>
</deviceinfo>

Thank you, I'm going to try that on my next reboot (which may take a week).

Xorg 1.4 in experimental is supposed to have input device hotplugging.

Does anyone have a Howto for Debian? I tried it, but I couldn't get it to hot-plug my USB mouse, so I'm back to using the regular mouse driver for it again, using the /dev/input/mice in-kernel-hack for hotplugging.

P.S. on a recent kernel, you might want to add

blacklist snd_pcsp

P.S. No, my blog doesn't have comments. Just send me an email (you know, 'legacy' email) via erich AT debian org.

Today, I uploaded a new version of my firewall configuration tool, pyroman, to Debian unstable.

About 4 hours later I googled for "Pyroman Debian" and was surprised to find the upload notification in the top results. The first hour of this was probably spent with me doing some package function tests (I don't want to upload broken packages, after all), then the announcement was distributed to the -changes mailing list at Debian, which in turn was picked up by Google Groups.

However that might be due to groups.google.com getting special treatment, though. For this resource, Google can actually trigger an update instead of having to have a spider frequently re-crawl all the contents.

Still I find it pretty impressive to have such new data already in their main index. I was used to this e.g. for blog and news search, but not for regular web search.

The Summer of Code wiki page in the Debian Wiki has been updated with an overview of the projects that made the race for the 13 slots we have.

A separate press release (containing a short paragraph on what each project is about) is in preparation and will be out soonish.

We've received another of the last minute slots (thanks to those organizations which returned some of their assigned slots) to a total of 13 this year.

We have received some very good application, and we'll be able to fill these 13 slots easily with very good applications working on a variety of topics.

The results will be published on Monday, since there may still be minor changes in which students are accepted or who didn't make it to the top slots.

Google Summer of Code 2008

[Yes, this post was written on April 1st and is not to be taken serious.]

The usability experts of Ubuntu have finally started to handle the single most mentioned usability issue with Linux: the top level directory names.

Quoting Finn C. Tional from the Ubuntu Usability Group:

It's one of the mysteries of Unix that the directory named "usr" is not for user data, and the directory named "etc" while looking like random stuff thrown together stores all the important config files. [...] This is probably the single most confusing hurdle for new Unix users. [...] We need to finally tackle this, before people are too used to these odd directory names.

Therefore, they propose the following renaming scheme:

/bin      /system/executables
/boot     /system/boot
/dev      /system/devices
/etc      /system/config
/lib      /system/libraries
/home     /users
/media    /storage
/mnt      /storage
/proc     /system/processes
/root     /users/Administrator
/sbin     /system/executables/admin
/tmp      /system/temporary
/usr      /system/applications

They'll include a patch for the GNU C library as well as for AppArmor to redirect the old path names to the new ones. Given the existing filename matching already done by AppArmor the overhead is expected to be neglible at least for AppArmor enabled systems. SELinux enabled systems will remain unchanged, since the user won't be allowed to see anything potentially irritating in the root directory anyway, but will be confined to his user directory.

Since there are a dozen applications that will need changes to accomodate the new naming scheme, expect these changes only to be included with Ubuntu 10.4 (also lovingly named Ubuntu X) scheduled for April 2010.

Other distributions are expected to follow up with these changes in 2011.

P.S. Yeah, the Ubuntu folks really need to think this throuh some more. Russel pointed out that "My System" is even easier to understand; after all this is not about someone elses system or some systematic error or whatever. I figure he's right. How about "My Computer" than this lowercase (pessimistic?) "system" directory they're proposing there!

As blogged before, Debian is in the Google Summer of Code 2008.

So far, we have rather few applications - much less than last year. This doesn't seem specific to Debian, other organizations have also been reporting fewer applications, and Google is considering a deadline extension. Maybe the low number is related to Easter holidays. Also at least at my university the summer term will start only on April 1st, just past the deadline. So many students probably are still away in holiday.

Anyway: if you are interested in participating in the Google Summer of Code, chances are still pretty good. We don't have too many applications yet; not even all of the projects on the Wiki Ideas page have received a submission yet, only a few have received more than one; and even with those a well-written submission standas a good chance. Also some new ideas have been added in the meantime.

In particular missing from our submissions list are:

• MergeMaster port
• debexpo
• CDD webtools
• security policy

Especially the lack of a submission for the MergeMaster port is surprising. Many people would love to see a good configuration file merging tool in Debian. I can only guess that people are thinking "awh, everybody is going to submit an application for this one, I don't have a chance here". You currenlty DO have a chance, because there is no single proposal in for this one yet!

If you have any questions, IRC channel #debian-soc in OFTC is pretty useful.

Debian is part of the Google Summer Of Code again this year (2008).

Last year was quite successful, so we hopefully will get at least as many slots as last year.

Applications will be possible March 24th to March 31st. This means, you should already starting writing your project proposals and get feedback by possible mentors. Ideas can be found in the Debian Wiki, but notice these are just ideas. You are by no means limited to what we're proposing there.

As for writing an application, here are some general notes:

• Start writing early, submit early. The early ones get best exposal to mentors. When we read the nth proposal for the same project, we're usually quite bored already. Especially with respect to feedback this IS a benefit for the early proposals
• Don't just copy & paste. We're not stupid. We want to know if you understand the subject and have good ideas, so show that. We're not interested in your ability to access the Wiki, we trust you on that one.
• Communicate. Open Source is about communication and collaboration. So get feedback from people who work on the related subjects and possible mentors. Don't keep your application secret. You don't have to be afraid someone could steal your application (remember, we read the applications, and we can tell who has just been using copy & paste and who is able to answer our questions!) - but you DO need the feedback to improve your application.
• Use all communication media. The GSoC web application has it's limits (e.g. by not being open yet). So make use of the IRC channels (#debian-soc in OFTC) and the mailing lists for your project. We'll also use these to judge your application, not just the web interface. "Has been asking good questions on the mailing list" is one of the best verdicts you can get.
• Bring in your own ideas. We're looking for talented, interested people, not "stupid work horses". So show what you've got.
• Don't be afraid of challenges. This is all about stepping up to a challenge. We'll help you succeed. If you e.g. aren't experienced in Python yet, but the proposal says "Required skills: Python", just be honest. Mention that you're a good Ruby coder, and we'll trust you on being able to pick up Python in a short timeframe. And maybe even just start already in filling such a gap.

In turn, we (= the mentors and admins) will try to (again - we did that last year) have at least three mentors read through your application, provide feedback on it and judge it. We don't draw lots for the slots, but we'll rank the applications based on the scoring by the mentors. We'll also try to assign you a fallback mentor in case your mentor has to step back for whatever reason and to give you additional people to talk to.

... was a lot easier than expected. Just not very well documented.

First of all, you need the appropriate utilities. Debian users can aptitude install libsmbios-bin

Next identify your system. It will look something like this

$ sudo modprobe dcdbas
$ sudo getSystemId
Libsmbios:    0.13.10
System ID:    0x01D8
Service Tag:  ...REMOVED...
Express Service Code: ...although my warrany is over...
Product Name: MXC061
BIOS Version: A10
Vendor:       Dell Inc.
Is Dell:      1

The information you need is the "System ID".

Now you need to get the so-called HDR file for your bios. This can either be extracted from their EXE file using wine (with -dump-hdr or so), or you can find it on the linux.dell.com server. This page contains a huge list, and there are tons of dirs like system_bios_ven_0x1028_dev_0x01d8_version_a10. 0x1028 apparently is "Dell". The second hex number is your System ID. The last number (A10 here) is the BIOS revision. Pick the appropriate directory. There should be a bios.hdr file in there.

You can verify if the file is appropriate for your system:

$ sudo dellBiosUpdate -f bios.hdr -t

$ sudo modprobe dell_rbu
$ sudo dellBiosUpdate -f bios.hdr -u

When rebooting the next time, your screen might be garbled for a few seconds. At least it was for me. I was scared I might have trashed my system, but then it rebooted and had the new BIOS. So just give it some time (Fortunately I've done enough BIOS updates to know to just wait. I've even done a 'blind' video BIOS update on a Nvidia TNT. The first update had trashed the card, but I was able to redo the flash process without seeing anything on the screen, and guess what, the card worked again!)

In case you're wondering how this works: as I understand it, the dell_rbu driver will reserve memory for the BIOS update. Being a kernel module, it can just lock the memory in place until the next reboot. It will store that address in CMOS for the Bios and set the update flag. On reboot, the current Bios will check if that the stored image is still intact (I bet they do some checksumming here!) and then load that into the BIOS flash. That way, you don't need to boot into a low-level system such as Dos or Dos-Mode anymore to do an update.

Well, I havn't seen this recently. Maybe because aptitude has rename 'upgrade' do 'safe-upgrade', to make it obvious, that 'dist-upgrade' might do unwanted things.

Back when I was the maintainer of the galeon webbrowser package, I got bug reports and reports on IRC each time the mozilla packages was updated.

The galeon package used to have a conflict with mozilla of any newer major version than the one it was built with. This was a good thing - mozilla APIs were chaning, and when Mozilla was upgraded from let's say version 1.5 to 1.6, it would break galeon. Galeon would at least need to be recompiled or might even need source changes. So there was plenty of reason to add this conflic.

People were using 'dist-upgrade' all the time, and what dist-upgrade did then was to upgrade the mozilla package by removing galeon. And they couldn't even install galeon back again, because the new mozilla had replaced the old mozilla in unstable. And each time, I basically had to tell people "well, you shouldn't have used 'dist-upgrade', it's for upgrading between major version of Debian, not for daily use.

In fact, running dist-upgrade right now would uninstall 'iceweasel-dom-inspector' for me. I guess this is exactly due to the same reasons.

I'm wondering whether we should maybe do a 'uninstall-ok' list (or 'dist-upgrade-hints') and ship it with the distribution. I'd then modify the 'dist-upgrade' command to

• removing any package in this 'hints' list to satisfy dependencies is okay (i.e. as it is now for any package)
• prompt for confirmation for any other package

So let's say there was experimental-browser in some revision, built with mozilla version 1.7, and conflicting to mozilla 1.8. The browser is discontinued, and ends up in the 'uninstall-hints' file. If the user does a dist-upgrade, it will be removed as usual.

However, if 'galeon' has such a conflict and is still alive, it won't be listed in unstables 'uninstall-hints' file, and thus not considered for automatic uninstallation. So people who unnecessarily run dist-upgrade will still suffer less (unless they chose to remove it anyway!)

However, if the user has built his own 'custom-webbrowser' package, it will cause a bigger warning when running dist-upgrade, because aptitude doesn't have that package in the hints file. So the users of local packages actually have a benefit here, too.

P.S. Sorry; I don't have time to follow planet debian these days. Still if you have feedback it's recommended to use planet or the mailing lists!

I wasn't aware of the "network-test" command in Debian, but it's actually quite neat:

INFO: This system has exactly one default route
INFO: Host localhost answers to ICMP pings
INFO: Loopback interface is working properly
[...]
INFO: The wifi0 interface has tx and rx packets.
INFO: The router 192.168.2.1 is reachable
INFO: This system is configured to use nameserver 192.168.2.1
INFO: Host 192.168.2.1 answers to ICMP pings
INFO: Dns server 192.168.2.1 resolved correctly www.debian.org
INFO: The nameserver configured for this system works properly
INFO: System can reach Internet host www.debian.org
INFO: System can access web server at Internet host www.debian.org

It does a quick network debugging output. I'd s/Dns/DNS/ though.

DRI (3D acceleration) stopped working for me. The reason is simple (as revealed by looking at the Xserver log file): it was missing the DRI library for my graphics card.

So if 3D acceleration isn't working for you anymore, try this:

aptitude install libgl1-mesa-dri

This package includes the library required for DRI on my Intel 915 graphics board. Not sure how it got lost, though. Maybe I purged it when trying to remove "unneded" packages from my system (in order to free up some space)... I tend to try to uninstall everything I don't think I need.

P.S. Looks like you can now but ATI/AMD graphics again, given that they're releasing specifications for their chips - reliable opensource drivers on the horizon!

I've fought both the Nvidia and old ATI driver hell - not having to do that was one of the main reasons why I wanted Intel graphics. Now ATI/AMD is back on my radar.

Debtags, a tag-based approach to classifying Debian software packages, has taken another big step forwards.

Debtags was included in the relaunch of packages.debian.org, Debians package search and information web server. This means it's now visible to pretty much any Debian user.

The experimental packages.debian.net also uses Debtags to recommend 'similar' packages.

There are some AI/Datamining projects around Debtags that I'm interested in, but I don't know when I'll find time to work on them.

... I would appreciate that (any *init maintainers going to DebConf?) - but I won't be around. I missed the DebConf sponsorship deadline (which was end of January; since I'm currently devoted to getting my diploma done, I don't have an income, so sponsorship would be good); and even now (they're currently asking for reconfirmation) I don't plan that far ahead. I have no idea what the state of my diploma thesis will be back then in June. Probably not yet stressful, but I just don't know. So I can't commit to DebConf.

A pity, I'd really like to go to a DebConf again, the last (and only) one I was at was in Oslo in 2003. I don't think we needed to sign up that early back then; the school building we could sleep in (and use the showers) was fine with me.

And of course I'd also love to contribute some swing dancing 'course' to the social dancing event...

DebianMuc release party, add yourself now. Saturday, at the Flaucher (Isar).

Weather forecast for this week is great. Probably around 24 C on saturday, the warmest day this week I've heard. It will still be getting cold at night (after all, it's not summer yet, though we like pretending it is); so maybe we should meet rather early. Also make sure to bring some warmer clothes, too.

Anyway, there is the Wiki and our mailinglist for organizing the party.

It's finally out. Happy Easter.

Debian has just

• Updated 'sarge' (aka: new 'oldstable') for a last time
• Elected a new project leader (congrats, Sam)
• Released Debian 4.0 'etch' (aka: new 'stable')

Yes, it's finally out. And I hope it has the high quality you've come to expect for Debian releases (which is probably why it takes us so long, apart from supporting 11 architectures in this release).

Congrats, and a big thank you to all those involved, especially our release managers.

I've upgraded an old woody box to etch these days. Live - I've been telling people they need to find a replacement for this machine for years now, but it's still around and playing an important role.

And with 'woody' I mean 'a woody heavily played around with, with a couple of backports and exotic stuff like XFS, a custom 2.4.25 kernel with grsecurity'. Especially the latter was why I was afraid of doing the upgrade.

In a first step, I incrementally upgraded everything to sarge (well, at least where the backports weren't already newer than sarge). I installed the stock sarge kernel, and prepared a reboot.

The reboot was then done out of schedule, because the machine died on it's own - it has been crashing about 1-2 times a year, and it hadn't happened for some time. Judging from the logs, it was that old problem again.

At second try it came up with the new kernel: I always forget to enable init ramdisks in the bootloader when switching from a custom kernel with every needed module built-in.

I then continued upgrading to etch, pretty much one service at a time.

Some things (I didn't do a full list; the box was running to many modified versions of packages of this being useful as upgrade reports to the release team, and it's a bit late in the schedule, too) where upgrading didn't work out of the box:

• Incompatible configuration file changes: amavis, courier, monit
• OpenLDAP refusing to load one of the third-party schemas
• Newer Courier POP/IMAP is incompatible to drac, breaking SMTP-after-POP
• Configuration changes of saslauthd breaking SMTP-AUTH
• IMP3, a webmail interface, doesn't work with PHP5. It has been replaced by IMP4 in sarge, however I'd like my users to be able to keep on using it for some while (and I need to find a way to migrate e.g. the address book over). I consider this a major upgrade annoyance with PHP5, that it no longer allows "return false;" in some situations (if you want to return by reference, you need to use a named variable). The behaviour of "get_class" also has changed in an incompatible way.

The bad news: there is still something wrong with the machine. It doesn't crash, but spits e.g. the following to dmesg:

amavisd-new: page allocation failure. order:5, mode:0xd0
 [<c013aa08>] __alloc_pages+0x2f8/0x370
 [<c013aaa5>] __get_free_pages+0x25/0x40
 [<c013e0b2>] kmem_getpages+0x22/0xc0
 [<c013ed0a>] cache_grow+0xba/0x180
 [<e0aebe1e>] xfs_bmap_read_extents+0x36e/0x540 [xfs]
 [<c013ef3a>] cache_alloc_refill+0x16a/0x220
 [<e0ae80fd>] xfs_bmap_alloc+0xe0d/0x1c60 [xfs]
 [<c013f3e4>] __kmalloc+0x74/0x80
 [<e0b389c9>] kmem_alloc+0x59/0xc0 [xfs]
...

I'd like to propose a Init Hackfest for Debian when etch is released.

Debian includes several init systems, including sysvinit, runit, minit, initng and upstart. However, only sysvinit is really supported, and others can be used in a compability mode (and most of their benefits are gone then). So there is some work to be done here. Some init scripts probably could also use some cleanup. :-)

Shortly after the release of etch is probably the best moment to work on such key parts such as the init system, since many packages are affected. I suggest to provide patches to the package maintainers and do uploads to 7-day delayed.

If you are interested, maybe you could add your name to the wiki page? I also think the mailing list initscripts-ng-devel at alioth is appropriate for discussion.

These days I picked up the Debtags AI topic again (so yes, development is alive, not the AI).

Some people will remember this topic, it was a Google Summer of Code project. The project didn't really complete back then.

Since my thesis isn't coming along too well (I don't know how to explain to my professor what I'm trying to achieve...), I've been playing around with different stuff. So I've picked up the Debtags AI again.

Back at the end of the GSoC or sometime later last summer, I had started a rewrite of the Debtags AI stuff in C++ for performance reasons. I also had some ideas on how to make it scale better and on how to improve the results. I think I've reached an interesting state now; training time of the AI is down to a few minutes (remember it was a few days when the GSoC started?), so I managed to cut off another order of magnitude. Evaluation of a text against the database (i.e. for every tag) happens in the fraction of a second.

This AI is turning out quite well now. I have one more idea for a trick that could improve the results from an algorithm side, and one from the data side. Enrico is already looking at how to integrate it with the web apps. :-)

And I also want to scale it up further. How about using it to classify web pages by their text content? I already have an idea on how to get some good training data... maybe I should consider writing a business plan instead of a diploma thesis...

Applications are still open until March 26th.

Note: the following is my personal opinion; I'm not the coordinator of the Debian GSoC project, and others might disagree.

Debian has received a couple of applications, but there were rather few among them I found really convincing. :-(

What I usually dislike in applications:

• doesn't state an actual project (yes, this happens, we nuke them pretty quickly. "Debian for my life" is not a real project, you know...)
• isn't related to Debian. For example "face recognition PAM module" certainly is an interesting topic, but I don't think Debian is the appropriate organization to mentor this. We aren't an organization of image recognition experts, but our key strength is distribution infrastructure.
• doesn't say much more than the suggested topic already did (note that for such 'popular' topics from the Wiki we usually receive more than one application; so adding some good ideas yourself or at least writing a good plan is key to being accepted!)
• doesn't give the impression of having done some basic background research, such as having searched in the Debian packages repository with "apt-cache search"

So if your application is really Debian-related, invest a few hours in writing the application and your chances are pretty good at being accepted!

Of course Debian could be an Umbrella for e.g. another network configuration GUI, a tool to configure traffic shaping etc.; however I don't think that should be our focus. In fact, Google itself could mentor these topics maybe as good as we can. So please don't just submit a proposal to us because you happen to be a Debian user, or submit it to all mentoring organizations. Instead try to find an appropriate mentoring organization. (On a side note, the mentoring organization is supposed to provide you with a mentor which can actually help you on the topic). Debian is a good choice when it comes to integrating software, software management, system administration and such. Thats what we do: collect existing software and try to make it work together as good as possible. And build infrastructure and tools to make this task easier. This of course touches e.g. porting to different architectures and writing new administration frontends, however we try to avoid reinventing the wheel.

One of the suggested topics, where I'm really surprised to not having seen a proposal yet is CRMI; which matches what I sometimes call a "per package wiki for metadata". Or a Debtags related project. Or a SELinux project. These are both pretty interesting technologies, which offer substantial benefits when actually used. When properly integrated in the distribution.

Dell is doing a survey on their upcoming Linux offers. But "Debian" isn't on their shortlist of preinstalled Linux versions. There is an "other" option though we can use.

Please tell Dell that Debian is nice on the Desktop, too. It's not a server-only distribution...

P.S. Let me point out, that I'm running Debian on a Dell Inspiron.

I was the maintainer of minit for some time, and spent some time adding some runit-like functionality to minit I then called "enitdir". It worked similar to runit (IIRC, maybe it was a different init).

Basically you had a directory for each runlevel, which contained symlinks to all services supposed to be running. There is a symlink called "current" or something pointing to the current runlevel. enitdir monitored this symlink and the directories contents via dnotify, so it supposedly was both very fast and efficient at noticing changes there.

Switching runlevels was as easy as "ln -snf current foobar"; starting and stopping services worked by removing the symlinks in the current runlevel or manually calling minit (for non-persistent changes, restarts, etc.)

(I think I never uploaded a package with any of this, the minit packages remained really close to upstream. I intended to do a fork/rewrite named enit, but never got around to it. Many of my ideas are addressed by upstart.)

However this didn't solve some integration issues.

First of all, not all packages back then were using invoke-rc.d; this should be a lot better nowadays.

But the major issues lie within handling multiple inits on one system.

There is a hook that applications could use to prevent init scripts from running (which might be the answer to Wouters iniscripts post). It's called "policy-rc.d".

However there are some things wrong with this approach: it doesn't really support the installation of multiple inits or handles the problems of switching between inits in any way.

Basically, the moment we need to switch inits (and thus service startup/stopping behaviour!) is during reboot. While the old init is still running, any start/stop operations MUST still use the method appropriate for the current init system. Otherwise, major bugs can occur, especially with smarter init systems that respawn services.

E.g. the user runs "apt-get install sysvinit mysql-server". Lets assume sysvinit has a debconf prompt 'make me the default init' and the user says yes. Next mysql-server is upgraded, during which it calls the sysvinit way of stopping the service (i.e. /etc/init.d/mysql-sever stop), then does some dangerous things to the database, then restarts the server. However, a smart init such as minit (when equipped with appropriate service files) will notice the mysql-server process dying and immediately restart it (notified by kernel, efficient and fast) while the upgrade script is still messing with the database files. Boom, there goes your database.

I guess you got the point.

So we probably need a smarter invoke-rc.d script. It should support

• init detection - figure out which init is running, e.g. by comparing the inode of /proc/1/exe to the inode of /sbin/init.* (current init doesn't need to be named /sbin/init, but note that this magic might break on upgrades. Fallback to readlink(/proc/1/exe) maybe?)
• different init behaviours. The current policy-rc.d hook is pretty much a yes/no hook. Instead it should call the appropriate init-specific invoke tool.

Such an invoke tool could then for example look like this:

if [ -e "/etc/enit/service/$1" ]; then
    enitctl start $1
else
    /etc/init.d/$1 start
fi

You get the idea, having the policy script figure handle compability for services that don't have an appropriate service description for this init system yet. (Yes, s/start/$2/ or something, above is pretty dumb, but helps bringing my idea over).

There was just a mail to debian-devel-announce with the new release schedule.

Here's an excerpt:

N    =  1 Apr 2007:
       -1 RC bugs.  Release etch with an off-by-one bug.

Nah, just kidding. Damn. I should probably have saved that one for April 1st.

Actual N is:

N    =  2 Apr 2007:
        0 RC bugs.  Barring any problems that would cause us to need to
        re-roll the installer <knock on wood>, we should be ready to
        release.

Debian used to be the cool kid among Linux distributions. Because our stuff worked much better, was easy to install and especially to upgrade. Dependencies would be automatically resolved while others were fighting dependency chaos, and our menus would have all the apps in it, where others had to fill their menus on their own. And at the same time, Debian was very flexible and could be customized to become e.g. Knoppix. Our bugtracking was great and we were openly discussing bugs and all this stuff.

Many of these Debian achievements are now common among distributions. Especially among Debian-derived distributions. Debian however has become a reliable 'stable' distribution often even called 'stale', while others stand in the spotlight of innovation. Other distributions have come up with maybe more advanced bugtrackers (I'm not talking bugzilla, which IMHO is overengineered) and other tools.

Technically, this isn't completely true. There are still many fields where Debian is technically leading. But our focus has recently been a lot about individual packages or components (e.g. the installer). Maybe we should try focusing more on infrastructure again.

In fact, Debian still has some very good infrastructure components others might be lacking. Our QA tools (including bug counters, tracking which versions are affected by which bugs, all kinds of graphs, wotomae) are great. All our update-* commands are missing in many other distributions, also things like invoke-rc.d. We have a solid Python policy to support multiple Python versions and precompilation (judging from the SELinux policy, none of the other distributions has that yet). We're able to use dash as a minimal shell instead of bash in most places (which does make a speed and memory difference). We have Debtags.

But these projects don't play a key role in Debian anymore AFAICT. Trying to start a major infrastructure thing requires a LOT of engagement, maybe too much. I'd love to see better SELinux support in Debian, but I can't do it on my own, it's just too much. And I find it very hard to find people to help me with that effort. If Enrico hadn't been pushing Debtags again and again (and with a lot of code), it would also have gone stale. Despite being IMHO something that can take Debian on top again (making it a lot easier to find appropriate software). One of the reasons why Debian is still living pretty much outside is that it would be a huge effort to get maintainers to add the corresponding Tag information to their packages and so on. I've always balked at even trying that, fortunately Enrico got some tag information added via overrides to the Packages file already. Another thing that should have been happening within Debian (but happened at Ubuntu) is 'upstart'. There have been a couple of packages dealing with new init systems, but none ever managed to get support into other packages (nor is there any package in Debian with upstart support that I'm aware of).

Getting SELinux strict support into init ramdisks is another big thing I'm too scared of to even attempt... i.e. I doubt that I'll be able to do that on my own, yet even to get it into the actual packages...

DPL candidates: any ideas on how to be come more agile in such points (e.g. adding support to sysvinit+upstart+initng+runit to all packages with init scripts)? It took us already ages to get LSB headers added to many init scripts. Or on any of the other transitions we should do (SELinux support, Debtags, ...), or even why we've lost this flexibility?

The one idea I have for that is to try to do some hackfests. Like an init transition day, where a group of people tries to NMU most of the packages that have init scripts. Or adds "Homepage:" to most packages, which some important package metadata we only have on some packages. Or adding 'watch' files.

Some of these would be easier if we had a common way of packaging and a central SVN repository. That would make it both easier to prepare the transition (e.g. committing init scripts beforehand) or especially for adding Homepage metadata and watch files without actually interfering with the maintainers work by not doing an upload immedeately, but just adding them to SVN so the maintainer includes them on his next upload.

(Sorry, no comments enabled in my blog.)

P.S. another thing I'd really love to see is a (semantic) PackageWiki for Debian, that has a Wiki-like structure with a page for each (Source-) package. Including things like e.g. Screenshots, Homepage link, Link to the Freshmeat page of the package, support lists/groups ... Kind of like the QA pages, but for the actual users, and editable by visitors.

With the help of the great qa.debian.org developer overview pages (great tool, thank you Igor and all others who contributed. It keeps on getting better!), I found out that a NMU I did during a Munich BSP for sarge still lives (it was a simple 'recommends' removal NMU): html2wml was not changed since then. Popcon lists a few installations for this, there are no bugs open, but I wonder if the package is actually still working or useful. Or if we should keep it in the repository (it has not been orphaned; but it doesn't look like the maintainer has been active since 2003, I didn't check the MIA tools though).

I have a Debian wish for lenny:

• define and deploy a standard way of packaging software, that can be used for like 90% of packages. (It doesn't 'have' to be CDBS, it can be something 'better' for a reasonable definition of better. CDBS is the closest of the packaging tools I've tried so far, I've had single line package scripts with CDBS for many packages)
• Put the maintainer scripts into version control, it should be something with a central repository, but that of course allows maintainers to easily do a local branch. Especially for backports. Maybe SVN with SVK is okay.
• Use a standardized patch system along with a toolchain, quilt-like
• Link this patch management to upstream watching, so that patches applied upstream can automatically 'disappear'

Why do we really have to make a distinction between NMUs and maintainer uploads? I agree that we need to have someone (which can be a group) be responsible for packages and need to keep track of that to detect unmaintained packages (as well as to have someone track bug reports).

With this central repository, we could have NMUs committed to the packages directly, and make contribution easier in general.

For example, right now transations are usually added to a package via a bug report. The maintainer then needs to go through these bug reports (and some packages have so many open bugs I doubt the maintainer has a real overview over them; so he might easily miss some easy to fix ones), extract the patch and apply it to his package after review. With this central patch tracking system, the translators could just commit the translation change to the package directly, and it will end up in the next upload automatically.

(Note that I'm not trying to force all packages to be maintained this way. I agree that for some packages it's not really appropriate. In general it should be left to the maintainers discretion. However I guess many team-maintained packages are handled in a similar way already, and I'd like to use that for my packages as well, even when not having Co-Maintainers. I'm also aware that when fixing security issues, you might not want to make your changes world visible immediately. This can however be done using SVK if we end up using SVN, for example.)

Some rationale for this suggestion:

• Promotes team maintainance
• Offers another easy way of contribution (especially for sponsorees)
• Better change and version tracking
• Standard way of packaging makes NMUs and adoption easier
• Makes it easier to work on many packages when needed (e.g. new GCC version fixes, porters, translations, upstart support, SELinux support, Python, all kinds of transitions)

In fact I think that other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes.

Anyway, just my € 0.02

[Yes, I'm aware that this was covered in the DPL debate, but IMHO the point of different packaging preferences falls a bit short, and probably needs to be addressed first, before being able to have a central VCS for all packages. Also I think we should be able to find a common VCS we can all live with, or at least 90% of packages.]

[And yes, I'm aware that this is a controversial topic that can easily start yet another flameware. But we need to find a way of keeping flamewars down anyway...]

Debians /etc/network/interfaces is a powerful way to setup multiple profiles; NetworkManager is a pretty UI for managing your network. However they don't play well together: NetworkManager will ignore devices managed via network/interfaces.

However, NetworkManager lacks a couple of important options, including static IPs and several wireless options; I can't connect to my universities WAP2 network using NetworkManager because of some missing options.

This is why I wrote this small script:

#!/bin/sh
# disable network manager:
dbus-send --system \
  --dest=org.freedesktop.NetworkManager \
  /org/freedesktop/NetworkManager \
  org.freedesktop.NetworkManager.sleep
sudo ifup eth1=eth1-lrz

My /etc/network/interfaces contains a working setup for my wireless named "eth1-lrz"; since this differs from the real device name, this works fine.

Running this script will tell NetworkManager to disconnect and instead setup the wireless for my university network. When connecting to a different network, I only have to do "ifdown eth1" and then click on the NetworkManager applet to enable it again. (would be "org.freedesktop.NetworkManager.wake")

... is pretty bad. So far, only four applications (i.e. much less than 1% of all packages) have been renamed to ice* (i.e. frozen!):

Iceweasel, Icedove, Iceape and Icedax. Or did I miss something?

P.S. All your freeze are belong to us.

P.P.S. Stupid SUV drivers delaying our freeze. Your CO2 production causes the climate to change, which makes freezing much harder!

Congrats to Felipe C. for the Bug-not-found bug (aka: the bug with the magic number 404 404) :-)

And thanks for the spanish translation.

Here's my contribution to the next DWN:

Some developers continue to whine in inappropriate places [1] about others being paid by Dunc-Tank for their work on Debian.
[1] http://www.debian.org/News/weekly/2006/42/

Would you please cut down your childish behaviour a bit more? Can someone else maybe step up and do DWN instead? I'm sooo getting tired of this (and you).

(Granted: at least you didn't claim that everybody is demotivated because of this, or that it delayed the etch release. Thats why I added the "more" in the previous paragraph; also what you wrote is likely correct - I can't judge your true motiviations, if you are actually demotivated or if you just don't like AJs hair color.)

It's a very subjective point of view, and while somewhat marked as such ("because its editor can't ignore other duties while the Debian project is indirectly paying some developers"; however there are six editors listed at the end!) I find it inappropriate to put this into DWN (which should try to be obejctive). To me, it's just another lame attempt of you to voice your disagreement with Dunc-Tank (again, note that you have been heard by the whole community, there is no censoring being done) in an unfair way (because I couldn't voice my opinion in the same place).

Did you at least talk about this paragraph with the other "editors"?

(Note: I'm not directly pro dunc-tank, and I find the way AJ introduced it not too appropriate; my suggestion would have been to ask him kindly to step down from having a position in the dunc-tank board. However I'm certainly not demotivated by it, but I find it both good that key people of Debian are being paid without having additional responsibilities to some company, and that there is now a way to donate to Debian that won't just eventually maybe be used for something, but where I can clearly mark it for.)

[Yes, I am aware that others are just as annoyed by my responses to Joey&co. Especially when they happen to agree with him. Nevertheless he maybe shouldn't be abusing DWN!]

A few days ago, I blogged on the popularity of Debian, using Alexa ranking graphs. They showed Debian ahead of the other distributions in terms of web page accesses. Ubuntu definitely was the top growing domain there, but it didn't reach Debian yet, and there was no drop to suggest that Debian was actually losing users to Ubuntu.

Here is another chart for you: (Note that it has a referrer block, if you are reading my blog via some planet I'm not aware of, I can add you to the whitelist that is allowed to refer to the image. I added this because some images from my photoblog were heavily linked from myspace and similar sites.)

This is a chart from the Debian popularity contest statistics. Submitting data here is entirely voluntary; the data is used to determine which packages to put on which CDs in the CD set.

The chart contains four lines, the top line is for bash; pretty much every system has bash, so this is very close to the number of submissions to the popularity contest database. Note that this number has doubled within one year.

Sarge was released in June 2005, and thats where the graph changes significantly. Up to then, popularity contest was a rather uncommon package, but sarge promoted its use somewhat IIRC. So lets look only on the post-sarge part of the graph. Ubuntu Dapper was released in June 2006. Any effect? No.

The other lines are gnome-session (green), kwin from KDE (blue) and openoffice.org-base (red). KDE is at about 25%, Gnome at about 50% and Openoffice goes up to 50%. This suggests that a significant amount of Debian installations are actually desktop machines (I remove popcon on all my servers, where I'm more concerned with not having too much software on it). For KDE and Gnome, these values have been quite constant. When only counting "active" users, Gnome drops to about 25% (same for OO.o), and KDE to around 10%. VIM would be at 35%, same for apache.

I don't claim these numbers are accurate; it's probably more interesting to compare Gnome vs. KDE and similar things. The total number of submissions (represented by bash in this graph) shows that Debian is quite healthy.

Oh, and of course I'd like to invite you to install popularity-contest and contribute your software choice to optimizing the CD layout for etch.

Joey and Josselin, I'm calling you childish, not because you "stand" your principles, but because of the way you try to convince others that your principles are better.

What you are using is:

• Insults ("lying", and for the record, FUD means twisting the facts and telling only half the story, and you are twisting the facts, as I detailed in my post; "should read constitution", which of course means to imply that I'm trying to deny you some constitutional right, which I'm not, I'm just asking you to stop spreading FUD)
• Blackmail and threats ("I'll stop contributing" [if dunc-bank is paying anyone], "reduced it much less than I could, probably much less than I should")
• Schadenfreude (the libpng mishap of the new maintainer; noone broke libpng intentionally. That is not a nice character trait, and pollutes the community)
• You seriously annoy people by going on and on and on, while everybody has already understood your opinion and arguments (and just happens to have a different opinion)
• Playing big words without actual content ("read the constitution §2.1.1", which btw. also states that you "must not actively work against these rules and decisions properly made under them"; your attempt at a GR failed, and you are working against these decisions on planet; I've however never said that you're oblieged to still work for Debian if you don't like the decision)

Actually, I'm by now convinced that it would have been better for Debian, if you would just have really left. Your behaviour in the last months makes you qualify as "poisonous people" (except these usually aren't big contributors). In my opinion, your infighting has harmed the project, it gives people the impression that being involved in Debian means mostly having to deal with such things. While it's not - Debian is still fun to me, although I have little time, and didn't manage to go to the last few Debian meetings here in Munich - all these fights are a nuisance to me. Even though I'm not actually affected by them (neither Dunc-Tank, because it doesn't demotivate me, nur the powerpc fights, nor some other fights on -private), the way they are dicussed on the Debian lists does annoy me.

Again: if anything is cutting on my motiviation, it's your behaviour (this btw. includes the powerpc issue and fighters, too, especially Sven Luther who has probably sent as many mails as all others together, just reiterating the same things again and again). So if you are planning to become a Debian contributor, learn to use the "delete" button in your email clients, and don't be afraid to just delete whole threads. Certain threads are just a waste of time and bring negative emotions.

So: Joey, Josselin: grow up, and accept that people sometimes have a different opinion, and you can achieve more by accepting that your opinions differ and just try to make the most of it anyway. Reminding them of your differences won't make them change their mind, nor will it make them like you any better.

Fortunately, most people in the project (well, everybody except me?) seem to obey above "poisoned people" recommendations, and just ignored your posts on this issue. I didn't, and one of the reasons it that I feared Joeys first post could grab some media attention, and I felt there should be at least one post saying that, well, the debian-installer and some other RC bugs are probably also a cause of the delay, and it's probably not worth rehashing the dunc-bank issue. So far, I've only seen one news article citing aba that the delay was caused by the debian installer among others, no "the delay is due to dunc-bank demotivating all developers" FUD.

Joey and Josselin are trying to bring dunc wars back. Please ignore the trolls.

They're talking more FUD than ever. And yes, I consider this behaviour childish, too.

Basically they claim that dunc tank is to blame for the etch release delay.

Sure, blame AJ for the attr breakage. And the libpng disaster. And the FransPop and others vs. Sven Luther issue. And the installer delays.

Especially the latter. The installer has never ever before delayed a Debian release, so obviously AJ and his dunc tank are to blame.

(Well, actually I think that this kind of infighting done wrt Sven Luthers access to the debian-installer repository or the anti-dunc-tank-evangelists that really harms the project: this can really take a lot of fun out of Debian, more than dunc-tank ever could. But pointing at the installer is more fun, you know...)

So Joey, Josselin: please, grow up. Stop trying to harm the project just because you disagree with a decision some months ago.

Thank you, aba, for working e.g. on helping sorting out the libpng issues and doing a quick NMU for the attr breakage. And all the other release work you've been doing before, during and after dunc-tank funding. Your work is heavily appreciated because it's constructive.

Debtags made quite some progress the last months. Many thanks to Enrico Zini, who did most of the work.

We now have a new database (on alioth), a new editing frontend (using Ajax, and accessing this database) and a couple of nice utils around it.

Go Tagging is a page listing untagged packages - by popularity contest score.

Just go there, click a package you are somewhat familiar with (sorry, the really popular ones are already gone :-) but there are still some well-known ones in there such as "rails") and edit the tags. Enrico also did some kind of AI to suggest tags. This is not based on the Google Summer of Code project, but something Enrico did using the Xapian search engine index he's been using for the main search function.

A couple of good features have been proposed, but are not yet implemented. For example, a "similar packages" overview, so that when you've been tagging one package you could easily switch over to another similar package.

Or a per-maintainer view. It was suggested that it should be added to the packages.qa.debian.org per-maintainer view page; this would be great, but will require some more work to be done.

On a related base, it would be interesting to make a tag cloud (like this Debian package cloud) on one maintainers packages only. This would then be a view of one maintainers interests in Debian...

Anyway, thanks to everybody who has been tagging packages and helping with the backend databases and applications.

When I run cowbuilder (or pbuilder), they mount /proc and /pts in their chroot. Nautilus notices this and places icons for proc and pts on my desktop, which actually is quite annoying...

Dear Lazyweb, how can I tell nautilus to not display these "filesystems" on my desktop?

Get enigma (new version 1.00 beta in incoming, should hit unstable soon) and you won't have time to work for the release anymore.

It's a great game, and it has almost 1000 levels now.

Please help test the beta, and lets delay etch! :-)

This is also the first package I've built with cowbuilder. I don't know if its faster - my new laptop is much faster, and I've been setting up a new development environment. But it works for me.

This is the shortest debian/rules file I've ever written:

#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk

CDBS can very clearly say "nothing special in this package". Everything else in this package is handled by debhelper defaults. Granted, this is a very simple package. But thats what I like about CDBS: don't waste my time (or the time by someone reading the debian/rules file) when it is standard stuff.