Hi,

For unstable (and presumably experimental) the current binNMU version is
exposed via the Binary-NMU-Version field, allowing a version for a
subsequent binNMU to be deduced by simply incrementing the field; this
is what "wb" uses for that purpose.

The Binary-NMU-* fields are not exposed for testing and stable, so this
auto-detection always results in binNMU 1 being scheduled, with
unhelpful results if the current version in those distributions was a
binNMU.

Please make the interface consistent across all suites.

Regards,

Adam

This demo only lasts as long as 'xz-utils' has binNMUskew. Pick any
other package that currently does to demonstrate the issue:

This URL (for unstable) shows binNMU versions in the 'Version' column
https://buildd.debian.org/status/package.php?p=xz-utils&suite=sid
Thus URL (for jessie) only shows the base version
https://buildd.debian.org/status/package.php?p=xz-utils&suite=jessie

This does not seem to be a bug in pgstatus, which just displays what
the database returns.

Clearly it is a different manifestation of the above 'wb nmu' issue

I just spent some time perusing the pgstatus and wanna build
sources. I didn't find anything in pgstatus which special-cases by
suite when displaying package.php. It just asks the database for
version and binary_nmu_version and displays those.

So, unsurprisingly, this seems to be in wanna-build.

Wookey

That's normal and a long-standing "issue". Is there a problem with this except
cosmetics? We don't claim to export the authoritative source of binary versions
of source packages. (Obtaining it is left as an exercise to the reader, as
every package can have a different binary version number. A rebuild might
theoretically stop producing a certain binary package, etc. That being said,
Installed-Version aka installed_version is what "wb nmu" actually uses to
determine the next NMU version to use - because wanna-build does not
actually know.)

Kind regards
Philipp Kern