duplicity cannot be expected to parse gpg.conf, no, nor to control gnupg
to such an extent. but if duplicity is to call out to gnupg for
encryption services, then duplicity can IMO be expected to recover
gracefully from catastrophic failures on gnupg's behalf to perform, even
when it arguably
addendum: editing my gpg.conf to comment out the version-2-only options
appears to make deja-dup run correctly. this seems to be at least a
workaround, if not the complete solution.
it's regrettable that gnupg versions 1 and 2 use the same config file,
with options not being backwards compatible.
output from points 1--3, in file "details.1.txt".
output from point #4, in file "deja-dup.log".
this bug tracker appears to be limited to one attachment per comment, so
i zipped the files together and attached the archive.
thank you for instructions on how to create the deja-dup debug log file
Public bug reported:
Attempting to create a full backup to a SMB NAS, succeeds if backup is
set to unencrypted. Fails if password is specified.
Symptom: deja-dup loops endlessly through "scanning" -> "encryption
password needed" -> "require password?" and round and round.
Possibly related to
