duply (simple duplicity) Activity
Brought to you by:
edso
Activity for duply (simple duplicity)
-
ede modified a comment on ticket #57
the options "should" work over all backends, but sure there might be implementation flaws. if so please open a ticket on https://gitlab.com/duplicity/duplicity/-/issues/ and let's fix it :) apart from the repo i only offer snapshots on https://duply.net/Code#Latest_Development_Snapshot if some issue needs double checking by the issuer. currently there not much developing on duply as it is quite mature and stable fortunately.
-
the options "should" work over all backends, but sure there might be implementation flaws. if so please open a ticket on https://gitlab.com/duplicity/duplicity/-/issues/ and let's fix it :) apart from the repo i only offer snapshots on https://duply.net/Code#Latest_Development_Snapshot if some issue needs double checking by the issuer. currently there not much developing on duply as it is quite matrue and stable fortunately.
-
3rjpq0d6x posted a comment on ticket #57
those options haven't always worked in my experienced, hence my request, but it might just be an issue on duplicity side. I'll investigate that and come back here if needed. Thanks a lot BTW, I've seen that this SVN repo is only updated on release, is there any repo somewhere that is up to date with active developpement ?
-
Add a retry mechanism in case of duplicity backend error
-
hey @3rjpq0d6x, duply is mainly meant to be run manually or by cron and be finished after it is done. i'm unsure if it is a good idea to have it sleeping and retry blindly if some error occurs. duplicity itself already has a retry mechanism build in that should be of help to you. look at the man page https://duplicity.us/stable/duplicity.1.html for the options --num-retries --backend-retry-delay does that help? ..sunny regards ede
-
Add a retry mechanism in case of duplicity backend error
-
duply (simple duplicity) updated /duply (simple duplicity)/2.5.x/readme.txt
-
-
release 2.5.6
-
-
conf setting "--exclude-other-filesystems" corrupts generated cmd line
-
released as v2.5.6 . THANKS again David!
-
-
release 2.5.6
-
release 2.5.6
-
David Epping posted a comment on ticket #144
Thanks so much! Yes, it works correctly in my setup as well.
-
conf setting "--exclude-other-filesystems" corrupts generated cmd line
-
all good. i think i found it. please try this snapshot https://duply.net/tmp/duply.sh
-
I hope this is a supported use case after all. It seems like the exclude-other-filesytems parameter is not in duply.sh and it must have been added to the config many years ago ...
-
ok, that helps. at least i got a hickup now to debug :) user@debian13-lxc:~$ duply david status Start duply v2.5.5, time is 2025-08-28 13:25:50. Using profile '/home/user/.duply/david'. Using installed duplicity version 3.0.4, python 3.13.5 (/usr/bin/python3) 'PYTHONPATH=:/usr/lib/python313.zip:/usr/lib/python3.13:/usr/lib/python3.13/lib-dynload:/usr/local/lib/python3.13/dist-packages:/usr/lib/python3/dist-packages', gpg 2.4.7 (Home: /home/user/.gnupg), awk 'mawk 1.3.4 20250131', grep 'grep (GNU...
-
Hi ede, thanks for putting in all that effort. While stripping down the config to something minimal that still shows the issue, I found that I can toggle between working and not working by commenting or having active my exclude-other-filesystems line. I also found that only the MAX_FULLBKP_AGE content xor the VOLSIZE content shows up in the commandline. If both are active VOLSIZE does not show up. This is the config showing the error and below outputs: BACKUP_BASE_DIR='/srv/duply' DUPL_PARAMS="$DUPL_PARAMS...
-
just tested the VOLSIZE issue VOLSIZE=50 DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE " with duply test status (test is a profile) and it works fine. verified it with the duply --preview parameter which does not execute but merely prints the generated cmd lines. NOTE the missing --volsize 50 from the status cmd line. :~$ ./duply_dev/duply_wrap test status --preview Start duply.sh v2.5.6dev, time is 2025-08-28 10:54:23. Using profile '/home/dup/.duply/test'. SNIP --- Start running command STATUS at...
-
created a fresh Debian 13 container installed duplicity/duply created test profile, enabled VOLSIZE and MAX_FULLBKP_AGE works for me. please send me the outputs requested above https://sourceforge.net/p/ftplicity/bugs/144/#f9d6 user@debian13-lxc:~$ duply test status Start duply v2.5.5, time is 2025-08-28 12:51:28. Using profile '/home/user/.duply/test'. Using installed duplicity version 3.0.4, python 3.13.5 (/usr/bin/python3) 'PYTHONPATH=:/usr/lib/python313.zip:/usr/lib/python3.13:/usr/lib/python3.13/lib-dynload:/usr/local/lib/python3.13/dist-packages:/usr/lib/python3/dist-packages',...
-
also can't replicate the issue with MAX_FULLBKP_AGE=1M DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE " with duplicity 3.0.4 . maybe a python 3.13 issue or something else on Debian 13 . will setup a vm and check.
-
just tested the VOLSIZE issue VOLSIZE=50 DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE " with duply test status (test is a profile) and it works fine. verified it with the duply --preview parameter which does not execute but merely prints the generated cmd lines. NOTE the missing --volsize 50 from the status cmd line. :~$ ./duply_dev/duply_wrap test status --preview Start duply.sh v2.5.6dev, time is 2025-08-28 10:54:23. Using profile '/home/dup/.duply/test'. SNIP --- Start running command STATUS at...
-
Incompatibility of conf settings MAX_FULLBKP_AGE, VOLSIZE with duplicity 3.0.4
-
i see. thanks! will have a deeper look.
-
My initial config had only MAX_FULLBKP_AGE uncommented and this was what triggered the problem for me. When creating the bug report, because it looked similar, I also tried with VOLSIZE briefly and saw it fail. I just re-tested and the error message is as follows, with default VOLSIZE of 50: 2025-08-26T22:05:50.147354+02:00 share duply-backup: --- Start running command PURGE at 2025-08-26 22:05:50.140 --- 2025-08-26T22:05:50.246601+02:00 share duply-backup: CommandLineError: Wrong number of positional...
-
Incompatibility of MAX_FULLBKP_AGE with duplicity 3.0.4
-
The problem combination is the MAX_FULLBKP_AGE or VOLSIZE feature of duply with for example the status command of duplicity. are you sure VOLSIZE raises an issue? afaics it is stripped for all non-backup commands.
-
Hi ede, thanks a lot. Just let me know if you need additional information from my side. Best regards, David
-
Incompatibility of MAX_FULLBKP_AGE with duplicity 3.0.4
-
hey David, will try to reproduce and fix. just wanted to let you know that i've seen your report and appreciate it. THANKS! ..ede
-
Incomatibility of MAX_FULLBKP_AGE with duplicity 3.0.4
-
duply 2.5.5 is released.
-
duply 2.5.5 released
-
-
release 2.5.5
-
-
-
release 2.5.5
-
Mischa ter Smitten posted a comment on ticket #143
👍
-
Duply (2.5.4) is not compatible with duplicity 3.0.4
-
Thanks! will release it as v2.5.5 soonish.
-
Works for me
-
can you please try this dev version? i think i ironed it out. https://duply.net/tmp/duply.sh
-
Indeed, that's what I was thinking too.
-
it will be shown on every duplicity run. i am not going to anything about it. duplicity is telling you to upgrade ;)
-
But the deprecation message is still show in the output (of BKP): Starting deprecation of python 3.8 support. Support for python 3.8. will finally removed with the release of 3.14. For details see https://devguide.python.org/versions/ Not sure if this really is a problem
-
Adding tail -1 to $CMD --version fixes the problem DUPL_VERSION_OUT=$($CMD --version | tail -1)
-
moin Mischa, saw it. working on it. will release a fix. Thanks for the heads up!
-
duplicity_version_get is probably failing because of the output change: # duplicity --version Starting deprecation of python 3.8 support. Support for python 3.8. will finally removed with the release of 3.14. For details see https://devguide.python.org/versions/ duplicity 3.0.4 February 08, 2025 versus # duplicity --version duplicity 3.0.3.2 November 25, 2024
-
Duply (2.5.4) is not compatible with duplicity 3.0.4
-
batch cmds with consecutive '_' fail WAS: Failure when parsing groupIn following and/or
-
good to hear. will be in the next release. happy new year ..ede
-
duply 2.5.4 released
-
-
duply 2.5.4 released
-
-
-
release 2.5.4
-
Failure when parsing groupIn following and/or
-
good to hear. will be in the next release. happy new year ..ede
-
Dominik Sommer posted a comment on ticket #142
Thanks @edso! I couldn't test the whole file (since my system version is on 2.4.1 with duplicity at 0.8.22), but applied the changes manually. Elegant solution - works fine!
-
nice catch Dominik, please try the latest snapshot. this should fix the issue. https://duply.net/tmp/duply.sh Thanks! ..ede
-
Just noticed I didn't use the correct formatting for multiline code - here's the patch again: case "$cmd" in '') # ignore empty parameter ;;
-
Failure when parsing groupIn following and/or
-
Filias posted a comment on ticket #141
Thanks! I'll report back if things don't work as expected.
-
Broken GPG_OPTS in duply 2.5.2 under macOS Sonoma
-
should be fixed in v2.5.3 . released now.
-
duplicity complains about GPG_OPTS for status command
-
should be fixed in v2.5.3 . released now.
-
-
-
release 2.5.3
-
can you guys please test if the new devel version fixes the issue for you? https://duply.net/tmp/duply.sh
-
can you guys please test if the new devel version fixes the issue for you? https://duply.net/tmp/duply.sh
-
posted a WORKAROUND here https://sourceforge.net/p/ftplicity/bugs/140/#3138. working on a fix.
-
hey Milan, turns out that the new command line parser used by duplicity is at fault and even worse that it will probably not be fixed as it was designed that way intentionally. good news for you though. since quite some time --pinentry-mode=loopback is not needed anymore as duplicity will set it itself if needed. so no need for duply to provide it anymore. PROBLEMSOLVED :) at least for you. will need to patch up duply. as a permanent fix (some) option values given to duplicity will need the equal...
-
hey Milan, turns out that the new command line parser used by duplicity is at fault and even worse that it will probably not be fixed as it was designed that way intentionally. good news for you though. since quite some time --pinentry-mode=loopback is not needed anymore as duplicity will set it itself if needed. so no need for duply to provide it anymore. PROBLEMSOLVED :) not really. will need to patch up duply. as a permanent fix (some) option values given to duplicity will need the equal sign...
-
Milan Zimmermann posted a comment on ticket #140
Hi, I have the same issue on Linux: duply --version duply version 2.5.2 (https://duply.net) Using installed duplicity version 2.2.3, python 3.11.9 (/usr/bin/python3.11) 'PYTHONPATH=:/usr/lib64/python311.zip:/usr/lib64/python3.11:/usr/lib64/python3.11/lib-dynload:/usr/lib64/python3.11/site-packages:/usr/lib64/python3.11/site-packages/PIL:/usr/lib64/python3.11/_import_failed:/usr/lib/python3.11/site-packages', gpg 2.4.5 (Home: /root/.gnupg), awk 'GNU Awk 5.3.0, API 4.0, PMA Avon 8-g1, (GNU MPFR 4.2.1,...
-
i see. while duplicity internally sets --pinentry-mode=loopback duply for the tests does not. i wonder why i never stumbled over that.
-
OK, the workaround does work, but requires me to set GPG_TEST='disabled', because otherwise the calls to gpg wont get the neccessary GPG_OPTS set, it seems. Thanks for yourhelp!
-
you are totally right. but seeing it as a rarely used option , --pinentry-mode=loopback is set by duplicity these days, i'll prefer to have upstream fix the issue properly. as a workaround you probably may comment #GPG_OPTS=... and add the "working" --gpg-options='--compress-algo=bzip2 --bzip2-compress-level=9' to latest conf entry DUPL_PARAMS=... if i find time i might have a look at it at the duplicity issue but can't promise anything. life's keeping me busy just now.
-
you are totally right. but seeing it as a rarely used option , --pinentry-mode=loopback is set by duplicity these days, i'll prefer to have upstream fix the issue properly. as a workaround you probably may comment #GPG_OPTS=... and add the "working" --gpg-options='--compress-algo=bzip2 --bzip2-compress-level=9' to latest conf entry DUPL_PARAMS=... if i find time i might have a look at it at duplicity but can't promise anything. life's keeping me busy just now.
-
running duply with bash -x shows that it generates the following command: ++ duplicity collection-status --archive-dir /var/.duply-cache --name duply_backup --encrypt-key XXXXX --encrypt-key XXXXX --sign-key XXXXX --gpg-options '--pinentry-mode=loopback --compress-algo=bzip2 --bzip2-compress-level=9' --full-if-older-than 1W sftp://user@backup.example.com According to https://gitlab.com/duplicity/duplicity/-/issues/795 the easy fix would be to use --gpg-options='$GPG_OPTS' instead of --gpg-options...
-
no Nuno, it's a bug in duplicity not accepting some --name value pairs separated by space anymore. the alternative --name=value still works. please read the ticket https://gitlab.com/duplicity/duplicity/-/issues/795 what confuses me is that the error is supposed to be fixed in duplicity. but furthermore, wrt. "--pinentry-mode" , this does indeed not need be set anymore as duplicity will do that automagically since some time. need to clean that from the conf template, will do :)
-
no Nuno, it's a bug in duplicity not accepting some --name value pairs separated by space anymore. the alternative --name=value still works. please read the ticket https://gitlab.com/duplicity/duplicity/-/issues/795 what confuses me is that the error is supposed to be fixed in duplicity.
-
Nuno Teixeira posted a comment on ticket #141
2.2.2 man page says related to --pinentry-mode: NOTE: Contrary to previous versions of duplicity, this option will also be honored by GnuPG 2 and newer versions. If GnuPG 2 is in use, duplicity passes the option --pinentry-mode=loopback to the the gpg process unless --use-agent is specified on the duplicity command line. This has the effect that GnuPG 2 uses the agent only if --use-agent is given, just like GnuPG 1. Does it make sense about using this option and error msg: duplicity.cli_util.CommandLineError:...
-
duplicity complains about GPG_OPTS for status command
-
this is the same duplicity issue as https://sourceforge.net/p/ftplicity/bugs/140/ which is according to the duplicity changelog fixed in v2.2.0 are you sure that you are running duplicity 2.2.2 ? can you post the complete output with versions and all? feel free to post to the duplicity ticket wrt. the underlying issue https://gitlab.com/duplicity/duplicity/-/issues/795
-
Broken GPG_OPTS in duply 2.5.2 under macOS Sonoma
-
FiLiS created ticket #141
duplicity complains about GPG_OPTS for status command
-
Ralf Schröter posted a comment on ticket #140
moin ede thank you for your help and your investigations. I will try your suggestion with downgrading...
-
Broken GPG_OPTS in duply 2.5.2 under macOS Sonoma
-
hey Ralf, the command line generated by duply is fine. i verified that duplicity is at fault here. i opened a ticket in that regard https://gitlab.com/duplicity/duplicity/-/issues/795 . consider downgrading duplicity, if the option is important to you or wait for the fix :) will close this as invalid as duply is working as expected. ..sunny regards ede
-
moin ede wow - thank you for the fast reply! Here is the requested output (I have replaced only PGP-key-id and passphrase with generics): Start duply v2.5.2, time is 2024-01-22 08:15:15. Using profile '/Users/ralf/.duply/devonthink.koofr.net'. Using installed duplicity version 2.1.5, python 3.11.7 (/opt/homebrew/Cellar/duplicity/2.1.5/libexec/bin/python) 'PYTHONPATH=:/opt/homebrew/Cellar/python@3.11/3.11.7_1/Frameworks/Python.framework/Versions/3.11/lib/python311.zip:/opt/homebrew/Cellar/python@3.11/3.11.7_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11:/opt/homebrew/Cellar/python@3.11/3.11.7_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/lib-dynload:/opt/homebrew/Cellar/duplicity/2.1.5/libexec/lib/python3.11/site-packages:/opt/homebrew/opt/llvm/lib/python3.11/site-packages:/opt/homebrew/opt/pycparser/lib/python3.11/site-packages:/opt/homebrew/opt/cffi/lib/python3.11/site-packages:/opt/homebrew/opt/protobuf/lib/python3.11/site-packages:/opt/homebrew/opt/python-certifi/lib/python3.11/site-packages:/opt/homebrew/opt/python-typing-extensions/lib/python3.11/site-packages:/opt/homebrew/opt/python-cryptography/lib/python3.11/site-packages:/opt/homebrew/opt/python-packaging/lib/python3.11/site-packages:/opt/homebrew/opt/six/lib/python3.11/site-packages:/opt/homebrew/opt/python-dateutil/lib/python3.11/site-packages:/opt/homebrew/opt/python-lxml/lib/python3.11/site-packages:/opt/homebrew/opt/python-ply/lib/python3.11/site-packages:/opt/homebrew/opt/python-psutil/lib/python3.11/site-packages:/opt/homebrew/opt/python-pyparsing/lib/python3.11/site-packages:/opt/homebrew/opt/python-pytz/lib/python3.11/site-packages:/opt/homebrew/opt/pyyaml/lib/python3.11/site-packages:/opt/homebrew/opt/llvm/lib/python3.11/site-packages:/opt/homebrew/lib/python3.11/site-packages',...
-
moin Ralf, please run duply backup command with parameter --preview and the offending GPG_OPTS enabled. post the complete output here after. i need versions outputs as well. thanks.. ede
-
moin Ralf, please run duply backup command with parameter --preview and the offending GPG_OPTS enabled. post the output here after. thanks.. ede
-
Broken GPG_OPTS in duply 2.5.2 under macOS Sonoma
1 >
