compiz-0.7.0 was released a week ago according to the timestamps in http://xorg.freedesktop.org/archive/individual/app/ ; could a new ebuild be released?
Created attachment 143712 [details] Proposed ebuild; DOES NOT WORK (see comment) Having played around with creating a 0.7.0 ebuild, apparently the new version relies on x11-libs/libxcb in ways I don't entirely understand. I've attached a proposed ebuild and a couple of patches, but this still doesn't build due to a dependency on the XResource "XGetXCBConnection". I'm not sure how one would go about fixing this.
Created attachment 143713 [details, diff] Copy of compiz-0.6.2-CVE-2007-3920.patch
Created attachment 143715 [details, diff] Fixes dependency on "x11-xcb" to just require "xcb"
Created attachment 143716 [details, diff] Fixes include of "X11/Xlib-xcb.h" to "xcb/xcb.h"
Now compiz supports kde4, so I think the ebuild should add a new USE=kde4, and compiz-fusion should add a new USE=kde4 too. But does x11-libs/qt-dbus:4 needs? i dont know...
Liu, there currently doesn't exist a kde4 USE flag, or at least none I can find listed in http://www.gentoo.org/dyn/use-index.xml or http://gentoo-portage.com/USE. Do you want a new USE flag which, when disabled, throws the "--disable-kde4" flag to the configure script? I guess that'd be easy enough to add...
Created attachment 143934 [details] Proposed ebuild w/ KDE4 USE flag Same as previous ebuild, with KDE4 USE flag added. Still doesn't work, for the same reason as before.
Xlib-xcb.h if part of libX11, but need USE=xcb.. so compiz-0.7.0-configure.patch and compiz-0.7.0-compiz-core.patch are unneccesary. and does we need xcb? maybe we should add a patch to disable xcb.. here has a one: http://gitweb.opencompositing.org/?p=users/3v1n0/compiz-patches;a=summary so i think should add a more USE=xcb
You're absolutely right, Liu; recompiling libX11 resolves these dependencies properly, as well as the lingering XGetXCBConnection problem I noted in my first comment. This does reveal, however, that the API for the ccp plugin which compiz-0.7.0 expects differs from that which is found in libcompizconfig-0.6.0. At least, I ran into ccp-related problems when running my new compiz-0.7.0, and this forum thread makes me think it's an API issue related to libcompizconfig: http://lists.freedesktop.org/archives/compiz/2007-November/002817.html . Since there's no "release" version of libcompizconfig later than 0.6.0, just the git sources, I'm almost tempted to resolve this bug as LATER; anyone else have thoughts on this move?
libcompizconfig depends compiz...do you run revdep-rebuild? i think when you rebuild compiz, you should rebuild everything depend compiz, at least run revdep-rebuild... i have a rather low-end computer, so i wont try. just rebuild everything depends compiz...thats my suggestion.
revdep-rebuild doesn't catch anything, but just oneshotting libcompizconfig somewhat confirms my fears: it won't build against compiz-0.7.0. This may not be soluble without a new libcompizconfig package.
(In reply to comment #11) > revdep-rebuild doesn't catch anything, but just oneshotting libcompizconfig > somewhat confirms my fears: it won't build against compiz-0.7.0. This may not > be soluble without a new libcompizconfig package. > hoho...doesnt catch anything but rebuild libcompizconfig... gentoo always says please rebuild everything depends xxx, dont forget it. and as you said, this question cant be resolved, so you can close this bug. but other distro can run compiz 0.7!
By "doesn't catch anything," I mean that using my ebuild and then running "revdep-rebuild rebuild" doesn't show any programs which need to be rebuilt. I'd need to manually find reverse dependencies for compiz and rebuild them. Sure, I probably should have done that as soon as I saw ccp issues, but it wasn't a completely obvious step. Anyway, I'll mark this as LATER now.
*** Bug 211571 has been marked as a duplicate of this bug. ***
*** Bug 211633 has been marked as a duplicate of this bug. ***
Reopen since the duplicates are annoying like hell.
*** Bug 212779 has been marked as a duplicate of this bug. ***
Hmm, now that a complete release version of compiz-fusion 0.7.2 has come out (at http://releases.compiz-fusion.org/0.7.2/ ), I'd bet this could actually be put through. Someone want to try and throw together some ebuilds? I'll try to do it in a day or two if no one else does.
"Reopen since the duplicates are annoying like hell." Sorry, I considered compiz-fusion and compiz 2 different package sets that just happened to share some core components. That's why I opened a seperate bug. Anyway, thanks for taking care of duping that.
As a stopgap until it's officially in portage, I just renamed the 0.6.0 ebuilds (changing any dep names in each ebuild internally) dropped the ebuilds in my local overlay and it compiled perfectly (though compiz now requires that X11 be built with the XCB use flag). I've been running it for the past 24 hours and it's rock solid thus far. BTW, emerald is MUCH more stable now.
Seconding the "mv'ing the old ebuilds and modifying dependencies" idea; I've had major problems with compiz leaking memory when idle, so if this helps, I'll post in that bug too.
(In reply to comment #17) > *** Bug 212779 has been marked as a duplicate of this bug. *** > Now that you've duped this, are you going to add this to portage anytime soon? x86 is very stable and requires minimal effort (just rename ebuilds and add a USE flag). Just curious, since compiz 0.7.2 came out weeks ago and we've seen nothing yet. Do you need some extra manpower to get this in place? I'll help.
(In reply to comment #22) > Do you need some extra manpower to get this in place? I'll help. Maybe it helps when you attach Your *-0.7.2-ebuilds?
OK, I'll post mine, but frankly it's probably easier for you guys to do what I did, rather than download my versions: copy all of the relevant packages into appropriate subdirectories of /usr/local/portage, rename the newest ebuild to -0.7.2.ebuild, modify the -0.7.2.ebuild to make all relevant dependencies need version 0.7.2, delete any other ebuilds, and digest.
Created attachment 145947 [details] compizconfig-python-0.7.2.ebuild
Created attachment 145948 [details] compiz-bcop-0.7.2.ebuild
Created attachment 145950 [details] compizconfig-backend-gconf-0.7.2.ebuild
Created attachment 145951 [details] compizconfig-backend-kconfig-0.7.2.ebuild
Created attachment 145953 [details] libcompizconfig-0.7.2.ebuild
Created attachment 145955 [details] compiz-fusion-plugins-extra-0.7.2.ebuild
Created attachment 145956 [details] compiz-fusion-plugins-main-0.7.2.ebuild
Created attachment 145957 [details] compiz-fusion-plugins-unsupported-0.7.2.ebuild
Created attachment 145958 [details] compiz-0.7.2.ebuild
Created attachment 145960 [details] compiz-fusion-0.7.2.ebuild
Created attachment 145962 [details] ccsm-0.7.2.ebuild
Created attachment 145963 [details] emerald-0.7.2.ebuild
(In reply to comment #36) > Created an attachment (id=145963) [edit] > emerald-0.7.2.ebuild > Hey guys, just a quick note: I had to manually merge the bcop package before the plugins-extra ebuild would compile correctly. Probably need to change the dependency settings.
compiz-plugins-extra only depends on compiz-plugins-main, not on >=compiz-plugins-main-0.7.2; this is in line with the original ebuilds (compiz-plugins-extra-0.6.2 also only requires compiz-plugins-main). Perhaps I should have changed that; whoever actually puts these into portage should think about this.
Hi, I think the dependency >=x11-themes/emerald-themes-0.5.2 should be removed from compiz-fusion-0.7.2.ebuild
Anonymous, you'd prefer that compiz-fusion only depend on x11-themes/emerald-themes, not any particular version thereof? Could be; I'm not proposing these as actual ebuilds, necessarily, only providing them so that others may upgrade to 0.7.2 before it's actually put into Portage. Speaking of which, I've been using these ebuilds for about a week now, and they seem pretty stable; they haven't fixed my memory leaking problems, but they certainly didn't bring any new ones (so far that I've found.)
(In reply to comment #40) > Anonymous, you'd prefer that compiz-fusion only depend on > x11-themes/emerald-themes, not any particular version thereof? Could be; I'm > not proposing these as actual ebuilds, necessarily, only providing them so that > others may upgrade to 0.7.2 before it's actually put into Portage. > > Speaking of which, I've been using these ebuilds for about a week now, and they > seem pretty stable; they haven't fixed my memory leaking problems, but they > certainly didn't bring any new ones (so far that I've found.) > Is emerald a true dependency (build-time or run-time) for Compiz (Fusion)? I haven't used emerald in quite a while, instead using kwin for window decorations. If emerald isn't a true dependency, just lumped in there as a compositing window decorator, maybe it could be a USE flag (enabled by default) so those of us not using emerald don't even need to pull it in.
compiz-0.7.2 ebuild fails to compile, even with the patches: No package 'x11-xcb' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables COMPIZ_CFLAGS and COMPIZ_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
(In reply to comment #42) > compiz-0.7.2 ebuild fails to compile, even with the patches: > > No package 'x11-xcb' found > > Consider adjusting the PKG_CONFIG_PATH environment variable if you > installed software in a non-standard prefix. > > Alternatively, you may set the environment variables COMPIZ_CFLAGS > and COMPIZ_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details. > I read too quickly for my own good and forgot to enable the xcb useflag for libx11. Oops. And Comment #8 says that the patches config and compiz-core in the compiz 0.7.2 ebuild are unnecessary; if that's so, someone needs to remove them from the ebuild.
(In reply to comment #43) > I read too quickly for my own good and forgot to enable the xcb useflag for > libx11. Oops. And Comment #8 says that the patches config and compiz-core in > the compiz 0.7.2 ebuild are unnecessary; if that's so, someone needs to remove > them from the ebuild. > Yea, I obsoleted those patches when I uploaded my copy of compiz-0.7.2.ebuild. Sorry if that was unclear.
Created attachment 146442 [details] tarball of all ebuilds for compiz-fusion 0.7.2 All of the ebuilds for compiz-fusion 0.7.2. They're already digested, just extract them and add to PORTDIR_OVERLAY. I'm uploading this since it doesn't look like we'll see these in Portage anytime soon. It'll be easier for the lazy people. ;-)
> Yea, I obsoleted those patches when I uploaded my copy of compiz-0.7.2.ebuild. > Sorry if that was unclear. > There seems to be a specific problem with nvidia-drivers... http://forums.gentoo.org/viewtopic-t-673340.html?sid=712d8f6aa1ffc79a21992c635cb8949f eselect opengl set xorg-x11, emerge compiz and resetting oGL to nvidia works fine.
Created attachment 146670 [details, diff] Backported patch from git to eliminate dependency on x11-libs/libX11 being bulit with xcb Backported patch from git to eliminate dependency on x11-libs/libX11 being bulit with xcb (since it's not actually used by compiz)
Created attachment 146672 [details] Updated ebuild to include xcb use tests and ability to build without xcb Updated ebuild to include xcb use tests and ability to build without xcb
By the way, this should probably go without saying, but I screwed it up and so might someone else: If you swap out your current compiz-0.7.2 ebuild for the new, xcb-less one and rebuild your system without xcb, make sure to revdep-rebuild and also re-emerge libcompizconfig, otherwise everything breaks. Unrelated: How goes the process of getting this incorporated into Portage?
Created attachment 148159 [details, diff] Patch to fix emerald alt + tab crash This patch should be applied to emerald , to fix the alt+tab crash. It was taken from ubuntu hardy.
http://lists.freedesktop.org/archives/compiz/2008-April/003074.html A new compiz release 0.7.4 is now available from: http://xorg.freedesktop.org/archive/individual/app/compiz-0.7.4.tar.gz Can we make it to the portage eventually?
Created attachment 148565 [details] Uses urefd.patch; read ebuild to learn where to put it. Here's a emerald-0.7.4.ebuild I've written; it applies the above unrefd.patch (actually, a modified version of that with "0.7.2" replaced with "0.7.4"). I'm pretty sure I messed up the configure flags, though, so I'd like someone to take a look at it.
(In reply to comment #52) > Here's a emerald-0.7.4.ebuild I've written; it applies the above unrefd.patch > (actually, a modified version of that with "0.7.2" replaced with "0.7.4"). I'm > pretty sure I messed up the configure flags, though, so I'd like someone to > take a look at it. I just had a look at the emerald-0.7.4 source tree. It seems to me that the urefd.patch has already been applied. So no need for this in the ebuild anymore. Actually I saw that compiz-0.7.4 was released. I used your work on 0.7.2 and applied the trivial changes to all compiz related ebuilds. I append a compiz-overlay.tar.gz. It contains both the 0.7.2 and the 0.7.4 series of packages.
Created attachment 148805 [details] this contains both the 0.7.2 and 0.7.4 series of packages
Hi Sandy, Thanks for the Overlay. A small bug flipped (in ccsm-0.7.4): DEPEND="dev-python/compizconfig-python-0.7.4 >=dev-python/pygtk-2.10" This should read: DEPEND="=dev-python/compizconfig-python-0.7.4 >=dev-python/pygtk-2.10" Added a corrected attachment (including all digests ;) ).
Created attachment 148848 [details] compiz-overlay.tar.gz from sandy with minor bugfix and all digests included This is actually sandy's overlay with a small bugfix and all digests included.
Closing in favor of bug 216621.
