I think there are a few things that, since I work in Gentoo, make me depressed. This is not usually related to other devs behaviour, as instead seems to happen to other people.
Other devs can stress me, piss me off when they try to make a fool of me (and that seems to happen more and more often, not sure why), and so on. They can’t depress me tho, I know that a lot of Free Software developers and advocates are strange people which often also have some really hard social problems 😛 It’s the fate of the technically skilleds.
What depresses me is when I work hard to get a good downstream (Gentoo) support for a package, but I end up hitting a wall of stone due to wrong choices of upstream. I already was depressed by Avidemux last year as I wasted almost a full week to work on patching it to avoid automagic dependencies and then upstream messed them up by changing the configure.in file in a way that made a good half of my patches to fail, and the other half failed because was depending on the first half.
Now, I already told in the last days that I had reports of some problems with ALSA and the latest kernel released (2.6.17), the problem was that serialmidi was using an unnumbered semaphore that, since 2.6.17, was replaced with a mutex, probably for performance reasons, and for design of course (an unnumbered semaphore is the definition of mutex, and probably mutexes’ implementation is faster than semaphores’). The fix was quick after I was told of that change and I found the correct functions to use with mutexes to replace the originals. No, this was not fixed upstream; serialmidi is one of those drivers that are present in alsa-driver but not in kernel tree.
Another of those driver is asihpi, that today Cardoe reported to me as not compiling on 2.6.17… thanks to dsd_ I discovered that MODULE_PARM was deprecated since a long time but still used in that driver. I look at the mercurial repository and… oh it’s fixed! 🙂
I hope so, but hope is not always fulfilled; and this is one of those cases. The patch is about 600KiB uncompressed, a bit less once bzip2’d, but still more than I’d like it to be. Also, it does not apply on alsa-driver-1.0.11. Okay, quick fix, I remove that driver entirely in current 1.0.11 ebuild when building on 2.6.17 and later, and I go looking for another solution. I try to build the drivers out of mercurial… and still no luck, the code still does not build.
Sometimes I wonder why I do maintain ALSA, why i spend so much time trying to get code working for this thing if every time a new kernel is released everything breaks…