New upstream version of kazehakase has been released on day of Niku (29) and Hidetaka Iwai packaged it. It now be built with GNU TLS so that it depends on libgnutls-dev. But when I built his package in my environment, it failed because of gnutls_session_t was not defined. This is because I had installed libgnutls11-dev that provides libgnutls-dev, so it satisfied build-dependency. However, latest (or actual) libgnutls-dev is development package for libgnutls12 and this is what kazehakase should build-depends on. I wonder kazehakase should build-depends on libgnutls-dev (>= 1.2.6) or build-conflicts libgnutls11-dev. Probably, it wouldn't appear FTBFS bug on buildd, because buildd will try to install libgnutls-dev....

Are you a software developer? Are you graduating soon? Maybe you should get involved in free software projects! There are any number of reasons people get involved, from altruistic reasons to selfish reasons. Let's approach it from a "selfish" point of view. I assert that involvement in free software projects looks really good on a resume, and is an excellent way to "network". Networking isn't all about schmoozing at job fairs; it's about building a reputation with professionals in your field. There are very few fields where a huge number of professionals are so very accessible. Software developers are very lucky in this sense. Common wisdom seems to indicate that the job market for software developers is very competitive, and it's going to continue to be competitive for a while yet. Any edge you can get over your classmates is going to help. There is plenty of opportunity to contribute, no matter what your skill level. There is documentation to write and there are translations to perform. There are bugs to fix, and packages to create. Of course there are projects that need more "serious" development as well. You don't have to start your own open-source project, and you don't have to learn to hack on the Linux kernel to add something very attractive to your resume. When people ask me how to get involved in free software, I usually recommend that they start out reporting bugs in the open-source software they use frequently. You might install a version of GNU/Linux, or if you want to stick with Windows or MacOS, you should browse around to find out what free software is available. I think you'll be pleasantly surprised. Let's use "Gaim", a multi-protocol IM client, as an example of how this might proceed. Gaim runs on Windows, GNU/Linux variants, and I'd expect MacOS X, and Unix. It's open source and free: http://gaim.sourceforge.net/. Download Gaim and the Gaim source code. Build it for your machine if you want. Notice what language it's written in. Do you know this language? If not, can you understand it (if you know Java, you can probably understand a lot of C, for instance). Try out Gaim, set up your AOL Instant Messenger and your IRC channels. Visit some open source channels. See any problems? Check the bug reports to see if anyone else has seen that problem. If not, report it as a bug (you might want to google for "how to report a bug" first). Now check out the "bug reports" for Gaim. Pick a bug and try to reproduce it. Why are bug reports the first step in improving your resume?

Reporting a bug is a half-hour task.

Fixing a bug is often (not always) a small, weekend-sized task.

Bugs introduce you to the source code on a level where you don't have to understand everything (hopefully).

You will build familiarity with debugging tools which are invaluable for a developer.

You will start to build a reputation with the authors of the software, and in the free software community.

And because developers are always very happy to get bug fixes that they didn't have to work on themselves. Let's take a look at the bug list for Gaim again. Different ways to contribute to fixing a bug:

If you can reproduce the bug, you might add more information to the bug report: What steps did take to reproduce it? Is there a unique combination of features you need to be using to cause the bug?

If you can't reproduce the bug, maybe it's fixed in the version you're using! Maybe you should add that to the report (better read and understand it very carefully first). Pick another bug, repeat.

Depending on your skill level, you might try to fix this bug, or at least isolate where the bug came from. If you manage to fix it, read about the "diff" and "patch" utilities. Send the author a patch, or attach the patch to the bug report. Here is a bug that looks pretty easy, and it doesn't look like the developer is particularly thrilled to spend time on it: "Buddy Pounce does not get removed when user is deleted". I'm going to take a wild stab at how you might fix this bug: most probably, there's a "list" of "pounces" that has a data-structure which contains both the buddy's name, and the pounce action, whatever that is. Find the code where the buddy is deleted from the buddy list (a different list). Add code to search through the "pounces" list to delete that buddy from the pounces list as well. Compile, test, and run diff to create a patch, attach it to the bug report, take a bow. Now add this to your resume. You are now 50% more interesting to me, as someone who reads resumes, than your classmates who have never taken on a project outside of school. You've shown initiative, skill, and maybe even teamwork. Higher levels of commitment If there's a piece of software that you love, that you think is really important, then you might try adding features to that software and joining the development effort. Lots of projects have a page dedicated to information about how to help out. Here is one for the Mozilla project, for instance. If you want to lead a development project, you might adopt one that has been orphaned. Many people recommend against starting your own project off the bat. I've presented you with a method to increase your skill and reputation, and to add something interesting to your resume. Try it out. You might find out why so many software professionals work on free software projects. It's tons of fun! Feel free to send me comments on this document, or to tell me whether this advice has effected you.

