Well, today was a yak-shaving day par excellence.

(Yak shaving, if you didn't know, is a term used to describe the situation where one perfectly normal thing leads you to do another perfectly normal thing, and so on and so on, until you find yourself shaving a yak).

I started off still working on the Python 2.6 rebuild. When I couldn't get wxpython 2.6 to build because of some crappy annoying error, I decided instead of working too hard on fixing it to see how many things we have left that depend on wxpython 2.6. I figured it couldn't be many, and I was right. For those who don't know, wxWidgets / wxGTK is a widely-used GUI-building library; version 2.8 came out quite a while ago, now, but most distros keep a copy of 2.6 around alongside it because some things wouldn't build with 2.8. Fedora's the only distro that's gone to 2.8-only so far. wxpython is the Python bindings for wxWidgets - if you want to write an app in Python using wxWidgets as your interface library, wxpython's the lump of code for you.

Turned out the only things left that depended on wxpython 2.6 were tovid, icepodder, python-hachoir-wx (popular software, that!) and a couple of BitTorrent clients - bittornado (which has been abandoned since 2006) and the official 'bittorrent-gui'.

I fixed tovid, icepodder and python-hachoir-wx to work with wxpython 2.8. Then I decided to just kill BitTornado and bittorrent-gui, because there's really no freakin' reason to use them any more. So if for some crazy reason you still have them installed - when 2009 Spring comes out, they'll be silently replaced by Transmission. Just so ya know.

So, ding dong, wxpython 2.6 is dead. Fun stuff! Emboldened by this success, I decided to have a shot at killing off wxGTK 2.6 itself, not just the Python bindings. So I generated a list of everything that uses it (anything that requires libwxgtk2.6 or libwxgtku2.6, basically) and started working through.

So far I've fixed up bacula, beid, freqtweak, iaxclient (via its subsidiary iaxcomm) and sffview. Tomorrow I'll tackle libwxhaskell and xchm, and if I can do those, we can go to wx 2.8 exclusively.

The yak shaving comes in in terms of actually fixing the stuff. Fr'instance, I had to patch various bits of beid to make it work with wx 2.8, but even after doing that, it wouldn't build on the buildsystem because of some batshit weird interaction between python 2.6 and scons 1.1.0 which caused it to add a space between every letter (l i k e t h i s) when scons added some CFLAGS. So I had to update scons to 1.2.0, which fixed that, but triggered another problem in part of beid's crappy buildsystem (which is basically something called bksys that died years ago, nothing else uses it any more). So I had to track down the guy who wrote bksys on IRC (at 4 a.m. in France, no less...), who helped me sort that one out.

Then there's iaxclient, which required packaging an entirely new library it depends on, and also required rebuilding one of its dependencies, kiax, which in TURN required another new library and a lot of poking around at its entirely-not-yet-ready-for-public-consumption build system (which assumes you're building it as a giant static binary, linked against a big set of static libraries which it assumes are present in the source tree but aren't actually shipped with it...) Actually I haven't uploaded it yet because it doesn't run properly, I'm waiting for some input from upstream on that one. I think it's a threading problem.

Of course, you might wonder why bother doing all this in the first place. After all, most of this stuff probably worked okay when it was built against wx 2.6.

Well, it's what developers and maintainers refer to as 'cruft', and we don't like it for good reasons. People generally don't like working with cruft. No-one actually wants to maintain wx 2.6 packages, because upstream doesn't maintain it any more and isn't interested in fixing any bugs you find, so you have to do all the work yourself, and it becomes a teetering pile of patches which have to be re-examined and fixed and updated for every new library major and GCC revision. It means that if you come across some kind of general bug in wx, you have to fix it twice, or - more likely - it won't get fixed in the old version at all because no-one loves it enough. Basically, old code doesn't get enough attention, and eventually the stuff that uses it will break. So to keep things floating along properly, you really have to clean out the cruft when you can.

So, that took up all day, in the end. Hopefully I can finish it up tomorrow and move on to something else. Whee...


roved2101 wrote on 2008-12-30 08:34:
Thanks for all the work you do. Icepodder is slow in development compared to other apps but still unique. Thanks for updating it for 2009.1 to the latest revision. I've been using it for sometime and it is quite nice and more flexible then the current stable. Cool I didnt know about Transmission, will use it from now on, now I am using Gnome. Hope the job huntings going great. Catch you around the community. All the best Rodger.
colin51 wrote on 2009-05-16 00:48:
Unfortunately for me dear old Mandriva released 2009 spring with Python 2.6 which breaks Icepodder. Much of the problem is the md5 hash which has now been included in a new library hashlib also the sha lib has been deprecated I was able to fix some of the the problems but one remains which I cannot track down since my knowledge of Python is next to zero. Boy could Mandriva do with you in QA; still it seems you have lanced on your feet!! Good for you
adamw wrote on 2009-05-16 03:06:
if you file a bug on it and give me the URL i'll see if I can figure anything out if I get some spare time...