[Pkg-fonts-devel] fontforge pending issues and uploading to experimental

[Vasudev Kamath]

Hi all,

We had discussed some of build failures with new fontforge which are
listed below.

As Adam noted in earlier mail fonts-pecita will break if we upload newer
fontforge. The issue is known to upstream of both fontforge and pecita
but no conclusion is drawn yet.

> It's a problem known to upstreams of both pecita and fontforge:
> https://github.com/fontforge/fontforge/issues/1747

How should we deal with this?. There seems to be some work around for
building pecita with new fontforge as discussed by pecita author in
above issue. Can we patch the fonts-pecita when we upload new
fontforge?.


We had another issue on mensis, quoting Adam's mail and my reply below.

>> New /usr/include/fontforge/basics.h has:
>> #include <fontforge-config.h>
>> yet during that check that file is not in the include path.  There are two
>> ways to find it: either #include <fontforge/fontforge-config.h> or add
>> /usr/include/fontforge to -I.

> Do I need to inform the upstream about this?. Setting -I might fix it
> but again it might break others isn't it?. I mean the ones with
> fontforge/*.h syntax in the upstream code.

>>
>> Mensis does call configure --includedir=/usr/include/fontforge yet the
>> actual check does:
>> configure:12535: gcc -c -g -O2 -fPIE -fstack-protector-strong -Wformat
>>     -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
>>     -I/usr/include/freetype2/ conftest.c >&5
>>
>> This looks like a bug in mensis rather than fontforge to me, but we can fix
>> it in either.

> Do we need to file bug on mensis?.

Can we have some conclusion on this part?. Bug in mensis or fontforge
upstream need to handle this?..

Another issue is on pdf2htmlex which is similar to the case of
mensis. Quoting Adam's mail and my reply below

>> > * pdf2htmlex
>> >
>> > /usr/bin/cc   -I/<<BUILDDIR>>/pdf2htmlex-0.14.6+ds/src -I/usr/include/poppler -I/usr/include/fontforge
>> > -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -Wall
>> > -o CMakeFiles/pdf2htmlEX.dir/src/util/ffw.c.o   -c /<<BUILDDIR>>/pdf2htmlex-0.14.6+ds/src/util/ffw.c
>> > In file included from /usr/include/fontforge/baseviews.h:30:0,
>> >                  from /<<BUILDDIR>>/pdf2htmlex-0.14.6+ds/src/util/ffw.c:17:
>> > /usr/include/fontforge/ffglib.h:27:18: fatal error: glib.h: No such file or directory
>> > compilation terminated.
>> > CMakeFiles/pdf2htmlEX.dir/build.make:425: recipe for target 'CMakeFiles/pdf2htmlEX.dir/src/util/ffw.c.o' failed

> I checked this is because of same case as above fontforge uses
> -I/usr/include/glib-2.0/ and uses glib.h but probably pdf2htmlex does
> not set -I and probably ends in this error.

> Question is how to deal with this error?. Tell upstream or ask fontforge
> to fix their headers?.

Again we need to decide on how to handle this.

There are some more failing fonts but I've not yet checked them, to
check those I would like to propose upload of new fontforge to
experimental. Is every one is okay with this?.

If every one is okay then I will go ahead and upload new version to
experimental (now that my key has moved from debian maintainers keyring
to debian keyring) and then we can schedule re-build of all packages
which build-depend on fontforge.

Cheers,