Re: Changed Github download URLs are affecting lots of existing watch files
Hi Bart,
On Sat, Mar 27, 2021 at 07:38:17AM +0100, Bart Martens wrote:
> On Fri, Mar 26, 2021 at 11:43:27PM +0100, Yadd wrote:
> > Le 26/03/2021 à 22:38, Andreas Tille a écrit :
> > > Any idea what to do (besides uploading all packages obtained from
> > > Github right after the release)?
> >
> > This breaks also more than thousand package from JS Team.
> >
> > We could perhaps handle that with uscan then each time GitHub changes
> > its website, only uscan should be updated.
>
> Yes. Or maintain watch files outside the packages.
Fine for me - but what is our QA tool chain using. As far as I know
tracker.d.o and other tools are relying on UDD and the information is
fed from the uploaded watch file. Or am I wrong with this assumption?
> Or use "fakeupstream.cgi"
> for popular platforms like github.
> https://salsa.debian.org/qa/qa/blob/master/cgi-bin/fakeupstream.cgi
For the moment there are four suggestions for watch files maintained
inside the package:
1. use the string suggested in `man uscan`
https://github.com/<user>/<project>/tags (?:.*?/)?v?(\d[\d.]*)\.tar\.gz
2. enable uscan to interpret some @GITHUBREGEX@
3. asking for a new github redirector on qa.debian.org as there
is for sf.net (or PyPI)
4. use "fakeupstream.cgi" (this service is new to me)
All suggestions sound promising to me to be more sustainable than the
current situation. For sure it would mean editing *lots* of d/watch
files (and upload once the new release cycle will start) I wonder
whether we could come up with some suggestion which of these (or may
be even other suggestions?) is the most promising one and all those
who now feel forced to change their watch files will possibly change
to the same string (automatically) instead of picking a random option.
I admit my prefered way would be to do this via lintian-error plus
lintian-brush to cure the issue.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: