Bug 491581 - Review Request: jVorbisEnc - Pure Java Ogg Vorbis Encoder
Review Request: jVorbisEnc - Pure Java Ogg Vorbis Encoder
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mattias Ellert
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 492203
  Show dependency treegraph
 
Reported: 2009-03-23 02:48 EDT by Orcan Ogetbil
Modified: 2009-05-09 00:18 EDT (History)
2 users (show)

See Also:
Fixed In Version: 0.1-3.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-02 12:25:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mattias.ellert: fedora‑review+
dennis: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Orcan Ogetbil 2009-03-23 02:48:55 EDT
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-29 22:29:38 EDT
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 13:23:09 EDT
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 13:59:50 EDT
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 19:10:35 EDT
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-04-30 22:59:04 EDT
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-04-30 23:30:42 EDT
Package approved. But keep bugging upstream...
Comment 7 Orcan Ogetbil 2009-04-30 23:38:09 EDT
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 16:53:40 EDT
CVS Done
Comment 9 Fedora Update System 2009-05-01 18:58:46 EDT
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 18:59:32 EDT
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 19:00:22 EDT
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 12:25:16 EDT
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 12:32:31 EDT
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 00:18:04 EDT
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.