font-tlwg fails to build on amd64

[murraybd]

The package font-tlwg with version 0.7.3 and epoch r0 fails to build from source with the following error:

running step "git-checkout"
[git checkout] repo='https://github.com/tlwg/fonts-tlwg' dest='.' depth='1' branch='' tag='v0.7.3' expcommit='a2d3f66b3004276232eb279c3392758c05bcc279' recurse='false'
[git checkout] execute: git config --global --add safe.directory /tmp/tmp.rGr9C8
[git checkout] execute: git config --global --add safe.directory /home/build
[git checkout] execute: git clone --quiet --origin=origin --config=user.name=Melange Build --config=user.email=melange-build@cgr.dev --config=advice.detachedHead=false --branch=v0.7.3 --depth=1 https://github.com/tlwg/fonts-tlwg /tmp/tmp.rGr9C8
[git checkout] execute: cd /tmp/tmp.rGr9C8
[git checkout] tar -c . | tar -C "/home/build" -x
[git checkout] execute: cd /home/build
[git checkout] execute: git config --global --add safe.directory /home/build
[git checkout] execute: git fetch --quiet origin --depth=1 --no-tags +refs/tags/v0.7.3:refs/origin/tags/v0.7.3
[git checkout] execute: git checkout --quiet origin/tags/v0.7.3
[git checkout] tag v0.7.3 is a2d3f66b3004276232eb279c3392758c05bcc279
+ aclocal
+ automake --add-missing
configure.ac:7: installing './install-sh'
configure.ac:7: installing './missing'
Makefile.am: installing './INSTALL'
parallel-tests: installing './test-driver'
+ autoconf -f
checking for a BSD-compatible install... /usr/bin/install -c
checking whether sleep supports fractional seconds... yes
checking filesystem timestamp resolution... 2
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking xargs -n works... yes
checking for a Python interpreter with version >= 3.7... python3.13
checking for python3.13... /usr/bin/python3.13
checking for python3.13 version... 3.13
checking for python3.13 platform... linux
checking for GNU default python3.13 prefix... ${prefix}
checking for GNU default python3.13 exec_prefix... ${exec_prefix}
checking for python3.13 script directory (pythondir)... ${PYTHON_PREFIX}/lib/python3.13/site-packages
checking for python3.13 extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib/python3.13/site-packages
checking python3.13 module: fontforge... no
configure: error: failed to find required module fontforge
failed to build package: unable to run package font-tlwg pipeline: unable to run pipeline: exit status 1

[sergiodj]

This will require fontforge (or more specifically py3-fontforge) to become multi versioned. I'm working on it.

[sergiodj]

Leaving my findings and thoughts here before I crash. Maybe I should open a separate bug for this multiversion thing...

Anyway, I was able to make fontforge shared objects to compile against different Python versions (cmake -DPython3_EXECUTABLE=/usr/bin/python3.xx . inside the build directory), but there are a few caveats:

• The fontforge binary also links against libpython. This means that we'll end up with multiple versions of the same binary, but I don't think we should apply the multiversion strategy to its package. Instead, I think we should ship only the the binary linked against the latest Python version (which is the first binary that gets built anyway).
• The .so files are correctly linked against each Python3 version, but unfortunately upstream doesn't make use of any Python build system for that. Instead, they just rely on cmake. This means that I'll have to do the renaming of each library myself (e.g., libfontforge.so.4 -> libfontforge.so.4.py3xx-ARCH_TRIPLET.so) in order to mimic what setuptools does, and to avoid file conflicts between the multiversioned packages. This is somewhat hacky...
• Because we can't rely on the pypi pipeline to install the right Python for us, I'll probably need to explicitly depend on the python-3.xx-base-dev packages.

I'll continue working on this tomorrow.

[sergiodj]

This has been fixed by #43255 .