With a recent par2 installed, bup fsck -v -j4 (optionally with -g or --quick) outputs messages like

Unexpected par2 error output
''Assuming par2 supports parallel processing


Unexpected par2 error output
''Assuming par2 supports parallel processing


Unexpected par2 error output
''Assuming par2 supports parallel processing


Unexpected par2 error output
''Assuming par2 supports parallel processing

pack-c43b5a506e802434012cea900fe0267532179eb1 generated
pack-a765e8f19683d1d0d2ea535470150660a9627a30 generated

Unexpected par2 error output
''Assuming par2 supports parallel processing

and so on. So the par2 -t1 test is run several times, despite caching attempts in cmd/fsck-cmd.py.

The fix proposed here moves the associated test from the par2 subroutine to par2_setup. Notes:

• This patch implicitly assumes that par2_setup() has been run before any calls to par2 take place and before any forking due to -jN happens. This is currently the case, as a look at the main section of fsck-cmd.py shows.
• The global variable _par2_parallel that stores the result has been renamed to par2_parallel as it is no longer accessed by only one subroutine (though not by subs in other files). The new name rings similar to the other global par2_ok. It is left at None if the test associated with par2_ok fails.

With this patch and the warning fixes from the fix-par2-t-msg branch, bup fsck -v -j4 now simply reports

Assuming par2 supports parallel processing

just once, which is as it should be.