fontconfig problems

[Nick Hudson]

Xfree86* is no longer supported by us anymore, or atleast by me.  XOrg
is the future and we made a desicion when XOrg was released to go to
XOrg from now on.  I would suggest if you are running any Xfree86
servers still to upgrade to Xorg, you wont be sorry.

Nick


On Mon, 2004-10-04 at 18:05 -0500, Chad Kittel wrote:
> 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
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://lunar-linux.org/mailman/listinfo/lunar-dev
-- 
Nick Hudson
Lunar Linux Dev Team
http://www.lunar-linux.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lunar-linux.org/mailman/private/lunar-dev/attachments/20041004/d01c19b4/attachment.bin