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 sounds like an ugly hack that I would rather not see implemented. I can't disagree. :-) If I knew how to fix it in the watch file, I would do so. > The are two issues here: > > The redirector was designed in the days when there were no directories > on the sf.net files section. I see. One other thing I will mention is that the current reflector does show two occurrences of "boost_1_62_0.tar.bz2". (And just now it even shows the path and a "direct link" that I'm pretty sure weren't present earlier today!) However, both occurrences link to the same reflector URL [1] that ends up at the wrong URL on sf.net. [1] https://qa.debian.org/watch/sf.php/boost/boost_1_62_0.tar.bz2 > 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 certainly it is a nuisance that the filenames are not unique. All I will say is that the folks releasing Boost are not novices and likely have a defensible reason for their madness. More to the point: it is out there and if uscan can be made more flexible, it would be appreciated. > or in the boost watch files. Modifying > the boost watch file is dependent on the fix for the above issue. OK. Thanks for looking into this! Best, -Steve
Attachment:
signature.asc
Description: This is a digitally signed message part.