I've searched to see if anyone has made a request to add XGL to Portage, but
all I found were bug reports from people acting as if it were already there. So
I am making the request.

From gentoo-wiki.com/HOWTO_XGL, it seems that users have already made
good progress on getting it to work, albeit unofficially. It also mentions two
Gentoo-based Live CDs that use XGL. So it can't be too wild to get XGL working
in Gentoo. Of course, it could be masked with ~arch while necessary. I have
tried the Kororaa Live CD on my desktop, which has dual Opterons and an NVIDIA
card, and it worked just fine.

The faster it's in Portage and being tested, the faster problems will be worked
out. I'm not going to go through that whole song and dance mentioned in the
wiki to install it, but the day it hits Portage, there will be at least one
more person testing it.

So feel  I.
Faboulus XGL in portage, please!

Vote!

What do you mean by "vote"? I know you can do that in KDE's Bugzilla, but I
haven't seen anything about doing so here.

I'm sorry, didn't want to confuse someone.
I'd love we had something like the kde-vote systems, but nope, there isn't
(afaik).
I just wanted to express my accordance ;)

So, in long form:
You have my vote! :)

Well, one could use the number of e-mail addresses on the CC list as a
rudimentary indicator of interest. Considering how many people have added
themselves to this CC list is such a short period of time, I'd say that there's
great interest in adding XGL to Portage. Too bad that doesn't make a maintainer
appear out of thin air, although I recently added a notice to the wiki page
saying that we need a maintainer. Suffice it to say that whoever volunteers
will probably be the most beloved Gentoo maintainer in a long time.

Isnt XGL an area where the Gentoo X project belongs too?
Can't this bug report be merged to the Gentoo X project?

Just a quick comment, I think some of the XGL stuff could be moved to portage.
I just did an install of Xorg 7.0 on the weekend and installed
compiz-quinnstorm and xgl from the xgl-coffee overlay. Then changed a line to
kdm and added the /usr/local/bin/compiz script and modified the kde file in
/etc/env.d and everything has worked flawlessly since. I think once Xorg 7.0
goes stable, some portion of the overlay could be moved into the tree as ~x86
pretty soon after. Of course the more people test the overlay and report bugs,
the better, so if you really want it, go and test it. The great part is that
you can't screw up your normal X.

Beware of 7.1 anyone who is using an nvidia video card. Use 7.0.

Hello. 

Adding Xgl to portage huh. Never thought I'd see the day! Anyway, I currently
maintain the xgl-coffee overlay (I go by CoffeeBuzz on freenode and forums)
along with a two others and I would gladly lend a hand in maintaining if no one
steps up.

Well, I don't see the masses fighting to maintain XGL, so it sounds like you
are our grand prize winner. We need somebody with actual Gentoo authority to
come by and do the whole knighting ceremony and such on you.

If you add xgl to portage, filter the -fforce-addr CFLAG when the mmx USE flag
is set..
On my Athlon-XP, the compilation of xgl-0.0.1_p20060606 fails with the
following error:

 i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include
