[Pkg-freeradius-maintainers] Bug#1008832: freeradius-python3: Module not linked with libpython when built with Python 3.10

[Andreas Metzler]

Control: tags -1 patch

On 2022-04-02 Adrian Bunk <bunk at debian.org> wrote:
> Package: freeradius-python3
> Version: 3.0.25+dfsg-1
> Severity: serious
> Forwarded: https://github.com/FreeRADIUS/freeradius-server/issues/4441

> Package: freeradius-python3
> Version: 3.0.25+dfsg-1+b1
> Depends: freeradius (= 3.0.25+dfsg-1+b1), libc6 (>= 2.4), libpython3.9 (>= 3.9.1)

> $ objdump -p /usr/lib/freeradius/rlm_python3.so | grep NEEDED  NEEDED               libpython3.9.so.1.0
>   NEEDED               libpthread.so.0
>   NEEDED               libdl.so.2
>   NEEDED               libc.so.6
>   NEEDED               ld-linux-x86-64.so.2
> $

> Package: freeradius-python3
> Version: 3.0.25+dfsg-1+b2
> Depends: freeradius (= 3.0.25+dfsg-1+b2), libc6 (>= 2.4)

> $ objdump -p /usr/lib/freeradius/rlm_python3.so | grep NEEDED
>   NEEDED               libpthread.so.0
>   NEEDED               libdl.so.2
>   NEEDED               libc.so.6
>   NEEDED               ld-linux-x86-64.so.2
> $

Hello,

As far as I can tell this caused by
a) freeradius doing an incomplete autoreconf at build-time (only at top
level directory, to configure-scripts in subdirectories are not
regenerated and
b) the upstream tarball's src/modules/rlm_python3/configure was built
using old autoconf macros which do not handle python 3.10.

Minimal fix seems to be to ship the results of

pushd  src/modules/rlm_python3/ && aclocal -I ../../../m4  && autoconf -I ../../../m4 --force ; popd

in a patch.

A complete fix would fix dh_autoreconf usage to rebuild all configure
scripts. The basic idea would be 
override_dh_autoreconf:
        dh_autoreconf --verbose debian/autoreconfme
and debian/autoreconfme containing
8X-------------------------------
#!/bin/sh

set -e
base=`pwd`
find `pwd` -name configure.ac -printf '%h\n' |
	while read i ; do
                cd $i
                autoconf --force \
                        --include=${base}/m4
                done
8X-------------------------------

However some additional ugliness is going to be needed because the
upstream system is kindof broken:
[...]
(sid)ametzler at argenau:/dev/shm/FREE/freeradius-3.0.25+dfsg/src/modules/rlm_python3$ autoconf -I ../../../m4 --force -I /usr/share/aclocal
[...]
configure.ac:13: error: possibly undefined macro: AM_PATH_PYTHON

---> So in this subdirectory aclocal is needed before autoconf to resolve
     AM_PATH_PYTHON.

But aclocal does not run successfully in all module subdirectories, e.g.
rlm_perl ...
(sid)ametzler at argenau:/dev/shm/FREE/freeradius-3.0.25+dfsg/src/modules/rlm_perl$ aclocal -I ../../../m4 --force
[...]
aclocal: error: configure.ac:6: file 'ax_with_prog.m4' does not exist
(sid)ametzler at argenau:/dev/shm/FREE/freeradius-3.0.25+dfsg/src/modules/rlm_perl$ grep ax_with_prog.m4 configure.ac
m4_include([ax_with_prog.m4])

... since in my tests aclocal does not look in directories given in -I
options to find files specified in m4_include() but expects the file
in the current working directories.

Obvious ugly solutions:
* Copy the m4 file to the subdirectories where they are refered by
  m4_include and run aclocal in addition to autoconf in
  debian/autoreconfme.
* Semi-manually construct a toplevel aclocal.m4 file by running aclocal on
  a throwaway configure.ac using all non-standard macros like
  AM_PATH_PYTHON and the invoke autoconf in the subdirectories with -I
  to the directory contaiing the constructed aclocal.m4.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'