Hi,
On Fri, Dec 22, 2017 at 12:18:00AM +0100, Martin Schröder wrote:
> 2017-12-22 0:08 GMT+01:00 Matthias Kilian <[email protected]>:
> > And here it is. NOT to be committed, because it breaks pdftex at
> > runtime. (Some use after free or realloc failure, iirc, I don't
>
> Please make sure that patches versions of pdftex and luatex clearly
> identify themselves as such so that mid-/upstream has at least a
> chance to understand bug reports about these versions.
ls /usr/ports/print/texlive/base/patches. Look, it's patched.
When I find a bug, and manage to fix it, I add a patch and leave
it to the maintainer to get it to upstream. I'll *not* start to
fiddle with displayed versions or a special README in that case.
In this special case (luatex and pdftex with new poppler): the
luatex patch is there to make it build with C++-11, so it will be
hopefully obsolete with texlive-2017 (which edd@ is working on).
And the xpdftex patch tries to fix the build with the new
poppler-internal object API (but breaks at runtime), which upstream
(wherever that is for pdftex) didn't seem to touch yet at all.
So what should I display in a version info or wherever (in case I
manage to fix pdftex correctly for poppler > 0.58)? "Note: this
differs from upstream in that it uses a new version of poppler and
fixes pdftex so that it builds and works with a poppler API which
shouldn't be used at all be pdftex'?
No, I'll not start doing things like this. Instead I'm waiting for
oks for the other diff (let texlive use the bundled poppler which
is even more rotten like our current poppler, and which will also
be rotten after the update to texlive-2017).
Ciao,
Kili
