Show quoted text> I'm not the maintainer of this module, but it seems that this is due
> to the fact that the maintainer has not shipped a test/trustdb.gpg
> file with the dist. The trustdb is required for the encrypt action in
> the first test case.
It shouldn't be; --trust-model=always should not necessitate the
existance of a trustdb. See below.
Show quoted text> the gpg command is emitting this error on the first test failure:
>
> gpg: Fatal: can't open `test/trustdb.gpg': No such file or directory
>
> You can replicate this by starting with a clean dist (or remove
> test/trustdb.gpg alternatively) and run:
>
> gpg --home test --recipient 2E854A6B --armor --trust-model=always \
> --encrypt Makefile.PL
>
> And you should see something like:
>
> gpg: WARNING: unsafe permissions on homedir `test'
> gpg: Fatal: can't open `test/trustdb.gpg': No such file or directory
>
> And "gpg" is exiting with code 2 in this instance.
GPG 2 does; GPG 1.4 does not. Compare:
$ rm Makefile.PL.asc
$ gpg --version | head -1
gpg (GnuPG) 1.4.16
$ rm -f test/trustdb.gpg
$ gpg --homedir test --recipient 2E854A6B --armor \
--trust-model=always --encrypt Makefile.PL
gpg: WARNING: unsafe permissions on homedir `test'
$ echo $?
0
$ ls test | grep trustdb
$ ls test | grep trustdb | wc -l
0
This is a bug in gpg2, and will be fixed in 2.0.27; see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751266 and
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=07006c99
Show quoted text> The actions taken by the second test (specifically
> $gnupg->get_public_keys) cause the trustdb.gpg file to be auto-created
> which eliminates this problem.
I've added a preliminary step which explicitly creates the trustdb, as a
workaround for the above bug.
- Alex