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: 1.06
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 .. 10 11 12 13 14 15 16 17 18 19 20 .. 56 Next › Last »

<deleted-account> commented on 2019-03-28 19:17 (UTC)

@denjack as per muktupavels' comment, could you try building Compiz 0.9.13 (without KDE4 dependencies installed) and seeing if it works for you?

You can build older versions of packages by cloning the git repository and then checking out a previous commit. In general, you can see the list of git commits by running git log in the git repository. But for this case you need to do the following:

git clone <https://aur.archlinux.org/compiz.git>

cd compiz

git checkoutc1a346ae6e69

Sidenote: don't believe what compiz.org says. It is barely maintained. I'm actually surprised it even says that 0.9.13 is the latest version. It said that 0.9.8 was the latest version for years and years, even though that came out in 2012.

muktupavels commented on 2019-03-28 19:11 (UTC)

Does kdecompat works without KDE deps? And works with newest KDE? If so there should not be problems to restore kdecompat plugin...

denjack commented on 2019-03-28 19:07 (UTC) (edited on 2019-03-28 19:09 (UTC) by denjack)

Chazza: Ah, see your EDIT notice now. That is an exaplanation, thank you. Bad news. No window thumbnails in the future it seems. Thank you very much for help.

denjack commented on 2019-03-28 19:03 (UTC)

@Chazza: You are probably right (some dependencies are perhaps missing at the end) but i think the key is other thing - Mint package is of version 0.9.13 whereas yours is 0.9.14. I checked compiz.org for details and noticed 0.9.13 is shown there as the latest stable 0.9. version. Strange... I downloaded it and unpacked. I saw plugins/kdecompat dir under 0.9.13 version whereas it is missing in 0.9.14 (link here among sources links). Tried to adjust PKGBUILD to use 0.9.13 instead of 0.9.14. I needed to comment out processing of two patches (reverse-unity-config and ccsm-unicode-fix) as prepare() section was failed on it (which is understandable). Now i'm fighting with missing files. May be dependecies issue may be not, i'm not so experienced but the name of the missing file doesn't seem to be related to kde, rather compiz itself (i see warning message "FindCompizConfig.cmake" file not found in cmake module directories.). Will see but it seems obvious to me that the source package is the matter. How you came to that incomplete 0.9.14 version if latest one is 0.9.13?

<deleted-account> commented on 2019-03-28 17:28 (UTC)

@denjack Can you have a look at that Mint package and see what the make dependencies are? The build system is most likely disabling compilation of kdecompat because of a missing dependency. I know for sure the kde-window-decorator code was never ported to KDE5. That's probably true of kdecompat as well. Do you have the KDE4 kdelibs package installed? You will surely need that at a minimum.

EDIT: I just checked and as it turns out KDE4 support was dropped upstream for the 0.9.14 release so that explains that. https://git.launchpad.net/compiz/commit/?id=a55d3fb3fc6cdeeae69baffe0ebb9ca84679a692

You will have to either stick with 0.9.13 or reverse apply the commit I linked to above. Sorry about that.

denjack commented on 2019-03-28 17:00 (UTC)

Hello Chazza, thank you for providing this package. Please why there is missing KDE Compatibility plugin in the package? I can see Gnome Compatibility and MATE Compatibility in CCSM but not KDE. KDE Compatibility is needed to have window thumbnails in DockBarX which is the most important, if not the only reason why i'm delaing with compiz. Noticed this plugin is available in Linux Mint compiz package version 0.9.13 i looked for it, but there is absolutely no information about it over the internet. Just as an attempt i tried to change -DBUILD_KDE from Off to On in PKGBUILD of your package and recompile it but no change, even no KDE decorator (the meaning for this configure option as far as i know) have appeared then. Do i something wrong or is the KDE Compatibility really missing in your package and if so why or how it can be add there? Thank you

xebuzer0 commented on 2019-03-25 06:14 (UTC)

@Chazza: Even I'm going to read those wiki pages to see other interesting thinks realated. Now I have a new knowledge that is makepkg with "si" argument, and like some other users, after "rebuilding" Compiz now works as good as always. Thanks a lot!

<deleted-account> commented on 2019-03-24 09:14 (UTC)

Hello xebuzer0

Documentation for the AUR can be found here: https://wiki.archlinux.org/index.php/Arch_User_Repository

I suggest you have a good read through. In fact, all documentation relating to Arch Linux can be found on wiki.archlinux.org. Just search it for your topic of choice.

To very briefly summarise the building part though, the way you build a package is you download the source package (either by going to the package webpage and clicking "Download snapshot" and then extracting the contents of the tarball or by running git clone <https://aur.archlinux.org/compiz.git>). Then you open a terminal inside the directory containing the source package contents and run makepkg -si. The -s option prompts you to install missing dependencies and the -i option prompts you to install the built package. To rebuild, you simply run makepkg again. You first need to remove the .pkg.tar.xz package created last time (assuming the build succeeded) and you might also need to remove the src directory as well if patch is complaining that there are patches that have already been applied.

As for symlinking new library names to old, please, please don't do this. It is NEVER a good solution. Shared library versions don't change for no reason. They change because the new library is not completely completely compatible with the old. If the program linked against the shared library depends on functionality that changed between the old and new versions of the library then you will run into strange problems and nobody will know what's going on. Also, you will get into a mess because you will lose track of which symlinks were created by you and which ones were created by the package manager.

xebuzer0 commented on 2019-03-24 08:16 (UTC)

@Chazza I just have a little problem... there's some documentation about what exactly means and how to "rebuild the package"? I've also tried uninstalling, cleaning cache and reinstalling but I get the same error, and even the sim-link doesn't helps because I get exactly the same error and the same "undefined symbol" string of @GaylairdCulbreth.

Thanks in advance and I hope you can help me, I'm a little newbie in the Arch World.

<deleted-account> commented on 2019-03-18 23:09 (UTC)

@Sebversive If you run an executable linked against shared libaries in the terminal, and any of those links are broken (i.e. /usr/bin/compiz is linked against libfoo.so.5 but libfoo got updated to libfoo.so.6) then you will get a message in the terminal saying something along the lines of:

shared object libfoo.so.5 could not be found.

And at that point you know you need to rebuild the package that provides that executable (in this case compiz). So this problem only occurs if the version number of a shared object file changes.

Some AUR maintainers will bump the pkgrel of their AUR packages every time there's a shared library that gets its version updated and then people that use AUR helpers like yaourt will have a rebuild triggered when they run their helper. I'm afraid I don't do this for compiz though, mainly because I don't use compiz any more so I don't know when the shared library versions change. I only build compiz and run it when there's an update or when there are issues reported here. I have previously stated - and will state again - that if anyone is unhappy with this, I am more than happy to hand over maintenance of compiz to someone else. Just send me an email.

With all that being said about AUR helpers, I would advise staying away from them anyhow, at least until you're completely familiar with how the AUR and building packages work.

Hope this helps

« First ‹ Previous 1 .. 10 11 12 13 14 15 16 17 18 19 20 .. 56 Next › Last »