software

A month or two ago, I installed Etch/amd64 on a HP system which uses the ATI SB400 chipset. It worked great mostly, but sound was choppy from the start.
I decided this week to investigate and quickly discovered that oss emulation on this chipset is giving most people issues. It turns out the solution, for a GNOME desktop, is really simple: remove the libesd0 package and install libesd-alsa0 instead, so that esd does not use OSS emulation.

Which begs the question, could the Debian installation system be made smarter so that systems using ALSA drivers wouldn't use OSS unless for applications that only support the latter?

Today I discovered a very useful and nearly undocumented Openswan configuration parameter, which goes by the name of leftsourceip (and symmetrically rightsourceip). What it does is telling the Linux Openswan VPN gateway what address to send traffic from, which it generates itself, and is destined for the other side of the VPN connection. Apparently there are some caveats when using the KLIPS IPsec stack, but it works great when using NETKEY. Details available in the thread up to and following this message on the Openswan Users mailinglist.

The immediate advantage of using leftsourceip is that you can just reach machines on the far end of the connection, from either gateway where you've set it, without having to specify source interface or address on the internal network.

There's already a patch in the Openswan BTS; hopefully it will be integrated soon.

While I did not aim for it, it was a little disappointing to learn that I got soooooo close to hitting #350000.

Not sure that I have enough of it, but I can try anyway. Here's one for the unlucky administrators who have an Exchange server amidst their server farm.
If a windows server running Exchange 2003 logs the following error event in the System log when it is restarted:

Access denied attempting to launch a DCOM Server. The server is:
{9DA0E106-86CE-11D1-8699-00C04FB98036}
The user is SYSTEM/NT AUTHORITY, SID=S-1-5-18.

then one possible cause is that the Microsoft Search service is missing a startup dependency on the Exchange Information Store – which is not obvious from anything in the event message or the surrounding ones. Searching the web does not list anything relevant at first either, you have to check lower ranked results to find the solution listed in the post by user "zeeshan_xt" in this message board thread. Hopefully this post helps it move up a bit.

Trying to build the unofficial Sarge DVD images for AMD64 today, jigdo-lite could not find several packages on the regular mirrors. Next it tried to fallback to amd64-cdsnap.debian.net, which I believe is a mirror listed in the jigdo template, but still failed to find them over there. Browsing the port pages, I found out that the Sarge release for amd64 is hosted on amd64.debian.net rather than that -cdsnap location. It seems those jigdo templates need an update...

It so happened that my ibook had a 8GiB free space area at the end of the hard drive, and therefore I decided to wanted to use that for MacOS X instead of the 2GiB partition that was used for it before. Trying to avoid problems with bad partitions, I booted from the OSX installation/rescue CD and opened Disk Utility.

To play safe, I locked the existing OSX partition for editing and then assigned the 8GiB free space area to a new hfs+ partition. When I committed, suddenly the existing partition label went blank. WTF??? Had Disk Utility decided it should format what that partition as well? Great, now I'd have to reinstall anyway instead of copying things over.

I rebooted to check partition numbers in linux, but instead of the yaboot prompt I got an alternating question mark / happy face, and after a couple of seconds it booted from the rescue CD again which was still in there. Apparently my bootstrap partition got messed with too. Not funny.

I powered off and inserted a bootable linux CD to chroot into the existing system and rerun ybin. However when I tried to mount the linux root partition it would not want to do so. I checked the partition numbers with fdisk and suddenly my stomach felt like it was tied into a knot: instead of using only the free space as told, Disk Utility had wiped the entire drive and created a 2GiB partition at the beginning and assigned the remaining 28GiB to the new partition instead.

So now I'm left with a ibook shaped paperweight for the time being. Luckily I did not keep anything really important on the laptop, but I did lose some uncommitted programming work, and some of my wife's old mail. Not to mention the time I'll lose by being unable to use it the first few days and having to reinstall it instead. So people: never trust a tool tailored for dummies to something as important as disk partitioning. And to Apple: FIX THE FUCKING PROGRAM SO IT DOES AS IS IT TOLD TO DO AND NOTHING ELSE!

Say Miguel, how cross platform is your .NET? Funny to see these applications mentioned underneath that banner.

Don't get me wrong, I have nothing against Mono (or Novell), in fact I use and like the two applications that I've tried of the above — beagle and f-spot — very much. I just don't think that poster message is appropriate given the projects mentioned in the post.

