I handle bug reports and email communication as soon as possible, but it does not mean that it may take month or even more to get reply. I'm not working full time on my free software projects, I do it only in my free time. Besides this I have regular job and I also have a real life with another hobbies. So if you wrote me something, just try to be patient, sending another emails to urge your issue won't help anybody. I will just have more unread mail to process until I get to real work.

SymPy is a pure Python library for symbolic mathematics. Last year SymPy had 5 excellent students and this year we are accepting students again.
Why should you apply? And why to SymPy?

Well, let me give you some reasons:

• First of all, it's fun. To get some idea, read the GSoC2007 SymPy page, where you can find out what the last year students did and especially read their reports, where they describe their impressions from the summer, how they tackled problems and their overall conclusions.
• It's not just about coding, we enjoy the social part too. There is a great community around numpy, scipy, ipython, matplotlib, Sage and similar tools and if you do scientific computing with Python, you gain a lot just being part of it, because you learn new things from the others.
• I currently live in Prague (most people say it's a beautiful city, but I actually like Los Angeles, or the Bay Area:), if there are enough interested people, we can make a coding sprint here (plus of course some sightseeing+pubs). Anyone with a good commit history is welcome to stay at my apartment. :)
  
• You earn $4500, some of which I suggest to spend on travelling to conferences/workshops, here are some tips: SciPy2008 (see also SciPy2007), EuroSciPy2008, Sage Days (you can read my impressions from SD6 and SD8), watch the numpy/scipy mailinglists for announcement of other meetings.
  

Read also the current status and motivation of SymPy and it's relation to Sage. If you want to apply, all the necessary information is on our wiki page.

Nevertheless, if you decide SymPy is not for you, but still you'd like to do GSoC project in a similar area, there are other good options too - one is SciPy/NumPy, the other is Sage. Unfortunately Sage was not accepted as a mentorship organization, but it has several good projects too, some of which you can do for example under the umbrella of the Python Software Foundation.

One of them is improving the Sage notebook. If you've never seen that - download Sage, start it (./sage), type "notebook()" and a nice Mathematica like notebook will popup in the browser. It allows collaborative editing ala Google Docs and many other things. If you'd like to work on it, reply to the email on sage-devel.

This post is both an attempt at replying to a bug against telepathy-glib, but also an attempt at explaining what Requires.private do (and don't). I am using Evolution as my example here, not to pick on Evolution or its authors in any way, but because it's a convenient example. Currently, on Ubuntu Hardy, evolution links against 75 different libraries. Amongst those, we find libz.so.1, libXinerama.so.1 and many more. I'll go out on a limb here and claim that Evolution does not call any of the functions in libXinerama directly. Let that be the assumption from here on. An obvious question then is, why does evolution link against libXinerama.so.1 if it doesn't use it? To answer that question, we need to go back in time to before we had dynamic linking. If you wanted to build a binary like evolution you had to have 75 -l statements when you linked and you ended up with the whole code for Xinerama embedded in your email and calendar client. For various reasons, we stopped doing that and switched to dynamic linking where the evolution binary just contains a reference to libXinerama. At some point we also grew the ability for libraries to contain those references to other libraries, so you don't have to hunt down all the dependencies of libfoo when you are linking with it. We also got tools such as libtool which try to abstract away a lot of the problems of building on older platforms which don't support inter-library dependencies. Now, since evolution still doesn't use anything directly in libXinerama.so.1 but just uses a library which in turn links against libXinerama.so.1, it shouldn't be linking against it. Then why is it linked with it? Again, we need to look back at history, and for this part I am at least partially responsible. pkg-config was originally written as a replacement for gnome-config and various other -config utilities. Lots of libraries and applications now ship .pc files and we have a standardised interface for querying those files. One of the problems the original authors of pkg-config faced was the problem of dependencies. They added dependencies so the authors of gst-python-0.10 could say "We need pygtk-2.0 too" and so the compilation flags needed for gst-python-0.10 would also include those for pygtk-2.0. Note that I'm using "compilation flags" loosely here, I am not just talking about CFLAGS. This did not fix the problem of inflated dependencies. Not at all. I talked with some of the Debian Release Managers back in 2004/2005 and we worked out a solution which should help us have correct, uninflated dependencies since the then-current way of handling dependencies caused big problems for migrations of packages between unstable and testing. The plan was to introduce a new field, Requires.private which would not show up unless you passed --static to the pkg-config invocation (since you need all libraries if you are linking statically). This definition of Requires.private was mostly useless since GNOME and GTK+ have a habit of including each other's headers. To make a long story short, I changed the semantics so the Cflags field from private dependencies were included even when not linking statically. A problem which pkg-config does nothing to guard against in this case is if you have libfoo.so.2 linking against libbar.so.1 and libfoo.so.2 exports some of libbar's types in its ABI (and not just as pointers, but actual structs and such). If libbar's soname is then bumped to libbar.so.2 and libfoo is rebuilt, libfoo's ABI has changed without a soname bump. This is bad and will cause problems. If your application is linked against both libfoo.so.2 and libbar.so.1, you'll still get problems since libfoo.so.2 then suddenly pulls in symbols from libbar.so.2. If you used symbol versioning, you would at least not get symbol conflicts and your application would continue to work, but you would have a spurious dependency and the package containing libbar.so.1 would be kept around until your application was recompiled. With this background, you might ask the question why we still have Requires since it is seemingly useless. For C, it is useless in all but the most special cases, just use Requires.private instead (and its sibling Libs.private). Other languages have different semantics. Some people use .pc files for other purposes such as gnome-screensaver having variables defining where themes and screensavers go. Hopefully this blog post has explained a bit about why we have Requires.private and what the difference between this and their regular counterpart is. If there's anything unclear, please do not hesitate to contact me.

For years, several important (or not so important) people have forecast the end of email. While most of what they were saying couldn t be disagreed with (important people always speak in vague, vacant terms), it wasn t until about a year ago that I noticed any effects. But over the past twelve months, I found myself frequently having to remind people of tasks, mostly outstanding emails, across the whole spectrum, and including companies who could make money from me if only they d bother replying. Statistics somewhere say that 90% or more of all mail is spam. I have very few problems with spam (and would like to describe my mail filter in a future post, but that ll take time), but I have no problem imagining how most email users out there, who are stuck with technology from the nineties (thanks mostly to Microsoft), are really drowning and thus fail at the basics of correspondence. So what s next? How should we continue to communicate, now that email has been fully embraced by the business world while it has grown to be more of a burden than a gain for the majority? Or is our society simply accumulating more and more slackers? NP: Barclay James Harvest: Time Honoured Ghosts

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.

Martin blogs about how the Camel book mentions the fact that scalars, arrays, and hashes have completely separate namespaces, as if this is a problem. Well, I disagree. As with anything in Perl: yes, obviously it's possible to confuse yourself with this feature, and yes, obviously it's true that if you do this, you will get to keep both pieces of your program. So don't do that then. However, when used properly, I find that it actually helps me improve readability of my programs. Let's say we have a subroutine which returns a reference to a filehandle to a bunch of data in a format that we know how to parse. We don't know what the filehandle points to (and we don't care, either), but we do know what the data is. So we store the filehandle in some scalar, and then proceed to parse the data into a hash. Now we could use variable names such as $fh and %hash, but I'll hope that everyone agrees with me that this is very bad practice. So, instead, we should name the variables after what they contain. Say our data file contains books:

$books = get_books_fh();
while(<$books>)  
	(... parse $author out of $_ ...)
	push @ $books $author , $_;
 

The filehandle to which $books is a reference, points to some useful data; and the %books hash table contains the exact same data, only structured in a different, more useful way. So why give them a different name? They're the same thing, call them the same way. Personally, I find this makes a whole lot of sense. And you can do the same thing with arrays vs hashes, or scalars vs arrays. Of course you can also write code that uses $somevar and @somevar, with no semantic connection between the two. That is stupid, so don't do it. The fact that you can do stupid things with Perl, however, should not mean the language sucks. You see, other than some other programming language I could think about, Perl does not assume its users are stupid, or inexperienced, or dummies, or whatever. Yes, that does mean that new users will get confused; but it also allows experienced users to Get Stuff Done in a proper way. And, well, I'm sure you can do stupid things with python, too.

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.

Programs themselves cannot be patented. They're explanations of mathematical relationships, not inventions. Paul Russell mentioned this ruling to me and Alex Hudson mentioned it to fsfe-uk. There's been some BBC coverage and very silly coverage in Computing which summarises it as as

"Symbian's win could benefit UK software makers"

You what? Shouldn't we be enabling other UK companies to compete in a free market with Symbian, which is a consortium of foreign companies after all, instead of granting Symbian a monopoly here? *fume*

This is fairly obvious in theory, but it’s the kind of thing you don’t always think about: when receiving patches via e-mail, it’s possible to have Mutt directly color them as vim or colordiff(1) does. I have this:

  % grep rc_diff ~/.muttrc
  macro   index   \e,sd   ":source ~/.mutt/rc_diff\n" "source ~/.mutt/rc_diff"
  macro   pager   \e,sd   ":source ~/.mutt/rc_diff\n" "source ~/.mutt/rc_diff"
  % cat ~/.mutt/rc_diff
  color body brightblue default   '^\+.*'
  color body brightred default    '^-.*'
  color body brightgreen default  '^(--- \+\+\+) .*'
  color body brightyellow default '^@@ .*'

Update: In case there was some confusion, the rc_diff snippet above is meant to be sourced only when there’s a mail with a patch, otherwise it’ll highlight parts of normail email too. The way to disable again, though, is quitting Mutt...

(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 guess i'm boring but... at Rob Bradford's Weblog - I'd find an alterslash-style Skip link more useful than the recently-added "Hide Author" links on planet.debian. Also, why does google put that in a bookmarklet instead of using a simple link?
• Debian, and other stuff Trying to launch emacs only when needed - can emacsclient run elisp? It would be really useful to be able to remote-control Emacs like that.
• Bubulle's weblog: F1 and anthems - at least France has an anthem... England doesn't. The slightly-religious/King-supported/used-at-cricket/Labour-linked Jerusalem and pretty-aggressive/Conservative-linked Land of Hope and Glory are often used, but aren't official.
• Write a new license, every day - Ganneff's Little Blog - this is why I was scared SPI might create a new licence for the debian logo by accident, instead of using the MIT/Expat one requested.

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.

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

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

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

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

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

The map of psytrance Thank you Anoebis !

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've been thinking that something that might help a wider adoption of the machine-readable copyright format is a proper emacs major mode for it. Well, at least, it does for me... So I started to write one. It is loosely based on debian-control-mode, although there is hardly any code left from it now. It only features syntax highlighting for now (including warning for licenses which were not on the wiki page at the time of the writing, or were marked as needing more discussions) but, after all, this is only my first emacs major mode... The code can either be downloaded there, or from my bzr repository, in the debian-mr-copyright-mode directory

bzr branch http://people.debian.org/~fourmond/bzr/scripts

No debian package for that for now, as anyways it really should integrate dpkg-dev when it has matured somehow. Hope this helps !

pianofiles.com, a sheet music exchange site which I had mentioned two years ago, has gotten a nice facelift. It used to be very slow and neither very pretty nor convenient. Most of these shortcomings have now been corrected. It's a great place to look particularly for modern tunes which, unlike classical works (which are usually public domain anyway), do not have a canonical version, but heaps of arrangements and transcriptions of live performances. Quality of course varies, but point is that you can get your hands on many versions and compare them. Typical latency of requests is about a day. For example, just yesterday I fired off a few emails, and today I have got three versions of "Nardis" by Bill Evans. Feel free to ask for any sheets I've got.

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?

Since the last post, I have significantly improved debian-mr-copyright-mode, that now provides an interactive function, debian-mr-copyright-scan-files that shows which files are covered by which clause of the debian/copyright file. I've also significantly improved my understanding of font lock and emacs lisp in general... As a demonstration, the attached picture represents the results of debian-mr-copyright-scan-files on the monsterz source package (Sam's original example). The output clearly shows that some files are not covered yet... You can get the emacs mode there. Its is starting to be good, but of course, many more improvements are still planned - in particular, quotes for files probably don't work yet. By the way, imenu now works. A debian package should probably come soon.

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.