On Fri, Jan 10, 2003 at 09:44:15AM -0500, Kevin.Hendricks wrote: > >028_fix_x_naming: IZ#7194. Fix X naming. 'XWindows' should be [...] > Issue 7194 does not seem to be related to XWindow vs X Window? > Is there another number we should be looking for here? Ooops, that was #7193, sorry. Martin has approved the issue and also added me to the committers list, so I've checked the changes in. > >024_freetype_macros.diff: IZ#6630 - add support for the new freetype > > internal macro names so that people building against a newer freetype > >(see > > system_freetype.diff) do not have to patch the source. Issue was > >closed > > and no response from the developer concering applying just the > >#defines > > fixes to the source for OOO_STABLE_1 > > I read this issue and was a bit confused at the end. Is the goal to > upgrade to freetype 2.1.3? ... No, that is already taken care of in >= 643 > or ... just to get patches in so that OOO_STABLE_1 will build against > an external freetype (given other patches below)? Yes > I assume you have tested your patch attached to the issue against > OOO_STABLE_1 and it does not hurt anything right? Yes, we've had the patch in for ages, and used it for builds both against the internal and external freetype. > If all your patch does is allow for building against an newer external > freetype and they do not break anything for users of freetyupe in the > OOO_STABLE_1 tree then I have no problems with these patches going into > OOO_STABLE_1 to help support the various linux distributions. > > But Sander, or Martin, or Armin should make the final call on this one > since Herbert never responded to your last question (and he is the > module owner) but he did approve use of freetype 2.1.3 for 644. Yes, fine. > Given the restrictions on the hinting in freetype as used by Sun, I am > in favor of adding config_office switch to allow building with an > external version of libfreetype FWIW. That is a goal which I also have and will work on with Kevin as time permits; even if the hinting problems were to be solved it still makes sense for distros to have the option to use their own versions of 'external' libraries when building native packages for a particular distribtion. On a side note, it seems that building on current Debian unstable with system libfreetype produces wierd errors in setup: [setup using autoresponse file...] unpack file: /usr/local/src/ooffice/openoffice.org-1.0.1/debian/tmp//usr/lib/openoffice/share/template/english/wizard/tplwizletter01.zip. make: *** [debian/stampdir/setup] Error 1 libtricks, when sending message: Invalid argument libtricks, when sending message: Invalid argument I'm not pointing any fingers yet; I suspect a buggy toolchain or libfreetype within Debian may be the cause, since unstable is transitioning to gcc 3.2 as its default compiler. Chris
Attachment:
pgpxULTnUlTBB.pgp
Description: PGP signature