Over the last days I have moved my email and web and stuff from a simple web and email hotel to a virtual server managed by me. So now I got a nice setup with

• Exim mailserver, smtp auth for sending
• Dovecot imap server
• roundcube webmail
• apache2 serving my blog and stuff

But most important for me: I can write my own spam filtering rules serverside and I can easily make sure all passwords are sent encrypted. What’s left on my todo, partly because I haven’t figured out how yet is

• Have exim not show the first recieved line when sending mail. No reason to put the IP of whatever place I am located into the emails
• Have exim rewrite the Subject: header of spam emails, not add a second Subject header
• Some kind of public/shared folders in dovecot
• Have moved my local pop3 kmail filtering rules over to exim filters

And I also still haven’t moved all my domains, but it is coming soon.

I am implementing the last bits and pieces I need for ikiwiki to replace rest2web on all sites I maintain. In doing so, I need to touch Perl. I probably ran into enough crap today for a very long rant, but instead I ll limit myself to a quote from the Perl book (3rd. ed., p. 52):

Note that we can use the same name for $days, @days, and %days without Perl getting confused.

I question any language whose interpreter s capability to deal with ambiguity without confusion is worth mentioning. NP: The Flower Kings: The Sum of no Evil

Update
After contacting Sebastian Dr ge, I've found that the problem with GVfs isn't in the deb-gview code, it is a permission problem within GVfs - the current deb-gview CVS code works with remote URIs when run under sudo which isn't ideal but at least indicates the nature of the problem. Once I have confirmation and/or gvfs is fixed, I'll skip deb-gview 0.1.6 and upload 0.2.0.

** (deb-gview:31002): WARNING **: file-read:http://ftp.debian.org/debian/pool/main/g/gpe-tetris/gpe-tetris_0.6.4-1_i386.deb:The specified location is not supported

Hmm. This is with current CVS of deb-gview, already substantially modified to work with GIO and GVfs as libgnomevfs is deprecated. I wanted to look at the port because quicklist and gpe-filemanager will need similar ports.

$ dpkg -l 'gvfs*'
ii gvfs 0.2.1-1 userspace virtual filesystem - server
ii gvfs-backends 0.2.1-1 userspace virtual filesystem - backends

I have an RC bug in deb-gview that I need to fix and I wanted to do the two jobs in one but it's looking now as if I'll need two uploads, 0.1.6 with a trivial fix to unstable just to fix the existing bug and 0.2.0 to experimental with a lot more changes but partially broken functionality. It's a shame because I've got everything else working using GIO - it is only the GVfs part that is giving errors.

Anyone else using GIO and GVfs with http:// in Sid?

In contrast to chess, there is very little free software for bridge players. Some deal generators have been around for years, but basically, that was all. Nowadays major online bridge site is bridgebase.com. Their windows client actually runs quite well in cedega (and wine), with the notable exception that the built-in double dummy solver doesn't work there. (A double dummy solver is a program that computes the optimal line of play with all four hands open (both sides dummy), and hence can compute the theoretically optimal score for a given board.) Furthermore, viewing records of played boards is a bit tedious as launching the viewer of course requires wine as well. Editing boards is not possible. This is where I started writing some perl scripts that would at least dump the board records as text files. At the same time I thought about doing something interesting with Gnome's glade UI builder. Over the past two years, I have been working on a GTK+ version of a bridge hand viewer and editor I called tenace. When Bo Haglund released his double dummy solver library as GPL software, I packaged it for Debian and worked on integration into tenace. It will compute "best" cards to play, determine par scores. Now tenace should be stable enough so I can risk announcing it to the world. Coincidentally, the screenshot shows a board from last week's club championships. East can beat 3NT by returning a Spade, but at my table they didn't and so the board became my first squeeze hand :)

