@ifset gpgtwoone macro not working in gpg.texi?

[Daniel Kahn Gillmor]

I don't think @ifset gpgtwoone is being evaluated properly in gpg.texi
(though i don't know why).  I'm using debian, and have both gpg (1.4.15)
and gpg2 (2.0.22) installed.

gpg(1) says:

       --try-secret-key name
              For hidden recipients GPG needs to know the keys to use
              for trial decryption.  The key set with --default-key is
              always tried first, but this is often not sufficient.
              This option allows to set more keys to be used for trial
              decryption.  Although any valid user-id specification may
              be used for name it makes sense to use at least the long
              keyid to avoid ambiguities.  Note that gpg-agent might pop
              up a pinentry for a lot keys to do the trial decryption.
              If you want to stop all further trial decryption you may
              use close-window button instead of the cancel button.

But the argument doesn't work in these versions:

0 dkg at alice:~$ gpg --try-secret-key 'Daniel Kahn Gillmor <dkg at fifthhorseman.net>' < tmp/x.gpg
gpg: Invalid option "--try-secret-key"
2 dkg at alice:~$ gpg2 --try-secret-key 'Daniel Kahn Gillmor <dkg at fifthhorseman.net>' < tmp/x.gpg
gpg: invalid option "--try-secret-key"
2 dkg at alice:~$ 

Looking in the source, i see that the documentation is supposed to be
wrapped in an "@ifset gpgtwoone" in doc/gpg.texi.  The same is true for
--with-keygrip -- it shows up in the manpage output.

Interestingly, "@ifclear gpgtwoone" is also evaluating to true, because
the export-secret-subkeys documentation contains the reference to
--simple-sk-checksum:

       --export-secret-subkeys
              Same as --export, but exports the secret keys instead.
              This is normally not very useful and a security risk.  The
              second form of the command has the special property to
              render the secret part of the primary key useless; this is
              a GNU extension to OpenPGP and other implementations can
              not be expected to successfully import such a key.  See
              the option --simple-sk-checksum if you want to import
              such an exported key with an older OpenPGP implementation.

Any ideas what might be going wrong in the documentation generation
process?

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: </pipermail/attachments/20131025/df5bf669/attachment.sig>