Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]

2016-09-19 Thread Gavin Smith
On 19 September 2016 at 13:29, Gavin Smith  wrote:
> \indexlbrace ->{\ifmonospace \else \ecfont
>\fi \char 123}

I don't know where this definition is coming from: it should be the
following definition:

\def\lbracechar{{\ifmonospace\char123\else\ensuremath\lbrace\fi}}

which, as you can see, doesn't use \ecfont.

Are you sure that you are using the texinfo.tex from Texinfo 6.3?



Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]

2016-09-19 Thread Gavin Smith
On 19 September 2016 at 13:03, David Kaspar [Dee'Kej]
 wrote:
> Hello guys,
>
> I have located the problem with help from my colleague (Vitezslav Crhonek,
> maintainer of texinfo). For some reason, the newer version of texinfo (6.1+)
> is unable to fallback to different fonts when some other fonts are
> unavailable.
>
> Recap:
>  * I was able to compile documentation for gawk-4.1.3 & gawk-4.1.4 with
> texinfo-6.0
>  * I was able to compile documentation for gawk-4.1.3 with texinfo-6.1
>  * I was NOT able to compile documentation for gawk-4.1.4 with texinfo 6.1
>
> Solution:
>  * I had to add installation of missing fonts into build root (texlive-ec,
> texlive-cm-super in Fedora)
>
> My guess is that you have switched to new fonts for Index of documentation,
> or older texinfo was able to get over missing fonts before so nobody has
> noticed that problem.

If anyone could give more specific information on this, that would be
great. What fonts are missing, and when are they required?

I remember there was a problem before with some characters as the
heading in an index, possibly brace characters: maybe this is related?
I remember that we tried to use standard fonts for these glyphs, but
maybe there is an omission somewhere?



Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]

2016-09-13 Thread arnold
"David Kaspar [Dee'Kej]"  wrote:

> I guess I didn't make myself clear. By default the vanilla source code is
> used during build inside mock, no modifications to it are currently there.
> So, when I try the build for 4.1.4, it uses the texinfo.tex shipped with
> gawk. There shouldn't be any way for mock to download some older
> texinfo.tex from somewhere else. The reason why it is older in the gawk.log
> is that I was trying to find out which commit started to cause this. I have
> found it, and I have put that log to pastebin. That's why it has older
> timestamp than current source tarball. :)

I see now.

> I'm actually starting to think that something has changed inside Texinfo
> 
>
> I will look into this more tomorrow, and I will discuss this with our
> maintainer of Texinfo.

Great. Sounds like the right way to go.

> > I don't have the cycles to try to mess with SRPMs and so on, especially
> > as I don't run an RPM-based distribution.
> >
> No problem, I understand. :) I will try to find some fix/workaround, I
> will keep you updated if needed.

Thanks for understanding. I appreciate the effort and am glad that
4.1.4 will get into Fedora soon.

Thanks,

Arnold



Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]

2016-09-13 Thread David Kaspar [Dee'Kej]
On Tue, Sep 13, 2016 at 4:22 PM,  wrote:

> Hi David.
>
> You need to figure out how to get mock to use the texinfo.tex shipped
> with gawk. Mock is stil using an older version. I support building the doc
> with what I ship.  But not otherwise.


​I guess I didn't make myself clear. By default the vanilla source code is
used during build inside mock, no modifications to it are currently there.​
So, when I try the build for 4.1.4, it uses the texinfo.tex shipped with
gawk. There shouldn't be any way for mock to download some older
texinfo.tex from somewhere else. The reason why it is older in the gawk.log
is that I was trying to find out which commit started to cause this. I have
found it, and I have put that log to pastebin. That's why it has older
timestamp than current source tarball. :)


> It may be that you need to move to Texinfo 6.1 (or even the just released
> Texinfo 6.3) for the latest Fedora. I don't know.  Using the texinfo.tex
> in the tarball is the way to go. You may need to move to the newer
> Texinfo anyway since that package has an updated and smarter texindex
> program which gawk's doc probably needs.
>
​Actually, we're using the Texinfo 6.1 for Fedora 24: (mock used this)
texinfox86_64
6.1-3.fc25  fedora   1.1 M
texinfo-texx86_64
6.1-3.fc25  fedora   153 k

We're using older version (Texinfo 6.0) inside F23, which is able to
compile the gawk-4.1.4 documentation.

I'm actually starting to think that something has changed inside Texinfo
between version 6.0 and 6.1, because there was this BZ for Texinfo:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1309702

