$ rpmlint SPECS/mydumper.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint SRPMS/mydumper-0.2.3-1.fc14.src.rpm mydumper.src: I: enchant-dictionary-not-found en_US 1 packages and 0 specfiles checked; 0 errors, 0 warnings. $ rpmlint /var/lib/mock/epel-5-x86_64/result/mydumper-*x86_64.rpm mydumper.x86_64: I: enchant-dictionary-not-found en_US mydumper.x86_64: W: no-manual-page-for-binary mydumper mydumper.x86_64: W: no-manual-page-for-binary myloader 2 packages and 0 specfiles checked; 0 errors, 2 warnings. Man pages do not exist for binaries, but this is listed as a 'SHOULD": http://fedoraproject.org/wiki/Packaging/ReviewGuidelines I did bring this to upstreams attention: https://answers.launchpad.net/mydumper/+question/165220 ====== Spec URL: https://raw.github.com/jness/mydumper/master/SPECS/mydumper.spec SRPM URL: https://github.com/jness/mydumper/blob/master/SRPMS/mydumper-0.2.3-1.fc14.src.rpm?raw=true Description: Mydumper (aka. MySQL Data Dumper) is a high-performance multi-threaded backup (and restore) toolset for MySQL and Drizzle. The main developers originally worked as Support Engineers at MySQL (one has moved to Facebook and another to SkySQL) and this is how they would envisage mysqldump based on years of user feedback.
Just commenting: - The build fails in mock for F15 x86_64. - Is the explicit mysql Require necessary? I couldn't actually test the package (see above) but a mock build for F14 shows that the automatic requirements do include libmysqlclient. If it is, you should add a comment to explain it (http://fedoraproject.org/wiki/Packaging:Guidelines#Requires). - CMakeLists.txt shouldn't be included in the documentation.
Thank you for looking over this Veeti, - I'm sorry I should have mentioned this is a EL5/EL6 package (not Fedora) - You are correct, a explicit Requires of mysql is not needed, I was being over hesitant with the existence of mysql51 and mysql55 IUS packages. - CMakeLists.txt has been removed from %doc ======= Spec URL: https://raw.github.com/jness/mydumper/master/SPECS/mydumper.spec SRPM URL: https://github.com/jness/mydumper/blob/master/SRPMS/mydumper-0.2.3-2.fc14.src.rpm?raw=true
Upstream mentioned docs & man pages are created with Sphinx: https://bugs.launchpad.net/bzr/+bug/534330 I'm going to attempt working in man pages and docs for this build
Unfortunately in order to create the Man pages with Sphinx python-docutil 0.6 or greater is required, however in EPEL we only have 0.5: http://download.fedora.redhat.com/pub/epel/5/SRPMS/repoview/python-docutils.html === build.log === [ 83%] Building manual page with Sphinx cd /builddir/build/BUILD/mydumper-0.2.3/docs && /usr/bin/sphinx-1.0-build -q -b man -c /builddir/build/BUILD/mydumper-0.2.3/docs/_build -d /builddir/build/BUILD/mydumper-0.2.3/doc s/_doctrees /builddir/build/BUILD/mydumper-0.2.3/docs/_sources /builddir/build/BUILD/mydumper-0.2.3/docs/man Making output directory... Sphinx error: The docutils manual page writer can't be found; it is only available as of docutils 0.6. === Spec URL: https://github.com/jness/mydumper/blob/master/SPECS/mydumper.spec SRPM URL: https://github.com/jness/mydumper/blob/master/SRPMS/mydumper-0.2.3-2.fc14.src.rpm?raw=true
Due to the requirements of python-docutils 0.6 or greater I decided it best to copy the man pages from a Fedora build via SOURCES. At the moment python-docutils is 0.5 in EPEL 5 and does not exist in EPEL 6. Spec URL: https://github.com/jness/mydumper/blob/master/SPECS/mydumper.spec SRPM URL: https://github.com/jness/mydumper/blob/master/SRPMS/mydumper-0.2.3-2.fc14.src.rpm?raw=true
Adding correct paths to files: Spec URL: https://github.com/jness/mydumper/blob/master/SPECS/mydumper.spec SRPM URL: https://github.com/jness/mydumper/blob/master/SRPMS/mydumper-0.2.3-3.fc14.src.rpm?raw=true
With the availability of python-sphinx > 1.0 and python-docutils > 0.6 on EL6 and Fedora I decided it best to have these build from sphinx on them: Spec URL: https://raw.github.com/jness/mydumper/master/SPECS/mydumper.spec SRPM URL: https://github.com/jness/mydumper/blob/master/SRPMS/mydumper-0.2.3-4.fc14.src.rpm?raw=true === This build was tested on Fedora 14, EL6, and EL5 from Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=3216086
Hi, I'm one of the core developers of mydumper (currently the main developer). Can you please let us know how you got around the following linking error when building on Fedora?: /usr/src/mydumper/binlog.c:160: undefined reference to `my_net_read' I believe this is due to the stripping of libmysqlclient. We have a bug report on this at: https://bugs.launchpad.net/mydumper/+bug/803982 I'd love to be able to document how to work around this :) Also, thanks again for your hard work on making this happen!
Hello Andrew, As you can see in the build.log I never ran in to this undefined reference while building for EL5: http://koji.fedoraproject.org/koji/getfile?taskID=3254341&name=build.log I did throw in a Fedora 15 build just to see the result and I was able to reproduce the error listed in the bug above: http://koji.fedoraproject.org/koji/getfile?taskID=3254355&name=build.log What is strange is I do not run across this issue on Fedora 14: http://koji.fedoraproject.org/koji/getfile?taskID=3254371&name=build.log == Jeffrey-
Many thanks for narrowing that down. It also appears to affect Mandriva as their packaging team have pointed out. I have a F15 box to play with so I'll see if anything can be done about it without changing your MySQL binaries next week. My wild guess (without looking at the .spec or anything) is MySQL is compiled with a GCC visibility flag or something which is hiding the my_net_read function as it is not supposed to be a publicly accessible part of the API but is needed for binary log retrieval.
Found the cause, filed a feature request in Bug #728634
Ping?
Jeffrey, we don't have too many resources on contacting non-responsive package submitter, if you can't respond in a week, I will close this. If someone is interested in this package, feel free to submit. Otherwise I will do this.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days