Hello everybody, During the last few days I've been submitting patches for some of the reports filled in my MBF of watch files. While fixing watch files I've encountered some upstream homepages are moved to an other server and other similar situations which prevent the watch files from doing their job. In some of the watch files I found the project at sourceforge, so I made them use the sf redirector. But in other cases I only found the project at freshmeat. Because of freshmeat's design it is not possible to directly use it in the watch files, that's how I came up with freshmeat.php[1]. I tried to make the freshmeat script (not really a redirector) very similar to sf's. So this is how it would be used (currently available here[2] to see it in action, but be warned I don't plan to keep it there) if my proposed changes[3] to uscan are also integrated: http://debian.freshmeat.net/projectName/branchID/projectName-(.*)\.tgz Example: http://debian.freshmeat.net/gringotts/71681/gringotts-(.*)\.tgz Some notes on the script (cons): * It downloads an xml file on every request (except when the final file is requested) * It is unable to report older versions (freshmeat-side, I can't do anything about it) * Branch id is required (otherwise a more extended and not so funny watch file is required) * Current regexes for input checks may be too strict (/^[a-z0-9\-\_\.]*$/Di) Some notes on the script (pros): * Finally watch information can be retrieved from freshmeat :) * Generated file names are consistent Possible solutions to the cons: * XML download: the script is able to use a caching/mirroring server by modifying the value of $baseUrl to something like http://cache.server.tld/freshmeat.net/projects-xml * Old versions: do we really need this? anyway: when the script fetches the xml file and parses it, the reported version could be stored, so future calls to the script will make it also report those old *known* versions. * Rest: it can all be tweaked (except for the branch id stuff) When should it be used: * Upstream's homepage is likely to change (e.g. already did in the past) * It doesn't have a sf.net/berlios/similar project account OR it doesn't release the files there (already seen that) * Upstream is known to keep the freshmeat project updated. Quoting part of the conversation from #debian-qa after announcing the creation of freshmeat.php to answer some possible questions: <Rhonda> Atomo64: Some doevs move their homepage. So? Maintainers are meant to stay in contact with upstream and know about those moves. Redirecting it through freshmeat (which, I have to repeat myself, is way too often totally neglected and lacking behind *immensly*) doesn't help much, is the wrong way to fix that problem, and gives a wrong impression, IMNSHO <Atomo64> Rhonda: yes, but I think nobody wants a package to be rebuilt just because a change in the watch file. But if the watch file isn't updated accordingly then it will fail to do its job <Rhonda> Atomo64: What's the problem with updating the watchfile in the package's VCS? <Atomo64> Rhonda: watch files aren't retrieved from VCS' <Rhonda> Atomo64: Erm, why should they be retreived from VCS? Aren't people doing uscan in their own local checkouts? <Rhonda> Again, you have still totally ignored that freshmeat projects are more then regularly hopelessly outdated and lacking behind. <Atomo64> Rhonda: that's not the rule for every project <Atomo64> and I've seen it, some projects even have their sf.net project but they don't upload any package there, and all is tracked at freshmeat Some notes regarding Rhonda's last message: It _is_ my _intention_ to fill bug reports when there's a new upstream version available. I'd like to stress the point that it is only my _intention_ so I'll post about that on -devel and here (-qa) when the right time comes to let anyone share their opinion and based on that take the final decision. Please don't comment about this topic yet. Now, as a reply to Rhonda: I don't believe watch files are stored under debian/ just to wait for some maintainer (or the current maintainer) to download the source and check if there's an upstream version available. And it isn't the case, that information is displayed on qa.debian.org/developer.php and dehs.alioth.debian.org and both report the results of the watch file of the source package in the archive, never from the VCS nor a local watch file. The conclusion to this is that the watch file on the archive needs to work as expected, and if upstream's homepage is 'regularly' moved from one server to an other then it becomes a perfect candidate to use the freshmeat.php script. There might also be some packages which may benefit from this script when upstream's tarball doesn't contain the version number/identifier. Since the freshmeat script generates the file names based on the project name and the project version, it is possible to use it for such cases. I think this is it. Any kind of feedback is very welcomed :-) [1] see the attached freshmeat.php file [2] http://deb.atomo64.puffinhost.com/freshmeat.php/ [3] see the attached uscan.patch file Kind regards, Raphael Geissert -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
Attachment:
freshmeat.php
Description: application/php
Index: uscan.pl
===================================================================
--- uscan.pl (revision 841)
+++ uscan.pl (working copy)
@@ -745,6 +745,8 @@
# Handle sf.net addresses specially
$base =~ s%^http://sf\.net/%http://qa.debian.org/watch/sf.php/%;
+ # Handle debian.freshmeat.net addresses specially
+ $base =~ s%^http://debian\.freshmeat\.net/%http://qa.debian.org/watch/freshmeat.php/%;
if ($base =~ m%^(\w+://[^/]+)%) {
$site = $1;
} else {
Attachment:
signature.asc
Description: This is a digitally signed message part.