Bug 473537
Summary: | Review Request: jcodings - Java Libraries for Ruby String Encodings | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Conrad Meyer <cse.cem+redhatbugz> |
Component: | Package Review | Assignee: | Mary Ellen Foster <mefoster> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review, mefoster, notting |
Target Milestone: | --- | Flags: | mefoster:
fedora-review+
kevin: fedora-cvs+ |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-02-14 03:54:57 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 473451 |
Description
Conrad Meyer
2008-11-29 07:13:10 UTC
[ NB: Borrowing the review format from Jerry James ... ] It's just recently been pointed out to me that there are specific GCJ guidelines for Java packages at https://fedoraproject.org/wiki/Packaging/GCJGuidelines that should probably be followed here unless there's a good reason not to. MUST items: - Output of rpmlint: jcodings.noarch: W: no-documentation 2 packages and 0 specfiles checked; 0 errors, 1 warnings. --- Is there any documentation at all to be had from upstream? - Package name: OK - Spec file name: OK - Packaging guidelines: note the GCJ thing above - Licensing guidelines: OK X License field matches: What is the license of this? JRuby as a whole is tri-licensed as CPL/GPL/LGPL, so I'm not sure that "MIT" is the right content here - Text license file in %doc: no, but it's not shipped with the source - Spec file in American English: OK - Spec file is legible: OK - Sources match upstream: OK (checked with sha1sum) - Compiles into binary RPMs on at least one platform: OK (checked on i386) - Use of ExcludeArch: OK (I did not check other arches, but this is noarch) - All build dependencies in BuildRequires: OK - Proper locale handling: OK - ldconfig: OK - Relocatable package: OK - Own all created directories: OK - No duplicate entries in %files: OK - Proper file permissions: OK - %clean section: OK - Consistent use of macros: OK - Code or permissible content: OK - Large documentation: OK (*no* documentation actually!) - Nothing in %doc affects runtime: OK - Header files in -devel: OK - Static libraries in -static: OK - Pkgconfig files: OK - .so files in -devel: OK - -devel package requires main package: OK - No libtool archives: OK - Desktop file: OK - Don't own files/directories owned by other packages: OK - Clean buildroot in %install: OK - Filenames are UTF-8: OK SHOULD items: X Query upstream for missing license file: see the note at https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text It's probably asking if they could put the license(s) into the tarball - Description and summary translations: OK - Package builds in mock: OK (checked for F-10 i386 only) - Builds on all supported architectures: did not check - Package functions as described: did not check - Sane scriptlets: OK - Subpackages require the base package: OK (n/a) - Placement of pkgconfig files: OK - File dependencies: OK (In reply to comment #1) > It's just recently been pointed out to me that there are specific GCJ > guidelines for Java > packages at https://fedoraproject.org/wiki/Packaging/GCJGuidelines that should > probably be > followed here unless there's a good reason not to. Right, the big deal especially was that there was *no* non-gcj jdk/jre on F-7 PPC/PPC64. Now that F-7 is dead it's been pushed less, but IMO still important because openjdk doesn't JIT on PPC and thus GCJ is *much* faster. WILLDO. > ... > --- Is there any documentation at all to be had from upstream? Not really -- this is mostly a new subproject of JRuby. > ... > X License field matches: What is the license of this? JRuby as a whole is > tri-licensed as > CPL/GPL/LGPL, so I'm not sure that "MIT" is the right content here This particular subpackage is MIT-licensed. They like to abuse SVN and put a bunch of projects on the same server, even with different licenses. Note the header at e.g. http://svn.jruby.codehaus.org/browse/~raw,r=7964/jruby/jcodings/trunk/src/org/jcodings/unicode/UnicodeCodeRanges.java > ... > SHOULD items: > X Query upstream for missing license file: see the note at > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text > It's probably asking if they could put the license(s) into the tarball Actually the tarball is automatically generated from SVN, so they need to put the license there. I'll ask. http://konradm.fedorapeople.org/fedora/SPECS/jcodings.spec http://konradm.fedorapeople.org/fedora/SRPMS/jcodings-1.0-2.fc9.src.rpm In koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1004755 Just fixing up the review flag. Ping? Argh, sorry about that ... Christmas holidays followed by $DAYJOB busy-ness. The changes look good, and the lack of documentation is annoying but I guess not a total show-stopper. It builds cleanly in mock for me. Better later than never: APPROVED New Package CVS Request ======================= Package Name: jcodings Short Description: Java Libraries for Ruby String Encodings Owners: konradm Branches: F-10 InitialCC: cvs done. Imported and built in rawhide. Closing. http://koji.fedoraproject.org/koji/taskinfo?taskID=1126104 |