Today I started the catalyst run on Klothos, after fixing freebsd-lib, and I got an overdue world update on Farragut, so I’ve decided to spend my time fixing the autotools bugs that were still open, as the new autotools are now mostly stable, and the breakages cannot but increase if they are not taken care of. Unfortunately, the people passing for a QA team seems not to care if users can fail building some packages because of unstated autotools dependencies or because their handling is simply broken, so there were bugs as old as three months now waiting their place in line.
After fixing the open bugs, I wanted to check how many more packages could be using broken autotools, so I used a simple command: <tt>fgrep -w libtoolize . -r –include ‘*.ebuild’</tt> .
No package should run libtoolize by itself, because most of the times devs simply don’t know WHEN to run it, and run it in the wrong order, when you want to run libtoolize you should run eautoreconf instead as you need to run every tool after a libtoolize. This test is quite good to find the packages that don’t know what they are doing, although it won’t find all of them.
Unfortunately the list is long, and I’m not sure if I’ll be able to solve all of them; I’ve tried fixing stable and ~arch if possible, but I think the best I can do is make sure that ~arch is fixed and then open a bug for all the packages that needs to get some version gone.
It’s a huge and massive amount of work to do, and it will probably stop me from doing a few other things I had in my TODO list for a while, but considering that it might save users form finding packages not building at all, it might be worth fixing.
So, wish me good luck, especially since I’m touching packages that are not mine, and I’m sure there will be someone barking about this (but I think I said to fix their autotools crap before, so …).
Talking about the soundcard instead, it seems like I can find Audigy 4 cards still around here, but they go for €79, which is not something I’d spend with eyes closed. Anybody here has one and can tell me how it works with ALSA? It should be just an Audigy 2 ZS with some changes, but I’m not sure about that. Also, does it come by default with optical input (the boxed version, not OEM)?
Can you post this as a Helpful Reminder(tm) to the dev list? Might cut your workload down a bit.It’d be nice to have a QA team that actually does something. Maybe springtime.
er, let me rephrase that to avoid insulting anyone. i meant it’d be nice to have a QA team that had the _power_ to correct the errors they find, rather than being limited to pinging bug reports.
Ryan, QA _has_ power to do that, as I do. Actually, they have reasons to do what I’ve done all day long, while I don’t, and I could probably leave my ass to devrel if some developer started complaining. I’m not in QA and so I don’t have powers to enforce anything.But the difference is that I don’t really care about losing my ass (really, if I were to be expelled, I think at this point I would just gain in health and free time), and I find the time wastes of writing unfinished documentation pointless if you don’t enforce it the slightest bit.I’m not the kind of person to just “fuck off” documentation, as you can read, I spend a lot of my time writing documentation, but I also try to get stuff done.Why couldn’t someone from QA in the past three months just fix the autotools bugs? Because they ignored them, either because they think that users should just get errors for being users, or because they don’t like Patrick who reported most of them, or just because they don’t give a rat’s ass about fixing the problems, and prefer instead writing complex policies or specifications or what the hell spb is writing instead of doing something useful for Gentoo.I’m I a bastard for saying so? Maybe, but I’m also honest, as I don’t trust the current QA project to do something useful in the medium-near timeframe.