Bug 977459 - fedora-review expects spec file URL to end in .spec
fedora-review expects spec file URL to end in .spec
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: fedora-review (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stanislav Ochotnicky
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-24 11:29 EDT by Matthew Booth
Modified: 2013-08-30 09:35 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-30 09:35:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Booth 2013-06-24 11:29:05 EDT
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 11:45:20 EDT
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 13:48:02 EDT
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 09:35:20 EDT
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

Note You need to log in before you can comment on or make changes to this bug.