We are currently developing a new feature for the dak instance running on ftp-master.debian.org: Release transitions. It basically means that the Release team has the possibility to block uploads of packages to unstable. I will describe the exact way how this will work in a mail to the release list, after aj merged my branch into mainline. But that should be pretty soon now, aj and myself did some code changes today and it looks ready now. Basically we will have a Yaml formatted file where the transitions are defined, together with a target package/version. As soon as that package with that version reaches testing the block is no longer in affect, but until that is the case every upload of a listed package will get rejected. We do check the testing version for every upload here to ensure that such a block, which is a pretty hard action, will be turned off as soon as the package transitioned, even if no Release team member is active at that time to remove it by hand. The release team will have a wrapper, dak transitions, which spawns an editor so they can define what they want as transitions. When they save and exit we check if the Yaml parses and then copy it over. The same wrapper is also used to clean the file from old transitions and to let the release team see what is defined in some nice, human-readable, way. (For the rest of the world I hope that the QA page will include information found in the file, which should be available later from http://ftp-master.debian.org/testing/hints/transitions.yaml. Or a little perl/ruby/python script for developers to run at home, so they can check if their package is affected). Its Yaml and easy to parse, even human-readable. :) I think it will be a nice feature helping the release, as huge transitions now can be done without the fear that one single upload will break them.

Some people expressed some concerns about the fact that we currently have about ~440 bugs in testing, but still hold to our plan of releasing in september 2008. The development of the RC bug graph as seen on bugs.debian.org is in fact not very promising - but using the information the BTS now keeps through version tracking, a more detailed graph can be created. This one in fact shows how nicely we are progressing: The number of long-standing RC bugs is steadily shrinking, while the number of fixed bugs just waiting for transition is increasing. The latter is due to several complex transitions that are stuck (such as the ghc upgrade to 6.8, the suitesparse upgrade or X.org). Anyway, lenny's overall situation is a lot better than the simple RC bug count shows, so try to be positive and start bug-fixing now, for the first Debian release on time!

In other positive news, the first bits of Gnome 2.22 have reached testing, we will switch the default gcc version to 4.3 on this weekend and will start using python2.5 as default python version in the next week. Interesting times!

Everyone’s favourite Saturday one-day classic so far this year(!) will be live on RAI Tre (13e) from 14:50 CET. Highlights are on Eurosport (19e) at 17:00 CET. (It’s live on Eurosport 2, but that’s not free-to-air.) Anyone found other free TV coverage? This seems surprisingly sparse, but I guess it competes with skating and swimming championships.

Last week, while I was already busier than I like, the cpu fan of my pegasos powerpc server blew off, and the resulting heat then killed the CPU. Which was quite a pain, as I used powerpc vservers on it, for which I had no replacement hardware. Or so I thought.

Time for an advertisment break: I'm giving away my oldworld powerpc macs, if you are interested in a beige G3, a 7200 or 4400 powermac, contact me. I doubt anyone will, these machines are more then ten years old. So I will probably give them to recycling next week. Be fast!

I'll also give away my pegasos2 board (and case) to the first person asking.

To make a two day story very short, I now run my vserver on a ten year old iMac, the very first model in a translucent case with build-in monitor, with 160 megabytes of RAM and 233 Mhz powerpc CPU. Yay. It's actually ok for what I need it.

The insane part is the booting. The hard disc has a MSDOS partition layout, as this is what the pegasos uses. But the iMac of course needs a HFS layout, so I need to use a boot CD, for which I've used a modified installer CD, where I replaced the kernel and initrd with the one I want. (Mostly because I didn't remember how to create a bootable CD on macs.) For some reason, the mac wouldnt boot this CD directly, so I've decided to use OpenFirmware (OF) to load yaboot (the bootloader) from CD manually and then yaboot will boot the kernel which can mount its root filesystem even from a disk with msdos partition layout :-)

And now I'll tell you about the magic of forth in OpenFirmware - which was only needed because I was stubborn and kept the kernel inside the directory install/powerpc on the CD... In OF you need to seperate pathes with backslashes, but with the OF installed on this iMac you can't type them! (No comment on that.) But you can use forth to evaluate them...

