Hello. linuxdoc-tools-0.9.69 was released a while ago. A bump is needed as well as a new maintainer. I would like to step up as a proxy-maintainer for this. Please find the proposed ebuild attached below.
Created attachment 410140 [details] linuxdoc-tools-0.9.69.ebuild Lots of things were changed here since 0.9.68-r1: - inherit autotools-utils for ebuild simplification - inherit perl-module to avoid ugly `eval` code - drop lex patch as it was merged upstream - replace malloc patch with sed one-liner - drop letter patch as the relevant ChangeLog entry from cvs just says: "Add patches from fedora", but I see no point going for 'letter' instead of 'a4' just because Fedora did so. Maybe there is a reason, but I was unable to deduce it from ChangeLog or ebuild comments. - update compiler patch - avoid bad code in src_{compile,install} and make ebuild look nicer @proxy-maint, please review.
Created attachment 410142 [details, diff] files/linuxdoc-tools-0.9.69-compiler.patch
Created attachment 410144 [details] metadata.xml
CC'ing @proxy-maint.
I do not encounter https://bugs.gentoo.org/show_bug.cgi?id=555848 bug with this ebuild.
Created attachment 410306 [details, diff] files/linuxdoc-tools-0.9.69-compiler.patch Add patch comment
Created attachment 410322 [details, diff] files/linuxdoc-tools-0.9.69-disable-doc-build.patch
Created attachment 410324 [details] linuxdoc-tools-0.9.69.ebuild Updated ebuild with 'doc' USE added. Unfortunately, upstream chose to unconditionally build and install docs during the _install_ phase. No configure options or other ways to avoid this are provided. Simply removing doc/ dir from sources won't do either. Whole build system has very much hardcoded stuff, so this is not a mistake, but a practice. The last resort and the only sane solution in this case is to patch out the relevant section from Makefile for '-doc' installs.
Created attachment 410344 [details] linuxdoc-tools-0.9.69.ebuild Move groff back to DEPEND. Though everything builds fine without it, linuxdoc.in file stores whether installed version of groff accepts mgs macro at compile time. Without groff installed it is automagic. linuxdoc.in later becomes /usr/bin/linuxdoc.
(In reply to Coacher from comment #8) > Created attachment 410324 [details] > linuxdoc-tools-0.9.69.ebuild > > Updated ebuild with 'doc' USE added. > > Unfortunately, upstream chose to unconditionally build and install docs > during the _install_ phase. No configure options or other ways to avoid this > are provided. Simply removing doc/ dir from sources won't do either. Whole > build system has very much hardcoded stuff, so this is not a mistake, but a > practice. > > The last resort and the only sane solution in this case is to patch out the > relevant section from Makefile for '-doc' installs. hi, I would suggest you talk to upstream, to see whether they'd like to make 'doc' configurable/optional, if answer is negative, then I would personally suggest just install doc unconditionally, instead of carrying/maintaining patches downstream.. still, I would say "let's try to avoid conditional patch" [1] use doc || epatch "${FILESDIR}/${P}-disable-doc-build.patch" [1] https://blog.flameeyes.eu/2008/06/why-conditional-patching-and-autotools-rebuild-is-a-bad-idea#gsc.tab=0 https://archives.gentoo.org/gentoo-osx/message/1deb37467f875a559b62a86b126ef396 for the metadata.xml, mind you give your full name for credit? example as (including the irc nick if you do have, people can ping you there) <maintainer> <email>dlan@gentoo.org</email> <name>Yixun 'dlan' Lan</name> <description>Primary Maintainer, Assign bugs</description> </maintainer> and finally, thanks for your contribution!
(In reply to Yixun Lan from comment #10) > hi, I would suggest you talk to upstream, to see whether they'd like to make > 'doc' configurable/optional Will do. But for now let us have a cleaned, modernized ebuild with this only sin we aware of. > if answer is negative, then I would personally > suggest just install doc unconditionally, instead of carrying/maintaining > patches downstream. It is not a hard patch to maintain. Throwing away lines is easy. But compiling tons of latex stuff just to build guide, which is not needed for normal functioning of this program can be irritating to many users. > still, I would say "let's try to avoid conditional patch" [1] > use doc || epatch "${FILESDIR}/${P}-disable-doc-build.patch" > > [1] > https://blog.flameeyes.eu/2008/06/why-conditional-patching-and-autotools- > rebuild-is-a-bad-idea#gsc.tab=0 > https://archives.gentoo.org/gentoo-osx/message/ > 1deb37467f875a559b62a86b126ef396 Thanks for the links! This problem was discussed on #proxy-maint IRC channel. Currently the conclusion is to have conditional patching because upstream doing lots and lots of hardcoding and probably will require lots and lots of convincing to make a change. But I'll definitely going to discuss it with them. > for the metadata.xml, mind you give your full name for credit? Maybe next time)
Created attachment 410354 [details] linuxdoc-tools-0.9.69.ebuild Minor sed formatting update.
commit 333ab91f8ad50666e86fe5f1ad914243c8321da7 Author: Ian Delaney <idella4@gentoo.org> Date: Wed Aug 26 22:58:17 2015 +0800 app-text/linuxdoc-tools: bump; major rewrite with new patches Add new proxy user maintainer to metadata requested via bug #558610, all patches and ebuild submitted, discussed and run tested by Coacher, patching to build and install to manage non standard doc build, closes the bug #558610
Talk to upstream, to see whether they'd like to make 'doc' configurable/optional is standard procedure. If Coacher wishes to that's fine but this build and install is so off the wall, well, standard procedure really doesn't apply.