[07:17] <LocutusOfBorg> hello mwhudson, I syncd vulture... the delta seems useless now, can you please also look at your other merges? zope.testing, golang-* :) thanks!
[07:26] <LocutusOfBorg> mwhudson, I also syncd python-tornado, the testsuite seems fixed in debian, the timeout has been increased via patch
[17:48] <ginggs> juliank: hi, if you have a chance, would you have a look at LP: #1713615 ?  the ubuntu version of ttf-mscorefonts-installer uses package-data-downloader which uses apt-helper. do you think this is a bug in apt?
[20:47] <juliank> ginggs: apt does not follow https->http redirects by design
[20:49] <juliank> but that was not the issue last times
[20:49] <juliank> here too
[20:49] <juliank> It redirects to a failed mirror page, so it would not work anyway
[21:00]  * juliank tried three times, works just fine
[22:15] <tomreyn> in case it helps, this is my understanding from past years of using SF.net:  sf mirrors would redirect to http://downloads.sourceforge.net/mirrorproblem?... only if the requested file should have been present at the requested mirror location but was not (due to mirroring issues) or had an incorrect checksum. also, this event triggers / schedules a redistribution from the master mirror to the download mirror. it's not possible to reproduce
[22:15] <tomreyn> it with a non-existant file location. also SF.net no longer seems to disclose which mirrors do not have a file (they did in the past), only the number of mirror servers which have it (and that only to project admins). so reproducing this will be difficult (the only way i can think of is to create a new file on some project and request this file from download mirrors before it has been distributed).
[22:18] <tomreyn> the redirection ot a plain http:// url seems like a bug to me, though (unless it is to rule out client TLS side issues), /mirrorproblem is also available via HTTPS and should probably be used as the redirection target instead.