Bug#498082: lintian: false positive in manpages
On Sun, Sep 07, 2008 at 12:02:06AM +, Thorsten Glaser wrote: Russ Allbery dixit: The error message is coming from man --warnings. It's possible that it may have some sort of problem. Can you double-check first that you have the most current man-db package? If so, I'll transfer the bug there. Oh okay. Sure. ii man-db 2.5.2-2on-line manual pager Looks current according to packages.d.o. Please note that man-db is almost never the real source of this kind of bug; if you think the warning is incorrect, please reassign to groff-base, not to man-db. (I've reassigned this one.) Could you please give me a copy of the manual page in question, since this package doesn't appear to be in the Debian archive? Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: lintian: false positive in manpages
Colin Watson dixit: Please note that man-db is almost never the real source of this kind of bug Okay, I did not know which of the many components may be the source. if you think the warning is incorrect, please reassign to groff-base, not to man-db. (I've reassigned this one.) Thanks. Could you please give me a copy of the manual page in question, since this package doesn't appear to be in the Debian archive? Yes, it does not appear… yet ;) but of course I’ve added three exemplars. There’s, interestingly enough, an iconv warning too (maybe in the mdoc macro package?) which lintian does not show. bye, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you 13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺ 16:06⎜Draget:#cvs Thank god I found you =) 17:14⎜ldiain:#cvs Thanks big help you are :-) 18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o 18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-) exemplars.tgz Description: Binary data
Bug#498082: lintian: false positive in manpages
reassign 498082 man-db tags 498082 fixed-upstream thanks On Sun, Sep 07, 2008 at 08:27:06AM +, Thorsten Glaser wrote: Colin Watson dixit: Please note that man-db is almost never the real source of this kind of bug Okay, I did not know which of the many components may be the source. if you think the warning is incorrect, please reassign to groff-base, not to man-db. (I've reassigned this one.) Thanks. Could you please give me a copy of the manual page in question, since this package doesn't appear to be in the Debian archive? Yes, it does not appear… yet ;) but of course I’ve added three exemplars. Heh, you managed to find a case where it actually *was* a man-db bug after all! I did say almost never, I guess ... There’s, interestingly enough, an iconv warning too (maybe in the mdoc macro package?) which lintian does not show. I'm not sure why Lintian didn't show it, but this is the key to the problem. What's happening is that appending //IGNORE to the target encoding given to iconv doesn't quite seem to work as documented, and you have to pass -c as well. The result of this is that the manual page gets truncated in the middle of a list. This is triggered by your use of UTF-8 characters that aren't just recoded versions of ISO-8859-1 characters in comments at the top of the manual page. The Debian Policy Manual documents the current situation: Due to limitations in current implementations, all characters in the manual page source should be representable in the usual legacy encoding for that language, even if the file is actually encoded in UTF-8. Safe alternative ways to write many characters outside that range may be found in groff_char(7). You can work around this bug by replacing those characters with some plain ASCII, perhaps something like this: -.\ * ` generates ‘ in groff, so use \` -.\ * ' generates ’ in groff, \' generates ´, so use \*(aq -.\ * - generates ‐ in groff, \- generates −, fixed in tmac/mdoc/doc-groff +.\ * ` generates U+2018 in groff, so use \` +.\ * ' generates U+2019 in groff, \' generates ´, so use \*(aq +.\ * - generates U+2010 in groff, \- generates U+2212, fixed in tmac/mdoc/doc-groff I've changed man-db to use manconv for all source/target encoding combinations. manconv interprets //IGNORE slightly more extensively than iconv, and so doesn't suffer from this bug. Sun Sep 7 15:26:25 BST 2008 Colin Watson [EMAIL PROTECTED] * src/manconv.c (try_iconv): Remove premature optimisation that sometimes caused us to write incomplete output. * src/man.c (add_manconv): Always use manconv even if iconv could theoretically do the job, as manconv has slightly more permissive behaviour that is generally more suitable for converting manual page source (Debian bug #498082). After this fix, you still have a warning: `aV' not defined, but that's a genuine problem in your pages rather than in either groff or man-db. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: lintian: false positive in manpages
Colin Watson dixit: Heh, you managed to find a case where it actually *was* a man-db bug after all! I did say almost never, I guess ... Happens ;-) This is triggered by your use of UTF-8 characters that aren't just recoded versions of ISO-8859-1 characters in comments at the top of the manual page. Ah, okay. The Debian Policy Manual documents the current situation: Due to limitations in current implementations, all characters in the manual page source should be representable in the usual legacy ^^ Interesting twist if this appears to comments as well. (But with your fix, I believe this won’t be necessary any more ☺) encoding for that language, even if the file is actually encoded in UTF-8. Safe alternative ways to write many characters outside that range may be found in groff_char(7). You can work around this bug by replacing those characters with some plain ASCII, perhaps something like this: -.\ * ` generates b-.\ * ' generates b-.\ * - generates b+.\ * ` generates U+2018 in groff, so use \` +.\ * ' generates U+2019 in groff, \' generates B4, so use \*(aq +.\ * - generates U+2010 in groff, \- generates U+2212, fixed in tmac/mdoc/doc-groff I think your mail arrived here in a broken state. After this fix, you still have a warning: `aV' not defined, but that's a genuine problem in your pages rather than in either groff or man-db. Interesting too. I will have to look at how GNU groff’s mdoc implementation defines the .Nx, .Ox c. macros then. (MirBSD uses ATT nroff (and offers GNU groff via ports) with the (a bugfixed) UCB mdoc implementation for both *roff processors, so that this issue has not appeared there yet.) Thanks for this quick fix and the coöperation! bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: lintian: false positive in manpages
On Sun, Sep 07, 2008 at 06:56:07PM +, Thorsten Glaser wrote: Colin Watson dixit: The Debian Policy Manual documents the current situation: Due to limitations in current implementations, all characters in the manual page source should be representable in the usual legacy ^^ Interesting twist if this appears to comments as well. (But with your fix, I believe this won’t be necessary any more ☺) Well, it literally does mean the whole file. But yes, it's a bit odd, and wasn't really intended to be that strict. I did consider stripping comments entirely before passing them on down the toolchain, but that would mean that line/byte numbers would be wrong, which could be confusing. -.\ * ` generates b-.\ * ' generates b-.\ * - generates b+.\ * ` generates U+2018 in groff, so use \` +.\ * ' generates U+2019 in groff, \' generates B4, so use \*(aq +.\ * - generates U+2010 in groff, \- generates U+2212, fixed in tmac/mdoc/doc-groff I think your mail arrived here in a broken state. It displays as intended here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498082 I suspect that either your mail user agent or something in your local mail delivery system is line-wrapping incorrectly. After this fix, you still have a warning: `aV' not defined, but that's a genuine problem in your pages rather than in either groff or man-db. Interesting too. I will have to look at how GNU groff’s mdoc implementation defines the .Nx, .Ox c. macros then. (MirBSD uses ATT nroff (and offers GNU groff via ports) with the (a bugfixed) UCB mdoc implementation for both *roff processors, so that this issue has not appeared there yet.) Right. I think .aV used to be part of the internal implementation of mdoc; docj.tmac still has it, commented as parse argument vector (recursive). As far as I can tell this was replaced by the doc-parse-args macro, probably in Werner Lemberg's complete rewrite of mdoc in March 2001. However, it wasn't obvious to me how to upgrade your macro. If you need help writing a replacement portable to both ATT troff and modern groff, the members of the [EMAIL PROTECTED] list are tremendously well-informed and are usually very helpful with such things. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: GNU mdoc vs UCB mdoc (was Re: Bug#498082: lintian: false positive in manpages)
Colin Watson dixit:
would mean that line/byte numbers would be wrong, which could be
confusing.
They are wrong anyway, as the macro packages count for byte numbers
too, at least in the iconv example. But still a point: we could just
wc the macro package first.
mdoc; docj.tmac still has it, commented as parse argument vector
(recursive). As far as I can tell this was replaced by the
doc-parse-args macro, probably in Werner Lemberg's complete rewrite of
mdoc in March 2001. However, it wasn't obvious to me how to upgrade your
macro.
Interesting… why a rewrite, I wonder. But yes, parse argument vector
recursively sounds about right. Maybe I can use something like this:
│.if \n(.g \{\
│.de aV
│.doc-parse-args \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
│..
│.\}
I think this use of a more than two character macro will be tolerated
by ATT nroff since it’s if’d out anyway.
The other option would be GNU groff mdoc tmac file upstream considering
to add back support for the aV macro…
bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in Notes on Programming in C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: GNU mdoc vs UCB mdoc (was Re: Bug#498082: lintian: false positive in manpages)
On Sun, Sep 07, 2008 at 07:57:44PM +, Thorsten Glaser wrote:
Colin Watson dixit:
would mean that line/byte numbers would be wrong, which could be
confusing.
They are wrong anyway, as the macro packages count for byte numbers
too, at least in the iconv example. But still a point: we could just
wc the macro package first.
Right now they're close enough to be useful, at least for me.
mdoc; docj.tmac still has it, commented as parse argument vector
(recursive). As far as I can tell this was replaced by the
doc-parse-args macro, probably in Werner Lemberg's complete rewrite of
mdoc in March 2001. However, it wasn't obvious to me how to upgrade your
macro.
Interesting… why a rewrite, I wonder.
You'd have to ask Werner. I assume he had a good reason; he doesn't
normally go in for rewrites for the sake of it, as far as I can see.
But yes, parse argument vector recursively sounds about right. Maybe I
can use something like this:
│.if \n(.g \{\
│.de aV
│.doc-parse-args \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
│..
│.\}
I think this use of a more than two character macro will be tolerated
by ATT nroff since it’s if’d out anyway.
The other option would be GNU groff mdoc tmac file upstream considering
to add back support for the aV macro…
This is beyond me; I recommend asking [EMAIL PROTECTED] for help here. I
don't know whether defining aV to doc-parse-args would be sensible or
not.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: lintian: false positive in manpages
Package: lintian Version: 1.24.2.1 Severity: normal W: mircpio: manpage-has-errors-from-man usr/share/man/man1/mircpio.1.gz list open at EOF! A .Bl directive has no matching .El I’ve got three manpages in mdoc(7) format with this error now. All of them are valid (at least I think so), but have nested lists: │ .Bl ... │ ... │ .Bl ... │ ... │ .El │ ... │ .El I think this triggers the manpage-has-errors-from-man bug falsely. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.20 Debian package development tools ii file4.25-1 Determines file type using magic ii gettext 0.17-3 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl1.1600-9 Time and date functions for Perl ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.2-2 on-line manual pager ii perl [libdigest-sha 5.10.0-13Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) pn libtext-template-perl none (no description available) ii man-db2.5.2-2on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: lintian: false positive in manpages
Thorsten Glaser [EMAIL PROTECTED] writes: W: mircpio: manpage-has-errors-from-man usr/share/man/man1/mircpio.1.gz list open at EOF! A .Bl directive has no matching .El I’ve got three manpages in mdoc(7) format with this error now. All of them are valid (at least I think so), but have nested lists: │ .Bl ... │ ... │ .Bl ... │ ... │ .El │ ... │ .El I think this triggers the manpage-has-errors-from-man bug falsely. The error message is coming from man --warnings. It's possible that it may have some sort of problem. Can you double-check first that you have the most current man-db package? If so, I'll transfer the bug there. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498082: lintian: false positive in manpages
reassign 498082 man-db thanks Russ Allbery dixit: The error message is coming from man --warnings. It's possible that it may have some sort of problem. Can you double-check first that you have the most current man-db package? If so, I'll transfer the bug there. Oh okay. Sure. ii man-db 2.5.2-2on-line manual pager Looks current according to packages.d.o. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
