When deploying packages, build the RPM package for Fedora 37 and deploy
only that.
Problem
=======
The v0.4.0 release introduced Fedora 37 support. We had tested building
an RPM package for Fedora 37 and installing it successfully, so we
assumed that we had the green light for the release.
Turns out however that our CI runners were not building packages for
each of our supported Fedora release, but solely for Fedora 35. It so
happened that Fedora 35 and Fedora 36 had similar Python versions, but
the same did not apply to Fedora 37.
The end result is that users could not install Dangerzone on Fedora 37
through our official repo.
Remediation
===========
In order to help out Fedora 37 users, we plan to do the following:
1. Bump the Fedora patch level of our package to -2. This will help
users install the new package, once we release it.
2. Change our CI pipeline to build an RPM package for Fedora 37 instead,
and deploy that to PackageCloud.
3. Comment out all the other deployments to PackageCloud, since the rest
of the distros are not affected.
IMPORTANT: This is a hotfix that should never be merged back in the main
branch.
Fixes#156
Poetry 1.3 has an upstream bug [1] that makes it fail in TTYs that
report size 0. A temporary fix for this is to disable escape sequences
support with `--no-ansi`.
[1]: https://github.com/python-poetry/poetry/issues/7184
Now that safe PDFs can open on Windows right after conversion
(implemented in commit 5b2fefd), we need to save/load the "Open safe
documents after converting" setting.
Cx-Freeze 6.13.0 limited the PATH of the build executables, making it so
Dangerzone couldn't find Docker through shutil.which().
More information on the issue is available at:
https://github.com/marcelotduarte/cx_Freeze/issues/1674
Allowing this would lead to several UI edge-cases related to where the
files would be saved. Avoiding this is the easiest solution at the
moment.
In the future we should consider other options.
It was possible that users would add duplicate documents via 'open with
Dangerzone'. This would lead to unexpected situations and preventing it
both in the CLI and the GUI solves those issues.
Handle the case where a user has already added some documents (either
through 'open with' or via Dangerzone 'select documents' button) and
then they want to add some more via the 'open_with' dialog.
It updates the settings to reflect the newly added documents and blocks
the user from adding them if a conversion is already in progress.
Makes the ContentWidget a choke-point, where we can allow or prevent
adding more documents and where we can ensure that newly selected
documents are added immediately to the DangerzoneGui class.
Logically, the application flow should not change in any way.
Closing windows on macOS would not actually close Dangerzone. Now that
it is a single-window program, it makes sense for it to close
immediately.
Fixes#271
The save group box would get partially trimmed when running in macOS
this appears to be due to differences in rendering fonts and widget
sizes.
Refs #270
Add a QA section in our release notes, which describes the list of
manual checks a developer needs to make before a release, to ensure that
we have no regressions.
Closes#246
Bump the global timeout used for various steps from 1 minute to 2
minutes. The reason is that we've seen several reports of operations
failing due to timeout reasons, that were otherwise legitimately
running.
Also, bump the timeout used for compression, which has been reported as
problematic as well.
Refs #146
Refs #149
If a user has provided an output filename for a document, then we should
no longer accept suffixes. The reason is that we can't do something
meaningful with it, as we can't alter the provided output filename.
The proper behavior is to reject this action with an exception. Note
that this acts more of a safeguard, since (currently) there is no path
where a user may add a suffix to a document that already has an output
filename.
In preparation for adding a limit on how many convert threads exist, we
are simplifying its logic. Getting ocr_lang doesn't seem to belong to
the thread.
