Description of problem: The new rpmlint version reports invalid-url warning for source references that are not urls, e.g. Source: %{_name}-%{version}.tar.gz results in: $ rpmlint globus-gram-client-tools.spec globus-gram-client-tools.spec: W: invalid-url Source0: globus_gram_client_tools-7.3.tar.gz The description of this warning is: $ rpmlint -I invalid-url invalid-url: The value should be a valid, public HTTP, HTTPS, or FTP URL. Issuing this warning if there is e.g. a git:// or svn+ssh:// url there makes sense, but issuing the warning when the source reference is not a url at all doesn't. There are many reasons why the source reference might not be a url: http://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control http://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code http://fedoraproject.org/wiki/Packaging:SourceURL#Troublesome_URLs Version-Release number of selected component (if applicable): rpmlint-0.94-1.fc12.noarch How reproducible: Always Steps to Reproduce: 1. Run rpmlint on a spec file with a non-url source reference Actual results: rpmlint issues an invalid-url warning. Expected results: No warning. Additional info: This issue did not exist in earlier versions of rpmlint.
This is intentional, we want a warning for all non-URL source archives to alert packagers to check if a URL would exist but is accidentally not used. If there's no URL that can be used for the source archive, just ignore the warning.
I've just hit the same problem. It would seem to me that a better solution would be for rpmlint to support file:// URLs.
I fail to see how file:// URLs in specfiles would make any sense.
"to alert packagers to check if a URL would exist but is accidentally not used" This seems to be a very weak argument. spectool -g and/or rpmbuild and/or mock will clearly break if the source isn't present and cannot be retrieved. Filtering only this exact scenario (no URL just filename) but ensuring other truly invalid URL warnings don't get suppressed is either tedious with a ton of package-specific yet nearly identical filter statements in a global rpmlint config (or all over the place in package-specific rpmlint configs) or a single regex (that is bug free) that suppresses every possibility of this exact error (and again, copy/pasted all over the place into every package-specific rpmlint file for those that don't use some giant global config file). Would you be willing to reconsider?
FWIW no, but then again other people look after rpmlint these days. Anyway, I think it's trivial to add one suppression filter to a rpmlint config that would take care of these cases and doesn't hurt others, if this message is undesirable. Doing it the other way (having rpmlint report something through its configs that it doesn't know about) is not possible.