I just hit two packages which gave me the following warning when
pkg_resources tried to load them:

/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is an invalid version and will not be supported in a future release
  warnings.warn(

(and a different version number in the other case).  The upstream
Python developers have a clear idea of what is accepted as a version
number, and it appears in
/usr/lib/python3/dist-packages/pkg_resources/_vendor/packaging/version.py
(in the python3-pkg-resources package) in the definition of
VERSION_PATTERN.

The version number that is being examined is that stored in
/usr/lib/python3/dist-packages/*.egg-info or
/usr/lib/python3/dist-packages/*.egg-info/PKG-INFO on the line
beginning "Version: ".

This appears to be a fairly rare bug: only two packages on my system
have this issue (and I've just reported bugs against them).
Nonetheless, if it is easy, it would be nice to have a lintian test
for it.

Best wishes,

   Julian

This looks strange to me. I wouldn't expect the package version
(especially with the Debian part) to be there.
I see flatbuffers runs `VERSION=$(DEB_VERSION) python$$pv setup.py build`,
I don't know why, or whether this is a good idea.

Some updates on this:

* The version information can also appear in
  /usr/lib/python3/dist-packages/*.dist-info/METADATA
* The upstream standard is defined in PEP 440:
https://peps.python.org/pep-0440/

I agree, flatbuffers is doing weird stuff.

Best wishes,

   Julian

RC error, as it prevented other packages from loading:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036947

So if this check is implemented, it should probably raise an lintian
Error if a package fails this check.  (The related feature request
#1005043 should probably only raise a warning.)

Best wishes,

   Julian