Evgeni Golov <evgeni@debian.org> writes:
> We (lindi, liw and me) had just a short discussion in #-devel, that it
> would be nice to have some sort of Vcs-Upstream-* in debian/control

How many packages are there that are not using a watch file because
upstream does not provide usable tarballs (either no tarballs or they
are behind some changing dynamic web site layout)?

Would it be a completely silly idea to extend uscan to support git in
addition to HTTP and FTP that it currently supports?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 84liz6k9ju.fsf@sauna.l.org">http://lists.debian.org/84liz6k9ju.fsf@sauna.l.org

On Tue, 19 Apr 2011, Timo Juhani Lindfors wrote:
> How many packages are there that are not using a watch file because
> upstream does not provide usable tarballs (either no tarballs or they
> are behind some changing dynamic web site layout)?

quite a few I guess ;-) but for some of them, especially in the land of
GIT, they endup on github and for it is possible to come up with a uscan
rule, e.g.

$> uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
opts="filenamemangle=s/.*/(.*)/pyoptical-$1.tar.gz/" http://github.com/esc/pyoptical/downloads .*tarball/([d.a-z]+)
-- Found the following matching hrefs:
/esc/pyoptical/tarball/0.3
/esc/pyoptical/tarball/0.3
/esc/pyoptical/tarball/0.3
/esc/pyoptical/tarball/0.2
/esc/pyoptical/tarball/0.2
/esc/pyoptical/tarball/0.2
/esc/pyoptical/tarball/0.1
/esc/pyoptical/tarball/0.1
/esc/pyoptical/tarball/0.1
Newest version on remote site is 0.3, local version is 0.3

> Would it be a completely silly idea to extend uscan to support git in
> addition to HTTP and FTP that it currently supports?

I think it would be really nice! also if you consider GIT over http (some
projects might not run git servers). Are you going to match tags?

related nuisance: if tarballs are to generated on the client (uscan) side
from a chosen treeish, they would change from run to run, so uscan then would
be usable only by the main maintainer himself for initial upload of the
revision, and for our DHS to watch for new releases (tags?)


--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110420010238.GI7764@onerussian.com">http://lists.debian.org/20110420010238.GI7764@onerussian.com

On Tue, Apr 19, 2011 at 09:02:38PM -0400, Yaroslav Halchenko wrote:
>
> On Tue, 19 Apr 2011, Timo Juhani Lindfors wrote:
> > How many packages are there that are not using a watch file because
> > upstream does not provide usable tarballs (either no tarballs or they
> > are behind some changing dynamic web site layout)?
>
> quite a few I guess ;-) but for some of them, especially in the land of
> GIT, they endup on github and for it is possible to come up with a uscan
> rule, e.g.

Note that there's githubredir.debian.net (as shown in uscan(1)) which
simplifies making watch files for github projects.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>

On 04/19/2011 09:03 AM, Timo Juhani Lindfors wrote:
> Evgeni Golov <evgeni@debian.org> writes:
>> We (lindi, liw and me) had just a short discussion in #-devel, that it
>> would be nice to have some sort of Vcs-Upstream-* in debian/control
>
> How many packages are there that are not using a watch file because
> upstream does not provide usable tarballs (either no tarballs or they
> are behind some changing dynamic web site layout)?
>
> Would it be a completely silly idea to extend uscan to support git in
> addition to HTTP and FTP that it currently supports?

And SVN, bzr, hg, CVS, Darcs, did I miss someone?
This is imho the task of the get-orig-source rule in debian/rules (which
needs a generic helper so not everyone has to invent the wheel again,
but thats a different topic).

Regards
Evgeni


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DAE97E9.9040106@debian.org">http://lists.debian.org/4DAE97E9.9040106@debian.org