Anthony Towns will be Debian’s next project leader. I am not happy with that outcome at all. With just a tiny margin, aj has won over Steve. Steve was not my favorite candidate as well, but he’d be better than aj, who in my opinion stands for the cabal that is running Debian from their positions of power for years now. Only 421 DDs have cast their vote, which is 43.3128% of all possible votes. Voter participation has thus been lower than the historic low Germany’s state Sachsen-Anhalt recently had in its Landtag election. More than half of the DDs do not seem to be interested in who makes Debian’s external policy and who represents the project to the outside. On the other hand, debian-vote sees a number of people who are not currently allowed to vote, but regularly contribute to Debian. It looks like the people who could vote don’t, while people who do good things to Debian are not allowed to vote. Bad. But, IMNSHO, the really bad thing is the new DPL itself. I think he has won the election with saying that he will increase Debian’s speed. On the other hand, he is member of ftpmaster, the team that might be one of the biggest causes for Debian’s slow speed. He is generally regarded to be close to the “Cabal”, which of course does not exist. I don’t see how the speed increase is can be accomplished giving this background. However, the vote can easily be interpreted as a vote of confidence in the Cabal, which in itself is a good thing. It shows that even the voting DD’s are comfortable to be ruled by the secret club of most senior DDs. I don’t have to like it, but I’ll have to live with it. aj is also one of the founders of #debian-tech, an IRC channel which has been created as a “nice” channel for technical discussions. The channel has a very strict code of conduct, and people are being removed from the channel if they do not comply. I am really really really afraid of this “be nice or else” attitude being extended to other Debian communications media during aj’s term. Being robbed of the right to speak one’s mind might adversely affect many people’s motivation to spend time with Debian in the future. In a nutshell: This is a sad day for Debian. But, otoh, every project gets the leadership it deserves. And it looks like Debian didn’t deserve any of the better candidates. jftr, I voted 63571824 Be warned: I have a bad history of mis-judging new DPLs just after their election. A year ago, I was quite happy about Branden being elected, and was convinced that things would change during his first term of DPLship. I really believed that he could remove the Cabal from the power, and that Debian would change to a more co-operative environment. I surely hope that I am as wrong this time as I was a year ago. It’ll be more positive this time.

The last days, Debian suffered a bug in the reportbug package which made it fail in postinst. This bug was promptly fixed, but reported like THIRTEEN times as a bug in the BTS. If I were reportbug maintainer, I’d have gone ballistic at this ignorance of bug reporters. Guys, all of you who have reported this bug are running Debian unstable, an unreleased development version of your distribution. Is it asking too much to follow basic etiquette to look in the BTS whether a fatal bug might already been reported? I mean, THIRTEEN nearly identical reports?

The host hosting blog.zugschlus.de, ivanova.notwork.de, was down due to a network failure in the hoster’s network for a few minutes today around 2 pm CEST. After returning, I found a lot of my syndicated articles anew on Planet Debian, known as the “flood” phenomenon. Is it possible that the Planet software does react in a non-graceful way when an RSS feed cannot be pulled? Mako, can you investigate this?

I'm glad people have reacted in a largely positive manner to the steering committee idea. It's not really original, but I'm perfectly happy with stealing ideas from other people. I'm going to clarify a few basic ideas here and then address criticism.

The biggest difference between Debian and someone like Canonical or Redhat is that we don't pay employees to do things. We could go that route, but a defining feature of Debian is that it has a bottom-up structure, rather than top-down. I think this makes us unique and we need to do our best to preserve it. I imagine the steering committee to be an extension of this model.