And so I use '" boot cd:,"(5C)install"(5C)yaboot" evaluate' in OpenFirmware, in which I get a prompt through pressing alt-windows-O-F while powering the machine on, to boot my main server at home. Easy.

I don't intend to do this very often (it runs 24/7), my new server has a XScale IXP422 266 mhz CPU and runs Debian armel :-)

But more on this later, now I need to throw out more old hardware, stuff I will never use again and which just takes physical space. Modern hardware is tiny - as can be seen on this huge pic! :-))

Oh, I almost stayed with powerpc: The "Conceptronic Grab'n'GO CH3WNAS" has nice specs too, is a bit cheaper and should be able to run Debian as well, but there are some missing bits until a 2.6 kernel will run and I wanted a solution which works today. And the FSG-3 (has better specs, that is, more RAM and more ethernet ports, allowing 4 vlans and) runs the new armel port already, the sub architecture patches "just" needs kernel mainline inclusion and there is no d-i support yet. But if you press the reset button on poweron, it will query a bootp server for its own IP address and for a file called zImage-recovery... :-)

And for those who care about the finished FOSDEM 2008 videos: unfortunatly I had even more hardware issues (which I refered to in the ... blog posting last week), which blocked me from working on them. But I will resume this work now (most of it is done by the computer anyway). Now, that I brought my laptop to warranty repair and put the disk into my desktop... To be clear: the laptop incident now is not the case I blogged about last week when I just wrote "..." - that was another machine where I intended to postprocess the videos on and now use as my laptop and to postprocess the videos on. I guess now you can somewhat imagine what I thought when my laptop broke two days ago on a harmless wednesday evening?

Hardware. It's great when it works.

OCaml 3.10.1 is now in Debian Lenny

zack@aquarium:~$ rmadison ocaml
     ocaml     3.08.3-3       oldstable   source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
     ocaml     3.09.2-9       etch-m68k   source, m68k
     ocaml     3.09.2-9          stable   source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
     ocaml     3.10.1-1         testing   source, alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
     ocaml     3.10.1-1        unstable   source, alpha, amd64, arm, armel, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
     ocaml     3.10.2-1    experimental   source, alpha, amd64, hppa, i386, ia64, powerpc, s390, sparc

Yay! Thanks Aba for the good news!

More updates:

* I can now walk to the mailbox on my own, and I only need to rest once on the way.
* I'm generally leaving the walker alone. It causes me more grief than it solves.
* I feel confident making the three steps up and down the balcony - which is good because the main doors are still too heavy for me.
* I've had a shower. I smell much better.
* We're starting to take visitors now - Jim and Sarah were here last night, Andrew and Sarah are coming tonight. It'll be nice to feel a little less isolated.
* I haven't spoken to my dad in a couple of days, but they were still scheduling his angiogram when I last spoke to him. All the walking and stuff that I've been doing means that I'm spending the balance of my day sleeping, so hopefully I'll catch up later today.

At this point, I'll probably post updates a lot less frequently, because it feels like the initial touch-and-go part is done. I'm looking forward to being off the steroids, and slowly spacing out the medications and such, but we're just in that zone where I'm getting up and around and am just waiting for lifting restrictions and such to be removed.

In the last few days, I've managed to sort out the various school extensions I need, the short term disability paperwork, the DMV disabled sticker paperwork, and all that.

Phone calls are much appreciated - the number is in my Orkut and Facebook profiles, it gives me a chance to interact with people and I'm starting to worry that I have too much time and am bothering the ones I talk to al the time. I'm still quite behind on emails, mostly because typing on the blackberry gets to be a bit much after a while.

I suspect I'm about to go into that annoying phase of recovery where nothing is urgent anymore, and we're coping, but we go stir-crazy because I'm not actually better enough to interact with the world yet and Angie still has to do almost everything for me. Any suggestions on making that part of the recovery suck less are appreciated! I've watched it a pile of times, but everyone seems to forget about it (including the people going through it).

Sunrise is 7:11 here this morning, I think I'll try to sit outside for it.

