Bug 645184 - Review Request: lua-wsapi - Lua Web Server API
Summary: Review Request: lua-wsapi - Lua Web Server API
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 645186
TreeView+ depends on / blocked
 
Reported: 2010-10-20 23:07 UTC by Tim Niemueller
Modified: 2010-11-10 17:02 UTC (History)
3 users (show)

Fixed In Version: lua-wsapi-1.3.4-2.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-04 23:43:35 UTC
Type: ---
Embargoed:
lemenkov: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Tim Niemueller 2010-10-20 23:07:39 UTC
Spec URL: http://fedorapeople.org/~timn/luastuff/lua-wsapi.spec
SRPM URL: http://fedorapeople.org/~timn/luastuff/lua-wsapi-1.3.4-1.fc13.src.rpm
Description:
WSAPI is an API that abstracts the web server from Lua web applications. By
coding against WSAPI your application can run on any of the supported servers
and interfaces (currently CGI, FastCGI and Xavante, on Windows and UNIX-based
systems).

WSAPI provides a set of helper libraries that help with request processing
and output buffering. You can also write applications that act as filters that
provide some kind of service to other applications, such as authentication,
file uploads, request isolation, or multiplexing.

WSAPI's main influence is Ruby's Rack framework, but it was also influenced by
Python's WSGI (PEP 333). It's not a direct clone of either of them, though,
and tries to follow standard Lua idioms.

URL: http://keplerproject.github.com/wsapi/
Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=2545670

rpmlint: One error, non-executable script. It is correct that the script is non-executable. I could patch out the first line, but then it doesn't harm either. I'd rather like to keep this unpatched and will let upstream know about it.

Comment 1 Peter Lemenkov 2010-10-23 08:13:42 UTC
I'll review it

Comment 2 Peter Lemenkov 2010-10-23 08:34:38 UTC
REVIEW:

Legend: + = PASSED, - = FAILED, 0 = Not Applicable

+ rpmlint is NOT silent

sulaco ~/rpmbuild/SPECS: rpmlint ~/Desktop/lua-wsapi-1.3.4-1.fc13.noarch.rpm 
lua-wsapi.noarch: E: non-executable-script /usr/share/lua/5.1/wsapi/sapi.lua 0644 /usr/bin/env
1 packages and 0 specfiles checked; 1 errors, 0 warnings.
sulaco ~/rpmbuild/SPECS: 

This issue is already addressed - see Tim's comments regarding it above.

+ The package is named according to the  Package Naming Guidelines.
+ The spec file name matches the base package %{name}, in the format %{name}.spec.

+/- The package meets the Packaging Guidelines although I've got few questions. It seems that you didn't package the contents of src/fastcgi - is it intentional? You also didn't package src/launcher contents fully - is it intentional too? 

+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines.
+ The License field in the package spec file matches the actual license (MIT).
+ The file, containing the text of the license(s) for the package, is included in %doc.
+ The spec file is written in American English.
+ The spec file for the package is legible.
+ The sources used to build the package, match the upstream source, as provided in the spec URL.

sulaco ~/rpmbuild/SOURCES: sha256sum wsapi-1.3.4.tar.gz*
37e0fb6b8692e333c387704c578e786455014810d864133d3203c0dbcab05af2  wsapi-1.3.4.tar.gz
37e0fb6b8692e333c387704c578e786455014810d864133d3203c0dbcab05af2  wsapi-1.3.4.tar.gz.1
sulaco ~/rpmbuild/SOURCES:

+ The package successfully compiles and builds into binary rpms on at least one primary architecture.
+ All build dependencies are listed in BuildRequires.
0 No need to handle locales.
0 No shared library files (because no shared libraries from src/fastcgi and src/launcher are packaged)
+ The package does NOT bundle copies of system libraries.
+ The package is not designed to be relocatable.
+ The package owns all directories that it creates.
+ The package does not list a file more than once in the spec file's %files listings.
+ Permissions on files are set properly.
+ The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ The package consistently uses macros.
+ The package contains code, or permissible content.
0 No extremely large documentation files.
+ Anything, the package includes as %doc, does not affect the runtime of the application.
0 No header files.
0 No static libraries.
0 No pkgconfig(.pc) files.
0 The package doesn't contain library files with a suffix (e.g. libfoo.so.1.1).
0 No devel sub-package.
+ The package does NOT contain any .la libtool archives.
0 Not a GUI application.

