Dear Luca,
Hi! Sorry if it took me a while to get back to you.
I see you have some interest in jpeg-xl package in Debian. You
previously mentioned:
> I'm not sure what we could do to expedite that.
If you work closely with upstream, the most difficult tasks for me
(Debian hat on) were:
* Dealing with convenient copies [*], I could not manage to get rid of
highway and lodepng. Would be nice if those were not required,
I believe it should be possible to use system highway - the relevant CMake flag is DJPEGXL_FORCE_SYSTEM_HWY.
As for lodepng - that's indeed not possible today, but it being a single, AFAIU-not-packaged-anywhere file might make it possible to make an exception there.
Note also that lodepng should only be required for tests and tools, and not for the main libjxl library.
* Use of system lcms2. There is a pending patch that has never been
integrated upstream [**],
A similar patch to allow external lcms2 has been submitted and should be integrated in the next release.
* djxl and cjxl are using the static jxl library. This is not a good
practice (again Debian hat on), since every time we fix a bug in the
shared libjxl, this means recompiling cjxl/djxl for no good reason.
Please make it configurable.
AFAIU, the JXL shared library doesn't expose symbols of the (non-public) C++ library, which would make using it from cjxl and djxl at least somewhat problematic;
we are planning to have cjxl and djxl use the C API, but that's going to take some work still.
* I also see a minor issue with exported symbols in jxl-threads (but I
can live with that).
What kind of issue?
Thanks for your time,
Thank you!
[*] https://wiki.debian.org/EmbeddedCopies
[**] https://github.com/libjxl/libjxl/issues/712
--
To unsubscribe, send mail to 948862-unsubscribe@bugs.debian.org.