[bug #60613] configure script should use our BuildFoundries.pl instead of gs -h to locate URW fonts

Follow-up Comment #3, bug #60613 (project groff): Resolving this ticket would mean fixing the chicken/egg problem discussed in bug #63824. I knew we'd talked about this somewhere before. ___ Reply to this item at:

[bug #60613] configure script should use our BuildFoundries.pl instead of gs -h to locate URW fonts

Update of bug #60613 (project groff): Category: Font devps => Font devpdf ___ Follow-up Comment #2: Assign to correct component ("category" in Savannah-speak).

Re: [PATCH] src/libs/libxutil/XFontName.c(utoa): non-GNU stdlib.h conflict

Hi Brian, At 2023-02-23T10:04:41-0700, Brian Inglis wrote: > On 2023-02-23 09:07, G. Branden Robinson wrote: > > At 2023-02-23T00:46:45-0700, Brian Inglis wrote: > > > gcc 11.3 build failure when static utoa definition in XFontName.c > > > conflicts with extern utoa declared in stdlib.h [...] > >

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #48, bug #63808 (project groff): Hi Deri, [comment #40 comment #40:] > > The question I was trying to ask was, "how do I simulate the scenario of URW fonts being absent and Ghostscript being present on the Debian system I'm using for testing?" > Now, this a good question. So you

[bug #55300] configure script tells users to look for URW fonts at dead URL

Update of bug #55300 (project groff): Status: Need Info => Duplicate Open/Closed:Open => Closed Summary: configure script tells users to look for URW fonts at dead URL and doesn't say w

[bug #63827] withdraw contrib/pdfmark

Follow-up Comment #3, bug #63827 (project groff): [comment #2 comment #2:] > Granted, that doesn't address the possibility that MR might be invoked with fewer than two arguments -- because pdfroff.1.man never calls it with fewer -- but that's a trivial adjustment, for the more general case. Right

[bug #63827] withdraw contrib/pdfmark

Follow-up Comment #2, bug #63827 (project groff): [comment #1 comment #1:] > Some changes, since then I already have captured, in some shape or > form; some others, (at least one of which looks suspiciously wrong, > to me... I guess I shouldn't make such statements, without corroboration. I had p

Re: [PATCH] src/libs/libxutil/XFontName.c(utoa): non-GNU stdlib.h conflict

Thanks Branden, On 2023-02-23 09:07, G. Branden Robinson wrote: At 2023-02-23T00:46:45-0700, Brian Inglis wrote: gcc 11.3 build failure when static utoa definition in XFontName.c conflicts with extern utoa declared in stdlib.h (but is not a WG14- or POSIX-standardized function) third argume

[bug #63831] src/libs/libxutil/XFontName.c(utoa) conflicts with stdlib.h utoa in non-GNU libc

URL: Summary: src/libs/libxutil/XFontName.c(utoa) conflicts with stdlib.h utoa in non-GNU libc Group: GNU roff Submitter: None Submitted: Thu 23 Feb 2023 04:56:22 PM UTC Categ

[bug #63824] revert recent change to skip tests at configuration time

Update of bug #63824 (project groff): Status: In Progress => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #4: commit 5486b5bc09f39

[bug #63825] [man pages] insufficient escaping in fallback MR definition

Update of bug #63825 (project groff): Status: In Progress => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: commit a9767ace3dd6a

[bug #63133] [pdfroff] throws warning on any document if -ww given

Follow-up Comment #7, bug #63133 (project groff): Not a resolver, just an updater. commit 948ccc55e6feb4f6db235488e485eb4386dc9b6a Author: G. Branden Robinson Date: Tue Feb 21 14:23:02 2023 -0600 pdfroff(1): Note new upstream development site. See

Re: [PATCH] src/libs/libxutil/XFontName.c(utoa): non-GNU stdlib.h conflict

[looping in groff@gnu for discussion] Hi Brian, At 2023-02-23T00:46:45-0700, Brian Inglis wrote: > gcc 11.3 build failure when static utoa definition in XFontName.c > conflicts with extern utoa declared in stdlib.h (but is not a WG14- or POSIX-standardized function) > third argument is usually

[bug #63133] [pdfroff] throws warning on any document if -ww given

Follow-up Comment #6, bug #63133 (project groff): [comment #5 comment #5:] > Bug #63827 is now open to track the removal of pdfmark from the > groff git repository. The following is more relevant to that bug, And I will follow up there. > but I'm starting it here because it's a reply to a comment

[bug #63827] withdraw contrib/pdfmark

Follow-up Comment #1, bug #63827 (project groff): bug #63133 comment #5: > Bug #63827 is now open to track the removal of pdfmark from the > groff git repository. The following is more relevant to that bug, > but I'm starting it here because it's a