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…
tell gregkh that it’s how great it is not to have a stable kernel interface…
Why? Cause you rule, you are the man and we couldn’t live-code without you?Keep up the great work man!Also, since Im here, how about adding ~x86 to the picoxine ebuild? 🙂
Agreed, you rock!Talking bout picoxine, HOMEPAGE=http://www.kde-apps.org/con… (current one redirects to download immediately)
I know we’ve discussed it before, and you’ve never been keen on it, but remember that you don’t *have* to maintain a 2nd version of ALSA for 2.6 users. There might be a few perceived downfalls of not supporting an in-portage version, but it is a huge step in the direction of reducing maintainance time…
Daniel, if only ALSA developers finally decided to separate userland and kernel interfaces, I’ll be more than happy to consider alsa-driver just heritage, but as long as the kernel drivers require to be sync-ed with the userland, it’s still important for it to work.Also, as you can see, there still are a few drivers that are not into main kernel tree, and for those users alsa-driver is even more important.