Package Details: compiz 0.9.14.2-10

Git Clone URL: https://aur.archlinux.org/compiz.git (read-only, click to copy)
Package Base: compiz
Description: Composite manager for Aiglx and Xgl, with plugins and CCSM
Upstream URL: https://launchpad.net/compiz
Licenses: MIT, GPL-2.0-or-later, LGPL-2.1-or-later
Conflicts: ccsm, compiz-bcop, compiz-core, compiz-fusion-plugins-experimental, compiz-fusion-plugins-extra, compiz-fusion-plugins-main, compiz-gtk, compizconfig-python, libcompizconfig, simple-ccsm
Provides: ccsm, compiz-bcop, compiz-core, compiz-plugins-extra, compiz-plugins-main, compizconfig-python, libcompizconfig
Submitter: None
Maintainer: xiota
Last Packager: xiota
Votes: 168
Popularity: 0.78
First Submitted: 2014-08-04 13:22 (UTC)
Last Updated: 2025-03-31 09:11 (UTC)

Required by (27)

Sources (10)

Latest Comments

« First ‹ Previous 1 .. 39 40 41 42 43 44 45 46 47 48 49 .. 56 Next › Last »

devrs0 commented on 2013-08-27 16:13 (UTC)

Seems to be an issue with the included libs from your xorg. I'm not sure how compatible this is the latest xorg versions. I built this using xorg 1.13.

<deleted-account> commented on 2013-08-27 14:18 (UTC)

This package fails to build for me with the error: In file included from /var/tmp/yaourt-tmp-rob/aur-compiz-dev/src/compiz-0.9.10.0/src/screen.cpp:55:0: /usr/include/X11/extensions/XInput2.h:173:22: error: conflicting declaration ‘typedef unsigned int BarrierEventID’ typedef unsigned int BarrierEventID; ^ In file included from /usr/include/X11/extensions/XInput2.h:33:0, from /var/tmp/yaourt-tmp-rob/aur-compiz-dev/src/compiz-0.9.10.0/src/screen.cpp:55: /usr/include/X11/extensions/Xfixes.h:274:17: error: ‘BarrierEventID’ has a previous declaration as ‘typedef int32_t BarrierEventID’ typedef int32_t BarrierEventID; Am I the only one with this problem? Compiz-bzr package does the same thing.

nuc commented on 2013-08-12 01:18 (UTC)

Compiz stable might be dropped from the repos but it still exists in the AUR: https://aur.archlinux.org/packages/compiz/ So it is only resonable to mark dev versions as dev and stable as stable, even if only to avoid confusion. I don't see the point in renaming and calling it stable branch if it's an unstable branch. Renaming brings no gain at all, but has only negatigve effects. Keeping the current name does make totally sense here, changing it doesn't.

whynothugo commented on 2013-08-11 16:45 (UTC)

I've used 0.9.x for over two years now, without ever using (or installing) unity, and fail to see any issues. In any case, arch has dropped 0.8, so we can consider it depricated (even though upstream differs).

nuc commented on 2013-08-11 10:52 (UTC)

0.9.x are dev Versions and only optimized for Unity. 0.8.9 is considered stable and for every DE. Only conmpiz 0.10 or 1.0 will be stable , but that will likely never happen. I for instance still use the 0.8.x branch (which btw got a new release not long ago: v0.8.9). 0.9.x is immature crap for non-Unity. Also see https://lists.launchpad.net/unity-dev/msg00625.html for reference.

whynothugo commented on 2013-08-11 03:18 (UTC)

It was completely dropped from the repos: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-May/024898.html And since there are far newer releases, it's safe to assume it is now deprecated.

nuc commented on 2013-08-10 21:06 (UTC)

@hobarrera: How is compiz 0.8 depreciated? Source?

whynothugo commented on 2013-08-10 17:31 (UTC)

Can we rename this to compiz-core, now that 0.8 is completely deprecated?

« First ‹ Previous 1 .. 39 40 41 42 43 44 45 46 47 48 49 .. 56 Next › Last »