autopkgtests fail with for version 5.0~1-4

[Pushkar Kulkarni]

Failure of autopkgtests [1] is reported for the 5.0~1-4 which is currently in noble proposed(universe). The output shows a failure of the loading of app_espeak module into asterisk.

==== output =====
666s Removing autopkgtest-satdep (0) ...
666s autopkgtest [09:39:15]: test module-loadable: [-----------------------
668s Asterisk has fully booted.
668s Unable to load module app_espeak
668s Command 'module load app_espeak' failed.
668s autopkgtest [09:39:17]: test module-loadable: -----------------------]
668s module-loadable FAIL non-zero exit status 1
668s autopkgtest [09:39:17]: test module-loadable: - - - - - - - - - - results - - - - - - - - - -
668s autopkgtest [09:39:17]: @@@@@@@@@@@@@@@@@@@@ summary
668s module-loadable FAIL non-zero exit status 1
==================

[1] https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/amd64/a/asterisk-espeak/20240127_093929_2a248@/log.gz

[Pushkar Kulkarni (pushkarnk)]

The immediate reason for the failure to load the app_espeak module is that it is installed at the wrong location : /usr/lib/asterisk/modules

==========================================

$ ls /usr/lib/asterisk/modules/app_espeak.so
/usr/lib/asterisk/modules/app_espeak.so

==========================================

But, asterisk installed through the Debian package sets module directory to /usr/lib/x86_64-linux-gnu/asterisk/modules

==========================================

$ grep astmoddir /etc/asterisk/asterisk.conf
astmoddir => /usr/lib/x86_64-linux-gnu/asterisk/modules

==========================================

[Pushkar Kulkarni (pushkarnk)]

Well, we want [1] to have the module installed at the right location. But the upstream Makefile does not honor our setting.

[1] https://git.launchpad.net/ubuntu/+source/asterisk-espeak/tree/debian/rules?h=applied/debian/sid#n13

The Makefile needs to be patched, perhaps.

[Pushkar Kulkarni (pushkarnk)]

The upstream Makefile [1] assumes the presence of /etc/asterisk/asterisk.conf during installation, which means it assumes that asterisk-config is installed. This does not make sense in a Debian/Ubuntu package context where the installation location is derived at while building the package.

Because the debian/control file does not list asterisk-config as a dependency, and rightly so, the asterisk.conf file is not going to be available inside a chroot where the package is getting built. This means the Makefile will fallback to the default location of /usr/lib/asterisk/modules, which is not acceptable to an actual asterisk instance at runtime.

[Pushkar Kulkarni (pushkarnk)]

I've also raised an MR with the Debian repo: https://salsa.debian.org/pkg-voip-team/asterisk-espeak/-/merge_requests/2

[Paride Legovini (paride)]

Hello and thanks for submitting this patch both here and to Debian. I have some comments/questions about it:

1. Do we actually need to keep the upstream way to detect ASTLIBDIR when $(ASTMODDIR) is not set? I'm speaking of:

+ifeq ($(ASTMODDIR),)
+ ASTLIBDIR:=$(shell awk '/moddir/{print $$3}' /etc/asterisk/asterisk.conf 2> /dev/null)

Maybe in the context of the Debian package we can just assume $ASTMODDIR is set from d/rules.

2. You mentioned that the issues comes from the fact that asterisk-config isn't a build-dep, and "rightly so". Is there any issue in installing asterisk-config as a build-dep? That will allow auto-detecting ASTLIBDIR with the upstream logic.

3. If you're keeping the d/patches patch, please add full dep-3 headers (https://dep-team.pages.debian.net/deps/dep3/), but I really suggest exploring the solution above.

[Dave Jones (waveform)]

Unsubscribing ubuntu-sponsors pending response to Paride's concerns. Please feel free to re-subscribe once these are addressed.

[Pushkar Kulkarni (pushkarnk)]

The concerns had been addressed on the MP. Apologies for not mentioning it here. Re-subscribing Ubuntu Sponsors.

[Lukas Märdian (slyon)]

https://launchpad.net/ubuntu/+source/asterisk-espeak/5.0~1-4ubuntu1

[Lukas Märdian (slyon)]

Ugh... looks like the bug number in d/changelog was wrong.