[Bug 717680] Review Request: python-cloudservers - Client library for Rackspace's Cloud Servers API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=717680

Chris Lalancette <clalance@xxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Flag|needinfo?(clalance@redhat.c |
                   |om)                         |

--- Comment #3 from Chris Lalancette <clalance@xxxxxxxxxx> 2011-07-06 10:24:18 EDT ---
(In reply to comment #2)
> [+] MUST: rpmlint must be run on every package
> [+] MUST: The package must be named according to the Package Naming 
>          Guidelines
> [+] MUST: The spec file name must match the base package %{name} [...]
> [+] MUST: The package must meet the Packaging Guidelines
> [-] MUST: The package must be licensed with a Fedora approved license
>          and meet the Licensing Guidelines
> * Uses INSTALLED_FILES -- See first <!> in
> https://fedoraproject.org/wiki/Packaging:Python#Byte_compiling . Please use
> file globbing.

Ah, I didn't know about that recommendation.  Fixed now.

> 
> [?] MUST: The License field in the package spec file must match the 
>          actual license
> I can't find the license anywhere in the source tarball. Would you be so kind
> as to point out where the files are licensed as BSD?

Unfortunately this project doesn't ship a separate LICENSE file.  The BSD
license is pointed out both in the setup.py and the PKG-INFO files.

> 
> [?] MUST: If (and only if) the source package includes the text of the 
>          license(s) in its own file, then that file, containing the text of 
>          the license(s) for the package must be included in %doc

As above, there is no separate license file.

> [+] MUST: The spec file must be written in American English.
> [+] MUST: The spec file for the package MUST be legible.
> [+] MUST: The sources used to build the package must match the upstream 
>          source, as provided in the spec URL. Reviewers should use md5sum for 
>          this task. If no upstream URL can be specified for this package, 
>          please see the Source URL Guidelines for how to deal with this.
> [+] MUST: The package MUST successfully compile and build into binary 
>          rpms on at least one primary architecture
> [n/a] MUST: If the package does not successfully compile, build or work on 
>          an architecture, then those architectures should be listed in the 
>          spec in ExcludeArch. Each architecture listed in ExcludeArch MUST 
>          have a bug filed in bugzilla, describing the reason that the package 
>          does not compile/build/work on that architecture. The bug number MUST 
>          be placed in a comment, next to the corresponding ExcludeArch line
> [+] MUST: All build dependencies must be listed in BuildRequires, except 
>          for any that are listed in the exceptions section of the Packaging 
>          Guidelines ; inclusion of those as BuildRequires is optional. Apply 
>          common sense.
> [n/a] MUST: The spec file MUST handle locales properly. This is done by 
>          using the %find_lang macro. Using %{_datadir}/locale/* is strictly 
>          forbidden
> [n/a] MUST: Every binary RPM package (or subpackage) which stores shared 
>          library files (not just symlinks) in any of the dynamic linker's 
>          default paths, must call ldconfig in %post and %postun.
> [n/a] MUST: If the package is designed to be relocatable, the packager must 
>          state this fact in the request for review, along with the 
>          rationalization for relocation of that specific package. Without 
>          this, use of Prefix: /usr is considered a blocker.
> [-] MUST: A package must own all directories that it creates. If it does 
>          not create a directory that it uses, then it should require a package 
>          which does create that directory.
> * See above usage of INSTALLED_FILES

Right, I think this should be fixed now.

> 
> [+] MUST: A package must not contain any duplicate files in the %files 
>          listing.
> [+] MUST: Permissions on files must be set properly. Executables should 
>          be set with executable permissions, for example. Every %files section 
>          must include a %defattr(...) line.
> [+] MUST: Each package must have a %clean section, which contains rm -rf
>          %{buildroot} (or $RPM_BUILD_ROOT).
> [+] MUST: Each package must consistently use macros.
> [+] MUST: The package must contain code, or permissable content.
> [n/a] MUST: Large documentation files must go in a -doc subpackage. (The 
>          definition of large is left up to the packager's best judgement, but 
>          is not restricted to size. Large can refer to either size or 
>          quantity).
> [n/a] MUST: If a package includes something as %doc, it must not affect the 
>          runtime of the application. To summarize: If it is in %doc, the 
>          program must run properly if it is not present.
> * note: Could docs/ or the generated readme be installed as %doc?

docs/ by itself isn't very useful.  However, you can use python-sphinx to build
HTML documentation.  I've updated the spec file to now build a separate -doc
package with that stuff included.

> 
> [n/a] MUST: Header files must be in a -devel package.
> [n/a] MUST: Static libraries must be in a -static package.
> [n/a] MUST: Packages containing pkgconfig(.pc) files must 'Requires: 
>          pkgconfig' (for directory ownership and usability).
> [n/a] MUST: If a package contains library files with a suffix (e.g. 
>          libfoo.so.1.1), then library files that end in .so (without suffix) 
>          must go in a -devel package.
> [n/a] MUST: In the vast majority of cases, devel packages must require the 
>          base package using a fully versioned dependency: Requires: %{name} =
>          %{version}-%{release}
> [n/a] MUST: Packages must NOT contain any .la libtool archives, these must 
>          be removed in the spec if they are built.
> [n/a] MUST: Packages containing GUI applications must include a
>          %{name}.desktop file, and that file must be properly installed with 
>          desktop-file-install in the %install section. If you feel that your 
>          packaged GUI application does not need a .desktop file, you must put 
>          a comment in the spec file with your explanation.
> [n/a] MUST: Packages must not own files or directories already owned by 
>          other packages. The rule of thumb here is that the first package to 
>          be installed should own the files or directories that other packages 
>          may rely upon. This means, for example, that no package in Fedora 
>          should ever share ownership with any of the files or directories 
>          owned by the filesystem or man package. If you feel that you have a 
>          good reason to own a file or directory that another package owns, 
>          then please present that at package review time.
> [-] MUST: At the beginning of %install, each package MUST run rm -rf
>          %{buildroot} (or $RPM_BUILD_ROOT).
> * Seems straightforward

This is in there now.

> [+] MUST: All filenames in rpm packages must be valid UTF-8.
> 
> A few questions and comments, see above.

I've uploaded the new spec to
http://people.redhat.com/clalance/python-cloudservers/python-cloudservers.spec,
and the new SRPM to
http://people.redhat.com/clalance/python-cloudservers/python-cloudservers-1.2-3.fc14.src.rpm.
 Can you take a look?

Thanks,
Chris Lalancette

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review


[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]