alsa cleanup: non-optional midi support, cleaner confd

Some more stuff that has happened recently with cleaning up ALSA ebuilds.  We (as in me, mostly) decided to drop support for the optional MIDI support in the alsa-lib and alsa-utils packages.  It originally was implemented as a hack on our end, always caused headaches when disabled, and a whole lot of ebuilds required that it be implemented anyway, so it wasn’t so optional to start with.

With alsa-1.0.20, I ripped out the midi use flag completely, but instead of fixing the reverse dependencies to check for an either/or scenario, instead it was decided to just go back and change all versions of the alsa-lib/utils ebuilds and to force it on, and then drop the check on those using it.  Thanks to Samuli (ssuominen) for fixing all the applications that were using it.

If you run into any ebuilds that are failing to merge because of the dependency, that are in the main portage tree (sorry, I can’t take responsibility for overlays), try syncing your tree again — it’s possible your last one was during the transition.  If you still find one that isn’t working, feel free to file a bug report at bugs.gentoo.org and assign it to alsa-bugs@gentoo.org.

Another change that has needed to happen for a while, though not nearly as dramatic, is that I ripped out the really old config options in the alsasound init script: KILLPROC_ON_STOP and UNLOAD_ON_STOP which would kill process using ALSA, and unload its modules, respectively.  Like before, they caused more problems than they solved (both of which, I might suggest, could be implemented in local.stop if you really needed something like that), and I’m glad to say they are gone.

That’s about all the major growing pains for now — that is, I certainly don’t have anything else on my plate for ALSA or its related applications, other than getting 1.0.20 stable and everything previous to that version removed from the tree.

As always, we appreciate any help people would like to give.  There’s still old bugs open, and it’d be good to know if they are solved or not in the latest release.

I realize some of these changes may be minor bumps for users, and if so, I apologize … but Gentoo is always changing goals and directions, and I’m quite glad that we have the flexibility to change things, instead of being stuck with one method.  Part of growth is just shedding the stuff that doesn’t work.

About these ads

4 Comments

Filed under Gentoo

4 responses to “alsa cleanup: non-optional midi support, cleaner confd

  1. Matt Henley

    When I try to start Jack, I get this error:
    18:39:37.187 Could not open ALSA sequencer as a client. ALSA MIDI patchbay will be not available.
    ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory
    Cannot connect to server socket err = No such file or directory
    Cannot connect to server socket

    Has the /dev/snd/seq gone away?

    • Matt, dunno what’s causing it … either way, this isn’t really the best place to debug the issue :) Please file a bug on bugs.gentoo.org, or check with the forums to see if anyone else is experiencing something similar.

      Thanks.

  2. Peter Karlsson

    I understand you wish to clean up the ebuild (removing midi use flag) and that it was a “hack” from the beginning. Can you explain what consequences this has? I.e. what functionality disappears with the removal of the midi use flag?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s