Unusual suffix added to HTML element IDs for C project (Linux) documentation

[jayaddison]

Hi folks,

Some of the Reproducible Builds test infrastructure for the Debian operating system performs comparative builds of packages with as many variances in the environment/system config as possible to try to eke out any causes of nondeterminism.

The documentation packages produced by building the linux (Linux kernel) source package in Debian are nearing reproducible (deterministic) output, but there are a few quirks remaining.

A quirk that I've encountered for the first time today is that some elements in the HTML documentation output seem to have the letter o added to them. There is currently an example of this at the following URL, although note that this is a somewhat ephemeral hyperlink: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/linux.html

For one of the comparative builds, the HTML output includes an api-obsolete.html page that contains:

<table·class="docutils·align-default"·id="abi-sys-kernel-fadump-enabledo">

...while in the comparison build, the same line instead contains:

<table·class="docutils·align-default"·id="abi-sys-kernel-fadump-enabled">

I briefly wondered whether this could be due to parsing/identification of the fadump-enabled symbol as an unsigned long/integer type -- but the relevant ID/type mapping for that appears in the C++ code of Sphinx, and Linux is (AFAIK) a C project.

Does anyone have any ideas for why this ID suffix might appear, and if so, how I could ensure that the build output remains stable/deterministic between diverse rebuilds such as these?

[jakobandersen]

I think this HTML is related to a reference to a page in the documentation rather than a C symbol (or C++), so the C and C++ domains are probably not responsible for the extra o.
Earlier in the diff you linked there is also

	<li><p><a·class="reference·internal"·href="abi-obsolete.html#abi-sys-kernel-fadump-enabledo"><span·class="std·std-ref">/sys/kernel/fadump_enabled</span></a></p></li>

with the same problem, which points towards looking in the std domain of Sphinx, or in Docutils itself.