Spec URL: http://oget.fedorapeople.org/review/lv2-swh-plugins.spec SRPM URL: http://oget.fedorapeople.org/review/lv2-swh-plugins-1.0.15-1.fc10.src.rpm Description: This is an early experimental port of my LADSPA plugins to the LV2 specification, c.f. http://lv2plug.in/ . It's still quite early days, but most things should work as well or not as they did in LADSPA. rpmlint is silent. The package is named as lv2-swh-plugins for consistency with other plugins we have (ladspa-xxx-plugins). koji rawhide build: https://koji.fedoraproject.org/koji/taskinfo?taskID=1266472
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?
(In reply to comment #1) > Fedora review lv2-swh-plugins-1.0.15-1.fc10.src.rpm 2008-04-23 > Thanks again! > ! 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. > I made a patch to fix these issues. I also sent my modifications upstream via email, since they don't have a bugtracker. > ? 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? It is upstream's decision. There is no generic way of naming the plugins. There are other plugins that I haven't packaged yet which have named their .so files in their own way, like $pluginname.so Some plugins even contain multiple .so files in the same directory. I don't think it is worth to change the names manually. The plugin host applications usually scan the %{_libdir}/lv2/ directory for plugins and dlopen them. For instance, the lv2-calf-plugins made it to the rawhide repo, and it has its own conventions. Spec URL: http://oget.fedorapeople.org/review/lv2-swh-plugins.spec SRPM URL: http://oget.fedorapeople.org/review/lv2-swh-plugins-1.0.15-1.fc10.src.rpm Changelog: - 1.0.15-2 - Fix unresolved symbols
I am well aware of "it's upstream's decision" issues. There are plenty of those in the packages I try to package as well. Package approved.
Thanks! New Package CVS Request ======================= Package Name: lv2-swh-plugins Short Description: LV2 ports of LADSPA swh plugins Owners: oget Branches: F-10 F-11 InitialCC:
cvs done.
lv2-swh-plugins-1.0.15-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/lv2-swh-plugins-1.0.15-2.fc11
lv2-swh-plugins-1.0.15-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/lv2-swh-plugins-1.0.15-2.fc10
lv2-swh-plugins-1.0.15-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 lv2-swh-plugins'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4075
lv2-swh-plugins-1.0.15-2.fc11 has been pushed to the Fedora 11 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 lv2-swh-plugins'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-4605
lv2-swh-plugins-1.0.15-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
lv2-swh-plugins-1.0.15-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.