I'm not raising priority because I'm not 100% certain that the failure is a
mistake in the packaging or a mismatch in our build environment.

If it is a problem on our side, any hint would be appreciated.

During a build of openjdk-21 in Trixie, I encountered the following error:

dh_clean
 debian/rules binary
jtreg_version="$(dpkg-query -f '${Version}\n' -W jtreg)"; \
if ! dpkg --compare-versions 7.3.1+1~ le $jtreg_version; then \
  echo "Error: testsuite requires jtreg 7.3.1+1~ but $jtreg_version is
installed"; \
  echo "Please update the jtreg dependency and regenerate debian/control"; \
  false; \
fi
dpkg: error: --compare-versions takes three arguments: <version> <relation>
<version>

Installing jtreg7 (from Build-Depends) on my system and running

dpkg-query -f '${Version}\n' -W jtreg

Indeed results in an empty string.
The query for the jtreg version happens here:
https://salsa.debian.org/openjdk-team/openjdk/-/blob/openjdk-21/debian/rules#L1145

I suspect that
https://salsa.debian.org/openjdk-team/openjdk/-/blob/openjdk-21/debian/rules#L164
needs an update. Though I honestly am not sure why it assigned jtreg_pkg to
be "jtreg" and not "jtreg7"

I'm somewhat confused by this though. In the build-chroot, with lsb-release
installed, I get:

# lsb_release --codename --short
sid
# # lsb_release --id --short
Debian

as I expected, since our rebuilds found emulating sid (though with the
packages from testing) to be the most reliable path to successful builds.
Here is the complete output from the dpkg-buildpackage run:

Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot
dpkg-buildpackage: info: source package openjdk-21
dpkg-buildpackage: info: source version 21.0.6+7-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Matthias Klose <doko@ubuntu.com>
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh_testdir
dh_testroot
dh_prep
for f in debian/*.in; do \
  f2=$(echo $f | sed 's/JB/openjdk-21/;s/\.in$//'); \
  case "$f2" in debian/control|debian/watch) continue; esac; \
  rm -f $f2; \
done
rm -f debian/*.install debian/*.links debian/*.debhelper.log
dh_testdir
dh_testroot
rm -rf stamps build build-* jtreg-test-output
rm -rf autom4te.cache
rm -f bin/{jtreg.tmwrc,my-jtreg-run,my-xvfb-run,auto*,ifnames}
rm -f buildwatch.pid
rm -f config.log configure.log
dh_clean
 debian/rules binary
jtreg_version="$(dpkg-query -f '${Version}\n' -W jtreg)"; \
if ! dpkg --compare-versions 7.3.1+1~ le $jtreg_version; then \
  echo "Error: testsuite requires jtreg 7.3.1+1~ but $jtreg_version is
installed"; \
  echo "Please update the jtreg dependency and regenerate debian/control"; \
  false; \
fi
dpkg: error: --compare-versions takes three arguments: <version> <relation>
<version>

Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or
'more' !
Error: testsuite requires jtreg 7.3.1+1~ but  is installed
Please update the jtreg dependency and regenerate debian/control
make: *** [debian/rules:1145: pre-build] Error 1
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2
--------------------------------------------------------------------------------
Build finished at 2025-02-14T14:41:29Z

All in all, I wonder why you check the version again in debian/rules when
debian/control already has the proper dependencies?

Kind regards,
Sven

Note; For a reason I don't see, the Debian build happened to have codename
`trixie` - despite the build supposedly having been uploaded to unstable. -
In other words, it didn't see itself as building on `sid`, it saw itself
being built on `trixie`.

Anyhow, the solution to this is rather simple: Remove `sid` from line 164
of debian/rules, similar to how it was done in
https://salsa.debian.org/openjdk-team/openjdk/-/commit/c257671660f03ef6d9c394adfa762d9fcc59db86
for openjdk-22 (and carried forward to openjdk-23, -24 and onwards, I
assume).

Consider pulling the same change into openjdk-21?

Cheers,
Sven

can't reproduce, works fine for me on testing and on unstable.

The difference is in this (from the i386 build in unstable)

========== stamps/configure ==========
mkdir -p bin
command -v autoconf
/usr/bin/autoconf
/bin/uname -a
Linux sbuild 6.1.0-33-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.133-1
(2025-04-10) i686 GNU/Linux
lsb_release -a
Distributor ID: Debian
Description: Debian GNU/Linux trixie/sid
Release: n/a
Codename: trixie

In our builds, the last line would be:
Codename: sid

The other openjdk-2* packages have a different comparison in
debian/rules line 165 (well, or close to that line) to select the
jtreg package to compare to, which doesn't include `sid` but only
bookworm and bullseye - which makes them select jtreg7 to query dpkg
for later on - and the builds in Debian itself apparently also
correctly select jtreg7 because the codename is (somewhat
incorrectly?) set to `trixie`. I'd appreciate if you could remove sid
from that line in the openjdk-21 package. To Debian builds, it
obviously doesn't matter (because the codename in unstable builds is
set to trixie), but for anyone attempting a build on a system that has
Codename:sid, it would.