Ick.
So I caught some sort of cold/flu thing, which inverted my sleep schedule (especially since it happened as daylight hours began ending around 5PM). In the process of rotating it back I got sick again, probably due to lack of sleep. Last night I didn’t sleep at all, so hopefully I can pass out around 10PM tonight without a problem. Quod Libet 0.15
Released (and uploaded to Debian), featuring all the aforementioned speedups (SVN actually has even more yet, and some significant memory reductions). We are polishing everything up (and working on the audio feed browser (feedparser is seriously hot)) for 1.0. It’s all very cool. Well, except the times GStreamer segfaults; that’s not so cool. Geeky Jokes
In a lecture on quantifier semantics, my NLP professor made the comment “In America, a b F(a, b). In my country, b a F(a, b).” Much of the class laughed. Speaking of NLP, my final project for that class is likely to segue into the next thing gesten and I tackle, assuming I have any free time at all next semester. Books
I haven’t spent money on books in almost two months (aside from textbooks). This means the amount of books I own and haven’t read is actually for the first time in about a decade. Soon maybe I’ll even be able to go back and reread the books I read when I was 12 but don’t remember very well (ruining precious childhood memories in the process). Python Optimizations
Just because all my posts have had one of these lately, two recent things that surprised me: if s[:1] == c: is slightly faster than if s and s[0] == c:. And if v: is slightly faster than if v is not None: if v could be 0, “”, or (), the false immutables (this one surprised me less after some thought, but it’s still easy to forget when is is otherwise faster).

… and for now, it’s 1.5rc2 that got in experimental. I made some changes to the firefox wrapper script so that it should be quicker to launch firefox in most cases. We don’t try to find the JVM version, since the ones we wanted to set LD_ASSUME_KERNEL for have been ABI incompatible for a while, and we don’t remove the XUL.mfasl and other problematic files since it is now correctly (I hope) by firefox itself. And if bugs arise again, we’ll try to fix in upstream code, not in wrapper script… I also fixed the dash bug and another one in xpidl. For what it’s worth, I did some testing with JVMs and firefox. I got success with

• Sun JRE 1.5update5,
• Sun 1.4.2_10,
• IBM 1.4.2SR3 (but not with java-package, see bug #338277),
• Blackdown 1.4.2-02 and 1.4.1-01.

On the other hand,

• IBM 1.3.1SR8 segfaults,
• Blackdown 1.3.1+02a and 1.3.0-FCS are built against libxpcom.so with older C++ ABI, so ld can’t find __vt_17nsGetServiceByCID,
• Sun 1.3.1_10 can’t load libstdc++-libc6.1-1.so.2.

I try hard not to hate Redhat, I really do. I don't visibly grimace when someone says "I'm running $REDHAT_DERIVED_DISTRO", and my first solution to "I can't get this to work on $REDHAT_DERIVED_DISTRO" is almost never "just install Debian,Ubuntu ". But Redhat makes it so hard to not beat them with a stick. For instance, I'm working on building a SOE for a client, and so I've got a bunch of scripts (calling random poorly documented and hard-to-find utilities) to help me do that. Naturally, I'm pruning the package list, which requires me to rebuild the list of packages which are on the CD. No problems, I can handle that. Oh, but the tool that builds the package list can't deal with the correct "ordering" of packages in the list. Why is ordering important? Because, and this will make you laugh, the installer can't actually deal with dependencies. Yes, that's right, anaconda will install your packages in any old order you specify, regardless of what is actually needed. Brain-damaged, certainly, but I've dealt with Windows, so this is ultimately a minor setback. The tools for building the packages lists are in a certain package, which I dutifully install. They then proceed to fail horribly. Why, do you ask? Because the script requires python modules from another package. Gee, wouldn't be handy if there was a mechanism by which a package could specify that it needed another package to operate? OH WAIT, THERE IS -- IT'S CALLED DEPENDENCIES, FOR $DEITY'S SAKE! YOU WROTE THE GODDAMN RPM SPECIFICATION, REDHAT, WHY CAN'T YOU ACTUALLY USE SOME OF IT'S FRIGGING FEATURES! But wait, there's more! Installing the package which contains the module doesn't actually make the module accessable to anything else on the system, because the module is installed in some god-forsaken, out of the way location, where Python fears to tread. You need to specify PYTHONPATH to make it work. Apparently someone was sure that specifying absolute paths in scripts (instead of letting the system search it's environment) was a bad idea, but didn't have problem with not putting modules in standard, well-known locations. Then, of course, the (other) tool segfaults. Why? Because it's reading an empty file. Wow. An empty file causes this thing to fall over in a screaming heap. Not "Sorry bub, but your file's empty" just an unceremonious segfault. Wow. Thanks. And that's even before we get around to actually doing an install...

Yes, I know that number by heart now. It's not a silly number, it's a bug. A grave bug on binutils which I opened, since the current version of binutils in unstable is, well, rather broken. I spent today tracking it down, and I found it. I must say I didn't expect that—I know next to nothing about the ELF file format, and even less about the binutils internals, so... But anyway, this is what I did:

• I compiled a simple application with a broken binutils installed, and ran it inside gdb. It of course segfaulted before it even reached main(), but that was expected. The interesting bit of information was where it segfaulted.
• With objdump -D, I checked where that was. Turned out it was in some obscure section called '<.plt>', which I had never heard of before; as I found out, that is the "Procedure Linkage Table"—whatever that may mean.
• I then compiled the same application against a known good binutils, and compared. The result of that comparison can be found in the bug log (which I linked to above); anyhow, there was a difference in one of the opcodes. The result of that was that rather than jumping to some bit inside the application (at 0x8000267c), it would jump to address 28b6.
  That can't be right, of course.
• The issue was now to find out what the relevant change was. Running debdiff over the sources of both packages produced a 30M diff, so going through that would've been a little too cumbersome.
  IRC to the rescue.
  P2 told me that the code responsible for the PLT was to be found in libbfd, and that I should look at the source files in the directory for that file. Looking at the diff, I found that the file bfd/elf32-m68k.c had seen quite a lot of changes relating to ColdFire V4E support. The ColdFire V4E is a processor of which the instruction set is based on the m68k instruction set, and it should technically be possible to produce an ABI that will run on both systems, though Debian doesn't support it yet; however, it appeared that the relocation code which was added in support of the V4E was broken somehow—after reviewing patches for a few hours, I finally stumbled upon revision 1.74, of which the commit log says Add support for generating PLT lookups for the ColdFire. Which is so closely related that it can't be a coincidence. I built me a new cross-binutils based on the most recent source package but with that revision reversed, and tested, which seemed to succeed. Now I'm double-checking by building a native version, which might take a while; but I expect that one to work, too.

I'm pretty excited about this, both because we've had this bug for almost two months now (and we really needed to get rid of it) and because it's actually the first time I track down a bug in anything toolchain-related. This is nice.

I've just packaged a newer version of python-django, if anyone is using these beware that the admin section has undergone a non backwards compatible change since the last package, details can be found from the django backwards incompatible changes page on the django wiki. sources.list lines are: deb http://www.sommitrealweird.co.uk/debian/ (sid sarge) django deb-src http://www.sommitrealweird.co.uk/debian/ (sid sarge) django and are available for i386 and amd64. The package still needs some work (various bits of config really shouldn't be where they are), but I expect to do that sometime before the release (we still haven't got an official django release). I should be working my way through the xmms-scrobbler bugs at some point this weekend, I hope... the tag reading is still quite bad, and does still segfault on badly formatted tags which is what really needs fixing. Anyways - back to it.