This Time Self-Hosted
dark mode light mode Search

I’m officially pissed off – The ALSA incident

Okay this is not the first time, but it doesn’t happen so often. I’m officially pissed off. By what? Well it’s long to explain.

Up to ALSA 1.0.9, the ALSA related packages were handled by Jeremy (eradicator); in the last months, tho, Jeremy seemed to have less time, so when ALSA 1.0.10rc1 was released, after a while I took care of adding the ebuilds to the tree under p.mask.
After that, rc2 was released, and was a bit of a mess because for the first tome one of the packages, alsa-jack, was not updated to rc2. That was fixed, too. I had also to patch alsa-utils in the mean time and a patch to alsa-driver for some Audigy card gone through, too. Other reports were from src_test failures for Hardened and general. I quite ignored them until rc3; it was p.masked stuff, it was RC, I wasn’t going to follow every bug for them. As the bugs where reproduceable with rc3, I patched alsa-lib to fix it.

Then come out the kernel 2.6.14… bad thing, the kernels lately started doing massive changes also in API, and the old alsa-driver 1.0.9 didn’t compile: the kernel is ship with ALSA rc1. This also requested to unmask alsa-lib as the drivers and the libs are better maintained in sync to avoid the old bugs with 1.0.8 and 1.0.9 (people told me that it shouldn’t be always an issue… but you know, we hadn’t had an 1.0.10 yet, and I for sure didn’t wanted to try!). ALSA 1.0.10_rc2 and rc3 gone wild on ~arch!
Note: I didn’t delete rc2, not really sure why I did that, but that’s the important thing.

Then, 2.6.14 needed to go stable, soon. When I saw dsd’s commit telling the urgency, I openend a bug to arches to stabilize ALSA. I gone for rc2 as rc3 was newer and didn’t have the time needed for stabling. The src_test problem stroke back, and I fixed that at last applying the same patch, I originally forgot of rerunning eautoreconf, and that caused another bug that I fixed quite immediatly (I forgot because the bug was not reproduced by who marked it stable). Problem solved? Well a part a few discussion with x86 arch team and the kernel guys, the incident seemed quite fixed now, for the future we’ll all try to make things clearer and smoother to mark stable. I made the first mistake by not CCing kernel guys on the arch bug, and I’m sorry about that….

No it does not end so well. A new bug come up, alsa-driver rc2 does not build on 2.4 kernels. A bit of a problem, but rc3 seems to work fine, that’s fine for me, normal problem, will be solved as soon as a non-rc alsa come up and we can mark that stable. Note that it wasn’t for 2.6.14, I wouldn’t have marked 1.0.10_rc* ~arch, let alone stable!
But no, that can’t be just considered a side problem of 2.4 users that should try to get a hold by themselves, I have to do something, but what? Now tell me, what I could have done more than that?

I try to be as calm as I can be, I try to do the best I can do. Maybe it’s not enough, but you can’t ask me to consider 2.4 kernels while marking stable a driver that is needed for last stable tree to work fine, being on an architecture with no 2.4 support, not being the arch team which marked it stable, and being ignored by arch teams, too!

I’m officially pissed off, for tonight, I’m off.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.