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 http://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: http://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 just for that. (I Volunteer!)
I am currently running xgl on my athlon 64 system from the coffeebuzz overlay. I sure will move to the portage version once it would hit that, and therefore do some testing with it. Time lacks however to do more active work on it :-(.
You most certainly have my vote. Some of you seem to think so and so doesn't work or so and so doesn't work - they can be marked unstable in portage - people can still use 'em if they want to, but other alternatives will still be available. XGL is progressing at a tremenously fast rate, and IMO, it will progress even faster if/when it's added to portage. I would be more than happy to be the maintainer for XGL if needs be if I were a dev... Think about it... The quicker it's added to the tree, the quicker us ATs can get to work on it, and the quicker it'll advance... Looks to me like they're all positives... Anyway... We wanna get as many people running it on their Gentoo installations so that Windows users can see it and install Linux ;)
I don't see a problem with adding it to portage hard masked. That way people that unamsk it should know what they're letting themselves in for when they hit problems ;) I can test AMD64/Nvidia/xorg7.0 if it goes in.
The only reason it should go into portage is if we're trying to make people that are too lazy to read through a whole howto and do what it says step by step start testing Xgl, too. Which, personally, I do not find such an appealing reason. If people want the simple way of only having to unmask a package and emerge it, then those people are not the kinds of people you want testing alpha software, imho. The only other thing Xgl in portage could do, is spread the word of Xgl (but frankly, how many people are browsing portage for new X servers?). People looking for eyecandy will stumble on the howto. There is no need for advertising it in the tree.
I disagree - after all, there's an alpha version of gcc in portage right now. Hell of a lot more critical than an X server. Probably a lot more too but I don't see any value in looking for more examples. As long as there's a volunteer to maintain it in tree, I see no downside to having it there and masked with the standard 'if you unmask this and break your system, be prepared to help fix it' disclaimer. In fact it should help by ensuring documentation, ebuilds and an official maintainer are in place for when it gets more mature and/or hits beta and can start being considered for ~arch. Which should ultimately lead to less or no problems by the time it's finally ready for stable.
(In reply to comment #23) > The only reason it should go into portage is if we're trying to make people > that are too lazy to read through a whole howto and do what it says step by > step ... sorry, but I think this is the wrong point of view - what you call "laziness" is what I see as "the wish to do the things systemically" for example, when the sofware is in Portage, you can use standard tools - namely this Bugzilla - to report bugs ... currently, the HowTo says: "If anyone finds and bugs in this announcement in regards to the update process, please inform me and I will correct it immediately. Your friendly CoffeeBuzz Maintainer, nesl247 - Alex Heck", so I looked at the coffeebuzz website but see no e-mail or contact information ...
(In reply to comment #24) > I disagree - after all, there's an alpha version of gcc in portage right now. > Hell of a lot more critical than an X server. Probably a lot more too but I > don't see any value in looking for more examples. > > As long as there's a volunteer to maintain it in tree, I see no downside to > having it there and masked with the standard 'if you unmask this and break your > system, be prepared to help fix it' disclaimer. In fact it should help by > ensuring documentation, ebuilds and an official maintainer are in place for > when it gets more mature and/or hits beta and can start being considered for > ~arch. Which should ultimately lead to less or no problems by the time it's > finally ready for stable. > In actuality, this is up to whomever (developer-wise) wants to maintain it in the Portage tree. You say the standard "if you unmask..." - the problem is - people who don't know what they are doing DO want to try it out and WILL unmask it and it does lead to unnecessary bugs being opened (already closed/not this package's fault so on and so forth) - Whether there are cvs snapshots, svn snapshots, live cvs, live svn builds IN the Portage tree does NOT matter. What matters is that whomever is willing to take care of this package actually does. Personally, I don't have the hardware to test it - and while I don't think a proxy maintainer is a bad thing, I do not like putting something into the tree that I don't personally use. So, if someone wants to send me the hardware I can use to actually do the testing, I might consider it. For now though, people can easily use the xgl-overlay from hanno (I believe is his name) - being as he seems to be dealing with it already, I trust his judgement that it is in fact NOT ready to be in the Portage tree for whatever reason.
Xgl isn't at a level yet where it should be added it to the tree and supported. I will be happy to add it as soon as there is a release that's mostly working. It's still developed on a branch in the X.Org repository, not even merged into the master, so it's clear that David Reveman doesn't think it's ready either. The hope is that Reveman will merge the xgl-0-0-1 branch into master before the next X.Org release, and so Xgl will be a part of xorg-server at that point with USE=xgl or similar. Adding it as a separate package now is just a hack, when it's already in the same repository.
Don't use the age-old 'if this package can do it then why can't Xgl'. There may be alpha packages in the tree, but that is no argumentation whatsoever for putting Xgl in there, too. Secondly, seriously, it's like we're thinking no further than Xgl. What about all the alpha version deps it has? They may be fairly usable in coffee's overlay, but adding them to portage means gentoo devs will have to support yet another whole lot of alpha packages that can break random things everywhere. I think bugzilla is already being assulted by these kinds of non-valid-'bugs'. The only considderable argumentation I have found in this bug for adding Xgl to portage so far is the fact that it would make bugzilla an official destination for bug discussion. But frankly, gentoo's bugzilla is not the place. Xgl should have a mailing list or bugzilla of it's own for that, it is not gentoo's responsability to play Xgl bugtracker.
(In reply to comment #23) > The only reason it should go into portage is if we're trying to make people > that are too lazy to read through a whole howto and do what it says step by > step start testing Xgl, too. Which, personally, I do not find such an appealing i disagree with this point, i don't think that lazyness is the problem.. I browsed the web and found many howtos related to xgl but following them step by step i have not been able to see xgl working and now i have it installed but i see only the old x interface and i don't know where i did something wrong.. my only option is to start the installation process from zero, maybe after having recompiled all the x stuff (at least 5-6 hours on my machine) but i have no idea of what is wrong with the actual installation.. a portage package could incrementally be tuned to report the correct conflicts or problems helping the debug process.. > If people want the simple way of only having to unmask a package and emerge it, > then those people are not the kinds of people you want testing alpha software, > imho. why? even just saying "it worked on my configuration" or "the installation stops at this point" is useful to debug the package, and can be done even by newbies. this can be a great support.. often more experienced users forget to explain all the passages to make an installation because they take it for "common knowledge". Less esperienced users instead follows each point rigorously and can help to find a detailed step by step installation sorry for the long answer and for the english roby
> I browsed the web and found many howtos related to xgl but following them > step by > step i have not been able to see xgl working and now i have it installed but i > see only the old x interface and i don't know where i did something wrong.. If there is a package in portage, it is not going to be fundamentally different than what is in the overlays at the moment. If you can't get that one to work, than you will likely have just as much luck with a package in the tree. Laziness may have been a bad way of approaching it, but the fact is that using this software may take quite some know-how. Knowhow people that can't make it work out of howto's lack. The software is ready for the tree, as soon as it's ready for those people. As soon as nobody fails installing the software from the overlays. > often more experienced users forget to > explain all the passages to make an installation because they take it for > "common knowledge". Less esperienced users instead follows each point > rigorously and can help to find a detailed step by step installation Frankly this sort of polishing up belongs more in a final beta, but that's my opinion again.
(In reply to comment #30) > If there is a package in portage, it is not going to be fundamentally different > than what is in the overlays at the moment. If you can't get that one to work, > than you will likely have just as much luck with a package in the tree. Yes this is true but it's not my point.. it's not a problem for me if i don't reach a successfull installation, but i would be very happy to know if the problem is some package conflict, or a library crash, or a configuration issue.. the portage dependency checking system could be of great help to my situation and i think many others give up just for the confusion.. > Laziness may have been a bad way of approaching it, but the fact is that using > this software may take quite some know-how. Knowhow people that can't make it > work out of howto's lack. The software is ready for the tree, as soon as it's Well, i am not a genious of x servers and graphical drivers but i am not a newbie.. i followed each point of the howtos repeatedly but i cannot say if the problem is caused by the nvidia drivers which lock x updates or other things.. roby
(In reply to comment #31) > i would be very happy to know if the > problem is some package conflict, or a library crash, or a configuration > issue.. > the portage dependency checking system could be of great help to my situation > and i think many others give up just for the confusion.. You do have all of these conveniences, too when installing the package from the existing ebuilds as they are in the xgl-coffee-overlay (see the howto-link at the top of the discussion).
I don't understand why do you argue about this. Instead of this make a vote. LET THE PEOPLE DECIDE!
We're dealing with the coherentness of the Gentoo Portage. This isn't a matter of who wants it and who doesn't, this is a matter of what's best for it. And if anyone is to decide, it's the gentoo devs that know what's best for the portage, not the people that don't.
I have the feeling that most people would like to do something like that: emerge -s xgl emerge -av xgl and get some results from the portage-tree. Would it be a compromise to implent a dummypackage like x11-base/xgl that gives an einfo to the wikipage only?
me too i want xgl in portage. I can test.
I'd be glad to see xgl on portage. You have my vote.
You have my vote too.
Compiz seems to be in portage now. Is there any change of the state of putting Xgl into the portage?
Be nice to have XGL in portage. Have my vote.
have my vote for xgl into portage :)
I like XGL/compiz a lot as you all do and as much as I'll love to have it in portage I have to say no. Reason's - it's alpha - it depends on other alpha,cvs and/or beta. - the beryl fork - I bet that most of the people that just said yes, haven't even seen the code. - a bad instalation can easily break your system.
I have to agree with the previous comment. People say yes because they like Xgl, not because they know what's good for portage. Think twice please, dear fellow gentoo'ers. The HOWTO is easy enough for you to get Xgl if you want it.
I'm pretty sure that "not now" was the decision already arrived at months ago. In fact, this bug is officially marked "resolved" with a resolution of "later."
Please stop polluting this bug with unrelated discussions and wrong information. There isn't much pressue on adding xgl at the moment, because with aiglx and nvidia-drivers, I think 90% of our users can run all the fancy stuff already without needing extra ebuilds. To state some things clear, Jorge: >- it depends on other alpha,cvs and/or beta. wrong >- the beryl fork and how's that related to xgl? beryl forks compiz, not xgl.
(In reply to comment #43) > People say yes because they like Xgl, not because they know what's good for > portage. er, maybe I got wrong the Gentoo philosophy, but I thought that it is basically to have something which people like, so saying "no, we will not support one of the most requested feature" means loosing users in favour of distributions that will suit their needs ... in other words, I think that Portage should serve to users, not users to Portage, so if something is "not good for Portage" then we have to work on it to make it good > The HOWTO is easy enough for you to get Xgl if you want it. once again to the above - if we should follow some obscure howtos then why use Gentoo? why not just do everything ourselves? I cannot speak for all the users, but from my point of view, I will not use this until it is in Portage - I will not report bugs to overlay maintainers just to find out that the official ebuilds are different and all my efforts for setting it up and testing are in vain as for the "beta" and "stability" arguments against including it in Portage - sorry, but these are nonsense; people who want stable system do not use ~ keywords and do not unmask packages - and for the others, if they break their systems, it's their fault, it is not the bussiness of the Portage maintainers to do nannies and do not allow users to play with fire (anyway, there is a lot other highly unstable stuff already included)
(In reply to comment #45) > Please stop polluting this bug with unrelated discussions and wrong > information. > There isn't much pressue on adding xgl at the moment, because with aiglx and > nvidia-drivers, I think 90% of our users can run all the fancy stuff already > without needing extra ebuilds. > 90% of the cards outthere are nvidia? I though you said we should stop putting wrong information on the bug report. > To state some things clear, Jorge: > >- it depends on other alpha,cvs and/or beta. > wrong how about the nvidia drivers you just mention isn't that beta? xgl is 0.0.1 xgl ebuild says >=media-libs/mesa-6.5.1_pre20060714 isn't that non-released? the code is moving so fast that the ebuilds have dates not versions on it. > > >- the beryl fork > and how's that related to xgl? beryl forks compiz, not xgl. > yes which means that to get a full working GUI environment you need either compiz or beryl
(In reply to comment #47) > (In reply to comment #45) > > Please stop polluting this bug with unrelated discussions and wrong > > information. > > There isn't much pressue on adding xgl at the moment, because with aiglx and > > nvidia-drivers, I think 90% of our users can run all the fancy stuff already > > without needing extra ebuilds. > > > 90% of the cards outthere are nvidia? I though you said we should stop putting > wrong information on the bug report. The mesa in portage which is used by all xorg drivers supports GLX_EXT_texture_from_pixmap or whatever that thing is called. > > To state some things clear, Jorge: > > >- it depends on other alpha,cvs and/or beta. > > wrong > > how about the nvidia drivers you just mention isn't that beta? > xgl is 0.0.1 > xgl ebuild says >=media-libs/mesa-6.5.1_pre20060714 isn't that non-released? Last time i check >=media-libs/mesa-6.5.1_pre20060714 matched =media-libs/mesa-6.5.1-r1 which is released and in portage. > the code is moving so fast that the ebuilds have dates not versions on it. Correct for the prereleases, but see above. > > > > >- the beryl fork > > and how's that related to xgl? beryl forks compiz, not xgl. > > > yes which means that to get a full working GUI environment you need either > compiz or beryl > XGL does not depend on compiz/beryl, it's just needed to get all features, you can run XGL without it though.
What is the current status of this? It seems that the required mesa version is already in portable (and even marked stable), so what else is needed to get xgl accepted in portage?
(In reply to comment #49) > What is the current status of this? It seems that the required mesa version is > already in portable (and even marked stable), so what else is needed to get xgl > accepted in portage? > See comment #27. Xgl still hasn't been merged into xorg-server proper. I'm not sure what upstream's plan is.
Look at all the people dropping their e-mails from this bug like it's hot, giving up hope that Gentoo's ever going to have XGL. Rightfully, since some other distributions have managed it for a long time, and Gentoo was once (about five years ago) supposed to be cutting-edge. Sad.
(In reply to comment #50) > See comment #27. Xgl still hasn't been merged into xorg-server proper. I'm > not sure what upstream's plan is. It looks like the Xgl code is evolving into the new Glucose acceleration architecture. So the Xgl server proper will never see a release, but Glucose will be added in a similar fashion to EXA.
(In reply to comment #51) > Look at all the people dropping their e-mails from this bug like it's hot, > giving up hope that Gentoo's ever going to have XGL. Rightfully, since some > other distributions have managed it for a long time, and Gentoo was once (about > five years ago) supposed to be cutting-edge. Sad. Gentoo's had Xgl for ages in overlays, which is where it belongs. So I don't really see your point.
Overlays that people make aren't part of Gentoo, they're things individuals have to create on their own so they can have things that Gentoo doesn't have. So Gentoo doesn't have XGL (or this bug wouldn't exist), and apparently never will at this Debian stable-like pace.
(In reply to comment #54) > Overlays that people make aren't part of Gentoo, they're things individuals > have to create on their own so they can have things that Gentoo doesn't have. > So Gentoo doesn't have XGL (or this bug wouldn't exist), and apparently never > will at this Debian stable-like pace. > without going into fights I think this shouldn't land in portage XGL is a hack and was coded knowing it was a hack, that said it's currently the only way many people have to be running compiz/beryl, now as Donnie pointed out they have been many overlays and the current one http://www.gentoo-xeffects.org/ IMO is great it even beats some "official" ones like the beryl ubuntu packages. PS: thanks nesl247 for your great overlay. as for "not part of gentoo" where have you been living? most overlays are maintained by devs and they are a critical part of gentoo this days, they are repo's of testing software (yes xgl is one of those).
to concur with #55, AIGlX is part of gentoo isn't it? It's an xorg flag. nvidia drivers that support it is part of gentoo. So there ya go. XGL is as mentioned a hack, to get development going, AIGLX is the same sort of temporary hack in a way. The replacement for both will be Xegl, but that I think is years off. If your talking about beryl/compiz, then maybe I could agree, however they are going through a merge fase atm so wouldn't count on it being in portage too soon. I for one don't think we should put it into portage until AGILX is available (stably) on both nvidia and ati drivers (and obviously all them others aswell sorta).
(In reply to comment #51) > Look at all the people dropping their e-mails from this bug like it's hot, > giving up hope that Gentoo's ever going to have XGL. I guess this may be because of aiglx+beryl solution ... (In reply to comment #55) > as for "not part of gentoo" where have you been living? most overlays are > maintained by devs and they are a critical part of gentoo this days, they are > repo's of testing software (yes xgl is one of those). this is only a bad joke, isn't it? but I am getting used to it, it is not for the first time since Gentoo lost its pride (as mentioned within comment #51) that users are told "do it yourself" ... the current dev-team seems to ignore the basic principle of making distro to serve the users and they prefer to play on their own grounds ... sorry to say that but I am really pissed off by some of the "superhumans" here :-( I've heard that in Arch Linux, there is one central repository maintained by the developers and one "unofficial" repository with users submissions, which may eventually make it into the central one, so if something is missing, one can take a look at a single place and then, if the thing is missing, improve the distro by submitting his package ... in the good old days of Gentoo it worked similar way: there was Portage, and there were many ebuild submissions in bugzilla, which could eventually made it into Portage (and if you missed something, you took a look into bugzilla) - now nearly nobody supports the centralised effort, there are dozens of overlays instead, with mutually incompatible software, package.keywords and package.unmask files growing to infinity, no chance to hunt a bug and no will to cooperate once again, "most overlays ... are repo's of testing software (yes xgl is one of those)." - where the heck is the logic in this? don't we have package.mask and ~arch for the purpose of working with unstable/testing software? what is the reason for not trying to integrate something with the core of the distribution but rather trying to set it up somewhere aside? does really everything (or rather say everybody) need its (his) own sandbox? yes, I'm really sad today :-( sorry, things like these should go to the forums (and it seems I am repeating myself anyway), but for me, it is on topic if this is a question "official vs. overlays"
(In reply to comment #57) > (In reply to comment #55) > > as for "not part of gentoo" where have you been living? most overlays are > > maintained by devs and they are a critical part of gentoo this days, they are > > repo's of testing software (yes xgl is one of those). > > this is only a bad joke, isn't it? Unfortunately, I think they were serious. Presented with such a powerful argument like that, I didn't even bother responding (and not just because it had absolutely nothing to do with what it purported to be responding to). Gentoo has lost touch with users (not just "its" users, but users in general, if it is believed that almost anyone is going to go for all this overlay crap, especially when other distributions, some even based on Gentoo, manage to give people all this stuff they want just fine).
(In reply to comment #57) > but I am getting used to it, it is not for the first time since Gentoo lost its > pride (as mentioned within comment #51) that users are told "do it yourself" > ... the current dev-team seems to ignore the basic principle of making distro > to serve the users and they prefer to play on their own grounds ... sorry to > say that but I am really pissed off by some of the "superhumans" here :-( I'm mildly annoying with users claiming that current devs need to do this and that. The reason I joined Gentoo is because I wanted to help out with X. Most of the work I do is to keep our official X packages up to date, and, yes, I spend most of my time on the parts I enjoy and less on the parts I don't. I'm glad you're interested in Xgl and want to see it in Gentoo, but I just simply don't have the time or interest to maintain it. If you want to see Xgl in Portage, join and maintain it! I'd encourage anyone with the desire and knowledge to become a dev do so. Or provide patches, or make an overlay, etc. Things like xprint are generally only functional because an interested user stepped up and provided patches to make them work. We don't have unlimited time, and we don't have unlimited resources. In fact, we're just users, like yourself, who got involved. Overlays are probably the best thing that could have happened to Gentoo, because it allows everyone to try things that devs don't have time or interest to maintain. As a side note, Hanno has asked the creator of Xgl for an update on its development status, but, as Donnie has pointed out, it looks like Xgl is changing shape and will be included in the mainline in a different form one day.
Now, that of course sounds very different - at least for me, personally, the answer "we won't put it in portage because current devs don't have resources to maintain it" is much more acceptable than some reasoning implying that the policy is now to exclude any packages from portage that aren't completely stable or will go under major transformation "one day".
(In reply to comment #60) > Now, that of course sounds very different - at least for me, personally, the > answer "we won't put it in portage because current devs don't have resources to > maintain it" is much more acceptable than some reasoning implying that the > policy is now to exclude any packages from portage that aren't completely > stable or will go under major transformation "one day". > Don't get me wrong - stability and transformation plays into this a bit :) In general (I reiterate, *not* referring to Xgl in particular), things that are unstable, under-maintained, under-supported and expected to undergo change take more effort to properly maintain in the tree than those that are given lots of upstream attention and thought. Back on topic, that's another reason why you see something like ffmpeg in the tree and not Xgl. (I choose ffmpeg because we've been maintaining CVS snapshots of the same version for over two years, which is what we'd have to do for Xgl). ffmpeg recently had a security bump. The fix was done in upstream's CVS and so we just had to take another snapshot of it. As far as I'm aware, the Xgl branch has unresolved security issues that have been fixed in the mainline. On top of this, Xgl doesn't have Xrandr 1.2 support, it doesn't have input hotplug support, etc etc. (or am I completely off my rocker?). Has there been stuff added to the Xgl branch? Yes, but not a whole lot recently[1]. Any other package in the tree with this level of upstream maintenance would be dropped into someone's overlay or drop-kicked completely. Thankfully, there are people who are willing to maintain it in an overlay, and probably give it more attention than we would be able to if it were in the official tree. http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=shortlog;h=xgl-0-0-1
I've got beryl and nvidia, no need for Xgl for me. Not removing CC for the reason stated in comment #51
As a quick note, it seems most people are forgetting that at this point XGL is only really useful for those running closed-source ATI drivers. Compiz and Beryl run with AIGLX and with the new nvidia-drivers. People should instead be looking at Compiz and Beryl and either testing open-source drivers for ATI or complaining to ATI for missing features. I'm still using XGL because of the ati-drivers, but I should really start looking at the free drivers. I also have nvidia+beryl on my amd64 desktop and it works a lot better!
Gentlemen, just my $0,02 ofcontribution both Compiz and Beryl have been merged as compiz-fusion, so the debate now is how stable compiz-fuzion are. Please add Xgl+compiz-fusion to portage . (In reply to comment #47) > (In reply to comment #45) > > Please stop polluting this bug with unrelated discussions and wrong > > information. > > There isn't much pressue on adding xgl at the moment, because with aiglx and > > nvidia-drivers, I think 90% of our users can run all the fancy stuff already > > without needing extra ebuilds. > > > 90% of the cards outthere are nvidia? I though you said we should stop putting > wrong information on the bug report. > > > To state some things clear, Jorge: > > >- it depends on other alpha,cvs and/or beta. > > wrong > > how about the nvidia drivers you just mention isn't that beta? > xgl is 0.0.1 > xgl ebuild says >=media-libs/mesa-6.5.1_pre20060714 isn't that non-released? > > the code is moving so fast that the ebuilds have dates not versions on it. > > > > > >- the beryl fork > > and how's that related to xgl? beryl forks compiz, not xgl. > > > yes which means that to get a full working GUI environment you need either > compiz or beryl >
Don't bother, Gentoo seems to have long ago taken the Debian stable attitude regarding XGL, combined with a big dose of "Portage? We don't need no stinkin' Portage as long as you can hunt down some overlay someone made." Hence why every comment posted on here results in more people giving up and taking themselves off the e-mail list. At this rate, expect this in Portage sometime around 2023, five years after the last bug was found. If only such stringent standards were followed with all the other broken shit in Portage.
Ideally, all it *should* require is someone willing to maintain the ebuild(s), and adding a ~ in front of the arch so that it's labeled "testing". Unfortunately, in reality politics come into play, with some people deciding what is or isn't good for other people. Whatever happened to Larry the Cow? http://www.gentoo.org/main/en/about.xml
... and reality bites :) g'luck to you all with this.
(In reply to comment #66) > Whatever happened to Larry the Cow? He got tired of all the years of waiting and changed distributions.
(In reply to comment #65) > Don't bother, Gentoo seems to have long ago taken the Debian stable attitude > regarding XGL, combined with a big dose of "Portage? We don't need no stinkin' > Portage as long as you can hunt down some overlay someone made." Hence why > every comment posted on here results in more people giving up and taking > themselves off the e-mail list. At this rate, expect this in Portage sometime > around 2023, five years after the last bug was found. If only such stringent > standards were followed with all the other broken shit in Portage. > please don't leave lame messages in bugzilla it's slow already. I'm behind the devs in here XGL itself is *broken* and is never going to be fix becuase they are better ways to do this, ones those are in place this is not needed, now as usual all that's needed for this to work is a maintainer, are you willing to do so? by the way I deleted myself from CC because I don't care about your ranting so don't bother replying since I know you won't take the ebuild responsabilities, if by any chance you do CC me I'll help out with any questions you may have even if I don't use XGL anymore.
Was it necessary to spam Bugzilla with a rant about lame messages and how we should use a "better XGL" that doesn't exist and probably isn't going to any time soon? Why don't you go create this "better XGL" and quit complaining about how XGL "is never going to be fix [sic] becuase [sic] they [sic] are better ways to do this"?
bugzie.
Cleaning old bugs with state LATER. This one is WONTFIX because xgl server has been deprecated.