I need/want to write a slightly more verbose posts about why I blogged this short and cryptic post saying "hardware..." but, aeh, due to more hardware problems I don't really have time for that. Doh.

OTOH, if you happen to have about 300gb or more space on some server unused and you are able to make some traffic too, I would very much like you to contact me and mirror the DebConf video archive, so that we have another backup.

The source disk has a problem currently (it seems to be ok, but...) and we have one mirror, which is what you access at [1 http://meetings-archive.d.n], which is even backed up to a tape library. So in theory, we should be fine. In practice there is Murphy and I would sleep better if I knew the data is safe at yet another location.

Anyone? (After DebConf8 I expect it to be 400gb data, btw...)

trickle (available in a package repository near you) is a neat little tool to limit network bandwidth of a particular app. It's very useful for those situations where you don't want your connection gobbled up, but the application in question does not implement traffic limiting. For example, to run a dist-upgrade capped at 30 KB/s, run this: trickle -s -d 30 apt-get dist-upgrade (Care to guess what I'm doing now?) Note that trickle does not seem to work across the sudo boundary: don't do trickle -s -d 30 sudo foo, do sudo trickle -s -d 30 foo .

I was recently forced to face once more the limitations and quirks of rpm. This is more painful, when looking at a more capable system like .deb.

When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .

Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.

Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time

So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.

Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.

Fatality two - why fatality one was met

All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.

This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).

Fatality three - why rpm based system fail to have upgrade support today

Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:

• new-preinst 2
• new-postinst 2
• old-prerm 1
• old-postrm 1

The numbers 1 and 2 are literally what is passed to the scripts and mean "the number of the installed versions of the same package that will exist after the current operation finishes". No versions of any kind, no other parameters, no rollback, no nothing, just 1 or 2.

And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).

More bad ideas from the rpm land (glad not to be there)

In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.

They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.

Moving a git layout from debian-only to debian+upstream ... and live happily with git-buildpackage Let's say you have a git repository you have used thus far to maintain only the Debian part of some package (i.e. no upstream sources on sight). OK, you're right, that would be quite an uncommon scenario for a git repository. In fact the truth is that you are in such a situation because the git repo was obtained converting from a subversion repo which was using the mergeWithUpstream stuff of svn-buildpackage. Now that you have git's space efficiency you want to change this, import upstream sources, and possibly adhere to a branch layout which is compatible with git-buildpackage (which is very simple in its minimal requirements: an upstream branch containing just upstream sources and a master branch containing a debianized source tree). Out of the box git-import-orig won't work since don't have the upstream branch. Creating it branching from master (or somewhere else) won't work either unfortunately. Indeed after branching you will need to remove the debian/ dir from upstream and when you will merge upstream with master you will be merging the removal as well, bad idea. By myself I've found some horrifying solutions involving using git-filter-branch on the upstream branch merged from master and then squashing all the history of that branch with git-rebase, but they are so horrible that I won't mention them here more than this. The nice solution came from a hint by madduck on the creation of branches without ancestry. Here is the complete recipe (assumed to be run from the master branch of the repo, before creating any upstream branch):

$ git-symbolic-ref HEAD refs/heads/upstream
$ git rm --cached -r .
$ git commit --allow-empty -m 'initial upstream branch'
$ git checkout -f master
$ git merge upstream
$ git-import-orig --no-dch ../foo_1.2.3.orig.tar.gz

In short: you should create an upstream branch without any ancestry, in it you should create an empty commit, then merge it (vacuously) in master, and now you're ready to call git-import-orig to the rescue. Feature request on git-buildpackage to support this out of the box is on the go: bug #471560.