First, the committee would be not be elected by the developers, but would instead be delegated by the DPL. Developers could challenge this delegation in the same manner as any DPL decision. The committee would be very similar to the technical committee in terms of size.

Second, its scope of power would be similar in that it would only relate to the distribution itself, rather than the way the Debian project itself was organized. Its powers would be limited to approving specific improvements within the distribution. These improvements would have to be submitted for approval by the committee, preferably in some sort of specification format similar to the one Ubuntu uses. The committee would then vote on the issue (most likely following the same rules as the technical committee). If they approve it, anyone is free to work on that specific improvement even if it touches on packages they don't maintain. This allows motivated developers to freely work on cross-distro improvements without worry. The committee would ideally be relatively quick to reply to submitted proposals, allowing fairly rapid developments to occur (to facilitate this, proposals must be well thought out).

Further, like the release team, the steering committee would also be responsible for actively working on goals that are set. This would ensure that something actually does get done. These features would give us a group with a limited scope of powers to implement large-scale improvements to the distribution without forcing anyone to do work they don't want to do. In addition, motivated people would have the authority to make large-scale improvements (like consistent theming for example) across many packages they don't maintain. People working on these improvements would be expected to try and cooperate with the normal maintainers as well as possible, so as to prevent problems. Maintainers who have issues can appeal to the technical committee, whose role would remain reactive to solve conflicts as they arise.

Ok, now for the critique from ij, which is a good one. I think the problem with what you suggest is that the DPL simply isn't going to be capable of acting like a good dictator without working full time on Debian for several years. The job is just too big. Allowing them to remain DPL for more than a year is something I don't think many DPL's would opt for anyway, it's just too draining.

The other existing structure is the technical committee, which is a better candidate for taking on this sort of role. The key to the tech-ctte though is that its job is to handle technical disputes. We could expand its role to allow it to set policies and direction, but then who do you appeal to if you don't agree with them? The developer body can override the tech-ctte (with a 2:1 majority) but that adds additional democratic overhead. GR's are draining, and providing another layer for technical decision making allows us to avoid them. Further, I'd like the steering committee and tech committee to have different modes of working. I imagine the steering committee to be more agile, taking a leading role in setting out a vision for the mass of developers to follow and take inspiration from. The tech committee, on the other hand, should be more defensive, carefully deciding on the most difficult issues. Basically the steering committee will looking towards the future, the tech committee will be looking towards the present.