In an effort to convert a GnomeUIInfo based menu to a GtkUIManager one, I ran into a few annoying holes in the GTK+ documentation. First and foremost, the GTK+ tutorial itself is completely silent about GtkUIManager. Thankfully there is a migration whitepaper in the API reference, but it is still missing a lot of info too. For example, it does not say what the signature of the callbacks for various action entry types look like, let alone give an example how such callbacks could work. And the API reference for GtkActionGroup, which lists the various action entry types does not specify callback signatures either. Only on the GtkAction, GtkToggleAction and GtkRadioAction pages the signatures are listed. Likely because that is where the signals they connect to are documented, but neither from the migration paper nor from the GtkActionEntry page one can find this out.

Another issue is that there apparently is no replacement for the gnome_app_install_*_menu_hints calls. I'm not sure if such method should be in GTK+ itself, and if so, where it should go. Perhaps added to GtkStatusbar, or to a new higher level widget on top of GtkStatusbar (rather than an "application" type widget, I think). Or maybe simply added to gnome-app-helper as an interim solution.
But given the lack of such replacement method, a bigger problem is that no useful documentation is available on how to extract the tooltips from the gtk action entries and set them manually. The connect-proxy signal for GtkActionGroup does mention menuitem tooltips, but that's it. Perhaps I've simply missed a thorough explanation, but if there is one, shouldn't the migration paper link to it?

And finally, something which is more of a problem with the API itself, there's a lack of placeholder macros like the GNOMEUIINFO_MENU_*_ITEM ones. It's easy enough to replace them by fully written action entries, but all of a sudden menus cease to be translated as the translation strings are now part of the application rather than an underlying library. And worse, this is a setback in providing consistency, both for menu names, associated tooltip texts, and translations of both of these. (As for translations, there is a gtk_action_group_set_translate_func method, but it is not clear or explained how to use it)

Enough about this — back to coding.

Past monday (sunday night, actually) I was struck by gastorenteritis. I've had this before, but this time it was worse: even tuesday evening I had trouble eating anything small, my stomach turned all over itself again though I was fairly hungry.

On the upside, after a few days rest and once I started feeling a bit better again, I had plenty time to finish a pending upload for GNOME Apt. No new features, just some code refactoring on the inside – to fix bugs and compilation with newer library versions. One particular change was to substitute GnomeConfig with a simple replacement wrapper based on GKeyFile. I had two reasons not to use GConf: backwards compatibility, and the fact that I believe GConf is over-architectured for an application such as gnome-apt which rather needs a barebones configuration system instead. Only if I would figure out a way to initially run as non-root and do privilege elevation in-process rather than start from gksu or some similar helper, would it be useful to take a look at GConf again.
On a somewhat related note, I have also quickpatched my private copy of stormpkg to be installable again with libapt 0.6.x, but it seems that finally the archive has outgrown it's CList-based package tree implementation. When I tried to swap out gnome-apt's internal widget for a TreeStore, the latter turned out to be too slow to be usable, but the stormpkg CList could easily handle the same packages datasets and kept doing so for a while. But now it has become even worse than that TreeStore implementation used to be; apparently it has now crossed a certain threshold and it takes minutes even just to start. Time to let it go, it has had it's time.

Since no such beast seemed to exist yet, I have hacked up a wrapper to turn an existing python CGI script into a WSGI application. The result is available from the sysfs download area as cgi2wsgi.py.

The wrapper requires you to rename the original CGI script to somecgi.py (pick a name), make it available in the python path, and set the name you gave the script in the wrapper wrapcgi method. This is due to the way it works: it mangles the environment and standard output, and then tries to import the CGI as a python module. Any output is gathered, split into headers and data and then returned to the WSGI server. An alternative approach could have been to create a full-fledged CGI environment and run the script by forking or another equivalent method, with the added bonus that this should work even to turn non-python CGI scripts into WSGI applications; but this looks like a lot more work than the import approach I used (which was tricky enough in certain details already).

The wrapper is not complete as it stands: there are a bunch of variables which are usually available to CGI scripts but aren't when the CGI is loaded by the wrapper. Also if your script uses globals and does not reset them to a sane state before use data may linger in between subsequent invocations. However, I have successfully run a few applications through it so it should provide a reasonably good base to start from. And it did show a few bugs which were not triggered in a standard CGI environment.
The best way to figure out weak spots in your CGI script is probably by running the wrapper in a WSGI server which is not run itself through CGI, to avoid the WSGI server environment leaking through to the application. If run standalone, the wrapper tries to use the OwlFish.com WSGIUtils to this purpose.

Bugfixes, enhancements and feedback welcome at mechanix on rack66.net.