| Message ID | 87pojmjdep.fsf@dusky.pond.sub.org |
|---|---|
| State | New |
| Headers | show |
Hi On Tue, Jan 17, 2017 at 12:34 PM Markus Armbruster <armbru@redhat.com> wrote: > Peter Maydell <peter.maydell@linaro.org> writes: > > > On 16 January 2017 at 09:33, Markus Armbruster <armbru@redhat.com> > wrote: > >> This is Marc-André's "[PATCH v8 00/21] qapi doc generation (whole > >> version, squashed)" with a few commit messages tweaked, and "[PATCH v8 > >> 14/21] (SQUASHED) move doc to schema" unsquashed into 161 patches. > >> > >> We did all the respins with in this squashed form to reduce noise. > >> However, since the unsquashed form is better suited for review, and > >> probably nicer if we have to revisit this part of the work down the > >> road, I'm proposing to merge this unsquashed. > >> > >> If you want me to post the unsquashed patches, I'm happy to redo this > >> pull request. > >> > >> If you'd rather pull the squashed version, likewise. > >> > >> I'm afraid this is a bit of a doc conflict magnet. The sooner we can > >> get it in, the easier for Marc-André and me. > >> > >> v2: > >> * Rebased (v1 conflicts with commit e1ff3c6) > >> * test-qapi.py tweaked to avoid trailing empty lines in .out > >> > >> The following changes since commit > b6af8ea60282df514f87d32e36afd1c9aeee28c8: > >> > >> Merge remote-tracking branch > 'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging > (2017-01-13 14:38:21 +0000) > >> > >> are available in the git repository at: > >> > >> git://repo.or.cz/qemu/armbru.git tags/pull-qapi-2017-01-16 > >> > >> for you to fetch changes up to 56e8bdd46a8a42d89b0afea9da83ae7679cc0439: > >> > >> build-sys: add qapi doc generation targets (2017-01-16 10:11:43 +0100) > >> > >> ---------------------------------------------------------------- > >> QAPI patches for 2017-01-16 > > > > This seems to trigger some warnings from older makeinfo versions: > > > > On the Fedora 20 ppc64be box and Ubuntu 14.04.5 LTS aarch64 box > > (Ubuntu: makeinfo (GNU texinfo) 5.2; > > Fedora: makeinfo (GNU texinfo) 5.1) > > Nobody should be using F20 by now, but the Ubuntu LTS is still legit. > > > /home/pm215/qemu/docs/qemu-ga-ref.texi:41: warning: undefined flag: > VERSION > > /home/pm215/qemu/docs/qemu-ga-ref.texi:41: warning: undefined flag: > VERSION > > /home/pm215/qemu/docs/qemu-qmp-ref.texi:41: warning: undefined flag: > VERSION > > /home/pm215/qemu/docs/qemu-qmp-ref.texi:41: warning: undefined flag: > VERSION > > This is supposed to be defined in Makefile: > > MAKEINFO=makeinfo -D 'VERSION $(VERSION)' > > Hrrm, Texinfo's NEWS file has for 6.0: > > * texi2any: > [...] > . -D'var val' on the command line works as intended again. > > I tried to find out more about this fix, but the Texinfo repository's > commit log is useless. > > I can reproduce the warning with 6.2 by running makeinfo without -D. > Curiously, output isn't affected. Looks like @subtitle is ignored by > makeinfo. > > Possible work-around I could squash in: > > diff --git a/docs/qemu-qmp-ref.texi b/docs/qemu-qmp-ref.texi > index 818e525..e0f2454 100644 > --- a/docs/qemu-qmp-ref.texi > +++ b/docs/qemu-qmp-ref.texi > @@ -38,7 +38,9 @@ along with this manual. If not, see > http://www.gnu.org/licens > es/ <http://www.gnu.org/licenses/>. > > @titlepage > @title QMP Reference Manual > +@iftex @c Work around bug in Texinfo prior to 6.0 > @subtitle QEMU version @value{VERSION} > +@end iftex > @page > @vskip 0pt plus 1filll > @insertcopying > > Marc-André, what do you think? > Since title @subtitle is being ignored by makeinfo, that looks fine. However, I think I would prefer rather have the warning since it's a makeinfo bug on old versions and it can be ignored. Hopefully, this thread can easily be found for reference (update commit message too?). Either way, I don't mind. Thanks > > On OSX (makeinfo (GNU texinfo) 4.8): > > That's from 2004. Just sayin'. > > > ./qemu-options.texi:60: warning: unlikely character [ in @var. > > ./qemu-options.texi:60: warning: unlikely character ] in @var. > > ./qemu-options.texi:61: warning: unlikely character [ in @var. > > ./qemu-options.texi:61: warning: unlikely character ] in @var. > > Generated qemu-options.texi did not change (I checked). > > The offending lines are > > @item -numa > node[,mem=@var{size}][,cpus=@var{cpu[-cpu]}][,nodeid=@var{node}] > @itemx -numa > node[,memdev=@var{id}][,cpus=@var{cpu[-cpu]}][,nodeid=@var{node}] > > which are generated from qemu-options.hx's > > DEF("numa", HAS_ARG, QEMU_OPTION_numa, > "-numa node[,mem=size][,cpus=cpu[-cpu]][,nodeid=node]\n" > "-numa node[,memdev=id][,cpus=cpu[-cpu]][,nodeid=node]\n", > QEMU_ARCH_ALL) > > by scripts/hxtool. > > This use of @var{} is perhaps questionable, but nothing changed around > here for many moons. Are you sure this is new in my pull request? > > > (OSX also has the long standing warning > > /Users/pm215/src/qemu-for-merges/qemu-doc.texi:7: warning: > > unrecognized encoding name `UTF-8'. > > but you can ignore that since it's been that way for years > > and is because osx's makeinfo is ancient.) > > > > thanks > > -- PMM > > -- Marc-André Lureau
Marc-André Lureau <marcandre.lureau@gmail.com> writes: > Hi > > On Tue, Jan 17, 2017 at 12:34 PM Markus Armbruster <armbru@redhat.com> > wrote: > >> Peter Maydell <peter.maydell@linaro.org> writes: >> >> > On 16 January 2017 at 09:33, Markus Armbruster <armbru@redhat.com> >> wrote: >> >> This is Marc-André's "[PATCH v8 00/21] qapi doc generation (whole >> >> version, squashed)" with a few commit messages tweaked, and "[PATCH v8 >> >> 14/21] (SQUASHED) move doc to schema" unsquashed into 161 patches. >> >> >> >> We did all the respins with in this squashed form to reduce noise. >> >> However, since the unsquashed form is better suited for review, and >> >> probably nicer if we have to revisit this part of the work down the >> >> road, I'm proposing to merge this unsquashed. >> >> >> >> If you want me to post the unsquashed patches, I'm happy to redo this >> >> pull request. >> >> >> >> If you'd rather pull the squashed version, likewise. >> >> >> >> I'm afraid this is a bit of a doc conflict magnet. The sooner we can >> >> get it in, the easier for Marc-André and me. >> >> >> >> v2: >> >> * Rebased (v1 conflicts with commit e1ff3c6) >> >> * test-qapi.py tweaked to avoid trailing empty lines in .out >> >> >> >> The following changes since commit >> b6af8ea60282df514f87d32e36afd1c9aeee28c8: >> >> >> >> Merge remote-tracking branch >> 'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging >> (2017-01-13 14:38:21 +0000) >> >> >> >> are available in the git repository at: >> >> >> >> git://repo.or.cz/qemu/armbru.git tags/pull-qapi-2017-01-16 >> >> >> >> for you to fetch changes up to 56e8bdd46a8a42d89b0afea9da83ae7679cc0439: >> >> >> >> build-sys: add qapi doc generation targets (2017-01-16 10:11:43 +0100) >> >> >> >> ---------------------------------------------------------------- >> >> QAPI patches for 2017-01-16 >> > >> > This seems to trigger some warnings from older makeinfo versions: >> > >> > On the Fedora 20 ppc64be box and Ubuntu 14.04.5 LTS aarch64 box >> > (Ubuntu: makeinfo (GNU texinfo) 5.2; >> > Fedora: makeinfo (GNU texinfo) 5.1) >> >> Nobody should be using F20 by now, but the Ubuntu LTS is still legit. >> >> > /home/pm215/qemu/docs/qemu-ga-ref.texi:41: warning: undefined flag: VERSION >> > /home/pm215/qemu/docs/qemu-ga-ref.texi:41: warning: undefined flag: VERSION >> > /home/pm215/qemu/docs/qemu-qmp-ref.texi:41: warning: undefined flag: VERSION >> > /home/pm215/qemu/docs/qemu-qmp-ref.texi:41: warning: undefined flag: VERSION >> >> This is supposed to be defined in Makefile: >> >> MAKEINFO=makeinfo -D 'VERSION $(VERSION)' >> >> Hrrm, Texinfo's NEWS file has for 6.0: >> >> * texi2any: >> [...] >> . -D'var val' on the command line works as intended again. >> >> I tried to find out more about this fix, but the Texinfo repository's >> commit log is useless. >> >> I can reproduce the warning with 6.2 by running makeinfo without -D. >> Curiously, output isn't affected. Looks like @subtitle is ignored by >> makeinfo. >> >> Possible work-around I could squash in: >> >> diff --git a/docs/qemu-qmp-ref.texi b/docs/qemu-qmp-ref.texi >> index 818e525..e0f2454 100644 >> --- a/docs/qemu-qmp-ref.texi >> +++ b/docs/qemu-qmp-ref.texi >> @@ -38,7 +38,9 @@ along with this manual. If not, see >> http://www.gnu.org/licens >> es/ <http://www.gnu.org/licenses/>. >> >> @titlepage >> @title QMP Reference Manual >> +@iftex @c Work around bug in Texinfo prior to 6.0 >> @subtitle QEMU version @value{VERSION} >> +@end iftex >> @page >> @vskip 0pt plus 1filll >> @insertcopying >> >> Marc-André, what do you think? >> > > Since title @subtitle is being ignored by makeinfo, that looks fine. > However, I think I would prefer rather have the warning since it's a > makeinfo bug on old versions and it can be ignored. Hopefully, this thread > can easily be found for reference (update commit message too?). Either way, > I don't mind. Thanks My proposed work-around suppresses the warning we get from old versions of makeinfo, but might degrade the title page with future versions of makeinfo. Peter, what's your preference?
On 17 January 2017 at 08:31, Markus Armbruster <armbru@redhat.com> wrote: > Peter Maydell <peter.maydell@linaro.org> writes: >> This seems to trigger some warnings from older makeinfo versions: >> >> On the Fedora 20 ppc64be box and Ubuntu 14.04.5 LTS aarch64 box >> (Ubuntu: makeinfo (GNU texinfo) 5.2; >> Fedora: makeinfo (GNU texinfo) 5.1) > > Nobody should be using F20 by now, but the Ubuntu LTS is still legit. The F20 box is the GCC compile farm's ppc64be box, so I'm not going to drop it from the build system list I'm afraid. >> /home/pm215/qemu/docs/qemu-ga-ref.texi:41: warning: undefined flag: VERSION >> /home/pm215/qemu/docs/qemu-ga-ref.texi:41: warning: undefined flag: VERSION >> /home/pm215/qemu/docs/qemu-qmp-ref.texi:41: warning: undefined flag: VERSION >> /home/pm215/qemu/docs/qemu-qmp-ref.texi:41: warning: undefined flag: VERSION > > This is supposed to be defined in Makefile: > > MAKEINFO=makeinfo -D 'VERSION $(VERSION)' > > Hrrm, Texinfo's NEWS file has for 6.0: > > * texi2any: > [...] > . -D'var val' on the command line works as intended again. > > I tried to find out more about this fix, but the Texinfo repository's > commit log is useless. > > I can reproduce the warning with 6.2 by running makeinfo without -D. > Curiously, output isn't affected. Looks like @subtitle is ignored by > makeinfo. That suggests we should be putting the VERSION information somewhere else so it actually appears in the output :-) Maybe writing the VERSION info to a file as a @set command (and then including that file in the texi) would work ? > Possible work-around I could squash in: > > diff --git a/docs/qemu-qmp-ref.texi b/docs/qemu-qmp-ref.texi > index 818e525..e0f2454 100644 > --- a/docs/qemu-qmp-ref.texi > +++ b/docs/qemu-qmp-ref.texi > @@ -38,7 +38,9 @@ along with this manual. If not, see http://www.gnu.org/licens > es/. > > @titlepage > @title QMP Reference Manual > +@iftex @c Work around bug in Texinfo prior to 6.0 > @subtitle QEMU version @value{VERSION} > +@end iftex > @page > @vskip 0pt plus 1filll > @insertcopying > > Marc-André, what do you think? > >> On OSX (makeinfo (GNU texinfo) 4.8): > > That's from 2004. Just sayin'. I assume it's the last GPLv2 version... >> ./qemu-options.texi:60: warning: unlikely character [ in @var. >> ./qemu-options.texi:60: warning: unlikely character ] in @var. >> ./qemu-options.texi:61: warning: unlikely character [ in @var. >> ./qemu-options.texi:61: warning: unlikely character ] in @var. > > Generated qemu-options.texi did not change (I checked). > > The offending lines are > > @item -numa node[,mem=@var{size}][,cpus=@var{cpu[-cpu]}][,nodeid=@var{node}] > @itemx -numa node[,memdev=@var{id}][,cpus=@var{cpu[-cpu]}][,nodeid=@var{node}] > > which are generated from qemu-options.hx's > > DEF("numa", HAS_ARG, QEMU_OPTION_numa, > "-numa node[,mem=size][,cpus=cpu[-cpu]][,nodeid=node]\n" > "-numa node[,memdev=id][,cpus=cpu[-cpu]][,nodeid=node]\n", QEMU_ARCH_ALL) > > by scripts/hxtool. > > This use of @var{} is perhaps questionable, but nothing changed around > here for many moons. Are you sure this is new in my pull request? Yep, definitely new. With current master: bash-3.2$ touch qemu-options.hx bash-3.2$ make -C build/all GEN qemu-options.def GEN qemu-options.texi GEN qemu-doc.html /Users/pm215/src/qemu-for-merges/qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. but no warnings about unlikely characters. thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On 17 January 2017 at 08:31, Markus Armbruster <armbru@redhat.com> wrote: >> Peter Maydell <peter.maydell@linaro.org> writes: >>> This seems to trigger some warnings from older makeinfo versions: >>> >>> On the Fedora 20 ppc64be box and Ubuntu 14.04.5 LTS aarch64 box >>> (Ubuntu: makeinfo (GNU texinfo) 5.2; >>> Fedora: makeinfo (GNU texinfo) 5.1) >> >> Nobody should be using F20 by now, but the Ubuntu LTS is still legit. > > The F20 box is the GCC compile farm's ppc64be box, so I'm not going > to drop it from the build system list I'm afraid. > >>> /home/pm215/qemu/docs/qemu-ga-ref.texi:41: warning: undefined flag: VERSION >>> /home/pm215/qemu/docs/qemu-ga-ref.texi:41: warning: undefined flag: VERSION >>> /home/pm215/qemu/docs/qemu-qmp-ref.texi:41: warning: undefined flag: VERSION >>> /home/pm215/qemu/docs/qemu-qmp-ref.texi:41: warning: undefined flag: VERSION >> >> This is supposed to be defined in Makefile: >> >> MAKEINFO=makeinfo -D 'VERSION $(VERSION)' >> >> Hrrm, Texinfo's NEWS file has for 6.0: >> >> * texi2any: >> [...] >> . -D'var val' on the command line works as intended again. >> >> I tried to find out more about this fix, but the Texinfo repository's >> commit log is useless. >> >> I can reproduce the warning with 6.2 by running makeinfo without -D. >> Curiously, output isn't affected. Looks like @subtitle is ignored by >> makeinfo. > > That suggests we should be putting the VERSION information > somewhere else so it actually appears in the output :-) > > Maybe writing the VERSION info to a file as a @set command > (and then including that file in the texi) would work ? Right now, that'll make no difference whatsoever, because the programs that choke on -D generate no output for the commands using the variable defined with -D. All they do is gripe. Three possible solutions, in increasing order of complexity: 1. Live with the warning from old versions. If a new version comes around that does something with @subtitle, it'll just work. 2. Suppress the warning with @iftex-hammer. No change in output now. If a new version comes around that does something with @subtitle, we won't profit unless we take out the @iftex. 3. Replace -D by @set, either by preprocessing .texi, or by including a generated snippet. No change in output now. If a new version comes around that does something with @subtitle, it'll just work. My order of preference is aligned with decreasing complexity, i.e. first 1., then 2., then 3. Please tell me what you want. If you want 3., I can certainly live with it, but I'd rather do 1. or 2. now, to get my rather conflict-prone pull request in, then do 3. as a follow-up patch. >> Possible work-around I could squash in: >> >> diff --git a/docs/qemu-qmp-ref.texi b/docs/qemu-qmp-ref.texi >> index 818e525..e0f2454 100644 >> --- a/docs/qemu-qmp-ref.texi >> +++ b/docs/qemu-qmp-ref.texi >> @@ -38,7 +38,9 @@ along with this manual. If not, see http://www.gnu.org/licens >> es/. >> >> @titlepage >> @title QMP Reference Manual >> +@iftex @c Work around bug in Texinfo prior to 6.0 >> @subtitle QEMU version @value{VERSION} >> +@end iftex >> @page >> @vskip 0pt plus 1filll >> @insertcopying >> >> Marc-André, what do you think? >> >>> On OSX (makeinfo (GNU texinfo) 4.8): >> >> That's from 2004. Just sayin'. > > I assume it's the last GPLv2 version... > >>> ./qemu-options.texi:60: warning: unlikely character [ in @var. >>> ./qemu-options.texi:60: warning: unlikely character ] in @var. >>> ./qemu-options.texi:61: warning: unlikely character [ in @var. >>> ./qemu-options.texi:61: warning: unlikely character ] in @var. >> >> Generated qemu-options.texi did not change (I checked). >> >> The offending lines are >> >> @item -numa node[,mem=@var{size}][,cpus=@var{cpu[-cpu]}][,nodeid=@var{node}] >> @itemx -numa node[,memdev=@var{id}][,cpus=@var{cpu[-cpu]}][,nodeid=@var{node}] >> >> which are generated from qemu-options.hx's >> >> DEF("numa", HAS_ARG, QEMU_OPTION_numa, >> "-numa node[,mem=size][,cpus=cpu[-cpu]][,nodeid=node]\n" >> "-numa node[,memdev=id][,cpus=cpu[-cpu]][,nodeid=node]\n", QEMU_ARCH_ALL) >> >> by scripts/hxtool. >> >> This use of @var{} is perhaps questionable, but nothing changed around >> here for many moons. Are you sure this is new in my pull request? > > Yep, definitely new. With current master: > > bash-3.2$ touch qemu-options.hx > bash-3.2$ make -C build/all > GEN qemu-options.def > GEN qemu-options.texi > GEN qemu-doc.html > /Users/pm215/src/qemu-for-merges/qemu-doc.texi:7: warning: > unrecognized encoding name `UTF-8'. > > but no warnings about unlikely characters. The problem of having [] within @var certainly predates this series. I can't see how the series brings it to the surface in the form of warnings. I don't have access to OS-X myself. I tried to reproduce with a locally compiled 4.8 I downloaded from gnu.org, no luck. Perhaps I'm doing it wrong. Please send me a build log, preferably with V=1.
On 17 January 2017 at 12:08, Markus Armbruster <armbru@redhat.com> wrote: > Right now, that'll make no difference whatsoever, because the programs > that choke on -D generate no output for the commands using the variable > defined with -D. All they do is gripe. > > Three possible solutions, in increasing order of complexity: > > 1. Live with the warning from old versions. If a new version comes > around that does something with @subtitle, it'll just work. > > 2. Suppress the warning with @iftex-hammer. No change in output now. > If a new version comes around that does something with @subtitle, we > won't profit unless we take out the @iftex. > > 3. Replace -D by @set, either by preprocessing .texi, or by including a > generated snippet. No change in output now. If a new version comes > around that does something with @subtitle, it'll just work. > > My order of preference is aligned with decreasing complexity, i.e. first > 1., then 2., then 3. > > Please tell me what you want. > > If you want 3., I can certainly live with it, but I'd rather do 1. or > 2. now, to get my rather conflict-prone pull request in, then do 3. as a > follow-up patch. Yeah, I think it's reasonable to apply this now and then fix up the warnings afterwards, since they don't break the build. I'll do that. In terms of what I'd like for the VERSION issue: (1) if it doesn't actually cause a change in the output, we should either just delete the use of VERSION entirely, or move it to somewhere outside of @subtitle which does actually appear somewhere. There's no point in putting in the version info if it doesn't get into the final output, whether it generates a warning or not. (2) If we want to display VERSION then we need to use @set, it looks like. thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On 17 January 2017 at 12:08, Markus Armbruster <armbru@redhat.com> wrote: >> Right now, that'll make no difference whatsoever, because the programs >> that choke on -D generate no output for the commands using the variable >> defined with -D. All they do is gripe. >> >> Three possible solutions, in increasing order of complexity: >> >> 1. Live with the warning from old versions. If a new version comes >> around that does something with @subtitle, it'll just work. >> >> 2. Suppress the warning with @iftex-hammer. No change in output now. >> If a new version comes around that does something with @subtitle, we >> won't profit unless we take out the @iftex. >> >> 3. Replace -D by @set, either by preprocessing .texi, or by including a >> generated snippet. No change in output now. If a new version comes >> around that does something with @subtitle, it'll just work. >> >> My order of preference is aligned with decreasing complexity, i.e. first >> 1., then 2., then 3. >> >> Please tell me what you want. >> >> If you want 3., I can certainly live with it, but I'd rather do 1. or >> 2. now, to get my rather conflict-prone pull request in, then do 3. as a >> follow-up patch. > > Yeah, I think it's reasonable to apply this now and then > fix up the warnings afterwards, since they don't break the > build. I'll do that. Thanks! > In terms of what I'd like for the VERSION issue: > > (1) if it doesn't actually cause a change in the output, we > should either just delete the use of VERSION entirely, or move > it to somewhere outside of @subtitle which does actually > appear somewhere. There's no point in putting in the version > info if it doesn't get into the final output, whether > it generates a warning or not. It does affect PDF output. PDF is generated by texi2pdf, which uses different command line options, and setting VERSION works fine there. > (2) If we want to display VERSION then we need to use @set, > it looks like. We need to decide whether we want to display the information that is now in @subtitle in makeinfo output in addition to PDF output. If yes, we need to put it somewhere else than the subtitle, and find a bug-compatible way to set VERSION. If no, we still might want to silence the warning produced by old versions of makeinfo.
On 17 January 2017 at 13:24, Markus Armbruster <armbru@redhat.com> wrote: > Peter Maydell <peter.maydell@linaro.org> writes: >> (1) if it doesn't actually cause a change in the output, we >> should either just delete the use of VERSION entirely, or move >> it to somewhere outside of @subtitle which does actually >> appear somewhere. There's no point in putting in the version >> info if it doesn't get into the final output, whether >> it generates a warning or not. > > It does affect PDF output. PDF is generated by texi2pdf, which uses > different command line options, and setting VERSION works fine there. Mmm, but if it's useful information we should be displaying it in all our documentation formats, not just tucking it away in something that only appears in the PDF. Conversely, if we're happy for some of our document formats not to contain it we could save ourselves the grief of having to work around this bug by dropping the @subtitle entirely. As an aside, how useful is the PDF output anyway? In 2017 there seems to me quite a good argument for just creating HTML... thanks -- PMM
Hi ----- Original Message ----- > On 17 January 2017 at 13:24, Markus Armbruster <armbru@redhat.com> wrote: > > Peter Maydell <peter.maydell@linaro.org> writes: > >> (1) if it doesn't actually cause a change in the output, we > >> should either just delete the use of VERSION entirely, or move > >> it to somewhere outside of @subtitle which does actually > >> appear somewhere. There's no point in putting in the version > >> info if it doesn't get into the final output, whether > >> it generates a warning or not. > > > > It does affect PDF output. PDF is generated by texi2pdf, which uses > > different command line options, and setting VERSION works fine there. > > Mmm, but if it's useful information we should be displaying > it in all our documentation formats, not just tucking it > away in something that only appears in the PDF. > Conversely, if we're happy for some of our document formats > not to contain it we could save ourselves the grief of > having to work around this bug by dropping the @subtitle entirely. It would be quite easy to add to the rest of the docs, that can be added on top. If its not useful enough in this current form (since it's only in the PDF, because tooling is lacking support), feel freel to remove it Markus. > As an aside, how useful is the PDF output anyway? In 2017 > there seems to me quite a good argument for just creating > HTML... > Afaik, most browsers support pdf nowadays. pdf output is more pleasant to read, the html version would need significant styling to be comparable (I have played with the CSS, that would already help). I hope we get there once we have better doc tooling (sphinx, readthedocs etc)
Peter Maydell <peter.maydell@linaro.org> writes: > On 17 January 2017 at 13:24, Markus Armbruster <armbru@redhat.com> wrote: >> Peter Maydell <peter.maydell@linaro.org> writes: >>> (1) if it doesn't actually cause a change in the output, we >>> should either just delete the use of VERSION entirely, or move >>> it to somewhere outside of @subtitle which does actually >>> appear somewhere. There's no point in putting in the version >>> info if it doesn't get into the final output, whether >>> it generates a warning or not. >> >> It does affect PDF output. PDF is generated by texi2pdf, which uses >> different command line options, and setting VERSION works fine there. > > Mmm, but if it's useful information we should be displaying > it in all our documentation formats, not just tucking it > away in something that only appears in the PDF. > Conversely, if we're happy for some of our document formats > not to contain it we could save ourselves the grief of > having to work around this bug by dropping the @subtitle entirely. Yes, that's why I wrote we need to decide whether we want the information that is now in @subtitle in the formats where @subtitle currently doesn't appear. > As an aside, how useful is the PDF output anyway? In 2017 > there seems to me quite a good argument for just creating > HTML... We do generate HTML. We also generate PDF. It's better for printing (if you're so inclined), and it costs us next to nothing: a couple of lines in the top-level Makefile. See commit 20cc999 "Documentation: Add build support for documentation in pdf format" (January 2010) and also commit ad23988 "build-sys: remove dvi doc generation" (in this series).
On 17 January 2017 at 14:23, Markus Armbruster <armbru@redhat.com> wrote: > Peter Maydell <peter.maydell@linaro.org> writes: >> As an aside, how useful is the PDF output anyway? In 2017 >> there seems to me quite a good argument for just creating >> HTML... > > We do generate HTML. We also generate PDF. It's better for printing > (if you're so inclined), and it costs us next to nothing: a couple of > lines in the top-level Makefile. Mmm, but in thinking about other possible document formats it would be interesting to know whether not producing PDF would be a dealbreaker or just dropping a feature that three people use... In any case, applied this pullreq to master. Interestingly there were no signs of the "unlikely character" warnings this time around. thanks -- PMM
On 01/17/2017 06:08 AM, Markus Armbruster wrote: > > Three possible solutions, in increasing order of complexity: > > 1. Live with the warning from old versions. If a new version comes > around that does something with @subtitle, it'll just work. > > 2. Suppress the warning with @iftex-hammer. No change in output now. > If a new version comes around that does something with @subtitle, we > won't profit unless we take out the @iftex. > > 3. Replace -D by @set, either by preprocessing .texi, or by including a > generated snippet. No change in output now. If a new version comes > around that does something with @subtitle, it'll just work. Automake projects use option 3 - they create version.texi with @set commands, then @include that into the main file. Should be fairly easy to crib the makefile magic from an autotooled project if you want to go that option. > > My order of preference is aligned with decreasing complexity, i.e. first > 1., then 2., then 3. I'm fine with any of the options (3 is nicest, but also the most work). I do agree, however, that if we are going to include version information (which I find useful), then we want it in both pdf and html outputs.
On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote:
> In any case, applied this pullreq to master.
Although it works fine on my OSX box (with warnings) it seems
to have broken the Travis OSX builds:
https://travis-ci.org/qemu/qemu/jobs/192750574
GEN qemu-options.texi
GEN qemu-monitor.texi
GEN qemu-img-cmds.texi
GEN qemu-monitor-info.texi
GEN qemu-doc.txt
qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'.
GEN qemu-img.1
/Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely
character [ in @var.
/Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely
character ] in @var.
/Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely
character [ in @var.
/Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely
character ] in @var.
/Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'.
/Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to
nonexistent node `bt-hcis' (perhaps incorrect sectioning?).
makeinfo: Removing output file `qemu-doc.txt' due to errors; use
--force to preserve.
make: *** [qemu-doc.txt] Error 1
thanks
-- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >> In any case, applied this pullreq to master. > > Although it works fine on my OSX box (with warnings) it seems > to have broken the Travis OSX builds: > https://travis-ci.org/qemu/qemu/jobs/192750574 > > GEN qemu-options.texi > GEN qemu-monitor.texi > GEN qemu-img-cmds.texi > GEN qemu-monitor-info.texi > GEN qemu-doc.txt > qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. > GEN qemu-img.1 > /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely > character [ in @var. > /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely > character ] in @var. > /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely > character [ in @var. > /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely > character ] in @var. > /Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'. > /Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to > nonexistent node `bt-hcis' (perhaps incorrect sectioning?). > makeinfo: Removing output file `qemu-doc.txt' due to errors; use > --force to preserve. > make: *** [qemu-doc.txt] Error 1 @table and @end table are nested correctly in my generated qemu-options.texi, and @anchor{bt-hcis} is present. Can you grab the offending qemu-options.texi for me?
On 20 January 2017 at 15:46, Markus Armbruster <armbru@redhat.com> wrote: > Peter Maydell <peter.maydell@linaro.org> writes: > >> On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >>> In any case, applied this pullreq to master. >> >> Although it works fine on my OSX box (with warnings) it seems >> to have broken the Travis OSX builds: >> https://travis-ci.org/qemu/qemu/jobs/192750574 >> >> GEN qemu-options.texi >> GEN qemu-monitor.texi >> GEN qemu-img-cmds.texi >> GEN qemu-monitor-info.texi >> GEN qemu-doc.txt >> qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. >> GEN qemu-img.1 >> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >> character [ in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >> character ] in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >> character [ in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >> character ] in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'. >> /Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to >> nonexistent node `bt-hcis' (perhaps incorrect sectioning?). >> makeinfo: Removing output file `qemu-doc.txt' due to errors; use >> --force to preserve. >> make: *** [qemu-doc.txt] Error 1 > > @table and @end table are nested correctly in my generated > qemu-options.texi, and @anchor{bt-hcis} is present. Can you grab the > offending qemu-options.texi for me? Alex may know how to get objects out of a failed Travis build (if it's possible at all). thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On 20 January 2017 at 15:46, Markus Armbruster <armbru@redhat.com> wrote: >> Peter Maydell <peter.maydell@linaro.org> writes: >> >>> On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >>>> In any case, applied this pullreq to master. >>> >>> Although it works fine on my OSX box (with warnings) it seems >>> to have broken the Travis OSX builds: >>> https://travis-ci.org/qemu/qemu/jobs/192750574 >>> >>> GEN qemu-options.texi >>> GEN qemu-monitor.texi >>> GEN qemu-img-cmds.texi >>> GEN qemu-monitor-info.texi >>> GEN qemu-doc.txt >>> qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. >>> GEN qemu-img.1 >>> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >>> character [ in @var. >>> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >>> character ] in @var. >>> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >>> character [ in @var. >>> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >>> character ] in @var. >>> /Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'. >>> /Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to >>> nonexistent node `bt-hcis' (perhaps incorrect sectioning?). >>> makeinfo: Removing output file `qemu-doc.txt' due to errors; use >>> --force to preserve. >>> make: *** [qemu-doc.txt] Error 1 >> >> @table and @end table are nested correctly in my generated >> qemu-options.texi, and @anchor{bt-hcis} is present. Can you grab the >> offending qemu-options.texi for me? > > Alex may know how to get objects out of a failed Travis build > (if it's possible at all). For the normal targets we can re-create builds at our leisure using the travis docker image. Unfortunately I'm not clear on how this works for the MacOSX build. The best solution I can come up with is to tweak your build to dump the .text into stdout and then look on the Travis web-page as the build fails. I had a similar fall-back encoded when debugging the clang build, something like: before_script: - ./configure ${CONFIG} --extra-cflags="-g3 -O0 -fsanitize=thread -fuse-ld=gold" || cat config.log So change your local .travis.yml to: - env: CONFIG="" os: osx compiler: clang script: make -j3 || cat qemu-options.texi and trigger a build with it. -- Alex Bennée
On Fri, Jan 20, 2017 at 04:46:05PM +0100, Markus Armbruster wrote: > Peter Maydell <peter.maydell@linaro.org> writes: > > > On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: > >> In any case, applied this pullreq to master. > > > > Although it works fine on my OSX box (with warnings) it seems > > to have broken the Travis OSX builds: > > https://travis-ci.org/qemu/qemu/jobs/192750574 > > > > GEN qemu-options.texi > > GEN qemu-monitor.texi > > GEN qemu-img-cmds.texi > > GEN qemu-monitor-info.texi > > GEN qemu-doc.txt > > qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. > > GEN qemu-img.1 > > /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely > > character [ in @var. > > /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely > > character ] in @var. > > /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely > > character [ in @var. > > /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely > > character ] in @var. > > /Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'. > > /Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to > > nonexistent node `bt-hcis' (perhaps incorrect sectioning?). > > makeinfo: Removing output file `qemu-doc.txt' due to errors; use > > --force to preserve. > > make: *** [qemu-doc.txt] Error 1 > > @table and @end table are nested correctly in my generated > qemu-options.texi, and @anchor{bt-hcis} is present. Can you grab the > offending qemu-options.texi for me? I hacked the travis.yml to add "|| cat qemu-options.texi" after the build fails. The output is here: https://travis-ci.org/berrange/qemu/jobs/194471961 Regards, Daniel
"Daniel P. Berrange" <berrange@redhat.com> writes: > On Fri, Jan 20, 2017 at 04:46:05PM +0100, Markus Armbruster wrote: >> Peter Maydell <peter.maydell@linaro.org> writes: >> >> > On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >> >> In any case, applied this pullreq to master. >> > >> > Although it works fine on my OSX box (with warnings) it seems >> > to have broken the Travis OSX builds: >> > https://travis-ci.org/qemu/qemu/jobs/192750574 >> > >> > GEN qemu-options.texi >> > GEN qemu-monitor.texi >> > GEN qemu-img-cmds.texi >> > GEN qemu-monitor-info.texi >> > GEN qemu-doc.txt >> > qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. >> > GEN qemu-img.1 >> > /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >> > character [ in @var. >> > /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >> > character ] in @var. >> > /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >> > character [ in @var. >> > /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >> > character ] in @var. >> > /Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'. >> > /Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to >> > nonexistent node `bt-hcis' (perhaps incorrect sectioning?). >> > makeinfo: Removing output file `qemu-doc.txt' due to errors; use >> > --force to preserve. >> > make: *** [qemu-doc.txt] Error 1 >> >> @table and @end table are nested correctly in my generated >> qemu-options.texi, and @anchor{bt-hcis} is present. Can you grab the >> offending qemu-options.texi for me? > > I hacked the travis.yml to add "|| cat qemu-options.texi" after the > build fails. The output is here: > > https://travis-ci.org/berrange/qemu/jobs/194471961 I fetched your branch (it's much more than just current master + the hack), and my local build generates the exact same qemu-options.texi, modulo line endings (I think; diff -w comes up empty).
Peter Maydell <peter.maydell@linaro.org> writes: > On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >> In any case, applied this pullreq to master. > > Although it works fine on my OSX box (with warnings) it seems > to have broken the Travis OSX builds: > https://travis-ci.org/qemu/qemu/jobs/192750574 > > GEN qemu-options.texi > GEN qemu-monitor.texi > GEN qemu-img-cmds.texi > GEN qemu-monitor-info.texi > GEN qemu-doc.txt > qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. > GEN qemu-img.1 > /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely > character [ in @var. > /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely > character ] in @var. > /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely > character [ in @var. > /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely > character ] in @var. > /Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'. > /Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to > nonexistent node `bt-hcis' (perhaps incorrect sectioning?). > makeinfo: Removing output file `qemu-doc.txt' due to errors; use > --force to preserve. > make: *** [qemu-doc.txt] Error 1 Are you *sure* this series causes the failure? I generated qemu-options.texi for every merge commit since v2.8.0, and the only one that changes it is commit 598cf1c "Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging". I then examined the commits in that merge, and the ones that affect qemu-options.texi are: * commit 43f187a hxtool: emit Texinfo headings as @subsection * commit b0cb0a6 Plumb the HAXM-based hardware acceleration support Could you kick off Travis builds to confirm or deny these commits cause the OS X trouble?
On 24 January 2017 at 09:53, Markus Armbruster <armbru@redhat.com> wrote: > Peter Maydell <peter.maydell@linaro.org> writes: > >> On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >>> In any case, applied this pullreq to master. >> >> Although it works fine on my OSX box (with warnings) it seems >> to have broken the Travis OSX builds: >> https://travis-ci.org/qemu/qemu/jobs/192750574 >> >> GEN qemu-options.texi >> GEN qemu-monitor.texi >> GEN qemu-img-cmds.texi >> GEN qemu-monitor-info.texi >> GEN qemu-doc.txt >> qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. >> GEN qemu-img.1 >> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >> character [ in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >> character ] in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >> character [ in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >> character ] in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'. >> /Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to >> nonexistent node `bt-hcis' (perhaps incorrect sectioning?). >> makeinfo: Removing output file `qemu-doc.txt' due to errors; use >> --force to preserve. >> make: *** [qemu-doc.txt] Error 1 > > Are you *sure* this series causes the failure? It's pretty solidly looking like it in travis: everything passes up until this merge is applied, and then everything fails... > I generated qemu-options.texi for every merge commit since v2.8.0, and > the only one that changes it is commit 598cf1c "Merge remote-tracking > branch 'remotes/bonzini/tags/for-upstream' into staging". Travis was already failing with this error before 598cf1c. First build with this error was on commit 23eb9e6; the build on the merge before that was fine. https://travis-ci.org/qemu/qemu/jobs/192750574 is the build log for the first failure. https://travis-ci.org/qemu/qemu/jobs/192689212 is the build log for the previous success. I do note one difference: the successful build does not appear to try to build qemu-doc.txt. Perhaps your merge enabled an attempt to build some flavour of the docs that has always been broken ? thanks -- PMM
Markus Armbruster <armbru@redhat.com> writes: > Peter Maydell <peter.maydell@linaro.org> writes: > >> On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >>> In any case, applied this pullreq to master. >> >> Although it works fine on my OSX box (with warnings) it seems >> to have broken the Travis OSX builds: >> https://travis-ci.org/qemu/qemu/jobs/192750574 >> >> GEN qemu-options.texi >> GEN qemu-monitor.texi >> GEN qemu-img-cmds.texi >> GEN qemu-monitor-info.texi >> GEN qemu-doc.txt >> qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. >> GEN qemu-img.1 >> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >> character [ in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >> character ] in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >> character [ in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >> character ] in @var. >> /Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'. >> /Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to >> nonexistent node `bt-hcis' (perhaps incorrect sectioning?). >> makeinfo: Removing output file `qemu-doc.txt' due to errors; use >> --force to preserve. >> make: *** [qemu-doc.txt] Error 1 > > Are you *sure* this series causes the failure? > > I generated qemu-options.texi for every merge commit since v2.8.0, and > the only one that changes it is commit 598cf1c "Merge remote-tracking > branch 'remotes/bonzini/tags/for-upstream' into staging". I then > examined the commits in that merge, and the ones that affect > qemu-options.texi are: > > * commit 43f187a hxtool: emit Texinfo headings as @subsection > * commit b0cb0a6 Plumb the HAXM-based hardware acceleration support > > Could you kick off Travis builds to confirm or deny these commits cause > the OS X trouble? Different tack: perhaps it's the way we run makeinfo. Commits touching that: * commit 56e8bdd build-sys: add qapi doc generation targets * commit f8bab10 build-sys: add txt documentation rules * commit e9ee06b build-sys: use --no-split for info Travis builds, please? Of course, if you got a Mac outside Travis that also fails, trying there would be quicker.
On 24/01/2017 11:09, Markus Armbruster wrote:
> * commit f8bab10 build-sys: add txt documentation rules
This could be the culprit...
Paolo
Peter Maydell <peter.maydell@linaro.org> writes: > On 24 January 2017 at 09:53, Markus Armbruster <armbru@redhat.com> wrote: >> Peter Maydell <peter.maydell@linaro.org> writes: >> >>> On 17 January 2017 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >>>> In any case, applied this pullreq to master. >>> >>> Although it works fine on my OSX box (with warnings) it seems >>> to have broken the Travis OSX builds: >>> https://travis-ci.org/qemu/qemu/jobs/192750574 >>> >>> GEN qemu-options.texi >>> GEN qemu-monitor.texi >>> GEN qemu-img-cmds.texi >>> GEN qemu-monitor-info.texi >>> GEN qemu-doc.txt >>> qemu-doc.texi:7: warning: unrecognized encoding name `UTF-8'. >>> GEN qemu-img.1 >>> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >>> character [ in @var. >>> /Users/travis/build/qemu/qemu//qemu-options.texi:60: warning: unlikely >>> character ] in @var. >>> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >>> character [ in @var. >>> /Users/travis/build/qemu/qemu//qemu-options.texi:61: warning: unlikely >>> character ] in @var. >>> /Users/travis/build/qemu/qemu//qemu-options.texi:630: No matching `@end table'. >>> /Users/travis/build/qemu/qemu//qemu-doc.texi:1419: Cross reference to >>> nonexistent node `bt-hcis' (perhaps incorrect sectioning?). >>> makeinfo: Removing output file `qemu-doc.txt' due to errors; use >>> --force to preserve. >>> make: *** [qemu-doc.txt] Error 1 >> >> Are you *sure* this series causes the failure? > > It's pretty solidly looking like it in travis: everything > passes up until this merge is applied, and then everything > fails... > >> I generated qemu-options.texi for every merge commit since v2.8.0, and >> the only one that changes it is commit 598cf1c "Merge remote-tracking >> branch 'remotes/bonzini/tags/for-upstream' into staging". > > Travis was already failing with this error before 598cf1c. > First build with this error was on commit 23eb9e6; the build on > the merge before that was fine. > https://travis-ci.org/qemu/qemu/jobs/192750574 > is the build log for the first failure. > https://travis-ci.org/qemu/qemu/jobs/192689212 > is the build log for the previous success. Yeah, that's conclusive. > I do note one difference: the successful build does not appear > to try to build qemu-doc.txt. Perhaps your merge enabled > an attempt to build some flavour of the docs that has > always been broken ? Since .texi doesn't change, the way we process it is the most likely suspect. In my other message, I list three commits that affect processing. I need help with testing them on OS X.
diff --git a/docs/qemu-qmp-ref.texi b/docs/qemu-qmp-ref.texi index 818e525..e0f2454 100644 --- a/docs/qemu-qmp-ref.texi +++ b/docs/qemu-qmp-ref.texi @@ -38,7 +38,9 @@ along with this manual. If not, see http://www.gnu.org/licens es/. @titlepage @title QMP Reference Manual +@iftex @c Work around bug in Texinfo prior to 6.0 @subtitle QEMU version @value{VERSION} +@end iftex @page @vskip 0pt plus 1filll