Bug 542436

Just a few comments, because I am no sponsor anyway:

- There is no documentation. You should at least add %doc ChangeLog
  The folder doc would also be interesting -> %doc ChangeLog doc

- There is no license file in the tarball:
  see: https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text

- see https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define


Anything else looks good at the first sight.

Changed incorrect package name in Summary.

Thomas,

Thanks for your reply. I have added %doc ChangeLog docs to the spec file, and changed the %define to %global. The original source package contains a COPYING file, which contains the license - is this okay, or do I need to add my own?

Kind regards,
Andrew

Hi Andrew,

you are welcome.

No, you *should* query upstream to add a COPYING file, if it doesn't exist already. If there is a COPYING file, this *has* to be in %doc.

You 'just' changed the spec file and rebuilded the src.rpm.
Please always bump the relase and add a changelog line, when you have changed anything:

Like
=============================
%changelog
* Mon Oct 30 2009 Andrew "acturneruk" Turner <email> 1.6.0-2
- adding %%doc
- %%global instead of %%define

* Mon Oct 20 2008 Andrew "acturneruk" Turner <email> 1.6.0-1
- Initial package for Fedora
=============================

Note the %%doc and not %doc. When just using %doc, rpmlint complains about 'using a macro in %changelog'.

After that, you should repost the SPEC and SRPM url and not just point to the ones in your first comment.

   Thomas

Updated re:Comment #4 above:-

http://c0456722.cdn.cloudfiles.rackspacecloud.com/python-cloudfiles.spec
http://c0456722.cdn.cloudfiles.rackspacecloud.com/python-cloudfiles-1.6.0-3.fc12.src.rpm

Thanks again for the guidance.

*** Bug 547622 has been marked as a duplicate of this bug. ***

Ping?

Can you updates package? I see new updates in upstream source. Also, have you submitted any more packages?

No response in many months; I'll close this soon if nothing happens.

I am taking over this review and will resubmit a SPEC/SRPM when ready.

Being held up by this:

https://github.com/rackspace/python-cloudfiles/issues#issue/18


Downloads from GitHub look like:

Source0: https://github.com/rackspace/%{name}/tarball/%{version}


Actually download:

rackspace-python-cloudfiles-1.7.5-0-g7c513c7.tar.gz


$ rpmbuild -ba SPECS/python-cloudfiles.spec 
error: File /home/wdierkes/packages/fedora/python-cloudfiles/buildroot/SOURCES/1.7.5: No such file or directory

SPEC: http://5dollarwhitebox.org/fedora/python-cloudfiles.spec
SRPM: http://5dollarwhitebox.org/fedora/python-cloudfiles-1.7.6.1-1.fc14.src.rpm


Can't do much about the 404 with github... Downloads are temporary when you visit the download link...

$ rpmlint -i SPECS/python-cloudfiles.spec 
SPECS/python-cloudfiles.spec: W: invalid-url Source0: http://download.github.com/rackspace-python-cloudfiles-1.7.6.1-0-g550d5ae.tar.gz HTTP Error 404: Not Found
The value should be a valid, public HTTP, HTTPS, or FTP URL.

0 packages and 1 specfiles checked; 0 errors, 1 warnings.


$ rpmlint -i RPMS/noarch/python-cloudfiles-1.7.6.1-1.fc14.noarch.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

You should probably open up a new review request instead of reopening a old new since the reports counting reviews processes will get confused otherwise and you shouldn't assign the review request to yourself.  Some preliminary notes

* Should document why you are using the git version instead of the release in the spec file

* Should document the patch and their upstream status

* No need to define the buildroot or have a clean section unless you are branching for EPEL

(In reply to comment #12)
> You should probably open up a new review request instead of reopening a old new
> since the reports counting reviews processes will get confused otherwise and
> you shouldn't assign the review request to yourself.  

I don't really follow why I should create a new tracker for this.  Seems more efficient to take it over since the original owner dropped it rather than having duplicates.


> 
> * Should document why you are using the git version instead of the release in
> the spec file

Done.  Noted that, the git version is not a 'git clone' of the repo in place of an official tarbal, but rather that github uses the tagg'ed git version when generating the tarbal.


> 
> * Should document the patch and their upstream status

This was applied upstream, and now removed.

> 
> * No need to define the buildroot or have a clean section unless you are
> branching for EPEL

This will be branched for EPEL.


SPEC: http://5dollarwhitebox.org/fedora/python-cloudfiles.spec
SRPMS: http://5dollarwhitebox.org/fedora/python-cloudfiles-1.7.7-1.fc14.src.rpm

$ rpmlint -i SPECS/python-cloudfiles.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -i RPMS/noarch/python-cloudfiles-1.7.7-1.fc14.noarch.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

(In reply to comment #13)
> (In reply to comment #12)
> > You should probably open up a new review request instead of reopening a old new
> > since the reports counting reviews processes will get confused otherwise and
> > you shouldn't assign the review request to yourself.  
> 
> I don't really follow why I should create a new tracker for this.  Seems more
> efficient to take it over since the original owner dropped it rather than
> having duplicates.

That way, bug reporter is always submitter of the package. This is meant implicitly at [1]:
"""
If the bug is resubmitted by someone else, it is also reasonable to change the resolution on the closed bug to DUPLICATE and mark it as a duplicate of the new bug so that reviewers of the new ticket can easily find the work that was done on the old one.
"""

Basically you resubmit it now in the same bug now...


[1] http://fedoraproject.org/wiki/Policy_for_stalled_package_reviews#Submitter_not_responding

OK... closing this then as it is now a duplicate of 674207

*** This bug has been marked as a duplicate of bug 674207 ***