Hide Forgot
Spec URL: http://users.tuxed.net/fkooman/rpmbuild/SPECS/bluecove.spec SRPM URL: http://users.tuxed.net/fkooman/rpmbuild/SRPMS/bluecove-2.1.0-1.fc10.src.rpm Description: BlueCove is a JSR-82 implementation on Java Standard Edition (J2SE) that currently interfaces with the Mac OS X, WIDCOMM, BlueSoleil and Microsoft Bluetooth stack. Originally developed by Intel Research and currently maintained by volunteers. Implementation of JSR-82 Java Bluetooth API. Additional GPL licensed module to support BlueCove runtime on Linux BlueZ. Issues with this package that still need to addressed: - in the i386 builds the bluecove-gpl package includes debug files, this is not the case on x86_64, I have no idea what is going on here. - whether or not to have a bluecove-gpl subpackage as bluecove package without bluecove-gpl package installed is useless. - the bluecove-gpl jar file and the native library are installed in %{_libdir}/bluecove but the "main" bluecove.jar file is installed in %{_javadir}, this seems a bit cluttered as you now need to include 2 jars from different locations in your apps classpath - rpmlint complains about "No binary" in the bluecove.jar file, it should probably be noarch, but I didn't find many JAR files that have BuildArch: noarch... - javadoc subpackage should be BuildArch: noarch as well? Upstream is very helpful in helping resolving packaging issues and committed already some things useful for packaging to svn :)
* Sun Jan 25 2009 François Kooman <fkooman@tuxed.net> - 2.1.0-2 - remove javadoc sub package, there isn't any real documentation, only references to JSR-82 API docs at jcp.org - create symlinks without version numbers - remove gpl sub package, bluecove without gpl subpackage is useless - include the interesting docs from gpl subpackage in the package instead of the subpackage - include README.dist Issues remaining: - debug files in i386 package... - it probably won't work immediately on ppc/ppc64 as there is only a check for i386 and x86_64 in the library loader at runtime (no ppc hardware to test on, it does build correctly in koji) Spec URL: http://users.tuxed.net/fkooman/rpmbuild/SPECS/bluecove.spec SRPM URL: http://users.tuxed.net/fkooman/rpmbuild/SRPMS/bluecove-2.1.0-2.fc10.src.rpm
* Sat Mar 14 2009 François Kooman <fkooman@tuxed.net> - 2.1.1-0.20090314 - prepare for release 2.1.1, update to snapshot 20090314 - remove upstreamed patches - add bluecove-bluez (uses dbus for device discovery) disabled for now as we need dbus-java >= 2.5.1 (BZ #490101) - add bluecove-emu - move libraries to versioned directory in libdir/bluecove per upstream request - remove ldconfig post and postun as other apps don't link to this - update README.dist - update package description Spec URL: http://users.tuxed.net/fkooman/rpmbuild/SPECS/bluecove.spec SRPM URL: http://users.tuxed.net/fkooman/rpmbuild/SRPMS/http://users.tuxed.net/fkooman/rpmbuild/SRPMS/bluecove-2.1.1-0.20090314.fc10.src.rpm Issues: - wait for dbus-java 2.5.1 to enable bluecove-bluez (#490101) - remove Classpath from manifest? (bluecove-bluez) - still debug files in i386 build?! - it probably won't work immediately on ppc/ppc64 as there is only a check for i386 and x86_64 in the library loader at runtime (no ppc hardware to test on) - wait for bluecove 2.1.1 final release (should be there in a month or so) Scratch Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1241412
Correct SRPM URL: http://users.tuxed.net/fkooman/rpmbuild/SRPMS/bluecove-2.1.1-0.20090314.fc10.src.rpm
Update to latest snapshot, and moved to fedorapeople hosting. Spec URL: http://fkooman.fedorapeople.org/bluecove/bluecove.spec SRPM URL: http://fkooman.fedorapeople.org/bluecove/bluecove-2.1.1-0.20090505.fc11.src.rpm
You need to document how the snapshot files were created. Generally you create a script that does it and include it in the SRPM. Is it possible to enable gcj support? Duplicate requires: Requires: dbus-java >= 2.5.1 Requires: dbus-java Getting a build failure on current F-12: [echo] create JNI headers using java.home /usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre compile-native-lib: [echo] compiling .c -> .o (-fPIC -fno-stack-protector) [apply] /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/src/main/c/BlueCoveLocalSocket.c: In function 'localSocketOptions2unix': [apply] /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/src/main/c/BlueCoveLocalSocket.c:404: error: 'org_bluecove_socket_LocalSocketImpl_LocalSocketOptions_SO_LINGER' undeclared (first use in this function) [apply] /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/src/main/c/BlueCoveLocalSocket.c:404: error: (Each undeclared identifier is reported only once [apply] /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/src/main/c/BlueCoveLocalSocket.c:404: error: for each function it appears in.) [apply] /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/src/main/c/BlueCoveLocalSocket.c:407: error: 'org_bluecove_socket_LocalSocketImpl_LocalSocketOptions_SO_RCVTIMEO' undeclared (first use in this function) [apply] /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/src/main/c/BlueCoveLocalSocket.c:410: error: 'org_bluecove_socket_LocalSocketImpl_LocalSocketOptions_SO_SNDTIMEO' undeclared (first use in this function) [apply] /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/src/main/c/BlueCoveLocalSocket.c:413: error: 'org_bluecove_socket_LocalSocketImpl_LocalSocketOptions_SO_SNDBUF' undeclared (first use in this function) [apply] /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/src/main/c/BlueCoveLocalSocket.c:416: error: 'org_bluecove_socket_LocalSocketImpl_LocalSocketOptions_SO_RCVBUF' undeclared (first use in this function) [apply] /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/src/main/c/BlueCoveLocalSocket.c:419: error: 'org_bluecove_socket_LocalSocketImpl_LocalSocketOptions_SO_PASSCRED' undeclared (first use in this function) BUILD FAILED /builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/build.xml:142: apply returned: 1
I'm getting the same build error now on Fedora 11 with all updates. Update to latest upstream snapshot does not seem to help. I need to look into this some more (and possibly consult upstream). When I get it to compile again I'll look into gcj support. Thanks for taking this review!
=== files === Spec URL: http://fkooman.fedorapeople.org/bluecove/bluecove.spec SRPM URL: http://fkooman.fedorapeople.org/bluecove/bluecove-2.1.1-0.20090914.fc12.src.rpm === changes === * Sun Jan 10 2010 François Kooman <fkooman@tuxed.net> - 2.1.1-0.20090914 - update snapshot to 20090914 - fix source links to snapshot version - add GCJ support === rpmlint === Not sure about why it complains about libmatthew-java... [fkooman@franek SPECS]$ rpmlint bluecove.spec bluecove.spec:172: W: libdir-macro-in-noarch-package (main package) %dir %{_libdir}/%{name} bluecove.spec:173: W: libdir-macro-in-noarch-package (main package) %{_libdir}/%{name}/* bluecove.spec:177: W: libdir-macro-in-noarch-package (main package) %attr(-,root,root) %{_libdir}/gcj/%{name} 0 packages and 1 specfiles checked; 0 errors, 3 warnings. [fkooman@franek SPECS]$ rpmlint ../SRPMS/bluecove-2.1.1-0.20090914.fc12.src.rpm bluecove.src:172: W: libdir-macro-in-noarch-package (main package) %dir %{_libdir}/%{name} bluecove.src:173: W: libdir-macro-in-noarch-package (main package) %{_libdir}/%{name}/* bluecove.src:177: W: libdir-macro-in-noarch-package (main package) %attr(-,root,root) %{_libdir}/gcj/%{name} 1 packages and 0 specfiles checked; 0 errors, 3 warnings. [fkooman@franek SPECS]$ rpmlint ../RPMS/x86_64/bluecove-2.1.1-0.20090914.fc12.x86_64.rpm bluecove.x86_64: E: explicit-lib-dependency libmatthew-java 1 packages and 0 specfiles checked; 1 errors, 0 warnings. [fkooman@franek SPECS]$ === builds === bluecove-bluez has some issues with gcj. With OpenJDK generated headers it works fine. Koji does: [echo] create JNI headers using java.home /usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre while my local machine does: [echo] create JNI headers using java.home /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre I guess I have to fix this JNI compilation stuff with gcj, I don't think upstream will be interested in this... See http://koji.fedoraproject.org/koji/getfile?taskID=1912388&name=build.log for the error.
If it can't compile with gcj, don't worry about it. Many packages I guess are dropping it now. To force OpenJDK use, you can do: BuildRequires: java-devel >= 1:1.6.0 Requires: java >= 1:1.6.0 I did a build dropping gcj and adding the above here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1914251 Now you need to drop noarch, because JNI files are arch specific. Also, you can change: %dir %{_libdir}/%{name} %{_libdir}/%{name}/* to just: %{_libdir}/%{name} The rpmlint warning is just complaining about any Requires that starts with "lib". For many languages, these requirements are generated automatically, but we're not quite there yet with Java.
=== files === Spec URL: http://fkooman.fedorapeople.org/bluecove/bluecove.spec SRPM URL: http://fkooman.fedorapeople.org/bluecove/bluecove-2.1.1-0.20090914.1.fc12.src.rpm Is the version okay like this? It is still possible to change it. Maybe it's nicer to mention the snapshot number (60 in this case)? === changes === * Mon Jan 11 2010 François Kooman <fkooman@tuxed.net> - 2.1.1-0.20090914.1 - remove GCJ support again as it breaks bluecove-bluez - fix files section redundancy === rpmlint === Clean now except the lib* error, which can be ignored. === scratch builds === F12: http://koji.fedoraproject.org/koji/taskinfo?taskID=1914693 F13: http://koji.fedoraproject.org/koji/taskinfo?taskID=1914682 Thanks for your time! :)
I modified the version to make more sense. Upgrade path is not OK, but as there is no release yet anyway, it doesn't really matter. Spec URL: http://fkooman.fedorapeople.org/bluecove/bluecove.spec SRPM URL: http://fkooman.fedorapeople.org/bluecove/bluecove-2.1.1-0.1.20090914snap60.fc12.src.rpm
* rpmlint rpmlint bluecove-debuginfo bluecove-debuginfo.i686: E: debuginfo-without-sources Looks like the source is not making it info the debuginfo package for some reason. * naming - OK * NamingGuidelines - OK * licensing - Looks like that there are still some files (e.g. BlueCoveBlueZ_RFCOMMServer.c) under the LGPLv2+ license. I don't think that is an issue but I think it needs to be mentioned in the spec and perhaps brought to the attention of upstream. * osi approved? - OK * included? - OK * correct mentioned in specfile? - NO specfile * American English - OK * legible - OK * ExcludeArch, blocking - OK * BuildRequires - OK * Locales - OK * shared libraries: ldconfig - OK * %clean section with rm -rf ${RPM_BUILD_ROOT} - OK * macros - OK * sources - OK * relocatable? Prefix: /usr? - OK * files and directories - OK * owns all created directories - OK * all files listed in %files - OK * permissions? - OK * deffattr? - OK * no .la files - OK * .desktop for GUI applications - OK * no conflicts with other packages - OK * -devel - NA * permissable content - OK * doc - OK * large doc in -doc package - OK * must not affect runtime - OK * mock build - http://koji.fedoraproject.org/koji/taskinfo?taskID=2106889 OK * sane scriptlets - OK * subpackages with fully versioned dependency - NA
It seems the bluecove-gpl JNI files are licensed LGPLv2+. I added LGPLv2+ as license as well. I made sure GCC gets the RPM_OPT_FLAGS parameter so the correct compiler flags are used. This solves the no sources in the debuginfo package. @Vlad: there are some warnings now in the JNI C code (both bluecove-gpl and bluecove-bluez) because of the new (more strict) compiler flags. See the build log at http://koji.fedoraproject.org/koji/getfile?taskID=2111403&name=build.log, maybe you can find some time to look at those :) Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2111401 Changelog: * Mon Apr 12 2010 François Kooman <fkooman@tuxed.net> - 2.1.1-0.1.20100401snap62 - update to new snapshot - make use of RPM_OPT_FLAGS for compiling JNI libs - add license LGPLv2+ to license tag as bluecove-gpl uses it Spec URL: http://fkooman.fedorapeople.org/bluecove/bluecove.spec SRPM URL: http://fkooman.fedorapeople.org/bluecove/bluecove-2.1.1-0.1.20100401snap62.fc12.src.rpm
Looks good. Approved.
I'll be waiting for the Bluecove 2.1.1 official release before I'll add them to Fedora 14/13. Thanks for your review! New Package CVS Request ======================= Package Name: bluecove Short Description: Implementation of JSR-82 Java Bluetooth API Owners: fkooman Branches: F-13 InitialCC:
CVS done (by process-cvs-requests.py).
ping François
Pong :) I'm waiting for version 2.1.1 of Bluecove before importing Bluecove, but it doesn't seem to happen :( I can import http://fkooman.fedorapeople.org/bluecove/bluecove-2.1.1-0.1.20100401snap62.fc12.src.rpm if you like and forget about 2.1.1 for now...
No, no problem. I've thought you forgot it or something like that. Regards :)
Update to newer snapshot (and compiled on Fedora 14 and it still works!). Waiting for official 2.1.1 release. It seems it will take some time still. Maybe I should just import this version of Bluecove and see how it goes. SRPM URL: http://fkooman.fedorapeople.org/bluecove/bluecove-2.1.1-0.1.20101024snap63.fc14.src.rpm Spec URL: http://fkooman.fedorapeople.org/bluecove/bluecove.spec
Why not.
I would say just import and build. You can always update to newer release after that.
bluecove-2.1.1-0.2.20101024snap63.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/bluecove-2.1.1-0.2.20101024snap63.fc15
bluecove-2.1.1-0.2.20101024snap63.fc15 has been pushed to the Fedora 15 testing repository.
bluecove-2.1.1-0.2.20101024snap63.fc15 has been pushed to the Fedora 15 stable repository.