Bug 492990 - Review Request: zynjacku - LV2 synths and plugins host
Review Request: zynjacku - LV2 synths and plugins host
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: 492969
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-31 00:10 EDT by Orcan Ogetbil
Modified: 2009-05-09 00:26 EDT (History)
2 users (show)

See Also:
Fixed In Version: 4-2.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-06 19:32:29 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+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Orcan Ogetbil 2009-03-31 00:10:18 EDT
Spec URL: http://oget.fedorapeople.org/review/zynjacku.spec
SRPM URL: http://oget.fedorapeople.org/review/zynjacku-4-1.fc10.src.rpm
Description: 
zynjacku is JACK based, GTK (2.x) host for LV2 synths. It has one JACK MIDI
input port (routed to all hosted synths) and one (two for stereo synths) JACK
audio output port per plugin. Such design provides multi-timbral sound by
running several synth plugins.

zynjacku is a nunchaku weapon for JACK audio synthesis. You have solid parts
for synthesis itself and you have flexible part that allows synthesis to suit
your needs.

lv2rack is a host for LV2 effect plugins.



rpmlint is silent.

I wasn't sure if I should split lv2rack to its own subpackage. Any ideas welcome.
Comment 1 Mattias Ellert 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
Comment 2 Orcan Ogetbil 2009-04-10 14:43:07 EDT
(In reply to comment #1)
> Fedora review zynjacku-4-1.fc10.src.rpm 2009-04-10
> 

Thank you for the review!

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

Thanks for the correction. Changed to GPLv2

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

Yes, removing sed's don't break anything. I should've been more careful. I wiped out those sed's.

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

Correct.

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

All of them are solid dependencies. gtk2 → hicolor-icon-theme dependency is used in many packages. I don't think that will be broken in their lifetime.


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

Changelog: 4-2
- License is GPLv2
- Clean up unnecessary bits from SPEC file
Comment 3 Mattias Ellert 2009-04-17 08:14:00 EDT
Package Approved.
Comment 4 Orcan Ogetbil 2009-04-17 11:15:48 EDT
Thank you!

New Package CVS Request
=======================
Package Name: zynjacku
Short Description: LV2 synths and plugins host
Owners: oget
Branches: F-10
InitialCC:
Comment 5 Kevin Fenzi 2009-04-17 12:51:01 EDT
I assume you want a F-11 branch here as well. 

cvs done with F-11 added.
Comment 6 Fedora Update System 2009-04-17 15:24:33 EDT
zynjacku-4-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/zynjacku-4-2.fc11
Comment 7 Orcan Ogetbil 2009-04-17 15:26:53 EDT
(In reply to comment #5)
> I assume you want a F-11 branch here as well. 
> 
> cvs done with F-11 added.  

yes, indeed. thanks!
Comment 8 Fedora Update System 2009-04-17 20:33:52 EDT
zynjacku-4-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/zynjacku-4-2.fc10
Comment 9 Fedora Update System 2009-04-21 20:56:54 EDT
zynjacku-4-2.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update zynjacku'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3814
Comment 10 Fedora Update System 2009-05-06 19:32:23 EDT
zynjacku-4-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2009-05-09 00:26:10 EDT
zynjacku-4-2.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.