Bug 913274

gcc experienced similar breakage, but looks like they're actively fixing/working-around the problem,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258

I (as the upstream GNU Texinfo texi2any/makeinfo developper) had a look, and as far as I can tell all the warnings and errors are indeed because of dubious or wrong Texinfo.  In the @macro case, the error comes from the fact that & is used in a @macro name which is incorrect.  I had a look at the sbcl manual, I can't see why those user @macro are defined.

The @macro error could use a better error message, though, I'll try to fix that.

fyi, maxima ftbfs now too:
http://koji.fedoraproject.org/koji/buildinfo?buildID=397154

(In reply to comment #3)
> fyi, maxima ftbfs now too:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=397154

I had a look, all the errors and warnings seems to point to real issues that should be corrected in the manual.

For the errors like

./to_poly_solve.texi:341: warning: @itemize has text but no @item

there could be indeed a missing @item, but the authors may also want to indent the text, for that there is a new @-command, @indentedblock.  But since it quite recent, bearing with the warning could also be the way to go.

Spot tested a few other texinfo/makeinfo using packages, hit anaother failure
wget:  http://koji.fedoraproject.org/koji/taskinfo?taskID=5039621
(another @item-related problem).

also a few successes (mostly to show to myself not *all* packages fail): 
grep
gzip
mtools
tar

(In reply to comment #5)
> Spot tested a few other texinfo/makeinfo using packages, hit anaother failure
> wget:  http://koji.fedoraproject.org/koji/taskinfo?taskID=5039621
> (another @item-related problem).

Indeed, all the @itemx flagged by makeinfo as incorrect are indeed incorrect.

> also a few successes (mostly to show to myself not *all* packages fail): 
> grep
> gzip
> mtools
> tar

All could have failed, as much more errors are caught now...

Another casualty, enblend,
https://koji.fedoraproject.org/koji/taskinfo?taskID=5104184

If serious headway cannot be made to resolve these problems soon, I humbly suggest pushing reverting back to texinfo-4.x for f19 and pushing texinfo-5.x back to f20.

(In reply to comment #2)

> The @macro error could use a better error message, though, I'll try to fix
> that.

In 5.1 the error message should be better.

(In reply to comment #7)
> Another casualty, enblend,
> https://koji.fedoraproject.org/koji/taskinfo?taskID=5104184

This one is much more tricky.  First it unveiledd an important bug in 5.1.  The remaining issues are also more complicated to solve.  I did send a mail to some enblend list (or group, I don't really found a traditional mailing list) with a possible solution and example code.

(In reply to comment #8)
> If serious headway cannot be made to resolve these problems soon, I humbly
> suggest pushing reverting back to texinfo-4.x for f19 and pushing
> texinfo-5.x back to f20.

enblend set aside, I think that package managers could report to upstream the issues and maybe prepare patches, although upstream could certainly figure out the simplest cases that are clearly incorrect.  I can step in, but I don't think that it's the best course.

That being said, keeping the new Texinfo a bit longer in rawhide only is certainly the way to go, at least that's what I would have advocated in my Fedora days.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Marking WONTFIX, I guess the way forward now is just to trudge through fixing probject's texinfo files to be compatible.