Bug#840908: Uscan's Sourceforge reflector is too naive

2016-10-16 Thread Adrian Bunk
On Sat, Oct 15, 2016 at 11:06:50PM -0500, Steve M. Robbins wrote: > On Sunday, October 16, 2016 11:48:32 AM CDT Paul Wise wrote: >... > > Your upstream isn't naming snapshot tarballs correctly. This should be > > fixed either in boost upstream > > I know this is the popular Debian perception and

Bug#840908: Uscan's Sourceforge reflector is too naive

2016-10-15 Thread Paul Wise
On Sun, Oct 16, 2016 at 11:48 AM, Paul Wise wrote: > This should be ... or in the boost watch files. Modifying > the boost watch file is dependent on the fix for the above issue. I've now committed the fix, you can use something like this: version=3 opts="uversionmangle=s/_/./g,dversionmangle=s/

Bug#840908: Uscan's Sourceforge reflector is too naive

2016-10-15 Thread Steve M. Robbins
On Sunday, October 16, 2016 11:48:32 AM CDT Paul Wise wrote: > On Sun, Oct 16, 2016 at 10:24 AM, Steve M. Robbins wrote: > > My suggestion is that the ones with "snapshots" in the path are simply > > filtered out from list displayed by the reflector as these are not > > release files. > > That sou

Bug#840908: Uscan's Sourceforge reflector is too naive

2016-10-15 Thread Paul Wise
On Sun, Oct 16, 2016 at 10:24 AM, Steve M. Robbins wrote: > My suggestion is that the ones with "snapshots" in the path are simply > filtered out from list displayed by the reflector as these are not > release files. That sounds like an ugly hack that I would rather not see implemented. The are

Bug#840908: Uscan's Sourceforge reflector is too naive

2016-10-15 Thread Steve M. Robbins
Package: qa.debian.org Severity: normal The uscan download from sourceforge doesn't download what you expect for boost. The reason is that the link provided by the reflector page [1] is incorrect: it leads to a "snapshot" url [2]. The correct URL is [3]. Paul Wise indicated [4] that the reflect