[bug#43628] Request for patch evaluation/review

Esteemed maintainers (and contributors),

Attached is a patch which, as far as I can see, should work. But it does
not. I would like to submit it here for review. Please tell me what I am
doing wrong or what I am failing to do, so that I might clean up this patch
and submit a proper one.

1. The problem this patch is trying to solve:
Aegisub (guix install aegisub), as it currently is, does not give any sound
(at least on foreign distros). The terminal output reads as follows, when a
video file (with audio) is added into the program and an attempt is made at
playing it: (Video is added to aegisub by using 'Video > Open Video...')
```
ALSA lib conf.c:3683:(snd_config_hooks_call) Cannot open shared library
libasound_module_conf_pulse.so
(/gnu/store/zcjdb23gbhl0pcnvvm8rnlprkfl43cv5-alsa-lib-1.2.2/lib/alsa-lib/libasound_module_conf_pulse.so:
libasound_module_conf_pulse.so: cannot open shared object file: No such
file or directory)
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM default
```
The complaint being that it can't find libasound_module_conf_pulse.so. This
.so comes from the guix package `alsa-plugins:pulseaudio`. The /gnu/store
directory for it is something like
/gnu/store/...-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/libasound_module_conf_pulse.so.
However, the .so file is being looked for inside of the /gnu/store path to
alsa-lib
(/gnu/store/...-alsa-lib-1.2.2/lib/alsa-lib/libasound_module_conf_pulse.so.

2. The Natural Solution:
Since libasound_module_conf_pulse.so is supplied by
`alsa-plugins:pulseaudio`, and the program is looking for it inside the
path to alsa-lib (supplied by `alsa-lib`), union-build is a logical
solution. This is what the patch implements.

3. Problem:
Despite this patch being applied, it continues to look for the .so file
inside the path to alsa-lib and not the union-alsa. What is more, alsa-lib
is not even in the inputs. Only union-alsa is. And yet, it seems to be
trying to use alsa-lib's /gnu/store path, which, the way I see it, violates
guix's functional package management.

4. It's not guix, it's me:
I'm sure this is some mistake on my part. Hence, I submit the diff here for
review.

P. S: The diff has changed a bit because I got this idea of moving
out/lib/alsa-lib/* into out/lib/ just to see if that makes any difference.
Only to realize a little too late that it doesn't. But I send the diff with
those changes included because I didn't stash the previous (cleaner) one.

I forgot to mention, but the union-build works. If one `guix build`s the
union package, and cd into the /gnu/store/...-union-build, one will see
that things are there as it should be (lib/normal-alsa-*.so and
lib/alsa-lib/*pulse*.so).

It's just that aegisub seems to be looking from the
/gnu/store/normal-alsa-lib-dir instead of /gnu/store/union-alsa-package.

Another information:

I have other programs on my foreign system (installed via guix) that
produce sound well, without any issues. They include:
espeak and kdenlive.

Also, I did try making the union-build use copies instead of symlinks using
(union-build ... #:symlink copy-recursively) but that didn't work out
either.

Now, I'm going to take a look at fixing the pkg-config rules, and will be
updating this thread should that resolve this issue.

On Sat, Sep 26, 2020 at 12:21 PM Prafulla Giri <pratheblackdiamond@gmail.com>
wrote:

> I forgot to mention, but the union-build works. If one `guix build`s the
> union package, and cd into the /gnu/store/...-union-build, one will see
> that things are there as it should be (lib/normal-alsa-*.so and
> lib/alsa-lib/*pulse*.so).
>
> It's just that aegisub seems to be looking from the
> /gnu/store/normal-alsa-lib-dir instead of /gnu/store/union-alsa-package.
>

Hi Prafulla,

Le 26 septembre 2020 03:31:38 GMT-04:00, Prafulla Giri <pratheblackdiamond@gmail.com> a écrit :
>Another information:
>
>I have other programs on my foreign system (installed via guix) that
>produce sound well, without any issues. They include:
>espeak and kdenlive.
>
>Also, I did try making the union-build use copies instead of symlinks
>using
>(union-build ... #:symlink copy-recursively) but that didn't work out
>either.
>
>Now, I'm going to take a look at fixing the pkg-config rules, and will
>be
>updating this thread should that resolve this issue.
>
>On Sat, Sep 26, 2020 at 12:21 PM Prafulla Giri
><pratheblackdiamond@gmail.com>
>wrote:
>
>> I forgot to mention, but the union-build works. If one `guix build`s
>the
>> union package, and cd into the /gnu/store/...-union-build, one will
>see
>> that things are there as it should be (lib/normal-alsa-*.so and
>> lib/alsa-lib/*pulse*.so).
>>
>> It's just that aegisub seems to be looking from the
>> /gnu/store/normal-alsa-lib-dir instead of
>/gnu/store/union-alsa-package.
>>

I think the issue with the union-build is that it is completely ignored: alsa doesn't look in it's current directory for plugins, but in the directory where it's been configured (at build time) to look for.

On the Guix System, there is a service that creates a /etc/asound.conf, which references alsa-plugins:pulseaudio. Maybe you actually want to configure that? Maybe try to copy this to a new file .asoundrc:

pcm_type.pule {
  lib "/home/foo/.guix-profile/lib/alsa-lib/libasound_module_pcm_pulse.so"
}

ctl_type.pulse {
  lib"/home/foo/.guix-profile/lib/alsa-lib/libasound_module_ctl_pulse.so"
}

pcm.!default {
  type pulse
}

ctl.!default {
  type pulse
}

Hello Mr. Lepiller,

Thank you for the tip. For the moment, I want to poke around this issue.
Perhaps I get absolutely tired of it (or find a good hack - and an ugly
patch). I did manage to learn a bit more about union-builds in general. So,
that's a silver lining.

Also, your work on guix-android seems so very cool! Please keep up the
great work!

On Sat, Sep 26, 2020 at 3:28 PM Julien Lepiller <julien@lepiller.eu> wrote:

>
>
> Hi Prafulla,
>
> Le 26 septembre 2020 03:31:38 GMT-04:00, Prafulla Giri <
> pratheblackdiamond@gmail.com> a écrit :
> >Another information:
> >
> >I have other programs on my foreign system (installed via guix) that
> >produce sound well, without any issues. They include:
> >espeak and kdenlive.
> >
> >Also, I did try making the union-build use copies instead of symlinks
> >using
> >(union-build ... #:symlink copy-recursively) but that didn't work out
> >either.
> >
> >Now, I'm going to take a look at fixing the pkg-config rules, and will
> >be
> >updating this thread should that resolve this issue.
> >
> >On Sat, Sep 26, 2020 at 12:21 PM Prafulla Giri
> ><pratheblackdiamond@gmail.com>
> >wrote:
> >
> >> I forgot to mention, but the union-build works. If one `guix build`s
> >the
> >> union package, and cd into the /gnu/store/...-union-build, one will
> >see
> >> that things are there as it should be (lib/normal-alsa-*.so and
> >> lib/alsa-lib/*pulse*.so).
> >>
> >> It's just that aegisub seems to be looking from the
> >> /gnu/store/normal-alsa-lib-dir instead of
> >/gnu/store/union-alsa-package.
> >>
>
> I think the issue with the union-build is that it is completely ignored:
> alsa doesn't look in it's current directory for plugins, but in the
> directory where it's been configured (at build time) to look for.
>
> On the Guix System, there is a service that creates a /etc/asound.conf,
> which references alsa-plugins:pulseaudio. Maybe you actually want to
> configure that? Maybe try to copy this to a new file .asoundrc:
>
> pcm_type.pule {
>   lib "/home/foo/.guix-profile/lib/alsa-lib/libasound_module_pcm_pulse.so"
> }
>
> ctl_type.pulse {
>   lib"/home/foo/.guix-profile/lib/alsa-lib/libasound_module_ctl_pulse.so"
> }
>
> pcm.!default {
>   type pulse
> }
>
> ctl.!default {
>   type pulse
> }
>

Is this a duplicate of #40832, "alsa-lib cannot find its plugins"?

https://bugs.gnu.org/40832

The patch I submitted in that bug ticket does work. I haven't found the
energy to perform a final review of the C code.