(Note: this is a long post)
Package: deb-gview
Use of GnomeVFS: "Individual package files or packages referenced in a changes file can be viewed from local or remote filesystems using GNOME VFS."
Main changes: src/dvarchive.c but also src/main.c.
Port Status: Complete and tested.
Prerequisites
Do not run any code before completing this step
You must ensure that gvfs, gvfs-bin and gvfs-backends are all installed and operational before running any of your modified code. Thereby hangs another tale. The application itself probably needs to depend on both gvfs and gvfs-backends. gvfs-bin provides test binaries like gvfs-info.
You need to ensure that the following command operates correctly:

$ gvfs-info http://www.google.com

display name: /

edit name: /

type: unknown

size: 0

attributes:

  standard::display-name: /

  standard::edit-name: /

  standard::content-type: text/html

  id::filesystem: type='http',uri='http://www.google.com',mount_prefix='/'

Note that this is run as the normal user, not under sudo and not as root. - that just complicates things. If you find that this works with sudo but not without, read the bug report against gvfsd.
If you get this output:

$ gvfs-info http://www.google.com

Error getting info: The specified location is not supported

read the bug report, find and kill the borked gvfsd process and ensure that gvfs-backends is installed before attempting any other gvfs* commands (including via your modified source code).
Starting

1. Online copy of the GIO docs. online copies of the GVfs docs. I mainly use Anjuta where both sets of the docs are available via libglib2.0-doc >= 2.16.1 and devhelp or via your localhost using dwww.


2. #include <gio/gio.h> to replace #include <libgnomevfs/gnome-vfs.h>.
   (May sound obvious now but examples are not that frequent in the GIO docs as part of libglib2.0-0.)


3. The GIO docs do give some info on porting variables:
   
   
   • GnomeVFSHandle * vfshandle; became GFile * ghandle; GInputStream * stream; in deb-gview
   
   
   • Extra variables needed for deb-gview: GVfs * vfs; GError * result; GFile * gfile; GFileInfo * ginfo;. GError itself is not new but it can catch you out in the port because so many GIO/GVfs functions can use it and you find yourself using g_clear_error(&error) a lot or GLib will complain about trying to replace data in a GError.
   
   


