Bug 453264

Ack, just realized that the files in this conflict with the 'js' package.  Need
to investigate this more, because it seems jscoverage includes it's own version
of js.

Grr.  Well, 
Spec URL: http://jkeating.fedorapeople.org/review/jscoverage.spec
SRPM URL:
http://jkeating.fedorapeople.org/review/jscoverage-0.3.2-0.1.rc1.fc9.src.rpm

have been updated after talking some with upstream.  They don't install the js
stuff anymore, but it was noticed that jscoverage statically links against the
js that's built during the build process.  I've asked upstream to help me work
up a configure option that has it dynamically link against the system js, we'll
see where that goes.

message from upstream (that I will later put in the spec file itself):

From: 	Ed <ed>
To: 	Jesse Keating <jkeating>
Subject: 	Re: Packaging jscoverage for Fedora
Date: 	Sun, 29 Jun 2008 12:01:38 -0500 (13:01 EDT)


Jesse Keating wrote:

> Hrm, that exposes a different problem.  Fedora has a pretty strict
> policy with regard to statically compiled software, in that you have to
> have a really really good reason to bring it in and have the exception
> on file.  Are there any ways to compile jscoverage against the shared js
> library?
> 

The Mozilla SpiderMonkey js library is intended to be used as a 
JavaScript interpreter, but JSCoverage uses it for parsing, rather than 
interpreting, JavaScript.  Unfortunately the parsing functions are not 
"public" and could possibly change any time the library is upgraded.


I think the above qualifies as a good reason to allow static linking.  I'm ready
to have this package reviewed.

The only current rpmlint output is a number of .css files in the examples have
dos line endings, which doesn't effect their use.  If not necessary I'd rather
not munge those files during package build.

There's more than just css files in doc; I don't know why license files are
buried down in there, but who knows.  Anyway, one line fixes everything up:
  find doc -type f -exec sed -i 's/\r//' {} \;

There's a test suite in the tarball; it runs fine with:
  %check
  cd tests
  make check

The documentation is a bit over half the package.  The whole thing is only a bit
over a megabyte so I wouldn't really worry about it, though if this becomes a
dependency of many other packages I'd consider splitting it to a subpackage.

I need to run now, but that really looks to be about all there is to say.

MD5Sum:
8e06fb1d7fdc06b02f5e79093908157e  jscoverage-0.3.2rc1.tar.bz2

Good:
* Source URL is canonical
* Upstream source tarball verified
* Package name conforms to the Fedora Naming Guidelines
* Group Tag is from the official list
* Valid license tag
* Buildroot has all required elements
* All paths begin with macros
* All necessary BuildRequires listed.
* Files have appropriate permissions and owners
* Package installs and uninstalls clean

Bad (non-blockers):
* As tibbs noted in comment #4, there is a test suite in the tarball that might
might be worth running.
* The devel subpackage bits can probably be dropped, since your not packaging
anything for it.
* rpmlint produces the following errors that should be fixed before importing
into CVS:
jscoverage.x86_64: W: wrong-file-end-of-line-encoding
/usr/share/doc/jscoverage-0.3.2/doc/example-jsunit/jsunit/licenses/gpl-2.txt
jscoverage.x86_64: W: wrong-file-end-of-line-encoding
/usr/share/doc/jscoverage-0.3.2/doc/example-jsunit/jsunit/app/xbDebug.js
jscoverage.x86_64: W: wrong-file-end-of-line-encoding
/usr/share/doc/jscoverage-0.3.2/doc/example-jsunit/jsunit/app/css/readme
<etc.>

+1 APPROVE

Jesse, are you still interested in adding this to Fedora?

Yes, sorry I've been distracted with some other work.

I'm going to close this as dead review, since the package was never imported and the original submitter account is no more active.