Bug 542436 - Review Request: python-cloudfiles - Python language bindings for Rackspace CloudFiles API
Summary: Review Request: python-cloudfiles - Python language bindings for Rackspace Cl...
Status: CLOSED DUPLICATE of bug 674207
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: BJ Dierkes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-29 19:48 UTC by Andrew Turner
Modified: 2011-02-01 00:04 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-02-01 00:04:03 UTC


Attachments (Terms of Use)

Description Andrew Turner 2009-11-29 19:48:15 UTC
Spec URL: http://c0456722.cdn.cloudfiles.rackspacecloud.com/python-cloudfiles.spec
SRPM URL: http://c0456722.cdn.cloudfiles.rackspacecloud.com/python-cloudfiles-1.6.0-1.fc12.src.rpm
Description: python-cloudfiles provides a simple interface to the Rackspace Cloud Files service. "Cloud Files is reliable, scalable and affordable web-based storage for backing up and archiving all your static content". Find out more at <http://www.rackspacecloud.com/cloud_hosting_products/files>.

This is my first package for Fedora.

Comment 1 Thomas Spura 2009-11-30 00:55:08 UTC
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.

Comment 2 Andrew Turner 2009-11-30 21:01:45 UTC
Changed incorrect package name in Summary.

Comment 3 Andrew Turner 2009-11-30 21:30:33 UTC
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

Comment 4 Thomas Spura 2009-11-30 21:54:19 UTC
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@example.com> 1.6.0-2
- adding %%doc
- %%global instead of %%define

* Mon Oct 20 2008 Andrew "acturneruk" Turner <email@example.com> 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

Comment 6 Peter Lemenkov 2010-05-07 08:57:44 UTC
*** Bug 547622 has been marked as a duplicate of this bug. ***

Comment 7 Parag AN(पराग) 2010-06-04 05:10:59 UTC
Ping?

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

Comment 8 Jason Tibbitts 2010-11-14 16:45:50 UTC
No response in many months; I'll close this soon if nothing happens.

Comment 9 BJ Dierkes 2011-01-18 01:01:14 UTC
I am taking over this review and will resubmit a SPEC/SRPM when ready.

Comment 10 BJ Dierkes 2011-01-18 01:40:09 UTC
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

Comment 11 BJ Dierkes 2011-01-26 03:28:06 UTC
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.

Comment 12 Rahul Sundaram 2011-01-31 16:07:33 UTC
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

Comment 13 BJ Dierkes 2011-01-31 23:26:47 UTC
(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.

Comment 14 Thomas Spura 2011-01-31 23:44:00 UTC
(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

Comment 15 BJ Dierkes 2011-02-01 00:04:03 UTC
OK... closing this then as it is now a duplicate of 674207

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


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