4. Separate path and URI handling - GIO and GVfs have separate filename/path handling for paths on a local filesystem and paths on remote filesystems and the two cannot be mixed. This was a big source of bugs during the port (it may be a UTF-8 issue) and in the end I went for a gboolean flag in the context that this particular viewer was handling a file from a remote filesystem (e.g. http://localhost/incoming/deb-gview_0.2.0_amd64.changes, http://ftp.debian.org/debian/pool/main/e/emdebian-tools/emdebian-rootfs_0.9.1_all.deb or http://incoming.debian.org/foo_version.changes) and not from a local path (e.g. /opt/debian/deb-gview/deb-gview_0.2.0_amd64.changes or ../../debian/deb-gview/deb-gview_0.2.0_amd64.deb). Personally, I found g_file_is_native to be unsuitable for this purpose and as I had a "user-entered" path available, I simply use if ((g_str_has_prefix (path, "..")) (g_str_has_prefix (path, "/"))) but YMMV, depending on how you obtain the path itself.
   Keep track of the type of input file when handling GFile - g_file_get_path will fail if passed a GFile that needs g_file_get_uri and vice-versa. These failures output messages to the console so they are relatively easy to track but not only will the call fail but the GFile itself is likely to get corrupted, leading to other bugs and messages to the console. g_vfs_get_file_for_path(vfs, path) and g_vfs_get_file_for_uri(vfs, path) (which obtain the GFile from GVfs in the first place) also fail if passed the wrong type of path.
   In some situations, g_file_get_parse_name can be used to get a "normal" char* representation of the path to the GFile but I was only able to use this in specific circumstances and only when the path and URI handling flag was implemented.
   This all complicates the port because gnome_vfs_make_uri_from_input did not have this separation issue.


5. Checking if a file exists - if (!g_file_query_exists (gfile, NULL)) may seem easy but unless issues with the URI and path are handled cleanly, this simple check will fail even though the file exists. The problem arises because GFile appears to mangle a URI with a path function and vice-versa. The GFile ends up with an invalid path and hence there is no valid file to check so the query fails - but without indicating that it's actually an internal error in GFile rather than a valid path that simply does not exist.


6. Reading files in one go - vfsresult = gnome_vfs_read_entire_file (vfstext, &changes_size, &contents); gets replaced with g_file_load_contents (cfile, NULL, &contents, &changes_size, NULL, &result); (note the order swap between the size and the buffer to use). Once read, the buffer can be handled as before. This is one of the easier changes in the port, once the above issues are all cleared up. On the other hand, GIO and GVfs do appear to handle relative paths more easily than GnomeVFS.


7. Checking VFS is active -
   

   vfs = g_vfs_get_default ();
   
      if (g_vfs_is_active(vfs))  



8. Reading files as a stream - result = gnome_vfs_read (vfshandle, readbuffer, skip, &bytesread); becomes bytesread = g_input_stream_read (stream, readbuffer, skip, NULL, &result);. Fairly straightforward as long as you use:
   

   if (result)  
   
   g_warning("Error: %s", result->message);
   
   g_clear_error (&result);
   
    

   (or something equivalent to get the error message to the user), every time you use &result.
   vfs_uri = gnome_vfs_uri_new (gnome_vfs_make_uri_from_shell_arg (filename)); becomes filestream = g_file_read (deb->ghandle, NULL, &result); (there's that &result again).


9. Checking the stream remains open.
   

   stream = (GInputStream*)filestream;
   
          if (g_input_stream_is_closed (stream))
   
          return FALSE;



10. Seeking inside the stream - YMMV but seek never appeared to work well for me in VFS so I had to read into a dump instead.
    

    gpointer dump; 	        
    
            dump = g_new0(gchar, seek); 	        
    
            result = gnome_vfs_read (deb->vfshandle, dump, seek, &bytesread); 	 
    
            g_free (dump);

    
    In GIO, seek is much easier: g_input_stream_skip (stream, seek, NULL, &result); - just handle that &result again.


11. Closing the stream - gnome_vfs_close (vfshandle); becomes g_input_stream_close (stream, NULL, &result);.


12. Getting information on files - if ((vfsinfo->type != GNOME_VFS_FILE_TYPE_REGULAR) (vfsinfo->size == 0)) becomes
    

    ginfo = g_file_query_info (ghandle, G_FILE_ATTRIBUTE_STANDARD_SIZE, G_FILE_QUERY_INFO_NONE, NULL, &result);
    
     if (0 == g_file_info_get_attribute_uint64 (ginfo, G_FILE_ATTRIBUTE_STANDARD_SIZE))
    
     
    
           dv_show_error (DV_ERR_NO_FILE, parent);
    
           return;
    
     

    
    (dv_show_error is a user-facing error report func) and, yes, there is a g_clear_error(&result); later.

Summary
This took me quite a bit of time and the bug in gvfsd was a significant hindrance so ensure that you test with gvfs-info before thinking there is a bug in your code. (Also remember that if you are reading files from http://incoming.debian.org/ then those files will disappear once each day when the cron job moves them into the pool. ) I recommend developing and testing against http://localhost/ during the port.
The GIO docs are relatively thin (especially for GVfs) and that is not just because GIO is still new. Starting a new application using GIO and having a working GIO/GVfs setup in place already would be much easier so new applications will work. As ever, the problems really show up when trying to port an application that has already worked around the various GnomeVFS bugs and now has to both remove those workarounds and implement one or two other changes for GIO.
Ensure your application has Depends: gvfs-backends - until the bug in gvfsd is fixed, it would be unwise to put gvfs-backends in Recommends: because that will almost inevitably result in any user without Recommends: enabled passing a call to GVfs at least once without an available backend, resulting in a broken gvfsd process and a completely broken application until the user either kills the process or logs out and logs back in. Even identifying that issue in a bug report is not straightforward - hopefully the bug report and this post will help. (Yes, depending on how you configure the ported application, it is entirely possible for this broken gvfsd process to break all file operations in your application, even local ones.) Unfortunately, there is no call (currently) to take down GVfs - you can only test to see if it is already active and that check is not sufficiently intelligent to detect the broken gvfsd process.
Subjectively, GIO does appear smoother than GnomeVFS and maybe faster. Now I need to get on and try to port other applications to GIO.....

That time of the release process now came where I will rant about uncoordinated introduction of debconf templates. Given the release timeframe, I started the very same work I did for etch: try to get as many debconf translations as possible in place. Of course, in the same time, these efforts are balanced by maintainers of packages who introduced new debconf templates without coordinating with debian-i18n for their localization and without sending calls for translations first. The answer is easy: use podebconf-report-po! This nice utility comes along with po-debconf and should indeed be marked Essential..:-) The bad guys of the day: citadel and ttf-mathematica4.1. Both combined add 18 strings without any effort to get translatons in. The bad guys of last days: bgoffice-dict-download, movabletype-opensource. As expected, most languages statistics will go down by tomorrow despite the simultaneous efforts of maintainers and /me to complete most other packages. Please, fellow Debian developers: it is now time to stop changing the bloody debconf templates.

Nothing to do today? How about - you write a new license? A new license a day - keeps sanity away. TO ALL THOSE IDIOTS OUT THERE CONSIDERING TO WRITE A NEW “OPEN SOURCE” LICENSE: PLEASE DIE A HORRIBLE DEATH And to all the software authors, graphic designers, to anyone who wants to haven open and free content: Thank you for your work, but please USE ONE OF THE EXISTING AND WELL-KNOWN LICENSES[1] or don’t waste the time doing the work. Otherwise you will just waste time from a lot of other people that want to use or distribute your work. Thanks. [1] Like GPL, LGPL, MIT, BSD, Apache or the free CC licenses.

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?

I am trying to add some order to the mess that is the Launchpad translation repository. Problem is, strings translated just once through Launchpad stick around forever, even if you change them in upstream later. In effect, a lot of translation bugfixes were not reaching Ubuntu users. I thought I had that covered. Unfortunately it's not the case. I just noticed that in the Launchpad package list sorting by changed strings only sorts the first page! Initially I had noticed random package names and mistakenly thought that the whole package list was sorted. The whole list (~1500 packages, shown in 75 package chunks) is sorted by "importance", so it's basically random. Good luck finding modified packages in that haystack. Seeking computer-literate monkeys.
Earn up to five bananas per hour!
Must be able to use mouse. Unless... how about increasing the batch size? Turns out that in Launchpad the batch size is not capped, so by changing a URL parameter you can just set it to a high number, wait a few short moments, and get the complete list of packages. Sort that by changed strings and we're done, right? We're done finding the local translations, but not fixing (reverting) them. The new, larger list reveals that there are more than a few of those with quite more than a few strings that should in 99% of the cases be reverted to packaged versions. Here's how that works: Monkey operator instruction manual

1. Click on 'Packaged' radio button for all 10 entries on page (no batch size modifications allowed here...)
2. Click 'save'
3. Repeat until the page says 'No more translations'
4. Done. Not! When you click the 'Save button', the starting offset is changed for the next page. However, the translations you just marked are removed from the list at the same time. So, if you were looking at translations 1-10, after pressing 'Save & Continue' you will actually be looking at translations 21-30, not 11-20! To get to the 'lost' translations, you have to retrieve the list from the start again. So, load the initial page and go to step #1 to fix the remaining half of translations. Next time you reach this step, half of those will be left. Next time, half of half of those. Isn't that fun!

Where's that monkey ad again? A brute force solution could be to write a script. That could save some bananas. Not that we could run out of them as this whole thing is pretty much bananas. That does not look like a clean solution though. Does anyone know if there there is a better way?

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.

Many artists use the problems of current society for inspiration. I am therefore optimistic in the sense that if artists are seeing freedom as a serious problem in the post 9/11 world, others outside of tech-oriented circles will finally notice as well. Bruce Schneier pointed out TSA Gangstaz a few weeks ago and now Frontalot's Secrets From The Future (the latter is even offered as an Ogg file, and the lyrics shows surprisingly deep technical understanding, so these guys seem to really care about this issue.) Anybody working on art related to patent or copyright law? (Not a rethorical question, this blog does have a comments feature!)

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!

Debian is part of the Google Summer Of Code again this year (2008).Last year was quite successful, so we hopefully will get at least as many slots as last year.Applications will be possible March 24th to March 31st. This means, you should already starting writing your project proposals and get feedback by possible mentors. Ideas can be found in the Debian Wiki, but notice these are just ideas. You are by no means limited to what we're proposing there.As for writing an application, here are some general notes:

• Start writing early, submit early. The early ones get best exposal to mentors. When we read the nth proposal for the same project, we're usually quite bored already. Especially with respect to feedback this IS a benefit for the early proposals
• Don't just copy & paste. We're not stupid. We want to know if you understand the subject and have good ideas, so show that. We're not interested in your ability to access the Wiki, we trust you on that one.
• Communicate. Open Source is about communication and collaboration. So get feedback from people who work on the related subjects and possible mentors. Don't keep your application secret. You don't have to be afraid someone could steal your application (remember, we read the applications, and we can tell who has just been using copy & paste and who is able to answer our questions!) - but you DO need the feedback to improve your application.
• Use all communication media. The GSoC web application has it's limits (e.g. by not being open yet). So make use of the IRC channels (#debian-soc in OFTC) and the mailing lists for your project. We'll also use these to judge your application, not just the web interface. "Has been asking good questions on the mailing list" is one of the best verdicts you can get.
• Bring in your own ideas. We're looking for talented, interested people, not "stupid work horses". So show what you've got.
• Don't be afraid of challenges. This is all about stepping up to a challenge. We'll help you succeed. If you e.g. aren't experienced in Python yet, but the proposal says "Required skills: Python", just be honest. Mention that you're a good Ruby coder, and we'll trust you on being able to pick up Python in a short timeframe. And maybe even just start already in filling such a gap.

In turn, we (= the mentors and admins) will try to (again - we did that last year) have at least three mentors read through your application, provide feedback on it and judge it. We don't draw lots for the slots, but we'll rank the applications based on the scoring by the mentors. We'll also try to assign you a fallback mentor in case your mentor has to step back for whatever reason and to give you additional people to talk to.

I'm moving to London in a bit over a week, which means disposing of some quantity of junk, moving some more to London and hiding the rest (anyone got any recommendations for storage? I don't need regular access, but life would be immeasurably easier if they can pick stuff up and take it away). It also means the end of almost 10 years of living in Cambridge, and as a consequence there will be a party in the usual location on Friday the 28th. And possibly also on Saturday the 29th, depending on how much alcohol there still is lying around.

Also, if anyone in the Cambridge area wants some junk, the current list is here. I'll update stuff here as necessary.

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.

Good: Probably because of its origins, there seems to be a higher willingness to write detailed commit messages in the Git community when necessary. I feel like at home. Bad: I really miss the distinction between mainline revisions and merged revisions. I guess that if they had that, there’d be less urges to rebase and squash all over the place.

Today I spent a while fixing some more segfault bugs. I guess that this work qualifies as either fixing RC bugs, or potential security bugs. Anyway I did an NMU of libpam-tmpdir a while back to fix all but one of the open bugs against it. I provided a patch for #461625 yelp: segfault while loading info documentation, which fixes the symptoms of bad info-parsing, and avoids the segfault. I also looked into the #466771 busybox cpio: double free or corruption during cpio extraction of hardlinks - but it turns out that was already fixed in Sid. Finally I found a segfault bug open against ftp:

• ftp: GET segfaults. Buffer overflow?
• Buffer overflow: comman buffer size is not checked (Almost certainly a duplication bug.)

To reproduce this bug run:

skx@gold:~$ ftp ftp.debian.org
220 saens.debian.org FTP server (vsftpd)
Name (ftp.debian.org:skx): anonymous
331 Please specify the password
Password: foo@bar.com
ftp> cd debian/doc
250 Directory successfully changed.
ftp> get dedication-2.2.cn.txt dedication-2.2.de.txt dedication-2.2.es.txt ..
local: dedication-2.2.de.txt remote: dedication-2.2.cn.txt
Segmentation fault

You need to repeat the arguments about 50 times. But keep adding more and more copies of the three files to the line until you get the crash. It isn't interesting as a security issue as it is client side only; but as a trivially reproducable issue it becomes fun to solve. Click to read the rest of the entry I mailed the maintainer of FTP and said unless I heard differently I'd NMU and cleanup the package in a week. All being well this entry will be nicely truncated in the RSS feeds as support for the <cut> tag was the main new feature in my previous upload of chronicle - the blog compiler I use/wrote/maintain. ObQuote: Razor Blade Smile

I post it here, because other might find it useful, even if probably somebody else will already have done it. So here is the problem I tried to solve: when using Emacs as an editor, there are several way

• one can use EDITOR=emacs, then each time you need an editor, you will have to wait for the Emacs launching time, and Emacs is not known to be quick fo this. Also, if the application that launch $EDITOR is waiting got it to end, you will have to quit Emacs and relaunch later.
• one ca use EDITOR=emacsclient, then if you forgot to launch emacs before using an application that need an editor, this will failed.

So I needed something to launch Emacs if needed, then to launch emacsclient, so here is my script (its named myemacs):

#!/bin/bash
if [ -z "$*" ]; then
    emacsclient -e "(raise-frame)"   (emacs &)
else
    emacsclient "$@"   (
	(emacs &)
	sleep 3
	emacsclient "$@")
fi

There is still problems with it: if emacsclient failed for any other reason than the nonexistence of the Emacs session, Emacs will be launch again. Also, one might want to launch it in “waiting” mode even if there is no argument. If you don’t want it to wait for the end of the edition of the file, you can use the -n option. Edit(Thanks to tom s zerolo): of course you need the proper incantation in the .emacs to start the emacs-server.
Reedit(thanks to MJR): and you need a recent (emacs22) as older emacsclient cannot evaluate lisp code.

I recently purchased a Grace ITC-IR1000 Wifi Radio from Beach Audio. There seem to be a number of competing products available at the moment, and it seems they are all based on the Reciva internet radio platform. This appears to be an ARM based system running Linux (checkout the GPL compliance area). It has built-in wireless, so connects up directly to your 802.11 network. It supports WEP and WPA; entering the WPA key is a little like entering your high score on an arcade game with a built-in scrolling alphabet. It supports all sorts of codecs, including the most important Real, WMA and MP3. Once on the network, it contacts Reciva service (free) to update and download channel lists. Once there, you can select stations filtered by region (Europe, Oceania, etc) then country. There are literally thousands to choose from, and users can contribute streams which are filtered by Reciva and added to the database periodically. An excellent feature is the ability to log-in to the website and both build favourite lists and add your own personal streams. You then register your radio's serial number with the website and on the next channel update you get access to your lists. It also offers you the opportunity to connect to a local PC to stream music from folders there; I haven't looked into this feature at all. Overall, it's a great device. The audio quality is great, and it seems to have at least a little sub-woofer built in. It has some nice features; 5 of the buttons on the front are quick access preset buttons, just hold it down when you are listening to the station and it remembers it. It supports a wide range of streams, the interface is simple to understand, it keeps the clock via NTP and directly connecting to the wireless is great. My ideal application is for a bedside clock radio, so I can listen to .au radio as I go to sleep and wake up. It has an inbuilt back-lit clock, sleep timer and alarm system, but they all take a bit of fiddling. The buttons are small and black, which doesn't help in the dark, and most access is done via the big scroll wheel which you press to make a selection (think iPod). However, the resistance of the rubber pads is less than that the pressure required to push the button in, so it really takes two hands. This means when you want to setup an alarm and put on the sleep timer as you go to bed there is a bit of fiddling through menus, etc. Also, as it is playing the clock seems to go away. Initially I had a problem with firewall ports, but it doesn't seem a big issue on the forums so it must have just been me. I also wonder what happens when Reciva go out of business, because all the tuning happens via their website. Something similar happened when 3com Audrey support was dropped; it then became a matter of faking DNS replies. Sniffing the protocol might be fun :) All in all, although it sounds a little silly, if you know what you want it for this is a great little system. I imagine any expat will get their money's worth listening to home radio stations. If you're only interested in local radio, I'd still suggest the best thing is still probably (surprise, surprise) a radio. It leaves a little to be desired as a bedside radio but is otherwise a very nice toy!

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.

Well this has been a busy week, and no mistake. Still I've advocated a new individual who wishes to become a Debian Developer. I guess now I get to watch second-hand to see how long the process takes! (I messed up though; the first sponsored upload for her has the wrong mail address. It'll get REJECTed, and then we'll try again. D'oh.) In more optimistic news this weekend I'm going to attempt to finish painting my front room. The painting of this room was started n the 3rd of February. So we're coming close to two months. A new record! Also this weekend I must write some letters ... Tonight will involve some Balvenie and a copy of The Godfather (part 1). ObQuote: Eight Legged Freaks.