I’ve put together a partial timeline of the Debian project using the SIMILE Project’s DHTML timeline component. This is definately work in progress: I would welcome additional events (by email or merge request please, not via blog comments) regarding:

• Dates of the earlier Debian releases
• Release freezes
• Interesting dates of important packages and tools (Linux kernel, XFree86/X.Org, glibc, aptitude, etc.)

The timeline is available to view here. Update: Assistance fixing the (non-Webkit) Konqueror issue would also be appreciated.

I’m trying to reach Alan Curry, pacman@TheWorld.com, about some GDB work he did last year. That address now bounces. He’s a regular Debian bug submitter, though none of his bugs have a newer address for him listed. So the best idea I could come up with was to ask the lazyweb - Alan, are you out there? Or does anyone else reading Planet Debian know how to reach him? Leave a comment or send me email if you do. Thanks. Updated: Yes, I did try Google. Thanks to all those who pointed out world.std.com (alias for TheWorld.com), and clss.net (most recently used in 2005; no active nameservers); sorry I forgot to mention that.

At the moment I keep my packages in Bazaar branches. I only version the debian/ subdir (whereas I have the .bzr directory at the same level as debian, i.e. not debian/.bzr). I do that because then $VCS operations work without having to be under debian. One drawback is that the output of status is a bit too noisy, with lots of “unknown” files (all the upstream files). I address that by aliasing bzr std to “bzr status debian”. With git, one could just have the following:

  % cat .gitignore
  /*
  !/debian
  /debian/files
  ...

Update: One of the Bazaar guys, Wouter van Heyst, points out on IRC that bzr can do it as well:

  % cat .bzrignore
  RE:(?!debian/).*
  ./debian/files
  ...

In fact, possibly more: lines starting with RE: are interpreted as Python regular expressions.

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 been provided the latest Verizon and Sprint EVDO cards to evaluate in the field for the past month. I now have to decide which to keep. It’s a close call (no pun intended). I’ve tested them both over various areas in Greater Boston and Washington DC. Key observations: (1) Speed: The Verizon card is usually faster. I’ve clocked up to 2.5 Mbps using the Speakeasy speed test on Verizon. That’s getting to be respectable enough to use a VPN without annoyance. My top rate on the Sprint card is about 2.0 Mbps, but usually it’s more like 1Mbps down / 0.5 Mbps up. (2) Coverage: There are more Verizon “dead” spots with no service at all. In those spots, the Sprint card invariably works fine. I’ve noticed this in some government buildings as well as on the T in Boston. (3) Device: The Verizon card I’m testing is a USB device (UM150) with an extendable antenna and the ability to power on/off right from the device. The Sprint card is one of those newfangled half-width PCMCIA cards, which requires an adapter for my laptop. There are pros and cons to each: the Verizon card is more compact when closed up and fits easily in my coat’s lapel pocket, but it seems quite precarious when actually plugged into the laptop. It could fall out easily or break if someone hit it with their bag walking by. The Sprint card, by contrast, is quite sturdy. I certainly can’t throw my laptop in my case with the Verizon card still plugged in, while the Sprint PCMCIA card can stay in without trouble. A colleague warns me, though, by keeping the PC card in I’ve created an opening for my dust and whatnot to enter the laptop. (4) Software: Finally, the (Windows) software for the Sprint card is much better than for the Verizon card. The updated Verizon software is as flaky as the last iteration. It definitely doesn’t like it if you try to disconnect after you go out of EVDO range. It also doesn’t usually survive a sleep cycle, and sometimes requires manual intervention in the task manager or a reboot to clean things up. It also has some silly features like a control panel to launch your web browser and email client. I’m not sure anyone wants to use their dial-up client that way The Sprint software has its own share of silliness by having nonstandard decoration (it looks like someone thought “skinning” it would be cool, so they took away any resemblance of regular window frame). But it’s stable and solid, survives suspend/resume, and I’ve yet to have to kill it even once. So there you have it. If anyone wants to speak in favor of one or the other, please do so in the comments. As a side note, I’m promoting broader use of the term “aircard” to make it easier to speak with nontechnical people about the difference between EVDO/WWAN and “WiFi.” Technorati Tags: Sprint, Verizon, EVDO, WWAN, Aircard

Share This

Continuing from where we left off… The lower bound for me becoming a DD was 8th Feb ‘98 when I applied; for comparison, the upper bound as best I can make out was 23rd Feb, when I would have received this mail through the debian-private list:

Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze 
To: Debian Private 
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week.  Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers.  These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
    Anthony is going to package the personal proxy from
    distributed.net - we don't have the source... He may adopt the
    transproxy package, too.
Regards,
        Joey

I never did adopt transproxy – apparently Adam Heath started fixing bugs in it a few days later anyway, and it was later taken over by Bernd Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I did do other things instead, which brings us back to where we left off…

---

• Crypto in main: It’s getting hard to remember the days when strong crypto software was classed as munitions and even getting a web browser to do SSL properly was a legal challenge; but for a long while that’s how it was, and as a result we had to keep all our security tools hosted separately to our main, US-based archive. The laws for that changed in early 2000, introducing a new exemption to the prohibition for software whose source code was available royalty-free (I think they called it “public source”). Unfortunately there were still drawbacks: it wouldn’t apply to some stuff in non-free, it wasn’t clear how far you had to go with the source code (is libssl’s source enough, or do you need the source for the apps that use ssl too?), and the biggest problem was you had to notify the export bureau and the NSA for everything you wanted to distribute. And all of that’s couched in the sort of confusing language you’d expect to find in, well, export regulations. So we ended up getting nowhere on merging crypto into the main archive for a long while because we couldn’t be confident of what we actually needed to do. We’d more or less already missed the opportunity to do the merge for the potato (2.2) release because it was frozen more or less exactly when the new regulations came out, and according to my mail archives Ben Collins (DPL at the time) got a team organised to review the legal issues by mid-May 2001. By July 2001, though, we still weren’t really getting anywhere; the lawyer we were talking to was looking at the ENC exception (which was for closed source stuff, and requires an active review by the BXA), instead of the TSU exception (which just requires notification). While it wasn’t terrible legal advice – following the ENC exception had a lower risk of misunderstandings on our part leading to problems later – it wasn’t useful in achieving our aims, ie, getting crypto stuff into main with a minimal level of ongoing effort, as well as a minimal level of risk. So moving onto August, we’d moved on from the lawyer we’d been using for this and other issues, to talking to a lawyer who specialised in export issues (and whose time was being covered by HP). That actually got us somewhere, with the end results being a matter of public record – we got the advice we wanted by November, we got a new incoming system so we could make sure we didn’t publish anything we hadn’t advised the NSA and BXA about, and most of all, we got cryptographic software in main for woody’s release. ssh at standard priority, apt by default checking archive signatures before downloading code to run as root, iceweasel coping with https:// urls out of the box all suddenly became possible, rather than artificially blocked due to pointless legal constraints. Yay! The way we notified BXA/NSA was somewhat interesting – we ended up notifying once for each package, when it passed through NEW: which is easy to automate, and limits the amount of software we block from review by other developers as best we can. OTOH, it also means a lot of notifications: the initial notification was a huge box of paper that got faxed off (there should be pictures somewhere on the net, but I don’t know where), and the vague hope that the ongoing reporting would not only comply with the regs, but manage to be something of a denial-of-service by compliance. As it turns out it apparently got noticed, with the following mail arriving in September 2005:

  From: Encryption 
  Date: Fri, 23 Sep 2005 12:51:02 -0400
  Subject: Addition to Debian Source Code updates
  Dear Mr. Collins,
  Your diligent reporting of updates to the Debian source code to the Bureau
  of Industry and Security has been an excellent example of perspicacity.
  However, you no longer need to do so per the following update to the EAR:
  [...]
  

  (The mails have always been sent with Ben's name attached) That mail was followed by another suggesting a phone conversation; unfortunately nobody seemed to notice the mail, at least until a year later (to the day!) when Joerg pointed out he was getting bounces form the BXA email address we'd been using... (Since then, based on the above mail, we've been recording notifications, but not passing them on; I sent a reply to the mails above indicating that, but didn't receive a response. There's been about 5000 notifications since then)
• Security and the architecture explosion: with crypto-in-main out of the way, along with lots of RC bug squashing, woody was looking good to come out in April or May, but unfortunately that all fell apart because of a lack of automation for handling security updates. Taking a step back, woody managed to introduce five new architectures compared to the previous release -- HP's pets, hppa and ia64; the IBM mainfram arch, s390, and the SGI/embedded mips and mipsel chips. That came just short of doubling our supported architectures (which had been i386, m68k, alpha, arm, sparc and powerpc), and was working really impressively well: testing was watching that they kept in sync, and the buildd network was keeping them all up to date with the latest source uploads, and the toolchain maintainers were making sure new kernels and compilers didn't cause massive breakages. It was great fun to be a part of, and I'm not sure how much is just blurry memories, but from here, it sure feels like it was a golden age on that score... Anyway, all the extra architectures freaked the security team out, given they were already having to worry about ssh'ing to half a dozen machines and manually do builds, and fix them when they broke, and to deal with that there'd been plans afoot for "rbuilder" to get rolled out, which never actually happened. All of which means it escalated from being the security team's problem, to a problem for everyone, particularly the release manager... The result of which meant knuckling down and coming up with a new security build infrastructure, which involved doing a dak install for the security archive, then building on the changes just rolled out for crypto-in-main to allow for packages to be autobuilt before actually being included in the archive, then updating official buildds for all the various architectures to target stable-security and testing-security and prioritise them and upload to the right place. But as stressful and last minute as that was, at least it worked, and woody made it out the door on July 20th 2002 -- and it's a good thing it worked, given woody ended up getting security support until June 30th 2006 -- the usual year after it's successor is released -- for four years support. (The same rule applied to sarge has resulted in two years and ten months' security support; eighteen month release cycles in general should result in two years and six months of support) Since then, with security managed by dak, there's been a few more bits I've been involved in. The most interesting of which (to my mind) was splitting the security upload queue from being completely secret and restricted to folks who are allowed to access updates prior to public announcement, into separate secret and non-secret queues. That was December 2005, and since then we've gone from having Joey Schulze basically being the sole person doing security updates to two separate teams, with ten new members. It's not without it's problems -- particularly for packages that get (mis)classified as NEW, or that get lost on their way for inclusion in the next stable point update, but it's nevertheless lightyears from where we were in April 2002, or even November 2005.
• Playing other people for suckers: with woody released, the whole "redo to release process" thing was essentially done -- it had been implemented, it had worked all the way to getting a release out, and in a fair few respects had improved things. Instead of the eight months of hand-approved uploads for the potato freeze, things had gone it automatically, albeit with gradually stricter constraints, right up until April; and even when the security problems delayed things, the manual updates only lasted a bit under three months. So at that point I was pretty happy, and looking forward to making things work a bit better and basically passing the buck to someone else. The first bit of buck passing that worked exceptionally well was jumping on Colin Watson, who'd been offering some debbugs patches on IRC, and after a delightfully brief discussion with some of the other debbugs folks, got getting him added to the group and able to make changes directly on the site. His advogato post the next day was:

  Yesterday I was invited onto the group that administers the Debian bug tracking system. I can't decide whether to be intimidated or excited. There's a great deal to do: my first couple of major projects look set to be integrating some of the existing QA interfaces to release-critical bug tracking, and developing a tool to help us edit spam out of bug histories.

  There's a lot to be said for grabbing people at the point where they're still intimidated by what they're joining; sure there's a definite risk that they'll break something you'll have to clean up, but that's pretty easy to deal with, and well worth all the extra excitement and energy that comes with a little bit of nerves. I did a talk on debbugs a few years later, at the 2005 DebConf, at which point we managed to entice Pascal Hakim and Don Armstrong into signing up, if I'm remembering right. At the same time Colin rolled out his implementation of version tracking support for debbugs (which I'd specced up a while ago, and helped design, but cannily avoided actually coding). Shortly after, Pasc put together bug subscriptions, and these days Don's pretty much the primary maintainer of debbugs. How cool is that? Passing on release managership was a bit less fortuitous though; it's a big job, and it's not something that you can offer "patches" for, generally. So after a bit of cogitating on just how to do it, I went with an open recruitment call in March 2003, and then a bunch of practical assignments to get the volunteers used to what RM work actually entailed and to see whether they actually like it. The recruitment call was mostly focussed on all the negatives, half to avoid people volunteering to be RM for the power (to decide which release policy wins, to tell maintainers what to do, to drop packages, or to just decide what name/number the next release gets) instead of wanting to actually do the work to get the next release out and keep developers happy; and the other half was the theory that if you make a job look hard, technical, but not terribly risky, it starts looking interesting to the right kind of people. The assignments generally were two parters -- first to introduce some stuff about release management that they mightn't be familiar with, and the second a bunch of problems that needed resolving that'd use those skills. The first set was RC bug fixing, followed by working out why packages aren't getting into testing, followed by dealing with packages with mutual dependencies and removing packages. At some point that evolved into the testing scripts accepting "hints" from the release team as to what packages to try in combination, or which packages to force out of testing. That turned out pretty successful, with Steve Langasek, Colin Watson and Joey Hess becoming official release assistants in August, and Colin and Steve replacing me as RM in mid-2004. It was also pretty satisfying to see Andi Barth do some more release assistant recruiting in 2005 following much the same model, and indeed using much of my mail verbatim. You can't really ask for better than that, I figure.

Geez, this was meant to be briefer...

Madduck complains about the lack of attractive data plans for mobile phone providers in Switzerland. Madduck: As always, you will have to remember there are many people confronted with a much worse situation than yours.
Up to a month ago, I never envisioned using my phone for anything besides... Well, talking. But yes, since I got my new gadget, I keep playing with GPS or using it for simple things that require Web access and do not require much interactivity (the suckiness of a 12-key keyboard is berhuge!) - Provided, of course, that I am near a WiFi hotspot, of course. My mobile service provider, Telcel, just publicly launched its 3G network - this means, of course, prices are well over the roof:
The cheapest plan starts at MX$59 (around US$5.5) a month, and gives you a whooping 1MB of allowed transfer - Anything you do over 1MB will cost you MX$0.06 per kilobyte. Yes, Telcel offers a 1.5Mbps connection, so it'd theoretically take only 6 seconds to exceed the monthly plan. After the joyful first seconds of network access, each second of full-fledged data transfer will cost you 9 pesos - Around US$0.85. How nice!
Now, there are plans for 1, 3, 5, 10, 15, 20, 30, 50, 100 and 1000MB. Their price increases at a slow pace up to MX$459, which is still somewhat expensive if you even thought on using your cell phone as a gateway (say, over Bluetooth) for your regular computer's connectivity. Of course, if I buy 1GB of data transfer, I'd expect a much lower price for each additional Kb. Well, no, it only goes down to MX$0.03. Per Kilobyte, yes, you read right. Those little things your Vic20 was full of.
There is even an unlimited plan. Well, yes, unlimited but limited - For MX$579 (~US$55) you get a nice deal, right? After all, I pay MX$350 for my 1024/128 DSL connection - it is on the right range. Well, no - If you get over 3GB in one month, your data rate will drop to 128Kbps for the rest of the month. Nice. No good as a gateway either.
So, I'm not hiring a 3G plan at all. But that's also a danger - If I open a net-using program at the wrong moment, I'll be billed at MX$0.14 per Kilobyte.
Bah.
[update] There is another similar service in Mexico, IUSAcell's BAM. Pricing is equivalent, though.

Good news everyone, new stable Gammu release is out. Since 1.18.92 it brings only few small fixes in build system, but there is quite big list of changes compared to 1.18.0:

• Add option to disable compiled in protection.
• Fixed detection of PostgreSQL.
• Improve debug messages when connecting to phone (bug #508).
• Fixed handling of some charsets in AT engine (bug #525).
• Identify more Nokia phones (thanks to Iv n Gabriel).
• Fixed regression with DKU2 cables on Windows (bug #533).
• Better compatibility with iCalendar files (bug #538).
• Do not link with irprops.lib on Windows.
• Various MSVC compilation fixes.
• Improved AT model parsing and added tests.
• Fixed possible crash in reading SMS from AT phones (bug #515).
• Proper fall back to automatic model when user enters wrong one.
• Added identification of several phones.
• Fixed reading of messages from AT phones without ME memory.
• Improve charset detection on Motorola phones (bug #522).

You can download from usual place: http://cihar.com/gammu/.

1. Bzr Exactly 2 years ago I started using bzr. I wanted to start using one of the new distributed VCS for my small projects, and I chose bzr. Not having the time/energy to do an exhaustive comparison among them and try them all to see which one I liked most, I read some articles about them, and decided that bzr would be the most appropriate for me, and that I’d stick to it if I was satisfied enough. (JFTR, at that time it was very important for me the ability to serve branches over plain HTTP, and bzr was the only one in which HTTP was a first-class citizen.) I’ve found bzr easy to use and to learn, powerful enough, customizable enough via plugins, and in general, not requiring a whole lot of attention to get things done. Also, not slow enough as to abandon it. 2. Git Yesterday somebody posted in #bzr a link to this post by Elijah Newren, where one comment said:

There’s one thing I keep telling people though: Learning git is like learning vi — it’s different from the VCS/text editors you know on a fundamental level. But once you’ve overcome that problem, you’ll not want to go back. Ever.

Which pretty much matched the idea I had of git. In the summer after my first year at Uni, I told myself: “OK, let’s learn vim.” And I think it’s one of the decisions that has paid off the most. Like learning to touch type. Reading the above quoted paragraph made more urgent the doubts I had been sporadically having during the past year: maybe I would have been better served by choosing Git instead of Bzr in the first place. What would be my life like if I had stayed with joe? 3. More about Git So yesterday I decided to spend a couple hours (or three) getting the feel of it, trying to find cool stuff. Until now, whenever I had had the need to use git, I just sticked to the bare minimum, without diving into it. I’m going to mention only two examples of the cool stuff I found. And I’ll confirm that, in my opinion, the comparison to vi really holds.

1. commands have lots of options. Tons. And some are incredibly cool, for example git log -S. It allows you to show entries whose diff contains the given string (or pattern, with --pickaxe-regex). I was missing bzr’s log --message, but it was obviously there, as log --grep.
2. Elijah has another entry that talks about what he dubs the “libmo”, and how it’s different between git and the rest, because of the “index is not automatic” schema. In particular, that entry opened my eyes about one very useful use of the index: putting there parts of an upcoming commit that are known to be correct, and that need no further inspection. Doing that with git add -p makes those parts no longer appear in your git diff, which is... whoa. I like to review before committing a lot. However, with other VCSen I always find myself reviewing/glancing at the same parts over and over. So having a way to review what’s pending or WIP is something to die for. And I know even before getting addicted to it!

4. More about Bzr I’m not sure I want to completely switch from bzr to git, not yet anyway. However, I think I’ll try it for some new projects, or migrate some minor ones. Before I can migrate everything I’ll need a bzr frontend for git-fast-import. One of the bzr authors, Ian Clatworthy, has written bzr-fastimport, and he tells me a simple exporter would not be very hard to write, and that he may even put some work into it. Also, I’m (still?) not very sold with some of the git standard practice of throwing away parts of your history regularly. We’ll see about that. Finally, one feature of bzr I would love to see in git is indented formatting for non-mainline revisions in log output (for git, in --topo-order mode only). This is most needed when you’re not rewriting your history for submission to mainline, I’ll reckon. Compare —date-order to —topo-sort to —topo-sort with —indent. Update: For this —indent thing, one could use tig, which after pressing g offers a sort of tree view in a curses-based interfaces. Somebody had mentioned this on IRC, and Peter Baumann kindly mentioned again over e-mail after reading this entry.

Since Switzerland s three main cell phone providers (Swisscom, Sunrise, and Orange) are apparently happy to remain stagnant, here are two business opportunities, in case you re fidgety and looking to get rich. The second actually applies to all of Europe, or even the world.

1. provide a true EDGE flat rate. The three providers all have unlimited data options, but cap their offers at 1.5-2.5 Gb/month, after which you end up paying horrendous amounts for each additional Megabyte. The marketing people are, of course, aware of this unlimited lie, while the casual customer does not have to be since s/he won t generate this amount of traffic.
2. peer with local providers and come up with a plan that allows me to roam about and use my phone from anywhere in Europe (or the world) for the exact same fees as always. I realise this will be quite difficult because it involves a large number of peering agreements, but think of the potential: I d switch immediately, I d even forego any remaining term I still have on my contract, and I am sure I am not the only one.

Once you hit the black numbers, please hand over a small percentage of your stakes for my ingenious ideas. NP: Gazpacho: Night Update: Gunnar replied with a peek into the situation in Mexiko. Yes, I am spoiled.

It’s here! In contrary to the estimated delivery time of about ten weeks, my Brompton arrived at Velofix at Saturday the 16th of February after only three weeks. The orange color is much nicer than the apple green I initially favourited from what I saw in the catalouge and the axle dynamo also proved to be a good idea, so I’m really happy about my choice. I used the Brompton to go to work everyday the last two weeks, even when it’s snowing like today: Although I’m starting slowly and taking the bus (hey, it’s a folding bike! :-) for the steepest parts (either from Am B rtli to Waidbadstrasse or Gsteigstrasse)… I even managed to fold the bike although I saw the bus already coming around the corner when I still was in the saddle. That was the day I was at work in less then 10 minutes — Perfect timing. :-) Since the local H ngg bus (route 38) only makes it’s round every 30 minutes, with the bike I’m now much more flexible and don’t have to hurry in the morning to catch the bus. (OTOH I had to notice that “being more flexible” doesn’t mean “having more time”… :-) I also use it on the campus for visits in other buildings. Although there are mostly stairs between the different levels of the campus, it’s no problem with the Brompton since it’s easy to carry, even if not folded. It’s much more comfortable than daduke’s little kickboard scooter whose hard wheels don’t feel healthy for bones and especially knees on ETH H nggerberg’s paths made out of washed-out concrete. Air tyres and rear suspension are much better… :-) Regarding the choice of gears: The MountainDrive would surely be helpful in hilly Z rich, especially since my fitness isn’t the best one at the moment, but 6 ears are ok, too, and will be even more ok as soon as my fitness gets better. The slower transmission wasn’t a bad choice either, although a wider transmission range would have been better.

I like autotools, I use them widely and I'm happy that I understand autotools sufficiently that I can be confident in using them and helping others with theirs. All my own upstream C projects rely on autotools and I have a personal rule that I always preserve make distcheck compatibility during CVS/SVN changes and without fail prior to ALL releases.
Lenny will be the second Debian release with which I've been involved and as I prepare to round on the RC bugs once again, I'm noticing a pattern in autotools bugs from other upstream teams.

1. If more upstream projects enforced rigorous testing with make distcheck, a lot of bone-headed numbskull errors would be prevented in the upstream codebase. Fixing make distcheck isn't that hard because it is a test of the build system files, not necessarily the source code. Once an upstream build is fixed, subsequent make distcheck failures are both rare and serious. Other failures in the test suite should be easier to spot too. The important point is that make check only tests the current build on the upstream system. make distcheck goes a long way to ensuring that the package will build in the same way on lots of systems, including cross builds.


2. autotools expects such fixes to be made upstream and fixing things after the release can be a serious PITA, so fix it before release.


3. The single greatest weakness of make distcheck and autotools in general is bit rot. It is so important for upstream to refresh the autogenerated files on an intermittent basis. With a big development team, this can be easy - especially if new people are regularly joining and building the source for the first time from CVS/SVN. Once that rotation stops, the difficulties of trying to fix the upstream code get more and more noticeable. Maybe one day autotools will fix this and become more resistant to bit rot but, for now, it is a significant problem.


4. As a consequence of file rotation, it is seldom a good idea to keep any autotools generated files in any form of RCS, even distributed ones. This is where I fall foul of many who want to package directly from SVN CVS foo. The mantra of lots of RCS helpers is "everything must be in the RCS" which is just plain wrong IMNSHO. The only things that must be in any RCS are the bits that upstream needs to write. So Makefile.am is, Makefile.in is not. configure.ac is, configure is not. Same for libtool, ltmain.sh, config.* and a host of other autotools generated files. If autogen.sh can generate or symlink them, don't have them in RCS. If, as upstream, you have not had to edit the file or copy it into place using a patch supplied by someone else, it should not be in the RCS. This discipline ensures that when someone starts from a fresh checkout, the build system is refreshed (and is why many autotools upstreams add a "make rcsclean" rule that goes one stage beyond make distclean by going back to raw RCS). If you maintain a helper that is meant to build packages like this, ensure that the helper has support for getting from raw RCS to make distcheck and ensure that the helper uses the tarball created by make dist not one of it's own.

Yes, bit rot is the curse of all software but when combined with the lack of usage of make distcheck prior to upstream falling quiet, I sometimes wonder about the merits of trying to fix bugs in the build system of packages with a most recent upstream release that precedes Etch. I get a real chill thinking about upstream packages with a most recent release that precedes Sarge.
So, if you're working on an upstream project using autotools, just do everyone a favour:

 svn cvs  ci -m "make sure things work"

make uninstall

make distclean

./autogen.sh

./configure --prefix=... 

make

make check

make install

make distcheck

Repeat the last stage until it completes without errors, commit the changes and retest from the beginning.
I'm not proposing something I do not do myself - as above, I do these tests on my own (released) upstreams on a regular basis. I just wish more upstreams would do so too. If every upstream did this prior to that final release, it would be so much easier to do all kinds of cool things with your code, long after you lose interest in it yourself.

On Saturday 1 March, I attended the Constitutional Review Roadshow at Explore@Bristol (pictured). The review is trying to develop the rules for the Cooperative Group after its merger with United. The event wasn't at all what I expected or hoped for. There were relatively few individual members there. I don't know the split, but most of the 60 or so attendees seemed to be elected members of some sort and this was the first chance they'd had to comment since the open consultation ended last year. Some of the elected members had travelled from the Eastern and South East regions. The initial slide "Purpose of Today" stated three aims:

1. bring members up to date;
2. give members the opportunity to ask questions;
3. and aid members in preparing their formal feedback.

I don't feel the event really brought us up to date or aided in preparing formal feedback, because the roadshow appeared to summarise a report which hasn't been published. Some of the elected members had seen it the day before, but no copies were available to use at the event, so we were pretty much in the dark for some aspects. The event didn't give us much opporunity to ask questions either, despite its length. I was expecting more of a consultation event, which was reinforced when I entered the room and saw seats gathered around tables. I did not expect an hour-long lecture followed by three hours or so of whole-group question-and-answer, broken by lunch. Even with the competent chairing (AFAICT), that was an amazingly inefficient way of working, with some people being cut short, but still leaving some people not being heard. It can be summed up by the chairman commenting

"I do not want this to turn into a discussion"

while the big screen next to him said "questions and discussion"! Headlines from the review: similar elected structures to current Group structure, but regional board nominated by individual members; merge regions to produce six new regions (West Midlands and North West, Wales and South West, London and South East, Eastern England and East and South Midlands, Yorkshire and Humber and North East, Scotland and Northern Ireland); add management and non-executive directors to national board; no clue how to fix diversity problems; no view on fees or job spec until structures are defined. I'll go through the slides in detail and post the questions and answers if anyone leaves a comment asking for them. Otherwise, I think I've lost enough time to this for now.

The topic of switching from CVS to something else regularly came forward but nobody did anything. The net result is that several documentation are now maintained outside of the debian-doc repository because their respective maintainers didn’t want to stay with CVS. After noticing that the developers-reference also switched to SVN, I decided to convert the whole debian-doc CVS repository and import it in the new “ddp” SVN repository on Alioth. This is now done. Hopefully, the Debian Documentation Project can now again become the central place for writing good documentation about Debian. New contributors can be easily added through the DDP Alioth project. Volunteers are welcome to review what’s in the SVN and move obsolete documentation aside. People who moved away are welcome back. Another project that also suffers from its CVS usage is the website (and it desperately needs a better design). After yet another round of discussion on #debian-devel, we agreed that discussing endlessly was not an option and that someone had to try the conversion and prepare the scripts for SVN usage. So I proposed to handle the CVS to SVN conversion and ifvoid decided to try to update the scripts. And it looks like things are progressing quite well… we included the CVS revision -> SVN revision mapping in the conversion (option –cvs-revnums of cvs2svn) and this will enable us to script the update of all translations (they encode a CVS revision to know if they are out-of-date or not). Expect to hear from us soon on debian-www@lists.debian.org… Partagez cet article / Share This

One final post then I'm done discussing mutt. (Primarily because too many people failed to understand the problem, I guess I wasn't being as good at explaining as I could have been.) So the goal was to be able to tag individual messages within mutt, such that a short while later a new folder would be created containing all messages of that tag, regardless of which folder the message(s) are in. Actually finding the tags and creating the virtual folders is easy to do. I wrote a simple indexer which scans for tags in messages and creates hardlinks as necessary. The problem with this is that many operations on those hardlinked messags would create a new copy of the message and operate on that - trashing the hardlink. For some operations that's just fine. But I did specifically want to be able to untag a tagged message and not have to hunt around for the original. (e.g. remove the "todo" tag from messages where I'd done the relevant action.) So after a bit of trial and error I came up with a patch which allows the editing of a message in-place, in the hardlinked folder, without trashing the hardlink. This patch just invokes "$EDITINPLACE <filename>" where "filename" is the name actual file the message I'm working on is stored on disk. (i.e. ~/Maildir/.people.thewomanmeg/cur/1.2.3.txt). By setting the EDITINPLACE variable to point to my ~/bin/editlabel script I may easily remove any tags from the hardlinked-message and have it apply to the original. Job done! There are some limitations with this approach that are worth mentioning though:

• IMAP? Ha! Nope. We only work on Maildirs.
• The header-cache facility of Mutt breaks my "find the filename of the Maildir message" function. Not sure why, so I just disabled it.
• Many operations on the virtual mailbox will still break the symlink; because they don't edit in place.

I've documented things in a rather random fashion, and I've made a backported package of mutt with my patch available online too. Primarily so I dont lose the source like I did with my mutt-ng backport. Pointless Work I spent about 30 minutes rebuilding mutt to use a bubble-sort on the folder list which is displayed in the sidebar. Only when I was just about to install this patched build did I realise that the mailboxes were displayed in the order they are listed in my .muttrc file. One quick edit with Emacs and the folder list was sorted properly. Boy is my face red.. ObRandom: I'm loving my deaf-friendly alarm clock. It rocks. Place it under your pillow and it vibrates to wake you up. Simple. Effective, and above all it doesn't disturb my partner up when I get up to catch an early morning train. (Thought to be fair I usually wake her up anyway; can't leave without a goodbye kiss!) I'm still waiting for the vibrating ring, but this is good enough in the meantime.

Someone over at Novell wrote an application to enable eID in various applications with a simple click: you can enable web authentication in firefox, and email signing in Thunderbird and Evolution. It also does stuff which I didn't even know was possible under Linux—enabling eID card use under OpenOffice.org. So I'm now a bit in dubio as to what I should do with this. I have an open bug report against libbeidlibopensc2 that claims the mozilla/firefox plugin should be automatically registered when you install the package, rather than having to go through a bit of javascript in some HTML file, and I kindof agree with that. I could analyze the C# code to see how the Novell people do it, translate that to C (since C# doesn't work on every architecture Debian supports, and besides I don't want to depend on yet another huge list of dependencies after wxWidgets and Qt), and call the relevant code from postinst to enable the relevant plugins system-wide. OTOH, allowing every user to make the choice for themselves, could be a good idea as well. Then again, that's not really the Debian way (if installed, it should just work). Then again, I don't think that enabling these plugins system-wide allows one to still disable it on a per-user basis. Guess I'll have to give it some thought—other people's insights are appreciated.