Bug 491581 - Review Request: jVorbisEnc - Pure Java Ogg Vorbis Encoder
Summary: Review Request: jVorbisEnc - Pure Java Ogg Vorbis Encoder
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mattias Ellert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 492203
TreeView+ depends on / blocked
 
Reported: 2009-03-23 06:48 UTC by Orcan Ogetbil
Modified: 2009-05-09 04:18 UTC (History)
2 users (show)

Fixed In Version: 0.1-3.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-02 16:25:21 UTC
Type: ---
Embargoed:
mattias.ellert: fedora-review+
dennis: fedora-cvs+


Attachments (Terms of Use)

Description Orcan Ogetbil 2009-03-23 06:48:55 UTC
Spec URL: http://oget.fedorapeople.org/review/jVorbisEnc.spec
SRPM URL: http://oget.fedorapeople.org/review/jVorbisEnc-0.1-1.fc10.src.rpm
Description: 
JVorbis is a music encoder, which compresses high quality audio format
(44.1-48.0kHz, 16+ bit, polyphonic).


rpmlint:
   jVorbisEnc.src:93: W: libdir-macro-in-noarch-package %{_libdir}/gcj/%{name}
This one is a false alarm. The package is not noarch.   

   jVorbisEnc.x86_64: W: no-documentation
Nothing we can do. There is no documentation in the source tarball, except the javadoc we produce.


Package fails to build in ppc64:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=1253732

I don't know if this is fixable. Any help will be appreciated.

Comment 1 Orcan Ogetbil 2009-04-30 02:29:38 UTC
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

Comment 2 Mattias Ellert 2009-04-30 17:23:09 UTC
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

Comment 3 Orcan Ogetbil 2009-04-30 17:59:50 UTC
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+?

Comment 4 Mattias Ellert 2009-04-30 23:10:35 UTC
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.

Comment 5 Orcan Ogetbil 2009-05-01 02:59:04 UTC
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+

Comment 6 Mattias Ellert 2009-05-01 03:30:42 UTC
Package approved. But keep bugging upstream...

Comment 7 Orcan Ogetbil 2009-05-01 03:38:09 UTC
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:

Comment 8 Dennis Gilmore 2009-05-01 20:53:40 UTC
CVS Done

Comment 9 Fedora Update System 2009-05-01 22:58:46 UTC
jVorbisEnc-0.1-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/jVorbisEnc-0.1-3.fc11

Comment 10 Fedora Update System 2009-05-01 22:59:32 UTC
jVorbisEnc-0.1-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/jVorbisEnc-0.1-3.fc10

Comment 11 Fedora Update System 2009-05-01 23:00:22 UTC
jVorbisEnc-0.1-3.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/jVorbisEnc-0.1-3.fc9

Comment 12 Fedora Update System 2009-05-02 16:25:16 UTC
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.

Comment 13 Fedora Update System 2009-05-02 16:32:31 UTC
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.

Comment 14 Fedora Update System 2009-05-09 04:18:04 UTC
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.


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