Bug 491581

The issue is with aot bits on ppc64 is reported in bug 498351.

Spec URL: http://oget.fedorapeople.org/review/jVorbisEnc.spec
SRPM URL: http://oget.fedorapeople.org/review/jVorbisEnc-0.1-2.fc10.src.rpm

Changelog: 0.1-2
- Disable building of aot bits on ppc64 (RHBZ #498351)

Package now builds in koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1329608

Fedora review jVorbisEnc-0.1-2.fc10.src.rpm 2009-04-30

rpmlint output:

[ellert@ellert jVorbisEnc]$ rpmlint 5310124110877769772196/result/jVorbisEnc/*.rpm jVorbisEnc.spec 
jVorbisEnc.src:97: W: libdir-macro-in-noarch-package (main package) %{_libdir}/gcj/%{name}
jVorbisEnc.x86_64: W: no-documentation
jVorbisEnc.spec:97: W: libdir-macro-in-noarch-package (main package) %{_libdir}/gcj/%{name}
4 packages and 1 specfiles checked; 0 errors, 3 warnings.

* OK
! needs attention

* rpmlint warnings are bogus - rpmlint does not understand the
  conditional BuildArch.

* Package is named according to the guidelines

* The specfile is named after the package

* The package follows the guidelines for a native Java package.
  Disabling the broken AOT bits for ppc64 makes sense, and a bug
  report is filed.

* Package license is Fedora approved (BSD)

! The sources say: "THIS LIBRARY SOURCE IS GOVERNED BY A BSD-STYLE
  SOURCE LICENSE INCLUDED WITH THIS SOURCE IN 'COPYING'", but there is
  no COPYING file in the source tree! This is strange... Did upstream
  make a mistake creating the source tarfile? Also - one (and only
  one) of all the source files (src/biniu/vorbis/AllocChain.java) says
  it is LGPL. Is this an oversight from upstream, or is it
  intentional? This too seems strange. If this one source file really
  is LGPL, I don't think you can release the package as BSD, since
  LGPL is more restrictive and the most restrictive license "wins".
  But it seems strange that the licensing of the package should depend
  on a single source file containing 5 lines of code (excluding
  comments and empty lines). Is upstream aware of this bizarre
  situation?

* There is no license file, and hence it can not be installed as %doc

* The specfile is written in legible English

* Sources matches upstream:

8476478045d6f7c0114272bc8bab97e1  jVorbisEnc_src.zip
8476478045d6f7c0114272bc8bab97e1  SRPM/jVorbisEnc_src.zip

* Package builds in mock (Fedora 10)

* BuildRequires are sane

* No shared libraries

* Package owns the directories it creates

* No duplicate files

* Permissions are sane and %files has %defattr

* %clean clears buildroot

* Consistent use of macros

* Documentation in -javadoc package

* Package does not own other's directories

* %install clears buildroot

* Installed filenames are valid UTF-8

Good catch. When I saw that there is no COPYING file, I looked at the website
   http://zbigniew.sudnik.org/app/vorbis/vorbis.html
which says the license is BSD.

The file src/biniu/vorbis/AllocChain.java contains only a 5-line class definition. It might be a mistake by the author. The header of that file also suggests that that part of the code is borrowed from jorbis. But when I checked the jorbis code, I found that it does not contain such a class.

Unfortunately, the only way to contact the author is the email address I found on the website (I downloaded all the other packages on his website, they don't carry contact information either). I sent an email to this address but I am not sure if he still uses this email, as the website hasn't been touched in the last 4 years.

Meanwhile, what is the best way out of this in case we can't get a hold of him? Should I make the license tag BSD and LGPLv2+?

According to the licensing guidelines the License tag should reflect the license of the components of the binary RPM, not the sources. The binary RPM has only one component - the jarfile. So the license tag should reflect its license. If you only have the present situation and the author can not provide clarification the jarfile is a unit compiled from some sources licensed as BSD and some sources as LGPLv2+. The license of the resulting unit must be the most restrictive license, i.e. LGPLv2+. So the only component in the binary RPM is LGPLv2+, and no component is BSD - so the license tag should then be LGPLv2+. It really is weird that the license of the package is given by the license of 5 lines of code - but this is how I read the Licensing guidelines.

Ok, then. I'll adjust it later if I ever get a response from upstream.

Spec URL: http://oget.fedorapeople.org/review/jVorbisEnc.spec
SRPM URL: http://oget.fedorapeople.org/review/jVorbisEnc-0.1-3.fc10.src.rpm

Changelog: 0.1-3
- License is LGPLv2+

Package approved. But keep bugging upstream...

Sure, I will. Thanks!

New Package CVS Request
=======================
Package Name: jVorbisEnc
Short Description: Pure Java Ogg Vorbis Encoder
Owners: oget
Branches: F-9 F-10 F-11
InitialCC:

CVS Done

jVorbisEnc-0.1-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/jVorbisEnc-0.1-3.fc11

jVorbisEnc-0.1-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/jVorbisEnc-0.1-3.fc10

jVorbisEnc-0.1-3.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/jVorbisEnc-0.1-3.fc9

jVorbisEnc-0.1-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

jVorbisEnc-0.1-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

jVorbisEnc-0.1-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.