[Bug 640205] Review Request: visualvm - Lightweight profiler that integrates many command-line JDK tools

bugzilla at redhat.com bugzilla at redhat.com
Thu Oct 7 13:45:25 UTC 2010


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

--- Comment #10 from Stanislav Ochotnicky <sochotni at redhat.com> 2010-10-07 09:45:25 EDT ---
(In reply to comment #8)
> Be sure I'm runing rpmlint ;) Most of this is caused by upstream, And I can do
> nearly nothing with it. 

first priority: packaging guidelines
second priority: making upstream happy

> http://koji.fedoraproject.org/koji/getfile?taskID=2519784&name=visualvm-1.3-2.fc14.src.rpm

Please next time provide separate link to spec file so it can be accessed
directly without digging it up from srpm

> here is bugfix and my comments (going out of upstream):
> visualvm.src: W: invalid-license GPLv2 + Classpath Exception
>  -This is how upstream has chosen to License it, and it is a widely known
> license type.

This license name is invalid. This has nothing to do with upstream. You are
supposed to use "Short name" column from
https://fedoraproject.org/wiki/Licensing#Good_Licenses for license tag.

> visualvm.src: W: patch-not-applied Patch0: visualvm-debuginfo.patch
>  -patch is applied, because of it's nature, in build. And IS applied

Add comment to the spec file explaining this.

> visualvm.x86_64: W: non-etc-or-var-file-marked-as-conffile
> /usr/lib64/visualvm/etc/visualvm.clusters
> visualvm.x86_64: W: non-etc-or-var-file-marked-as-conffile
> /usr/lib64/visualvm/etc/visualvm.conf
>  -Upstream maintains conf files within %{_libdir}/visualvm/etc/ .. thereis
> nothing I can change about it
> 
> visualvm.x86_64: W: no-documentation
>  -Upstream does not provide any.

How about COPYING file?

> visualvm.x86_64: E: zero-length
> /usr/lib64/visualvm/visualvm/config/Modules/org-netbeans-modules-options-keymap.xml_hidden
> ...
> visualvm.x86_64: E: zero-length /usr/lib64/visualvm/profiler/.lastModified
>  -Upstream generates them and it is best not to delete them as upstream may
> rely on them for something.
>
> visualvm.x86_64: W: hidden-file-or-dir
> /usr/lib64/visualvm/profiler/.lastModified
>  -Added by upstream build.

Are they really needed? "Upstream may rely on them for something" is not the
answer. If you can't figure out if these files are really needed, ask upstream.
If there is no other way, remove these empty files and re-create them in post
(remove in postun). Though I very much doubt it would harm anything if they
were missing.

> visualvm.x86_64: W: dangling-symlink /usr/lib64/visualvm
> /platform/usr/share/netbeans/platform12
>  -visualvm depends on netbeans and the above target will exist when netbeans is
> installed. (tested by installation)

No problem here

> visualvm.x86_64: W: no-manual-page-for-binary jvisualvm
>  -Binary launches a gui.

no problem

> visualvm.x86_64: W: non-standard-dir-in-usr jvm
>  -Created by upstream -- not much I can change.

Really? You are using configure instead of %configure macro and you are not
setting sysconfdir. I am guessing that's why etc dir ends up in /usr

> visualvm-debuginfo.x86_64: W: invalid-license GPLv2 + Classpath Exception
> 3 packages and 0 specfiles checked; 18 errors, 12 warnings.
> 
> 
> visualvm.x86_64: W: conffile-without-noreplace-flag
> /usr/lib64/visualvm/etc/visualvm.clusters
> visualvm.x86_64: W: non-etc-or-var-file-marked-as-conffile
> /usr/lib64/visualvm/etc/visualvm.conf
> -FIXED
> 
> visualvm-debuginfo.x86_64: E: debuginfo-without-sources
> -FIXED (by upstream and in spec)

I'll start official review, but you'll have to fix those issues one way or the
other.

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



More information about the package-review mailing list