On Montag, 18. November 2019 00:45:25 CET Albert Astals Cid wrote:
> Any way we can avoid this?
No, not at the moment. It's not just a copy but a patched version of disco=
unt
having two fixes for what we need now for new features in Cantor to be
released in 19.12. This is the work done during Nikita's GSoC project this
summer, details in
https://sirgienkogsoc2019.blogspot.com/2019/07/markdown-and-support-of-emb=
edded.html
https://sirgienkogsoc2019.blogspot.com/2019/07/improved-rendering-of-mathe=
matical.html


The two patches are not incorporated by the upstream yet. For the first, t=
he
pull request is not accepted yet. For the second, a discussion with the au=
thor
was required that didn't happen because of his unresponsiveness.


> Having copies of third party code will be a a real pain in the ass in th=
e
> future.
Yes. After 19.12 we'll check what to do with this - try to re-initiate the
discussions with discoun't author, fork discount and maintain it or use a
different library.


For 19.12 we need to bring https://cgit.kde.org/cantor.git/commit/?
id=3Dfebeff84b016a6f4c93acf45783e7604419a08b4 into release/19.12. Here we =
don't
use any tar archive to avoid problems on build systems where LANG is not s=
et:
https://mail.kde.org/pipermail/release-team/2019-November/011629.html
https://bugs.kde.org/show_bug.cgi?id=3D410802

asturm mentioned yesterday in Matrix/IRC one or two other packagers who
reported this problem, too. And we also added a README file to document th=
e
content of the thirdparty folder in Cantor.


Regards,
Alexander