On Tue, Jan 05, 2016 at 07:42:14PM +0000, Adam D. Barratt wrote: > On Tue, 2016-01-05 at 12:54 -0500, Daniel Kahn Gillmor wrote: > > 0 dkg@alice:~$ bts --cache --cache-mode=full cache src:gnupg2 > > Downloading http://bugs.debian.org/src:gnupg2 ... (cached new version) > > Downloading http://bugs.debian.org/678613 ... bts: failed to download > > bugreport.cgi?msg=4;mbox=yes;bug=678613, skipping > > bts: failed to download bugreport.cgi?mbox=yes;msg=9;bug=678613, skipping > > (cached new version) 1/116 > [...] > > Sorry to not have more pointers about what's going wrong here. Maybe > > something changed in some perl module about "success" or "failure" > > when the file fetched has 0 length? > > As far as I can tell, nothing's changed in terms of the code - bts has > always regarded a 0-byte file as a failure. The oldest machine I have to > hand to check is wheezy, which has > > if ($response->is_success) { > my $content_length = defined $response->content ? > length($response->content) : 0; > if ($content_length == 0) { > warn "$progname: failed to download $ref, skipping\n"; > > Presumably only "cache-mode=full" causes the "useless messages" to be > downloaded.
Keeping above context for owner@. > What I'm not sure about is whether the BTS has always > presented those files as 0-bytes and, if so, why it bothers linking to > the mbox to begin with; the "full text" (i.e. non-mbox) versions appear > to be populated as expected. Good questions. Maybe debbugs folks have some insight. The bts(1) code has done this since mirroring/cacheing was first implemented, so it's definitely nothing new. However, they may be a little overzealous or maybe were compensating for an issue since fixed in LWP. I'm adverse to changing the check, but I also don't think we need a bunch of zero-length files being mirrored. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <james...@debian.org>
