http://bugzilla.rpmfusion.org/show_bug.cgi?id=680
--- Comment #3 from NicolasChauvet <[email protected]> 2009-06-24 16:14:39 --- (In reply to comment #2) > Hello Nic, > > Feel free to have a look at the package review for the initial alsa-plugins > https://bugzilla.redhat.com/show_bug.cgi?id=222248, it says something about > the > maemo package. No legal reasons, but lack of any other relevant package for > the > N800 platform. If that has changed then I could revisit the inclusion of the > maemo package in fedora. the maemo plateform target an arm processor. This plugin is only usefull to control the dsp on such plateform. There is no dependency expect from dbus. from the fedora alsa-plugin, we could have : %ifarch arm --enable-maemo-plugin \ --enable-maemo-resource-manager \ %else --disable-maemo-plugin \ %endif (For some reason this has to be explicitly disabled or enabled - and then have the related -maemo sub-package done) There is a maemo sub-package that can be found for some distro on ix86 and x86_64. But I expect it will be usefull only for development purpose. (And I'm not even sure). > Regarding the speex plugin, it depends on ffmpeg > which is part of rpmfusion so yes, speex would be a good candidate for > inclusion in rpmfusion. If speex was in livna at the time of the alsa-plugin review, this is not the case anymore. You can enable it from the fedora package (then I will disable it). > This is not a formal review: > > * Looking at your package, it would be best to split this into separate > sub-packages so people do not end up with everything and the kichen sink when > they only want the a52 plugin for example. The current shape, only the a52 and lavcrate plugin are provided (in other word, only needs the libavcodec dependency since a52 from libavcodec extends feature wise the previous a52dec implementation.) I would like to keep the freeworld keyword, and stay monolithic unless other dependencies are added... > * For consistency, you should include a sample configuration file for the > plugins. I'm not a > * You should also include the matching doc for each of you sub-package taken > out of the doc/ dir > > * missing %post and %postun I don't think ldconfig should be run on library meant to be dlopened from a path not added to the linker (_libdir/alsa-lib ). If it is required, then ldconfig need to be run on %post and %postun for each sub-package as : %post subpackage -p /sbin/ldconfig %postun subpackage -p /sbin/ldconfig But I'm very confident that this is not required at all. (at least grep libasound_module /etc/ld.so.cache doesn't seems to output anything). > * Are you sure that --with-speex=lib compiles on x86_64 ? yes, the lib option isn't related to the library path on lib64. It stands for system library over "no" speex usage or "builtin" speex library (understand statically linked). (Furthermore, x86_64 is my primary testing platform, so yes it works). But I will not enable speex from there since it should go to fedora. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.
