[Bug 492945] Review Request: lv2-swh-plugins - LV2 ports of LADSPA swh plugins

bugzilla at redhat.com bugzilla at redhat.com
Thu Apr 23 14:10:33 UTC 2009


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=492945





--- Comment #1 from Mattias Ellert <mattias.ellert at fysast.uu.se>  2009-04-23 10:10:32 EDT ---
Fedora review lv2-swh-plugins-1.0.15-1.fc10.src.rpm 2008-04-23

rpmlint output:

3 packages and 1 specfiles checked; 0 errors, 0 warnings.

* OK
! needs attention
? needs clarification

* Package is named according to guidelines.

* Spec file is named after the package.

* The package is licensed with a Fedora approved license (GPLv2+).

* There are parts of the sources in the tarfile under other licenses,
  but as far as I can tell all files in the binary RPM have at least
  one source file under GPLv2+, so GPLv2+ is correct for the full binary
  RPM.

* The sources has no (relevant) license file, and the binary package
  doesn't either. (There is a util/gsm/COPYRIGHT file, but the code in
  the util/gsm directory is not compiled during the build.)

* The specfile is written in legible English

  The answer to the comment "FIXME: Fix weird permissions. How can we
  handle this in %%prep?" is to use "install -m 644" instead of
  "install" when installing the .ttl files. But then the command must
  be split in two because the .so files installed in the same command
  should not have 644 permission, but the default 755. It might be
  easier to do it the way it is currently done, and ask upstream to
  fix it for a later version.

* Sources matches upstream and is the latest version:
  c78f42c36d7bf2fb5b17f795ef9636d1  swh-lv2-1.0.15.tar.gz
  c78f42c36d7bf2fb5b17f795ef9636d1  SRPM/swh-lv2-1.0.15.tar.gz

* Package compiles in mock (Fedora 10)

! Some of the plugins have undefined symbols. This is OK if the
  undefined symbols are available in the application that loads the
  plugins, but it might be safer to link the plugins to the libraries
  providing the missing symbols if this can not always be guaranteed.

  62 of the 91 plugins have missing symbols from libm (sin, cos, tan,
  exp, sqrt, log, pow, etc.)

  In addition the following undefined symbols are present:

  undefined symbol: shm_open
 (/usr/lib64/lv2/analogue_osc-swh.lv2/plugin-Linux.so)
  undefined symbol: shm_open
 (/usr/lib64/lv2/fm_osc-swh.lv2/plugin-Linux.so)
  undefined symbol: shm_open
 (/usr/lib64/lv2/hermes_filter-swh.lv2/plugin-Linux.so)
  undefined symbol: fftwf_plan_r2r_1d
 (/usr/lib64/lv2/mbeq-swh.lv2/plugin-Linux.so)
  undefined symbol: fftwf_execute
 (/usr/lib64/lv2/mbeq-swh.lv2/plugin-Linux.so)
  undefined symbol: fftwf_destroy_plan
 (/usr/lib64/lv2/mbeq-swh.lv2/plugin-Linux.so)
  undefined symbol: pitch_scale
 (/usr/lib64/lv2/pitch_scale-swh.lv2/plugin-Linux.so)

  At least the last one is potentially tricky since the header file
  that provides this symbol is within the source tarball, but the
  corresponding implementation file is not compiled: util/pitchscale.h
  and util/pitchscale.c. Or is there a different implementation of
  this function somewhere that is used to resolve the missing symbol
  when the plugin is loaded.

  The other undefined symbols in the list above are from librt and
  libfftw3f - are the applications loading the plugins always linked
  to these libraries?

  The plugins in the other two packages have no undefined symbols.

* BuildRequires are sane.

* No shared libraries in the default library path.

* Owns or depends on packages that own it directories

* No duplicate files

* Permissions are sane and %files has %defattr

* %clean clears buildroot

* macros are used consistently

* Contains code

* %doc is not essential at runtime

* Package does not own other's directories

* %install clears buildroot

* Installed filenames are valid UTF-8

? The plugins from this package are all labelled with a -Linux suffix,
  while this is not the case for the plugins from the other two plugin
  packages. What is the reason for not being consistent among the
  different packages?

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.




More information about the package-review mailing list