There is a new upstream version released, 3.0.6.1, which claims to
address my own favourite bug, #977546.

I've packaged the new version as a test, in a fork of your packaging
repo on github

https://github.com/barak/duplicity

I've also done some minor packaging updates. One thing I'm not sure
about is if I got the changed dependencies, like properly adjusting
for python3-socks aka pysocks. Also upstream tweaked the test suite,
not sure if I correctly merged your test suite patch with upstream's
changes.

Anyway, we'll see if this new version works properly when I run out of
space and have a partial full backup that needs to be cleaned!

Cheers,

On Mon, 17 Nov 2025 10:33:16 +0000, "Barak A. Pearlmutter" writes:

thanks for the heads-up and the tinkering; i hope to find a little time
for duplicity this weekend.

Well, one issue with the new version is that it wants a GPG passphrase
*EVERY RUN*, and also doesn't know how to ask for it properly: you
need to do shenanigans with an agent and such. The following:

Version 3.0.6.2 was just released.  It goes back to the old passphrase
handling and fixes other problems, so skip the 3.0.6.1 version and go to
3.0.6.2.

...Thanks,
...Ken

Packaged 3.0.6.2 in github.com/barak/duplicity branch debian, seems to
work okay! Not sure if due to my fixing option passing vs changes to
duplicity GPG stuff, but in any case my stuff is being backed up,
phew.

On Sun, 23 Nov 2025 05:57:38 -0600, Kenneth Loafman writes:
it tells me that the metadata is in sync, followed immediately by a kaboom when
it attempts to decrypt a remote manifest file

example invocation (which has worked fine up to and including 3.0.5.1):

 duplicity backup --exclude-other-filesystems --volsize 250 --encrypt-key 2FCCF66BB963BD5F --archive-dir /var/lib/duplicity \
 --name boot --full-if-older-than 7D /boot rsync://backup@REDACTED::/backup/REDACTED/boot
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Nov 26 01:04:01 2025
Error processing remote file (duplicity-inc.20251127T150401Z.to.20251128T150401Z.manifest.gpg): GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 4096-bit RSA key, ID 0x360EEB3F4F780821, created 2013-11-03
"Alexander Zangerl <az@snafu.priv.at>"
gpg: decryption failed: secret key not available
===== End GnuPG log =====

Traceback (innermost last):
  File "/usr/lib/python3/dist-packages/duplicity/__main__.py", line 76, in dup_run
    with_tempdir(main)
  File "/usr/lib/python3/dist-packages/duplicity/__main__.py", line 60, in with_tempdir
    fn()
  File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1646, in main
    do_backup(action)
  File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1799, in do_backup
    check_last_manifest(col_stats)  # not needed for full backups
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1460, in check_last_manifest
    last_backup_set.check_manifests(check_remote=config.check_remote)
  File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 271, in check_manifests
    remote_manifest = self.get_remote_manifest() if check_remote else None
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 316, in get_remote_manifest
    manifest_buffer = self.get_remote_file(self.remote_manifest_name)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 329, in get_remote_file
    log.Info(_(f"Processing remote file {os.fsdecode(remote_file)} ({len(remote_file_buffer)})"))
                                                                         ^^^^^^^^^^^^^^^^^^
 UnboundLocalError: cannot access local variable 'remote_file_buffer' where it is not associated with a value

I have a possible fix for this, see attached patch.  Would you mind trying
it?

Seems there was a line deleted that should not have been.  AArgh!

On Sat, 29 Nov 2025 07:59:18 -0600, Kenneth Loafman writes:

same invocation as last time:

duplicity backup --exclude-other-filesystems --volsize 250 \
--encrypt-key 2FCCF66BB963BD5F --archive-dir /var/lib/duplicity \
--name boot --full-if-older-than 7D /boot \
rsync://backup@REDACTED::/backup/REDACTED/boot

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Nov 26 01:04:01 2025
Error processing remote file (duplicity-inc.20251129T053415Z.to.20251129T150401Z.manifest.gpg): GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 4096-bit RSA key, ID 0x360EEB3F4F780821, created 2013-11-03
"Alexander Zangerl <az@snafu.priv.at>"
gpg: decryption failed: secret key not available
===== End GnuPG log =====

Manifests not equal because different volume numbers
Fatal Error: Remote manifest does not match local one.
Either the remote backup set or the local archive directory has been corrupted.

I have similar issues with 3.0.6.3-1.

With --no-check-remote and --encrypt-key options, duplicity still asks for a passphrase.

I believe the line
https://gitlab.com/duplicity/duplicity/-/blob/dev/duplicity/dup_main.py?ref_type=heads#L160
is wrong and that need_passphrase should be set to False there.

HTH

The fix is already done and will be out in `3.0.7` by the end of the year.

...Thanks,
...Ken

Version 3.6.0.3-1 still has an issue with credentials being passed
through to gpg. I generated a package 3.6.0.3-1.1 in
https://github.com/barak/duplicity branch debian commit e838d638 which
includes post-3.6.0.3 development, in particular commit ac163d5e which
fixes the problem. It also has a few other minor tweaks, like an
updated debian/watch file.

Never mind, upstream 3.0.7 is out.

On Wed, 31 Dec 2025 18:48:50 +0000, "Barak A. Pearlmutter" writes:

yes, and it doesn't work without any encryption at all either.

thanks for your efforts. we clearly duplicated some of that
in the last two days: i pushed out 3.6.0.3-2 yesterday,
which...

...also includes that commit but not unchanged. upstream doesn't seem to
understand public key encryption and insists on passphrase-checking
*public* keys without reason.

while that commit fixes some/most gpg2 use with agent and gpgsm and
other special cases, it absolutely breaks
public-key-only/no-private-key-in-sight encryption.

(in the orginal commit, line 150 in dup_main.py makes
public key encryption strictly depend on check remote.
with --no-check-remote you get no public key encryption
at all and it falls through to symmetric.)

i'll have a look at these when i prep the next release, but
that won't be for a while: 3.0.6 broke much more than it fixed,
and i want 3.0.7 to mature some before i spend time on it.

regards
az

Yes, the big advantage of duplicity when I first started using it long
ago was that it used public key encryption, so the remote backup was
encrypted but couldn't be decrypted without information not present on
the being-backed-up machine. I thought that was a pretty fine idea.
And that property is now broken.

I was sort of assuming the issue would be dealt with in the fullness
of time, and in the meantime at least I'd have backups, even if I
needed to open up a private key during the backup process which seems
like a pretty bad idea.

Of course, the shorter this window of
not-properly-using-asymmetric-encryption is open the happier I'll be.