Upgrading Dangerzone 0.5.0 to 0.6.0 on Fedora 38 may / will break the OCR component

[deeplow]

Upgrading Dangerzone 0.5.0 to 0.6.0 on Fedora 38 may / will break the OCR component. This can be easily fixed by appending the line

    export TESSDATA_PREFIX=/usr/share/tesseract/tessdata

to the file .bash_profile in the disposable template used for the Dangerzone dispVM.

Originally posted by @GWeck in #704 (comment)

[deeplow]

Great catch! We had tested on Qubes a dev build for Fedora 38 templates, and a production build for Fedora 39 templates. And yet we missed it 😬 . The reason we missed it is:

1. The PyMuPDF version on Fedora 39 is 1.23.3, which accepts the Tesseract data path as a separate argument. Our code checks for the PyMuPDF version and does pass the correct path:

   dangerzone/dangerzone/conversion/common.py

   Lines 24 to 28 in d35eb56

   	def get_tessdata_dir() -> str:
   	if running_on_qubes():
   	return "/usr/share/tesseract/tessdata/"
   	else:
   	return "/usr/share/tessdata/"

   dangerzone/dangerzone/conversion/pixels_to_pdf.py

   Lines 60 to 72 in d35eb56

   	if int(fitz.version[2]) >= 20230621000001:
   	page_pdf_bytes = pixmap.pdfocr_tobytes(
   	compress=True,
   	language=ocr_lang,
   	tessdata=get_tessdata_dir(),
   	)
   	else:
   	# XXX method signature changed in v1.22.5 to add tessdata arg
   	# TODO remove after oldest distro has PyMuPDF >= v1.22.5
   	page_pdf_bytes = pixmap.pdfocr_tobytes(
   	compress=True,
   	language=ocr_lang,
   	)

2. The dev script on Qubes has this line, so that's why the issue did not manifest on our local tests:

   dangerzone/dev_scripts/dangerzone

   Lines 7 to 9 in d35eb56

   	# XXX workaround lack of tessdata path arg for PyMuPDF < v1.22.5
   	# for context see https://github.com/freedomofpress/dangerzone/issues/682
   	os.environ["TESSDATA_PREFIX"] = os.environ.get("TESSDATA_PREFIX", "/usr/share/tesseract/tessdata")

Originally posted by @apyrgio in #704 (comment)

[apyrgio]

This issue has been fixed in our repo, but we also need to ship a new Dangerzone version for affected users. What we plan to do shortly is:

1. Use the latest commit in main (f75d471 as of writing this).

2. Bump the release number from 1 to 2 in install/linux/dangerzone.spec:

   dangerzone/install/linux/dangerzone.spec

   Line 36 in f75d471

   Release: 1%{?dist}

3. Build a dangerzone-qubes-0.6.0-2.fc38.x86_64.rpm package. That is, build an RPM only for Fedora 38 and Qubes.

4. Publish this package in our yum-tools-prod repo, so that users who have installed 0.6.0-1 will get updated to 0.6.0-2.

5. Create a v0.6.0-2 tag in the Dangerzone repo, as we did for the Fedora 37 hotfix in v0.4.0.

[apyrgio]

@GWeck we have a 0.6.0-2 release out for Fedora 38, that fixes this problem in particular. If you still have any issues with the new update, please let us know. Agains, thanks a lot for the bug report 🙂