More and more early adopters choose to use Ubuntu instead of Debian. Ubuntu has newer versions of the software that matters (XOrg, FF, OOO, Gnome,…) than the stable Debian or, sometimes than even the unstable Debian. Early adopters are the users that are most eager to try new shiny things, do not scream too much if those things break and seem to make good bug reporters. They are the key second level - just below the developers and above most users in the pyramid of software development and use. They are also the people that have a tendency to become developers. That is why I have this feeling that capturing early adopters is essential to development of a thriving free software community. How can that be done? I do not know, but I have an idea that might just work. What I envision is a merger of development processes of Debian, Ubuntu, Knoppix, Skolelinux and all other Debian derrived distributions. The base for this merger would be an eternal unstable line where all developers would be encouraged to put the newest and greatest software - THE place to be if you want to be on the bleeding edge. I see this unstable line being much newer then Debian unstable, but retaining similar level of quality (how? it is a good question). Then there would be a set of tools available to splice packages from this unstable line into a stabilisation and stable branches for each distribution. The tools would be the same for all distributions and the packages would be the same for all distributions, the difference between distributions would be achieved by the way that the packages and their specific versions are chosen, patches applied for a particular distribution and in some ways by the assembly of the final release media. The proper Debian releases in this context would be no different then Ubuntu releases but will be created using different criteria and at different times. The tools must be powerful enough so that release preparations of any distribution (including Debian proper) would not need to slow down the progress of the flow of new features into the eternal unstable line. The infrastructure needed to operate such complex system would be immense. It would need to have some similarities to the systems Debian uses for distribution, release and bug management, it would need to have some similarities to Ubuntu’s Launchpad (just free, understandable, usable and well documented), and I think that it would also need to have some similarities to Gentoo’s Portage system (distros do want to recompile packages with different options and with their own library versions). It would also help if this unstable line could still hold few parallel versions of one package - like the latest release and the cvs version. (However I am pressed to even imagine all the complexities this would bring into apt and bug reporting/debugging.) I think that such structure will not only concentrate the scarce resource that are the early adopters in a place that will benefit all distributions, but will also provide extra dimensionality for social and technical growth for The Debian Project. The Debian Project will turn from a single great distribution to a swarm of wonderful distributions with a strong central spine - the eternal unstable line. An additional benefit to this will be that it will be possible to fork Debian if social pressures require that (like it happened with gcc vs. eggc) for the benefit of all free software users. Like, for example, the David’s steering commitee whould not disturb the Debian main line until it has been proven to work - it could be formed, it could set goals for a branch and feel in total control of their release goals and methods. After the steering commitee makes a successful release, it would be only a matter of a political decision of whether to call that release Debian proper or not. Note: As always this is just an uniformed rant of a relatively passive DD who is blissfully ignorant of pretty much everything, so please tell me if and why it can or can not be done. P.S. While I am in such writelly mood, I should probably write that free software advocacy article for a new journal that I promised them a month ago. P.P.S. If the system is written with it in mind, then each user’s computer could theoretically be a separate distribution which keeps a splice of Debian unstable line (or any subline) with local modifications and possible local compilation options. If done right, this could also provide a ground for merging up with Gentoo. P.P.P.S. After reading trough logs of several bugs on the Launchpad, I have a feeling that Ubuntu is being flooded by much more bugreports then Cannonical is designed to handle (especially for free). I am not pointing fingers here, I am just suggesting that it is another facet of the same problem and that this idea of mine could reduce this load and let Ubuntu developers concentrate on what they really want to do.

GTetrinet 0.7.10 is out. This release fixes a security hole (CVE-2006-3125), so you're advised to update ASAP. The last release was assembled during UbuntuDownUnder, back in April 2005, which is a good indication about GTetrinet's development health. If you're interested in writing new features or fixing the many bugs in GTetrinet, please consider joining the mailing list. GTetrinet really needs your help! Debian binaries are on the way to unstable; Ubuntu will hopefully suck them up soonish. Get the hot tarball from the GNOME FTP mirrors.

Some good new up front:
I'm down to around 10 audit errors on booting my amd64 system in targeted policy. To achieve this I did some small changes to the udev init script, and some larger policy modifications (mostly treating /dev/.static/dev the same way as /dev) (see webSVN changes view). The bad news:
I'm halting my SELinux development. I'm moving into a new room today, and the box I've recently been using SELinux on is staying with my dad. After all we bought it for him to surf. So I don't have any computer to run SELinux on (my 4+ years old laptop is way to packed already). And that means I can't seriously work on SELinux much anymore. Sorry. It sucks to stop tweaking it right before it's done, but I can't do much about it. [Update: It's not just about the hardware. The hardware is the reason why I can't do much at all, but as you may have seen in one of my previous blog entries, a couple of things in my life are changing right now. I have no idea how much spare time I'll have at my hands. I welcome the offers of sponsorship I've seen, but I can't accept them when I might end up not doing much more anyway. Sorry.]

