I was checking on Tor like this and it prints a warning:
$ tor --verify-config --hush
Jun 19 13:29:14.005 [warn] Tor was compiled with zstd 1.4.4, but is running
with zstd 1.4.5. For safety, we'll avoid using advanced zstd functionality.

This probably doesn't matter much in practice, but seems quite strange. Is
this a precaution that should be overridden in Debian since the package
management takes care of that with Conflicts/Breaks? See the changelog
excerpts showing the care taken already:

 libzstd (1.4.5+dfsg-2) unstable; urgency=medium
 * Drop ZSTD_LEGACY_MULTITHREADED_API, since nothing in Debian seem to use it

 libzstd (1.4.5+dfsg-1) unstable; urgency=medium
 * New upstream version 1.4.5+dfsg
 * Update symbols file, add ZDICT_getDictHeaderSize and remove all
 ZSTDMT_* symbols, also remove renamed ZSTD_CCtxParam_getParameter and
 ZSTD_CCtxParam_setParameter, no reverse dependencies use any of the
 removed symbols
 * Remove 0018-Alias-renamed-API-symbols.patch since no rdeps use the old
 symbols
 * d/rules: call dh_makeshlibs with -V 'libzstd1 (>= 1.4.5)', since this
 version introduces new public symbols
 -- Alexandre Mestiashvili <mestia@debian.org>  Fri, 05 Jun 2020 10:47:12 +0200

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tor depends on:
ii  adduser         3.118
ii  libc6           2.30-8
ii  libcap2         1:2.34-2
ii  libevent-2.1-7  2.1.11-stable-1
ii  liblzma5        5.2.4-1+b1
ii  libseccomp2     2.4.3-1+b1
ii  libssl1.1       1.1.1g-1
ii  libsystemd0     245.6-1
ii  libzstd1        1.4.5+dfsg-2
ii  lsb-base        11.1.0
ii  runit-helper    2.8.15
ii  zlib1g          1:1.2.11.dfsg-2

Versions of packages tor recommends:
ii  logrotate    3.16.0-3
ii  tor-geoipdb  0.4.3.5-1
ii  torsocks     2.3.0-2+b1

Versions of packages tor suggests:
ii  apparmor-utils       2.13.4-2
pn  mixmaster            <none>
pn  obfs4proxy           <none>
ii  socat                1.7.3.4-1
pn  tor-arm              <none>
pn  torbrowser-launcher  <none>

- -- Configuration Files:
/etc/tor/torrc changed [not included]

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXuz30wAKCRByvHFIwKst
p/94AP9l/7F+4Gwxh1GcovbqlbiaYf0EcVM2x//w9D9hhhtNGQEApHMcfb8848Dj
jhIP3ZY8OPwDr+VPbB06K0BFSw3+owg=
=Ld86
-----END PGP SIGNATURE-----

The same thing has again been popping up for a couple of months, we're
just at a later version of course.

    Tor was compiled with zstd 1.5.2, but is running with zstd 1.5.4. For safety, we'll avoid using advanced zstd functionality.

Unstable actually has 1.5.5 already. Looks like we'd need a rebuild
while there's little pressing incentive; fair enough, as tor itself is
up to date even in Bookworm. May not be a bug at all.


Regards,
Oliver

This bug comes from the system wherever the package is built
it must have some stale older version of libztd or something.

When built on a CLEAN debian-stable, the result is a
binary that used the header of the libzstd version actually available
in debian-stable → it doesn't have this problem.

So. the problem is not the build-scripts, it's not the tor sources
it's the system that used the build scripts.

DO NOT ASK torproject to hide this. fix the issue.

Which is as simple as use a plain debian stable to build, with
the libzstd-dev from stable and it's fine.

Thanks!

I've looked a bit deeper and this is what happened:

the package tor-0.4.7.13 has been built 2023-01-12
at this point bookworm still was testing and in January
bookworm/testing had libzstd-1.5.2

but then libzstd-1.5.4 entered bookworm/testing 2023-02-23
so tor would have needed a rebuild as there is a runtime test
to avoid version mismatch.

Hiding a test result that checks for version mismatch
is NOT a solution in case of version mismatch.

Rebuilding and by that linking with libzstd-1.5.4 is.

I'v seen meanwhile you've built 0.4.8.5 but put it
into testing and backports only.

for bookworm/stable the problem  still exists.

Plus there was a bug fix release, 0.4.7.14 in july
"This version fixes several minor bugfixes and one major bugfix"
https://forum.torproject.org/t/stable-release-0-4-7-14/8493

but for bookworm/stable the problem still exists.

Even in case 0.4.8.5 doesn't fit into debian rules for stable repository,
the upstream 0.4.7.14 is a pure bug fix

3305 out of 7846 tor nodes still use 0.4.7.13 - I guess most of these
just because they trust in debian stable is well maintained.

Please do :)