[Bug 472848] Review Request: jeuclid-core - MathML rendering solution

[bugzilla at redhat.com]

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=472848





--- Comment #10 from Brennan Ashton <bashton at brennanashton.com>  2008-11-26 21:41:21 EDT ---
(In reply to comment #8)
> - MUST: The package must be named according to the Package Naming Guidelines .
> 
> The project is named "jeuclid". Why is the package named jeuclid-core?
> 
> The Java packaging guidelines (https://fedoraproject.org/wiki/Packaging/Java)
> say that you should follow the project's name and provide a symlink if the
> commonly used jar name is different.
> 
jeuclid is a larger project that contains more modules. This is the only core
module.  Should I package the project in one spec file and have the sub
projects like core in it?
http://jeuclid.sourceforge.net/jeuclid-core/index.html

> - MUST: The package must meet the Packaging Guidelines .
> 
> Group:  Applications/Text
> License: ASL 2.0
> 
> The above lines have trailing whitespace at the end.
Fixed
> # this patch points the ant to the correct jars 
> Patch0:  jeuclid-core-build.patch
> 
> You could use build-classpath or build-jar-repository instead of the above
> patch.
Yes and know, the main reason that I patch is that the build.xml file expects
them to be symbolic linked to a lib folder in it that does not exist. It will
not build if this is not there.  I though while I was patching that, I might as
well put the links to the jars in the file.
I could do it with build-classpath, but the patch will have to stay for the lib
dir issue.  This is not really an upstream issue.

> # this patch removes FreeHep support as per the build README 
> Patch1:  jeuclid-core-FreeHep.patch
> 
> You don't have to say "this patch", it's redundant. What you should say,
> instead, is whether or not the patches have been sent upstream (and if not,
> why).
Took those extra words out. Added that FreeHep was an optional feature and
would not be passed upstream.
> 
> - MUST: The package must be licensed with a Fedora approved license and meet
> the Licensing Guidelines .
> 
> The following files have no licensing information, please ask upstream to
> provide it (not a blocker).
> $ licensecheck.pl -r . | grep -v Apache
> ./jeuclid-core/src/test/java/net/sourceforge/jeuclid/test/LayoutTest.java: *No
> copyright* UNKNOWN
> ./jeuclid-core/src/test/java/net/sourceforge/jeuclid/test/ViewerTest.java: *No
> copyright* UNKNOWN
> ./jeuclid-core/src/test/java/net/sourceforge/jeuclid/test/ConverterTest.java:
> *No copyright* UNKNOWN
> ./jeuclid-core/src/test/java/net/sourceforge/jeuclid/test/DOMBuilderTest.java:
> *No copyright* UNKNOWN
> 
> The rest seems to be under ASL 2.0, thus OK.
I will file an upstream bug and post.
> 
> - 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.
> 
> OK:
> ff3690e649bf0ead5fd2a03c732dc1ce  jeuclid-parent-3.1.3-src.zip
> 
> - 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. Refer to the Guidelines for examples.
> 
> You should use
> %{_javadir}/%{name}-%{version}.jar
> instead of
> %{_javadir}/*
> in %files section. It'll let you detect stray files if they ever make their way
> into buildroot in some future release.
Fixed

Sorry for the intermediate post, we had a mid-air bz collision.
Spec URL: http://bashton.fedorapeople.org/jeuclid-core.spec
SRPM URL: http://bashton.fedorapeople.org/jeuclid-core-3.1.3-5.fc9.src.rpm

-- 
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.