Daniel Mendler writes: > Eli Zaretskii writes: > >>> From: Xiyue Deng >>> Date: Mon, 27 Jan 2025 15:22:47 -0800 >>> >>> When trying to build compat 30.0.2.0 using Emacs 28.2 from Debian >>> Bookworm (the current stable release), the build process throws the >>> following error: >>> >>> ,---- >>> | ... >>> | dh binary --with elpa >>> | dh_update_autotools_config >>> | dh_autoreconf >>> | dh_auto_configure >>> | dh_auto_build >>> | make -j2 "INSTALL=install --strip-program=true" >>> | make[1]: Entering directory '/build/reproducible-path/compat-el-30.0.2.0+dfsg' >>> | Compiling compat-25.el >>> | Compiling compat-26.el >>> | Compiling compat-27.el >>> | Compiling compat-28.el >>> | Compiling compat-29.el >>> | Compiling compat-30.el >>> | >>> | In toplevel form: >>> | compat-30.el:28:1: Error: untrusted-content already defined >>> | make[1]: *** [Makefile:81: compat-30.elc] Error 1 >>> | make[1]: *** Waiting for unfinished jobs.... >>> | make[1]: Leaving directory '/build/reproducible-path/compat-el-30.0.2.0+dfsg' >>> | dh_auto_build: error: make -j2 "INSTALL=install --strip-program=true" returned exit code 2 >>> | make: *** [debian/rules:4: binary] Error 25 >>> | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 >>> | -------------------------------------------------------------------------------- >>> | Build finished at 2025-01-27T23:09:47Z >>> `---- >>> >>> This doesn't happen when building using Emacs 29.4 from Debian Trixie >>> (current testing). >> >> Daniel, could you please look into this? > > You can build Compat with (setq compat-strict nil). Compat has strict > checks in place which check that the defined symbols match the reported > Emacs version. These checks are for the purpose of Compat development. I > suspect that Debian has security patches applied which turn Emacs 28.2 > into an Emacs 28/29 mix. See also the report at > https://github.com/emacs-compat/compat/issues/60. > You are right indeed: Emacs in Debian stable has applied a patch in one of its security fixes which introduced this variable[1]. So this is exactly like the Gentoo situation you linked. [1] https://sources.debian.org/src/emacs/1%3A28.2%2B1-15%2Bdeb12u3/debian/patches/0030-lisp-files.el-untrusted-content-New-variable.patch/ > Daniel -- Regards, Xiyue Deng