This repository has been archived by the owner on Jan 5, 2024. It is now read-only.
Handle subprocess stderr output in Python 3.9, treat lpadmin warnings as non-fatal
#97
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
subprocess.check_call does not raise an exception anymore if there's just output on stderr - hence, we move on to its newer API that allows us to capture stderr and analyze it even if the returncode is 0. It also safely ignores lpadmin driver warnings to allow us to continue to use printer drivers with CUPS.
5 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As opposed to how it worked in Python 3.7,
subprocess.check_calldoes not raise an exception anymore if there's output on stderr even when the returncode is 0. So we move on to the newersubprocessAPI that allows us to capture stderr and analyze it even if the returncode is 0.This is necessary so we can safely ignore
lpadminwarnings that would otherwise stop the printing process. This means that at least for now, we'll continue to use Debian supplied printer drivers with CUPS. However a change like #94 ought to be considered/tested in the future for the obvious benefit of not having to deal with printer drivers and easily supporting new printers.Fixes #93
Towards freedomofpress/securedrop-workstation#600
Testing
To save on time, this PR may be reviewed at the same as #96.
make testpasses (test-busterCI is currently broken, may be safely ignored).txtfiles and.docxfiles with a supported printer connected is successful