Bug 455622

The URLs for Spec/SRPM return a 404 error page. Please clear NotReady from the Whiteboard when this review request is ready for a review.

Sorry, looks like the URLs went away during "the incident".

Updated spec URL: http://people.redhat.com/dmalcolm/js/scriptaculous-js.spec
Updated SRPM URL: http://people.redhat.com/dmalcolm/js/scriptaculous-js-1.8.1-1.src.rpm

Successful scratch build in Koji here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1355452

Removing "NotReady" from the whiteboard.

Unofficial review

rpmlint output:

$ rpmlint scriptaculous-js-1.8.1-1.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint ../SPECS/scriptaculous-js.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.


$ rpmlint scriptaculous-js-1.8.1-1.fc11.noarch.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint scriptaculous-js-tests-1.8.1-1.fc11.noarch.rpm
scriptaculous-js-tests.noarch: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

Warning can be ignored 
-------

Builds successfully on Koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1619781

-------

$ rpm -i scriptaculous-js-1.8.1-1.src.rpm 
warning: user dmalcolm does not exist - using root
warning: group dmalcolm does not exist - using root
warning: user dmalcolm does not exist - using root
warning: group dmalcolm does not exist - using root
warning: user dmalcolm does not exist - using root
warning: group dmalcolm does not exist - using root

$ du -sh scriptaculous-js-1.8.1-1.fc11.noarch.rpm 
92K	scriptaculous-js-1.8.1-1.fc11.noarch.rpm
$ du -sh scriptaculous-js-tests-1.8.1-1.fc11.noarch.rpm 
84K	scriptaculous-js-tests-1.8.1-1.fc11.noarch.rpm

--------

list:

[x] Rpmlink output pasted above.

[x] Naming guidelines are followed.

[x] Spec file from spec link matches spec in srpm.

[x] License checked.

[x] The package meets the packaging guidelines.

[x] The license file is included in %doc.

[x] The spec file is written in American English.

[x] The spec file for the package is legible. 

[x] The sources used to build the package matches the upstream source.

[x] The package successfully compiles and builds into binary rpms.

[x] A package owns all directories that it creates. 

[x] No file is listed more than once in the spec file's %files listings. 

[x] Permissions on files are set properly.

[x] Has a %clean section, which contains rm -rf $RPM_BUILD_ROOT.

[x] Consistently uses macros.

[x] Package contains only permissible content.

[x] Files listed in %doc do not affect the runtime of the application.

[x] Package does not own files or directories already owned by other packages. 

[x] At the beginning of %install, the package runs rm -rf $RPM_BUILD_ROOT.

[x] All file names in rpm packages are valid UTF-8. 

(The point from the MUST list of review guidelines that are left out here do not apply in this case.) 

---------

[x] The reviewer should test that the package builds in mock.

[x] The package should compile and build into binary rpms on all
supported architectures. 

[x] Subpackages other than devel should require the base package
using a fully versioned dependency.


(The point from the SHOULD list of review guidelines that are left out here do not apply in this case.)

--------

x: OKay

> [x] Rpmlink output pasted above.

Oops, please read that as rpmlint.

Thanks for looking at this.  If I'm reading through the unofficial review correctly, am I right in thinking there's nothing needing to be addressed?

I noticed 1.8.2 is the latest stable release recommended by upstream, so I updated the specfile accordingly. 

New specfile with 1.8.2 is here:
http://people.redhat.com/dmalcolm/js/scriptaculous-js.spec
(overwriting old one)

New SRPM here:
http://people.redhat.com/dmalcolm/js/scriptaculous-js-1.8.2-1.src.rpm

I'll review it.

MUST items:

[+/-] rpmlint must be run on every package. The output should be posted in the review.
$ rpmlint *
scriptaculous-js-tests.noarch: W: no-documentation

Consider put into tests sub-package files MIT-LICENSE README.rdoc.

[+] MUST: The package must be named according to the Package Naming Guidelines .
[+] MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption.
[+] MUST: The package must be licensed with a Fedora approved license and meet 
the Licensing Guidelines.
[-] MUST: The License field in the package spec file must match the actual license.
Yes. I only doubt about one file sound.js, it contain comment string: "// Based on code created by Jules Gravinese (http://www.webveteran.com/)"
I have not fount on this page any license.

So, I fire FE-legal here, please try clarify this issue, contact with author or leave for Spot...

[+] 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.
[+] 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.

$ md5sum *
10aa518e3b44f5a2a55f2bc8caadcd62  scriptaculous-js-1.8.2_RPM.tar.bz2
10aa518e3b44f5a2a55f2bc8caadcd62  scriptaculous-js-1.8.2.tar.bz2


[+] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1626056

[+] 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.
[+] 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.
[+] MUST: A Fedora package must not list a file more than once in the spec file's %files listings.
[+] 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). [15]
[+] MUST: Each package must consistently use macros.
Only note: You may also use %{name}-%{version} in Source0 tag, but it on you choose.

[+] MUST: The package must contain code, or permissible content.
[+] MUST: Large documentation files must go in a -doc sub-package. (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).
[+] 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. [18]
[+] 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).
[+] MUST: All filenames in rpm packages must be valid UTF-8.


SHOULD Items:
[+] SHOULD: The reviewer should test that the package builds in mock.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1626056
[+] SHOULD: The package should compile and build into binary rpms on all supported architectures.
[+] SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
There nothing test I think.

Some additional things:
1) It is optional. You name subpackage as scriptaculous-js-tests, but actually no tests there! It contain only html-files with functionality demo. Please consider rerename it into something like scriptaculous-js-demo or scriptaculous-js-examples
2) You Requiere httpd. Why??? It is contain only static jasascript files, so I eleav it may functional on any web-server. So you must require "webserver" (this is meta provides)
3) You bundle prototypejs library here (http://prototypejs.org/) and even this is not standard binary library, It is not permited anyway and must be packaged separately.
For things see:
http://fedoraproject.org/wiki/No_Bundled_Libraries#For_the_Review_Guidelines
https://fedoraproject.org/wiki/Packaging:Java#Pre-built_JAR_files_.2F_Other_bundled_software (this one is about Java packaging, but speak also about "Other bundled software" so I think it applicable)

It is clear from the various entries on Jules Gravinese's website that he is not only aware of Scriptaculous, but is aware of his specific contributions to it, and that they were made by him. Thus, I see no reason why there is a licensing concern around sound.js.

Lifting FE-Legal

Ok, sounds good, thank you Tom.

Dave Malcolm, there stay only one major issue - bundled prototypejs. Other things is optional or easy fixable.

I'm sorry that I let this stall - I'm very busy with Python these days.

I no longer have a specific use for scriptaculous-js.  If someone else would like to be the maintainer of this within Fedora, that would be great.  I don't realistically see myself being a good maintainer here (too many other demands on my time).

Thanks Till, Satya and Pavel for your work on reviewing this, and I'm sorry to have to drop the ball on this.

Ok, I close it as WONTFIX.