Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


See <https://bugs.documentfoundation.org/show_bug.cgi?id=124503#c9> for the fix for master (towards LO 6.3). While the title and fix both cover a broad scope (any JRE that reports a java.vendor that the LO code doesn't find in its hardcoded list), the issue that prompted the bug and the fix is that Debian and Ubuntu apparently started to distribute OpenJDK versions that no longer announce the well-known Oracle java.vendor string, but instead go with things like "Debian", "Ubuntu", or "Private".

It is not clear to me whether those distros will revert their modifications soonish (so that there would be no immediate need for LO to get anything fixed on our side). If not, the question is whether to backport the above fix to libreoffice-6-1 (towards LO 6.1.6), libreoffice-6-2 (towards LO 6.2.4), and maybe even libreoffice-6-2-3. The fix isn't exactly small, so I would prefer to not backport it aggressively. But I don't know how severely users would be affected by this issue. (I assume that Debian and Ubuntu would take care of the issue for their bundled LO, by updating the hard-coded list accordingly. That could also be an alternative to backporting the above fix here at upstream, but with drawbacks: We would---somewhat needlessly---extend the hardcoded list, even if master already has a fix that makes the additions moot.)

Thoughts, esp. from people involved in the relevant distros?

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.