fontconfig problems

[Nick Hudson]

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??
> 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
>
I mean Gnome 2.8 depends heavily on Kernel 2.6.  It doesnt depends 
heavily on itself :)


>
>
> 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