Hi,

if the Github templates are supposed to make things any easier, then
they lack docs. I understand that it is darn hard to track packages on
github since there are so many ways to do it right, but if that's not
possible, then the docs should not suggest that using v5 and the github
templates will solve all pains with versionmangle and ever-changing
links.

aide (https://github.com/aide/aide/releases/tag/v0.19.3) does tag
and sign releases, but runs autoreconf and some version poking before
building the release tarball. They do not commit the tree the tarball
represents. I understand that this is a rather common method to release
software that uses GNU autotools.

Neither
Version: 5

Template: GitHub
Owner: aide
Project: aide

nor
Version: 5

Template: GitHub
Release-Only: yes
Owner: aide
Project: aide

do properly pick up the release tarball. Instead, they pull a
synthesized tarball from
https://api.github.com/repos/aide/aide/tarball/refs/tags/v0.19.3
does not match what upstream actually released, breaking both their
published checksums and their signatures.

If it is not the Intention of the GitHub templates to pull tarballs
manually prepared by upstream, this should be documented.

If this is a user error, please close this bug with the reference to a
documentation patch so that I can see how the docs were improved.

uscan has been moving so quickly in the last year that it is almost
impossible to find out which docs, blog entries, bug reports, forum or
e-mail discussions match what current uscan is supposed to do.

Greetings
Marc
--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBUILD_LINTIAN=no
DEB_BUILD_OPTIONS="parallel=10"
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -us -uc -j10"
DEBUILT_LINTIAN_OPTS="-i -I --show-overrides"
DEBSIGN_KEYID=mh+debian-packages@zugschlus.de
DEBCHANGE_MULTIMAINT=no
BTS_SENDMAIL_COMMAND="/usr/sbin/exim4 -f mh+debian-packages@zugschlus.de"
BTS_INTERACTIVE=force

Hi,

Indeed, the Github template could be improved.

Even if upstream doesn't manually tune the release tarball before
publishing it, my fear is that someone not used to Debian packaging
practices could download tarballs by browsing a project tags/releases
page, notice that it doesn't match (Github "tags" tarballs include the
commit hash in the base directory's name, so even if the contents is
100% identical, the sum is not) and think "Hey, Debian doesn't use the
tarballs found on Github, something's fishy !".

For now I use this workaround for tags:

```
Download-Url-Mangle:
s%api.github.com/repos/([^/]+/[^/]+)/git/(.*)%github.com/$1/archive/$2.tar.gz%
```

And for releases:

```
Release-Only: yes
Download-Url-Mangle:
s%api.github.com/repos/([^/]+/[^/]+)/tarball/(.*)%github.com/$1/archive/refs/tags/$2.tar.gz%
```

I also don't understand why `Uversion-Mangle: auto` isn't the default,
since `~` is Debian-specific and without it, uscan always considers
pre-releases as newer than the matching final release.

Regards,

Re: Marc Haber

I've had similar problems. My main problem with the documentation is
that general templates stuff (not just github) is distributed over
debian-watch(5) and uscan-templates(5). In fact, the treatment of
templates in debian-watch is *longer* than the whole uscan-templates
documentation, so it looks like one doesn't have to read the latter at
all.

Yet, "Custom-Version" is only documented in uscan-templates. But
debian-watch looks like a full specification of the version 5 syntax,
so when Custom-Version isn't in there, it didn't occur to me at all
that I should be looking at uscan-templates.

The other way round, the default values of options are only documented
in debian-watch, so when one wanted to change something, reading
uscan-templates doesn't really help.

The easiest fix might actually be to nuke uscan-templates(5)
completely and move the few bits that it is adding to debian-watch(5).

Christoph