fontconfig problems

[Chad Kittel]

On Monday 04 October 2004 10:15 am, Nick Hudson wrote:
> I may or maynot have a nice solution to the fontconfig problems.
> Instead of using the fontconfig module, why dont we use fontconfig that
> comes with XOrg??  This way fontconfig is updated each time XOrg is,
> also it would minimize the risk of problems.  Since Xorg is on a release
> schedule so is fontconfig and with each release fontconfig will be
> updated to the latest version.  Let me know what you think??

Does this cause a problem with xfree86(-beta) users?  If it does, is it time 
to totally phase those modules out or are we still planning on supporting 
those?

- Chad K.

> Also I have a few more tests to run on the new version of XOrg, but it
> doesnt look like it will be much longer on getting a new release out.
> Once I do that then I can start on Gnome 2.8.  Speaking of Gnome 2.8 how
> close are we on having a "stable" 2.6 kernel??  When are we planning on
> moving to a 2.6 kernel??  Gnome 2.8 depends heavly on Gnome 2.8,
> expecially DBUS and HAL.
>
> Nick
>
> Auke Kok wrote:
> > Jerry Lundström wrote:
> >> Nick Hudson wrote:
> >>> Yeah its a good idea, or maybe we could update fontconfig with a new
> >>> XOrg release and just have them recompile together??  Either way
> >>> sounds like a better plan.   ATM I have some major issues with
> >>> getting any xserver to compile so I cant test any of this till it
> >>> gets fixed, but I think if we only update fontconfig when a new XOrg
> >>> version comes out this wont happen again.  Or we can just spawn off
> >>> a Xorg, Pango and Gtk2 rebuild after you compile fontconfig.
> >
> > I was hoping something "shorter" and "sooner". I'm sure we can come up
> > with an informational message (the fontconfig upgrade was how long
> > ago?) that at least explains the issue and suggests the easiest
> > approach *today*.
> >
> >> Why not just do a lunar rebuild everytime you install a module? that
> >> way we never need to bother checking what new versions/module do.
> >
> > well erm
> >
> >> ...
> >> ...
> >> ...
> >> ...
> >>
> >> OR MAYBE we should start taking care of libraries?!?!
> >
> > go get your coffee first, read your comics and think again
> >
> >> We dont make any effort in checking how libs are installed today and
> >> if we dont start this will not be the first problem we will have.
> >> If you havn't noticed libexpat change a few weeks ago, it installed
> >> itself as .so.1 and suddenly changed to .so.0 breaking some other
> >> programs that was linking to .so.1 .
> >>
> >> Sure we can ignore the big problem and just tell everyone to rebuild
> >> most of thier system when a lib change.... or we could global
> >> solution/guideline on how to deal with libs.
> >
> > neither works, lunar is still a distro that requires manual
> > intervention and the more we automate the solution the more software
> > is rebuilt and the more problems you will get if you don't cover all
> > corners.
> >
> > We cannot cover all corners.
> >
> > That said I don't think we should let this pass but I am much more
> > enthusiastic to frequent communications from the dev group towards
> > users about possible issues and guidelines etc than increasing the
> > load on our users. This comes from 2 viewpoints:
> >
> > 1) our users are smart
> >
> > 2) our users can be smarter if we tell em how
> >
> > Everytime I fix a core bug I am ashamed about the amount of
> > documentation we have. At least I am trying to communicate horizontal
> > and vertical to cover my ass in this type of problems.
> >
> >> I leave it up for the collective decision of ALL lunar-devs (in other
> >> words, reply to this thread or your say has nothing of value).
> >
> > ehmmmmmm did you get your coffee yet?
> >
> > okay you do have a point. I'll come back to it later.
> > _______________________________________________
> > Lunar-dev mailing list
> > Lunar-dev at lunar-linux.org
> > http://lunar-linux.org/mailman/listinfo/lunar-dev
>
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://lunar-linux.org/mailman/listinfo/lunar-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lunar-linux.org/mailman/private/lunar-dev/attachments/20041004/afa78438/attachment.bin