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=474787 --- Comment #12 from Denis Arnaud <denis.arnaud_fedora@xxxxxxx> 2009-05-31 21:32:15 EDT --- [My machine crashed just before I pressed the commit button of the review :( ] Note that, as I have not the sponsor status, that is not an official review. However, there are a number of issues (some important, some others less) that I can point to you (in no particular order). 1. Doxygen, as it is configured, generates .map files (in the doc/html sub-directory), due to the use of the DOT tool (belonging to the graphviz package). On some configurations (e.g., my Fedora rawhide/11, with rpmbuild), some of those files are generated with a zero-length, which rpmlint then complains of. There are, at least, two solutions/work-arounds: 1.a. Just drop the use of DOT in the Doxygen configuration file: HAVE_DOT = NO as in http://rmol.svn.sourceforge.net/viewvc/rmol/trunk/rmol/doc/doxygen_html.cfg.in?revision=183&view=markup As Doxygen replaces with other, simpler, diagrams, that should not be a so big issue. 1.b. Keep the use of DOT, but: - Add a 'BuildRequires: graphivz' directive. - Remove any zero-length-map files after the Doxygen generation (http://cvs.fedoraproject.org/viewvc/rpms/asterisk/F-11/asterisk.spec?revision=1.51&view=markup): find doc/html -name '*.map' -size 0 -delete Note that with mock, there is, as is, no zero-length-map-file issue, but the .map files are not generated, due to the missing 'BuildRequires: graphviz' directive. Note also that you can not see that in the build.log (http://koji.fedoraproject.org/koji/getfile?taskID=1383290&name=build.log) of Koji, as you have re-directed the output log of Doxygen into a file removed by mock. 2. Avoid re-directing the output log of Doxygen, so that that log be present in the build.log generated by mock (and Koji): make doxy > doxymake.log 2> doxymake.stderr ==> make doxy 3. You may consider creating a separate -doc sub-package for both the HTML Doxygen-generated documentation and the Latex-generated tutorial (https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation). 4. I would rather keep the PDF version of the tutorial, rather than the DVI one. Moreover, we could alter the Makefile so that it generates only the PDF version (which is now the default with latex). 5. In the %files section, you should take ownership of the %{_includedir}/bits directory (https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership): %dir %{_includedir}/bits/ 6. Still in the %files sections, it may be better to use a wildcard for the libraries, as it will still hold for future versions of the library: %{_libdir}/libstxxl.so.* 7. You may replace instances of stxxl with the %{name} macro, and of 1.2.1 with the %{version} macro (https://fedoraproject.org/wiki/Packaging/Guidelines#Macros). For instance: --------------------------------------------------- URL: http://%{name}.sourceforge.net Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz Patch0: %{name}-build-shared.patch Patch1: %{name}-build-shared-makefile.patch --------------------------------------------------- x. The build system (makefiles) appears to be very specific to that package, and it may not be portable. For instance, you have to install the files manually yourself in the specification file. If you consider to bring a GNU Autotools environment (and submit the corresponding patch upstream), and if I can help you, do not hesitate. -- 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review