Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libvirt-java: Java bindings for the libvirt library https://bugzilla.redhat.com/show_bug.cgi?id=453119 tibbs@xxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nobody@xxxxxxxxxxxxxxxxx |tibbs@xxxxxxxxxxx Status|NEW |ASSIGNED Flag| |fedora-review? ------- Additional Comments From tibbs@xxxxxxxxxxx 2008-07-03 21:42 EST ------- Yes, this builds. In addition to the strange-permission complaint above (which isn't a problem) rpmlint says: libvirt-java-javadoc.x86_64: W: non-standard-group Development/Documentation which is bogus; we don't care what goes in Group: libvirt-java.x86_64: E: zero-length /usr/share/doc/libvirt-java-0.1.2/NEWS There's generally no point in shipping an empty file. Is it needed for something? libvirt-java.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libvirt_jni.so.0.1.2 /usr/lib64/libxenstore.so.3.0 This just means that libvirt_jni links against libxenstore but doesn't call any functions in it. This is pretty common with pkgconfig files since they maximally specify link flags; generally easy to correct by linking with "-Wl,--as-needed" but not really a big issue as long as it doesn't result in expanded dependencies, which it doesn't here. The Source: tag should contain a URL to the sources: Source: http://libvirt.org/sources/java/libvirt-java-%{version}.tar.gz Your BuildRoot must contain at least %{release}.http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag The license looks to be LGPLv2+ to me. None of the source files have the proper license blocks, and so the license in the COPYING.LIB files allows us to choose any version of the LGPL that has ever or will ever exist. The use of gcj is only a strong suggestion but not a requirement, so I'm certainly not going to block on it here. My understanding is that we still have platforms where gcj is needed, but I guess that's between you and the (rest of) the java team. The javadoc subpackage needs dependencies on the main package and jpackage-utils. I'm pretty sure that test.java file isn't really useful unless it has an existing virtual machine to talk to. Please correct me if I'm wrong. I have to ask: what is the point of the libvert-src zipfile? Why would a Java package need to include its source code? * source files match upstream: c746b1f8a76bdf16c0b9eb6751fa7998712ba07788a3ab5a6b4c0842a4bb7cb4 libvirt-java-0.1.2.tar.gz * package meets naming and versioning guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * summary is OK. * description is OK. * dist tag is present. X build root needs at least %{release}. X license field does not match the actual license. * license is open source-compatible. * license text included in package. * latest version is being packaged. * BuildRequires are proper. * %clean is present. * package builds in mock (rawhide, x86_64). * package installs properly. * debuginfo package looks complete (no java files since gcj isn't called). X rpmlint has a valid complaint (zero-length NEWS file). X final provides and requires: libvirt-java-0.1.2-1.fc10.x86_64.rpm libvirt_jni.so.0()(64bit) libvirt-java = 0.1.2-1.fc10 = /sbin/ldconfig java >= 1.5.0 jpackage-utils libvirt >= 0.4.0 libvirt.so.0()(64bit) libvirt_jni.so.0()(64bit) libxenstore.so.3.0()(64bit) libvirt-java-devel-0.1.2-1.fc10.x86_64.rpm libvirt-java-devel = 0.1.2-1.fc10 = libvirt-devel >= 0.4.0 libvirt-java = 0.1.2-1.fc10 libvirt_jni.so.0()(64bit) pkgconfig libvirt-java-javadoc-0.1.2-1.fc10.x86_64.rpm libvirt-java-javadoc = 0.1.2-1.fc10 = X no dependencies on jpackage-utils or main package. * %check is not present; test code can't be run in the buildsys. * shared libraries installed: ldconfig is called properly. unversioned .so links are in the -devel package * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * scriptlets OK (ldconifg). * code, not content. * %docs are not necessary for the proper functioning of the package. * no headers. * pkgconfig files in the -devel package; pkgconfig dependency included. * no static libraries. * no libtool .la files. * no pre-built jars * single jar, named after the package * jarfiles are under _javadir. * javadocs are under _javadocdir. -- 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, or are watching someone who is. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review