Fewer patches, fewer combos

After the new warning of the last days about toolchain-funcs eclass (well actually about gcc eclass which is getting deprecated), I started fixing all the video and sound ebuilds to use the new toolchain-funcs eclass, where needed.

Yes because many ebuilds stopped using gcc functions but still inherited gcc, or where just using it to find out if you are using gcc 3.4 to apply patches which are valid for all gcc version. In these cases, I just removed the inheritance and made the patch apply unconditionally.

This is more important as it seems, because sometimes the new errors which came up with newer gcc was just warnings before, but the code was equally wrong. This is true also for new gcc4 patches. Having the patches applied unconditionally, also, makes less combination of applied patches possible. This is useful because if the code is different between system cause of the gcc version, it’s more difficult find out problems, also because emerge info just shows the current compiler, not the compiler used for the package (this is true mainly for runtime problems, not compile time as there the gcc is just the same).

Cleaning up many ebuilds also lead me to check some quite-unused quite-unmaintained packages, which shown 34K patches and 22K makefiles. It’s not so much, but 120K less to sync is someway interesting for me. I’ve already converted a few packages to patchset tarballs (that I maintain locally using a subversion repository, so to have them always updated), but those was less band-consuming that the ones I found last night.

With that cleanup my commit statistics are going to have a strange curve 🙂

Now I’m compiling gcc 3.3, to test a couple of packages so to apply a few more patches unconditionally, so to have less checks here and there.
I’ve also changed the checks for gcc 3.4 or better, when legit (for example for cflags), to consider the existance of gcc4. Most of them was just bound to gcc 3.x series.

By the way.. have you seen the german spam attack? It’s driving me crazy, also because usually most of the spam is just filtered by GMail, and a few mails are filtered locally by spamassassin.. today I received more than 60 spam mails which was unfiltered, and just now spamassassin starts to recognize them as true spam. As suggested by slarti I’ve increased the scoring of razor2 and bayesian rules so that they can junk a single mail by themselves, and now I hope I can get rid of them.

I’m lucky I’m using a good-trained bayesian filter, but that’s not a solution.