Well John Howard said he wanted to start a nuclear debate in Australia. Seems it has already started on Planet Linux Australia. I figure I might as well have a meandering blog post about alternative energy and current world events, since I've just been immersing myself in the best news I can obtain with my crappy cable package in a country not renowned for its awareness of world affairs. Firstly, since there's been talk about nuclear power, I'd like to offer my thoughts on Iran, and how it's sounding like Iraq all over again. People are getting in a flap about Iran enriching uranium. Iran says that they don't want "the bomb", they only want nuclear power to meet their energy demands. Now if this is true, then surely should applaud a country that sits on a chunk of the Middle East's oil reserves looking to use something other than oil for its energy needs. I for one don't know if you need to "enrich" uranium to use it for a nuclear reactor, or whether it's good enough "as is". But let's just assume that Iran's intentions are as they have said, then it's going to be Iraq all over again. The US said Iraq had weapons of mass destruction. The US is saying Iran is enriching uranium for the purposes of making a bomb. So far the former claim hasn't been proven, so what's to say the latter is true either? Let's say the nuclear debate in Australia determines that it'd be a good a thing for Australia to go nuclear. How is Australia enriching uranium for electricity generation any different to Iran doing it? (Other than Australia is in the Coalition of the Willing, and Iran is in the Axis of Evil). Speaking of Iran being in the Axis of Evil, how is Iran supplying weapons to Hezbollah fundamentally any different to the US supplying weapons to Israel? Oh, and is anyone allowed to criticise Jewish people without being called anti-Semitic? Since when is invading a neighbouring country considered okay? I am so glad Australia is an island nation. These countries with land borders, sheesh... Anyway, back to alternative energy. I'm a greenie, (with a lowercase "g") so I'm open to nuclear power, but it does frighten the willies out of me, with things like Chernobyl. I'd never heard of a Pebble Bed Modular Reactor until Paul wrote of it. It certainly sounds safer than previous methods of nuclear reaction. But of alternatives. Wind, for example, doesn't need to be big and arguably ugly. These guys in the UK have made a very sexy and quiet wind turbine. I don't know how it stacks up in terms of cost or output to the traditional three-bladed wind turbines like what I've photographed in Southern California, but they're supposed to be quiet, which is apparently one of the (many) arguments that landowners like farmers have against wind generation in general. This Australian company has come up with a very small, but less sexy wind turbine, that I believe to be fairly cheap. Finally, in terms of generation, and I've written about this before, but I find the Tower of Power to be a fascinating concept in natural energy generation. Where am I going with this ramble? No idea. I do think rapidly developing countries like China should completely leapfrog over the era of oil and move to renewably generated electricity. Maybe they can get the manufacturing costs down of the equipment, and it'll be less of a big deal in terms of cost for the rest of the world to adopt it. Whew. What a ramble. Don't start me on flushing toilets with drinking water.

Today I reached another milestone in the development of upstart, the packages in universe can now replace the existing sysvinit package. Before trying this, make sure your installation is up to date as we’ve had to split out some parts of sysvinit into a new sysvutils package. If you’re up to date, and want to try it out, install the upstart and upstart-compat-sysv packages from universe. Note that the first reboot after you’ve installed the packages (from sysvinit to upstart) will be a little tricky… use reboot -f. If your system boots and shuts down normally, everything’s working just fine. Note that both will be somewhat more quiet than you’re used to, unless you have usplash running. Throughout the rest of this entry, I’ll try to answer some of the questions and comments that I’ve received since the last post. Events As I talked about previously, upstart is an event-based init daemon. Events are the primary force for having your services and tasks started and stopped at the appropriate time and in the appropriate order. So what are events and where do they come from? (Note that this part is under development, so may change in later releases). Events are just simple strings that may be sent by any process when something it is tracking the state of changes. They have no state or longevity, and if, when queued, they do not cause any job state changes, then they have no effect unless they are sent again. Jobs can list which events cause them to be started if they are not already running and which events cause them to be stopped if they are running. Multiple start and stop events may be listed, in which case the first to occur changes the job until the next one occurs. upstart itself generates the following system events:

• “startup”, on system boot.
• “shutdown”, when the system is about to be shut down.
• “stalled”, when there are no jobs running and no events in the queue.

The shutdown tool included in the package also causes one of the following events to be sent once the “shutdown” event has been handled:

• “reboot”,
• “halt”,
• “poweroff”,
• “maintenance” (aka. going into “single user” mode),
• any user-defined event with shutdown -e event.

Jobs also generate events whenever they change state, this is the primary source of events for ordering:

• “jobname/start”, when the job is first started.
• “jobname/started”, once the job is running.
• “jobname/stop”, when the job is first stopped.
• “jobname/stopped”, once the job has stopped.
• “jobname”, for services this is generated once it is running; for tasks this is generated once it has finished.

And as mentioned, any other process on the system may send events through the control socket or just by using initctl trigger EVENT. For now this is just the event string, however it’s intended that the event may include other details including environment variables and even file descriptors. Typical example To clarify how it all hangs together, here’s an example (using fictional names) of how the tasks and events can be arranged to provide race-free mounting of filesystems.