- The package must not own files or directories already owned by other packages. the directories /var/www/ and /var/ww/cgi-bin/ are currently owned by httpd. Directory /var/www/ is also co-owned by cherokee and thttpd. Yes, that becomes a problem since more and more alternative web-servers and libraries are included into Fedora and we must do something with it. Unfortunately we can't do too much in order to resolve this situation - we can 

a) Add totally bogus dependency on httpd
b) Claim ownership on whole /var/www (as cherokee and thttpd already did) and as permitted by new guidelines. I recommend this way.

Also I advice you to keep an eye on this issue (different http-server and directories/web-server agnostic expansion modules).

+ At the beginning of %install, the package runs rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ All filenames in rpm packages are valid UTF-8.


Ok, please fix and/or comment the issues noted above, and I'll continue.

Comment 3 Tim Niemueller 2010-10-23 15:23:29 UTC
(In reply to comment #2)
> 
> + rpmlint is NOT silent
> 
> This issue is already addressed - see Tim's comments regarding it above.

Upstream communication is at http://thread.gmane.org/gmane.comp.lang.lua.kepler-project/4403

> +/- The package meets the Packaging Guidelines although I've got few questions.
> It seems that you didn't package the contents of src/fastcgi - is it
> intentional? You also didn't package src/launcher contents fully - is it
> intentional too? 

Yes, for now I packaged Xavante (#645186) with WSAPI, which is most common and best supported. If the request arises, I will consider adding the other options as well, but for now to keep things simple and do not expect much or any usage so I won't.

> - The package must not own files or directories already owned by other
> packages. the directories /var/www/ and /var/ww/cgi-bin/ are currently owned by
> httpd. Directory /var/www/ is also co-owned by cherokee and thttpd. Yes, that
> becomes a problem since more and more alternative web-servers and libraries are
> included into Fedora and we must do something with it. Unfortunately we can't
> do too much in order to resolve this situation - we can 
> 
> a) Add totally bogus dependency on httpd
> b) Claim ownership on whole /var/www (as cherokee and thttpd already did) and
> as permitted by new guidelines. I recommend this way.

Went with option b)

> Also I advice you to keep an eye on this issue (different http-server and
> directories/web-server agnostic expansion modules).

Will do, assuming it's discussed on fedora devel.

> Ok, please fix and/or comment the issues noted above, and I'll continue.

Done. New files:
Spec: http://fedorapeople.org/~timn/luastuff/lua-wsapi.spec
SRPM: http://fedorapeople.org/~timn/luastuff/lua-wsapi-1.3.4-2.fc13.src.rpm

Comment 4 Peter Lemenkov 2010-10-23 17:08:00 UTC
Ok, I don;t see any other issues so this package is


APPROVED

Comment 5 Tim Niemueller 2010-10-24 02:12:37 UTC
Peter, thank you for all the quick and thorough reviews. Really appreciated! If you even have more time, Xavante at #645186 still needs a reviewer ;-)

Comment 6 Tim Niemueller 2010-10-24 02:21:00 UTC
New Package SCM Request
=======================
Package Name: lua-wsapi
Short Description: Lua Web Server API
Owners: timn
Branches: f12 f13 f14 el5 el6
InitialCC:

Comment 7 Kevin Fenzi 2010-10-25 18:53:19 UTC
Git done (by process-git-requests).

Comment 8 Fedora Update System 2010-10-25 20:34:00 UTC
lua-wsapi-1.3.4-2.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/lua-wsapi-1.3.4-2.fc12

Comment 9 Fedora Update System 2010-10-25 20:34:46 UTC
lua-wsapi-1.3.4-2.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/lua-wsapi-1.3.4-2.fc13

Comment 10 Fedora Update System 2010-10-25 20:35:36 UTC
lua-wsapi-1.3.4-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/lua-wsapi-1.3.4-2.fc14

Comment 11 Fedora Update System 2010-10-25 20:36:16 UTC
lua-wsapi-1.3.4-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/lua-wsapi-1.3.4-2.el5

Comment 12 Fedora Update System 2010-10-27 22:43:22 UTC
lua-wsapi-1.3.4-2.fc13 has been pushed to the Fedora 13 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 lua-wsapi'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/lua-wsapi-1.3.4-2.fc13

Comment 13 Fedora Update System 2010-11-04 23:27:36 UTC
lua-wsapi-1.3.4-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2010-11-04 23:43:30 UTC
lua-wsapi-1.3.4-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Fedora Update System 2010-11-04 23:49:27 UTC
lua-wsapi-1.3.4-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2010-11-10 17:02:48 UTC
lua-wsapi-1.3.4-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.


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