Comment 28 for bug 1849785

This moved in python:
3.7:
libpython3.7-minimal:amd64: /usr/lib/python3.7/_sysconfigdata_m_linux_x86_64-linux-gnu.py
3.8:
libpython3.8-stdlib:amd64: /usr/lib/python3.8/_sysconfigdata__linux_x86_64-linux-gnu.py

Build depends is: libpython3-all-dev
The file is present - Build-env:
/usr/lib/python3.8/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-38.pyc
/usr/lib/python3.8/__pycache__/_sysconfigdata__x86_64-linux-gnu.cpython-38.pyc
/usr/lib/python3.8/_sysconfigdata__linux_x86_64-linux-gnu.py
/usr/lib/python3.8/_sysconfigdata__x86_64-linux-gnu.py

This is explicit in
override_dh_auto_install:
        dh_auto_install
        set -e; export _PYTHON_SYSCONFIGDATA_NAME='_sysconfigdata_m_${DEB_HOST_ARCH_OS}_${DEB_HOST_MULTIARCH}'; \
        for pyver in `py3versions -s`; do \
                dh_auto_configure -- --enable-python PYTHON=$$pyver; \
                dh_auto_install --sourcedirectory=src/python -- PYTHON=$$pyver; \
        done

So it turns out this lost the "m" in python 3.8
Which probably would autoresolve in other cases, but since here the d/rules has it listed explicitly it fails.

Error reproducible with:
$ set -e; export _PYTHON_SYSCONFIGDATA_NAME='_sysconfigdata_m_linux_x86_64_linux-gnu'
$ dh_auto_install --sourcedirectory=src/python -- PYTHON=python3.8

works with:
set -e; export _PYTHON_SYSCONFIGDATA_NAME='_sysconfigdata__linux_x86_64-linux-gnu'
dh_auto_install --sourcedirectory=src/python -- PYTHON=python3.8

Note that it also works WITHOUT the set at all.
Per the commit that added it this is for an FTCBFS => https://salsa.debian.org/debian/libseccomp/commit/3e16ede54bbcce6238e542d043821cabcc6a343e#8756c63497c8dc39f7773438edf53b220c773f67_31_29

I now wonder, does python 3.8 need to be fixed or the d/rules of libseccomp or both.