• “udev” service started on the “startup” event.
• udev daemon is configured to send a “new-block-device” event whenever a new block device is added to the system.
• “checkfs” task is started on the “new-block-device” event to check the filesystem.
• “mountfs” task is started when the “checkfs” task has finished and mounts the filesystem if listed in /etc/fstab
• “filesystem-mounted” event is generated whenever a filesystem is mounted.
• “fstab” task is started on the “filesystem-mounted” event, it checks the list of mounted filesystems against /etc/fstab and if all are mounted, generates the “writable-filesystem” event.
• other services and tasks would be started on the “writable-filesystem” event.

By breaking this job into these small tasks, we can see how the pieces fit together. Because everything is now done on events, there are no race conditions; we know that any filesystem listed in /etc/fstab will be checked and mounted. The only reason they wouldn’t be is if there’s an error of some kind, and that means you have larger problems anyway and the system administrator would have a shell to fix it. Of course, the moment they finish checking the filesystem and mount it, the boot process would carry on. There’s no reason that any of these events need to be generated by the upstart daemon itself, it can receive them from any other daemon on the system such as udev, acpid, etc. This keeps the focus of the init daemon narrow. A large part of the future development will be working out exactly what kinds of events we want init itself to generate, what kinds we want to come from elsewhere, and what the contents of an event can be. Getting Involved If you want to get involved with trying to nudge the direction of upstart development, you can join the upstart-devel mailing list at http://lists.netsplit.com/ Or if you just want to grab the source code, tarballs are published at http://people.ubuntu.com/~scott/software/upstart/ and the bzr archive is at http://bazaar.launchpad.net/~keybuk/upstart/main

