Bug#450432: ... and even more bugs like this? - Debian

This is a discussion on Bug#450432: ... and even more bugs like this? - Debian ; Last week I've reported a bug in ifconfig(8) (as of net-tools 1.60-17.) The problem is in that the ifconfig.8 contains the following: --cut-- ..B ifconfig eth0:0 down .. Note: for every scope (i.e. same net with address/netmask combination) all aliases ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Bug#450432: ... and even more bugs like this?

  1. Bug#450432: ... and even more bugs like this?

    Last week I've reported a bug in ifconfig(8) (as of net-tools
    1.60-17.) The problem is in that the ifconfig.8 contains the
    following:

    --cut--
    ..B ifconfig eth0:0 down
    .. Note: for every scope (i.e. same net with address/netmask combination) all
    aliases are deleted, if you delete the first (primary).
    --cut--

    This is (I guess) intended to be rendered by Groff as:
    ``ifconfig ... in the bold face, then period (.), then Note:,
    ...'' However, it renders just as if there were no ``. Note:
    ...'' line at all. I guess, it happens because Groff interprets
    ``. Note:'' (or ``. Note''?) as a ``command'', and since it
    knows no definition for it, it ignores the entire line.

    The problem is that ifconfig.8 isn't the only file with such a
    misfeature!

    $ bash check-man-periods.sh /usr/share/man/man1/*.gz
    /usr/share/man/man1/gpg.1.gz:. This is only used when \fB--use-agent\fR has
    /usr/share/man/man1/ocamldoc.1.gz:. The file
    /usr/share/man/man1/rpost.1.gz:. If this form is used, any port number specified via the -N option
    /usr/share/man/man1/sfxtest.1.gz:. Higher values of mode are more verbose.
    ....
    /usr/share/man/man1/v.surf.rst.1grass.gz:. User can choose to output vector files \fItreefile\fR and \fIoverfile\fR
    ....
    $

    (Look below for check-man-periods.sh.)

    What I'm expected to do, then? (With respect to Debian BTS.) I
    believe, start filing multiple bug reports would be a bad idea
    (for me now.) May I suggest an explicit warning to be generated
    by Groff on unknown ``command'', so that lintian(1) will issue a
    warning on a malformed manual page, too? (Or a ``strict check''
    mode for Groff, to be used especially by lintian and alike?)

    And, out of curiosity, was the ``. Note:'' (and similar) ever
    rendered by Groff, and if it is, when the behaviour was changed?

    #!/bin/bash
    ### check-man-periods.sh --- Check man pages for ``period bugs'' -*- Sh -*-

    examine_1 () {
    local f="$1"
    local s='\([[:blank:]].*\)\?$'
    ## a rough approximation...
    ## FIXME: nor commas, nor backslashes are allowed in $1
    sed -e '/^[.][[:blank:]]/!d' \
    -e '/^[.][[:blank:]]\+[.[:digit:][]/d' \
    -e '/^[.][[:blank:]]\+\(B[IR]\?\|[IP]P\|SM\|\\["}]\)'"$s"'/d' \
    -e '/^[.][[:blank:]]\+\(ad\|br\|de\|ds\|el\|fi\)'"$s"'/d' \
    -e '/^[.][[:blank:]]\+\(ftr\?\|hy\|ie\|if\|in\|mso\|\)'"$s"'/d' \
    -e '/^[.][[:blank:]]\+\(n[efhrs]\|nop\|r[mr]\|t[im]\)'"$s"'/d' \
    -e '/^[.][[:blank:]]\+\(warn\|while\)'"$s"'/d' \
    -e "s,^,$f:,"
    }

    for f in "$@"; do
    case "$f" in
    (*.gz) zcat "$f" | examine_1 "$f" ;;
    (*) < "$f" examine_1 "$f" ;;
    esac
    done

    ### check-man-periods.sh ends here


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: Bug#450432: ... and even more bugs like this?

    Hi Ivan,

    great!

    Ivan Shmakov wrote:
    > $ bash check-man-periods.sh /usr/share/man/man1/*.gz


    Debian has lintian and linda to check for machine-detectable errors like
    this one. Maybe you could wirte the same test in perl/python and submit
    it as a whishlist item to the BTS for one of those packages.

    Kind regards

    T.
    --
    Thomas Viehmann, http://thomas.viehmann.net/


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Bug#450432: ... and even more bugs like this?

    Ivan Shmakov writes:

    > Last week I've reported a bug in ifconfig(8) (as of net-tools
    > 1.60-17.) The problem is in that the ifconfig.8 contains the
    > following:


    > --cut--
    > .B ifconfig eth0:0 down
    > . Note: for every scope (i.e. same net with address/netmask combination) all
    > aliases are deleted, if you delete the first (primary).
    > --cut--


    > This is (I guess) intended to be rendered by Groff as: ``ifconfig
    > ... in the bold face, then period (.), then Note:, ...'' However,
    > it renders just as if there were no ``. Note: ...'' line at all.
    > I guess, it happens because Groff interprets ``. Note:'' (or
    > ``. Note''?) as a ``command'', and since it knows no definition
    > for it, it ignores the entire line.


    Yeah, this is a common roff coding problem. That text should be written
    as:

    .BR "ifconfig eth0:0 down" .
    Note: ....

    or with the period escaped.

    In general, I wish that people would stop writing man pages directly in
    roff unless they really know roff. Some people do, and that's great, but
    most people really don't and it's not a trivial language. It has weird
    corner cases and gotchas. I know it well enough to have written various
    translators to roff, and I still use POD to write all my man pages and
    then convert them because doing it directly in roff is too error-prone.
    Those who prefer it can of course use DocBook instead.

    > What I'm expected to do, then? (With respect to Debian BTS.) I
    > believe, start filing multiple bug reports would be a bad idea
    > (for me now.)


    Well, they certainly are bugs, and I think filing those bugs after you
    verify that this is a problem and the period wasn't there for some other
    purpose (such as to create a comment line) is perfectly fine.

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: Bug#450432: ... and even more bugs like this?

    >>>>> Russ Allbery writes:

    [...]

    >> --cut--
    >> .B ifconfig eth0:0 down
    >> . Note: for every scope (i.e. same net with address/netmask combination) all
    >> aliases are deleted, if you delete the first (primary).
    >> --cut--


    [...]

    > Yeah, this is a common roff coding problem. That text should be
    > written as:


    > .BR "ifconfig eth0:0 down" .
    > Note: ....


    Yes, I've guessed that when I was submitting a patch for
    Bug#450432.

    > or with the period escaped.


    ... And this is the thing I haven't found how to do. Could you
    please show me that spell?

    [...]

    >> What I'm expected to do, then? (With respect to Debian BTS.) I
    >> believe, start filing multiple bug reports would be a bad idea (for
    >> me now.)


    > Well, they certainly are bugs, and I think filing those bugs after
    > you verify that this is a problem and the period wasn't there for
    > some other purpose (such as to create a comment line) is perfectly
    > fine.


    Isn't .\" the better way to go then?

    Since this issue could be checked with lintian, I think that
    sending a wishlist report on it is a better way. IIUC, once the
    check is in lintian, the bugs like this would be filed
    automatically?


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: Bug#450432: ... and even more bugs like this?

    >>>>> "TV" == Thomas Viehmann writes:

    [...]

    >> $ bash check-man-periods.sh /usr/share/man/man1/*.gz


    > Debian has lintian and linda to check for machine-detectable errors
    > like this one. Maybe you could wirte the same test in perl/python and
    > submit it as a whishlist item to the BTS for one of those packages.


    I still like the idea of implementing a check for unknown
    commands in Groff instead. A warning from Groff may be used to
    trigger a lintian warning, like how it's already done (check
    lintian/checks/manpages, Tag: manpage-has-errors-from-man.)

    I haven't written anything in Perl for the three years or so,
    but of course could give it a try.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: Bug#450432: ... and even more bugs like this?

    Ivan Shmakov writes:
    >>>>>> Russ Allbery writes:


    >> or with the period escaped.


    > ... And this is the thing I haven't found how to do. Could you
    > please show me that spell?


    \&. Note:

    \& is a null token that can be put at the beginning of a line to ensure
    that it's not interpreted as a roff command. .BR is better, in my
    opinion, since this introduces an extraneous space before the period.

    Another approach that also works is to stop using .B entirely and instead
    use font escapes:

    \fBifconfig eth0:0 down\fP.

    This is what Pod::Man does since constructing the .BR lines is complex and
    can run into short arbitrary limits in some roff implementations.

    > Isn't .\" the better way to go then?


    Yes, but you never can tell what people do.

    > Since this issue could be checked with lintian, I think that
    > sending a wishlist report on it is a better way. IIUC, once the
    > check is in lintian, the bugs like this would be filed
    > automatically?


    No, lintian doesn't file bugs. Someone still has to go file the bugs,
    even if lintian is used to do the check.

    This is a minor bug, not a wishlist bug, IMO. Unless you meant the bug on
    lintian. (If you meant the bug against lintian, including a patch to do
    this check would be lovely.)

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Re: Bug#450432: ... and even more bugs like this?

    >>>>> Russ Allbery writes:
    >>>>> Ivan Shmakov writes:
    >>>>> Russ Allbery writes:


    >>> or with the period escaped.


    >> ... And this is the thing I haven't found how to do. Could you
    >> please show me that spell?


    > \&. Note:


    > \& is a null token that can be put at the beginning of a line to
    > ensure that it's not interpreted as a roff command. .BR is better,
    > in my opinion, since this introduces an extraneous space before the
    > period.


    ACK. Thanks for that.

    > Another approach that also works is to stop using .B entirely and
    > instead use font escapes:


    > \fBifconfig eth0:0 down\fP.


    > This is what Pod::Man does since constructing the .BR lines is
    > complex and can run into short arbitrary limits in some roff
    > implementations.


    Well, looks like so, but I see a problem with the legacy
    manpages that ``miss their parts.''

    >> Isn't .\" the better way to go then?


    > Yes, but you never can tell what people do.


    A lintian check. To remind of a bad practice.

    >> Since this issue could be checked with lintian, I think that sending
    >> a wishlist report on it is a better way. IIUC, once the check is in
    >> lintian, the bugs like this would be filed automatically?


    > No, lintian doesn't file bugs. Someone still has to go file the
    > bugs, even if lintian is used to do the check.


    Lintian documentation reads:

    --cut: /usr/share/doc/lintian/lintian.html/ch1.html--
    3. Please DO NOT use Lintian to file bug reports (neither single ones
    nor mass bug reports). This is done by the authors of Lintian
    already and duplication of efforts and bug reports should be
    avoided!
    --cut: /usr/share/doc/lintian/lintian.html/ch1.html--

    Is this bit out of date?

    > This is a minor bug, not a wishlist bug, IMO. Unless you meant the
    > bug on lintian.


    Yes, I've meant the latter.

    > (If you meant the bug against lintian, including a patch to do this
    > check would be lovely.)


    I'll start working on it soon.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: Bug#450432: ... and even more bugs like this?

    On Tue, Nov 13, 2007 at 01:44:23AM +0600, Ivan Shmakov wrote:
    > Last week I've reported a bug in ifconfig(8) (as of net-tools
    > 1.60-17.) The problem is in that the ifconfig.8 contains the
    > following:
    >
    > --cut--
    > .B ifconfig eth0:0 down
    > . Note: for every scope (i.e. same net with address/netmask combination) all
    > aliases are deleted, if you delete the first (primary).
    > --cut--


    You may also want to check lines starting by a single quote (').

    Good luck,
    --
    Nekral


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: Bug#450432: ... and even more bugs like this?

    Ivan Shmakov writes:
    >>>>>> Russ Allbery writes:


    > > No, lintian doesn't file bugs. Someone still has to go file the
    > > bugs, even if lintian is used to do the check.


    > Lintian documentation reads:


    > --cut: /usr/share/doc/lintian/lintian.html/ch1.html--
    > 3. Please DO NOT use Lintian to file bug reports (neither single ones
    > nor mass bug reports). This is done by the authors of Lintian
    > already and duplication of efforts and bug reports should be
    > avoided!
    > --cut: /usr/share/doc/lintian/lintian.html/ch1.html--


    > Is this bit out of date?


    Yes. I should fix that.

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: Bug#450432: ... and even more bugs like this?

    On Tue, Nov 13, 2007 at 01:44:23AM +0600, Ivan Shmakov wrote:
    > What I'm expected to do, then? (With respect to Debian BTS.) I
    > believe, start filing multiple bug reports would be a bad idea
    > (for me now.) May I suggest an explicit warning to be generated
    > by Groff on unknown ``command'', so that lintian(1) will issue a
    > warning on a malformed manual page, too? (Or a ``strict check''
    > mode for Groff, to be used especially by lintian and alike?)


    The -wmac option to groff will emit a warning for this mistake. See the
    "Warnings" node in 'info groff'.

    It's not especially easy right now to make Lintian pass this, since man
    doesn't expose an interface to add extra options to groff. I'll file a
    bug for my own reference and see about adding one.

    > And, out of curiosity, was the ``. Note:'' (and similar) ever
    > rendered by Groff, and if it is, when the behaviour was changed?


    No, it wasn't. As others have said, this is a moderately common mistake.
    I usually fix it by putting \& (zero-width space) at the start of the
    line, and indeed that's what groff's info documentation recommends.

    > #!/bin/bash
    > ### check-man-periods.sh --- Check man pages for ``period bugs'' -*- Sh -*-


    I very much recommend against any attempt to parse *roff in shell, FWIW.
    Even man-db's flex parser is ultimately doomed to failure and should
    probably be replaced with something cunning involving custom groff
    macros at some point.

    Cheers,

    --
    Colin Watson [cjwatson@debian.org]


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Re: Bug#450432: ... and even more bugs like this?

    >>>>> "CW" == Colin Watson writes:

    >> What I'm expected to do, then? (With respect to Debian BTS.) I
    >> believe, start filing multiple bug reports would be a bad idea (for
    >> me now.) May I suggest an explicit warning to be generated by Groff
    >> on unknown ``command'', so that lintian(1) will issue a warning on a
    >> malformed manual page, too? (Or a ``strict check'' mode for Groff,
    >> to be used especially by lintian and alike?)


    > The -wmac option to groff will emit a warning for this mistake.


    Today, I've found it, too.

    > See the "Warnings" node in 'info groff'.


    ... I've done it the hard way -- looked through the source.

    > It's not especially easy right now to make Lintian pass this, since
    > man doesn't expose an interface to add extra options to groff.


    And here goes another hack:

    $ cat man.local
    ..warn 512
    ..mso /usr/share/groff/site-tmac/man.local
    $ cat mdoc.local
    ..warn 512
    ..mso /usr/share/groff/site-tmac/mdoc.local
    $ LC_ALL=C GROFF_TMAC_PATH="$PWD" man ifconfig > /dev/null
    Reformatting ifconfig(8), please wait...
    /tmp/zman6d1c0O:63: warning: `Note:' not defined
    $ LC_ALL=C GROFF_TMAC_PATH="$PWD" \
    man gpg ocamldoc rpost sfxtest v.surf.rst > /dev/null
    Reformatting gpg(1), please wait...
    /tmp/zmanqItyHp:153: warning: `-'' not defined
    /tmp/zmanqItyHp:1449: warning: `GPG_AGENT_INFO'' not defined
    /tmp/zmanqItyHp:1450: warning: `This' not defined
    Reformatting ocamldoc(1), please wait...
    /tmp/zmanGibSgq:109: warning: `The' not defined
    Reformatting rpost(1), please wait...
    /tmp/zmanq2L13v:96: warning: `If' not defined
    Reformatting sfxtest(1), please wait...
    /tmp/zman8dcg6e:87: warning: `Higher' not defined
    Reformatting v.surf.rst(1grass), please wait...
    /tmp/zmaneiehzB:130: warning: `User' not defined
    $

    How about adding this one to lintian?

    > I'll file a bug for my own reference and see about adding one.


    Yes, please.

    [...]

    >> #!/bin/bash
    >> ### check-man-periods.sh --- Check man pages for ``period bugs'' -*- Sh -*-


    > I very much recommend against any attempt to parse *roff in shell,
    > FWIW. Even man-db's flex parser is ultimately doomed to failure and
    > should probably be replaced with something cunning involving custom
    > groff macros at some point.


    Agreed upon that.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Re: Bug#450432: ... and even more bugs like this?

    >>>>> "IS" == Ivan Shmakov writes:
    >>>>> "CW" == Colin Watson writes:


    [...]

    >> The -wmac option to groff will emit a warning for this mistake.


    [...]

    >> It's not especially easy right now to make Lintian pass this, since
    >> man doesn't expose an interface to add extra options to groff.


    IS> And here goes another hack:

    > $ cat man.local
    > .warn 512
    > .mso /usr/share/groff/site-tmac/man.local
    > $ cat mdoc.local
    > .warn 512
    > .mso /usr/share/groff/site-tmac/mdoc.local
    > $ LC_ALL=C GROFF_TMAC_PATH="$PWD" man ifconfig > /dev/null
    > Reformatting ifconfig(8), please wait...
    > /tmp/zman6d1c0O:63: warning: `Note:' not defined
    > $


    [...]

    IS> How about adding this one to lintian?

    So, I've written a (yet another) crude hack and going to file a
    wishlist bug against lintian.

    A run on some of the `.deb's from Debian 4.0 *r0* (somewhat a
    random and, what's worse, somewhat outdated set):

    $ lintian --root="$PWD"/../lintian-root-2007-11-15 \
    *.deb \
    | grep -F has-errors
    W: libdirectfb-dev: manpage-has-errors-from-man usr/share/man/man1/directfb-config.1.gz 24: warning: `l' not defined
    W: dvidvi: manpage-has-errors-from-man usr/share/man/man1/a5booklet.1.gz 9: warning: `IX' not defined

    The lines like this seems to me somewhat bogus. I guess, `.IX'
    allows one to specify an index item, and since `man' doesn't
    provide any indices, this macro is left undefined, and thus
    ignored by `man' (and it's okay.)

    A simple-minded approach to suppress these warnings would be
    something like:

    ..de IX
    ..end

    but I believe that such a definition belongs to the macro
    package `man' uses.

    W: dvgrab: manpage-has-errors-from-man usr/share/man/de/man1/dvgrab.1.gz 308: warning: `..' not defined
    W: dput: manpage-has-errors-from-man usr/share/man/man1/dput.1.gz 92: warning: `P.SH' not defined
    W: dpkg-dev: manpage-has-errors-from-man usr/share/man/man1/dpkg-checkbuilddeps.1.gz 27: warning: `UR' not defined
    W: dpkg-dev: manpage-has-errors-from-man usr/share/man/man1/dpkg-architecture.1.gz 104: warning: `C`' not defined

    Something like the above with these two?..

    W: dpkg-dev: manpage-has-errors-from-man usr/share/man/fr/man1/dpkg-checkbuilddeps.1.gz 34: warning: `UR' not defined
    W: dpkg-dev: manpage-has-errors-from-man usr/share/man/fr/man1/dpkg-architecture.1.gz 111: warning: `C`' not defined
    W: dpkg-dev: manpage-has-errors-from-man usr/share/man/ja/man1/dpkg-checkbuilddeps.1.gz 29: warning: `UR' not defined
    W: dpkg-dev: manpage-has-errors-from-man usr/share/man/de/man1/dpkg-checkbuilddeps.1.gz 33: warning: `UR' not defined
    W: dpkg-dev: manpage-has-errors-from-man usr/share/man/de/man1/dpkg-architecture.1.gz 110: warning: `C`' not defined
    W: dpkg-dev: manpage-has-errors-from-man usr/share/man/ru/man1/dpkg-checkbuilddeps.1.gz 33: warning: `UR' not defined
    W: dpkg: manpage-has-errors-from-man usr/share/man/man1/dpkg-query.1.gz 51: warning: `T' not defined

    ... And with this one, too? Below there're mentions of `DA',
    `DS', `E', `LO' and `TR' as well.

    W: dpkg: manpage-has-errors-from-man usr/share/man/fr/man1/dpkg-query.1.gz 42: warning: `T' not defined
    W: dpkg: manpage-has-errors-from-man usr/share/man/fr/man8/dpkg-statoverride.8.gz 91: warning: `UR' not defined
    W: dpkg: manpage-has-errors-from-man usr/share/man/ja/man1/dpkg-query.1.gz 39: warning: `T' not defined
    W: dpkg: manpage-has-errors-from-man usr/share/man/ja/man8/dpkg-statoverride.8.gz 75: warning: `UR' not defined
    W: dpkg: manpage-has-errors-from-man usr/share/man/de/man8/dpkg-statoverride.8.gz 92: warning: `UR' not defined
    W: dpkg: manpage-has-errors-from-man usr/share/man/man8/dpkg-statoverride.8.gz 90: warning: `UR' not defined
    W: dpkg: manpage-has-errors-from-man usr/share/man/sv/man1/dpkg-query.1.gz 41: warning: `T' not defined
    W: dpkg: manpage-has-errors-from-man usr/share/man/pl/man1/dpkg-query.1.gz 43: warning: `T' not defined
    W: dpkg: manpage-has-errors-from-man usr/share/man/pl/man8/dpkg-statoverride.8.gz 88: warning: `UR' not defined
    W: docbook-utils: manpage-has-errors-from-man usr/share/man/man7/frontend-spec.7.gz 37: warning: `..)' not defined
    W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man1/instant.1.gz 81: warning: `E' not defined
    W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man5/transpec.5.gz 467: warning: `DS' not defined
    W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man3/regexp.3.gz 2: warning: `DA' not defined
    W: dirmngr: manpage-has-errors-from-man usr/share/man/man1/dirmngr.1.gz 245: warning: `#'' not defined
    W: dirmngr: manpage-has-errors-from-man usr/share/man/man1/dirmngr-client.1.gz 86: warning: `-vv'' not defined
    W: dialog: manpage-has-errors-from-man usr/share/man/man3/dialog.3.gz 1494: warning: `..' not defined
    W: dhcp3-common: manpage-has-errors-from-man usr/share/man/man5/dhcp-options.5.gz 1136: warning: `.'' not defined
    W: dh-make: manpage-has-errors-from-man usr/share/man/man8/dh_make.8.gz 74: warning: `If' not defined
    W: debootstrap: manpage-has-errors-from-man usr/share/man/man8/debootstrap.8.gz `R' is a string (producing the registered sign), not a macro.
    W: ddd: manpage-has-errors-from-man usr/share/man/man1/ddd.1.gz 34: warning: `PSPIC' not defined
    W: dctrl-tools: manpage-has-errors-from-man usr/share/man/man1/tbl-dctrl.1.gz 115: warning: `Bi' not defined
    W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dcfujiturn.1.gz 7: warning: `LO' not defined
    W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dccleancrw.1.gz 7: warning: `LO' not defined
    W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dcraw.1.gz 13: warning: `LO' not defined
    W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dcparse.1.gz 7: warning: `LO' not defined
    W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dcfujigreen.1.gz 7: warning: `LO' not defined
    W: dcc-common: manpage-has-errors-from-man usr/share/man/man8/dcc.8.gz Empty input line #820
    W: dcc-client: manpage-has-errors-from-man usr/share/man/man8/dccifd.8.gz 688: warning: `"' not defined
    W: dbs: manpage-has-errors-from-man usr/share/man/man1/dbs-edit-patch.1.gz 91: warning: `UR' not defined
    W: dbs: manpage-has-errors-from-man usr/share/man/man7/dbs.7.gz 320: warning: `UR' not defined
    W: dbconfig-common: manpage-has-errors-from-man usr/share/man/man1/dbconfig-load-include.1.gz 8: warning: `Xc' not defined
    W: dbconfig-common: manpage-has-errors-from-man usr/share/man/man1/dbconfig-generate-include.1.gz 8: warning: `Xc' not defined
    W: db4.4-util: manpage-has-errors-from-man usr/share/man/man1/db4.4_checkpoint.1.gz 27: warning: `TR' not defined
    W: db4.4-util: manpage-has-errors-from-man usr/share/man/man1/db4.4_deadlock.1.gz 50: warning: `TR' not defined
    W: db4.4-util: manpage-has-errors-from-man usr/share/man/man1/db4.4_load.1.gz 127: warning: `TR' not defined
    W: db4.3-util: manpage-has-errors-from-man usr/share/man/man1/db4.3_deadlock.1.gz 50: warning: `TR' not defined
    W: db4.3-util: manpage-has-errors-from-man usr/share/man/man1/db4.3_load.1.gz 127: warning: `TR' not defined
    W: db4.3-util: manpage-has-errors-from-man usr/share/man/man1/db4.3_checkpoint.1.gz 27: warning: `TR' not defined
    W: dasher: manpage-has-errors-from-man usr/share/man/man1/dasher.1.gz 112: warning: `B--with-a11y.' not defined
    $

    [...]


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  13. Bug#377392: Bug#450432: ... and even more bugs like this?

    In a recent thread in debian-devel, it was suggested that
    lintian could call man(1) in such a way that the groff(1),
    called by `man', will emit warnings for every undefined macro,
    which is useful in catching the bugs like this:

    ..B foo
    .. Note: ...

    Below is the patch that implements the suggestion. Since `man'
    doesn't allow the `-wmac' option to be passed to `groff' by any
    other means, I've had to introduce two new files -- `mdoc.local'
    and `man.local' (to override the files in groff/site-tmac/), and
    the ${LINTIAN_ROOT}/groff-hack directory to hold them.

    --- lintian-1.23.36/checks/manpages 2007-10-16 10:40:04.000000000 +0700
    +++ lintian-1.23.36-groff-hack/checks/manpages 2007-11-16 00:16:11.000000000 +0600
    @@ -253,10 +253,12 @@
    # processed properly. (Yes, there are man pages that include other
    # pages with .so but aren't simple links; rbash, for instance.)
    my $cmd;
    + my $groff_dir = "$ENV{'LINTIAN_ROOT'}/groff-hack/";
    + my $man_cmd = "GROFF_TMAC_PATH='$groff_dir' man -l";
    if ($file =~ m,^(.*)/(man\d/.*)$,) {
    - $cmd = "cd unpacked/\Q$1\E && man -l \Q$2\E";
    + $cmd = ("cd unpacked/\Q$1\E && $man_cmd \Q$2\E");
    } else {
    - $cmd = "man -l unpacked/\Q$file\E";
    + $cmd = "$man_cmd unpacked/\Q$file\E";
    }
    my $pid = open MANERRS, '-|';
    if (not defined $pid) {
    diff -drHuN --exclude='*~' lintian-1.23.36/debian/rules lintian-1.23.36-groff-hack/debian/rules
    --- lintian-1.23.36/debian/rules 2006-11-19 07:11:32.000000000 +0600
    +++ lintian-1.23.36-groff-hack/debian/rules 2007-11-16 00:11:37.000000000 +0600
    @@ -45,7 +45,7 @@
    install -m 755 frontend/lintian-info $(tmp)/usr/bin/
    # library files
    @echo .... install library files ....
    - for d in checks collection lib unpack; do \
    + for d in checks collection lib unpack groff-hacks; do \
    install -d $(usl)/$$d; \
    find $$d -type f ! -path '*/CVS/*' ! -path '*/.svn/*' \
    | xargs -iFILE cp -p FILE $(usl)/$$d/; \
    diff -drHuN --exclude='*~' lintian-1.23.36/groff-hacks/man.local lintian-1.23.36-groff-hack/groff-hacks/man.local
    --- lintian-1.23.36/groff-hacks/man.local 1970-01-01 07:00:00.000000000 +0700
    +++ lintian-1.23.36-groff-hack/groff-hacks/man.local 2007-11-14 23:09:47.000000000 +0600
    @@ -0,0 +1,2 @@
    +.warn 512
    +.mso /usr/share/groff/site-tmac/man.local
    diff -drHuN --exclude='*~' lintian-1.23.36/groff-hacks/mdoc.local lintian-1.23.36-groff-hack/groff-hacks/mdoc.local
    --- lintian-1.23.36/groff-hacks/mdoc.local 1970-01-01 07:00:00.000000000 +0700
    +++ lintian-1.23.36-groff-hack/groff-hacks/mdoc.local 2007-11-14 23:09:48.000000000 +0600
    @@ -0,0 +1,2 @@
    +.warn 512
    +.mso /usr/share/groff/site-tmac/mdoc.local




    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  14. Re: Bug#450432: ... and even more bugs like this?

    On Fri, Nov 16, 2007 at 12:05:39AM +0600, Ivan Shmakov wrote:
    > $ lintian --root="$PWD"/../lintian-root-2007-11-15 \
    > *.deb \
    > | grep -F has-errors
    > W: libdirectfb-dev: manpage-has-errors-from-man usr/share/man/man1/directfb-config.1.gz 24: warning: `l' not defined
    > W: dvidvi: manpage-has-errors-from-man usr/share/man/man1/a5booklet.1.gz 9: warning: `IX' not defined
    >
    > The lines like this seems to me somewhat bogus. I guess, `.IX'
    > allows one to specify an index item, and since `man' doesn't
    > provide any indices, this macro is left undefined, and thus
    > ignored by `man' (and it's okay.)


    Perhaps some of these should be explicitly ignored by lintian, as
    they're problems with popular generator tools and it really doesn't do
    anyone any good to report them in lintian; they should be filed as bugs
    against the generators instead. (Unfortunately, you might have to parse
    groff's warning text in order to ignore particular cases.)

    ..IX is probably from pod2man, which does:

    .\" If the F register is turned on, we'll generate index entries on stderr for
    .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
    .\" entries marked with X<> in POD. Of course, you'll have to process the
    .\" output yourself in some meaningful fashion.
    .if \nF \{\
    . de IX
    . tm Index:\\$1\t\\n%\t"\\$2"
    ..
    . nr % 0
    . rr F
    .\}

    Russ, perhaps this should be something like this instead to suppress the
    warning?

    .\" If the F register is turned on, we'll generate index entries on stderr for
    .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
    .\" entries marked with X<> in POD. Of course, you'll have to process the
    .\" output yourself in some meaningful fashion.
    .ie \nF \{\
    . de IX
    . tm Index:\\$1\t\\n%\t"\\$2"
    ..
    . nr % 0
    . rr F
    .\}
    .el \{\
    . de IX
    ..
    .\}

    > A simple-minded approach to suppress these warnings would be
    > something like:
    >
    > .de IX
    > .end
    >
    > but I believe that such a definition belongs to the macro
    > package `man' uses.


    man doesn't use any macro package of its own; it's all in groff. I'd
    like to keep it that way if possible. Anyhow, since this is a macro
    defined by a particular man page generator, it's not appropriate to
    handle it in either man or groff.

    > W: dvgrab: manpage-has-errors-from-man usr/share/man/de/man1/dvgrab.1.gz 308: warning: `..' not defined


    Looks like a botched attempt to define a macro. (.. is what you use to
    terminate a macro definition.)

    > W: dput: manpage-has-errors-from-man usr/share/man/man1/dput.1.gz 92: warning: `P.SH' not defined


    An obvious typo.

    > W: dpkg-dev: manpage-has-errors-from-man usr/share/man/man1/dpkg-checkbuilddeps.1.gz 27: warning: `UR' not defined


    ..UR used to be what you used to mark up URLs; man(7) recommended it
    until not that long ago.

    > W: dpkg-dev: manpage-has-errors-from-man usr/share/man/man1/dpkg-architecture.1.gz 104: warning: `C`' not defined


    I'm not entirely sure what all this line noise is trying to achieve.
    Looks to me like stuff like \f(CW\*(C`\-c\*(C' should just be \-c; aside
    from the undefined strings, why should just the option be constant-width
    and not the rest of the example command line?

    > W: dpkg: manpage-has-errors-from-man usr/share/man/man1/dpkg-query.1.gz 51: warning: `T' not defined


    I think .T was perhaps meant to be .TP.

    > W: docbook-utils: manpage-has-errors-from-man usr/share/man/man7/frontend-spec.7.gz 37: warning: `..)' not defined


    groff usage error; the line should read:

    \&...)

    .... or else the "...)" should be wrapped onto the previous line.

    > W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man1/instant.1.gz 81: warning: `E' not defined


    Firstly, I think \*EM was probably supposed to be \*(EM. Secondly,
    there's no such string defined, and perhaps \(em is what they really
    meant.

    > W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man5/transpec.5.gz 467: warning: `DS' not defined


    Err. This looks like an attempt to use ms macros, maybe? .RS and .RE
    would be the appropriate equivalents in the man macros, if I understand
    the intention correctly.

    > W: docbook-to-man: manpage-has-errors-from-man usr/share/man/man3/regexp.3.gz 2: warning: `DA' not defined


    Perhaps this is how you specify dates in some old version of the man
    macros? The date is conventionally the third argument to .TH nowadays.

    At any rate, docbook-to-man has no business shipping this manual page at
    all, and it should simply be removed.

    > W: dirmngr: manpage-has-errors-from-man usr/share/man/man1/dirmngr.1.gz 245: warning: `#'' not defined
    > W: dirmngr: manpage-has-errors-from-man usr/share/man/man1/dirmngr-client.1.gz 86: warning: `-vv'' not defined


    I don't have this installed, but they look like typos.

    > W: dialog: manpage-has-errors-from-man usr/share/man/man3/dialog.3.gz 1494: warning: `..' not defined


    Maybe another botched attempt to define a macro?

    > W: dhcp3-common: manpage-has-errors-from-man usr/share/man/man5/dhcp-options.5.gz 1136: warning: `.'' not defined


    The line begins like this:

    '.' character

    .... and should instead begin:

    \&'.' character

    (' is groff's default no-break control character.)

    > W: dh-make: manpage-has-errors-from-man usr/share/man/man8/dh_make.8.gz 74: warning: `If' not defined


    Typo; the leading ". " should just be removed.

    > W: debootstrap: manpage-has-errors-from-man usr/share/man/man8/debootstrap.8.gz `R' is a string (producing the registered sign), not a macro.


    An error, fixed in debootstrap 1.0.0.

    > W: ddd: manpage-has-errors-from-man usr/share/man/man1/ddd.1.gz 34: warning: `PSPIC' not defined


    This is sort of odd; that macro is defined in cases where the output
    device is capable of drawing pictures using pic. I think it would be
    best to ignore this one, although the warning could be suppressed like
    this:

    .if d PSPIC .PSPIC /tmp/buildd/ddd-3.3.11/./ddd/PICS/dddlogo.eps 10cm

    > W: dctrl-tools: manpage-has-errors-from-man usr/share/man/man1/tbl-dctrl.1.gz 115: warning: `Bi' not defined


    Typo for .BI.

    > W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dcfujiturn.1.gz 7: warning: `LO' not defined
    > W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dccleancrw.1.gz 7: warning: `LO' not defined
    > W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dcraw.1.gz 13: warning: `LO' not defined
    > W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dcparse.1.gz 7: warning: `LO' not defined
    > W: dcraw: manpage-has-errors-from-man usr/share/man/man1/dcfujigreen.1.gz 7: warning: `LO' not defined


    I only know of .LO in the mm macros, but 1 isn't a valid argument to
    even those so I don't know what this is meant to be. It could be removed
    without losing anything.

    > W: dcc-common: manpage-has-errors-from-man usr/share/man/man8/dcc.8.gz Empty input line #820


    Seems to be fixed. (Disallowing empty input lines is specific to the
    mdoc macros.)

    > W: dcc-client: manpage-has-errors-from-man usr/share/man/man8/dccifd.8.gz 688: warning: `"' not defined


    It's in dcc-server now. It looks like these were meant to be .\" (i.e.
    comments).

    > W: dbconfig-common: manpage-has-errors-from-man usr/share/man/man1/dbconfig-load-include.1.gz 8: warning: `Xc' not defined
    > W: dbconfig-common: manpage-has-errors-from-man usr/share/man/man1/dbconfig-generate-include.1.gz 8: warning: `Xc' not defined


    I only know of .Xc in mdoc, and this doesn't look like how you'd use it
    there. What it's doing here is anyone's guess. I'd remove it.

    > W: db4.4-util: manpage-has-errors-from-man usr/share/man/man1/db4.4_checkpoint.1.gz 27: warning: `TR' not defined
    > W: db4.4-util: manpage-has-errors-from-man usr/share/man/man1/db4.4_deadlock.1.gz 50: warning: `TR' not defined
    > W: db4.4-util: manpage-has-errors-from-man usr/share/man/man1/db4.4_load.1.gz 127: warning: `TR' not defined
    > W: db4.3-util: manpage-has-errors-from-man usr/share/man/man1/db4.3_deadlock.1.gz 50: warning: `TR' not defined
    > W: db4.3-util: manpage-has-errors-from-man usr/share/man/man1/db4.3_load.1.gz 127: warning: `TR' not defined
    > W: db4.3-util: manpage-has-errors-from-man usr/share/man/man1/db4.3_checkpoint.1.gz 27: warning: `TR' not defined


    This looks like a typo for .TP, to set up an indented paragraph.

    > W: dasher: manpage-has-errors-from-man usr/share/man/man1/dasher.1.gz 112: warning: `B--with-a11y.' not defined


    Missing space after .B.

    Cheers,

    --
    Colin Watson [cjwatson@debian.org]


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Re: Bug#377392: Bug#450432: ... and even more bugs like this?

    Colin Watson writes:

    > .IX is probably from pod2man, which does:


    > .\" If the F register is turned on, we'll generate index entries on stderr for
    > .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
    > .\" entries marked with X<> in POD. Of course, you'll have to process the
    > .\" output yourself in some meaningful fashion.
    > .if \nF \{\
    > . de IX
    > . tm Index:\\$1\t\\n%\t"\\$2"
    > ..
    > . nr % 0
    > . rr F
    > .\}


    > Russ, perhaps this should be something like this instead to suppress the
    > warning?


    > .\" If the F register is turned on, we'll generate index entries on stderr for
    > .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
    > .\" entries marked with X<> in POD. Of course, you'll have to process the
    > .\" output yourself in some meaningful fashion.
    > .ie \nF \{\
    > . de IX
    > . tm Index:\\$1\t\\n%\t"\\$2"
    > ..
    > . nr % 0
    > . rr F
    > .\}
    > .el \{\
    > . de IX
    > ..
    > .\}


    Sure, that seems reasonable.

    >> W: dpkg-dev: manpage-has-errors-from-man usr/share/man/man1/dpkg-architecture.1.gz 104: warning: `C`' not defined


    > I'm not entirely sure what all this line noise is trying to achieve.
    > Looks to me like stuff like \f(CW\*(C`\-c\*(C' should just be \-c;


    It's intentional in general. I don't know why it's not defined, though.
    \f(CW sets a fixed-width font, and \*(C` and \*(C' add "" when fonts
    aren't supported but suppress the quotes when fonts are supported.
    pod2man has done this for eons.

    I haven't looked at this particular usage, but there are places where this
    is exactly the desired markup.

    Maybe there's some missing logic for defining empty strings?

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  16. Re: Bug#377392: Bug#450432: ... and even more bugs like this?

    On Sat, Nov 17, 2007 at 06:50:18PM -0800, Russ Allbery wrote:
    > Colin Watson writes:
    > >> W: dpkg-dev: manpage-has-errors-from-man usr/share/man/man1/dpkg-architecture.1.gz 104: warning: `C`' not defined

    >
    > > I'm not entirely sure what all this line noise is trying to achieve.
    > > Looks to me like stuff like \f(CW\*(C`\-c\*(C' should just be \-c;

    >
    > It's intentional in general. I don't know why it's not defined, though.
    > \f(CW sets a fixed-width font, and \*(C` and \*(C' add "" when fonts
    > aren't supported but suppress the quotes when fonts are supported.
    > pod2man has done this for eons.


    In pod2man's case, it's almost fine. I think it would be helpful if it
    ..ds'ed C` and C' to the empty string in the troff branch, though.

    However, dpkg-architecture.1 isn't a pod2man-generated page, and it
    seems to have cribbed the use of these strings without also cribbing
    their definitions. In this case, I don't think quotes would be desirable
    anyway - the context is:

    CC=i386\-gnu\-gcc dpkg\-architecture \f(CW\*(C`\-c\*(C'\fR debian/rules build

    eval \`dpkg\-architecture \f(CW\*(C`\-u\*(C'\fR\`

    One problem that seems to crop up a lot with inexperienced *roff users
    is that they crib from other example pages without understanding which
    facilities are effectively built into the language and which are
    provided by bits at the top of the page. I've tried to provide examples
    in /usr/share/doc/man-db/examples/ which should be good enough for many
    people.

    Personally I like to use the mdoc macros, which form a logical markup
    language rather than a physical markup language, so you don't spend time
    mucking about with font selections and can just say "this is a flag" or
    "this is a program argument" or whatever instead. However, I think I
    would echo Russ' recommendation to use POD if you don't know *roff well
    and just want to write a manual page without the formatting getting in
    your way.

    Cheers,

    --
    Colin Watson [cjwatson@debian.org]


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  17. Re: Bug#450432: ... and even more bugs like this?

    >>>>> Colin Watson writes:

    [...]

    >> W: libdirectfb-dev: manpage-has-errors-from-man usr/share/man/man1/directfb-config.1.gz 24: warning: `l' not defined
    >> W: dvidvi: manpage-has-errors-from-man usr/share/man/man1/a5booklet.1.gz 9: warning: `IX' not defined


    >> The lines like this seems to me somewhat bogus. I guess, `.IX'
    >> allows one to specify an index item, and since `man' doesn't provide
    >> any indices, this macro is left undefined, and thus ignored by `man'
    >> (and it's okay.)


    > Perhaps some of these should be explicitly ignored by lintian, as
    > they're problems with popular generator tools and it really doesn't
    > do anyone any good to report them in lintian; they should be filed as
    > bugs against the generators instead.


    ACK.

    > (Unfortunately, you might have to parse groff's warning text in order
    > to ignore particular cases.)


    I'm not familiar with Groff at all... Does it allow later `.de'
    to override the former?..

    > .IX is probably from pod2man, which does:


    [...]

    > Russ, perhaps this should be something like this instead to suppress
    > the warning?


    [...]

    >> A simple-minded approach to suppress these warnings would be
    >> something like:


    >> .de IX
    >> .end


    ... And if it does, this definition just could be put into
    lintian/groff-hack/{mdoc,man}.local, effectively suppressing the
    Groff warnings.

    >> but I believe that such a definition belongs to the macro package
    >> `man' uses.


    > man doesn't use any macro package of its own; it's all in groff. I'd
    > like to keep it that way if possible. Anyhow, since this is a macro
    > defined by a particular man page generator, it's not appropriate to
    > handle it in either man or groff.


    ACK.

    >> W: dvgrab: manpage-has-errors-from-man usr/share/man/de/man1/dvgrab.1.gz 308: warning: `..' not defined


    > Looks like a botched attempt to define a macro. (.. is what you use
    > to terminate a macro definition.)


    Looks more like a comment from the generator:

    305 Sections, no Front\-Cover Texts and no Back\-Cover Texts. A copy
    306 of the license can be found under
    307 \fB/usr/share/common\-licenses/FDL\fP.
    308 ...\" created by instant / docbook\-to\-man, Wed 13 Dec 2000, 17:30

    [...]

    >> W: dpkg-dev: manpage-has-errors-from-man usr/share/man/man1/dpkg-checkbuilddeps.1.gz 27: warning: `UR' not defined


    > .UR used to be what you used to mark up URLs; man(7) recommended it
    > until not that long ago.


    What to use instead?

    [...]

    >> W: dirmngr: manpage-has-errors-from-man usr/share/man/man1/dirmngr.1.gz 245: warning: `#'' not defined


    244 Lines starting with a
    245 '#'
    246 are comments.

    >> W: dirmngr: manpage-has-errors-from-man usr/share/man/man1/dirmngr-client.1.gz 86: warning: `-vv'' not defined


    85 verbose commands to \fBdirmngr\fR, such as
    86 '-vv'
    87 .

    > I don't have this installed, but they look like typos.


    Some misused quotes?

    >> W: dialog: manpage-has-errors-from-man usr/share/man/man3/dialog.3.gz 1494: warning: `..' not defined


    > Maybe another botched attempt to define a macro?


    1490 .TP 5
    1491 .B const char * \fIfmt
    1492 is the format of the \fBprintf\fP-like message to write.
    1493 .TP 5
    1494 ...
    1495 are the variables to apply to the \fIfmt\fP format.

    More like an Attempt to render ellipsis.

    [...]

    >> W: ddd: manpage-has-errors-from-man usr/share/man/man1/ddd.1.gz 34: warning: `PSPIC' not defined


    > This is sort of odd; that macro is defined in cases where the output
    > device is capable of drawing pictures using pic. I think it would be
    > best to ignore this one, although the warning could be suppressed
    > like this:


    > .if d PSPIC .PSPIC /tmp/buildd/ddd-3.3.11/./ddd/PICS/dddlogo.eps 10cm


    ACK. Alternatively, an empty definition in
    groff-hack/{mdoc,man}.local could be used (``if not defined
    PSPIC, define empty PSPIC''.)

    [...]


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  18. Re: Bug#450432: ... and even more bugs like this?

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iQIVAwUBR0Gpk79TXYEfUvaLAQJfBhAAoF4n5d22TlJ9KwFoW0 4IQuB3Rf0USFx6
    N0op3oNPwmcFy5VP/c4cE/P1MiqlejnLJ6xhyIs4ypoALOOqKdeCVooG9VMUkO8v
    lhE40a2iHq/qsfDdiSOyhWozXfuaKi6c87bjRxI6RMZN+Y3KNwuA81JmDHN9Z WRp
    5Hyp3umeUXQ4+DQd4O8j4zHhxngR5ZuU2UUlbPnSZTUH9AMQtV xYGVnYOLt/T8Za
    Kh2D/cth18nySX8sd/qNsKEVctepkS57GyZece2/CtPspfkA8HPYVxxDkXUtvZG1
    u0stuoyd4xQCXy4e5misifcMoRPHcwAFQrTW4TZy5/Mh4hgW5Q49Nvv4zPUQC9PX
    Y3knVudYtrkvYUQPXxdwDrubpreE0SY4S35CRRCDhhuEqKEg10 NnCaVV8Se7sS4h
    CTdUtWyNOqAOEDsWmtCkpLs/kaC30826X8WDcJYkZY9csRL1+umGIDFYS0oRS30G
    xC8Xg9+er6+AiCCDf1UOy0Vgq10NZz34oPxF+ucuBYuJqTZa+L 4L/aKKUkhXGdzn
    HY+LXudh5di53oPkQjz/h7w/wf4zKEgajq2OuAYrV81hQCYarUIyYnAAehfwpO88
    aDMxRFFhO/Sbpewx8HAnS5ajlsvZVxXmrahjneaxBHVoW5XKi/Ob/eJqSLImf6U1
    rRnShOxu7/A=
    =XHNF
    -----END PGP SIGNATURE-----


  19. Bug#377392: Bug#450432: ... and even more bugs like this?

    >>>>> Colin Watson writes:

    >> In a recent thread in debian-devel, it was suggested that lintian
    >> could call man(1) in such a way that the groff(1), called by `man',
    >> will emit warnings for every undefined macro, which is useful in
    >> catching the bugs like this:


    >> .B foo
    >> . Note: ...


    >> Below is the patch that implements the suggestion. Since `man'
    >> doesn't allow the `-wmac' option to be passed to `groff' by any
    >> other means, I've had to introduce two new files -- `mdoc.local' and
    >> `man.local' (to override the files in groff/site-tmac/), and the
    >> ${LINTIAN_ROOT}/groff-hack directory to hold them.


    > While I haven't reviewed the code in detail, the general approach
    > seems largely reasonable to me. However, the error the developer sees
    > will just be "manpage-has-errors-from-man", which in fact is no
    > longer really true in this case; you're specifically enabling
    > warnings that man doesn't show. Perhaps it would be best to turn
    > these warnings from groff into a different lintian warning which can
    > have a more informative description, and ideally a way for the
    > developer to reproduce the problem.


    A helper script, `lintian-man', could be introduced to hide all
    the hackery, and to provide a way for the developer to reproduce
    the problem. Then, Tag: may be changed to, e. g.,
    `manpage-has-messages-from-lintian-man'. (Or should this script
    be called `man-lintian'?)

    I still hope that either `groff' or `man' will offer a way to
    specify `-w'-options for `groff' in a more clean way. The
    helper script could then be modified, or eliminated entirely.

    The patch is as follows. (TODO: newly introduced lintian-man
    script demands a man page on its own.) This new version of the
    patch suppresses `.IX'-related warnings. (TODO: the generator
    is to be fixed.)

    --- lintian-1.23.36/checks/manpages 2007-10-16 10:40:04.000000000 +0700
    +++ lintian-1.23.36-groff-hack/checks/manpages 2007-11-21 21:16:29.000000000 +0600
    @@ -253,10 +253,11 @@
    # processed properly. (Yes, there are man pages that include other
    # pages with .so but aren't simple links; rbash, for instance.)
    my $cmd;
    + my $man_cmd = "lintian-man -l";
    if ($file =~ m,^(.*)/(man\d/.*)$,) {
    - $cmd = "cd unpacked/\Q$1\E && man -l \Q$2\E";
    + $cmd = "cd unpacked/\Q$1\E && $man_cmd \Q$2\E";
    } else {
    - $cmd = "man -l unpacked/\Q$file\E";
    + $cmd = "$man_cmd unpacked/\Q$file\E";
    }
    my $pid = open MANERRS, '-|';
    if (not defined $pid) {
    @@ -282,7 +283,7 @@
    }
    chomp;
    s/^[^:]+://o;
    - tag "manpage-has-errors-from-man", "$file", "$_";
    + tag "manpage-has-messages-from-lintian-man", "$file", "$_";
    last;
    }
    close(MANERRS);
    --- lintian-1.23.36/checks/manpages.desc 2007-06-21 15:48:26.000000000 +0700
    +++ lintian-1.23.36-groff-hack/checks/manpages.desc 2007-11-21 21:16:26.000000000 +0600
    @@ -120,9 +120,12 @@
    Please double-check the manual page and replace the template language
    with specific information about this program.

    -Tag: manpage-has-errors-from-man
    +Tag: manpage-has-messages-from-lintian-man
    Type: warning
    -Info: This man page provokes warnings or errors from man.
    +Info: This man page provokes warnings or errors from lintian-man.
    + .
    + lintian-man is a helper script which behaves like man, but with Groff
    + warnings (-wman) explicitly enabled.

  20. Re: Bug#377392: Bug#450432: ... and even more bugs like this?

    >>>>> David Weinehall writes:

    >> A helper script, `lintian-man', could be introduced to hide all
    >> the hackery, and to provide a way for the developer to reproduce
    >> the problem. Then, Tag: may be changed to, e. g.,
    >> `manpage-has-messages-from-lintian-man'. (Or should this script
    >> be called `man-lintian'?)


    > [snip]


    > Sounds like a great idea in general. But: correct manual pages is
    > not something that is specific to debian packages, so maybe manlint
    > would be a better idea, also having it as a part of the man-db
    > package instead might be an idea.


    Well, one might then implement a generic method of passing Groff
    options via `man', thus obviating the need to override the
    `man.local' and `mdoc.local'. How about an environment variable
    (say, `MANROFFOPT' or `MANGROFFOPT')?

    > lintian already depends on man-db, so the dependencies wouldn't
    > change, and it would also mean that linda can use the same check
    > without code duplication.



    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread
Page 1 of 2 1 2 LastLast