For over 6 years now I've been running Buildd.Net as a service for additional information about Debian autobuilder network. The reason for running Buildd.Net was simple: until then there was a web interface running on kullervo.debian.org, but generating the webpage took more and more time on that m68k box as Debian was growing in number of packages. That webpage was always a nice plus for m68k over other architectures and it was often asked for having such a page for those other archs as well. With taking over the webpage from kullervo the other archs were added as well and Buildd.Net was born.

Buildd.Net was open for other archs and flavours, as I called the different dists like unstable, non-free or even volatile or skolelinux. Buildd.Net was always buildd centric, contrary to buildd.debian.org, which is more package centric. Yes: was - as I'm shutting down Buildd.Net soon.

The reason for this is a change of interest after m68k has been removed from Debian because of the Vancouver proposal. Vancouver caused the death of m68k. Well, anyway. Without being an official Debian arch, the development on m68k came to an end. There was no progress anymore and on the other hand there were changes in the backend of the Debian autobuilder network, which made changes on Buildd.Net necessary. Requests for help in maintaining to adopt the changes were fruitless. The changes that Buildd.Net is needing are beyond my capability of programming.

And as a consequence I'm going to shutdown Buildd.Net in the near future. Not entirely, but significantly. It will return to its origins: being a m68k (and m32r) autobuilder informational page instead of trying to follow up the whole Debian autobuilder network. Just for the chance that m68k will be revived again somewhen.
Andreas Barth told me that most of the functions of Buildd.Net is available on buildd.debian.org as well, although not yet visible. I offered cooperation and help when he wants to implement Buildd.Net functionality into buildd.debian.org. I still believe that Buildd.Net is offering a worthwhile alternative view of the autobuilder network. But, as I already said, I can't maintain Buildd.Net code source any longer on my own. So I better shut the service down instead of delivering a broken service any longer, if there's noone interested in helping.

Anyway, I hope that you all enjoyed the service in the past!

Mac OS X and other operating systems are using L2TP/IPsec for VPN connections. I'm running StrongSwan as my IPsec stack of choice, so I wanted to setup a VPN between my Debian lenny server and OS X as my roadwarrior. There's a nice howto on nielspeen.com. Everything is fine except for one thing:

Q: I want to set up strongSwan to interoperate with Microsoft Windows using L2TP/IPsec. I'm getting the error message "NAT-Traversal: Transport mode disabled due to security concerns" which results in strongSwan sending an encrypted notification BAD_PROPOSAL_SYNTAX

A: Here is a quote from strongSwan lead developer Andreas Steffen on how to deal with this problem:
NAT-Traversal with IPsec transport mode has some inherent security risks. Since Microsoft doesn't care about this please compile strongSwan with the option

./configure --enable-nat-transport

So, there's the inherent security risk, but without --enable-nat-transport L2TP/IPsec doesn't work at all with StrongSwan on Lenny. Is there anything I can do, dear LazyWeb, to be able to use L2TP/IPsec VPN connection with OS X and Linux (StrongSwan) to have a really secure connection? Being able to use Windows as VPN roadwarrior clients is optional, but no requirement.

I'm using BackupPC to make backups from one computer to another. Usually no big deal, but between the two machines there's a VPN connection across two dialup connections and 450 km air line. So, there is a maximal usuable bandwidth of about 1 Mbps between both locations. The problem was now: host A (the machine which is backupped) was initially backupped by host B (the machine running BackupPC) when host B was still located right beside host A. In the meantiime host B has been moved to its remote location and there I excluded one or the other directory in the following backup. Now I wanted to include them again, thinking that BackupPC is clever enough to realize that those directories are already in the backup #0.

Sadly, BackupPC seems to just compare the latest full backup without considering the partial backup, that was filled during the last 14 days over the 1 Mbps link. So BackupPC began to pull all the 200 GB of data again, although it already got roughly 180 GB in the partial backup. The cause for the partial backup was a longer connection timeout between the two dialup hosts.

Because I don't wanted to pull all 180 GB again and again and again, I looked for another solution for the problem. And it is quite simple. Given are a full backup #0 and another backup #7. #0 is the initial, complete backup before the relocation. Backup #7 is the backup after the relocation where I omitted some directories that contains 200 GB of data. Backup #8 is the partial backup. What I now did was this:

• in /var/lib/backuppc/pc/host_A/ I created a new directory for backup #9 by issueing 'cp -al 0 9'
• next, copy the content of the other valid backups the same way
• edit 9/backupInfo and change the number of the bakcup like this: 'num' => '9'
• add another line in pc/host_a/backups for backup #9
• start another full backup of host A from the webinterface in BackupPC on host B again

BackupPC will now base its freshly started full backup on the directory contents of backup directory 9. When the backup finished, you can delete that backup directory #9 again. This works quite well for me and the transfer with rsync. Maybe there are other methods dealing with that problem. Feel free to leave some comments.

As Dries Buytaert, the creator and head of development of Drupal, announced on Twitter, the new major (pre-)version of Drupal, namely Drupal 7 alpha 1 has been released! This was on the 9th birthday of Drupal.

This is great news and the release notes are mentioning some aspects why this is so:

Revamped User Interface
An incredible amount of work has gone into improving the user experience and administration interface. The new administration theme "Seven", the overlay module, the dashboard and the configurable shortcut bar, all lead to a much more user-friendly interface. In-place editing is enabled for blocks and nodes by default, so modifying the content of a site becomes much simpler.

