There is also a mixerlib that I'm not sure where it comes from, it seems _based_ on SDL_mixer, but not the same.
I looked at this, and this package has some seriously bad programming practices - especially on the mixer/SDL_mixer part. To fix that i think we would have to find exactly what is different between its mixer and SDL_mixer and basically rewrite a good part to make it work nicely with SDL_mixer. On the other hand, it seems this package is only used for PySol. PySol has long stopped being developed or supported (~2004), and another project has taken lead, called PySolFC. This new project has no need for a sound server and is written totally in Python through Python's sound interface ossaudiodev. Which means it works perfectly out of the box, without having to compile anything or worry about exported symbols. My suggestion is to remove PySol and pysol-sound-server and put PySolFC on portage. I will try to work on an ebuild, but I have never made one, so it might take a while before I get anything presentable. The only problem with this is that the Python sound interface writes directly to /dev/dsp, and when alsa is working it seems to block that device. According to google, many distros are seeing that problem, but no solution is presented. I will look at it as well, but it is not a problem of PySolFC or Python, but of ALSA's OSS emulation.
I filed an ebuild for PySolFC, like I said I would. It is under bug #253200. Hopefully in time it might get accepted and pysol-sound-server and pysol can be removed from the portage. I know it might not be the best solution for this, but it is the best way I think I could contribute to closing this bug. (BTW, that ALSA/OSS problem I talked about: my bad. I didn't know I had to alsaconf after modprobing the OSS modules. Nevermind that.)
Would be best if this migration to PySolFC is done rather sooner than later. libmikmod had 2 recent vulnerabilities, CVE-2007-6720 and CVE-2009-0179
and it's gone.
