While performing a package review, I noticed that rpmlint doesn't like
Source URL's that point to github. Rpmlint emits a 'file-size-mismatch'
warning for the package I am reviewing, and a quick google search
highlights additional package reviews with github source URL's having
the same issue. I've not yet seen a recommended resolution in the other
package reviews, so I thought this might be appropriate for the list.
I see the following warning ...
$ rpmlint -i nagios-plugins-rhev-1.0.0-2.fc16.src.rpm
nagios-plugins-rhev.src: W: file-size-mismatch nagios-plugins-rhev-1.0.0.tar.gz = 9941,
The size of the file in the package does not match the size indicated by
peeking at its URL. Verify that the file in the package has the intended
A quick inspection of --verbose output from curl made me believe that a
redirect might be confusing rpmlint ...
< HTTP/1.1 302 Found
< Server: nginx/1.0.4
< Date: Wed, 24 Aug 2011 12:10:07 GMT
< Content-Type: text/html; charset=utf-8
< Connection: keep-alive
< Status: 302 Found
< X-RateLimit-Limit: 100
< X-RateLimit-Remaining: 100
< X-Runtime: 108ms
< Content-Length: 158
I adjusted the SourceURL in the spec file to the redirected URL, but the
original problem remains.
I'm confused, curl seems to think everything matches (size=9941)...
$ curl -v
< HTTP/1.1 200 OK
< Content-Length: 9941
But rpmlint is still upset ...
nagios-plugins-rhev.src: W: file-size-mismatch
nagios-plugins-rhev-1.0.0.tar.gz = 9941,
Looking into rpmlint a bit further, abstractCheck::check_url() is
discovering a content-length of 1. When I check the value of
'Content-Length' using urllib2.urlopen ... I get the expected value.
I suspect something is amiss with rpmlint abstractCheck and the custom
_HeadRequest.get_method(). Removing it, resolves the problem. Perhaps
I should take this to the rpmlint development list as it seems related
to an intentional upstream fix