Bug#276000: Bug reports for texinfo (and 2 wishes)
So it is okay to include always the latest texinfo.tex together with info and makeinfo etc from 4.8? Yes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#37515: Bug reports for texinfo (and 2 wishes)
Mp... brings you *ALSO*! to the top of the appendix page, although it is actually on the next page (this could be related to the error 276000 see below???) Happily, it seems your surmise was correct: this bug is not happening for me now, so I suppose that it was the same as 276000. It makes sense, as the underlying problem was a page break separating a whatsit (whether for the toc or a pdf location or whatever) from its chapter/section heading following, due to the interline glue. Let me know if you still find an example that fails ... thanks, k -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#146133: info goto node with dot
It seems that the generation of the info files, especially with the jump indications at the end of the first file, are improperly created. WOuldn't this explain the problem? Yes, it might explain it, except that those jump indications are correct, as far as I can tell. That's why I said it is necessary to have more files. My guess is a parsing problem in standalone info. Otherwise I'd expect all the nodes to be unfindable, not just the one with the period in the name. see at the end of the first file there is a binary blob giving information on where one has to jump to in the other files. True??? Yes. The binary blob is nothing very magical - it's character counts to find the nodes, kind of like all the subfiles are concatenated together, ignoring the preamble junk. The first table tells the count at which each subfile starts. Something related: The most puzzling, even for me, error/bug/strangeness is that info jumps to the man page of top when you enter info ./notexistingfile instead of going to the top node or giving an error message ;-) Unrelated. Isn't it wonderful behavior? Explanation: - info tries to find the top node to search for notexistingfile; - then that search fails; - there is no info page for top; - so it falls back to searching for the man page for top. Yes, this is a silly bug. I've never mustered enough interest to fix it. Shame on me. Thanks, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#146133: info goto node with dot
Can you tell me in which function the scanning is performed, I can take a look into the code. Ugh, when I've looked at this stuff before, it seems to be spread all over. Most of the relevant code is in nodes.c, I think, e.g., info_get_node. (And maybe once I learn how to debug an interactive program like this, that tries to open a screen ;-) It's a pain. $ info --dribble=save.drib perform minimal actions to reproduce bug q Then you can use info --restore=save.drib in gud-mode under Emacs (or whatever debug env you like to use). Better would be an arbitrary man page or info node, :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#146133: info goto node with dot
GNU. Free.Document.License and boing, I cannot go the the node. Ah! Is it documented somewhere that node names *SHOULD NOT* contain .? Yes, in the Texinfo manual. If yes, we can also forget about this and close this bug, because info is not used according to the documentation, misuse. We could, but still, it would be nicer to actually fix it to work. Since Emacs Info can handle it, there's no real reason why standalone Info shouldn't be able to do so as well. Ultimately we want to get rid of that restriction anyway. I briefly grepped through the source, and I think (no promises) the relevant code might be the horribly ugly test in skip_node_characters in search.c, if you feel like messing with it for a few minutes ... Thanks, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276000: Bug reports for texinfo (and 2 wishes)
276000 Wrong page number in table of contents
I have just checked in this changed to texinfo.tex which I hope fixes
this one. (texinfo.tex is a lot easier to hack than info :)
Thanks,
Karl
--- texinfo.tex 8 Jan 2006 22:14:37 - 1.206
+++ texinfo.tex 27 Jan 2006 22:46:07 -
@@ -4,5 +4,5 @@
\expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
%
-\def\texinfoversion{2006-01-08.14}
+\def\texinfoversion{2006-01-27.14}
%
% Copyright (C) 1985, 1986, 1988, 1990, 1991, 1992, 1993, 1994, 1995,
@@ -4505,11 +4505,19 @@
\fi\fi\fi
%
-% Write the toc entry (before \donoderef). See comments in \chfplain.
+% Write the toc entry (before \donoderef). See comments in \chapmacro.
\writetocentry{\toctype\sectionlevel}{#1}{#4}%
%
% Write the node reference (= pdf destination for pdftex).
-% Again, see comments in \chfplain.
+% Again, see comments in \chapmacro.
\donoderef{#3}%
%
+% Interline glue will be inserted when the vbox is completed.
+% That glue will be a valid breakpoint for the page, since it'll be
+% preceded by a whatsit (usually from the \donoderef, or from the
+% \writetocentry if there was no node). We don't want to allow that
+% break, since then the whatsits could end up on page n while the
+% section is on page n+1, thus toc/etc. are wrong. Debian bug 276000.
+\nobreak
+%
% Output the actual section heading.
\vbox{\hyphenpenalty=1 \tolerance=5000 \parindent=0pt \raggedright
@@ -4574,5 +4582,5 @@
[EMAIL PROTECTED]
\temp
- }
+ }%
\fi
\fi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#146133: info goto node with dot
Hi Norbert, Back on this from November ... 146133 and 151850 Matching vs. Searching -- If you take a info file which is split into different files, and there is a node containing a `.', jumping to this node does not work. I checked this with 4.8 and it is still present there. (I have a rather long example here, if you want I send it to you) In my tests, splitting into different files doesn't matter. For instance, the a2ps, gettext, and cvs manuals have node names containing . in subfiles, and (oddly enough) both standalone info and emacs could find them. Here we have some very strange problem: I don't know wether you are interested in taking a look at this. The problem is that the *INFO* files are *generated* from html pages, not via texi files. THe actual road is: TeX Document - latex2html - HTML Document - python script - info files I assume that the generation of the info files contains a bug. I don't see anything obviously wrong in those (python2.1-lib) info files, so unfortunately I can't quickly blame the info generation code :). I notice that the info reader does recognize the node, in that it shows up in the completion list. I also notice that I cannot reach the node by other means, e.g., traversing the menus (string services, re), I get the interesting error: Matching vs. Searching: No such file or directory The only idea that comes to my mind is that perhaps it's because the *filename* also contains a . (the 2.1). Can you try making the python docs without that dot, and/or making a test file with a dot, and see what happens? BUT: the emacs info reader actually *can* jump to the Matching vs. Searching node. So either the emacs-info reader add some kind of magic or there is a problem in info. Clearly there is some difference, but bugs in standalone info are the lowest priority for me. Furthermore, node names are also documented not to contain . -- although this is a ridiculous restriction, it is one of long standing, and it's not easy to fix in full generality. So unless some lightning strikes or another developer appears, I can't hold out a lot of hope on this one, sorry ... Thanks, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345604: [tex-live] Re: ConTeXt documentation in commercial products
since there is never the guarantee Guarantees aren't necessary, in my mind. With context, there is probably no way to guarantee that anyone can ever get exactly the same result as you unless they come over to your office and duplicate your disks :). (Probably not even that would be enough.) The main point of free documentation is to allow, in principle, someone who makes changes to the free software it describes to also update the documentation. Distributing pdf's doesn't allow that. Making a good-faith effort to distribute sources (even if not necessarily complete / guaranteed to run) does. Any interest in reconsidering? if i generate an html page from an xml file, it has no source either). If you generate an html page from an xml file, the xml file is the source. understand those tens of pages of legal stuff -) Well, the GPL is five pages typeset, but your point remains the same :). Thanks, k -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345739: (fwd) Bug#345739: Multiple segfaults when resizing the terminal
Hi Loic, + * Fix segfault when resizing the terminal rapidly by checking more carefully +whether the display line is set prior to refering to it. +[info/display.c:display_update_one_window] Thanks for sending in this change (and thanks, Norbert, for passing it on, since otherwise I would never have learned about it). The patch is certainly sensible, and I've installed it. As for the remaining problem: occasional segfault when rapidly resizing, with a weird value of entry: ... I'm afraid some corruption happens or unintialized memory is used, and I suggest you run info in valgrind. 1) Unfortunately, I can't resize my window rapidly enough to make the crash happen. 2) Unfortunately again, I'm not set up to run valgrind, nor can I make it (and analyzing the results) a priority. 3) If you or anyone are able to use valgrind or other tools to detect such memory problems, that would be great. I am not surprised that rapid window resizes (and consequent signal handling) are not 100% robust. That code was written many, many years ago, and this is one of the many areas where standards committees have promulgated many changes. Thanks again for the patch. Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345739: (fwd) Bug#345739: Multiple segfaults when resizing the terminal
Here is another bug report, this time about segfaults. It contains extensive backtraces and a small patch. Thanks. I haven't heard about this one before. If you can't reproduce it, I doubt I can either, but the patch sounds fine in any case, even if it doesn't 100% solve it. Anyway, will look at it ASAP. Thanks again, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340555: XyMTeX in TeX live
Regretfully, Dr. Shinsaku unambiguously replied to me that he wishes to restrict XyMTeX distribution. So I'll be taking it out of TeX Live for next year. Date: Thu, 01 Dec 2005 09:16:29 +0900 From: Fujita Shinsaku [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Karl Berry) Subject: Re: XyMTeX licensing Dear Dr. Berry Thank you for your announcement on XyMTeX. Because XyMTeX has not been fully developed and should be equipped with other additional functions, I wish to restrict the disturibution within personal use and CTAN distribution. If that is truly what you intend, then we will regretfully have to remove XyMTeX from TeX Live (and other free software distribution). So I think this conclusion would be inevitable under your policy. Sincerely Yours Shinsaku Fujita [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340555: XyMTeX in TeX live
Hi Norbert, I hope life after release of TL2005 has settled down a bit Well, just redirected into other areas :(. Interstingly, the files state something a bit different: A license statement clearly taken from tex.web, so I'm glad it is not considered nonfree :). we (actually Frank Küster suggested this) would like you to ask him again about the license condition, Ok, I will ask him. Cheers, karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340555: XyMTeX licensing
Dear Dr. Shinsaku, I'm one of the people developing the TeX Live software distribution for the TeX user groups. The Debian project recently asked me about XyMTeX, which we do currently include in TeX Live, based on your license statement being analogous to that of Knuth's for TeX itself. But now it seems that back in April, Debian contacted you about this, and you replied that only personal + CTAN redistribution was allowed. If that is truly what you intend, then we will regretfully have to remove XyMTeX from TeX Live (and other free software distribution). Of course we'd much prefer to keep distributing it. So, may I ask you to clarify/confirm, please? If you do intend the user groups and distributions to be able to include it, then I'd like to further suggest that the LPPL (http://www.latex-project.org/lppl/) is perhaps the simplest widespread choice that seems to come closest to your wishes. Thanks for all your work, and best regards, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328365: temporary file race in texindex
0600? 0666 might lead to an information leak. Thanks, changed. This comment is outdated after the patch. Right. I fixed that comment and a couple other minor things when I applied. Thanks, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328365: temporary file race in texindex
In fact the patch seems to be against texinfo-4.8, the last released version of texinfo. Well, the patch applies, but that's not what I was saying. One question: For the upcoming texinfo-4.8 package in Debian, can I use the patch of Henry, Karl? It's up to you, but I don't advise it. It reverts many declarations to KR form (i.e., a much older texindex.c). Aside from that, it also reverts at least one bug fix I made regarding initials (years ago). Perhaps you or someone could work on just making a patch which fixes the race condition without all the other extraneous (and undesirable) changes. That would help me. Thanks, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328365: temporary file race in texindex
Can you please comment on my first try on this, attached. That looks just fine. I'll apply it later today or tomorrow. Thanks Norbert! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328365: temporary file race in texindex
I've adapted the OpenBSD stuff and created a patch. Maybe you want to look at it if this works. Thanks for doing this. In general, the OpenBSD code seems to be a couple versions back, as it has KR function definitions and omits a couple other changes I made (quite) a while ago. I wonder if you could start with the current texindex.c and make a patch with only the mk*temp changes? I could separate it out from your patch given time, but it will happen that much faster if you wouldn't mind going that extra step. The race-condition fix itself looks fine to me, although I admit I am not especially expert at such things. Thanks again, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328365: temporary file race in texindex (was: CAN number)
This has been assigned CAN-2005-3011, please mention this number in the changelog when you fix this to allow easy tracking. Someone, please send me the actual bug report, and (hopefully) a fix. Thanks, karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328365: temporary file race in texindex
It increased its revision control version number from 1.3 to 1.11, but there are no changes - have they all been reverted? There were no changes to texindex.c. The $Id$ change isn't meaningful -- it happened because of temporarily moving Texinfo to berlios (because savannah was dead for months) and then moving it back. | In OpenBSD this seems to have been fixed in 2000 (sic!), see this patch Since the BSD folks (or Red Hat or anyone else but you, pretty much) never bother to forward me any bugs or fixes they make, it's only by random chance like this that I find out about them. I rarely have time to go seeking them out. I don't see why texindex cannot simply use completely random filenames? Sounds fine to me. Any chance of sending me a clean patch? The BSD patch has so many conflicts that it is hard to tell what is really being changed in this regard. Thanks, k -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322713: [tex-live] (fwd) Bug#322713: dvipdfm doesn't understand gs anymore
Please consider to drop dvipdfm in favor of dvipdfmx! Funny thing. I asked the fmx maintainers the same thing, about completely dropping fm in favor of fmx in TL, and they advised me not to do so. fm had additional programs (ebb and something else), and different behavior in some cases. They hoped to make it completely compatible soon, so we could drop fm next time around. At least that was my understanding ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#250216: [tex-k] Plans about supporting TrueType/Type42 fonts in dvips?
are there any plans to enable dvips to include TrueType fonts in a Postscript file, by wrapping them up as Type42 fonts? I am not aware of anything along these lines. Tom? If there is some TrueType+TeX volunteer interested in working on it, patches would be welcome, I'm sure. I also feel sure there are a lot of subsidiary issues. It would be good to be compatible with pdftex's truetype support, if that makes sense. (I'm not too familiar with what pdftex can and can't do with truetype.) Support for OpenType would probably be even more useful going forward. Do you know if they be handled via Type42? Or some other way? Best, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316154: [tex-live] Re: Bug#316154: texmf.cfg: Close possible security problem
Well, the submitter spoke about some mal code sent to somebody, who calls it and the LaTeX file does something really bad. As far as I know, foreign files can't do anything *really* bad. As distributed, TeX will only write files (via \openout) under TEXMFOUTPUT (if set) or the current directory, not to arbitrary paths. And of course it only has current-user privileges, anyway. And it won't run arbitrary processes, either (\write18 is disabled by default), either. As for reading, I don't see a problem in this scenario. Fine, so this foreign document can read /etc/passwd, and you process it and the output contains a nicely (horribly) typeset version of /etc/passwd. As long as you don't blindly post the output on the web for all to see, I see no problem here. Nothing TeX does will get the information to anyone but you, and you already had permission to read it. The time I can see reading being a problem is in a TeX preview web page scenario, where people can upload arbitrary documents or insert arbitrary code. In this case, setting openin_any=p makes all the sense in the world. (I doubt it is sufficient, but at least it is a start.) Perhaps you can condense the above into a couple of sentences for texmf.cnf :). normally I don't read very long documnents before processing them I don't either, but I don't see a problem with it. Agreed. Where can I find the docs for texmf.cnf? I would either add text to the `Runtime options' node in the Web2c manual, or add a new node `Security' as the last section of the `Installation' chapter, depending on how much we have to say. The individual options of texmf.cnf aren't systematically documented anywhere but in the file itself -- the `Runtime options' node is all there is. (I don't think it makes sense to put this kind of information where the syntax of texmf.cnf is discussed, which is in the Kpathsea manual ...) best, karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316154: [tex-live] Re: Bug#316154: texmf.cfg: Close possible security problem
Hi Hilmar, % The default settings are not secure when you process LaTeX files of % possibly doubtful origin. In this case, set openin_any = p. I'm not too excited about putting such a vague and alarmist message into texmf.cnf. I have no objection to putting in something more specific, along the lines of openin_any=t will let TeX documents read any file on the system; if you're allowing unknown people to run your TeX over the web, you should change this to openin_any=p. Well, that's not great, but you get the idea. What's the scenario where this is a problem again? Ordinarily the output from TeX is not readable except by someone on the system who can read any file TeX can anyway. If we're talking about some hypothetical web interface which allows generic uploading/running tex/displaying back, that's not a good idea for lots of other reasons, too. I've no clue if that will really help many people, I agree with you that 99% of users (at least) will never see a note in texmf.cnf, but we could write a couple of sentences in the documentation, if we can come up with something useful to say (even if just to point to when this question arises in the future). That would have slightly more of a chance of being seen. Best, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#262967: [twg-tds] Re: Bug#262967: cjk-latex: /usr/share/texmf/hbf2gf does not comply with TeX Directory Structure
Hi Frank and all,
So can hbf2gf stay as a top directory?
Seems fine to me, FWIW. Did someone suggest otherwise?
Probably this is just a missing
feature of the TDS. What do others think?
Obviously the TDS cannot explicitly mention every program in the world,
that being an open-ended list. Here is what it says:
\item[\replaceable{program}] for program-specific input and
configuration files for any \TeX{}-related programs (examples:
\path|mft|, \path|dvips|). In fact, the \path|tex|, \path|metafont|,
\path|metapost|, and \path|bibtex| items above may all be seen as
instances of this case.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
