Bug 522613 - Review Request: python-tornado - Scalable, non-blocking web server and tools
Summary: Review Request: python-tornado - Scalable, non-blocking web server and tools
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Thomas Spura
QA Contact: Fedora Extras Quality Assurance
: 617834 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2009-09-10 20:13 UTC by Ionuț Arțăriși
Modified: 2014-09-03 10:35 UTC (History)
11 users (show)

Fixed In Version: 0.2-3.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-11 15:05:47 UTC
Type: ---
tomspur: fedora-review+
gwync: fedora-cvs+

Attachments (Terms of Use)

Description Ionuț Arțăriși 2009-09-10 20:13:52 UTC
Spec URL: http://mapleoin.fedorapeople.org/pkgs/tornado/tornado.spec
SRPM URL: http://mapleoin.fedorapeople.org/pkgs/tornado/tornado-0.1-1.fc11.src.rpm

Description: Tornado is an open source version of the scalable, non-blocking web server and
and tools that power FriendFeed. The FriendFeed application is written using a
web framework that looks a bit like web.py or Google's webapp, but with
additional tools and optimizations to take advantage of the underlying
non-blocking infrastructure.

The framework is distinct from most mainstream web server frameworks (and
certainly most Python frameworks) because it is non-blocking and reasonably
fast. Because it is non-blocking and uses epoll, it can handle thousands of
simultaneous standing connections, which means it is ideal for real-time web
services. We built the web server specifically to handle FriendFeed's
real-time features — every active user of FriendFeed maintains an open
connection to the FriendFeed servers


$ rpmlint ../RPMS/noarch/tornado-0.1-1.fc11.noarch.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Thank you!

Comment 1 Silas Sewell 2009-09-11 03:50:51 UTC
I wrote a spec for myself which includes the C module (for Python 2.5 users).

I thought I might as well throw is up here just in case anyone else was interested.


Comment 2 Rene Ploetz 2009-09-24 17:07:59 UTC
This is an unofficial review for the original package and spec file:

+: ok
!: needs to be fixed
-: not applicable

MUST Items:
[+] rpmlint comes out clean on every package
[+] package name meets Package Naming Guidelines
[+] spec file name must match base package name
[+] the package license (ASL 2.0) is correct and allowed in Fedora
[+] spec file is legible and written in American English
[+] SOURCE url points to packaged source archive
[+] package md5sum matches upstream (69d6c60c4eca3a32de23aa5e3717b6f2)
[+] BuildRequires are correctly specified as per Python Guidelines (see below)
[+] package builds fine in koji
[-] locales are properly handled
[+] no system libraries are bundled
[-] if package installs libraries in default paths run ldconfig in %post/%postun
[!] package owns the directories it creates