I went wedding list creating in John Lewis yesterday. It was fun for about 5 minutes and then the novelty of a Palm with a barcode reader wore off. They'd told me to be careful where I pointed it, so I didn't get to see just how good the range was. :( During the lengthy process a Hauppauge MediaMVP caught my eye (it's a hardware MPEG2 decoder with SCART socket, ethernet and remote control - the idea being you stream content to it from your PC and watch it on the TV), reduced from £79.99 to £39.99. I'd considered buying one of these in the past, so I took a closer look. And discovered one marked down to £25.00 at the back. Took it to the checkout to confirm the price, got told it was right, and bought it. I'm not exactly sure what I'm going to do with it just yet. :) I've already got a hardware MPEG2 decoder on the DVB card hooked up to the TV, though the MVP is a fanless device and might make a better choice than the living room PC. mvpmc is a potential option, and there's a plugin for VDR as well. Or there's just the prod it and see what I can make it do approach. It's an IBM PowerPC 405 with 32MB RAM (though only 16M for the OS it seems) and an SMC 91C111 ethernet chip. The interesting bit of the MPEG2 decoder has no source which is a pain though. :( Still. Fun toy! \o/

At work I recently decided to set up virtual servers on one of in house development servers, a Dell Poweredge 1750. I've used UML before personally and also on one of our remote servers but this time I wanted try Xen as it seems to be the da bomb these days. Well I tried both Debian kernels and a self-built one but both crahsed on boot at XEN) Scrubbing Free RAM: ...........done.
(XEN) Xen trace buffers: disabled. After skimming the internet briefly I decided to try openvz which I also wanted to try out and it works well for our purposes. I'm not saying Xen sucks, just that the system didn't boot and I couldn't see why right away.

I've been working on a mail forwarding system which required me to implement <a href="http://www.openspf.org/srs.html">SRS</a> to allow people who use <a href="http://www.openspf.org/">SPF</a> to be customers of the service (as I use SPF on my domain it's fairly important to me). Reading the web pages before actually trying to implement it things seemed quite easy. All over the web you will see instructions to just set up an /etc/aliases file that pipes mail through the <span style="font-weight: bold;">srs</span> utility.<br /><br />The problem is that none of the srs utility programs actually support piped mail. It seems that the early design idea was to support piped mail but no-one actually implemented it that way. So you can call the srs utility to discover what the munged (cryptographically secure hash signed) originator of the email should be but you have to do the actual email via something else.<br /><br />This wasn't so much of a problem for me as I use my own custom maildrop agent to forward the mail instead of using /etc/aliases (Postfix doesn't support what I want to do with /etc/aliases - dynamically changing the email routing as you receive it isn't something that Postfix handles internally).<br /><br />However I still have one problem. Sometimes I get two or three copies of the SPF header from Postfix when it checks them.<br /><br />In my <span style="font-weight: bold;">main.cf</span> file I have a <span style="font-weight: bold;">smtpd_recipient_restrictions</span> configuration directive that contains <span style="font-weight: bold;">check_policy_service unix:private/spfpolicy</span> and the Postfix <span style="font-weight: bold;">master.cf</span> file has the following:<br /><br /><pre><br />spfpolicy unix - n n - - spawn user=USER argv=/PATH/spf-policy.pl<br /></pre><br /><br />Does anyone have any ideas why I would get multiple SPF checks and therefore multiple email header lines such as:<br /><pre><br />Received-SPF: none (smtp.sws.net.au: domain of SRS0=MUyCQ6=CO=coker.com.au=russell@inumbers.com does not designate permitted sender hosts)<br />Received-SPF: none (smtp.sws.net.au: domain of SRS0=MUyCQ6=CO=coker.com.au=russell@inumbers.com does not designate permitted sender hosts)<br />[some other headers]<br />Received-SPF: pass (inumbers: domain of russell@coker.com.au designates 61.95.69.6 as permitted sender)<br />Received-SPF: pass (inumbers: domain of russell@coker.com.au designates 61.95.69.6 as permitted sender)<br />Received-SPF: pass (inumbers: domain of russell@coker.com.au designates 61.95.69.6 as permitted sender)<br /></pre><br /><br />The email went through one mail router and then hit the destination machine, but somehow got 5 SPF checks along the way. Also the pair of identical checks had no lined between them and the set of three identical checks also had no lines between them. So multiple checks were performed without any forwarding. It seems that a single port 25 connection is giving two or three checks. Both machines run Postfix with SPF checking that is essentially idential (apart from being slightly different versions, Debian/unstable and RHEL4).<br /><br />Any advice on how to fix this would be appreciated.

Queen Elizabeth II and the Debian project threaten religious warfare! D-Inq has today uncovered a conflict between the Debian Project and the queen of England and other places. The row is over the King James Version of the Bible. "It's all mine! Mine! Mine!" the monarch told D-Inq in an exclusive interview. "Keep yer dirty fingers off it or I'll sick the SAS on you." In the UK, the monarch owns the copyright for the KJV Bible, but the Debian project wishes to distribute it freely. The SAS, UK's elite fighting force and the Queen's personal mob, is already gearing up. Instead of their usual arsenal of guns and bombs, they're opting to use a new kind of weapon, the DD Attitude Readjustment Tool, or DART. The Debian Project is undaunted. "We've seen worse, this is a pedestrian transport in a big grassy place in comparison" says a Debian flame war veteran, Steve, 22, from Portland, Oregon. "The SAS is nothing compared to a vigorous discussion about firmware freeness. It's not even as bad as someone spoiling the next episode of B5." Things might get more difficult, though. There are rumors that MI5 has already infiltrated Debian's discussion forums. Worried analysts imply that some of the recent, divisive developments within the project are the result of agent provocateurs. "The new Python policy is one", says Lars W, an analyst who wishes to remain nameless. "No sensible person would have done things like that", he continues. While both sides ramp up their fighting forces, local constabulary in many English towns has already started to confiscate and deport machines running Debian to Libya. Time will tell when they will return.

To infinity, and beyond! -- Buzz

[Debian]

I should write about this a few days ago but didn't have the time. Sorry. Well, these are great news (at least for me), a few days ago I sent the second part of my T&S and already got approved. My AM (Hi Cl ment) also pointed out a few changes that were needed in my packages that are already fixed and uploaded; Cl ment already sent the report and considering that, I'm now waiting for the Front Desk to review my application (and after that, DAMnation. I'm happy! I also finish the adoption of xless and levee. I still have to finish the MyPasswordSafe adoption, but before I have to fix a RC bug related to the use of sudo as the gain-root command (instead of fakeroot) in the alpha buildd. Thanks neuro that already give me a few tips on how to solve it.

Following the random ideas season:

• Next week, Extremadura will host the i18n Debian people, the idea is to discuss lots of ideas, specially i18n Infrastructure, but not only discuss, also code a lot!
• I do not like the idea to have sourceless firmware in main and I really like Don Armstrong proposal on that subject.
• I still have to finish the desproxy, tuxfrw and thumbs packaging work to get it in time for etch.
• I'm wondering how a tally sheet with more than 10 choices looks like

[Anti-SPAM season]

Like a lot of people already did, in the last two weeks I've been fighting SPAM in my company and also on the server of Free Software Projects that I'm part of the System Administration Team. In most cases I'm using postfix with clamscan and postgrey, but I will switch to amavisd-new to use SpamAssassin (with razor/pyzor). But I'm still studying the various alternatives in a Debian Sarge system.

Hey silva, thank you! (Journeyer certification).

So appart from being happy just by being awake, these three last days have also brought a lot of surprises. I’ll mention a couple. First, my mind is with a mental activity level quite high, not unknown to me, but never experienced with this intensity and duration combined. I now need tools to accommodate to this. My gut feeling is that ikiwiki and maybe vim-outliner are going to suite me perfect. If that’s finnally the case, Joey Hess gets my gratitude for both (author, referrer). Secondly, I’m running an experiment with my sleep patterns that I was planning on not talking here about until at least a week from starting. But the details have changed a bit, and IRC just gave me the chance to reduce my two planned paragraphs description with a two-line one, so I’ll take it:

  [dato] it's 22pm, I'm about to have dinner, and the fact that the sun is rising
         doesn't bother me at all

/etc/init.d/cryptmount: 16: source: not found
/etc/init.d/cryptmount: 19: Syntax error: "(" unexpected

Another bashism. Policy violation in section 10.4. Severity "serious", but trival to fix. I thought we had managed to get rid of all unnecessary bashisms. Any Debian Developer should use e.g. dash as /bin/sh to avoid these bugs. It's faster, and bugs triggered by that are rare. Speaking of cryptmount: Dear Lazyweb, how do I get pmount/gnome ask for the luks passphrase using a graphical prompt? Right now, if Gnome tries to automount the encrypted drive, the password will be asked on some /dev/null device and pmount will hang.

I resigned from Debian today.

It wasn't actually any one thing. But over the past few weeks (months? Years?) it's become clear to me that Debian doesn't really seem to know who or what it's for. Arguments erupt over whether something is a deeply held principle or an accident of phrasing on the website; whether we should release more often or less often; whether free software is more important than our users having functional hardware. And, depressingly, these debates generally seem to turn into pedantic point scoring and insults and yes, I'm probably as guilty as many others in this respect. But it's got to the point where social interaction with Debian-the-distribution makes me want to stab people, even though I've just spent a lovely weekend with Debian-the-people. Perhaps worse, I occasionally find mails I've sent that make me want to stab me.

So it's got to the point where I find myself reading things written by people I respect, and deciding that I'd be generally happier if I didn't read them. I could just unsubscribe from all the mailing lists, except that part of the fun of being involved in Debian was being part of a community. I don't want my only form of communication with the rest of the project to be limited to bug reports, especially when I find the development IRC channels as bad as the mailing lists.

It's interesting to compare Debian to Ubuntu in this respect, though the different ages of the projects make it difficult to draw any firm conclusions. The fairly rigidly enforced Ubuntu code of conduct probably helps a great deal in ensuring that discussions mostly remain technical. The distinction between core-dev and MOTU is a pretty explicit acknowledgment that not all developers are equal and some are possibly more worth listening to than others. And, at the end of the day, having one person who can make arbitrary decisions and whose word is effectively law probably helps in many cases.

There's a balance to be struck between organisational freedom and organisational effectiveness. I'm not convinced that Debian has that balance right as far as forming a working community goes. In that respect, Ubuntu's an experiment - does a more rigid structure and a greater willingness to enforce certain social standards result in a more workable community? In a few years, we ought to have an answer. I look forward to finding out.