I switched from Pine to Mutt as my primary email client around the time I decided to become a Debian developer, because Pine's PGP support was abysmal (it also beat building Pine packages by hand all the time). The other bonus feature was it threaded emails, which made it easier to follow mailing lists. It's been a very gradual learning process since I switched, and I certainly don't consider myself to be a Mutt power user. I initially really hated it, I think largely because of the concept of "old, unseen" messages, versus "new" messages, and the behaviour of the Tab key. Once I unset the mark_old variable, it got a lot more tolerable. I think at some point I either plagiarised someone's .muttrc from the Internet, or sat down with the manual (or possibly a bit of both) and came up with a config that I could live with, and it's been workable ever since. One problem I (more recently) started having was that when I had 200-odd unread emails in my inbox, which has been pretty common occurrence in the last couple of years, and someone replied to an email in an old thread, because I wasn't necessary scrolling through all 200-odd emails (as new, unthreaded emails usually sorted chronologically at the bottom of my inbox), I'd miss the fact that the email had arrived, often for extended periods of time. I was lamenting this problem to Sarah over dinner last night, and saying how I preferred Gmail's behaviour, where the position of a thread in the inbox was determined by the date of the most recent email in the thread. I figured Mutt must have a sort option to be able to deal with this, and so I went rummaging in the manual last night, and discovered the sort_aux configuration variable. I've set that to last-date-received, and now I'm very pleased. I should never miss an email again. Of course, I should really try practising Inbox Zero, then it wouldn't be an issue.

There is one particular aspect of Microsoft’s document format going through ISO process that I had a hard time to find a counter-argument against: “Well it is better to have multiple open formats, isn’t it?”. Last night when I was presenting in a Document Freedom Day event, I finally got one. When multiple standards exist in the same area, two options can exist:

1. Cooperative standards - providing similar functionality in different ways that can coexist in the same medium without a significant overhead. An example of this are the credit cards - they have multiple ways that the card information can be transferred to the bank: visual writing down of the data, imprint, magnetic strip and the chip. Any of these ways can be used and all of the are equally valid;
2. Conflicting standards - providing the same functionality in incompatible ways. The example here is the power adaptors - the form of the power plug is an open and public standard (AFAIK), but so many of them exist in different places that it creates all sorts of problems both for companies producing electronic equipment and for frequent travellers.

What Microsoft proposes is much worse than the power plug mess, because the power plug standards are at least restricted by region. But imagine going to another country and having to be ready that you hotel could have any one of 8 power plug types at random. And while electricity is rather easy to convert looselesly, complex documents are far more .. complex. It is like having to buy 8 different power bricks for each of your electrical devices to be prepared for all possible voltages, frequencies, waveforms, polarities and whatnot. Having more than one ISO document standard in a horrifying idea for any programmer that will have to ever work on software that will need to support both of them - twice the work for no etra benefit whatsoever. If Microsoft can prove (in technical terms) that their file formats present capabilities that Open Document can not, then the only sane way to implement those in the ISO format is to add those capabilities as an extension of the existing Open Document format and not to reinvent the wheel. Microsoft also has a habit of pointing to JPEG and PNG being “competing”. Well, they are not - those are complimentary standards, because JPEG is designed for compression of photographic details while PNG is designed for the compression of bitmapped vector images. Something like DejaVu could be seen as a superset of the two formats. So, if you ever need an argument against more standards - remember about the power plugs.

Ah, Erich, that IS so true. I never found a well written PHP application anyway, or it was only 10 lines long. I guess that's primarily the language fault. It permits to do a lot of stuff and does not simplify, help nor force the simplest implementation methods like MVC which should be the base in Web developement. Well, take as example what we would do with Python and GTK+ if they were like PHP and HTML (I do not have the API reference so it will be somewhat improvised):

