On Thu, 2016-12-01 at 12:55 +0100, Albert Astals Cid wrote: > commit 5621ce4ecc63c289a99ec09cddd8088fa65db726 > Author: Albert Astals Cid <albert.astals at canonical.com> > Date:Â Â Wed Nov 23 17:03:41 2016 +0100 "git am" doesn't recognize this formatting. Could you use "git send- email" for submitting patches? Instructions are available here: https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/ > Â Â Â Add env var for data dir > Â Â Â > Â Â Â Helps making pulseaudio relocatable, i.e. having the code and data in a different > Â Â Â root path than the one that was decided on compilation time I asked you to provide a use case in the commit message, but you only added an explanation for what "relocatable" means. If want to make a snap for PulseAudio and being relocatable helps with that, say it in the commit message. Also explain *why* you want to make a snap for PulseAudio, because I don't really see a use case for that. AFAIK, the usual reason for distributing applications as snaps is that snaps work on any distribution and they run in a secure sandbox. However, the model doesn't work well for system daemons. How are applications expected to connect to the sandboxed PulseAudio? Do you export the socket from the PulseAudio sandbox? If so, how do you avoid conflicts with the operating system's own PulseAudio? Another problem is that if you want to use udev, that's not portable, because mixing different versions of libudev and udevd is not expected to work. By the way, is it common for snaps to bundle unaltered binary debs from Ubuntu? A lot of software has files in /usr/share, and if snaps can't install their files there, I'd expect a lot of debs to not be relocatable. > diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c > index 3dbf6b1..da5b657 100644 > --- a/src/modules/alsa/alsa-mixer.c > +++ b/src/modules/alsa/alsa-mixer.c > @@ -2507,8 +2507,17 @@ static int path_verify(pa_alsa_path *p) { > Â static const char *get_default_paths_dir(void) { > Â Â Â Â if (pa_run_from_build_tree()) > Â Â Â Â Â Â Â Â return PA_SRCDIR "/modules/alsa/mixer/paths/"; > -Â Â Â else > -Â Â Â Â Â Â Â return PA_ALSA_PATHS_DIR; > +Â Â Â else { > +Â Â Â Â Â Â Â static const char *paths_dir = NULL; > +Â Â Â Â Â Â Â if (!paths_dir) { > +Â Â Â Â Â Â Â Â Â Â Â paths_dir = getenv("PULSE_DATA_PATH"); > +Â Â Â Â Â Â Â Â Â Â Â if (!paths_dir) > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â paths_dir = PA_ALSA_PATHS_DIR; > +Â Â Â Â Â Â Â Â Â Â Â else > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â paths_dir = pa_sprintf_malloc("%s/alsa-mixer/paths", paths_dir); paths_dir is never freed. We try to keep PulseAudio Valgrind-clean, so I think this should be handled in some other way. I think it would be best to require the function caller to free the returned string. Another solution that I'd be ok with would be to save the datadir in pa_core when pulseaudio starts. I think the alsa-mixer code doesn't currently always have a pointer to pa_core, but that's probably not difficult to change. > +Â Â Â Â Â Â Â } > +Â Â Â Â Â Â Â return paths_dir; > +Â Â Â } > Â } > Â > Â pa_alsa_path* pa_alsa_path_new(const char *paths_dir, const char *fname, pa_alsa_direction_t direction) { > @@ -4333,6 +4342,23 @@ void pa_alsa_decibel_fix_dump(pa_alsa_decibel_fix *db_fix) { > Â Â Â Â pa_xfree(db_values); > Â } > Â > +static const char *alsa_profile_sets_dir() { > +Â Â Â if (pa_run_from_build_tree()) > +Â Â Â Â Â Â Â return PA_SRCDIR "/modules/alsa/mixer/profile-sets/"; > +Â Â Â else { > +Â Â Â Â Â Â Â static const char *profile_sets_dir = NULL; > +Â Â Â Â Â Â Â if (!profile_sets_dir) { > +Â Â Â Â Â Â Â Â Â Â Â profile_sets_dir = getenv("PULSE_DATA_PATH"); > +Â Â Â Â Â Â Â Â Â Â Â if (!profile_sets_dir) > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â profile_sets_dir = PA_ALSA_PROFILE_SETS_DIR; > +Â Â Â Â Â Â Â Â Â Â Â else > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â profile_sets_dir = pa_sprintf_malloc("%s/alsa-mixer/profile-sets", profile_sets_dir); Same comment as above. -- Tanu https://www.patreon.com/tanuk
