On Wed, Nov 07, 2007 at 09:09:34AM -0000, Adam D. Barratt wrote: > Hi, > > Debian Bug Tracking System wrote: >> Processing commands for [EMAIL PROTECTED]: >> >>> severity 449972 wishlist >> Bug#449972: libdns-zoneparse-perl: debian/watch fails to report >> upstream's version >> Severity set to `wishlist' from `minor' > > To save others having to find the missing context, the "problem" Ivan's > referring to is that CPAN connection-limit their FTP server by returning a > 500 response, which uscan (quite reasonably imo) treats as an error. For > example: > > ---- > uscan warning: In watchfile /tmp/libdns-zoneparse-perl_watchiMHNlb, reading > FTP directory > ftp://ftp.cpan.org/pub/CPAN/modules/by-module/DNS/ failed: 500 Sorry, > there are already 2 users from 217.196.43.134 logged on. Try again in 10 > minutes. > ---- > > I can see two issues with attempting to treat the above as a temporary > error: > > a) The textual part of the message will vary from server to server. Even if > we make uscan match the message style quoted above, that won't help with > non-CPAN servers.
Just because the message will very and we can't necessarily parse every conceivable future message doesn't mean there isn't lots of useful information to be gained with a few simple regexen to match some common FTP servers, don't you think? > b) It's not a temporary error. FTP response codes of 5xx are defined as > permanent errors which should not be retried without a human checking that > the situation has changed since the error was generated. 500 specifically > is "syntax error or command unrecognised". IMHO, CPAN should really be > returning "421 Service not available" in this case. I agree that it might not be the correct error code. Nevertheless, the message makes it pretty clear that it is a temporary / retriable error and I think we should treat it as such (I don't think the alternative of trying to change the way FTP software works at upstream repositories and mirrors around the world instead is particularly realistic). If uscan provided (for example) a separate exit status or some other method of providing this information to the tools that in turn use uscan to find bad watchfiles, they could provide more accurate results. This certainly isn't an bug in the watch file of every individual Perl library package! Since folks are now using "Debian Health Status" output generated using uscan to file bugs against packages, that pretty clearly points to the need for a smarter uscan, that deals with upstream repositories as they're found in the real world and gives the bulk tools using uscan's output the ability to retry temporary failures before considering watch files bad. Well, that's what I'm wishing for, anyway. :) -- _ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
