Glitches in the Matrix ] Korean car with Taiwanese license plate (edited to anonymise it) over EU license plate with (Portuguese??) numbers on the right, and Korea as country code. Italian pasta sold by a British supermarket, in Taiwan. Also, "Messicani" is not a kind of Italian pasta. Google for it, and you'll only find it mentioned in British websites.

I've spent a lot of hours over the weekend stripping out markup on my personal website, so that I can regenerate it from a templating system. My template-compiler is horribly hacky, but it produces reasonably good results from simple input files. The only motivation for this was to finally transition my site to a consistant layout, and allow me to easily change the layout again in the future. I looked over WML, htmlpp, and a few other static web-compilers before writing my own tiny processor. I guess most of them are more powerful than mine, but similarly more complex to get started with. I'll share the code if there is any interest. (Primarily it is template expansion of a body, optional per-page menus, and per-page HTML header inclusion.) The only significant thing that has changed in my website is a tiny RSS feed of updates (also compiled!) and the removal of many sections from the top-level menu. (For example my body piercing section has been obsolete for years. It is still present, but I see no point in advertising it. Better resources exist.. The plus side is that I've managed to do all this whilst watching "Dead Like Me" over the Easter weekend. Both series from start to finish. Good show.. Obquote: 10 Things I Hate About You

In June last year, I bought a TomTom GPS device. Their use of Linux on the device was a clear plus in their favour, but it was only that, given that overall they’re the best devices available. Unfortunately, the TomTom HOME software that is needed to manage the device is not as good as the device itself. An account on their website is needed for updates and the online shop, and as I usually do, I used an email address in the form jb+something@jblache.org. That’s a trick most of us use to trace back the origin of spam, usually revealing that some company sold its customer database. I’ve been doing that for years. I was quite happy that the website did not reject the address as being invalid; that’s something that happens everytime the random web developer maintaining the site decides to start “validating” email addresses, for some value of email addresses. For the following 8 months I’ve been using this address as the account login (don’t really have the choice, anyway) with the TomTom HOME software. Last month, the v2 of the said software was finally made available for Mac OS X. Where the v1 used to accept my email address, the v2 would now reject it. You guessed it, Joe Random developer decided to start validating email addresses in TomTom HOME. I reported the regression (and here, something must be said about their infamous support website), with pointers to the relevant RFCs. In the following email ping-pong, they managed to:

• Pretend the password was the problem. I have to say here that the software displays a big red “invalid email address” next to the email address field as soon as I enter the + character. No mistake possible here.
• Send me my login and password, in clear text, when I never asked for that. That also means they’re storing passwords in clear text. IT’S 2008 FOR FUCK’S SAKE! STOP STORING CLEAR TEXT PASSWORDS, DAMMIT.
• Pretend their email platform is the most secure in the world. Ever heard of SSL? TLS? Clearly not.
• Pretend it’s not a regression in the v2 of TomTom HOME. We’re not speaking the same language, it seems.
• Pretend the email address is invalid. No surprise there, but it’s clear they did not bother reading the fucking RFC.

Last but not least, their last reply was: “we found that the standard does not apply to us. Please change your email address for a valid one.” Now, I’m left wondering: does the GPS standard apply to TomTom devices? I truly hope so.

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

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.

One of the challenges maintaining the Debian archive kit (dak) is dealing with Debian-specific requirements: fundamentally because there are a lot of them, and they can get quite hairy – yet at the same time, you want to keep them as separate as possible both so dak can be used elsewhere, and just so you can keep your head around what’s going on. You can always add in hooks, but that tends to make the code even harder to understand, and it doesn’t really achieve much if you hadn’t already added the hook. However, dak’s coded in python, and being an interpreted language with lots of support for introspection, that more or less means there’s already hooks in place just about everywhere. For example, if you don’t like the way some function in some other module/class works, you can always change it (other_module.function = my_better_function). Thus, with some care and a bit of behind the scenes kludging, you can have python load a module from a file specified in dak.conf that can both override functions/variables in existing modules, and be called directly from other modules where you’ve already decided a configurable hook would be a good idea. So, at the moment, as a pretty simple example there’s an init() hook invoked from the main dak.py script, which simply says if userext.init is not None: userext.init(cmdname). But more nifty is the ability to replace functions, simply by writing something like:

# Replace process_unchecked.py's check_signed_by_key
@replace_dak_function("process-unchecked", "check_signed_by_key")
def check_signed_by_key(old_chk_key):
    changes = dak_module.changes
    reject = dak_module.reject
    ...
    old_chk_key()

That’s made possible mostly by the magic of python decorators – the little @-sign basically passes the new check_signed_by_key function to replace_dak_function (or, more accurately, the function replace_dak_function(...) returns), which does the dirty work replacing the function in the real module. To be just a little bit cleverer, it doesn’t replace it with the function we define, but its own function with simply invokes our function with an additional argument to whatever the caller supplied, so we can invoke the original function if we choose (the old_chk_key parameter – the original function takes no arguments, so our function only takes one). Right now, we don’t do much interesting with it; but that should change once Ganneff’s little patch is finished, which should be RSN… Hopefully, this might start making it easier to keep dak maintained in a way that’s useful for non-Debian installs – particularly if we can get to the point where hacking it for Debian generally just implies changing configuration and extension stuff – then we can treat updating all the real scripts as a regular software upgrade, just like it is outside Debian.

Growing up for the most part in the 1980’s, Saturday Night Live was the funniest regularly scheduled part of my week. It’s either gotten less funny over the years, or I’ve changed. Probably both. One of the biggest problems SNL faces is that it must fill ninety minutes every week, although these days if you subtract out ads, music, and other filler/transitional material, I expect it’s only thirty to forty minutes of actual comedy. Either way, a lot of SNL skits go on longer than necessary to deliver their comic payload. I expect this was actually true in the 1980’s as well, but I didn’t notice it so much. Enter The Onion and its video content. Freed from the confines of the television programming schedule, the Onion can make its online video clips just exactly as long as the writers want, and release them on their own schedule. In recent months, they’ve been batting in the high 800s. E.g., Diebold Accidentally Leaks Results of 2008 Election Early (on a serious note, see Ed Felten’s recent Sequoia discovery and followup); Army Holds Annual ‘Bring Your Daughter to War’ Day. Or any of them, really.
White House Press Secretary Spins Wife’s Tragic Death As A Positive
Army Holds Annual ‘Bring Your Daughter To War’ Day My only complaint about The Onion video content is that they have only one sponsor at any given time, and they make you watch the same exact ad (both as a short pre-mercial and a longer post-mercial) every time you watch a video. The repetition isn’t effective and I can’t imagine it’s the best use of the Onion’s advertising revenue. I suggest at least rotation ads — or better yet, only forcing an ad on the viewer after every nth video. Thanks to Steve and Flour for the key insight about clip-length. Technorati Tags: The Onion, Saturday Night Live

Share This

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!

I still can’t get the hang of RSS feed aggregators. There is something about the Google reader’s uniformity that I find unsettling. Block after block of text all neatly laid out. But… it is really useful to keep track of those feeds that aren’t listed on the the planets like Random Acts of Reality, MySociety and Cook (almost) Anything at Least Once. So, I was cheered up no end to discover they have a “Next” bookmarklet. Once added to your toolbar or whatever this lets you go to your next unread post in the page where the post comes from. Yay, no more uniformity, yay, personal expression. Oh, but everyone is using Kubrick.

I just read an interesting blog post about Montenegro [1]. Apparently a key to the process of becoming a country was acting like it was inevitable. It seems that this method can be applied to many areas, one of which is the contest between Linux and some proprietary OSs. For many years monopolists have convinced people that it was inevitable that they would monopolise all areas of software development. Why use any other software (even if it is more reliable, faster, has more features, and is cheaper) if a monopolist is about to dominate the market? The monopolist changes sometimes, the monopolist from ~1990 to now is different from the monopolist of the 1970’s, but the tactics of a computer monopolist remain the same. The way to beat this is largely to just ignore them. There is an ongoing debate in some circles about when Linux will be “ready for the desktop“. I’ve been running Linux as my primary desktop environment since about July 1998, it’s almost 10 years of having Linux as my primary desktop environment. It seems inevitable that the Linux will take over the desktop - it’s far better for desktop use than it was 10 years ago when I switched. Some people claim that Linux lacks driver support. Every piece of hardware that I’ve wanted to use over the last 10 years has had adequate support. Often second-hand hardware works best with Linux, hardware vendors have no reason to continue to support their old products on newer operating systems (they make more money if you buy new hardware to run the new OS). Not only is hardware support for Linux adequate, but long-term support is far superior (and I often get to use cheap second-hand hardware). Now that an increasing number of hardware vendors are supporting Linux for their new hardware (Intel, AMD, and most laptop vendors are doing some good work in this regard). It seems that everyone who has tried both says that writing drivers for Linux is easier than writing drivers for proprietary OSs, so it seems inevitable that Linux will end up with better driver support by all metrics. Linux is designed for users. DRM (Digital Restrictions Management) is not something that interests Linux developers. Run Linux and your computer will obey you and give full quality audio and video. It seems inevitable that Linux will dominate the AV section of the market (it already dominates the computer work involved with creating movies). Free software (of which Linux is merely the most famous and popular example) is based on the principles of open design and open standards. When you use a free software program to save a file then you can be reasonably sure that you will be able to read it back again in a few decades. Most free software uses file formats that are well documented and standardised. Sometimes there are bugs in programs and new versions will use files in a different way, this is sometimes a case when you rely on a bug in an old version. Using the older version of the software is sometimes required to properly access old data. Fortunately when you have the source to the older programs they can be compiled on new systems (so different types of CPU won’t matter). Also the lack of DRM means that an OS image can be virtualised. One thing that is on my todo list is to create a set of virtual machine images of some of the most commonly used distributions of Linux so I can easily compare distributions of 10 years ago with modern distributions - it’s not technically challenging and there is no particular technical or legal obstacle to doing this. This would also mean that if someone gave me a file in some strange format from 10 years ago I would have a better chance of reading it. It seems inevitable that as the value of data increases the desire to avoid OSs that prevent people from accessing their own data will also increase, and that will eventually squeeze out most closed software from the market. This doesn’t mean the end of proprietary software, merely the end of software that holds user’s data hostage. The majority of the world’s population does not use computers. The computers that they end up using will be cheap because they can’t afford to waste so much money on new hardware. To make cheap machines means that there will be limited resources in terms of RAM, mass storage, and CPU power which require more efficient software. Also to properly take advantage of machines with small screens and other limitations changes to the design of the software will be required. It seems inevitable that the most open software will be adapted to such environments more readily than proprietary software. Now this doesn’t mean that we can take a break from development. In the free software community there are usually many different programs to perform a particular task with competition between the developers of the various projects. The fact that a monopolist is inevitably going to lose it’s position is of little relevance to the competition between the various free alternatives.

• [1] http://www.airs.com/blog/archives/115

Share This

I am just watching US Senator Barack Obama speaking at Google about his bid to become the next US president [1]. He has announced plans for allowing greater citizen oversight of the government including having all government data in open file formats (a great idea - the Australian Bureau of Statistics has a large amount of data online in Excel format). But his most significant item so far is to have a National CTO (Chief Technology Officer). It’s an idea that seems totally obvious now that I’ve heard it and leaves me wondering why I never thought of it before! Barack understand technology, wants a functioning democracy, and gets a +5 Insightful from me for the CTO idea! He also announced a plan to double federal funding for basic scientific research as part of a measure to make the US more competitive with other countries. He mentioned the US standing in the world as a problem (it’s the first mention of this that I’ve heard from anyone in the US government) and notes this as an issue which limits the ability of the US to save lives in regions such as the Darfur. He also claims that there is no clash of civilisations and cites his experience living in a Muslim country as helping to build bridges. When discussing his reasons for running he said that he believes that he can bring his country together to solve problems better than other candidates. That’s the type of thing you often hear and ignore in political campaigns. It is often difficult to believe that someone wants to be famous and powerful for anything other than the most selfish reasons. But Barack gives me the strong impression that he is genuine. He stated a plan to shut down Guantanamo bay (presumably just the prison and torture aspect - I’m guessing that he is not intending to close the military base) and to stop “rendition” (sending prisoners to other countries to be tortured). His plans for education are innovative, as part of educating young children (0-3 years old) he stated an aim to teach parents to read so that they can read to their children! It’s sensible and obvious once you have heard it, but no-one seems to have publicised that idea before. He announced that he will increase teachers’ salaries. He describes the US as having an “empathy deficit“, it’s obvious to almost everyone outside the US but not something that many people in the US realise. He wants decisions to be based on facts and is determined to use facts when dealing with health insurance companies. I just wish that we had some politicians like him in Australia. In terms of policy the Greens politicians would agree with him, but the combination of great policies, insight, and excellent delivery seems a lot better than any of the options in Australia. Update: Changed the post (including the permalink) to have the correct spelling of Barack. Mental note - double check the spelling of everything in the permalink.

• [1] http://au.youtube.com/watch?v=m4yVlPqeZwo

Share This

I am just watching US Senator Barak Obama speaking at Google about his bid to become the next US president [1]. He has announced plans for allowing greater citizen oversight of the government including having all government data in open file formats (a great idea - the Australian Bureau of Statistics has a large amount of data online in Excel format). But his most significant item so far is to have a National CTO (Chief Technology Officer). It’s an idea that seems totally obvious now that I’ve heard it and leaves me wondering why I never thought of it before! Barak understand technology, wants a functioning democracy, and gets a +5 Insightful from me for the CTO idea! He also announced a plan to double federal funding for basic scientific research as part of a measure to make the US more competitive with other countries. He mentioned the US standing in the world as a problem (it’s the first mention of this that I’ve heard from anyone in the US government) and notes this as an issue which limits the ability of the US to save lives in regions such as the Darfur. He also claims that there is no clash of civilisations and cites his experience living in a Muslim country as helping to build bridges. When discussing his reasons for running he said that he believes that he can bring his country together to solve problems better than other candidates. That’s the type of thing you often hear and ignore in political campaigns. It is often difficult to believe that someone wants to be famous and powerful for anything other than the most selfish reasons. But Barak gives me the strong impression that he is genuine. He stated a plan to shut down Guantanamo bay (presumably just the prison and torture aspect - I’m guessing that he is not intending to close the military base) and to stop “rendition” (sending prisoners to other countries to be tortured). His plans for education are innovative, as part of educating young children (0-3 years old) he stated an aim to teach parents to read so that they can read to their children! It’s sensible and obvious once you have heard it, but no-one seems to have publicised that idea before. He announced that he will increase teachers’ salaries. He describes the US as having an “empathy deficit“, it’s obvious to almost everyone outside the US but not something that many people in the US realise. He wants decisions to be based on facts and is determined to use facts when dealing with health insurance companies. I just wish that we had some politicians like him in Australia. In terms of policy the Greens politicians would agree with him, but the combination of great policies, insight, and excellent delivery seems a lot better than any of the options in Australia.

• [1] http://au.youtube.com/watch?v=m4yVlPqeZwo

Share This

Unsurprisingly, there is a deal of common ground between a SQLite backend and a GDA backend. Both need simple routines that convert library data into SQL statements but each has very different ways of reading that data back from storage.
I've spent today doing upstream work (whilst also getting my central heating system replaced). Gutted the house, gutted the library - what's wrong with that?
However, I've decided to make these new functions private to the library rather than exporting them. Simple reason really - they are one-way routines.
One day, QOF will support UPDATE statements and one day a bit later it will also support DELETE and even DROP but those require changes within the library like "unregistering" objects that the current code simply doesn't expect.
Eventually, this kind of SQL support can make a usable query interface for quicklist and a few other stalled projects (like DWI). The principle gain is to allow QOF objects to evolve and adapt but retaining compatibility will be a challenge. (QuickList is likely to only support a read-only mode for some objects and require that others are renamed before being amended.)
The other advantage of this refactoring is that the SQLite backend in libqof2 will be a lot smaller than before. Migrating the code hasn't increased the size of libqof2 either because so much deprecated code has been removed when bumping the SONAME.
I'm sticking with the roadmap of not looking to release libqof2 until after Lenny but that gives me plenty of time for internal reworking to get the GDA backend functional.
So far, I have been able to create a test GDA data source, add a table and data, delete the data and drop the data source. Not bad! (I test with SQLite but XML, MySQL, PostgreSQL and other ODBC connections are supported by GDA without changes to the QOF code.)
As ever, implementing new functionality needs a new test case so that has also been started - only 20 tests so far but worth doing.
Other changes before libqof2 - at the request of the original developer - will include updating QOF-Generator to work with libqof2, updating the old HTML example pages to provide a "QuickStart Guide" and other introductory documentation. Whilst I'm doing that, I'll probably also work on the Emdebian website documentation that also needs improved coordination.
Also note that pilot-qof and gpe-expenses are already libqof2 compatible. All that will be needed is some way for those to provide the username and password variables that some GDA connections would need. (The QOF GDA code already has support for such settings, it just needs to be implemented in the respective frontends.)
First set of changes are now in QOF CVS.
(Yes, CVS - I just don't see the appeal of all those new-fangled RCS versions - subversion is about as "modern" as I need. I just don't need the hassle that comes from git fanboys (or any of the other RCS versions) - nor do I need the hassle of migrating CVS to SVN.)
What I would say is that of the various SVN WWW interfaces, websvn stinks, view svn is a bit better but the only one I really like is Trac. For a single large project, Trac is much more friendly IMHO.

finally, after waiting for some years, we now get the profil delivered directly to our doorstep on sunday mornings too, instead of stuffed into the mailbox on monday by the regular postal service. it started two or three weeks ago, but today was the first sunday where I actually managed to take my time to read it on the first possible day.

spending two hours in the bathtub with a news magazine that is officially released only tomorrow is a good break between Java packages before & Perl packages afterwards.

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

Because my diploma exams are getting nearer, I have to reduce my contribution to the Debian project for the next two months (up to mid/end of May). There is fortunately currently not much to do for me and also no need to NMU my packages. But please read the following notes, if you (still) think there is a reason for a NMU: GCC 4.3 transition Done. All related packages have been fixed. My sponsor just needs to upload psicode to fix the last outstanding bug. PS: Also the build-twice-in-a-row release goal will be reached by the upload of the apbs update by my sponsor. gfortran transition Almost done. mpqc already reached the buildds. ghemical has been uploaded, but waits for mopac7 and libghemical, which are in NEW because of the new library names. apbs and psicode already have been transitioned. Other bugs Ok, I’ve closed almost all relevant bugs in my packages. There are a few outstanding bugs that should be examined for Lenny and can be fixed in NMUs - preferable via delayed NMU queue and an information to the debichem group:

#420795: chemical-mime-data: Unknown media type in type ‘chemical/x-*’

Upstream bug tracker for shared-mime-info contains some more information, how to deal with this. Patches/ideas welcome.

#438694: gabedit: Crashes when loading any XYZ format file

Looks tricky. Maybe an OpenGL issue related to some video card drivers. Not sure.

#442223: openbabel: some connect information lost when convert from pdb to txyz

Nothing examined yet to solve this bug.

#464867: extrema: conflicts with psi3 package

Hope, my team will cover this asap.

#465723: mopac7 — please do not use g2c.

There is currently a workaround using f2c to solve this bug. But MOPAC7 has been written in FORTRAN and we can use gfortran and drop f2c completely. See the report for more information. This is something I would like to see in Lenny.

For the xmlto package it was planned to add the dblatex toolchain for PDF/PS/DVI creation because passivetex will very probably never have a comeback in Debian and docbook-xsl/fop is not fully main and cannot create DVI output. In the case you want to help, feel free to add this feature by NMU to experimental (maybe with version 0.0.21~dblatexX.Y). A first patch is available in bug report #416622. New upstream releases It is possible that there will be a new upstream release for docbook-xsl in the near future. DO NOT consider uploading it by NMU if you did not test it! This upcoming release ships manpage stylesheets, that have been rewritten in large parts. So regressions can be expected. Fortunately Michael Smith and me agreed, that we should test it carefully, before the release is done. Unfortunately I will not have the time to do it. So if you consider uploading it, please get in contact with Michael (xmldoc) and offer your help testing it. He added (and I hope, many Debian packagers and packaging groups will like that) some kind of regressions tests. These tests build the manpages from several Debian packages: e.g. samba, apt, aptitude, git, fglrx and some more. There are further some new supported features, that should be added to the manpage example shipped with the Debian package. I also planned to split the source package (atm, docbook-xsl and docbook-xsl-doc tarballs are merged together for Debian) as soon as docbook-xsl-ns is packaged - which I wanted to do with the next upstream release. So consider all of the above notes if you plan an NMU to upload a new upstream release and in question, mail me and wait for my answer (which will need some days). In all other cases, new upstream releases should be easier to handle. ITPs All my ITPs are delayed. However if you plan to still upload one of these packages, you should consider the following notes:

docbook-xsl-ns

See the above note about docbook-xsl and the source package split.

html-xml-utils

Already in a good shape, but I sent upstream some patches to improve the manpages. Version 4.6 of the html-xml-utils should contain these patches and this version should be uploaded into Debian. With this version, Bert Bos will probably also decide, which prefix will be used for the binaries (they have very generic names atm; the prefix will probably be hx- or hxu-). Waiting for this releaes therefor is IMHO a good choice.

DocBook 5

I already found a problem that need to be addressed in the package: Where to install its catalog? You will see, that there is already a catalog file in /usr/share/xml/docbook/schema/dtd/ shipped by the docbook-xml. Now I’m not sure, what to do here. Upstream ships one catalog file for all supported schemas (RNG, DTD, W3C schema and schematron), so maybe the catalog file can go into /usr/share/xml/docbook/schema/. Really not sure atm. The answer to this question might affect the Debian XML policy and should be made carefully.

QA work/fixes Several lintian warnings have already been fixed in the SVN repositories used for my packages but have not yet been uploaded. I really only plan to reduce my work during the preparation and the exams. So whatever you do, please try to make it easy for me to continue my packaging work after the exams :)

