patches on FC3 Re: [ANN] X11R6.8.2 Release Candidate 1 is out!
Sergio Monteiro Basto
sergio at sergiomb.no-ip.org
Thu Feb 17 14:32:36 PST 2005
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 !?
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.
More information about the xorg