Hi,
Am Thu, Nov 07, 2024 at 11:41:28AM +0100 schrieb Guillem Jover:
> Ah I assumed the sources were being taken from pypi, if they are taken
> from GitHub, then that explains yes. Perhaps using
> https://pypi.org/project/catalogue/#files as the URL for uscan (if uscan
> is happy with that one), would solve that problem? (And if it does,
> then perhaps python packages should be progressively transitioned to
> use pypi URLs to avoid this kind of problem?)
I have *not* inspected the situation personally. However, you might
want to check the difference between the PyPI tarball and the tarball
from Github. In lots of cases these are different and the maintainer
might have picked Github for a reason (which is actually the
recommendation I've read several times on the Debian Python list).
Common cases are missing test suite inside PyPI tarball but maybe other
things as well.
> But I'm thinking that, perhaps the best option is to ask upstream
> directly, whether they are going to release a 2.1.x release soon, or
> if they could do that now, and/or whether they could perhaps
> remove/rename the git tag perhaps (with the implied issues with messing
> with history and git tags being sticky on cloned repos)? As I assume
> other downstreams might be in the same/similar situation?
Sounds sensible - otherwise I'd probably go with the override proposed
by Colin.
Kind regards
Andreas.
--
https://fam-tille.de
