[alsa-devel] [PATCHES] Integrate minimal systemd support in alsa-utils
Heya,
Up to this point most distributions have been using different init scripts/udev rules files to save/restore mixer settings at boot/hotplug/shutdown. Please see my two attached patches for alsa-utils which add standardized, simplified support for this.
The first patch is stolen from Debian/Ubuntu, which moves asound.state to /var/lib, which is a more appropriate place, since /etc might be read-only.
The second patch includes a minimal udev rule (executed synchronously, enabled on all systems, regardless of systemd is used or not) and two systemd service files (executed asynchronously at boot/shutdown, only enabled if built with systemd support).
Given that most big distributions are moving to adopt systemd sooner or later it would be great to have support for this in the upstream package to avoid further balkanization how things are done here.
Lennart
At Tue, 23 Nov 2010 03:16:58 +0100, Lennart Poettering wrote:
From c5b414489626fcd46d792ab96db06e254dfeff90 Mon Sep 17 00:00:00 2001
From: David B. Harris david@eelf.ddts.net Date: Tue, 23 Nov 2010 02:59:18 +0100 Subject: [PATCH 1/2] Move asound.state location to /var/lib/alsa/
/etc might be on a read-only partition which is not suitable for dynamic data such as the mixer settings. Hence move the location of asound.state to /var/lib.
Could you add configure option to specify the path instead of replacing the fixed path? I don't mind to change the default path, but dropping the old path is no good approach, since alsa-utils is still used by many old distros.
thanks,
Takashi
alsaconf/alsaconf.in | 4 ++-- alsactl/alsactl.1 | 4 ++-- alsactl/alsactl.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/alsaconf/alsaconf.in b/alsaconf/alsaconf.in index ccc1b37..b9815d1 100644 --- a/alsaconf/alsaconf.in +++ b/alsaconf/alsaconf.in @@ -956,8 +956,8 @@ If you have a big amplifier, lower your volumes or say no. aplay -N $TESTSOUND fi fi
- if [ ! -r /etc/asound.state ]; then
- xecho "Saving the mixer setup used for this in /etc/asound.state."
- if [ ! -r /var/lib/alsa/asound.state ]; then
- xecho "Saving the mixer setup used for this in /var/lib/alsa/asound.state." $sbindir/alsactl store fi clear
diff --git a/alsactl/alsactl.1 b/alsactl/alsactl.1 index eb3cbd1..eb5968c 100644 --- a/alsactl/alsactl.1 +++ b/alsactl/alsactl.1 @@ -43,7 +43,7 @@ Print alsactl version number.
.TP \fI-f, --file\fP -Select the configuration file to use. The default is /etc/asound.state. +Select the configuration file to use. The default is /var/lib/alsa/asound.state.
.TP \fI-F, --force\fP @@ -90,7 +90,7 @@ The configuration file for init. By default, PREFIX/share/alsa/init/00main is used.
.SH FILES -\fI/etc/asound.state\fP (or whatever file you specify with the +\fI/var/lib/alsa/asound.state\fP (or whatever file you specify with the \fB-f\fP flag) is used to store current settings for your soundcards. The settings include all the usual soundcard mixer settings. More importantly, alsactl is diff --git a/alsactl/alsactl.c b/alsactl/alsactl.c index 3b5dfda..59f0738 100644 --- a/alsactl/alsactl.c +++ b/alsactl/alsactl.c @@ -30,7 +30,7 @@ #include <alsa/asoundlib.h> #include "alsactl.h"
-#define SYS_ASOUNDRC "/etc/asound.state" +#define SYS_ASOUNDRC "/var/lib/alsa/asound.state"
int debugflag = 0; int force_restore = 1; -- 1.7.3.2
At Tue, 23 Nov 2010 03:16:58 +0100, Lennart Poettering wrote:
Heya,
Up to this point most distributions have been using different init scripts/udev rules files to save/restore mixer settings at boot/hotplug/shutdown. Please see my two attached patches for alsa-utils which add standardized, simplified support for this.
The first patch is stolen from Debian/Ubuntu, which moves asound.state to /var/lib, which is a more appropriate place, since /etc might be read-only.
The second patch includes a minimal udev rule (executed synchronously, enabled on all systems, regardless of systemd is used or not) and two systemd service files (executed asynchronously at boot/shutdown, only enabled if built with systemd support).
Given that most big distributions are moving to adopt systemd sooner or later it would be great to have support for this in the upstream package to avoid further balkanization how things are done here.
The second patch looks good to me. It doesn't break, at least. I'm going to apply it unless anyone else has specific objection.
thanks,
Takashi
On Tue, Nov 23, 2010 at 07:16, Takashi Iwai tiwai@suse.de wrote:
The second patch looks good to me. It doesn't break, at least. I'm going to apply it unless anyone else has specific objection.
Now that both is merged, mind putting that in openSUSE Factory?
We need to enable systemd services with: --with-systemdsystemunitdir=/lib/systemd/system
list the files/dirs in: /lib/systemd/system/*.service /lib/udev/rules.d/*.rules
Drop the current custom udev rule: /etc/udev/rules.d/40-alsa.rules and use only the systemd one in /lib/udev/. It should work also for non-systemd setups.
All the naming rules for the snd/ subdir can be removed on all recent systems, only the GROUP="audio" is needed.
No rules files should be installed in /etc, all files from packages belong into /lib.
The old SYSV init script: /etc/init.d/alsasound should be linked to: /lib/systemd/system/alsasound.service -> alsa-restore.service so that the init script will not be executed on systemd bootups.
Thanks, Kay
At Tue, 23 Nov 2010 18:05:00 +0100, Kay Sievers wrote:
On Tue, Nov 23, 2010 at 07:16, Takashi Iwai tiwai@suse.de wrote:
The second patch looks good to me. It doesn't break, at least. I'm going to apply it unless anyone else has specific objection.
Now that both is merged, mind putting that in openSUSE Factory?
Sure. A few questions, though:
We need to enable systemd services with: --with-systemdsystemunitdir=/lib/systemd/system
list the files/dirs in: /lib/systemd/system/*.service /lib/udev/rules.d/*.rules
These come from alsa-utils, obviously. But alsa.rpm requires alsa-utils, so this should be OK.
Drop the current custom udev rule: /etc/udev/rules.d/40-alsa.rules and use only the systemd one in /lib/udev/. It should work also for non-systemd setups.
Do you mean I copy systemd's rules file to alsa.rpm...?
We need a rules file for non-systemd (i.e. without systemd.rpm), so someone still needs to provide a udev stuff for sound, I suppose?
All the naming rules for the snd/ subdir can be removed on all recent systems, only the GROUP="audio" is needed.
No rules files should be installed in /etc, all files from packages belong into /lib.
OK.
The old SYSV init script: /etc/init.d/alsasound should be linked to: /lib/systemd/system/alsasound.service -> alsa-restore.service so that the init script will not be executed on systemd bootups.
OK, this is easy.
thanks,
Takashi
On Wed, Nov 24, 2010 at 06:40, Takashi Iwai tiwai@suse.de wrote:
At Tue, 23 Nov 2010 18:05:00 +0100, Kay Sievers wrote:
Now that both is merged, mind putting that in openSUSE Factory?
Sure. A few questions, though:
We need to enable systemd services with: --with-systemdsystemunitdir=/lib/systemd/system
list the files/dirs in: /lib/systemd/system/*.service /lib/udev/rules.d/*.rules
These come from alsa-utils, obviously. But alsa.rpm requires alsa-utils, so this should be OK.
Fine.
Drop the current custom udev rule: /etc/udev/rules.d/40-alsa.rules and use only the systemd one in /lib/udev/. It should work also for non-systemd setups.
Do you mean I copy systemd's rules file to alsa.rpm...?
Can't we just let them get installed from alsa-utils.rpm? And drop the current rule from alsa.rpm?
We need a rules file for non-systemd (i.e. without systemd.rpm), so someone still needs to provide a udev stuff for sound, I suppose?
Oh, we just enable --with-systemd and install the systemd files and udev rules unconditionally, they don't pull systemd.rpm in, the systemd files will jsut be ignored on SYSV boxes, but the udev rule will still be used. That should work and is how it usually works.
Kay
At Wed, 24 Nov 2010 11:50:28 +0100, Kay Sievers wrote:
On Wed, Nov 24, 2010 at 06:40, Takashi Iwai tiwai@suse.de wrote:
At Tue, 23 Nov 2010 18:05:00 +0100, Kay Sievers wrote:
Now that both is merged, mind putting that in openSUSE Factory?
Sure. A few questions, though:
We need to enable systemd services with: --with-systemdsystemunitdir=/lib/systemd/system
list the files/dirs in: /lib/systemd/system/*.service /lib/udev/rules.d/*.rules
These come from alsa-utils, obviously. But alsa.rpm requires alsa-utils, so this should be OK.
Fine.
Drop the current custom udev rule: /etc/udev/rules.d/40-alsa.rules and use only the systemd one in /lib/udev/. It should work also for non-systemd setups.
Do you mean I copy systemd's rules file to alsa.rpm...?
Can't we just let them get installed from alsa-utils.rpm? And drop the current rule from alsa.rpm?
Yes, we can.
We need a rules file for non-systemd (i.e. without systemd.rpm), so someone still needs to provide a udev stuff for sound, I suppose?
Oh, we just enable --with-systemd and install the systemd files and udev rules unconditionally, they don't pull systemd.rpm in, the systemd files will jsut be ignored on SYSV boxes, but the udev rule will still be used. That should work and is how it usually works.
Ah, so you mean 90-alsa-restore.rules in alsa-utils package, and drop 40-alsa.rules in the current alsa.rpm. OK, that's easy.
thanks,
Takashi
On Wed, Nov 24, 2010 at 06:40, Takashi Iwai tiwai@suse.de wrote:
At Tue, 23 Nov 2010 18:05:00 +0100, Kay Sievers wrote:
All the naming rules for the snd/ subdir can be removed on all recent systems, only the GROUP="audio" is needed.
No rules files should be installed in /etc, all files from packages belong into /lib.
OK.
Just noticed, that we have the GROUP="audio" stuff already in the main udev package. I think 40-alsa.rules can just go.
Thanks, Kay
At Tue, 23 Nov 2010 18:05:00 +0100, Kay Sievers wrote:
On Tue, Nov 23, 2010 at 07:16, Takashi Iwai tiwai@suse.de wrote:
The second patch looks good to me. It doesn't break, at least. I'm going to apply it unless anyone else has specific objection.
Now that both is merged, mind putting that in openSUSE Factory?
We need to enable systemd services with: --with-systemdsystemunitdir=/lib/systemd/system
list the files/dirs in: /lib/systemd/system/*.service /lib/udev/rules.d/*.rules
Drop the current custom udev rule: /etc/udev/rules.d/40-alsa.rules and use only the systemd one in /lib/udev/. It should work also for non-systemd setups.
All the naming rules for the snd/ subdir can be removed on all recent systems, only the GROUP="audio" is needed.
No rules files should be installed in /etc, all files from packages belong into /lib.
Now I fixed all these on OBS multimedia:libs project. The only question is the below one:
The old SYSV init script: /etc/init.d/alsasound should be linked to: /lib/systemd/system/alsasound.service -> alsa-restore.service so that the init script will not be executed on systemd bootups.
Do you mean to create a symlink
/lib/systemd/system/alsasound.service -> alsa-restore.service
corresponding to /etc/init.d/alsasound, while keeping /etc/init.d/alsasound as is?
If so, this will also belong to alsa-utils.rpm, I suppose. Otherwise we'll get a circular dependency.
thanks,
Takashi
On Fri, Nov 26, 2010 at 09:36, Takashi Iwai tiwai@suse.de wrote:
At Tue, 23 Nov 2010 18:05:00 +0100, Kay Sievers wrote:
On Tue, Nov 23, 2010 at 07:16, Takashi Iwai tiwai@suse.de wrote:
The second patch looks good to me. It doesn't break, at least. I'm going to apply it unless anyone else has specific objection.
Now that both is merged, mind putting that in openSUSE Factory?
We need to enable systemd services with: --with-systemdsystemunitdir=/lib/systemd/system
list the files/dirs in: /lib/systemd/system/*.service /lib/udev/rules.d/*.rules
Drop the current custom udev rule: /etc/udev/rules.d/40-alsa.rules and use only the systemd one in /lib/udev/. It should work also for non-systemd setups.
All the naming rules for the snd/ subdir can be removed on all recent systems, only the GROUP="audio" is needed.
No rules files should be installed in /etc, all files from packages belong into /lib.
Now I fixed all these on OBS multimedia:libs project. The only question is the below one:
The old SYSV init script: /etc/init.d/alsasound should be linked to: /lib/systemd/system/alsasound.service -> alsa-restore.service so that the init script will not be executed on systemd bootups.
Do you mean to create a symlink
/lib/systemd/system/alsasound.service -> alsa-restore.service
Yes, so: systemctl start alsasound.service works, and the old init script is not started anymore by the SVSV compat code.
corresponding to /etc/init.d/alsasound, while keeping /etc/init.d/alsasound as is?
Yes, for non-systemd boots.
If so, this will also belong to alsa-utils.rpm, I suppose. Otherwise we'll get a circular dependency.
Sure, it does not matter as long as the link is there. :)
Thanks a lot, Kay
At Fri, 26 Nov 2010 12:50:00 +0100, Kay Sievers wrote:
On Fri, Nov 26, 2010 at 09:36, Takashi Iwai tiwai@suse.de wrote:
At Tue, 23 Nov 2010 18:05:00 +0100, Kay Sievers wrote:
On Tue, Nov 23, 2010 at 07:16, Takashi Iwai tiwai@suse.de wrote:
The second patch looks good to me. It doesn't break, at least. I'm going to apply it unless anyone else has specific objection.
Now that both is merged, mind putting that in openSUSE Factory?
We need to enable systemd services with: --with-systemdsystemunitdir=/lib/systemd/system
list the files/dirs in: /lib/systemd/system/*.service /lib/udev/rules.d/*.rules
Drop the current custom udev rule: /etc/udev/rules.d/40-alsa.rules and use only the systemd one in /lib/udev/. It should work also for non-systemd setups.
All the naming rules for the snd/ subdir can be removed on all recent systems, only the GROUP="audio" is needed.
No rules files should be installed in /etc, all files from packages belong into /lib.
Now I fixed all these on OBS multimedia:libs project. The only question is the below one:
The old SYSV init script: /etc/init.d/alsasound should be linked to: /lib/systemd/system/alsasound.service -> alsa-restore.service so that the init script will not be executed on systemd bootups.
Do you mean to create a symlink
/lib/systemd/system/alsasound.service -> alsa-restore.service
Yes, so: systemctl start alsasound.service works, and the old init script is not started anymore by the SVSV compat code.
corresponding to /etc/init.d/alsasound, while keeping /etc/init.d/alsasound as is?
Yes, for non-systemd boots.
If so, this will also belong to alsa-utils.rpm, I suppose. Otherwise we'll get a circular dependency.
Sure, it does not matter as long as the link is there. :)
OK, done now. I'm going to submit to FACTORY later once after checking the builds in multimedia:libs repo.
Thanks!
Takashi
On Fri, Nov 26, 2010 at 12:57, Takashi Iwai tiwai@suse.de wrote:
At Fri, 26 Nov 2010 12:50:00 +0100, Kay Sievers wrote:
OK, done now. I'm going to submit to FACTORY later once after checking the builds in multimedia:libs repo.
Thanks! Seems to work fine for me after I created /var/run/alsa/.
That should be done in the tool itself, or just package it in the RPM?
Kay
At Tue, 30 Nov 2010 07:12:41 +0100, Kay Sievers wrote:
On Fri, Nov 26, 2010 at 12:57, Takashi Iwai tiwai@suse.de wrote:
At Fri, 26 Nov 2010 12:50:00 +0100, Kay Sievers wrote:
OK, done now. I'm going to submit to FACTORY later once after checking the builds in multimedia:libs repo.
Thanks! Seems to work fine for me after I created /var/run/alsa/.
Do you mean /var/lib/alsa?
That should be done in the tool itself, or just package it in the RPM?
This should have been included in alsa-utils.rpm. I'll fix it.
thanks,
Takashi
On Tue, Nov 30, 2010 at 08:06, Takashi Iwai tiwai@suse.de wrote:
At Tue, 30 Nov 2010 07:12:41 +0100, Kay Sievers wrote:
On Fri, Nov 26, 2010 at 12:57, Takashi Iwai tiwai@suse.de wrote:
At Fri, 26 Nov 2010 12:50:00 +0100, Kay Sievers wrote:
OK, done now. I'm going to submit to FACTORY later once after checking the builds in multimedia:libs repo.
Thanks! Seems to work fine for me after I created /var/run/alsa/.
Do you mean /var/lib/alsa?
Oh, sure, you are right.
That should be done in the tool itself, or just package it in the RPM?
This should have been included in alsa-utils.rpm. I'll fix it.
Great.
Thanks, Kay
On 2010-11-23 03:16, Lennart Poettering wrote:
Heya,
Up to this point most distributions have been using different init scripts/udev rules files to save/restore mixer settings at boot/hotplug/shutdown. Please see my two attached patches for alsa-utils which add standardized, simplified support for this.
The first patch is stolen from Debian/Ubuntu, which moves asound.state to /var/lib, which is a more appropriate place, since /etc might be read-only.
The second patch includes a minimal udev rule (executed synchronously, enabled on all systems, regardless of systemd is used or not) and two systemd service files (executed asynchronously at boot/shutdown, only enabled if built with systemd support).
Lennart,
Could you clarify how this affects/changes behaviour for distros not running systemd?
Also, I personally don't like the idea of saving the mixer state at shutdown. (Although I know Ubuntu has that as well.) Too many times I have cranked up the volume for some reason, then turned the computer off, only to find the login sound at maximum volume.
Given that most big distributions are moving to adopt systemd sooner or later
That assumption is not necessarily true at this point. AFAIK, it remains to be seen. That said, I don't mind a systemd patch into alsa-utils, as long as it doesn't break or bloat anything for non-systemd distros.
On Tue, 23.11.10 08:08, David Henningsson (david.henningsson@canonical.com) wrote:
The second patch includes a minimal udev rule (executed synchronously, enabled on all systems, regardless of systemd is used or not) and two systemd service files (executed asynchronously at boot/shutdown, only enabled if built with systemd support).
Lennart,
Could you clarify how this affects/changes behaviour for distros not running systemd?
As I wrote above it won't even be installed if systemd is not around.
Also, I personally don't like the idea of saving the mixer state at shutdown. (Although I know Ubuntu has that as well.) Too many times I have cranked up the volume for some reason, then turned the computer off, only to find the login sound at maximum volume.
Then disable it. And since you don't run systemd you won't even have to do that explicitly.
Given that most big distributions are moving to adopt systemd sooner or later
That assumption is not necessarily true at this point. AFAIK, it remains to be seen. That said, I don't mind a systemd patch into alsa-utils, as long as it doesn't break or bloat anything for non-systemd distros.
Well, this thing is far less "bloaty" then what Ubuntu is currently doing. i.e. Ubuntu duplicates the mixer init database in an init script /sbin/alsa-utils which is moved there for weird reasons. I can only encourage you to drop that "bloat" and rely on the mixer init database that comes with alsa, like everybody else.
(Sorry, the word "bloat" just sets me off)
But anyway, if you don't have systemd, you won't even see these files. Nothing changes for you.
(Also note that Ubuntu is currently asynchronously executing said init script from an udev rule. That means that by the time a device added event reaches PA the mixer has not been configured properly yet, which can confused PA quite a bit. Hence please make sure to drop the execution of said init script from the udev rule, either by simply adopting the code this patch includes, or by making your current rule synchronous. Thanks.)
Lennart
On 2010-11-23 12:42, Lennart Poettering wrote:
On Tue, 23.11.10 08:08, David Henningsson (david.henningsson@canonical.com) wrote:
The second patch includes a minimal udev rule (executed synchronously, enabled on all systems, regardless of systemd is used or not) and two systemd service files (executed asynchronously at boot/shutdown, only enabled if built with systemd support).
Lennart,
Could you clarify how this affects/changes behaviour for distros not running systemd?
As I wrote above it won't even be installed if systemd is not around.
Ok.
Also, I personally don't like the idea of saving the mixer state at shutdown. (Although I know Ubuntu has that as well.) Too many times I have cranked up the volume for some reason, then turned the computer off, only to find the login sound at maximum volume.
Then disable it. And since you don't run systemd you won't even have to do that explicitly.
Ok; so the question is whether we should even have such a rule, and if so, should it be enabled by default? Do other people than you and me have an opinion here?
Given that most big distributions are moving to adopt systemd sooner or later
That assumption is not necessarily true at this point. AFAIK, it remains to be seen. That said, I don't mind a systemd patch into alsa-utils, as long as it doesn't break or bloat anything for non-systemd distros.
Well, this thing is far less "bloaty"
It is not bloating at all (at least not by my standard) if it's not even installed, don't worry.
then what Ubuntu is currently doing. i.e. Ubuntu duplicates the mixer init database in an init script /sbin/alsa-utils which is moved there for weird reasons. I can only encourage you to drop that "bloat" and rely on the mixer init database that comes with alsa, like everybody else.
(Sorry, the word "bloat" just sets me off)
But anyway, if you don't have systemd, you won't even see these files. Nothing changes for you.
(Also note that Ubuntu is currently asynchronously executing said init script from an udev rule. That means that by the time a device added event reaches PA the mixer has not been configured properly yet, which can confused PA quite a bit. Hence please make sure to drop the execution of said init script from the udev rule, either by simply adopting the code this patch includes, or by making your current rule synchronous. Thanks.)
Thanks for the tip, reducing upstream delta is always a good thing. IIRC some of it is inherited from Debian, so it wouldn't hurt for me to find out a little more about this at that level.
On 2010-11-23 12:42, Lennart Poettering wrote:
i.e. Ubuntu duplicates the mixer init database in an init script /sbin/alsa-utils which is moved there for weird reasons.
This is from Debian, of course, and it was moved there in Ubuntu to discourage people from running it (because it erroneously implies to people that it does magical things in alsa userspace) and because /usr might not be available. Of course when the script is removed completely, people howl. Efforts began some time ago to obsolete it (I blogged about it, even) and consolidate all its mess into the alsactl init db (patches have been sent to this mailing list, too). A nontrivial concern is that for some subset of the hard-coded (ick!) mixer controls being set in that script, there are no associated bug reports containing relevant hardware information (e.g., PCI SSID). Thus, migrating them over to the init db format is quite history-search-intensive. But, as I've stated formerly here and on pulseaudio-discuss, it's definitely deprecated (e.g., bug reports have been retitled to indicate that such-and-such an entry in the init db is needed. As I've stepped away from Ubuntu development due to $dayjob, the efforts need to be continued by others).
-Dan
On Tue, 23 Nov 2010, Lennart Poettering wrote:
Heya,
Up to this point most distributions have been using different init scripts/udev rules files to save/restore mixer settings at boot/hotplug/shutdown. Please see my two attached patches for alsa-utils which add standardized, simplified support for this.
The first patch is stolen from Debian/Ubuntu, which moves asound.state to /var/lib, which is a more appropriate place, since /etc might be read-only.
This will break users which upgrade the package manually from sources and /var/lib/alsa directory is not created. I think that the 'make install' rules should create this directory and also alsaconf should check/create this directory if it does not exists.
The second patch includes a minimal udev rule (executed synchronously, enabled on all systems, regardless of systemd is used or not) and two systemd service files (executed asynchronously at boot/shutdown, only enabled if built with systemd support).
Given that most big distributions are moving to adopt systemd sooner or later it would be great to have support for this in the upstream package to avoid further balkanization how things are done here.
I applied this second patch to the alsa-utils repo.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tue, 23.11.10 10:44, Jaroslav Kysela (perex@perex.cz) wrote:
Heya,
Up to this point most distributions have been using different init scripts/udev rules files to save/restore mixer settings at boot/hotplug/shutdown. Please see my two attached patches for alsa-utils which add standardized, simplified support for this.
The first patch is stolen from Debian/Ubuntu, which moves asound.state to /var/lib, which is a more appropriate place, since /etc might be read-only.
This will break users which upgrade the package manually from sources and /var/lib/alsa directory is not created. I think that the 'make install' rules should create this directory and also alsaconf should check/create this directory if it does not exists.
See attached patch. This will now ensure the directory is created both at install time and when alsaconf is run.
Also, I made the path configurable, as requested by Takashi, however set the default to /var/lib/alsa.
Given that most big distributions are moving to adopt systemd sooner or later it would be great to have support for this in the upstream package to avoid further balkanization how things are done here.
I applied this second patch to the alsa-utils repo.
Thanks!
Lennart
On Tue, 23 Nov 2010, Lennart Poettering wrote:
On Tue, 23.11.10 10:44, Jaroslav Kysela (perex@perex.cz) wrote:
Heya,
Up to this point most distributions have been using different init scripts/udev rules files to save/restore mixer settings at boot/hotplug/shutdown. Please see my two attached patches for alsa-utils which add standardized, simplified support for this.
The first patch is stolen from Debian/Ubuntu, which moves asound.state to /var/lib, which is a more appropriate place, since /etc might be read-only.
This will break users which upgrade the package manually from sources and /var/lib/alsa directory is not created. I think that the 'make install' rules should create this directory and also alsaconf should check/create this directory if it does not exists.
See attached patch. This will now ensure the directory is created both at install time and when alsaconf is run.
Also, I made the path configurable, as requested by Takashi, however set the default to /var/lib/alsa.
I applied your patch. Just only one comment: The better location for the install-data-hook is the alsactl/Makefile.am.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
'Twas brillig, and Lennart Poettering at 23/11/10 02:16 did gyre and gimble:
+udevrulesdir=/lib/udev/rules.d
This doesn't appear to be used unless I missed something?
If it were used, I'd rather make this configurable. Obviously udev pretty much mandates this path but it's a PITA when doing non-root make installs to custom prefixes when it's hard coded like this. But like I say, this looks unused here...
Col
On Wed, 24.11.10 17:55, Colin Guthrie (gmane@colin.guthr.ie) wrote:
'Twas brillig, and Lennart Poettering at 23/11/10 02:16 did gyre and gimble:
+udevrulesdir=/lib/udev/rules.d
This doesn't appear to be used unless I missed something?
If it were used, I'd rather make this configurable. Obviously udev pretty much mandates this path but it's a PITA when doing non-root make installs to custom prefixes when it's hard coded like this. But like I say, this looks unused here...
Well, it still honours $(DESTDIR) logic.
It's referenced by the dist_udevrules_DATA= stanza.
Lennart
'Twas brillig, and Lennart Poettering at 24/11/10 19:47 did gyre and gimble:
On Wed, 24.11.10 17:55, Colin Guthrie (gmane@colin.guthr.ie) wrote:
'Twas brillig, and Lennart Poettering at 23/11/10 02:16 did gyre and gimble:
+udevrulesdir=/lib/udev/rules.d
This doesn't appear to be used unless I missed something?
If it were used, I'd rather make this configurable. Obviously udev pretty much mandates this path but it's a PITA when doing non-root make installs to custom prefixes when it's hard coded like this. But like I say, this looks unused here...
Well, it still honours $(DESTDIR) logic.
Yeah but it's still a PITA for self-builds and (I'm told from Arun) some Gentoo stuff too.
Anyway, I've attached an entirely uncontroversial patch that fixes up any issues for those that care. Same as an earlier commit from last year in PulseAudio by Arun Raghavan.
It's referenced by the dist_udevrules_DATA= stanza.
Ahh OK, I don't really grok auto* foo, but I can spot some pixie dust there that kinda makes sense :)
Cheers
Col
participants (7)
-
Colin Guthrie -
Daniel Chen -
David Henningsson -
Jaroslav Kysela -
Kay Sievers -
Lennart Poettering -
Takashi Iwai