First, a question: dear lazyweb, how do I completely disable non-SSL access with lighttpd? I can't seem to find how to have a lighttpd SSL-only configuration. (and only binding port 80 on localhost does not count for an answer)

On to the subject. While it's easy to add SSL to lighttpd and enable PHP (through fastcgi) and Debian makes it even easier with it's lighty-enable-mod tool if you only do it once in a blue moon then it's not exactly resident knowledge. So here are the steps to do it, on Debian Etch:

1. apt-get the lighttpd, php4-cgi or php5-cgi, and openssl packages
2. lighty-enable-mod fastcgi
3. if using php5, update the path to the cgi binary in /etc/lighttpd/conf-available/10-fastcgi.conf (it's preconfigured for php4)
4. lighty-enable-mod ssl
5. update the path to the SSL certificate in /etc/lighttpd/conf-available/10-ssl.conf
6. restart the lighttpd server

That's all there is to it. Well, strictly speaking there's a step 4a: install a certificate; but that's arguably not a part of the configuration process.
(for reference: openssl req -new -x509 -keyout /etc/lighttpd/selfcert.pem -out /etc/lighttpd/selfcert.pem -days 365 -nodes will generate a self-signed certificate)

Rhonda,

The webinterface for it doesn't require any authentication at all, leading technically to anonymous translations all over the place. The so-called "review" process consists of the same not-existing authentication, leading to a situation where unknown people can put in whatever they like and have other (or potentially the same) unknown people acknowledge that.
The language team has actively chosen that way because it was said that bad translations simply won't happen and that the review (three people opening the page and clicking onto a button) will not let that happen. Well, it happened. And is happening all over the place.

Hmmm... That sounds quite like a definition of Wiki in my book. Just add a version-control layer underneath, and...
Oh, you didn't? Umh... Tough luck! :-(

Last week I did again some work on nagios-plugins. After the announcement of Dann Frazier to upload NMU to fix a trivial bug, I thought it’s time again to give some extra care to the package. So I prepared 1.4.11-2 fixing the important bugs and uploaded it. I also commited some minor fixes to the svn, so these issues will get fixed by the next upload. Since the development of policyd-weigh stalled and unfortunately maybe get stuck, I was looking for an alternative, which maybe found with postfwd. It’s quite flexible but it also will take more time (and care!) to get a reliable configuration, which maybe effective as policyd-weight (still) is right now. While checking the dependencies for postfwd I noticed that Net::DNS::Async isn’t available in Debian (yet). So I decided to create a package starting with dh-make-perl, join the Debian Perl Group and let it review. Damyan Ivanov was so kind to review and upload it, Gregor Herrmann did also give some much useful hints. Thanks to both! And yes, I also found time to step forward with NM, since I was overloaded the last weeks with usual work and life. Thank to my AM to be so appreciative.

I spent part of my Sunday on samba yesterday. After all, that ankle tendinite I have for nearly two weeks now has some benefits for Debian: I don't waste hours running on week-ends. Samba 3.0.28a was announced by upstream and I worked to package it. Not really difficult and the package is already ready. It again minimizes the numer of Debian patches: we're slowly converge back towards upstream. Meanwhile, Steve uploaded a new release of 3.0.28, introducing the use of ucf to manage smb.conf changes. He slightly messed up in the update and, therefore got 3 RC bugs in a row for the same problem (#470138, #470139, #470140...and even #470142 to complete the picture). Good score, Steve. One beer for me next Debconf...:-)...The breakage was fixed a few hours later. So, conclusion: we apparently have active users who are committed to reports errors. Good...:-) As soon as 3.0.28-4 makes its way to unstable *and* the automated Ubuntu merge-o-matic, I'll probably upload 3.0.28a, not really waiting for 3.0.28-4 to enter testing (we already have 3.0.28 in testing). Another work in the pipe is the preparation of samba 3.2.0. Upstream released RC2 last week and I did early work to package it (for experimental as of now). However, that release incorporates most parts of our "FHS" patch, for better compliance to the FHS, as well as several other patches we pushed to them. And, as these weren't applied as is, some checks have to be done. Moreover, some other changes seem to be needed to get the package to compile. And, finally, we need to merge back recent changes from the trunk branch (such as the ucf support). All this is a way too high barrier for me and I'll need Steve to take that load, which he promised to do (and so *will* do, I know him enough....). When all this will be settled down, it will be time to jump in the BTS and fight with some old bugs of the package.

I previously wrote about my visits to Turkey to develop our export market in the Middle-East and how I ended up representing the whole Estonian business world in bilateral negotiations with Turkey. I'm going there again for two weeks, this time accompanied by a whole business delegation headed by Estonian prime minister Andrus Ansip. Asides from various official events organized by our Turkish hosts to present Turkey to their Estonian guests, the crux of the visit is a conference hosted by DEIK and the Estonian embassy, on Tuesday, March 18th. The goal of this conference is to present Estonia's extremely advanced use of ICT technology in E-Business and E-Governance. Speakers from several private and public sector organizations will explain how they benefited from Estonia's hyper-connected lifestyle and, most of all, how this has made every Estonian's life more pleasant, because it offers a convenient way of performing a broad range of online transactions not just with businesses, but also with governmental organizations. Yours truly will speak about the advantages Estonia offers to investors and technology freaks alike, from the perspective of an industry insider who, given the opportunity of choosing his first pick for a liberal high-tech nation, dropped the Nokiaesque lands of Suomi to go Eesti. The morning of conference will end with a business lunch where interested Turks can network with their Estonian counterparts and create lucrative bilateral opportunities. Space in the TOBB Plaza auditorium is limited so those interested in attending should promptly contact DEIK to get their name added to the guest list. Turks interested in learning more about Estonia in their own language should visit estonya.net.

In case you didn’t know, I’ve decided to resign as atheme project lead. This is for a few reasons:

• Firstly, I have felt overall ineffective in this role since late 2007. This is probably due to the fact that disagreements between me and several other people have resulted in people leaving the organization to work on other projects, and the fact that atheme has not grown in any significant way since last year’s Summer of Code event.
• Secondly, I am busy with a lot of other things and do not have time to give the proper attention this role needs. This role is basically defining the direction that atheme grows in, and capitalizing our strengths to expand the project and promote it. I see the lack of growth and proper promotion as a personal failure.
• Thirdly, at the moment I am under a lot of stress due to dealing with various issues at the moment, which is leaving me irritable and generally quick to anger. This is not a quality we want in our project leadership. In short: I’m fucking up, and it needs to stop. So right now, I am resigning as project lead. If people want me back when I am under less pressure in general, then that’s great.
• Fourthly, we need to see new leadership in atheme anyway, to keep things interesting. Without a regular change in leadership, people will start to see us as someone’s personal project, and that’s not the case with atheme.

However, just because I’m resigning as project lead doesn’t mean that I will stop working on projects I care about inside atheme, like audacious, mowgli, and mcs. These projects are critical components of the modern FOSS desktop, and I intend to continue working on them. This is purely an administrative change, so that any mistakes or stupidity I do have no effect on atheme.org’s overall health. I hope to see many other Atheme members step up and try to become project lead. Under the right leadership, atheme’s projects could become a much more notable platform in FOSS development within a short amount of time. Update: Due to popular demand, I have changed my mind. I’m no longer resigning as project lead of atheme.

dpkg-cross updates
uploaded to Debian unstable

   * General support for querying endianness of an architecture.

   * Update standards version (no changes)

   * Add Cvs-CVS field to debian/control

   * Reinstate detect_arch for improved build test checks in emdebian-

     tools

   * get_endianness: new function for Emdebian TDeb support

This provides support for architecture-dependent TDebs in Emdebian as well as adding detection of armel.

emdebian-tools 0.8.3
Uploaded to Emdebian

   * Interim Emdebian release.

   * emsecondstage: ensure cdebconf environment is setup before

     configuring packages

   * emdebian.gpe: Add extra packages needed to allow the gpe package set

     to boot.

   * Emdebian::Tools, (create_patches) : skip generated files.

     [*.debhelper, *.substvars, files]

   * em_installtdeb: support special modes via debian/xcontrol

   * Support unpack method in basic emsandbox rootfs

   * embootstrap: continue after some errors

   * Support unpack method in gtk emsandbox rootfs

   * Simplify basic empdebuild chroot and copy in hostname files

   * empbuilderlib: add support for creating skeleton versions of

     /etc/group and /etc/passwd.

   * empbuilderlib: add an approximate time set func for use when no

     network is available.

   * emsecondstage: configure cdebconf before others so that the database

     is ready

   * embootstrap: use the new support in empbuilderlib for group, passwd

     and date

   * Add --arch support to em_installtdeb

   * Depend on new support in libdebian-dpkgcross-perl

   * empdebuild: force the -S argument to apt-cross to prevent

     intermittent failures

   * empbuilderlib: parse the .list contents from dpkg

   * embootstrap: ensure buildplace is clean before starting a fresh

     debootstrap

   * emdebuild: use dpkg-cross support for detect arch to distinguish

     between arm and armel binaries

   * Emdebian::Tools. add parse_xcontrol function for easy queries of

     debian/xcontrol

   * pbuilder/emdebian.crossd gpe gtk : Tidy up the scripts with routine

     calls to the empbuilderlib library

   * pbuilder/empbuilderlib: Add some common routines to help make the

     rootfs bootable

   * pbuilder/emsecondstage: bring into line with other changes in the

   * empbuilderlib.3 : Add a manpage for the expanded set of common

     functions in empbuilderlib

   * Suggest file-roller for inspection of rootfs tarballs

   * emdebhelper.mk: sync with recent changes in CDBS for debhelper

     support

Reasoning
OK, so why upload emdebian-tools to Emdebian when it depends on the update to dpkg-cross in Debian?
Well, emdebian-tools is becoming a bit of a behemoth. I mean a package that has only existed for 12months and has had over 30 releases, increasing in size from 30kb to over 500kb (without counting dependencies) and which encompasses a gammut of scripts with different roles is just begging for a functional package split.
Package splits take time - not just the time in NEW but all the testing to ensure that each split can be installed separately without falling over "Unable to find foo in @INC" etc.
At the same time, emdebian-tools is both rapidly developing and becoming remarkably stable (which gives some indication of just how diverse it has become).
So I'm heading for a 1.0.0 release before Lenny and to achieve that, I want to split it:

1. emdebian-tools - umbrella package consisting of the core build scripts (perl) - these are becoming quite stable - that depends on all the others.


2. emdebian-archive-keyring - tiny package that just implements SecureApt for the Emdebian repository.


3. emdebian-rootfs - the rapidly developing (shell and perl based) root filesystem management scripts, based on debootstrap and pbuilder.


4. libemdebian-tools-perl - a standard perl module of common functions for the other packages.

This allows people to use the toolchains with the smallest package, prepare root filesystems from prebuilt binary packages with just three of the four and only those who build packages will need all four.
So the plan, overall, is to keep updating emdebian-tools in Emdebian unstable during the time that emdebian-tools 0.9.0 goes through NEW in Debian. Then, when 0.9.x is in testing and any issues from the split are resolved, 1.0.0 can be uploaded to Debian.

Package split issues in general
Something that bugs me with package splits is this stable vs development issue within the same source. I think it would be sensible to only upload emdebian-tools (the stable bit) if it changes but to upload emdebian-rootfs as often as necessary whilst still building from the same source.
This issue will also bite when Emdebian deploys other functional package splits and seeks to improve apt itself to handle many, many more binary packages.
It's also a similar idea to allowing translators to upload TDebs separately from normal package updates.
Why should I have to split the source in $RCS in order to upload package splits separately? Other upstream teams won't do that so Debian needs a solution.
Why should users have to download emdebian-tools 1.0.1 which is absolutely identical to 1.0.0 just because emdebian-rootfs needed lots of updates in 1.0.1. (Remember, emdebian-tools will depend on emdebian-rootfs so when emdebian-rootfs is updated, all users of emdebian-rootfs and all users of emdebian-tools will get the update. Yet I don't see why emdebian-tools itself needs to be touched.)
It is plain daft.
I've seen similar issues in other environments where, for various very good reasons, users need to limit the bandwidth and duration of apt downloads. For Emdebian, we also need to limit the total amount of data downloaded by apt-get upgrade simply because free space on the device can be severely restricted - my target device will have about 7Mb free space and that is regarded as "under-utilised". Downloading an entire package just to update /usr/share/foo/changelog.gz in such circumstances is just plain stupid. I know we can do better than that.
Apt needs to become much more intelligent and have a way of only downloading the changes in packages instead of the entire .deb - something along the lines of an rsync method. To get that working, the actual package names need to be munged so that rsync can compare foo_1.2.3-1_all.deb against foo_1.2.3-2_all.deb by having both symlinked as foo_current_all.deb. (dpkg-name can restore the original name if needed.)
Such a method must be possible and would have enormous benefits for packages like OOo where each upload can't be changing 100% of the code each time, yet we all have to download Mb after Mb of content that is identical to what dpkg is about to replace.
Am I just ranting or does this strike a chord on the lazyweb in general?
The slowest part of many desktop experiences of Debian could well be the time taken to download updates - not everyone has multi Mb broadband.

Tomorrow I turn 32, so I've got to be all mature and responsible and stuff now. Maybe. This means no more song lyrics will be used for blog titles. Instead I shall switch to film quotes. Films are more mature than songs, right? There are three candidates standing for the DPL this year. I'm glad I didn't stand, but I came pretty close to doing so. I just think I'd be unlikely to receive the votes, and busy enough to fail even if I did get picked. It seems to me that every year people promise to do too many things; fixing NEW, fixing the NM process & etc.. Me? I'd have only one goal: Open up the keyring-handling. Nothing more. Nothing less. (Sure I'd blow all the Debian money on new toys for people but that'll be our little secret ;) Anyway since there was a bit of interest I've uploaded a new steam engine video and I've started to document some of my collection:

• My steam engine page.

More updates later. Really I need to sit down, clean my toys, and then get some good pictures taken. Maybe next month I'll find the time. (Ha!)

There are two ways of telling a story: The first way is just reciting what happens. I did foo. Then I did bar. That didn't work, so I did quux.. The second way is reciting what mistakes you shouldn't have made. Lessons learned: don't do foo, because that will result in bar, and a visit to the hospital. No, I won't be updating the package, as I promised. In the interest of, well, keeping things interesting, here's a tale of what I did last week, in reverse mode:

• It's not a good idea to forget to close your laptop bag when you throw the bag on your back, since that might catapult out the laptop and break your hard disk.
• When ordering a replacement hard disk, it usually helps to call the supplier to confirm the payment so that you can actually go and get the disk, rather than waste several days on waiting
• When installing MacOS on a secondary partition after installing Debian and spending several hours fine-tuning the Debian installation, do not run the MacOS partitioner. It will reformat your Linux-partitions as HFS+ ones.
• Remember that it takes several hours to download the DVD image to install Debian. Downloading that one rather than the CD image, or (better yet) going to the office where you have such a DVD lying around in order to "save time" is silly.
• If you restore from backups, and your backup program in its default configuration writes to /tmp, do not forget that Debian in its default configuration clears out /tmp on boot. This is especially important if, due to the relative speed of tape streamers and network hardware, the process of restoring from backups takes several hours and you shut down the laptop after completing the restore, so that you can go home. Sigh.

The good news is that I now have a 160G hard disk rather than a 60G one. Whee.

Fields used by an LDAP Unix user database Some notes about LDAP for Unix user management: Meaning of fields for objectClass posixAccount:

• uid contains the username
• uidNumber contains the numeric UID
• gidNumber should have the numeric GID
• cn should contain the user's full name (optional)
• homeDirectory and loginShell contain what you think they contain
• gecos contains the gecos from passwd (optional)
• userPassword contains crypt followed by the encrypted password from /etc/shadow (md5 password hashes are ok as well) ( SASL is an interesting alternative)
• sn is the surname (optional)
• givenName is the given name (optional)

Meaning of fields for objectClass posixGroup:

• gidNumber is the group id
• cn is the group name
• memberUID attributes contain posixAccount.uid values

For objectClass inetOrgPerson: what you put there can be used as if it were a vCard by mail programs and contact lists. Now, the name of people could potentially be split in cn,givenName,sn,gecos and displayName (possibly more): how would normal user tools deal with the redundancy? To show a gecos field, pam_ldap will search for a gecos field first, then automatically fallback on building a gecos field out of the other suitable info it finds. To show a name, sane programs try displayName first and if it's not present they guess using the rest. Then there is the issue of how to chose the dn to identify users, groups and so on. Users usually go in uid=$USERNAME,ou=People,$SUFFIX, while groups would usually go in cn=$GROUPNAME,ou=Groups,$SUFFIX. Should you need to create the People and Groups organizational units, this could be the proper bit of LDIF:

dn: ou=$NAME,$SUFFIX
ou: $NAME
objectClass: organizationalUnit

To add fields that are not already part of a schema, one needs to create their own schema. To do that, one needs to first obtain (free of charge) a Private Enterprise Number that is used in various places in the schema definition. Making up your own one means risking conflicts if you eventually grow larger. But it is rarely needed, because for most things there are already schemas available. Many thanks to Wouter and noshadow for allowing me to crudely extract all this content from their brains.

Android relies heavily on something called "resources" to access portions of the system that aren't directly in the Java code. For instance, if you had an ogg file that you wanted to use to play a sound with, you would add it as res/raw/foo.ogg. Then, during compilation, the aapt tool transforms all your resources into a Java file called R.java, which is basically a series of integers that can be used to reference the actual resources. For instance, to set up our hypothetical ogg file, we would do:

MediaPlayer mp = MediaPlayer.create(context, R.raw.foo);

That's all well and good as far as it goes, and if you don't have any reason not to use it, you should. However, with Hecl, one of my goals is to make it very easy to create applications. This means:

• No complex directory layout structure.
• No big long build files that require tools like ant.
• No complex compilation steps.

I'm not there yet, on the Android platform, which is a bit more complex than Java ME (where it is indeed so easy to create new Hecl .jars that it's possible to do it on the fly via this web site: http://builder.hecl.org), but I am making progress. One thing that a user might want to do is add their own files to the .apk file that actually gets installed on the phone. Since it's just a zip file, that's pretty easy:

zip -r Hecl.apk res/raw/foo.ogg

However, without a resource, there is no way to access that file, so the question is: how can we get ahold of it somehow? The first piece of the puzzle is Java's ZipFile class, which lets us open up a zip compressed file, such as the .apk file that contains the ogg file we're interested in in this case. The critical passage is getting ahold of the actual filename on the Android filesystem of the code that's currently running. It turns out to not be too difficult, if a bit obscure:

String filename = this.getPackageManager().getApplicationInfo(packagename, 0).sourceDir;

With that information in hand, we can feed it to ZipFile, and then access the contents at run time. It's not a perfect nor complete solution, yet. So many of the Android API's require a resource ID, so it takes some extra coding to do things from the InputStream that we can get out of the zip file, but there may be ways to make this easier. For instance, we could simply dump the contents of raw/ into an application specific data directory the first time an application runs, in order to at least be able to access the files as files, rather than InputStreams connected to ZipEntries. In any case, at least it's possible to access files added to the .apk without requiring the compilation step. I'm not sure how many other use cases there might be for direct access to the .apk file, but if other people need to do this, hopefully this information will be helpful.

Uploading gpsdrive tracks to openstreetmap I've got some gpsdrive tracks and my area is blank on openstreetmap. People pointed me at gpsbabel, and it took me a while to figure how it works. For the record, don't do any of this:

gpsbabel -i gpsdrive -o gpx -f track0000.sav -F track0000.gpx
gpsbabel -i gpsdrive -o gpx track0000.sav track0000.gpx

What you would have to do is this:

gpsbabel -i gpsdrive -f track0000.sav -o gpx -F track0000.gpx

However, it would choke on gpsdrive's "missing" points with all values set to 1001. You can grep them out, then gpsbabel would work, but openstreetmap would reject the data because the points have no timestamp: gpsbabel won't carry that on from the gpsdrive tracks to the GPX tracks. The way to go is here, which contains a link to a tiny little perl script that will do the proper conversion for you:

./gpsdrive2gpx.pl track0000.sav > track0000.gpx

Those you can upload them to openstreetmap, at last.

Imagine when a frequently used application doesn't work anymore on your machine. It simply won't start anymore, whereas an older version does work flawlessly. Of course you would submit a grave bugreport, wouldn't you? And maybe you will be able to find the cause for the problem and submit something like a patch to fix this problem? At least you are sure that you are not alone with this problem, right?

Usually you would think that this kind of bugs would be fixed really fast and a new and fixed version will be uploaded soon, right?
But that seems not to be the case for PowerPC users, who are waiting for over a month now for a fixed version of Icedove.
Is there any (unknown) reason why there's still no fixed version of Icedove that works on PowerPC? If so, please let me know...

OCaml(Core) GForge enters beta testing status Since a few weeks we have set up a team of people which is working on offering software services for the OCaml community, which in this respect has been lagging behind other programming language communities for too long. By chance, the team has turned out to be composed by Debian DDs and contributors (Sylvain Le Gall which is leading the effort and also offering hardware via his new company, Pietro Abate, Romain Beauxis, and myself). The name of the project is OCamlCore. A few weeks ago we announced the availability of an OCaml-related planet, which since yesterday is also being advertised on the resource page of the language. The other relevant service we are setting up is a forge for hosting OCaml-related software projects. Yesterday we have finally announced the beta testing of the forge, which is available at http://forge.ocamlcore.org. We are now looking for people which has a OCaml-related software projects which want to go to a forge or want to migrate there, and are willing to help us in discovering and fixing potential pending issues. If you are interested please read the announcement, register to the forge, and submit the project request. Please state explicitly in the project description that you are aware of the current beta testing status. Your help is needed and will be very much appreciated!

Daniel notes that self-delusion is a necessary component of all voluntary work.
Any human activity can be over-analysed into oblivion, especially if the terms of reference for "meaning" are impacted by a view of the real world that is overly abstract. Even paid work needs some self-delusion because no matter how much money you earn, the old maxims bite back - "you can't take it with you" and "no point earning it unless you can enjoy it".
Before I started with voluntary software work, I was heavily involved in voluntary charity work and the motivation is much the same. "The grand scheme of things" will never be sufficiently affected by any activity such as to provide the sole justification for that activity. The vast majority of people and the vast majority of actions simply are not and cannot become that important. (This is where religion is important for some people, the hope that despite all evidence to the contrary, acts of random kindness have some meaning to the person doing the act instead of just to the recipient.)
Voluntary work is generally for the benefit of others. In free software it is about writing code to solve our own issues in a way that others can use without facing the problems that we had to solve. Writing new code to solve a problem or fixing bugs in existing code to solve a new problem can only help others if the solution is shared. So the validation of that work is in helping someone else accomplish a task without having to spend the time fixing that issue, leaving them time to fix the next one.
Working on free software of all kinds is worthwhile simply because it is a way of helping others.
"When all things are considered", most people working on Debian are the lucky ones. Born into an environment where good education is available and where parents/relatives were able to indulge our fascination with electronic and computerised widgets that had no direct bearing on whether our basic human needs were met with regard to food, warmth and health. Trained at great expense and able to use that training not only to meet our personal financial needs but also to make time available for other unpaid tasks that benefit others who do not have those things. Living in a time of peace and stability, where the more esoteric and "frivolous" tasks can be undertaken without causing hardship or neglect of others. (My nephew frequently sums up this whole idea as like having won the lottery just by existing.)
There is an element of justification that can be derived from such a view - an element of responsibility and duty. After experiencing all those good things and after realising that we have such an opportunity, it can engender a feeling of obligation to do something that justifies what we have already received to balance out those who have the skills to do what we do but, for reasons of birth alone, do not have that opportunity or the means.
That is a form of secular humanism - validation of our own situation in the use of our skills and time to make things easier for those who are less fortunate.
OK, Debian isn't about providing clean water for all, or the redistribution of food and medicines to those without but the organisations that do that work can be assisted indirectly by making the systems used by such organisations work more efficiently, with greater stability and with more flexibility.
Not everyone can (or should) be on the front line of whatever acts of kindness will solve the problem of inequality but there is an obligation on those of us who have received the benefits of inequality to do what we can to make it easier to redraw the balance.
Debian is one such way and it is a truly international way of benefiting others too. It is more beneficial than the charity work that I did previously - chiefly because that was a very local service that was very labour-intensive and so could only benefit small numbers of people.
Improving Debian won't make us more important to the universe, life and everything (the answer to that is 42 as we all know), but it will help others do what they do, it will improve their lives and their ability to spend their time on what they want to do instead of having to fix problems that we have already solved.
Debian, to me, is about sharing solutions. Helping someone else do something that Debian could not do before, without requiring them to fix all the problems that I had to solve to devise the solution in the first place. Sharing not just the solution but the method of the solution and the means to extend the solution to new problems.
We, as Debian developers, have been granted the access and tools to solve these problems for the benefit of those who do not have upload privileges. Those rights come with responsibilities (as always) to use our skills and time to find the solution and without making things more difficult in the process.
In the grand scheme of what I can actually do as opposed to what might be possible if X, Y and Z were different, what I do in Debian and Emdebian is worthwhile. In fact, it is just as worthwhile as my paid non-IT employment in healthcare provision because, within healthcare, I can only help the single person in front of me. In Debian, I can help all those people who I will probably never meet but who want Debian to do something that I am able to achieve.
What is particularly nice about Emdebian is that there are people who tell us that our work is worthwhile by putting up the hard cash to fund work sessions and conferences that bring the various developers into one place. The international aspects of Debian can be a barrier in some ways and things always happen more quickly when the various members of the team can be brought from the four corners of the planet into one place for a week or so. It is these gatherings that boost the motivation and the enjoyment of making progress towards a common goal. Debian can be a solitary world where communication is limited to plain text. Probably the best way to "oil the wheels" in Debian is to get a group of Debian people together and just let them hack.
Voluntary work of all kinds requires personal motivation and working alone with only limited means of communication with others can be quite demotivating. Getting people together is a very useful antidote.

I’ve released dsyslog 0.2 tonight with support for BSD syslog facility and severity decoding, as well as some other nice features. You can download the source here. In other news, my computer died, so I got a new one with an Intel Core2Duo E6550, and it surprisingly outperforms my old Opteron 265 system. I’m confused as to why, after all… less cores. Also, daytime business has been forcing me to keep a schedule opposite to the one I am used to. Luckily enough for me, that will end soon and I might actually be able to get more than five hours of sleep. Sadly the lack of sleep results in weird grammatical and spelling mistakes, so it’ll be great when that’s over with! Umm, what else is new? I’m working on a Debian-derivitive which is more community-oriented: think Ubuntu except less corporate; a true grassroots project to enhance and bring Debian to the masses. Big selling point? No static releases, so users always get the latest and greatest. I don’t want to make any big claims about planned success or anything, we’ll see what happens. It’s called Defusion (you could claim it means “debian fusion” or something, but that sounds ricetastic, and if I wanted rice, I’d clearly be running Gentoo, not Debian (or Defusion for that matter)). Hmm, perhaps it’s the Debian version of ArchLinux? Well, we’ll see about that — anyone who cares is invited to participate, the requirements of entry for joining Defusion is much less than joining Debian (no keysigning parties needed here, instead we intend to do a peer review sort of thing where people who do good work get their keys added to our keyring eventually — kind of like how Ubuntu works if I understand it correctly; no flames please). As for Ubuntu, I guess I need to debug why my patch to make pulseaudio be used as default didn’t work. Hopefully this blog will be updated more in the next few weeks!

I'm sure most people have one of these, but here is my yet-another email-me-when-I-need-to-upgrade-something crontab entry, after I found cron-apt too complex:

0 */8 * * *     apt-get -qq update && apt-get -dqq dist-upgrade && apt-get -qq --simulate dist-upgrade   grep ^Inst

If your root mail goes to some place you read (probably a good idea), you will get a list of packages it wants to upgrade. When running stable, this will also effectively send you alerts about security updates.