Recent changes in GitHub releases pages, I cannot check upstream version with uscan. How do you deal with it?
Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
 Recent changes in GitHub releases pages, I cannot check upstream version with uscan. How do you deal with it?
It's not that recent ; here is a working example:
version=4
opts="\
dversionmangle=s/\+dfsg.*$//,\ filenamemangle=s/.+\/[vV]?(\d\S+)\.tar\.gz/coq-$1\.tar\.gz/,\ repack,repacksuffix=+dfsg,\
" \
https://github.com/coq/coq/tags .*/[vV]?(\d[^\s+]+)\.tar\.gz
julien.puydt@gmail.com, le lun. 19 sept. 2022 18:00:37 +0200, a ecrit:
Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
Recent changes in GitHub releases pages, I cannot check upstream version with uscan. How do you deal with it?
version=4
opts="\
dversionmangle=s/\+dfsg.*$//,\ filenamemangle=s/.+\/[vV]?(\d\S+)\.tar\.gz/coq-$1\.tar\.gz/,\ repack,repacksuffix=+dfsg,\
" \
https://github.com/coq/coq/tags .*/[vV]?(\d[^\s+]+)\.tar\.gz
That works for the tags page, but not for the releases page... The
problem is that the tags page only contains snapshots of the repository,
and not an autoconf-ed tarball.
That works for the tags page, but not for the releases page... The
problem is that the tags page only contains snapshots of the
repository,
and not an autoconf-ed tarball. For instance since recently uscan
cannot
get the correct tarballs from
https://github.com/brailcom/speechd/releases
Recent changes in GitHub releases pages, I cannot check upstream
version with uscan. How do you deal with it?
The problem is that the tags page only contains snapshots of the
repository, and not an autoconf-ed tarball.
Hi, what I usually do with GitHub is to use its API, since it has the advantage of not breaking uscan when they do changes to the web UI.
Hi, what I usually do with GitHub is to use its API, since it has the advantage of not breaking uscan when they do changes to the web UI.
The GitHub pages are also paginated, so you get the same issue whether using the API or not.<div dir="auto"><br></div><div dir="auto">I have been hit by this on cases where upstream does enough beta|rc|snapshots releases such that the latest GArelease gets in the second page and uscan fails due to not finding it.</div></div>
On Tue 20 Sept 2022, 01:39 Paul Wise, <pabs@debian.org> wrote:
On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote:
Hi, what I usually do with GitHub is to use its API, since it has the advantage of not breaking uscan when they do changes to the web UI.
Since the API uses pagination, this has the minor downside of making it harder to use the uscan --download-version option with older versions.
The GitHub pages are also paginated, so you get the same issue whether
using the API or not.
On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote:
Hi, what I usually do with GitHub is to use its API, since it has the advantage of not breaking uscan when they do changes to the web UI.Since the API uses pagination, this has the minor downside of making it harder to use the uscan --download-version option with older versions.
On Mon, 2022-09-19 at 20:50 +0900, Hideki Yamane wrote:
Recent changes in GitHub releases pages, I cannot check upstream
version with uscan. How do you deal with it?
If you are using the automatically generated tarballs, then
just switching to the uscan git mode seems like the way to go.
On Mon, 19 Sep 2022 at 18:12:15 +0200, Samuel Thibault wrote:
julien.puydt@gmail.com, le lun. 19 sept. 2022 18:00:37 +0200, a ecrit:
Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
Recent changes in GitHub releases pages, I cannot check upstream version with uscan. How do you deal with it?
version=4
opts="\
dversionmangle=s/\+dfsg.*$//,\ filenamemangle=s/.+\/[vV]?(\d\S+)\.tar\.gz/coq-$1\.tar\.gz/,\ repack,repacksuffix=+dfsg,\
" \
https://github.com/coq/coq/tags .*/[vV]?(\d[^\s+]+)\.tar\.gz
That works for the tags page, but not for the releases page... The
problem is that the tags page only contains snapshots of the repository, and not an autoconf-ed tarball.
It's quite noisy and unpleasant, but here's the best I could come up with:
https://salsa.debian.org/debian/bubblewrap/-/blob/debian/latest/debian/watch (my upstream here uses tags like v1.2.3, adjust as necessary if yours doesn't)
or if you need to repack for DFSG reasons: https://salsa.debian.org/sdl-team/libsdl2/-/blob/master/debian/watch
(in this case my upstream uses tags like release-1.2.3)
smcv
<br></div><div>What is the process to find an agreement on which updated version should be published on the wiki [2] ?</div><div><br></div><div>Thanks,</div><div>Riccardo</div><div><br></div><div>[1]Â <a href="https://github.com/volans-/gjson-py/blob/debian/debian/watch">https://github.com/volans-/gjson-py/blob/debian/debian/watch</a></div><div>[2]Â <a href="https://wiki.debian.org/debian/watch#GitHub">https://wiki.debian.org/debian/watch#GitHub</a></div></div>
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] ?
On Sun, Oct 9, 2022 at 7:06 PM Volans <volans.ubuntu@gmail.com> wrote:
I've encountered the same problem and come out with a version of thewatch 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@ ifthat'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'seasily adaptable to different formats.
What is the process to find an agreement on which updated version shouldbe 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/<user>/<project>/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/<user>/<project>/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
For now I'll probably upload to the release page the signatures of both files, but this is definitely suboptimal. </div><div><br></div><div>Riccardo</div><div><br></div><div>[1] <a href="https://api.github.com/repos/{OWNER}/{REPO}/tarball/{RELEASE}">https://api.github.com/repos/{OWNER}/{REPO}/tarball/{RELEASE}</a></div><div>[2] <a href="https://codeload.github.com/{OWNER}/{REPO}/tar.gz/refs/tags/{RELEASE}">https://codeload.github.com/{OWNER}/{REPO}/tar.gz/refs/tags/{RELEASE}</a></div></
</div>
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 147:26:13 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,730 |