The recent libffi upload didn't build successfully on ppc64el, with
symptoms not matching the other FTBFS bug I reported today. From the
buildd log
<https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=ppc64el&ver=3.7.1-1&stamp=1783944229&raw=0>:
--- debian/libffi8.symbols (libffi8_3.7.1-1_ppc64el)
+++ dpkg-gensymbolsjufNPp	2026-07-13 12:03:47.533467105 +0000
@@ -4,5 +4,9 @@
  (symver)LIBFFI_CALL_PLAN_8.4 3.7
  (symver)LIBFFI_CLOSURE_8.0 3.4
  (symver|arch=!arc !hppa !ia64 !m68k !loong64 !any-mips !any-mipsel !any-mips64 !nios2 !powerpc !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_8.0 3.4
+ LIBFFI_COMPLEX_8.0@LIBFFI_COMPLEX_8.0 3.7.1-1
  (symver|arch=!arc !hppa !ia64 !m68k !nios2 !sh4)LIBFFI_GO_CLOSURE_8.0 3.4
- (symver)LIBFFI_INT128_8.3 3.7
+#MISSING: 3.7.1-1# (symver)LIBFFI_INT128_8.3 3.7
+ ffi_type_complex_double@LIBFFI_COMPLEX_8.0 3.7.1-1
+ ffi_type_complex_float@LIBFFI_COMPLEX_8.0 3.7.1-1
+ ffi_type_complex_longdouble@LIBFFI_COMPLEX_8.0 3.7.1-1

In addition to the LIBFFI_INT128_8.3 symver not being present as
expected (same as in the other FTBFS bug report), it seems that the
LIBFFI_COMPLEX_8.0 symver has been added, on this architecture only.

Perhaps ppc64el gained a feature in this release that was previously
only supported on a few architectures like x86 and ARM? If so, removing
ppc64el (and possibly other architectures) from the negative
architecture list might solve this.

buildd logs for big-endian powerpc and ppc64 don't seem to be available,
so I can't tell whether those -ports architectures have the same failure
mode.

Thanks,
    smcv

Version: 3.7.1-2

Appears to have been fixed by:

libffi (3.7.1-2) unstable; urgency=medium

   * Conditionalize new symbols on architectures.