-I../include -I../include -I../include -I../include -I../include -I../include
-I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus
-I../hw/xfree86/common -DHAVE_DIX_CONFIG_H -DUSE_MMX -mmmx -msse -Winline
--param inline-unit-growth=10000 --param large-function-growth=10000
-D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I../include -I../include
-I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi
-I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb
-mtune=athlon-xp -O2 -pipe -fforce-addr -fomit-frame-pointer
-fprefetch-loop-arrays -funroll-loops -frerun-cse-after-loop -frerun-loop-opt
-falign-functions=4 -mmmx -m3dnow -msse -mfpmath=sse -MT libfbmmx_la-fbmmx.lo
-MD -MP -MF .deps/libfbmmx_la-fbmmx.Tpo -c fbmmx.c  -fPIC -DPIC -o
.libs/libfbmmx_la-fbmmx.o
fbmmx.c: In function `fbCompositeSrc_yv12x8888mmx':
fbmmx.c:2337: error: can't find a register in class `GENERAL_REGS' while
reloading `asm'
fbmmx.c:2337: error: can't find a register in class `GENERAL_REGS' while
reloading `asm'
fbmmx.c:2337: error: can't find a register in class `GENERAL_REGS' while
reloading `asm'
make[1]: *** [libfbmmx_la-fbmmx.lo] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xgl-0.0.1_p20060606/work/xgl-xorg/fb'
make: *** [all-recursive] Error 1

!!! ERROR: x11-base/xgl-0.0.1_p20060606 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_compile
  ebuild.sh, line 939:   Called src_compile
  ebuild.sh, line 1248:   Called x-modular_src_compile
  x-modular.eclass, line 317:   Called x-modular_src_make
  x-modular.eclass, line 312:   Called die

!!! emake failed
!!! If you need support, post the topmost build error, and the call stack if
relevant.

Something tells me there is preciously little interest for this from
wanted@gentoo.org, though.

Or, another possibility could be that there are some of us who are interested,
but simply don't have the hardware to test, therefore are unwilling to maintain
something we can't personally test ourselves.

In reply to comment #10, I had that same problem on two installations. The
error is alluded to here:
gentoo-wiki.com/HOWTO_XGL#inline_unit_growth_error
In reply to the request in general, I believe there is far greater interest
than is shown here, and probably for the reasons listedn in Comment #12
There are a considerable amount of gentoo flavores sites other than the
gentoo-wiki as well as a flood of threads in the forum on the subject. I fear
neither the wiki nor this bug entry have the circulation needed, and perhaps
the lack of full KDE integration isn't helping either ;) As an asside, I have
this running on two machines, installed as per the wiki, and neither has
experienced any stability problems.

But there are serious issues to be adressed before Xgl could be ready for the
tree. For instance, the Xfixes that Xgl comes with is outdated to the one used
by Xorg 7.0. As a result I have had serious issues with any application calling
certain Xfixes calls. I resolved the matter by copying the Xfixes from Xorg
server into Xgl and compiling it like that.

Apart from that dual framebuffer does not work yet, and direct rendering is not
yet available.

Naturally, there are alot of packages in portage already suffering comparably
troublesome issues, and are masked for those exact reasons. Introducing Xgl
into the official tree may give a boost to bugfixes, but it can only happen
through a flood of bugreports that the maintainers that wish to step forward
should be prepared for.

Xgl is something perceived as cool by the general community, and offering it to
them through a source that does not require them to read a HOWTO can lead to
alot of hardship with them. All I'm trying to say is if we want to put this in
the tree, we should be prepared to deal with the results of that. The
alternative is to leave it open to those that wish to try it out through a very
good HOWTO, and put it in the tree as soon as it is ready to face people that
don't want to bother reading a HOWTO, and expect everything to work out of the
box.

(In reply to comment #14)

Many good points. 

Testing is my main concern (similar situation to comment #12). I personally
have a nvidia card on x86 arch. Everything works fine and its very snappy
however, I have a very hard time tracking down performance issues and bugs
relating to ATI and Intel chipsets (in fact, I've given up). 

It would be nice to have at least three maintainers/testers representing the
three chipsets, plus one with amd64 and one with ppc perhaps. 

My desktop has Opterons and an NVIDIA card, and my laptop has a Turion64 and an
ATI card. Both computers will be testing XGL the day it hits Portage. I don't
know about doing anything in any official capacity, since I'm a graduate
student and the last thing I need is more "homework," but I'll definitely be
testing it on both computers (he'll, I'm the guy that initiated this whole
request).

I personally vote AGAINST putting XGL into Portage. It would be a major
mistake. My reasons are as follows:

XGL is rapidly developing
Requires use of compiz (or compiz-quinnstorm which seems more popular)
Compiz is rapidly developing
XGL requires the latest mesa (latest stable is masked) from cvs

I wouldn't disagree with making the CoffeeBuzz overlay (which CoffeeBuzz,
myself and Roderick maintain) the official Gentoo XGL method for getting it and
have a little support from them. But putting such a rapidly developing piece of
software, which has little to no function without another rapidly developing
piece of software is a mistake.

(In reply to comment #17)

I agree with nesl247. I personally dont think its ready, but I'll still try and
convince myself it is ;)

> XGL is rapidly developing

True, but there are semi-stable snapshots. We just currently bump the dates way
too often IMO because we dont have testers so we leave it to all users to
"test" (and this is STILL alpha software so users should = testers). Also, my
current philosophy is "grab the very latest and do what it takes to make it all
work". I originally had testing and trunk overlays because the trunk was
suppose to be the "proven stable for most users" and testing was the "very
latest" for devs and users who could actually submit fixes and useful bug
reports. But alas, I couldn't keep trunk up to date because I was always
playing with testing. I needed another maintainer for trunk. I couldn't do
both.

> Requires use of compiz (or compiz-quinnstorm which seems more popular)

I've had nothing but trouble with compiz-quinn. It's never worked flawlessly,
compiz-vanilla on the other hand works very well so I would add compiz-vanilla.
Compis-quinnstorm has more bells and whistles but until its matured its
inherently bug ridden and unstable.

> Compiz is rapidly developing

True, but again, theres the potential of just keeping stable snapshots.

> XGL requires the latest mesa (latest stable is masked) from cvs

And this is the kicker, XLG's deps. We can't add cvs builds for libdrm, mesa
etc etc to portage. So we could pick xgl/compiz snapshots that DO work with the
versions already in portage (if any) or wait until those pkgs are released and
become available in portage. How the dep's are masked in portage is irrelevant
as xgl/compiz had better be hard masked too.

XGL's deps are a big problem. According to Quinn's changelog, May 3rd was when
compiz required cvs mesa and glproto 1.4.7 (in portage).

I haven't had a problem with -quinnstorm, maybe my system just works nicely.

Stable snapshots of alpha products isn't a great idea. I wouldn't put
XGL/Compiz into Portage until beta hits, or when the amount of issues dies
down. 

For one, the deps need to be in portage. Two, XGL needs to go in then, and hold
off on compiz. 

Compiz right now seems to only work nicely on gnome. (KDE-Window-Decorator even
maintained?) Thus it would need to depend on a large amount of gnome deps. And
once again, KDELibs needs to be patched to get it working with compiz and
virtual desktops (or whatever that patch does that we have).

Too many problems with XGL/Compiz, especially with users not always reading.
For software like this if it wen't into portage, we would need that gcc4.1
pre-portage like flag: I_PROMISE_TO_SUBMIT_PATCHES_WITH_BUGS. And really, with
the amount of trouble with XGL/Compiz, Gentoo might need it's own team