Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: rapidsvn - Graphical interface for the Subversion version-control system https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190139 ------- Additional Comments From tibbs@xxxxxxxxxxx 2006-04-27 21:55 EST ------- Oops, it seems I took this package by mistake, but I'll go ahead and do a review. Right off, there's a build failure on x86_64: checking for Subversion headers... found checking for Subversion libraries... not found configure: error: Subversion libraries are required. Try --with-svn-lib. error: Bad exit status from /var/tmp/rpm-tmp.54929 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.54929 (%build) Error building package from rapidsvn-0.9.1-1.src.rpm, See build log ending However, the build succeeds on i386. My assumption is that it isn't checking /usr/lib64 for the subversion libraries. You can probably pass --with-svn-lib="/usr/lib /usr/lib64" to build everywhere. Issues: You include the COPYING file, but it contains only the string "Fill me in with licensing information". The actual license is more complex than just GPL, it seems. LICENSE.txt contains all of the details, so it should probably be packaged. I think "GPL and LGPL" would be a more appropriate license tag. Is autoconf really required? I didn't see it being called in the build log, and removing it doesn't seem to hurt anything. rpmlint complains: E: rapidsvn library-without-ldconfig-postin /usr/lib/libsvncpp.so.0.0.0 E: rapidsvn library-without-ldconfig-postun /usr/lib/libsvncpp.so.0.0.0 You need to call ldconfig in %post and %postun: see http://fedoraproject.org/wiki/ScriptletSnippets (the "Shared Libraries" section). W: rapidsvn devel-file-in-non-devel-package /usr/lib/libsvncpp.so The guidelines indicate that if you have a versioned .so, the unversioned one must go in a -devel package. It seems there's a bunch of headers included in /usr/include; those should probably go in a -devel package as well. (Well, they're .hpp files, which I haven't seen before, but they look like C++ class definitions.) There does seem to be some kind of test suite (in src/tests/svncpp), but I'm not sure how you would go about calling it. This isn't a blocker, but you might want to take a look. Review: * package meets naming and packaging guidelines. * specfile is properly named, is cleanly written and uses macros consistently. X license field matches the actual license. X license is open source-compatible and included upstream but is not included in the package. * source files match upstream: ba03034db35912c7b51b146cc7e6090e rapidsvn-0.9.1.tar.gz ba03034db35912c7b51b146cc7e6090e rapidsvn-0.9.1.tar.gz-srpm ? BuildRequires are proper (not sure about autoconf) X package fails to build in mock (development, x86_64). X rpmlint is silent. O final provides and requires are sane. X shared libraries are present; ldconfig should be called but isn't. * package is not relocatable. * owns the directory it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * %clean is present. O %check not present; there seems to be an upstream test suite, but it's not immediately obvious how it would be called. * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. X headers present in main package. * no pkgconfig files. * no libtool .la droppings. * a GUI app; desktop file properly installed with desktop-file-install. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review