On Tue, Oct 11, 2022 at 10:23 AM Stephan Lachnit
wrote:
> On Sun, Oct 9, 2022 at 7:06 PM Volans wrote:
> >
> > I've encountered the same problem and come out with a version of the
> watch file using the GitHub APIs. In my case I also needed to download the
> PGP signature. I've add some comments to the watch file for an easier
> understanding.
> >
> > The approach should be generic enough to work for others [1].
> >
> > The package name in the URL could also be replaced with @PACKAGE@ if
> that's the same of the GitHub project name.
> > In my case too, tags are prefixed with a 'v' (i.e. v1.2.3), but that's
> easily adaptable to different formats.
> >
> > What is the process to find an agreement on which updated version should
> be published on the wiki [2] ?
>
> I mentioned it before, one should increase the limit of results per
> page to the maximum (which is 100).
> Also I don't think using `@PACKAGE@` is a good idea inside the URL as
> it is maybe different from the Debian source package name.
>
> For releases I use something like (w/o signatures):
> ```
> version=4
> opts="searchmode=plain,\
> filenamemangle=s%v?@ANY_VERSION@%@PACKAGE@-$1.tar.gz%" \
> https://api.github.com/repos///releases?per_page=100 \
> https://api.github.com/repos/[^/]+/[^/]+/tarball/v?@ANY_VERSION@
> ```
> For tags:
> ```
> version=4
> opts="searchmode=plain,\
> filenamemangle=s%v?@ANY_VERSION@%@PACKAGE@-$1.tar.gz%" \
> https://api.github.com/repos///tags?per_page=100 \
> https://api.github.com/repos/[^/]+/[^/]+/tarball/refs/tags/v?@ANY_VERSION@
> ```
>
> One could probably combine the tarball search link into a unified
> regex expression, didn't try that yet.
>
> Overall I agree that the Github API thing should be documented in the
> Wiki and in the uscan man page.
>
> Cheers,
> Stephan
>
Sure, I agree for the API page size, thanks for the suggestion.
To add some additional burden I noticed that the archive downloaded from
the API [1] is different from the one downloaded from the browser [2]
because they have a different top-level directory name, while the API one
has:
{OWNER}-{REPO}-{REF_SHA1}/
where REF_SHA1 is the SHA1 of refs/tags/{TAG_NAME}, the browser one has:
{OWNER}-{VERSION}/
where, at least in my case, VERSION is the tag name without the leading
'v'. For a tag name of 'v0.2.0' I get 'gjson-py-0.2.0.tar.gz' that
extracted creates 'gjson-py-0.2.0/' (note the lack of 'v' in the names).
Because of the two different directory structures, the tar.gz files are
different so any md5 or gpg signature verification made on one would fail
with the other, adding additional confusion or complexity.
For now I'll probably upload to the release page the signatures of both
files, but this is definitely suboptimal.
Riccardo
[1] https://api.github.com/repos/{OWNER}/{REPO}/tarball/{RELEASE}
[2] https://codeload.github.com/{OWNER}/{REPO}/tar.gz/refs/tags/{RELEASE}