About a year ago, I bought a Norhtec MicroClient Jr., a complete 200 MHz MMX-compatible SoC (“Vortex86”) PC so small that it fits into your hand or onto VESA mountings. Althought thought as thin client, the machine has 128 MB RAM and runs Debian from either netboot, USB stick, CF card or 2.5” harddisk without problems and not even that slow. Later last year, we needed more MicroClient Jrs. at work and since the MicroClient JrSX had a 300 MHz 486SX-compatible SoC processor (“Vortex86SX”) from MSTi and 128 MB DDR RAM instead of SD RAM, we expected them at least in the same performance range and bought a few for ETH and I also bought one for myself. Well, they were about three times slower, since the FPU is missing, not all programs from Debian Etch work fine, e.g. X doesn’t work without patching and recompiling (with Sid, X works, but not the kernel anymore)… BTW: I had both machines with me at FOSDEM ‘08 at the Debian booth and the MMX-compatible machine also at Chemnitzer Linux-Tage (CLT) at the Symlink booth and in Kurt Gramlich’s talk about ecological computers. So if you saw them there, just imagine the same case, with a twice to three times faster CPU and four times the amount of RAM, but with roughly the same carbon foot-print! For our thin client purposes at work we now use ALIX boards from PC Engines (Mini-ITX format) with 500 MHz AMD Geode processors. They’re much faster than the MicroClient Jr. and need even less power. Today, while surfing around on some Mini-ITX shops, I found some computer in obviously MicroClient Jr. case, but with 500 MHz VIA Eden processor and 512 MB of RAM. I first couldn’t believe it. They are selling it as eTC-2500. Since eTC-2300 was one of the brandings of the MicroClient Jr. which is called eBox-2300 officially by the manufacturer DM&P, I searched for eBox-2500, but didn’t find anything useful. Then I looked at the manufacturer’s product page at CompactPC.com.tw and found the eBox-4300 — so it’s really true, they managed to fit a board with 500 MHz VIA processor and half a Gig of RAM into the already fscking small space inside the MicroClient Jr. case, and even without needing more power: Still 15W from the power adaptor. Next stop was Norhtec’s Website. And yes, they also have a new MicroClient product: The MicroClient Sr.. I really need to have one of those for my MicroClient collection! ;-)

Daniel, there have never, ever, been any changes in ikiwiki can could result in GUID changes on upgrade, with the exception of enabling usedirs, which is something you have to do manually. And there never will be any if I have anything to say about it.. Of course, you can cause the GUIDs of posts to change by renaming or moving the files around, or by changing the url to your blog. Doesn't explain why it happened of course.. PS, can I git clone your blog from somewhere? There's an interesting blip in your RecentChanges page that I'd like to figure out, where one time the change author is listed as "Daniel Burrows Daniel_Burrows".

I've been sucked into this alternate reality game, "The Lost Ring", which involves 6 people who woke up with amnesia in labyrinths around the world, blindfolded, with a tattoo "Trovu la ringon perditan". It involves a lost Olympic sport, lots of Greek mythology and history, and lots of puzzles and detective work. Currently 26 pages of a codex are being tracked down from hiding places all around the world, with ones in Cardiff and Austin recovered over the past few days, one in Shanghai that I hope will be reached soon, and a location just discovered in Stockholm (in a bread store!), that someone needs to go check out. (Update: Jon read about it in my blog and went and got photos! page 1 page 2.) This is the first time I've played an alternate reality game, but the way the story is told, through blogs, podcasts, youtube videos, email with the characters, and recovered documents like this, is quite compelling. Also interesting is all the use of Esperanto, as well as characters who speak Spanish, French, German, Chinese, Japanese, and Portuguese, so that translation is an ongoing part of the game.

During the last weeks I’ve been busy working on adding support of new source package formats to dpkg-source (the wig&pen format, a wig&pen variant based on quilt, Joey’s git based format integrated by djpig, …). I just reached the state where I believe the code is mostly ready to be merged in the master branch. Thus I would like some external testing and feedback. Grab and install the package here and try building packages with dpkg-source "--format=3.0 (quilt)" -b mypackage (or any other new format). You can find more infos in the call for test on debian-dpkg (here and here). If you find regressions, please report them. If you want to grab the latest sources, use git clone git://git.debian.org/git/dpkg/dpkg.git dpkg; cd dpkg; git checkout -b sourcev3 origin/sourcev3. Partagez cet article / Share This