On Sat, Mar 01, 2025 at 10:51:44AM +, Gavin Smith wrote:
> I came across a section in the Automake manual describing problems with
> Makefile rules with multiple outputs.
>
> https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html
>
> We have such rules in several places
On Sat, Mar 01, 2025 at 01:48:39PM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Sat, 1 Mar 2025 11:16:31 +
> >
> > A simpler solution could be to use the GNU make .NOTPARALLEL feature:
>
> Are we requiring GNU Make for building Texinfo? Because otherwise
> '.NOTPARALLEL' is A
> From: Gavin Smith
> Date: Sat, 1 Mar 2025 11:16:31 +
>
> A simpler solution could be to use the GNU make .NOTPARALLEL feature:
Are we requiring GNU Make for building Texinfo? Because otherwise
'.NOTPARALLEL' is AFAIK GNU-specific.
On Sat, Mar 01, 2025 at 10:51:44AM +, Gavin Smith wrote:
> I had an idea that "locking" could be done in a separate helper program.
> The "make" rule would become something like:
>
> LOCK_ONCE=build_aux/lock-once.sh
>
> $(srcdir)/main/command_data.c $(srcdir)/main/command_ids.h
> $(srcdir)/m
I came across a section in the Automake manual describing problems with
Makefile rules with multiple outputs.
https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html
We have such rules in several places for building texi2any. For example,
in tta/C/Makefile.am:
$(srcdir)/mai
On Thu, 9 Jan 2025 at 09:12, Werner LEMBERG wrote:
> >> So: can this be fixed on the side of `texinfo.tex` at least for the
> >> space character, circumventing the luatex bug for the most common
> >> case?
> >
> > I have minimal understanding of lua and
>> So: can this be fixed on the side of `texinfo.tex` at least for the
>> space character, circumventing the luatex bug for the most common
>> case?
>
> I have minimal understanding of lua and luatex. I've edited
> texinfo.tex in the obvious way: [...]
>
> I
On Wed, Jan 08, 2025 at 04:39:58AM +, Werner LEMBERG wrote:
> > So 0x20 is translated as '\\040', i.e., 4 bytes instead of ' ',
> > 1 byte, and strcmp correctly sorts 4 bytes and this is the bug:
> > luatex has to unscape these strings before the sort
ewers like `evince` or `okular` are not affected,
ghostscript (as a post-processor) and Acrobat (at least as a viewer)
actually are.
Luigi wrote to me the following in a private e-mail:
> It's a bug in luatex, [...] Inside [the demo PDF] we have [stuff
> like]
>
> ```
> 44848
On Tue, Dec 03, 2024 at 08:24:52PM +, Gavin Smith wrote:
> On Tue, Nov 19, 2024 at 09:04:23PM +, Gavin Smith wrote:
> > While testing texi2any, I accidentally found a bug:
> >
> > $ export top_srcdir=../../ top_builddir=.. TEXINFO_DEV_SOURCE=1
> > $ ./tex
On Tue, Nov 19, 2024 at 09:04:23PM +, Gavin Smith wrote:
> While testing texi2any, I accidentally found a bug:
>
> $ export top_srcdir=../../ top_builddir=.. TEXINFO_DEV_SOURCE=1
> $ ./texi2any ../doc/info-stnd.info
> texi2any: warning: input file info-stn
On Sun, Nov 24, 2024 at 04:33:25PM +0100, Patrice Dumas wrote:
> On Sun, Nov 24, 2024 at 01:31:58PM +0100, Patrice Dumas wrote:
> > Sure. Maybe we could add a more explicit quotation warning in the
> > manual, like
> >
> > @cartouche
> > @quotation warning
> > Source highlighting is experimental,
On Sun, Nov 24, 2024 at 01:31:58PM +0100, Patrice Dumas wrote:
> Sure. Maybe we could add a more explicit quotation warning in the
> manual, like
>
> @cartouche
> @quotation warning
> Source highlighting is experimental, feedback is welcomed.
>
> The HIGHLIGHT_SYNTAX arguments are likely to chan
On Sun, Nov 24, 2024 at 01:05:56PM +, Gavin Smith wrote:
> Thanks. I imagine that if the user's document had the same language
> in different examples (e.g. TeX), but that it had to be highlighted
> differently for the same language in different examples (e.g. TeX
> with different catcodes, e.
On Sun, Nov 24, 2024 at 02:53:17PM +0200, Eli Zaretskii wrote:
> > Is it worth having both options for syntax highlighting for source-highlight
> > in case an example changes something for later examples? I do not know
> > anything about how source-highlight works, so it may not be a problem,
> >
> From: Gavin Smith
> Date: Sun, 24 Nov 2024 11:05:49 +
>
> On Sat, Nov 23, 2024 at 07:44:18PM +0100, Patrice Dumas wrote:
> > On Fri, Nov 22, 2024 at 10:02:15AM -0800, Raymond Toy wrote:
> > > First, a simple bug
> > > https://www.gnu.org/software/texinf
On Sun, Nov 24, 2024 at 11:05:49AM +, Gavin Smith wrote:
> Is it worth having both options for syntax highlighting for source-highlight
> in case an example changes something for later examples? I do not know
> anything about how source-highlight works, so it may not be a problem,
> but imagin
On Sat, Nov 23, 2024 at 07:44:18PM +0100, Patrice Dumas wrote:
> On Fri, Nov 22, 2024 at 10:02:15AM -0800, Raymond Toy wrote:
> > First, a simple bug
> > https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Syntax-Highlighting,
> > where the link for "GNU S
On Sat, Nov 23, 2024 at 10:44 AM Patrice Dumas wrote:
> On Fri, Nov 22, 2024 at 10:02:15AM -0800, Raymond Toy wrote:
>
> > But I tried texinfo 7.1.1 with HIGHLIGHT_SYNTAX with pygments to
> highlight
> > the examples in Maxima's user manual. It works quite well for the few
> > examples I looked
On Fri, Nov 22, 2024 at 10:02:15AM -0800, Raymond Toy wrote:
> First, a simple bug
> https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Syntax-Highlighting,
> where the link for "GNU Source-Highlight" is broken.
This seems to be fixed in the development versi
On Fri, Nov 22, 2024 at 10:02 AM Raymond Toy wrote:
>
> But I tried texinfo 7.1.1 with HIGHLIGHT_SYNTAX with pygments to highlight
> the examples in Maxima's user manual. It works quite well for the few
> examples I looked at. Generating the HTML document took much longer than
> usual, but I gu
First, a simple bug
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Syntax-Highlighting,
where the link for "GNU Source-Highlight" is broken.
But I tried texinfo 7.1.1 with HIGHLIGHT_SYNTAX with pygments to highlight
the examples in Maxima's user manual. It works
n make the
difference between a modest-sized buffer underflow and a huge overflow.
An argument could be made that the probable segfault resulting from a
huge overflow is the more helpful failure mode, as it reduces the
possibility that the bug goes unnoticed until it turns into a deeply
buried
arer code, I am considering
> > setting SEARCH_BINDING start and end offsets to size_t instead of long.
> > Indeed, this should be a bug if they are negative (although there were
> > places in the code where they could become negative temporarily, before
> > being reset to
instead of long.
> Indeed, this should be a bug if they are negative (although there were
> places in the code where they could become negative temporarily, before
> being reset to 0 right after, which I modified).
As Eli said, unsigned types in C can be dangerous. I have spent hour
> Date: Tue, 8 Oct 2024 01:46:56 +0200
> From: Patrice Dumas
>
> Keeping long could hide some bugs of offsets becoming negative, but also
> be more robust in face of those bugs if it does not matter much that the
> offsets become negative.
>
> Any advice?
>
> I attach the patch that would set S
Hi Patrice,
Patrice Dumas writes:
> I realized that there was a bug because I had set SEARCH_BINDING start
> and end offsets to size_t, which lead s.start becoming the max size_t
> value (and to a segfault), I had not seen it while reviewing the code
> for such possibilities.
>
Hello,
In the info reader, as part of an effort to avoid comparison of signed
and unsigned integers, and also to have a clearer code, I am considering
setting SEARCH_BINDING start and end offsets to size_t instead of long.
Indeed, this should be a bug if they are negative (although there were
node prev for `Index' is
> > `Texinfo@asis{::}Convert@asis{::}Plaintext' in sectioning but not in menu
> > texi2any_internals.texi:374: warning: node up for `Index' is `Top' in
> > sectioning but not in menu
> > texi2any_internals.texi:15: warning: node `Top
Hi, Patrice,
On Sat, Aug 17, 2024 at 9:08 AM Patrice Dumas wrote:
>
> It would be somewhat strange if it fixes Dario issue, but who knows.
> In any case it was a good thing to fix.
It actually did -- I am able to build commit 4174fe2155 just fine.
Thanks a lot!
I am unfortunately not familiar w
any_internals.texi:374: warning: node up for `Index' is `Top' in
> sectioning but not in menu
> texi2any_internals.texi:15: warning: node `Top' lacks menu item for `Index'
> despite being its Up target
> BUG: format_line_message: error_location_info undef at
> ..
On Fri, Aug 16, 2024 at 12:25:45AM +0100, Gavin Smith wrote:
> BUG: format_line_message: error_location_info undef at
> ../../tp/../tp/Texinfo/Report.pm line 86.
> Texinfo::Report::format_line_message("warning", "menu entry node name
> should not contain `:&#x
xi:374: warning: node prev for `Index' is
`Texinfo@asis{::}Convert@asis{::}Plaintext' in sectioning but not in menu
texi2any_internals.texi:374: warning: node up for `Index' is `Top' in
sectioning but not in menu
texi2any_internals.texi:15: warning: node `Top' lacks me
ay have
> been other changes on the master branch that this patch relied on.
>
> I think we should only include this patch if:
>
> * Patrice thinks it is okay for the release branch; and
> * The bug is important enough to fix in a bug-fix release, when balanced
> against the comp
;
> I think we should only include this patch if:
>
> * Patrice thinks it is okay for the release branch; and
> * The bug is important enough to fix in a bug-fix release, when balanced
> against the complexity of the change and the risk of introducing further
> bugs (which
clude this patch if:
* Patrice thinks it is okay for the release branch; and
* The bug is important enough to fix in a bug-fix release, when balanced
against the complexity of the change and the risk of introducing further
bugs (which I doubt).
Distributors (like Debian) would always be free to include the patch
if they wanted to.
rt b225268a2ecdc58a06faa73c629ae1810942989f
corresponding to 2023-02-01 Patrice Dumas to fix the
parsing of @table @asis\n@item @end table inducing a bug.
Report from Florian Weimer.
* tp/Texinfo/ParserNonXS.pm (_close_current, _end_line),
tp/Texinfo/XS/parsetexi/close.c (close_current),
tp/Texinfo/
ng argument
The message "You found a bug" does indeed indicate a bug.
In the original input file (cc65.texi), the failing input is around line
1086:
@w{ }
@item !@*.NOT
@item Boolean not
@item 7
@item @end table
@*
@center Available operators, sorted by precedenc
Hi Florian,
Thanks for the report!
Florian Weimer writes:
> The attached file produces this error when being processed with
> “makeinfo cc65.texi”:
>
> | You found a bug: Nothing closed while a line context remains
> | - (document_root)[C43]
> |
> |
> | Addition
Gavin Smith wrote:
> I've attempted to fix it in version 2023-03-27.21. I tried to
> support different configurations of manual (e.g. @contents at start,
> @contents at end, no @contents) but it is quite possible I've missed
> some possibilities.
Looks good to me.
Thanks!
Arnold
Gavin Smith wrote:
> On Sun, Mar 26, 2023 at 08:54:20PM +0300, arn...@skeeve.com wrote:
> > Hi.
> >
> > I just formatted the gawk manual to PDF. The pages themselves
> > look fine. However, using evince on Ubuntu 22.04, the side bar showing
> > the sections and pages, has all the page numbers i
On Sun, Mar 26, 2023 at 08:54:20PM +0300, arn...@skeeve.com wrote:
> Hi.
>
> I just formatted the gawk manual to PDF. The pages themselves
> look fine. However, using evince on Ubuntu 22.04, the side bar showing
> the sections and pages, has all the page numbers in roman numerals!
>
> I'm using
Hi.
Gavin Smith wrote:
> On Sun, Mar 26, 2023 at 08:54:20PM +0300, arn...@skeeve.com wrote:
> > Hi.
> >
> > I just formatted the gawk manual to PDF. The pages themselves
> > look fine. However, using evince on Ubuntu 22.04, the side bar showing
> > the sections and pages, has all the page numb
On Sun, Mar 26, 2023 at 08:54:20PM +0300, arn...@skeeve.com wrote:
> Hi.
>
> I just formatted the gawk manual to PDF. The pages themselves
> look fine. However, using evince on Ubuntu 22.04, the side bar showing
> the sections and pages, has all the page numbers in roman numerals!
>
> I'm using
Hi.
I just formatted the gawk manual to PDF. The pages themselves
look fine. However, using evince on Ubuntu 22.04, the side bar showing
the sections and pages, has all the page numbers in roman numerals!
I'm using texi2pdf 7.0.1.
Let me know if you want a screen shot.
Thanks,
Arnold
On 3/23/23 13:36, Patrice Dumas wrote:
There was a bugtracker at some point, but it was not so useful.
On Thu, Mar 23, 2023 at 07:44:47PM +, Gavin Smith wrote:
The scale of this project is also a factor here, and if it were a larger
project a bug tracking system might be more useful
Gavin Smith , Thu Mar 23 2023 20:44:47
GMT+0100 (Central European Standard Time)
On Thu, Mar 23, 2023 at 05:57:58PM +0100, Bogdan wrote:
No bugtracker? Not good from a bug reporter's point of view :). I thought
all FSF projects use the same bugtracker, it would seem logical. You
probably
There was a bugtracker at some point, but it was not so useful.
On Thu, Mar 23, 2023 at 07:44:47PM +, Gavin Smith wrote:
> The scale of this project is also a factor here, and if it were a larger
> project a bug tracking system might be more useful, although I don't really
> h
On Thu, Mar 23, 2023 at 05:57:58PM +0100, Bogdan wrote:
> No bugtracker? Not good from a bug reporter's point of view :). I thought
> all FSF projects use the same bugtracker, it would seem logical. You
> probably have a good reason for not to have one, but don't you sometim
Am 08.02.2023 um 23:55 teilte Gavin Smith mit:
Hi Gavin,
I still didn't get it right. This change stopped the crash but it
could lead to missing text in nodes. The "Manipulating Hyphenation"
node in the groff manual only had 222 lines displayed, but it should
have had 323 lines.
So I've made
r message looks differently.
> >
> > hille@sid-amd64:~$ /usr/bin/info groff > /dev/null
> > realloc(): invalid next size
> > Aborted (core dumped)
>
> Apologies for the further crash. I believe I have fixed it in commit
> 9a83ffc3d. I have also added the change to t
* Hilmar Preuße , 2022-11-14 17:27:
This seems to hang forever:
$ LC_ALL=C info python3.10 -n 'Other Language Changes<3>'
[...]
Worse, when I change the terminal size while it's running, it segfaults.
Backtrace:
#0 0x5661ca96 in window_make_modeline (window=window@entry=0x582a0b30) at
.
Hi.
Gavin Smith wrote:
> On Mon, Jan 02, 2023 at 10:36:20PM +0200, Arnold Robbins wrote:
> > Hi.
> >
> > When I format the gawk manual using texinfo.tex 2022-12-19.22
> > there is a problem on the very first two pages. These are the
> > pages from @shortti
On Mon, Jan 02, 2023 at 10:36:20PM +0200, Arnold Robbins wrote:
> Hi.
>
> When I format the gawk manual using texinfo.tex 2022-12-19.22
> there is a problem on the very first two pages. These are the
> pages from @shorttitlepage.
>
> The bug is that these pages have page num
Hi.
When I format the gawk manual using texinfo.tex 2022-12-19.22
there is a problem on the very first two pages. These are the
pages from @shorttitlepage.
The bug is that these pages have page numbers! The first page
has a simple "1". The second (otherwise blank) page has a
full
> From: Gavin Smith
> Date: Wed, 14 Dec 2022 08:13:55 +
> Cc: 59...@debbugs.gnu.org, bug-texinfo@gnu.org
>
> I think using curly quotes by default was a mistake in the first place
> for UTF-8 input; however, any changes to the defaults should be discussed
> on bug-texin
and line.
I think using curly quotes by default was a mistake in the first place
for UTF-8 input; however, any changes to the defaults should be discussed
on bug-texinfo@gnu.org. The main issue that I would foresee is that
in Emacs Info mode, there can be highlighting of text surrounded by
curly
; /dev/null
> realloc(): invalid next size
> Aborted (core dumped)
Apologies for the further crash. I believe I have fixed it in commit
9a83ffc3d. I have also added the change to the release branch, and I
think that we should make a bug-test release fairly soon with this fix
in it (say, within a mon
mar
Weitergeleitete Nachricht
Betreff: Bug#1025940: info: buffer overflow in copy_converting()
Weitersenden-Datum: Mon, 12 Dec 2022 09:51:01 +
Weitersenden-Von: Jakub Wilk
Weitersenden-An: debian-bugs-d...@lists.debian.org
Weitersenden-CC: jw...@jwilk.net, Debian TeX Task Force
Datum: Mon, 12
On Sat, Dec 03, 2022 at 01:45:31PM +0200, Eli Zaretskii wrote:
> > >
> > > I've observed this on Ubuntu, SLES, and RedHat.
> >
> > Thanks for the report. It should be fixed in commit e114ca3745.
>
> I believe you meant commit edff3e5615, right?
Yes, that is right.
> From: Gavin Smith
> Date: Fri, 2 Dec 2022 22:46:43 +
> Cc: "bug-texinfo@gnu.org"
>
> On Fri, Dec 02, 2022 at 09:02:04PM +, LaPolla, Justin Anthony wrote:
> > I found a bug in the stand-alone Info reader. To reproduce:
> >
> > Op
On Fri, Dec 02, 2022 at 09:02:04PM +, LaPolla, Justin Anthony wrote:
> I found a bug in the stand-alone Info reader. To reproduce:
>
> Open any file in info. For example, 'info gcc'.
>
> Put the cursor at the top of the page.
>
> Issue the 'b
I found a bug in the stand-alone Info reader. To reproduce:
Open any file in info. For example, 'info gcc'.
Put the cursor at the top of the page.
Issue the 'beginning-of-line' command (e.g. 'M-x beginning-of-line', or
'C-a').
Watch as i
Am 17.11.2022 um 20:25 teilte Gavin Smith mit:
On Thu, Nov 17, 2022 at 08:29:34AM +0200, Eli Zaretskii wrote:
Hello Gavin,
Can you please email me the python3.10.info file off-list so I can
fix it.
File sent off-list.
Thanks. It should be fixed in commit 353c22d11c. The problem was
due
> On 17 Nov 2022, at 19:25, Gavin Smith wrote:
>
> On Thu, Nov 17, 2022 at 08:29:34AM +0200, Eli Zaretskii wrote:
>>> From: Gavin Smith
>>> Date: Wed, 16 Nov 2022 23:05:59 +0000
>>> Cc: Sam James , bug-texinfo@gnu.org
>>>
>>> Can you plea
On Thu, Nov 17, 2022 at 08:29:34AM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Wed, 16 Nov 2022 23:05:59 +
> > Cc: Sam James , bug-texinfo@gnu.org
> >
> > Can you please email me the python3.10.info file off-list so I can
> > fix it.
&
> From: Gavin Smith
> Date: Wed, 16 Nov 2022 23:05:59 +
> Cc: Sam James , bug-texinfo@gnu.org
>
> Can you please email me the python3.10.info file off-list so I can
> fix it.
File sent off-list.
On Tue, Nov 15, 2022 at 05:46:46PM +0100, Hilmar Preuße wrote:
> Am 15.11.2022 um 16:49 teilte Sam James mit:
> > > On 15 Nov 2022, at 14:03, Hilmar Preuße wrote:
> > > Am 15.11.2022 um 13:56 teilte Eli Zaretskii mit:
> > > > > Date: Mon, 14 Nov 2022 17:27:20 +0100
> > > > > From: Hilmar Preuße
>
Am 15.11.2022 um 16:49 teilte Sam James mit:
On 15 Nov 2022, at 14:03, Hilmar Preuße wrote:
Am 15.11.2022 um 13:56 teilte Eli Zaretskii mit:
Date: Mon, 14 Nov 2022 17:27:20 +0100
From: Hilmar Preuße
Hi,
Hello,
This seems to hang forever:
$ LC_ALL=C info python3.10 -n 'Other Language
> On 15 Nov 2022, at 14:03, Hilmar Preuße wrote:
>
> Am 15.11.2022 um 13:56 teilte Eli Zaretskii mit:
>>> Date: Mon, 14 Nov 2022 17:27:20 +0100
>>> From: Hilmar Preuße
>
> Hi,
>
> Sorry for posting the E-Mail twice!
>
>>> This seems to hang forever:
>>>
>>>$ LC_ALL=C info python3.10 -n
Am 15.11.2022 um 13:56 teilte Eli Zaretskii mit:
Date: Mon, 14 Nov 2022 17:27:20 +0100
From: Hilmar Preuße
Hi,
Sorry for posting the E-Mail twice!
This seems to hang forever:
$ LC_ALL=C info python3.10 -n 'Other Language Changes<3>'
Where can one find this python3.10 Info manual?
> Date: Mon, 14 Nov 2022 17:27:20 +0100
> From: Hilmar Preuße
>
> This seems to hang forever:
>
>$ LC_ALL=C info python3.10 -n 'Other Language Changes<3>'
Where can one find this python3.10 Info manual?
Hi,
another issue for TeXinfo 7.0. This is texinfo 7.0 +
fc756d9128170d92cfacb367e2622c991b1ea5c7
b13b687f6358af61b9fe3a04f50f7824ba38ccef
40ec4f80ba9875cb801390bf7a2fed4371c6c4dc
I'm able to reproduce on Debian unstable, texinfo 7.0 is in experimental.
Hilmar
--- original report ---
This se
On Fri, Apr 08, 2022 at 10:50:19PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 8 Apr 2022 15:53:31 +0200
> > From: Tomas Kalibera
> >
> > Would this be an acceptable fix? (turn OSTYPE to uppercase when setting
> > MSYSTEM)
> >
> > MSYSTEM=$(echo $OSTYPE | tr [a-z] [A-Z]) uname | $EGREP -iv
> From: Gavin Smith
> Date: Fri, 8 Apr 2022 15:12:19 +0100
> Cc: Eli Zaretskii , bug-texinfo@gnu.org
>
> On Fri, Apr 08, 2022 at 03:53:31PM +0200, Tomas Kalibera wrote:
> >
> > On 4/8/22 15:31, Gavin Smith wrote:
> > > On Fri, Apr 08, 2022 at 03
> Date: Fri, 8 Apr 2022 15:53:31 +0200
> From: Tomas Kalibera
>
> Would this be an acceptable fix? (turn OSTYPE to uppercase when setting
> MSYSTEM)
>
> MSYSTEM=$(echo $OSTYPE | tr [a-z] [A-Z]) uname | $EGREP -iv
> 'cygwin|msys' >/dev/null; then
>
> It was suggested by Markus Mützel in a
> From: Gavin Smith
> Date: Fri, 8 Apr 2022 14:31:32 +0100
> Cc: Eli Zaretskii , bug-texinfo@gnu.org
>
> > It works with Msys2 and cygwin for me, but breaks with MSYSTEM, where
>
> What is MSYSTEM? Is this the original msys?
>
> > $ uname
> > MINGW32_
> From: Gavin Smith
> Date: Fri, 8 Apr 2022 13:56:31 +0100
> Cc: Tomas Kalibera , bug-texinfo@gnu.org
>
> What happens if we don't set MSYSTEM at all?
Then you cannot distinguish between MSYS and MinGW, because 'uname'
will return a value that doesn't t
On 4/8/22 18:30, Gavin Smith wrote:
On Fri, Apr 08, 2022 at 06:07:01PM +0200, Tomas Kalibera wrote:
Works for me on all those 3 systems (just needed to add \ at the end of the
line after "/dev/null "). And checking OSTYPE against "msys" is a common
pattern in Msys2 patches, so I assume it is c
On Fri, Apr 08, 2022 at 06:07:01PM +0200, Tomas Kalibera wrote:
> Works for me on all those 3 systems (just needed to add \ at the end of the
> line after "/dev/null "). And checking OSTYPE against "msys" is a common
> pattern in Msys2 patches, so I assume it is correct for Msys2.
Commited in df78
On 4/8/22 17:25, Gavin Smith wrote:
On Fri, Apr 08, 2022 at 04:30:12PM +0200, Tomas Kalibera wrote:
I am not sure what is the correct name of it. I executed
C:\MinGW\msys\1.0\msys.bat to get the shell.
It uses : as path separator.
Have you found that running texi2dvi fails in such an environ
On Fri, Apr 08, 2022 at 04:30:12PM +0200, Tomas Kalibera wrote:
> I am not sure what is the correct name of it. I executed
> C:\MinGW\msys\1.0\msys.bat to get the shell.
> It uses : as path separator.
>
> > Have you found that running texi2dvi fails in such an environment, with
> > my patch above?
On 4/8/22 16:12, Gavin Smith wrote:
On Fri, Apr 08, 2022 at 03:53:31PM +0200, Tomas Kalibera wrote:
On 4/8/22 15:31, Gavin Smith wrote:
On Fri, Apr 08, 2022 at 03:15:01PM +0200, Tomas Kalibera wrote:
What happens if we don't set MSYSTEM at all?
diff --git a/util/texi2dvi b/util/texi2dvi
ind
On Fri, Apr 08, 2022 at 03:53:31PM +0200, Tomas Kalibera wrote:
>
> On 4/8/22 15:31, Gavin Smith wrote:
> > On Fri, Apr 08, 2022 at 03:15:01PM +0200, Tomas Kalibera wrote:
> > > > What happens if we don't set MSYSTEM at all?
> > > >
> > > > diff --git a/util/texi2dvi b/util/texi2dvi
> > > > index
On 4/8/22 15:31, Gavin Smith wrote:
On Fri, Apr 08, 2022 at 03:15:01PM +0200, Tomas Kalibera wrote:
What happens if we don't set MSYSTEM at all?
diff --git a/util/texi2dvi b/util/texi2dvi
index 1f42b41907..c506bbad37 100755
--- a/util/texi2dvi
+++ b/util/texi2dvi
@@ -85,7 +85,7 @@ IFS="$space
On Fri, Apr 08, 2022 at 03:15:01PM +0200, Tomas Kalibera wrote:
> > What happens if we don't set MSYSTEM at all?
> >
> > diff --git a/util/texi2dvi b/util/texi2dvi
> > index 1f42b41907..c506bbad37 100755
> > --- a/util/texi2dvi
> > +++ b/util/texi2dvi
> > @@ -85,7 +85,7 @@ IFS="$space$tab$newline"
$ MSYSTEM=$OSTYPE uname
msys_NT-6.2
$ uname -a
MINGW32_NT-6.2 DESKTOP-G858KME 1.0.19(0.48/3/2) 2016-07-13 17:45 i686 Msys
Tomas
This was added on 2015-09-23 in what is now git commit 02cc28bb352be.
Link to discussion at that time:
https://lists.gnu.org/archive/html/bug-texinfo/2015-09/msg00078.html
I
85,7 +85,7 @@ IFS="$space$tab$newline"
# Msys. It is safer to use OSTYPE, this is why we set MSYSTEM to
# $OSTYPE before calling uname
if test -n "$COMSPEC$ComSpec" \
- && MSYSTEM=$OSTYPE uname | $EGREP -iv 'cygwin|msys' >/dev/null; then
+ && una
> Date: Wed, 6 Apr 2022 14:39:30 +0200
> From: Tomas Kalibera
>
> texi2dvi on Msys2 doesn't find tex, because it incorrectly detects ";"
> as path separator (it is ":").
>
> The problem is in the following code. With Msys2, OSTYPE is "msys", but
> MSYSTEM is upper-case "MSYS" and uname needs i
Hello,
texi2dvi on Msys2 doesn't find tex, because it incorrectly detects ";"
as path separator (it is ":").
The problem is in the following code. With Msys2, OSTYPE is "msys", but
MSYSTEM is upper-case "MSYS" and uname needs it that way:
# In the case of Msys, uname returns a value derived
On Sun, Mar 20, 2022 at 10:22:32AM +0100, Wybo Dekker wrote:
> On line 464:
>
> ldta_result="$ldata_result \"$dir\""
>
> ldata should probably be ldta
Thank you for the report. The bug was probably introduced by me
when I added prefixes to the variable n
On line 464:
ldta_result="$ldata_result \"$dir\""
ldata should probably be ldta
--
Wybo Dekker
Deilsedijk 60
NL-4158 CH Deil
The Netherlands
m: +31 6 3033 3955
On Thu, Nov 25, 2021 at 11:14:39AM -0500, Ken Brown wrote:
> I'm probably the only person building texinfo on Cygwin, but this is just a
> heads-up that there's a bug in gnulib/m4/threadlib.m4 that can cause
> mysterious crashes that are very hard to debug. The bug shows up w
I'm probably the only person building texinfo on Cygwin, but this is just a
heads-up that there's a bug in gnulib/m4/threadlib.m4 that can cause mysterious
crashes that are very hard to debug. The bug shows up when running 'make check'
in the info subdirectory. 13 of the 8
I thought it was a bug, because
it seems to me that makeinfo should produce the same filename regardless of
whether it found the image or not. Perhaps the Org backend is not producing a
correct conversion, but the problem seemed to be an inconsistent result from
makeinfo.
Regards,
wlharvey4
On Thu, Oct 14, 2021 at 12:25:40AM -0700, wlharv...@mac.com wrote:
> sub _convert_image_command has a couple of bugs.
>
> There are a couple of lines that assign to $image_file the concatenation
> $basefile.$extension. However, the concatenation needs to be quoted; e.g.
> $image_file = “$basef
sub _convert_image_command has a couple of bugs.
There are a couple of lines that assign to $image_file the concatenation
$basefile.$extension. However, the concatenation needs to be quoted; e.g.
$image_file = “$basefile.$extension”. Otherwise it is a concatenation of two
strings without the
Thanks for reporting the problem. I installed the attached patch to the
Gnulib web page's manual.css. It fixed things for me after I forced my
browser to reload.
Index: manual.css
===
RCS file: /web/gnulib/gnulib/manual.css,v
retriev
just the section heading).
-- Forwarded message -
From: Steve Ward
Date: Thu, Aug 19, 2021 at 12:56 PM
Subject: Re: bug#50116: Text on GNU grep webpage far too big
To: Gavin Smith
Cc: <50...@debbugs.gnu.org>
On Thu, Aug 19, 2021 at 2:12 AM Gavin Smith wrote:
>
On Tue, Feb 09, 2021 at 10:02:47PM +0100, Barath Aron wrote:
> On 2/9/21 9:55 PM, Gavin Smith wrote:
> > On Tue, Feb 09, 2021 at 09:10:28PM +0100, Barath Aron wrote:
> > > The code path I wrote is the trace of the program, I didn't made it up. It
> > > first opened a regular, non-compressed file wi
1 - 100 of 1659 matches
Mail list logo
