The sysvinit version that hit unstable today has a grave bug if you have been running "startpar" or maybe "shell" style parallel booting. Read this bug report, if you have been using these (they were not enabled by default, so unless you've been giving parallel boot a try before, you should be ok.)

How to check if you are affected:

grep CONCURRENCY /etc/default/rcS

If this command says "startpar", then you ARE affected. If it says "shell" you MIGHT be affected. If you have not set CONCURRENCY or if it's "none" or "makefile", then you should be ok (according to the bug).

The workaround is as simple: just put either "none" or "makefile" in there, these are the only two values that are still distinct.

How to recover a broken system:

1. Boot recovery mode aka "single-user". At some point you should be asked for the root password. Login.
2. Run mount -o remount,rw / to enable write mode on your disk.
3. $EDITOR /etc/default/rcS and change the value of "CUNCURRENCY"
4. reboot

You should have a working system again.

I can only confirm that changing "startpar" to "none" helped me. I havn't tried "makefile" yet, and "none" seemed more likely to fix things.

Unless someone drops in as new maintainer, I'll file for removal of ModLogAn from Debian soon.

The software has been abandoned upstream for, well, a couple of years. It still works okayish (just the patterns need refreshing), and in fact I'm still running it. But there is plenty of software to replace it, and it seems as if many people go the Google Analytics way today.

Please speak up quickly if you care about ModLogAn, otherwise it's gone from Debian soon.

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

I hope to see more applications - and good luck that we get enough slots for all of you!

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>

Into yet another custom file in this directory.

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

to a custom file in /etc/modutils/, in order to avoid your PC speaker showing up as regular audio device. You don't want your regular apps to consider your legacy PC speaker as audio device usually.

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!

.

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

(see the Wiki page for details on these projects).

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

And do the update by calling

$ 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

Note that I'm not suggesting to automatically remove any package. It also is not supposed to be a list with all packages that ever were removed. But just packages where it's known that they might need to be removed. Nor is this list meant to do away with aptitudes automatic uninstalling of packages that were only installed to satisfy dependencies. (If you are still using 'apt-get', you should really consider to use 'aptitude' instead. It will automatically uninstall all those 'libfoo13' packages for you if you use it consequently. Whenever you install a package with 'apt-get', aptitude won't know if it was manually selected or automatically, and assume manual.)

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.

, 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...

, 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.

But other than that, the upgrade was mostly a job for apt-get, not for me.

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]
...

So there is something wrong with the XFS malloc handling. This has happened twice now since the reboot. I've been suspecting XFS of being related to the servers' crashes before (which tend to occur during load; the crash which 'allowed' me to switch to 2.6 actually showed the OOM killer of that old kernel killing some inappropriate processes). After the easter holidays, I'll reboot the machine with the etch kernel, maybe this is gone then.