Hi,

can you please trigger a binNMU of tetrinetx for reproduce.d.n:

nmu tetrinetx_1.13.16-22 . armhf . unstable . -m "Rebuild to fix Depends:"

We currently have this diff:

Hi Jochen

I see similar in the build log of tetrinetx 1.13.16-21 [1]:

 Package: tetrinetx
 Version: 1.13.16-21
 Architecture: armhf
 Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
 Installed-Size: 192
 Depends: libadns1t64 (>= 1.5.0~0), libc6 (>= 2.38)

... but not in the build logs of -20 or -19.

I've scheduled the binNMU anyway, in case it helps resolve the issue,
or with debugging.

Regards
Graham


[1] https://buildd.debian.org/status/fetch.php?pkg=tetrinetx&arch=armhf&ver=1.13.16-21&stamp=1778025492&raw=0

Control: reassign -1 dpkg
Control: retitle -1 Randomness in dependencies when symbols with different but equal versions are used

The same happened on hppa, which rules out a bit flip.

The root cause is in dpkg.

I do not understand the source of non-determinism in the output,
but symbols with different but equal versions are used by tetrinetx:

$ dpkg --compare-versions "1.5.0~0" "=" "1.5.0~"
$ echo $?
0
$

cu
Adrian

[ Leaving most of the context intact for the adns maintainer. ]

Hi!

So the cause for this seems to stem from the adns symbols file
containing most symbols with 1.5.0~ and a couple with 1.5.0~0
versions.

Depending on how the symbols appear in the reverse dependency
binaries, then the emitted versions would be either one of those.

I think this should be fixed in adns, because this seems to be
currently triggering "undefined behavior" from dpkg-dev tools.

Then while pondering whether this should also be improved or changed
in dpkg-dev tools, I thought there were two potential main avenues
(or variations over these):

  a) The tools could normalize the versions, so that versions that
     are version-wise equal, but string-wise different would not
     cause this kind of problem. This would diverge from our current
     version handling which is "preserving", and could have unintended
     fallout. I don't think this is the correct way to go.

  b) The tools could start doing version-wise comparisons, and if
     the versions are equal, then do a string-wise comparison for
     sorting purposes. While this would preserve the versions and
     would solve this kind of problem, it seems rather cumbersome,
     and then we'd need to make any other tool evaluating versions
     do the same. So this does not look enticing either.

     Also similar issues can be triggered for example with versioned
     dependency simplification when combined with substvars generation
     (where different substvars could be generated in random order).

So, I think just keeping it as "undefined behavior" from dpkg PoV
looks fine to me, unless someone has a better idea, and getting adns
fixed should solve this specific issue. The attached diff should
accomplish this.

Thanks,
Guillem

Guillem Jover writes ("Re: Bug#1137222: nmu: tetrinetx_1.13.16-22"):

Thanks for the investigation.  This anomaly seems to have been a slip
by me in 2014.  I'll fix it.

Despite this being simply a mistake in adns, I don't think we could
rule out that a packagae might reasonably end up with a symbols file
with equivalent but textually different entries.  For example,
different symbols entries might be generated by different code paths
for some reason, and happen to specify equivalent but not identical
versions.

I do think that it would be better for dpkg-dev to avoid introducing
nondeterminism when it has to choose betweeen equivalent alternatives.

(The phrase "undefined behaviour" is a red flag to me.  It's from C,
which is by now rightly notorious for providing the programmer with a
hostile environment full of gotchas.  I don't really think you mean
that anyway, since "undefined behaviour" might mean "delets all your
files".)

When there are multiple outputs that are conxistent with the input,
and correct, think it's fine for dpkg-dev to make an abitrary choice.
But it would be nice if the output were reproducible.  That mostly
just means avoiding having it depend on randomness, time, etc.

IDK the precise dpkg-dev algorithms here, but the root of the
nondeterminism is probably perl hashes.  When building packages, we
should probably disable perl's hash randomisation feature.  That
exists to avoid complexity attacks; it doesn't make sense in a source
package build which can in any case execute arbitrary computations.

So perhaps something somewhere should be setting PERL_HASH_SEED=0.

I think this is a bad idea.  The fact that two version numbers are
equal for the purposes of version comparison doesn't mean we can
substitute one for the other, in general.

I think it was probably a mistake (my mistake) to treat "0" and "00"
as equal for version comparison.  That's whaat leads to the
possibility of different strings comparing equal, leading to the
distinction between textual-identicalness and equivalence.  But that
ship has sailed a long time ago.

This does seem invasive, indeed.

But if we can avoid the original source of the nondeterminisim then we
could perhaps make the output unpredidtable but still stable under
rebuilds using the same inputs.

Ian.