%{python_sitelib}/%{name}/* is not sufficient, see http://fedoraproject.org/wiki/Packaging:UnownedDirectories#Common_Mistakes
This way you would not own %{python_sitelib}/%{name}

[+] no file is listed twice
[+] permissions on files are explictly set (via defattr)
[+] package must contain %clean with rm -rf %{buildroot} (or $RPM_BUILD_ROOT)
[!] macros are consistently used

You should decide to either use %{buildroot} or $RPM_BUILD_ROOT - either one is fine, but mixing them should be avoided.

[+] the package has permissable code / content
[-] large documentations must be put into -doc subpackage
[+] files included in %doc must not be essential for the application to work
[-] header files must be in -devel package
[-] static libraries must be in a -static package
[-] packages containing pkgconfig(.pc) files must "Requires: pkgconfig"
[-] library files without a suffix (foo.so) must go into -devel subpackage if libraries with a suffix (foo.so.0.0) are present.
[-] %{name}-devel packages must specify a fully versioned dependency on the %{name} package
[-] package must not contain any libtool (.la) archives
[-] (most) GUI applications need to include a %{name}.desktop file
[+] package must not own any file or directory already owned by another package
[+] first command in %install must be rm -rf %{buildroot} (or $RPM_BUILD_ROOT)
[+] all filesnames in package are valid UTF-8

[!] if source package does not include license text as seperate file, packager should query upstream to include it
[-] if available,  description and summary in spec file should contain translations for non-english languages
[+] package builds fine in mock
[+] package should compile on all supported architectures
[+] package does work during a short test
[+] scriptlets - if used - must be sane
[-] non-devel subpackages should require the base package
[-] pkgconfig(.pc) files should be placed in -devel package
[-] if package does require a file outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin, packager should require the package which provides the file (not the file alone)

Python-specific MUST-Items:
[+] package must (almost always) require python-devel
[+] if package wants to install into the global site_packages directory, python_sitelib must be defined according to Python Guidelines
[-] python eggs must be built from source
[-] python eggs must not be downloading dependencies during build process
[+] egg-info files must be included in the package if available
[-] compat packages must install using easy_install -m
[-] if building multiple versions (compat packages), one package must contain a default version usable via "import modulename"
[+] all python source files except those in %{_bindir} and %{_sbindir} must be byte-compiled into *.pyo and both source and compiled version must be included in the package

* package does not own every directory it creates
* mixed usage of %{buildroot} and $RPM_BUILD_ROOT

Note: This package will not compile for Fedora < 11, as the setup script will try to compile epoll.c as F10 has only Python 2.5, but this is not a blocker.

Other Questions:
Why do you use a script to remove the shebangs from files? Creating a patch may be better to verify the changes you make to the source - especially if you only want to make rpmlint happy.

You should also consider to update your package to match the latest upstream version (0.2).

Comment 3 Ionuț Arțăriși 2009-09-24 21:54:14 UTC
Thank you, Rene!

I've updated the package to fix these issues:

I've also refactored the way the spurious permissions are handled.

I'm using the script to remove the shebangs as mentioned here:
Though either method seems fair to me.

I've also contacted upstream for the inclusion of the LICENSE file:

Inspired by Silas Sewell above, I would also like to rename this package to python-tornado.

Comment 4 Thomas Spura 2009-10-19 21:32:32 UTC
(In reply to comment #3)
> Inspired by Silas Sewell above, I would also like to rename this package to
> python-tornado.  

Good. Go ahead. :)

Package Review

 - = N/A
 x = Check
 ! = Problem
 ? = Not evaluated

 [?] Package is named according to the Package Naming Guidelines.
     When the name will be python-tornado and the spec renamed, yes
 [?] Spec file name must match the base package %{name}, in the format %{name}.spec.
     also checking later
 [x] Package meets the Packaging Guidelines
 [x] Package successfully compiles and builds into binary rpms on at least one supported architecture.
     Tested on: 
       [] devel/i386 
       [] devel/x86_64
       [] F11/i386 
       [x] F11/x86_64
 [x] Rpmlint output:
     $ rpmlint tornado.spec tornado-0.2-1.fc11.src.rpm noarch/tornado-0.2-1.fc11.noarch.rpm 
2 packages and 1 specfiles checked; 0 errors, 0 warnings.

 [x] Buildroot is correct
     (%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n))
 [x] Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines.
 [x] License field in the package spec file matches the actual license.
     License type: ASL 2.0
 [-] 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 is included in %doc.
 [x] Spec file is legible and written in American English.
 [x] Sources used to build the package matches the upstream source, as provided in the spec URL.
     Upstream source: 4704cbf8baab2562c1e648c76de87b60
     Build source:    4704cbf8baab2562c1e648c76de87b60
 [x] Package is not known to require ExcludeArch
 [x] All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines.
     BuildRequires: python-setuptools is missing, so it should not build in koji, but it does:
 [-] The spec file handles locales properly.
 [-] ldconfig called in %post and %postun if required.
 [x] Package must own all directories that it creates.
 [x] Package requires other packages for directories it uses.
 [x] Package does not contain duplicates in %files.
 [x] Permissions on files are set properly.
     But: find demos -name "*.py" | xargs chmod -x
     would be better readable.
 [x] Package has a %clean section, which contains rm -rf %{buildroot}.
 [x] Package consistently uses macros.
 [!] Large documentation files are in a -doc subpackage, if required.
     The demos are 1.1 MB big and the main files, which will be used are 0.2 MB, please put the demos in a -doc subpackage
 [x] Package uses nothing in %doc for runtime.
 [-] Header files in -devel subpackage, if present.
 [-] Static libraries in -devel subpackage, if present.
 [-] Package requires pkgconfig, if .pc files are present.
 [-] Development .so files in -devel subpackage, if present.
 [!] Fully versioned dependency in subpackages, if present.
 [x] Package does not contain any libtool archives (.la).
 [-] Package contains a properly installed %{name}.desktop file if it is a GUI application.
 [x] Package does not own files or directories owned by other packages.

Python specific musts are fullfiled, too.

 [x] Latest version is packaged.
 [!] Package does not include license text files separate from upstream.
     upstream already queried
 [-] Description and summary sections in the package spec file contains translations for supported Non-English languages, if available.
 [x] Reviewer should test that the package builds in mock.
 [x] Package functions as described (no hardware to test with).
     helloworld does ;)
 [x] Scriptlets must be sane, if used.
     comment about permissions above
 [-] The placement of pkgconfig(.pc) files is correct.


- rename to python-tornado (summary of this bug, too)
- split the demos into a -doc subpackage

Comment 5 Thomas Spura 2009-10-19 22:58:01 UTC
Lifting FE-LEGAL, because I'm unsure if the name 'facebook' (and maybe 'django') may be in the demos subdir.

There is no picture or something like that in the sources, but the example 'demos/facebook' seems to redirect to the offical website and the name is called several times…
What are the naming rights like?

The example itself is ASL 2.0.

Is that a legal issue?

Don't think so, but want to be sure, anyway ;)

Comment 6 Tom "spot" Callaway 2009-10-20 14:29:17 UTC
No real issue here, as the code isn't claiming to be "facebook, the web site". Lifting FE-Legal.

Comment 8 Thomas Spura 2009-10-20 20:50:13 UTC
Checking items, left behind last time, because of the rename:

 [x] Package is named according to the Package Naming Guidelines.
 [x] Spec file name must match the base package %{name}, in the format 

 [x] Large documentation files are in a -doc subpackage, if required

Close to finish, but the rename introduced some new things ;)

- use %global instead of %define,
  see: https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define

- Group: Development/Libraries should be for libraries.
  These examples should be better in: Documentation

Comment 9 Ionuț Arțăriși 2009-10-20 22:15:30 UTC
Thanks again, Thomas!


There's quite an omission I made when opening this ticket it seems. Sorry. I haven't yet been accepted in the packager group, though I'm in the process of being sponsored.

Comment 10 Thomas Spura 2009-10-20 23:32:37 UTC
It would be nice to know that before starting a review ;)
e.g. with blocking FE-NEEDSPONSOR like in the 5 / 7 other review requests!!

The two issues, mentioned in comment #8 are resolved, so I'll approve this, when you are sponsored.

Remove the block to FE-NEEDSPONSOR, once you are sponsored...

Comment 11 Thomas Spura 2009-10-30 10:22:13 UTC


Comment 12 Ionuț Arțăriși 2009-10-31 09:47:47 UTC
New Package CVS Request
Package Name: python-tornado
Short Description: Scalable, non-blocking web server and tools
Owners: mapleoin
Branches: F-11 F-12

Comment 13 Kevin Fenzi 2009-10-31 23:56:52 UTC
cvs done.

Comment 14 Fedora Update System 2009-11-04 12:39:34 UTC
python-tornado-0.2-3.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update python-tornado'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-11024

Comment 15 Fedora Update System 2009-11-11 15:05:39 UTC
python-tornado-0.2-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Ionuț Arțăriși 2010-08-06 10:13:56 UTC
Package Change Request
Package Name: python-tornado
New Branches: el5 el6
Owners: mapleoin

I'd like to make this package available for EPEL. Thanks.

Comment 17 Jason Tibbitts 2010-08-13 17:13:49 UTC
Git done (by process-git-requests).

Comment 18 Thomas Spura 2014-09-03 08:40:51 UTC
*** Bug 617834 has been marked as a duplicate of this bug. ***

Comment 19 Thomas Spura 2014-09-03 08:43:31 UTC
Package Change Request
Package Name: python-tornado
New Branches: epel7
Owners: tomspur orion

Comment 20 Gwyn Ciesla 2014-09-03 10:35:44 UTC
Git done (by process-git-requests).

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