texi2dvi was exiting with wrong exit code, and doing only one
iteration/pass. This looks almost like something I'm getting inside mock.
The problem was reported to Texinfo upstream:
http://lists.gnu.org/archive/html/bug-texinfo/2016-02/msg00121.html

I will look into this more tomorrow, and I will discuss this with our
maintainer of Texinfo.


> I don't have the cycles to try to mess with SRPMs and so on, especially
> as I don't run an RPM-based distribution.
>
​No problem, I understand. :) I will try to find some fix/workaround, I
will keep you updated if needed.​

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .​


Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]

2016-09-13 Thread arnold
Hi David.

You need to figure out how to get mock to use the texinfo.tex shipped
with gawk. Mock is stil using an older version. I support building the doc
with what I ship.  But not otherwise.

It may be that you need to move to Texinfo 6.1 (or even the just released
Texinfo 6.3) for the latest Fedora. I don't know.  Using the texinfo.tex
in the tarball is the way to go. You may need to move to the newer
Texinfo anyway since that package has an updated and smarter texindex
program which gawk's doc probably needs.

Inisde mock, you can try setting the TEXINPUTS environment variable to
have the gawk doc directory in it first:

TEXINPUTS=$PWD/doc:$TEXINPUTS make -C doc/ pdf

or some such.

I don't have the cycles to try to mess with SRPMs and so on, especially
as I don't run an RPM-based distribution.

HTH,

Arnold


"David Kaspar [Dee'Kej]"  wrote:

> Hello guys,
>
> I was in a hurry yesterday, so I have accidentally sent the wrong log
> file... :-/ Today, I looked into this more:
>
> * I am able to create documentation if I normally use 'make -C doc/ pdf' or
> 'cd doc && make pdf && cd ..' for gawk-4.1.4 in my Fedora 24.
> * The problem occurs when I try to build it inside mock [1] for Fedora 24
> (and higher), I'm trying to do rebase for F26.
> * If I try to build it for F23 in mock, it passes. IOW, using newer
> versions of 'texi2dvi' inside mock (for F24+) results in compilation fail.
> * When it fails, it produces only partial documentation, with Index and
> everything behind it missing.
> * When I use the 'texi2pdf' instead of 'make pdf' in the specfile, I'm able
> to see at which line this occurs.
> * I've used git-bisect to find a commit where the build starts to fail,
> it's this commit:
>
> [upstream||gawk] ~ [3e762b6 $] # git last
> * commit 3e762b6f62061974d152dd251f3e83cacca073e3 (HEAD, refs/bisect/bad)
> | Author: Arnold D. Robbins 
> | Date:   12 months ago
> |
> | Update infrastructure files.
>
> * This helped me narrow it to file causing the issue: doc/texinfo.tex
> (using older version of texinfo.tex with the first failing commit allows
> build to pass).
> * Reading through changes in the texinfo.tex, there was some bigger update
> to how Index is being produced, if I'm not mistaken.
> * Running the build with refs/bisect/bad commit and with 'texi2pdf' shows
> me, that the compilation of PDF stops at line number 38144 of gawk.texi
> (which has @cindex right above it).
>
> So, I have updated the pastebin log, so you can check it out yourself here:
> http://pastebin.com/skxGpHnL
>
> Unfortunately, I'm not so good with TeX to be able to pinpoint the problem
> more closely, but if you need anything more from me, I can help. :) I can
> also provide you with the srpm if you would like to build it / try it
> yourself.
>
> -
> [1] https://github.com/rpm-software-management/mock/wiki
> -
>
> Best regards,
>
> David Kaspar [Dee'Kej]
> *Associate Software Engineer*
> *Brno, Czech Republic*
>
> RED HAT | TRIED. TESTED. TRUSTED.
> Every airline in the Fortune 500 relies on Red Hat.
> Find out why at Trusted | Red Hat .



Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]

