[Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has nomembernamed `find_sbit_image'

[Jim Gettys]

The citizenship thing is to work with freetype to help avoid the
situation coming up in the future to bite us (and others) again.

If we don't get our act together about testing, and testing with
our upstream partners (in this case, freetype), we'll suffer again,
and again, and again...

I'm happy with whatever people think is the right solution.
                               - Jim


On Fri, 2004-07-30 at 10:53, Egbert Eich wrote:
> Jim,
> 
> I don't understand what you are trying to get at.
> The required patch is already part of freetype 2.1.8. We include 
> plain freetype 2.1.8 for convenience. Not any patched version.
> Any shared freetype lib *newer* than 2.1.7 will also work.
> 
> Chisato had convinced the freetype folks to include his patch
> in 2.1.8 so he did exactly what you suggested below.
> 
> The build only breaks when one has a version of freetype installed
> that is *older* than 2.1.8. Like the build of 6.7 broke if one had
> a version of freetype installed that was older than 2.1.7.
> 
> Chisato was following exactly the guidelines that he was given -
> pretty much the ones that you outlined below. 
> Now people suggest to change the rules on him because they don't
> care for his patch and the requirement for FreeType 2.1.8 imposes 
> an inconvenience for them.
> Now is this good citizenship?
> 
> Egbert.
> 
> 
> Jim Gettys writes:
>  > 
>  > I see no problem with requiring more recent freetypes, (or other
>  > dependencies) when there are good reasons.
>  > 
>  > I do see major problems with privately patched versions of dependencies.
>  > Are we to start shipping libc if there are bugs? Or libm?
>  > 
>  > Good open source behavior involves good citizenship with allied
>  > projects: I think we need to grow up and work in the larger community.
>  > 
>  > And given we have a freetype dependency, I think it behooves us to
>  > try to work with the freetype project to detect regressions in their
>  > library *before* it breaks us (or our users in the field).  I suspect
>  > that they'd be very happy to see such testing done in a systematic
>  > fashion, rather than the haphazard fashion to date.  (who knows, maybe
>  > we can encourage them to run one or more tinderclients ;-)).
>  > 
>  > And breaking the build isn't a good situation.  I know we've not yet
>  > worked out policy around broken builds (now that we can detect them); on
>  > many projects, on at least the core development platforms, if the build
>  > is broken, no further check-ins are even permitted, and I suspect such a
>  > policy might serve us well.  But to do this, we have to work out what
>  > our version dependencies are.
>  > 
>  > > 
>  > > > BTW, another problem seem to be that mozilla (and thunderbird) builds
>  > > > fails against Freetype 2.1.9. I've seen that both using OpenBSD's ports
>  > > > and gentoo's portage of mozilla 1.7.1 and thunderbird 0.7. Is there a
>  > > > known workaround for that?
>  > > 
>  > > Not really. Someone wrote patches but they only work with FreeType
>  > > 2.1.8. That's why I start to like the idea with linking the library
>  > > statically into the font code, otherwise the next FreeType2 release may
>  > > cause headache again...
>  > 
>  > Here lies madness.  So in parts of the world that the Apple hinting
>  > patent does not apply, users are supposed to rebuild X? (not to mention
>  > other bugs that may only be discovered later being un-fixable). 
>  > Statically linking private copies just delays the pain, and makes it
>  > harder to fix.
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg