fontconfig problems

Mon Oct 4 23:49:54 UTC 2004

On Monday 04 October 2004 06:24 pm, Nick Hudson wrote:
> 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.

This wasn't a question reguarding me personally as I only run XOrg and have 
been "since the begining."  I'm talking about our users that use the lunar 
provided xfree86(-beta) modules still (god help their soles)... Are they 
going be have issues with the fontconfig module being removed (or is this a 
XOrg needed dependancy only?) -- as I look at 'lvu leert fontconfig', I see 
my own answer, XOrg only... silly me.

Back on the subject of xfree86 (and totally off topic from the thread)... What 
is the future of these modules? How long are we planning on keeping them 
around if they are not "supported?"  Can we create a module directory for 
unsupport/deprecated modules and reloated them there? When we do phase those 
out, we could get rid of two X profile modules:  'xserver' and 
'xservers-profile'

- Chad K
>
> 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
-------------- 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/0cc50a51/attachment-0001.bin