Spec URL: http://people.redhat.com/caolanm/jfreereport/jcommon.spec
SRPM URL: http://people.redhat.com/caolanm/jfreereport/jcommon-1.0.12-1.fc9.src.rpm
Description: jcommon is a prerequisite of jfreereport which is itself a prerequisite of the useful OpenOffice.org reportdesigner
I see two suspicious @redhat.com CCs added to this. caolanm->dbhole/overholt: Is
there anything about this package that's of interest elsewhere in the java stack
as well as for the OOo stack ?
I just CC'd us because we were working on the Java Packaging Guidelines and this
was a new package that could be used to test the guidelines.
I'm not aware of where else jcommon is used.
Does this supercede bug 252114?
caolanm->jerry: I have a interest in getting jfreereport and its dependencies
into fedora by F-10, but I'm not super interested in maintaining it :-) Though I
will if I have to.
I wasn't aware of bug 252114, but it doesn't look like its moving pretty fast
either. Feel free to mark one as a duplicate of the other. The above spec is pre
the java guideline finalization so I haven't checked if it needs to be resynced
to pass the new final guidelines.
*** Bug 252114 has been marked as a duplicate of this bug. ***
Created attachment 304171 [details]
Patch to comply with Java guidelines
I was hoping to get to a full review tonight, but ran out of time. I'll try
again tomorrow night. In the meantime, though, I believe you need this patch
to be compliant with the new guidelines. The patch also contains a purported
debuginfo fix. Without that, I get a debuginfo package with no sources. With
it, I get a debuginfo package with sources under some weird paths. Do you know
how to make it work correctly?
I'm happy to maintain or co-maintain this package, by the way.
Jerry, what is that patch supposed to do? As far as I can see there is
nothing wrong with the debuginfo. All the source files are there.
zorro:SPECS $ rpm2cpio ../RPMS/x86_64/jcommon-debuginfo-1.0.12-1.fc9.x86_64.rpm
| cpio -it | head -30
I built on an F-8 i386 machine, and it looks like you built on an F-9 x86_64
machine. I'll bet that F-8 vs. F-9 is the deciding factor here. Just to check
my sanity, could you try building on an F-8 machine and see if you get a debug
package with no sources?
The rest of the patch makes the spec file conform to the current Java packaging
guidelines, at least by my reading. I still plan to do a full review tonight.
Updated to guidelines:
debuginfo works for me on F-9 (rawhide)
The thing that matters is the version of java-1.5.0-gcj-devel.
I'm using java-1.5.0-gcj-devel-126.96.36.199-21.fc9.x86_64
I can't remember when the fix went in, but it was in a F8 update.
Then the F8 update never got pushed. I've got
java-1.5.0-gcj-devel-188.8.131.52-17.fc8 (the original F8 version) on my machines. I
see no updates to this package on download.fedora.redhat.com for F8. I run "yum
upgrade" every day.
Here's my review. First, I'd like to know why "ant compile-xml" wasn't run. Do
we know that none of the intended users of jcommon need the XML part?
- rpmlint output:
$ rpmlint jcommon
$ rpmlint jcommon-javadoc
jcommon-javadoc.i386: W: non-standard-group Development/Documentation
$ rpmlint jcommon-1.0.12-2.fc9.src.rpm
jcommon.src: W: mixed-use-of-spaces-and-tabs (spaces: line 16, tab: line 4)
- package naming guidelines: OK
- spec file name matches package name: OK
- packaging guidelines: see below
- licensing guidelines: OK
- license file in %doc: OK
- spec file in American English: OK
- spec file is legible: OK
- sources match upstream: OK
- binary RPM build on at least one arch: OK
- ExcludeArch used appropriately: OK
- All build dependencies in BuildRequires: OK for what is built. If we also
build the XML jar, then a BuildRequires of "jaxp" is also necessary. The
package containing jcommon-xml.jar (which I think should be a subpackage) also
needs to Require jaxp in that case.
- Handles locales properly: OK
- Calls ldconfig if necessary: OK
- Relocatable: OK
- Owns all directories it creates: OK
- No duplicate %files entries: OK
- Permissions on files: OK
- Clean section in spec file: OK
- Consistent use of macros: OK
- Code or permissible content: OK
- Large documentation: OK
- Documentation not needed to run: OK
- Header files in -devel: OK
- Static libraries in -static: OK
- Proper use of pkgconfig: OK
- .so files in -devel: OK
- -devel requires main package: OK
- No .la archives: OK
- Desktop file: OK
- Don't own directories owned by others: OK
- Delete buildroot before install: OK
- All filenames in UTF-8: OK
- License file: OK
- Summary and description translations: OK
- Builds in mock: OK
- Compiles on all architectures: cannot check
- Package functions as described: OK
- Sane scriptlets: OK
- Subpackages require main package: NO, the javadoc subpackage does not do this
- Placement of pkgconfig files: OK
- File dependencies: OK
The Java and GCJ guidelines are followed, except that they want the javadoc
subpackage to Require both jpackage-utils and the main package. This is not
listed as a MUST.
Summary: as long as the jcommon-xml.jar file is produced or a rationale for why
it should not be is offered, the only failing items are SHOULD items. The
failing SHOULD items are:
- Mixed use of tabs and spaces in the spec file
- Javadoc subpackage does not Require jpackage-utils and the main package
No particular reason for not having the -xml stuff built, doesn't seem to hurt
to have it. So...
Great, thanks Caolan. The new XML parts doesn't break any of the previously
reviewed items, so this is good.
Oops, forgot to assign the bug to me.
Thanks for rescuing this from review ghetto :-)
Caolan: Can you add a cvs template here with what branches you want, etc?
ug, forgot final step
New Package CVS Request
Package Name: jcommon
Short Description: JFree Java utility classes
Cvsextras Commits: yes
imported, can't actually build it yet. But I assume it'll all come together
after devel auto moves to F-10
Package change Request
Package Name: jcommon
New branches: EL-5 F-9
New branch owners: lkundrak
Contacted Fedora maintainer two days ago, and he did't respond (though he seems
to read other mails). One of my packages is stuck on dependency on this. I'll
still be glad and thankful if caolan maintained this in the requested branches
if he wants to (if he responds, and agrees to, just ignore the relevant line of
the above request).