2016-09-13 Thread David Kaspar [Dee'Kej]
Hello guys,

I was in a hurry yesterday, so I have accidentally sent the wrong log
file... :-/ Today, I looked into this more:

* I am able to create documentation if I normally use 'make -C doc/ pdf' or
'cd doc && make pdf && cd ..' for gawk-4.1.4 in my Fedora 24.
* The problem occurs when I try to build it inside mock [1] for Fedora 24
(and higher), I'm trying to do rebase for F26.
* If I try to build it for F23 in mock, it passes. IOW, using newer
versions of 'texi2dvi' inside mock (for F24+) results in compilation fail.
* When it fails, it produces only partial documentation, with Index and
everything behind it missing.
* When I use the 'texi2pdf' instead of 'make pdf' in the specfile, I'm able
to see at which line this occurs.
* I've used git-bisect to find a commit where the build starts to fail,
it's this commit:

[upstream||gawk] ~ [3e762b6 $] # git last
* commit 3e762b6f62061974d152dd251f3e83cacca073e3 (HEAD, refs/bisect/bad)
| Author: Arnold D. Robbins 
| Date:   12 months ago
|
| Update infrastructure files.

* This helped me narrow it to file causing the issue: doc/texinfo.tex
(using older version of texinfo.tex with the first failing commit allows
build to pass).
* Reading through changes in the texinfo.tex, there was some bigger update
to how Index is being produced, if I'm not mistaken.
* Running the build with refs/bisect/bad commit and with 'texi2pdf' shows
me, that the compilation of PDF stops at line number 38144 of gawk.texi
(which has @cindex right above it).

So, I have updated the pastebin log, so you can check it out yourself here:
http://pastebin.com/skxGpHnL

Unfortunately, I'm not so good with TeX to be able to pinpoint the problem
more closely, but if you need anything more from me, I can help. :) I can
also provide you with the srpm if you would like to build it / try it
yourself.

-
[1] https://github.com/rpm-software-management/mock/wiki
-

Best regards,

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .


Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]

2016-09-13 Thread arnold
Gavin Smith  wrote:

> On 12 September 2016 at 18:52,   wrote:
> > Hi.
> >
> >> there seems to be a regression for the documentation of gawk. I'm not able
> >> to compile the PDF version of it with current version 4.1.4. I was able to
> >> compile it in the same way for 4.1.3.
> >>
> >> There's a lot of output during compilation, and unfortunately I do not have
> >> time to look at it now... :-/ Here's the link to the gawk.log:
> >>
> >> http://pastebin.com/skxGpHnL
> >
> There looks nothing wrong with that output: it finishes processing the file:
>
> [477] [478] [479] [480] [481] [482] [483] [484] [485] [486]
> (GNU Free Documentation License) [487] [488] [489] [490] [491] [492] [493]
> [494] [495] (Index) [496] [497] [498] )
> Here is how much of TeX's memory you used:
>
> ...
>
> Output written on gawk.pdf (508 pages, 1740511 bytes).

Looking at the raw paste data:

(./gawk.texi (/home/dkaspar/Downloads/gawk-4.1.4/doc/texinfo.tex
Loading texinfo [version 2013-02-01.11]:

But looking at what I put into the tarball:

$ grep version texinfo.tex
\def\texinfoversion{2016-02-05.07}

This is the cause. David - this is in your court.

Thanks,

Arnold



Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]

2016-09-13 Thread Gavin Smith
On 12 September 2016 at 18:52,   wrote:
> Hi.
>
>> there seems to be a regression for the documentation of gawk. I'm not able
>> to compile the PDF version of it with current version 4.1.4. I was able to
>> compile it in the same way for 4.1.3.
>>
>> There's a lot of output during compilation, and unfortunately I do not have
>> time to look at it now... :-/ Here's the link to the gawk.log:
>>
>> http://pastebin.com/skxGpHnL
>
There looks nothing wrong with that output: it finishes processing the file:

[477] [478] [479] [480] [481] [482] [483] [484] [485] [486]
(GNU Free Documentation License) [487] [488] [489] [490] [491] [492] [493]
[494] [495] (Index) [496] [497] [498] )
Here is how much of TeX's memory you used:

...

Output written on gawk.pdf (508 pages, 1740511 bytes).



Re: [bug-gawk] 'make -C doc/ pdf' [Makefile:457: recipe for target gawk.pdf failed]

2016-09-12 Thread arnold
Hi.

> there seems to be a regression for the documentation of gawk. I'm not able
> to compile the PDF version of it with current version 4.1.4. I was able to
> compile it in the same way for 4.1.3.
>
> There's a lot of output during compilation, and unfortunately I do not have
> time to look at it now... :-/ Here's the link to the gawk.log:
>
> http://pastebin.com/skxGpHnL

I always use

cd doc ; make pdf

and that works flawlessly for me. I have never used `make -C doc/ pdf'
and I don't know why that fails. In fact, it works just fine for me too
(Ubuntu 16.04).

Looking at your log, it looks like you're not getting the texinfo.tex
file distributed with gawk but a rather older one.

I'm adding the texinfo list, maybe they can shed some light.

> Question: If you fix this issue, will it be in git only, or will you
> prepare new tarball?

Can you just change your procedure to use 'cd doc; make pdf' ?

Or can you help determine why it's not working? Especially since it
does work for me...

Any fix would likely just be in git since this is the first time
such an issue has ever been raised.

Thanks,

Arnold