Custom Fields
Drupal 7 bundles in the ability to add custom fields, similar in functionality to the Content Construction Kit (CCK) module. However, fields are no longer limited only to content types; they can be added to users, taxonomy terms, and other entities. Fields also have support for translations.

Image Handling
Drupal 7 brings native image handling to core. Image fields may be added to content, and have image styles applied to them, such as scaling, cropping, and other effects.
Update Manager
Building on Drupal 6's Update module, which keeps site administrators informed when new module and theme releases are available, the new Update Manger module can also install and upgrade modules and themes.

Front-end "under-the-hood" improvements
A new render API allows for highly granular theming, core template files have been revamped to provide more semantic markup, Drupal 7 now has built-in RDFa support, includes jQuery UI and a new AJAX framework, and a new core theme "Stark" which exposes Drupal's markup directly for those who want to dive in and start theming.

In addition, Drupal 7 has several major accessibility enhancements, making it the most accessible release of Drupal to date!

Back-end "under-the-hood" improvements
A revamped database layer resolving nearly all limitations in the Drupal 6 database layer, automated testing framework, new PHP stream-based file API that supports private and public files simultaneously, revamped node access system, new hooks for more flexible system interaction, an Entity API, a job queue API, and many, many, many more improvements.

Drupal 7 is also the most scalable release to date, with features such as built-in proxy server support, advanced caching techniques, and Content Delivery Network support for static files.

Alone the inclusion of CCK and Views are great news, whereas all PostgreSQL users will benefit from the new database layer under the hood. I've tested a pre-alpha development version some weeks ago and that Drupal 7 experience was already great. So, it would be nice to see Drupal 7 in Debian soon as well, but I guess a alpha 1 version might be too early to be packaged.

There is a drupal6 package in Debian, but for me as a Drupal User its support in Debian is somewhat unsatisfactory. Apparently it's not just me, but several other users are in the same situation. Drupal releases new version when a security issue was fixed in Drupal Core. Currently there are several security issues pending that are fixed in newer upstream version 6.15, which was releases on 2009-12-16. Bug #561726 deals with this as well as #562165.
It seems as if the maintainer is busy with other things, which is fairly ok, and if he isn't following Drupal security mailing list as we, as the users, are always need to forward and remember him about the security updates. Not just now, but also in the past. Remembering the maintainer about security updates is ok for me, alas it's somewhat tedious doing so. And beside the current situation, which made be ok giving Christmas vacation, Happy New Year and such, I'm quite satisfied with the work of the maintainer. But: could someone else please upload a new version of Debian in the meanwhile, please?! ;-)

UPDATE:
Luigi uploaded drupal 6.15 to unstable and I'm subscribed to pkg-drupal-devel on Alioth... ;)

Allen Lesern wünsche ich ein Frohes Fest, fröhliche Weihnachten, viele Geschenke oder einfach nur einen schönen 24. Dezember!
To all readers: Merry Christmas, Buon Natale, Joyeux Noel, Vrolijk Kerstfeest or whatever you will celebrate these days in your culture!

Allen Lesern wünsche ich ein Frohes Fest, fröhliche Weihnachten, viele Geschenke oder einfach nur einen schönen 24. Dezember!
To all readers: Merry Christmas, Buon Natale, Joyeux Noel, Vrolijk Kerstfeest or whatever you will celebrate these days in your culture!

I'm using digikam to organize my pictures I took with my D90 DSLR. I always got the impression that the View -> "Zoom to 100%" menu shows not the full sized image (100%). When using another picture viewing program like okular and choosing View 100% there, I get a "bigger" image. Proof is here:

100% view - Okular vs. Digikam

You can see okulars view on the left in the foreground. Digikams 100% view is in the background at the right. Both apps are showing the same JPEG picture. I don't know that Digikam is doing wrong there, but it's definitely not a 100% view that it shows. Time for a bug report, I guess...

UPDATE:
Oh well... wondering why all those people got the Copyright-Notice.png instead of the real picture, I finally discovered that I need to change the rewrite settings for the IPv4 vhost section as well. IPv6 users hadn't this kind of problem. So, better use IPv6 instead of IPv4, folks! ;-)

And thanks to sgran for pointing out <vhost 1.2.3.4 2001::1:2:3:4> syntax! ;-)

UPDATE 2:
The bug report is filed and registered as #562197.

UPDATE 3:
Problem solved! See bugreport.

I'm using digikam to organize my pictures I took with my D90 DSLR. I always got the impression that the View -> "Zoom to 100%" menu shows not the full sized image (100%). When using another picture viewing program like okular and choosing View 100% there, I get a "bigger" image. Proof is here:

100% view - Okular vs. Digikam

You can see okulars view on the left in the foreground. Digikams 100% view is in the background at the right. Both apps are showing the same JPEG picture. I don't know that Digikam is doing wrong there, but it's definitely not a 100% view that it shows. Time for a bug report, I guess...

UPDATE:
Oh well... wondering why all those people got the Copyright-Notice.png instead of the real picture, I finally discovered that I need to change the rewrite settings for the IPv4 vhost section as well. IPv6 users hadn't this kind of problem. So, better use IPv6 instead of IPv4, folks! ;-)

And thanks to sgran for pointing out <vhost 1.2.3.4 2001::1:2:3:4> syntax! ;-)

UPDATE 2:
The bug report is filed and registered as #562197.

UPDATE 3:
Problem solved! See bugreport.