Description of problem: When LANG is set to cs_CZ.UTF-8, backup fails with unknown error and long traceback. Version-Release number of selected component (if applicable): deja-dup-43.4-2.fc37.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start deja-dup with Czech localisation: $ LANG=cs_CZ.UTF-8 deja-dup 2. Try to run backup via by clicking on "Zálohovat nyní" button. Actual results: The process ends with following message (added translation after # character): Zálohování se nezdařilo # Backup failed Ukončeno s neznámou chybou # Exited with an unknown error Traceback (innermost last): File "/usr/bin/duplicity", line 87, in <module> with_tempdir(main) File "/usr/bin/duplicity", line 70, in with_tempdir fn() File "/usr/lib64/python3.11/site-packages/duplicity/dup_main.py", line 1585, in main do_backup(action) File "/usr/lib64/python3.11/site-packages/duplicity/dup_main.py", line 1607, in do_backup action).set_values() ^^^^^^^^^^^^ File "/usr/lib64/python3.11/site-packages/duplicity/dup_collections.py", line 725, in set_values log.Debug(ngettext(u"%d file exists on backend", ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: not all arguments converted during string formatting Expected results: Backup will process correctly. Additional info: When running with English translation, everything works correctly. WORKAROUND: run deja-dup from command line with LANG=C (or any other language) $ LANG=C deja-dup
Forgot to add duplicity version: duplicity-1.0.1-1.fc37.x86_64
Also it seems to be working correctly on the previous version duplicity-1.0.0-1.fc37.x86_64, so marking this as regression.
A small word of caution: 1.0.0 had an encryption interaction bug and is a buggy combo with deja-dup. 1.0.1 fixed that, so I'd recommend using 1.0.1 in English until this is fixed (rather than 1.0.0 in cs_CZ). As for this bug, it looks like one of the cs_CZ translation for that string ("%d file exists on backend") is missing the %d symbol. Does Fedora use its own language packs, or upstream's directly?
Moved to component duplicity as that seems to be the problematic part. (In reply to Michael Terry from comment #3) > A small word of caution: 1.0.0 had an encryption interaction bug and is a > buggy combo with deja-dup. 1.0.1 fixed that, so I'd recommend using 1.0.1 in > English until this is fixed (rather than 1.0.0 in cs_CZ). Thanks for this caution. > As for this bug, it looks like one of the cs_CZ translation for that string > ("%d file exists on backend") is missing the %d symbol. Does Fedora use its > own language packs, or upstream's directly? I would think, that Fedora uses upstream's language pack, but it is only my assumption. I'm not sure, if following procedure was correct/meaningful, but I tried to download duplicity cs_CZ.po[1] file from gitlab (commit 083c795a), update line 3150 from: msgstr[3] "" to msgstr[3] "%d souborů existuje na podpůrné vrstvě" (not sure, if the translation is correct for this plural version) and generated the binary message catalog and copied it to /usr/share/locale/cs/LC_MESSAGES (overwrite the existing one) like this: $ msgfmt cs_CZ.po -o duplicity.mo $ sudo cp -f duplicity.mo /usr/share/locale/cs/LC_MESSAGES/duplicity.mo And when I tried to trigger backup, if failed again (probably little bit later) with similar error, but on different message: "Found %d secondary backup chain." So I've updated the `msgstr[3] ""` for this message similarly as for the previous one, generated again the binary catalog using msgfmt and now it seems like the backup is working. Also it looks, like there are many other empty messages like `msgstr[3] ""`, not sure, if all of them might cause such failure in some circumstances. [1] https://gitlab.com/duplicity/duplicity/-/blob/main/po/cs_CZ.po
Yeah upstream’s file looked fine to me. Blank translations are normal, the English string gets used (just means no translation yet).
(In reply to Michael Terry from comment #5) > Yeah upstream’s file looked fine to me. Blank translations are normal, the > English string gets used (just means no translation yet). But from my experiment mentioned in Comment 4, it looks like the problem is the same with the upstream version of translation file. And if I've filled the empty string for the problematic sentence, it started to work (it progressed little bit further to another similar failure with different sentence).
Oh sorry I think I misread your comment 4
Filed upstream.
FEDORA-2022-3ee1a4e8fd has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3ee1a4e8fd
FEDORA-2022-3ee1a4e8fd has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-3ee1a4e8fd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-3ee1a4e8fd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The issue is still there and it looks like the file /usr/share/locale/cs/LC_MESSAGES/duplicity.mo wasn't changed at all between the versions 1.0.1-1.fc37 and 1.0.1-3.fc37: $ sha256sum duplicity*.mo 8ad787b79f3570f4c6b4e23b1964884dde120353d041e24ed26c4c77006ead33 duplicity-1.0.1-1.mo 8ad787b79f3570f4c6b4e23b1964884dde120353d041e24ed26c4c77006ead33 duplicity-1.0.1-3.mo (copied the above mentioned file to tmp and renamed it with the version from which it was copied) Moving back to ASSIGNED.
FEDORA-2022-f7af2c8bcc has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-f7af2c8bcc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7af2c8bcc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
In the new version duplicity-1.2.1-1.fc37.x86_64, the issue seems to be fixed and everything works as expected.
FEDORA-2022-f7af2c8bcc has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.