[Bug 492990] Review Request: zynjacku - LV2 synths and plugins host

Fri Apr 10 17:15:17 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=492990

--- Comment #1 from Mattias Ellert <mattias.ellert at fysast.uu.se>  2009-04-10 13:15:16 EDT ---
Fedora review zynjacku-4-1.fc10.src.rpm 2009-04-10

* OK
! needs attention
? needs confirmation

* rpmlint silent

  $rpmlint *.rpm zynjacku.spec
  3 packages and 1 specfiles checked; 0 errors, 0 warnings.

* Package is named according to guidelines

* The spec file is named after the package

* The stated license (GPLv2 and GPLv2+ and LGPLv2+ and Public Domain)
  is approved by Fedora

! The license tag in the specfile correctly discribes the license of
  the sources. However, the license tag should describe the license of
  the content of the binary packages. The content of the binary
  package in this case is the two python script lv2rack.py and
  zynjacku.py, and the shared library zynjacku_c.so. None of the
  header files are packaged as part of the binary package.

  - The python scripts are licensed under GPLv2.

  - The shared library is compiled from sources having the 4 different
    licenses you state in the License tag. A compiled unit compiled
    from sources with different but compatible licenses falls under
    the strictest of the licenses, in this case GPLv2. See:
    https://fedoraproject.org/wiki/Licensing/FAQ#Multiple_licensing_situations

  So all components of the packaged binary package are GPLv2, so the
  License tag should simply be GPLv2.

* The package includes the license file (gpl.txt)

* The specfile is written in legible English

* Source matches upstream and is latest version

  20ead5385b1a47f0a148f9f27e8889ef  zynjacku-4.tar.bz2
  20ead5385b1a47f0a148f9f27e8889ef  SRPM/zynjacku-4.tar.bz2

! Package compiles in mock (Fedora 10), however the specfile uses sed
  to change configure and aclocal.m4 thereby changing the timestamps
  on these files resulting in compilation warnings like:

aclocal.m4:14: error: this file was generated for autoconf 2.61.
You have another version of autoconf.  If you want to use that,
you should regenerate the build system entirely.
aclocal.m4:14: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
automake-1.10: autoconf failed with exit status: 63
WARNING: `automake-1.10' is probably too old.  You should only need it if
         you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
         You might want to install the `Automake' and `Perl' packages.
         Grab them from any GNU archive site.
cd . && /bin/sh ./config.status Makefile depfiles
config.status: creating Makefile
config.status: executing depfiles commands
cd . && /bin/sh /builddir/build/BUILD/zynjacku-4/config/missing --run
autoheader
aclocal.m4:14: error: this file was generated for autoconf 2.61.
You have another version of autoconf.  If you want to use that,
you should regenerate the build system entirely.
aclocal.m4:14: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
autoheader: '/usr/bin/autom4te' failed with exit status: 63
WARNING: `autoheader' is probably too old.  You should only need it if
         you modified `acconfig.h' or `configure.ac'.  You might want
         to install the `Autoconf' and `GNU m4' packages.  Grab them
         from any GNU archive site.

  The timestamps should either be restored after the change:

  sed s/A/B/ file > file.new ; touch -r file file.new ; mv file.new file

  or all files that are generated from the changed files should be
  touched in the appropriate order, so that regeneration is not
  triggered,

  or the full autoconf bootstrap chain should be rerun so that all
  files are generated with the autotools version of the distribution
  the RPM is compiled for.

  The first option is the easiest one to implement.

  At closer inspection, I don't think the modification is needed at
  all. The hardcoded path that is changed by the sed replacement is
  only used as a fallback when the call to sysconfig.get_python_lib
  fails, which should never happen.

  Rebuilding the package with the sed replacements removed still puts
  the library in /usr/lib64/python2.5/site-packages/zynjacku_c.so on
  x86_64 - without the warnings caused by changing the timestamps.

? Build requires are sane, I think. But there is a "no" during configure:

  checking for LV2... yes
  checking for GTK... yes
  checking for PYGTK... yes
  checking for JACK... yes
  checking for LV2DYNPARAMHOST1... yes
  checking for SLV2... yes
  checking for JACK_MIDI... yes
  checking for OLD_JACK_MIDI... no

  I assume since JACK_MIDI is found OLD_JACK_MIDI isn't needed, right?

* No shared libraries in default library search path

? The package owns the directories it creates, or depend on packages
  that do. The dependency path to the owner of the directory
  /usr/share/icons/hicolor/72x72/apps is quite long though:

  zynjacku → pygtk2-libglade → pygtk2 → gtk2 → hicolor-icon-theme

  You are confident that any future updates to any of the packages in
  this chain will not break it?

* No double listed files

* File permissions are sane and %files has %defattrs

* %clean clears buildroot

* The specfile uses macros consistently

* Package contains code

* %doc is not essential for running

* No headers, no static libraries, no pkg-config files, no shared
  libraries in default library search path, no .la files

* .desktop files are installed using desktop-file-install in the
  %install section

* Package does not own other's directories

* %install clears buildroot

* Installed filenames are valid UTF-8

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