patches on FC3 Re: [ANN] X11R6.8.2 Release Candidate 1 is out!

[Sergio Monteiro Basto]

About old stuff :) 

I don't replay this message later because I don't had nothing to say.
A big thanks for your replies Mike.
This src.rpms provides me a way to compile newer versions of xorg.
I had compile src.rpms from Fedora devel repo, on other machines and I
am very happy with it, none problem found.
But I like to try, especially for savage-dri drive, make one src.rpm 
from CVS head, this way I can install Xorg without overwrite everything
on /usr/X11 and others problems that have been argued on this thread.

The big problem is to know what patches should I apply ?  none !?

thanks,

On Sun, 2004-12-26 at 00:41 -0500, Mike A. Harris wrote:
> Sergio Monteiro Basto wrote:
> > +#define BuildDevelDRIDrivers YES
> 
> The Devel drivers are not part of the normal set of drivers built in 
> X.Org, because they are in a state of development, and are either 
> incomplete or insecure, or both, or have other known major issues of 
> some sort.  Once these drivers are considered both stable as well as 
> secure, they will probably be changed to be built by default in X.Org 
> upstream however.
> 
> While we will not ship or support drivers that are known unstable or
> insecure in Fedora Core, we definitely encourage developers and/or users
> to compile the devel drivers and test them and report bugs to X.Org
> bugzilla, as this will help greatly to stabilize them so they can be
> included by default in future X.Org releases.
> 
> I don't believe Savage DRI works properly currently.
> 
> 
> > 1 - 26 patches applied, some of than are marked has important, why they
> > aren't applied on xorg cvs, yet ? ( if I got a problem will be more
> > difficult trace it).
> 
> In general, like Kristian has mentioned, we want to get as many patches 
> upstream into X.Org as possible.
> 
> One of our goals is to have as few patches in the Fedora Core xorg-x11 
> spec file as possible, by having future patches merged directly into 
> X.Org CVS head first, before we apply them to our rpms.  In some cases 
> however, we need hotfixes right away, and may apply them prior to their 
> inclusion in CVS head.  We definitely want to minimize that as much as 
> possible however, as it is beneficial to both X.Org, and to us, to have 
> all patches upstream, rather than having to cart them around for a long 
> time.  Hopefully we will have gotten all of the relevant patches merged 
> into X.Org prior to the next major release (X11R7?).
> 
> 
> > 2- This one, is a old question but seems, to me, appropriated.
> > xorg-x11-devel has included all xorg-x11-Mesa-devel and if I want
> > compile Mesa from sources it is a big confusion, so for me should be
> > split ed.
> 
> When X.Org is modularized completely, it may make sense to have Mesa as 
> a separate set of RPM packages again, if it builds with DRI support 
> outside of the X source tree now.  In the past, Mesa didn't build with 
> DRI support, and required extra effort to build it DRI enabled outside 
> of X packaging.  Once we no longer had to support software GL on 3.3.6 
> servers, we stopped shipping Mesa separately in order to reduce the 
> maintenance overhead of maintaining the heavily hacked up rpm packages. 
>   Definitely not something we'd want to do again.  ;o)
> 
> If Mesa builds standalone now with DRI support though, or builds against 
> the X.Org SDK or whatever, this would be something worth investigating. 
>   I don't follow Mesa development that closely nowadays though, so I'm 
> not quite sure if this is true or not, but I'm sure someone reading this 
> can confirm/deny for me.
> 
> > but the worst is, GL includes are putted on /usr/include/GL
> > instead /usr/X11R6/include/GL why ? if I compile xorg from cvs make
> > install puts it on /usr/X11R6/include/GL why you change the location ? 
> 
> The OpenGL ABI on Linux officially specifies that libGL (or a symlink
> to the libGL) must reside within /usr/lib, and the headers must be in 
> /usr/lib/GL (or a symlink pointing to them).  In our OS, the GL libs in 
> /usr/lib are actually symlinks pointing to the actual X.Org supplied
> libGL, libGLU, which is OpenGL ABI compliant.
> 
> The headers also must be in /usr/include/GL for compliance, although
> that can also be a symlink to elsewhere legally.  You can of course move 
> the symlinks around if you wish, but rpm based upgrades will either 
> break, or will overwrite whatever you put in there outside of rpm 
> context, so I would highly discourage doing so.
> 
> The best place to put 3rd party libGL replacements and headers is in 
> /usr/local/ or /opt/ or somewhere else, and properly pass the compiler 
> the right flags to have it use the right includes/libs.
> 
> Hope this helps.
> TTYL
> 
-- 
Sérgio M.B.