I appear to have underestimated the remaining work needed to get xulrunner in a pleasant enough shape for an upload. Which means the package won’t be ready this week-end. It’s always when you come closer to the goal that it gets farther… And I still haven’t decided once and for all if I would still version the libxul library. The problem is the following: there are two different ways to link or load libxul: dependent glue or standalone glue. The first one dynamically links embedding applications to both libxpcom and libxul, while the second links to a static library (well, dynamic, in Debian, because there is no reason why we should need to binNMU all reverse dependencies whenever we fix something in the glue), which dlload()s libxul. From Mozilla POV, embedding applications are supposed to use the standalone glue. Considering we will more than probably have both schemes in use within reverse dependencies, I’m not sure I still want to bother diverging from upstream by keeping SO versioning on libxpcom and libxul… That unfortunately means that we will go back to the previously sucky situation where reverse dependencies have to put a dependency on the Gecko runtime themselves. A debhelper might help, though. I will keep SO versioning on libmozjs, though, because it has some reverse dependencies, and a changing ABI. The good news, anyways, is that I was able to build and run Iceweasel on top of the xulrunner pre-package. I also ran sunspider on both this Iceweasel 3.0b4 and Iceweasel 2.0 ; the difference is really impressive: 3.0b4 is almost 4 times as fast ! For reference, the Webkit currently in unstable (which is quite old, actually), gives these results. The one in experimental unfortunately crashes. By the way, I’m planning to package a new Webkit snapshot soon after I’m done with xulrunner and Iceweasel, we’ll see then how it performs. While speaking of tests, both Iceweasel 3.0b4 and Webkit from experimental pass the Acid 2 test (contrary to Iceweasel 2.0), and have both quite good results on the Acid 3 test: 61 for Webkit from experimental, when it doesn’t crash (but current trunk has been reported to score 91 !), and 67 for Iceweasel 3.0b4 (compared to 52 for Iceweasel 2.0). Update: Interestingly, built with upstream optimization flags (-Os-freorder-blocks -fno-reorder-functions) instead of -O2, it is slighly slower, though it might be better on some older hardware, or other architectures (I’m testing on x86-64).