Summary: | sci-visualization/gnuplot-4.6.2-r1 - ./gnuplot.texi:17653: raising the section level of @subsubsection which is too low (with sys-apps/texinfo-5.1) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrés Becerra Sandoval <andres.becerra> |
Component: | Current packages | Assignee: | Ulrich Müller <ulm> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | cmue81, junghans, Martin.vGagern, sci, vityokster |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://sourceforge.net/p/gnuplot/bugs/1226/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 464362 | ||
Attachments: |
build log
Fix info source gnuplot-4.6.2-texinfo-5.patch gnuplot-4.6.2-r1.ebuild.patch gnuplot-4.6.3.ebuild.patch gnuplot-4.6.2-r1-to-4.6.3.ebuilds.diff |
Description
Andrés Becerra Sandoval
2013-04-01 15:24:33 UTC
Please attach the complete build log. Created attachment 344038 [details]
build log
Same error here, build log attached.
This is almost certainly linked to the doc USE flag.
I'm a bit surprised that the process terminates although this error message does not appear fatal.
I recently updated texinfo from 4.13-r2 to 5.1. As I had gnuplot-4.6.2 installed before, this seems to be related to the texinfo upgrade.
Created attachment 344052 [details, diff]
Fix info source
This patch keeps texinfo 5.x happy. It omits the @ref inside the @uref, and raises all the terminal type sections from @subsubsection to @subsection level, as they are children of a @section, the "complete list of terminals". Emerged all right for me.
Thanks Martin, the patch works for me. (In reply to comment #1) > Please attach the complete build log. Martin did it first, is my same problem. I have applied Martin's patch and emerged the package successfully. Thanks! Can you please report this upstream, too? Created attachment 344122 [details, diff] gnuplot-4.6.2-texinfo-5.patch gnuplot.texi is a generated file, so the fix should really be applied to doc2texi.el, see attached patch. OTOH, that would require Emacs as build-time dependency. We had that previously, and some people were unhappy with that (see bug 368269, bug 369097, bug 400999, and numerous duplicates). So maybe we should use Martin's patch in addition, so that gnuplot.texi doesn't need to be regenerated. @Christoph: What is your opinion? (In reply to comment #7) > Created attachment 344122 [details, diff] [details, diff] > gnuplot-4.6.2-texinfo-5.patch > > gnuplot.texi is a generated file, so the fix should really be applied to > doc2texi.el, see attached patch. > > OTOH, that would require Emacs as build-time dependency. We had that > previously, and some people were unhappy with that (see bug 368269, bug > 369097, bug 400999, and numerous duplicates). So maybe we should use > Martin's patch in addition, so that gnuplot.texi doesn't need to be > regenerated. > > @Christoph: What is your opinion? I personally think gnuplot's build-in help is anyway the best way to find information and considering the fact that we had trouble with the texi generation before, let's just bundle a recent version and add a "noinfo" use flag. (In reply to comment #6) > Can you please report this upstream, too? It is reported already: http://sourceforge.net/p/gnuplot/bugs/1226/ (In reply to comment #8) > I personally think gnuplot's build-in help is anyway the best way to find > information and considering the fact that we had trouble with the texi > generation before, let's just bundle a recent version and add a "noinfo" use > flag. Excellent idea. I've packed gnuplot.info (generated with makeinfo 4.13) in an extra tarball and uploaded it to Gentoo mirrors. The updated ebuild will follow soon. I haven't added the noinfo flag though, as the additional distfile has less then 200 kbytes which is negligible. (In reply to comment #9) > > Can you please report this upstream, too? > > It is reported already: > > http://sourceforge.net/p/gnuplot/bugs/1226/ We can close the downstream bug then. Thanks for reporting! *** Bug 464504 has been marked as a duplicate of this bug. *** This problem is back in sci-visualization/gnuplot-4.6.3, due to the fact that the ebuild copies the old info file without touching its timestamp. Since gnuplot.info will end up being older than gnuplot.texi, make will still attempt to rebuild it, resulting in the described issues. The patch from comment #3 can still be used to fix this, so even though the documentation is originally generated via doc2texi.el, as comment #7 states, the resulting gnuplot.texi is shipped with the package and can be used for patching. Personally I'd consider this approach better than the pre-compiled texinfo documents, since it is more source-oriented, more the Gentoo way to do this, and would avoid the burden of having to keep the info reasonably up to date. (In reply to comment #13) > The patch from comment #3 can still be used to fix this, so even though the > documentation is originally generated via doc2texi.el, as comment #7 states, > the resulting gnuplot.texi is shipped with the package and can be used for > patching. Personally I'd consider this approach better than the pre-compiled > texinfo documents, since it is more source-oriented, more the Gentoo way to > do this, and would avoid the burden of having to keep the info reasonably up > to date. And I personally think, we should just get rid of this info file completely. Is your above patch still valid for 4.6.3 ? (In reply to comment #13) > The patch from comment #3 can still be used to fix this, so even though the > documentation is originally generated via doc2texi.el, as comment #7 states, > the resulting gnuplot.texi is shipped with the package and can be used for > patching. Personally I'd consider this approach better than the pre-compiled > texinfo documents, since it is more source-oriented, more the Gentoo way to > do this, and would avoid the burden of having to keep the info reasonably up > to date. The "Gentoo way" is what I've outlined in comment #7. (In reply to comment #14) > And I personally think, we should just get rid of this info file completely. > Is your above patch still valid for 4.6.3 ? Patching a generated file is not a proper solution. Also the patch is a bit large for FILESDIR, so we'd have to put it on mirrors. (In reply to comment #15) > Patching a generated file is not a proper solution. Also the patch is a bit > large for FILESDIR, so we'd have to put it on mirrors. 535 bytes is quite large?? wow! come on, if gentoo devs would have just fixed it like originally proposed, this discussion would long be over. patching a distributed file is fine - it's a file from upstream. e.g., we do not run eautoreconf all the time, unless necessary. Greetings btw: imho, for indeed larger patches, portage could just hold them gzipped or xz'd. and epatch shoul handle that just as well if it does not already. (In reply to comment #16) > 535 bytes is quite large?? wow! come on, if gentoo devs would have just > fixed it like originally proposed, this discussion would long be over. The patch for the texinfo file has 16 kB size which is close to the repoman limit. I'd rather not put it in filesdir. Concerning the rest of your comment: Please read up on the relevant policies before posting. (In reply to comment #17) > The patch for the texinfo file has 16 kB size which is close to the repoman > limit. I'd rather not put it in filesdir. Ah, sorry - mixed this up with your own patch. You did not go into why patches cannot be held zipped in portage. Looking at the obsoleted patch there is a lot of repetition. If we can find a regexp catching the subsubsections in question maybe a simple sed command will do and you won't have to care about any patch.. Greetings your fellow policy reader .. (In reply to comment #18) > (In reply to comment #17) > > The patch for the texinfo file has 16 kB size which is close to the repoman > > limit. I'd rather not put it in filesdir. > > Ah, sorry - mixed this up with your own patch. You did not go into why > patches cannot be held zipped in portage. > > Looking at the obsoleted patch there is a lot of repetition. If we can find > a regexp catching the subsubsections in question maybe a simple sed command > will do and you won't have to care about any patch.. It will: sed -e '/^@uref/ s/@ref{\([^}]*\)}/\1/' \ -e '/^@node aed767/,$ s/^@sub/@/' \ -i gnuplot.texi I hope this is small enough for portage.. Greetings Created attachment 346336 [details, diff]
gnuplot-4.6.2-r1.ebuild.patch
Created attachment 346338 [details, diff]
gnuplot-4.6.3.ebuild.patch
Created attachment 346340 [details, diff]
gnuplot-4.6.2-r1-to-4.6.3.ebuilds.diff
This is just a diff between the /patched/ ebuilds, i.e. the ones from portage with the attachment ebuild.patches of this bug applied, for reference.
This is not resolved upstream, according to the URL it's still "open". Kindly asking to review the patches for the ebuilds.. |