Bug 977459

Summary: fedora-review expects spec file URL to end in .spec
Product: [Fedora] Fedora Reporter: Matthew Booth <mbooth>
Component: fedora-reviewAssignee: Stanislav Ochotnicky <sochotni>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: leamas.alec, pingou, sochotni
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-30 13:35:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthew Booth 2013-06-24 15:29:05 UTC
Description of problem:
fedora-review fails when run against this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=977446

at least against the initial comment. The error is:
ERROR: 'Cannot find spec file URL'

Note that it now succeeds because comment#4 deliberately changed the spec file URL to work round this issue :)

The problem is in url_bug.py:

    def find_spec_url(self):
        urls = self._find_urls_by_ending('.spec')
        if len(urls) == 0:
            raise self.BugError('Cannot find spec file URL')
        self.spec_url = urls[0]

It expects the URL to end in .spec. However, the BZ in question links directly to a spec file in git:

Spec URL: http://git.annexia.org/?p=fedora-specs.git;a=blob_plain;f=nbdkit.spec;hb=HEAD

fedora-review could probably be smart enough to recognise this as a spec file URL anyway given that the beginning of the line uses a standard format defining it as a spec file.

Version-Release number of selected component (if applicable):
fedora-review-0.4.1-2.fc19.noarch

Comment 1 Alec Leamas 2013-06-24 15:45:20 UTC
There is a relevant section on this in the manpage: URL Limitations.

Basically, we already remove the parameters suffix which starts with '?'. I see no problem removing also any ';*' suffix here unless some site uses parameterized urls with a ';' and a trailing whatever.spec.

That said, the easy way around this is to use the --rpmspec option. This makes the spec link irrelevant. Downside is that the spec in the link isn't compared with the spec in the srpm - and that's not so bad IMHO

Comment 2 Alec Leamas 2013-06-24 17:48:02 UTC
At a second thought, I think this is hard to solve. Obviously, annexia.org encodes the filename as part of the query string after the '?'. As stated in the manpage, we have chosen to skip this part part spec urls. This is because some (many?) sites adds query parameters after the filename to encode versions etc.

So, to accept the url in this bug we need to use the query string whereas other sites requires us to drop it.  There's not enough information in this bug to motivate a changed behaviour w r t this IMHO.

It is possible to use some heuristics and try different versions of the url given the querystring, but to be frank I don't think it's worth the effort given that --rpmspec is a perfectly viable walk-around.

Comment 3 Alec Leamas 2013-08-30 13:35:20 UTC
Closing this bug as WONTFIX according to motivation above. It could be seen as NOTABUG as well, but... If you have any new input on this, please feel free to reopen bug. And thanks again for reporting, some things got sorted out here IMHO