The most important aspects of this release are Python 3.7 compatibility and support for the Canon CR3 file format. See the release notes if your version of ExifTool needs to be upgraded to be able to read CR3 files.
Full change log:
- Added support for Canon CR3 format. Requires ExifTool 10.87 or newer.
See the release notes for details on upgrading ExifTool. Note: program
performance with CR3 files is notably slower than other photo file formats.
Other photo file formats are read using the high performance library exiv2
to read metadata and extract thumbnails. Unfortunately exiv2 does not yet
support the CR3 format. Exiv2 0.28 will support the CR3 format.
- Fixed bug #1790351: Video date time metadata not parsed correctly when
āDSTā appears in time zone component.
- Added support for FFF and IIQ raw formats.
- The MOS and MRW formats are now handled by ExifTool, not exiv2.
- Better handle Exif date time values that unwisely deviate from the Exif
Version 2.3 specification, e.g. Hasselblad files.
- Fixed bug #1790278: File renaming and subfolder generation editor breaks
with Python 3.7.
- Updated installation script to use ālooseā instead of āstrictā Python
version checking.
- Fixed bug in installation script where a system installed Rapid Photo
Downloader package was not being uninstalled.
- Fixed bug #1791131: Report fatal camera access problem without crashing
- Improved install.py script to install libmediainfo0 on openSUSE where the
package exists.
thanks for the release! Iām also happy to announce there is now a new maintainer of the Debian package who uploaded the new version 5 days ago, and it trickled down into testing without problem. i did find a release critical bug, but itās probably a packaging issue on our side.
So I wonder if itās really a packaging problem on our sideā¦
But itās true there might be a module missing in pyqt5 in Debian. It is customary, however, to avoid shipping duplicate copies of code in Debian, so this might actually be deliberate.
I recall that Debian patches pip, so if Debian is patching PyQt5 in an unexpected way it wouldnāt surprise me.
I tested the code against PyQt5 < 5.11 and >= 5.11 and it works. Hence my suspicion that something else is happening in Debian that breaks that test.
While it is possible to simply import sip, as it says in the PyQt5 docs it will not work if the order of the import statements is reversed (i.e. import sip must come after importing something else from PyQt5). I strongly prefer explicit to implicit, so thatās why I put in the explicit test.
If that is breaking due to something happening in Debian then I may need to revisit it. Practicality beats purity.
@anarcat Iām not sure what was changed in the most recent Debian package, but I see the status message āUse python3-sip module, not the bundled copy of PyQt5.ā
PyQt5 >= 5.11 uses its own private copy of sip because it must, according to the PyQt 5 developer. See PyQt5-sip Ā· PyPI
The code in Rapid Photo Downloader 0.9.12 works on the latest versions of Arch and openSUSE without problems. As far as I know they do not need to patch anything in PyQt 5 or Rapid Photo Downloader.
If Debian is forcing PyQt5 >= 5.11 to use the the copy of sip that is not specific to PyQt, then I anticipate that will break PyQt5 in unexpected ways.
Thank you for investigating @Kirtai . Dmitry is a smart and experienced maintainer. He is active on the PyQt mailing list, submitting patches too. I donāt know why these Debian specific changes to the PyQt5 Debian package were made. Perhaps he is trying to avoid breaking existing packages in the Debian archive that expect the old PyQt5 / sip import behavior. I donāt know ā Iām just speculating.
It seems likely that the āUse the public version of sip module, per Policy Ā§ 4.13.ā in the changelog was referring to Debian Policy 4.13 which says to remove bundled copies of code that an application uses for convenience and replace them with proper dependencies when making a package.
Letting him know that this isnāt one of those cases would hopefully be enough.