Bug#840908: Uscan's Sourceforge reflector is too naive
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 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. >... This is not a Debian perceptions, it is just bad when published tarballs with different names carry the same contents. And based on real-life experience in companies, I can tell you that even "we are doing it this way for 20 years" does not necessarily imply that there is (or ever was) any defensible reason... The uscan issue might be fixed due to quick action by Paul, but could you anyway ask upstream to switch to a unique naming scheme? It is really hard to imagine any defensible reason for naming the daily snapshot from master boost_1_62_0.tar.bz2 instead of something like boost_1_62_0_master_20161015.tar.bz2 > Best, > -Steve cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#840908: Uscan's Sourceforge reflector is too naive
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/\+dfsg$//" \ http://sf.net/boost/ .*/[.\d]+/boost_([\d_]*)\.tar.bz2 Note the space after the redirector URL. Note the numerical directory match, it needs adjusting if you want alpha/beta. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#840908: Uscan's Sourceforge reflector is too naive
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 signature.asc Description: This is a digitally signed message part.
Bug#840908: Uscan's Sourceforge reflector is too naive
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 two issues here: The redirector was designed in the days when there were no directories on the sf.net files section. I'm going to try adding links that include the path, existing links will need to remain for backwards compatibility. Your upstream isn't naming snapshot tarballs correctly. This should be fixed either in boost upstream or in the boost watch files. Modifying the boost watch file is dependent on the fix for the above issue. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#840908: Uscan's Sourceforge reflector is too naive
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 reflector is a proxy for the RSS feed and indeed both URLs are present: https://sourceforge.net/projects/boost/files/boost/snapshots/master/boost_1_62_0.tar.bz2/download https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.tar.bz2/download 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. [1] https://qa.debian.org/watch/sf.php/boost/ [2] https://sourceforge.net/projects/boost/files/boost/snapshots/master/boost_1_62_0.tar.bz2/download [3] https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.tar.bz2/download [4] https://lists.debian.org/debian-devel/2016/10/msg00292.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
