Bug 480607 - Review Request: bluecove - Implementation of JSR-82 Java Bluetooth API
Summary: Review Request: bluecove - Implementation of JSR-82 Java Bluetooth API
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
Depends On: 490101
TreeView+ depends on / blocked
Reported: 2009-01-19 13:18 UTC by François Kooman
Modified: 2011-06-15 18:30 UTC (History)
6 users (show)

Fixed In Version: bluecove-2.1.1-0.2.20101024snap63.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-15 18:30:37 UTC
orion: fedora-review+
kevin: fedora-cvs+

Attachments (Terms of Use)

Description François Kooman 2009-01-19 13:18:10 UTC
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
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 :)

Comment 1 François Kooman 2009-01-25 16:03:04 UTC
* 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

Comment 2 François Kooman 2009-03-14 15:25:21 UTC
* 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

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

Comment 3 François Kooman 2009-03-14 15:27:49 UTC
Correct SRPM URL: http://users.tuxed.net/fkooman/rpmbuild/SRPMS/bluecove-2.1.1-0.20090314.fc10.src.rpm

Comment 4 François Kooman 2009-05-16 21:42:31 UTC
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

Comment 5 Orion Poplawski 2009-10-20 20:31:49 UTC
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-
     [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)
/builddir/build/BUILD/bluecove-2.1.1-SNAPSHOT/bluecove-bluez-2.1.1-SNAPSHOT/build.xml:142: apply returned: 1

Comment 6 François Kooman 2009-10-28 20:13:50 UTC
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!

Comment 7 François Kooman 2010-01-10 17:46:52 UTC
=== 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-

while my local machine does:      [echo] create JNI headers using java.home /usr/lib/jvm/java-1.6.0-openjdk-

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.

Comment 8 Orion Poplawski 2010-01-11 16:10:26 UTC
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:

Now you need to drop noarch, because JNI files are arch specific.

Also, you can change:

%dir %{_libdir}/%{name}

to just:


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.

Comment 9 François Kooman 2010-01-11 19:01:24 UTC
=== files ===
Spec URL: http://fkooman.fedorapeople.org/bluecove/bluecove.spec

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! :)

Comment 10 François Kooman 2010-02-07 21:54:32 UTC
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

Comment 11 Orion Poplawski 2010-04-09 23:02:33 UTC
    *  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 


    * 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

Comment 12 François Kooman 2010-04-12 18:19:46 UTC
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

* 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

Comment 13 Orion Poplawski 2010-04-14 23:05:56 UTC
Looks good.  Approved.

Comment 14 François Kooman 2010-05-03 13:11:21 UTC
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

Comment 15 Kevin Fenzi 2010-05-04 02:29:17 UTC
CVS done (by process-cvs-requests.py).

Comment 16 Tareq Al Jurf 2010-08-27 20:07:04 UTC
ping François

Comment 17 François Kooman 2010-08-28 06:38:33 UTC
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...

Comment 18 Tareq Al Jurf 2010-08-28 13:46:55 UTC
No, no problem.
I've thought you forgot it or something like that.

Regards :)

Comment 19 François Kooman 2010-11-03 20:10:25 UTC
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

Comment 20 Orion Poplawski 2010-11-03 20:14:19 UTC
Why not.

Comment 21 Alexander Kurtakov 2011-06-03 06:20:59 UTC
I would say just import and build. 
You can always update to newer release after that.

Comment 22 Fedora Update System 2011-06-04 14:53:31 UTC
bluecove-2.1.1-0.2.20101024snap63.fc15 has been submitted as an update for Fedora 15.

Comment 23 Fedora Update System 2011-06-07 04:24:29 UTC
bluecove-2.1.1-0.2.20101024snap63.fc15 has been pushed to the Fedora 15 testing repository.

Comment 24 Fedora Update System 2011-06-15 18:30:29 UTC
bluecove-2.1.1-0.2.20101024snap63.fc15 has been pushed to the Fedora 15 stable repository.

Note You need to log in before you can comment on or make changes to this bug.