#finally we do not need this module I wrote everything myself
#import somemodule
def main():
    # Well we want to do some printing
    window = GtkWindow()
    # Connect to the database without any abstraction, that sucks
    db = mysql.connect()
    data = db.query("select RANDOMLYTYPEDDATA from MYONLYTABLE");
    while data:
        # Ah, we do not have include() so we cannot reuse code
        # I'm a PHP developer, I do not know functions
        import somestuff
    window.print(somestuff.result)
    # Obviously, forgot to close db connection, etc.
    if form.data.field == "hello":
        # The user asked for hello, print hello
        window.print("hello")
    # debug
    print data[0]
    if form.data.anotherfield[0] == "morning":
        data = db.query("select anotherdata from MYONLYDATA")
    else:
        sys.exit(42)
    label = GtkLabel()
    # Yes know we construct the view!
    window.add(label)
    label.print(data)

That is typical PHP code: we just take randomly typed data from our DB eng... no wait, from MySQL (remember that's LAMP!!! Not LAPP or anything else, bitches!), then we print some HTML code with data, and we do tests on environment, forms, etc, and we get back data, reprint them, do not use functions but include() multiple times thousand of files and then do not close/free anything. It's so easy to do bad code that lot of people coming from nowhere and who did not learn anything from other languages are doing it. Another hypothesis coming from my experiment: PHP is a language which can be developed under any OS since it's server-side executed. A link between mostly brain dead "developers" from the Microsoft world and whose from the Free Software world. A clash. I apologize to some of my coworkers doing better PHP all the day.

Approximately one year ago danske bank swallowed the second-largest Finnish bank, Sampopankki. Last weekend, the perfectly fine working web-bank was flushed down the toilet and replaced with Danske Banks infrastructure. So far the results are quite horrific:

• People are reporting missing/too much money been shown in their accounts.
  
• Standard ssl/html based frontend has been replaced by a java applet. Worse, it needs a JNI library. Apparently to sniff your PC configuration. Surprisingly they provide a (ia32) Linux JNI lib as well. Compile once, run to the hills...
  
• The new webbank has security holes. url's that show a competing banks login prompt instead of sampo/danske bank are circulating on IRC. Apparently the danish website has the same bug too. The bank representative has (so far) refused to acknowledge there is a security hole.
  

A surprising number people have dismissed the whole issue as "IT business as usual, why complain?". Sure, we all *know* that most IT projects deliver late, fail to work until the first service pack, fail to import data properly from previous versions or simply fail completely. But is that something we should just accept as part of life? Even for banks that are (were) holding our money?

As last year, I'll be trying to help with the Debian Project Leader IRC Debate tonight (2008-03-26 20:30Z until 23:30Z). This annual election is probably the biggest influence most developers have on the direction of the project, so please choose wisely. :-) Unlike last year (IMO), it's a more interesting field of candidates who are all strong in different ways. I feel even the weakest candidate is stronger than in previous elections. Anyway, I shan't write more until after the debate. If you can't make the debate, recordings will be posted promptly, among the rest of the debate that's on debian-vote. This old dog is probably going to use a new IRC client for the debate, to make it easier to watch everything and copy-paste audience questions, so I hope I control it properly!

I am looking for a charity to receive regular donations. I would like to support the environment and wildlife, rather than people directly, and the World Wildlife Fund immediately comes to mind. While I ve been supporting the fund s work for two years now, I feel a bit uneasy about its size. It seems plausible that they can leverage synergies much more effectively, but large organisations also burn through heaps of money just to be able to do what they want to do. In addition, I feel the whole organisation is too professional and anonymous. The same applies to Greenpeace. With none of this do I intend to discredit the work of the WWF or Greenpeace! They re just not what I am looking for. I have previously donated to a charity in China, but the troubles and efforts involved with this were too much. And while China certainly needs a lot of help and support in rethinking their environmental policies, it s not like central Europe or other parts of the world couldn t put money to good use in this sector as well. So what I seek for is a small charity who operates in a niche and to whom regular donations, even if small, make a difference. EuroNatur looks promising. I d love to have more choice though. If you know of any, please let me know. NP: Barclay James Harvest: Eyes of the Universe Update: Micah Anderson pointed me to the Rainforest Action Network and Ron Lee introduced me to the Sea Shepherd Conservation Society, started by Greenpeace co-founder Paul Watson, who resigned from the Greenpeace Foundation (in 1977) because of disagreements with the emerging bureaucratic structure of the organization . I have contacted both and asked for their annual reports and whether they have experience with tax-deductible donations from Central Europe. Update: Karen O Sullivan suggests the Jane Goodall Institute and the International Fund for Animal Welfare. I ve written to them as well.

In an effort to improve the performance of nbd-server, I wrote a patch to make it use some common sendfile() implementations (specifically, Linux- and FreeBSD-style sendfile calls). Unfortunately, however, when I test the Linux version (I haven't done tests with the FreeBSD version yet), the server outputs some garbage in fron of the actual data that it needs to send; as a result, obviously the client can't make heads or tails of it, and the connection is dropped. However, when I run it inside gdb, everything is fine. When I call strace over the server, I don't see any obvious errors. I tried using the DODBG version of the server (see the code for details), but that didn't help me. At this point, I'm pretty clueless as to what is going on. If anyone were to give me some hints or pointers, I would be eternally grateful.

Still putting most all of my brain and time in to trying to graduate. This has left me shockingly little time for things like working on Debian.

Part of the reason why I haven't been working on more visible things (X, Debian) is that I haven't had the solid blocks of time to devote to reading email. I think I need to unsubscribe from all but two or three lists so I don't end up paralyzed by the email onslaught the way I am now. I need to get back to slinging code.

My iPod completely crapped out on me a week and a half ago. I plug it in to my computer and it's totally dead. It was only a little over a year old. Massive fail. Fuck you Apple. I've purchased a 4GB Cowon U3 which plays oggs natively and explicitly "supports" linux. We'll see how that goes, but after one day of use I'm pretty happy.

The entry of Squeak in to Debian and my own realization that GNU Smalltalk exists for those of us who might not want to live inside the smalltalk environment has prompted me to look at the language for the first time. A half hour a night (about a third of the time it takes me to read my email on a very good night) has only made me more excited about this language. If you haven't taken a serious look at Smalltalk yet, it's worth your while. It's like all sorts of things that we can approximate and dream about not only are a reality, but they were invented back in the 70's and have been here all along. It's made me seriously question some of the directions that Linux and Debian have gone in.

Something I always forget where it’s written in (sshd(8)), but which is pretty useful when you have a cluster setup where heartbeat manages failover and stuff. And you want to use ssh to connect to the cluster. Whenever heartbeat switches the cluster-ip to the second machine and you try to ssh to it, ssh will reply with a nice WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! - which isn’t helpful. But SSH knows how to deal with it, the user just needs to tell it about that. Imagine you have the two machines foo1 AKA 192.168.1.1 and foo2 AKA 192.168.1.2 and the clustername foo AKA 192.168.1.10. Adding the following to your .ssh/known_hosts will keep your ssh happy if you ssh foo, no matter on which machine the cluster-ip is:

foo1,foo,192.168.1.1,192.168.1.10 ssh-rsa AAAAB3Nsomething[...]
foo2,foo,192.168.1.2,192.168.1.10 ssh-rsa AAAAB3Nsomethingelse[...]

Most people know that you can run commands "in the background" on UNIX by prefixing them with "nice":

nice run_long_script.sh

What that does of course is reduce the priority of the process so that the CPU scheduler only runs it when nothing else (of a higher priority) wants to run. What it doesn't do however is run the process without any impact whatsoever on your other tasks. The reason is that the background process can still ruin the performance of your computer by monopolizing the hard disk.

It turns out that Linux 2.6.13 or later (with the CFQ scheduler) support a tool called ionice which is a "nice" command for I/O operations (like disk accesses). It works like this:

ionice -c3 command

The only problem is that you can only reduce the IO priority of a process as root. The reason being that if you're not careful you could have a high priority (CPU priority that is) IO-blocked by a lower-priority process.

But if you run your compilation like this:

sudo ionice -c3 make

it will run the whole thing as root, which is probably not what you want. So you could do something like:

sudo ionice -c3 sudo -u myusername make

to run the compilation as yourself. Though one problem persists: sudo strips out your environment. So things like distcc and ccache may not work anymore.

Here's how I solved these problems in my background compilation script for custom kernel Debian packages:

#!/bin/bash
nice fakeroot make-kpkg --revision=custom.1.0 kernel_image &
BACKGROUND_BUILD=$!
sudo ionice -c3 -p $BACKGROUND_BUILD
wait $BACKGROUND_BUILD exit 1

Italian National Anthem Christian mentions that he likes the Italian National Anthem, although not the words. No Italian in their right mind likes the words; luckily we are generally not forced to learn them, so we can allow ourselves to not give a damn about it. Which is our general strategy to deal with all the insanity we get every day. What's the point of a nationalist anthem anyway, when the people who care most about the country are wishing for the Germans to invade us? Anyway, here's my attempt at national anthem lyrics that suck less, for the benefit of those, like Christian, who like the music but not the words.

Fratelli d'Italia
L'Italia s' desta,
Chi cazzo sto Scipio
Che ci han messo in testa.
Non c' la Vittoria
che porge la chioma,
Siam schiavi di Roma
E del Vatican.
Scongiuri alla sorte
Si rischia la morte
Si spera di no.
Noi siamo da secoli
Calpesti, derisi,
Perch siam mafiosi
ladroni e collusi.
Si rischia di nuovo
di aver Berluscone
Dell'emigrazione
Gi l'ora suon .
Scongiuri alla sorte
Si rischia la morte
Si spera di no.
Uniamoci, amiamoci,
l'unione, e l'amore
Ridanno alla gente
Il suo buonumore;
Giuriamo far sesso
sul suolo nat o:
Chiaviamo, perd o,
Chi dice di no?
Scongiuri alla sorte
Si rischia la morte
Si spera di no.
Dall'Alpi a Sicilia
Noi ti condoniamo,
Ogn'uom di Bettino
Ha il core, ha la mano,
I bimbi d'Italia
Fan calcio balilla,
Bastardo chi frulla
Gancin non si pu .
Scongiuri alla sorte
Si rischia la morte
Si spera di no.
I nostri politici
Son tutti venduti:
Si sente dall'Austria
L'odor dei rifiuti.
Lavora in Italia,
Il nero, il Polacco,
In nero, perbacco,
Io lo pagher .

Scongiuri alla sorte
Si rischia la morte
Si spera di no.

(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.....

The interface was subtly broken for quite some time, because of a broken w-b synchronization script. It's fixed again, so those who stopped using it because it lagged for months can use it again, and know that I'm the one to prod if it's broken. Also, a nice unknown feature is that if you want the state of $package in experimental, the following alias DWYM^[1]:

 http://experimental.debian.net/$package

While working on an stlport4.6 still not done ldbl128 transition (430305) I got bitten by 434691. Of course, as stlport4.6 is a dead beast, only used by Debian's OOo (upstream uses an internal 4.5 tree), no patch exists yet. And Ubuntu didn't noticed the breakage yet either. So I'm with this on my hands: g++-4.1 builds fine:

 artemis# g++-4.1 -fdiagnostics-show-option -pthread -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -frtti -O2 -fPIC complex.cpp -c -o ../lib/obj/GCC/ReleaseD/complex.o

g++-4.2 and g++-4.3 don't:

 artemis# g++-4.2 -pthread -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -frtti -O2 -fPIC complex.cpp -c -o ../lib/obj/GCC/ReleaseD/complex.o
 complex.cpp:27: error: 'float _STL::abs(const _STL::complex<float>&)' is not declared in '_STL'
 complex.cpp:32: error: 'double _STL::abs(const _STL::complex<double>&)' is not declared in '_STL'
 complex.cpp:39: error: 'long double _STL::abs(const _STL::complex<long double>&)' is not declared in '_STL'

 artemis# g++-4.3 -pthread -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -frtti -O2 -fPIC complex.cpp -c -o ../lib/obj/GCC/ReleaseD/complex.o 
 complex.cpp:27: error: 'float _STL::abs(const _STL::complex<float>&)' is not declared in '_STL'
 complex.cpp:32: error: 'double _STL::abs(const _STL::complex<double>&)' is not declared in '_STL'
 complex.cpp:39: error: 'long double _STL::abs(const _STL::complex<long double>&)' is not declared in '_STL'

Help for this particular problem would be much appreciated, because I see absolutely nothing wrong in that code (with my limited C++ skills I shall say). EDIT: seems like I found the issue with a lot of luck, some using .... crack was causing the issue. So all in all, I fixed two RC bugs today even if I have to delay the NMU because of OOo-related transitions for a while.

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?

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!)

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 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.