Jpegxl can use isobmff, so if thatās an issue for exiv2 then it must be an issue for jpegxl as well. Iāve never heard of an issue with jpegxl, soā¦
So ask them.
Again, the JPEG XL interest group has some resourceful backing. Exiv2 has none.
Can confirm Iām experiencing this on Debian 11.
I donāt need to. I donāt see in any way how there is a patent issue here. I never understood how any of the arguments of the exiv2 dev were valid. But you can see how it has effected things.
OP here. Since my original post Iāve achieved a better workaround by recompiling exiv2 with BMFF/CR3 support using the simple option in the first post in the link that darix shared:
https://bugzilla.redhat.com/show_bug.cgi?id=1979565
With the recompiled exiv2, the OBS package of darktable works fine.
That technique is specifically for RPM-based Linux distros, but I assume there must be something analogous for DEB-based distros too.
But I agree that the whole legal rigamarole around this is silly and annoying.
1 Like
Of course it is. But when the only way to prove the invalidity of a patent is in court, and when thatās prohibitively expensive for many of the parties concerned, who wants to take the risk?
That is the problem, yes.
In Fedora, we try to build and ship only packages which we know (as far as we can know) not to create any legal challenges, at least in the US jurisdiction. That can be frustrating for users and packagers at times. But it is part of our definition of āfreeā, and it is why Fedora can be a baseline distro in certain areas.
That big warning that exiv2 put up can hardly be ignored. In particular, now that it is there: If we continued building exiv2 with ISOBMFF support we would do so being fully aware of these patent claims. That is riskier than it used to be.
For similar reasons, RedHatās legal team will never say āyes it is patent encumberedā - that would be an invitation for the patent holder to go after prior uses of the code.
All we currently know is that we will not get an āOKā from RedHatās legal team in the current state of affairs. We would need exiv2 to become part of a legal entity (KDE was under discussion) which takes on liabilities in case of patent issues.
Alternatively, if exiv2 could load format support as modules, we could easily have the missing module at rpmfusion so that it enhances the Fedora exiv2 for those users accepting the risk individually. I donāt think exiv2 supports this right now.
1 Like
actually the OBS repository provides an exiv2 package with the required options turned on.
you could also have an exiv2 package in the distro with the formats turned off. and then ship the same source package via fusion and isobmff enabled there. then the user can just replace the exiv2 copy with the fusion one and be done. Thatās what openSUSE does with packman.
Technically you can do this, of course, it is much easier.
AFAIK it is against RPM fusion guidelines, though.
Sometimes Guidelines need a revision if there is a very good reason 
This could then also be used to have Mesa with the hardware encoder support turned back on 
Sure, but donāt you think the guidelines are there for very good reasons, too?
We are getting somewhat OT. I meant to provide the background for OPās observations. In Fedora and neighboring lands (RHEL/EPEL/RPM fusion), we handle legal things and the āboundariesā between different lands in a specific way, which serves us well most of the time, and provides challenges sometimes. That could probably be said about most alternative ways of doing things, too. Thereās always at least one way which would be easier in a specific scenario. No reason to change your long tome committment to a generally good way of doing things, though.
I might have a very good idea, why those guidelines might be there. And I also know very well in which cases it might make sense to amend those guidelines and create solutions that will make sure that those 2 packages do not diverge (e.g. lacking security updates) while at the same time giving the users the support for the additional formats.
e.g. for openSUSE it is solved by packman just following the original sources in the distro. and the spec file already having the needed conditionals in place to build it fully functional in packman.
If wanted drop me a PM or contact me on IRC and i can show you the details
What would be the steps to do this?
@mjg but fedora ships a whole bunch of packages for jpg 2000, which has the same isobmff āissue.ā
Yes. And darktable already had a tone mapping module already. Would you suggest discussing sigmoid vs. filmic rgb in a Fedora bugzilla entry?
Next time I know better than offering background on Fedoraās packaging situation here, even if it affects darktable users. If you are really interested in an answer to your question (rather than dragging the discussion further OT from OPās concern) you find everything in my posts above.
also libavif 
As an example, mlt-freeworld from RPM fusion provides only libmltavformat.so and similar, and the mlt package in Fedora has everything except a few soās for specific formats. But mlt is a program, and exiv2 is a library ā¦ Maybe it could split out parts into separate soās?
But Iāll mute this thread shortly. Time management ā¦
Iām just trying to get to a solution and avoid the jpg2000 or libavif tangents.
- FR in exiv2 ?
- FR in rpm fusion?
Not sure why you switched to this kinda aggressive tone. you are not the only distribution that has those problems and we actually try to help your users. I just spent a lot of time e.g. to make vkdt and DT work for Fedora users so that they could get up2date packages right after the release.
And the comments about other isobmff enabled packages are actually very relevant for the fedora packaging situation. because right now the packaging is inconsistent as some isobmff related packages are enabled in the distro while others are not.