## Package Details: compiz 0.9.14.1-4

Git Clone URL: https://aur.archlinux.org/compiz.git (read-only, click to copy) compiz Composite manager for Aiglx and Xgl, with plugins and CCSM https://launchpad.net/compiz ccsm compiz GPL, LGPL, MIT ccsm, compiz-bcop, compiz-core, compiz-fusion-plugins-experimental, compiz-fusion-plugins-extra, compiz-fusion-plugins-main, compiz-gtk, compizconfig-python, libcompizconfig, simple-ccsm ccsm, compiz-bcop, compiz-core, compiz-plugins-extra, compiz-plugins-main, compizconfig-python, libcompizconfig Chazza robson Chazza 161 0.070738 2014-08-04 13:22 (UTC) 2020-10-23 12:45 (UTC)

### Sources (8)

#### quequotion commented on 2022-05-05 20:14 (UTC)

Maybe just me, but build fails with XML parser errors about 80% of the time (in a clean chroot).

The errors are not always on the same line or of the same nature (sometimes it's Premature end of data in tag short; sometimes it's Document is empty; etc).

This seems to be just luck of the draw. After four failed attempts, changing nothing at all, the fifth worked.

Just in case anyone else had this problem and is about to go down the same rabbit hole I did trying to figure out what is wrong with the XML parser: probably nothing, just keep trying.

#### piotrv commented on 2021-07-13 19:24 (UTC) (edited on 2021-07-13 19:31 (UTC) by piotrv)

I switched to compiz-git before, but since a very recent update of some dependencies as it seems, I can rebuild this package again and working :-)

#### doobd3 commented on 2021-07-06 13:37 (UTC)

Having problem with segfault after last upgrade (today) when starting compiz. tried to remove and rebuild from both compiz & compiz-git, but the same happens, reported here https://bugs.launchpad.net/compiz/+bug/1934789

Seconded :)

#### LeCrayonVert commented on 2021-07-03 13:49 (UTC)

@Chazza thanks for all the hard work those last past years ;)

#### robson commented on 2021-06-22 10:27 (UTC)

And which emarald are you using? because I emerald-gtk3 https://aur.archlinux.org/packages/emerald-gtk3/ and everything works very well for me. Of course emerald-gtk3 is bare without any theme but just go here https://www.gnome-look.org/browse/cat/117/order/latest and download the theme that suits you.

#### ector commented on 2021-06-22 09:26 (UTC) (edited on 2021-06-22 09:34 (UTC) by ector)

Hi everyone, even from some update emerald crashes continuously.
I don't know what it is due to.
I also reinstalled emerald and compiz but the crashes continue.


#### muktupavels commented on 2021-05-10 13:52 (UTC)

Now when you know how to reproduce please get stacktrace and open launchpad bug.

#### robson commented on 2021-05-10 13:31 (UTC)

I found the cause of compiz crashing, when I launch file manager and bring up the context menu, then select create document, and that's when compiz crashes. https://i.postimg.cc/43SCvHJN/Przechwycenie-obrazu-ekranu-2021-05-10-14-56-27.png

#### muktupavels commented on 2021-05-10 13:21 (UTC)

No idea if you need to do something about it but check if you dont have two compizconfig.so files now. There was multi-arch fix for that module so it might be installed in new location. No idea which file would be used if that is the case.

#### robson commented on 2021-05-10 10:54 (UTC) (edited on 2021-05-10 11:11 (UTC) by robson)

I too have never had a problem with compiz working, I recently rebuilt it after updating protobuf, i.e. April 19 and everything worked very well. I think this is due to the changes made 9 days ago https://git.launchpad.net/compiz

#### andym commented on 2021-05-10 10:33 (UTC)

I normally have to rebuild after a linux update, but apart from that I never seem to have any problems. I use compiz stand-alone.

#### robson commented on 2021-05-10 09:52 (UTC) (edited on 2021-05-10 09:53 (UTC) by robson)

What is going on with compiz? Because after building it often crashes, well the screen jumps. At first I thought it was the fault of the new protobuf, but this problem also occurs on the current version of protobuf.

#### Chazza commented on 2021-04-05 21:09 (UTC)

I'm dropping compiz and compiz-git. I don't use them anymore so it makes more sense that an active user continue maintenance.

#### lectrode commented on 2021-03-15 21:24 (UTC) (edited on 2021-03-15 21:49 (UTC) by lectrode)

@robson @Chazza Thank you for checking. Glad to know it doesn't affect everyone. I'll keep digging. Maybe I did something weird in my bash environment

EDIT: Ended up being my version of glib2. Does not affect the version included in the arch repos.

#### Chazza commented on 2021-03-15 21:22 (UTC)

Just rebuilt compiz and I'm unable to reproduce this one. Sorry.

#### robson commented on 2021-03-15 20:54 (UTC)

I rebuilt compiz yesterday after the protobuf update, and the build went without any problems.

#### lectrode commented on 2021-03-15 20:23 (UTC)

Still investigating, but currently I cannot compile this or compiz-git for the protobuf update. Getting this repeating error during the build:

Package >= was not found in the pkg-config search path.
Perhaps you should add the directory containing >=.pc'
to the PKG_CONFIG_PATH environment variable


On first glance it seems like a build dependency update introduced a bug, as it's reading '>=' as a package name)

So far I've tried * downgrading cmake to 3.18.4 * downgrading cython to 0.29.21

Anyone else running into this issue?

#### Autodidaddy commented on 2021-03-03 01:58 (UTC) (edited on 2021-03-09 20:03 (UTC) by Autodidaddy)

Tnx. I'll try workarounds next. I noticed enabling 'Animations Plus' was causing compiz to crash completely at random times. Then I disabled all animations and I haven't had any issues so far.

edit; keep having issues. I have the workarounds enabled now. I was also having issues with the screenshot plugin (very important to me) in that the shots were now faded. Workaround was to disable the selection indicator. Not acceptable.

edit; turns out to be the kernel!! see https://bbs.archlinux.org/viewtopic.php?id=263401

#### Chazza commented on 2021-03-01 19:20 (UTC)

Have you tried this: https://wiki.archlinux.org/index.php/Compiz#Video_tearing

Otherwise I'm not too sure.

#### Autodidaddy commented on 2021-03-01 18:08 (UTC)

I ran into rendering issues, switched back from compiz-git but didn't resolve it. I'm running Plasma now with all desktop effects on and no issues so it's got something to do with compiz. First noticed it with playing DRM video. Then gtk apps started just missing parts, and fullscreen video with mpv suddenly would flicker badly. After reboot everything fine again for some time. Any ideas where to start?

#### Autodidaddy commented on 2021-02-03 17:34 (UTC)

I'm good again! Tnx @ lectrode; learned something there. Rebuilding packages shown by that pacman command didn't work. I tried the command for 3.9 instead of 3.8 which gave me a huge list. Then proceeded to install rebuild-detector. It took hours and hours to rebuild everything that needed to rebuild and while I was at it installed compiz-git. I'm not sure if that fixed the issue for me or switching to compiz-git. I'll stay with compiz-git for now.

#### lectrode commented on 2021-02-02 17:45 (UTC)

@Autodidaddy @wm8120 You can list packages that need to be rebuilt after python update with:

pacman -Qqo "/usr/lib/python3.8/site-packages"


There is also a rebuild-detector in the AUR that may help you out further.

#### robson commented on 2021-02-02 10:43 (UTC) (edited on 2021-02-02 10:43 (UTC) by robson)

If so, try building compiz-git https://aur.archlinux.org/packages/compiz-git/

#### Autodidaddy commented on 2021-02-02 01:34 (UTC) (edited on 2021-02-02 01:37 (UTC) by Autodidaddy)

I don't think it's nonsense @robson. I updated my system and ccsm won't start:

Traceback (most recent call last):
File "/usr/bin/ccsm", line 98, in <module>
import compizconfig
ModuleNotFoundError: No module named 'compizconfig'

Rebuilding compiz didn't fix it. Did you fix the issue @wm8120?

#### robson commented on 2020-12-04 00:15 (UTC)

@wm8120 What nonsense are you talking. I just finished building a compiz, and it is building properly. Update your system before building anything.

#### wm8120 commented on 2020-12-03 23:37 (UTC)

The latest update makes the python upgrade from 3.8 to 3.9 and causes several module cannot import, e.g. compizconfig. Because no corresponding packages under /usr/lib/python3.9/site-packages/ directory. How to fix this issue?

#### Chazza commented on 2020-11-02 12:19 (UTC)

@je-ve Metacity is required for metacity theme support in gtk-window-decorator. If you want to use emerald you can just install it and next time compiz starts it should automatically be used - see https://wiki.archlinux.org/index.php/Compiz#Window_decoration. Metacity will remain a hard dependency.

#### je-vv commented on 2020-11-01 23:56 (UTC)

Can metacity be maded an opt depend, or is there any library from it, which compiz uses? See, compiz can be used with emerald from AUR, which I prefer, so I'm not sure why making metacity required.

#### juancri commented on 2020-10-23 22:29 (UTC)

That was fast. Thank you, @Chazza!

#### Chazza commented on 2020-10-23 12:27 (UTC) (edited on 2020-10-23 13:26 (UTC) by Chazza)

Thanks for the heads up folks. Looks like @muktupavels has a patch: https://code.launchpad.net/~muktupavels/compiz/+git/compiz/+ref/remove-unused-or-broken-buttons

I will test it shortly.

EDIT: patch is now applied.

#### eggz commented on 2020-10-23 11:59 (UTC)

AS far as I can see, References to

Are no longer present in the metacity lib.

Proof of concept, add this as the last block under the prepare() directive of the PKGBUILD;

  # Remove old metacity references
sed -i /META_BUTTON_TYPE_SHADE/d ${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c sed -i /META_BUTTON_TYPE_ABOVE/d${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c
sed -i /META_BUTTON_TYPE_STICK/d ${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c sed -i /META_BUTTON_TYPE_UNSHADE/d${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c
sed -i /META_BUTTON_TYPE_UNABOVE/d ${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c sed -i /META_BUTTON_TYPE_UNSTICK/d${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c
sed -i /BUTTON_SHADE/d ${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c sed -i /BUTTON_ABOVE/d${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c
sed -i /BUTTON_STICK/d ${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c sed -i /BUTTON_UNSHADE/d${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c
sed -i /BUTTON_UNABOVE/d ${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c sed -i /BUTTON_UNSTICK/d${srcdir}/${pkgname}-${pkgver}/gtk/window-decorator/gwd-theme-metacity.c


It should build fine now.

#### eggz commented on 2020-10-23 11:28 (UTC)

@Juancri: Confirmed

#### juancri commented on 2020-10-23 08:58 (UTC)

compiz is not compiling with the new metacity version metacity-3.38.0

Output:

/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c: In function ‘meta_button_state_for_button_type’:
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:98:14: error: ‘META_BUTTON_TYPE_SHADE’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_SPACER’?
|              ^~~~~~~~~~~~~~~~~~~~~~
|              META_BUTTON_TYPE_SPACER
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:98:14: note: each undeclared identifier is reported only once for each function it appears in
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:100:14: error: ‘META_BUTTON_TYPE_ABOVE’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_CLOSE’?
100 |         case META_BUTTON_TYPE_ABOVE:
|              ^~~~~~~~~~~~~~~~~~~~~~
|              META_BUTTON_TYPE_CLOSE
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:102:14: error: ‘META_BUTTON_TYPE_STICK’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_SPACER’?
102 |         case META_BUTTON_TYPE_STICK:
|              ^~~~~~~~~~~~~~~~~~~~~~
|              META_BUTTON_TYPE_SPACER
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:104:14: error: ‘META_BUTTON_TYPE_UNSHADE’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_SPACER’?
|              ^~~~~~~~~~~~~~~~~~~~~~~~
|              META_BUTTON_TYPE_SPACER
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:106:14: error: ‘META_BUTTON_TYPE_UNABOVE’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_CLOSE’?
106 |         case META_BUTTON_TYPE_UNABOVE:
|              ^~~~~~~~~~~~~~~~~~~~~~~~
|              META_BUTTON_TYPE_CLOSE
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:108:14: error: ‘META_BUTTON_TYPE_UNSTICK’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_LAST’?
108 |         case META_BUTTON_TYPE_UNSTICK:
|              ^~~~~~~~~~~~~~~~~~~~~~~~
|              META_BUTTON_TYPE_LAST
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c: In function ‘button_type_to_meta_button_type’:
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:557:20: error: ‘META_BUTTON_TYPE_SHADE’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_SPACER’?
|                    ^~~~~~~~~~~~~~~~~~~~~~
|                    META_BUTTON_TYPE_SPACER
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:559:20: error: ‘META_BUTTON_TYPE_ABOVE’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_CLOSE’?
559 |             return META_BUTTON_TYPE_ABOVE;
|                    ^~~~~~~~~~~~~~~~~~~~~~
|                    META_BUTTON_TYPE_CLOSE
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:561:20: error: ‘META_BUTTON_TYPE_STICK’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_SPACER’?
561 |             return META_BUTTON_TYPE_STICK;
|                    ^~~~~~~~~~~~~~~~~~~~~~
|                    META_BUTTON_TYPE_SPACER
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:563:20: error: ‘META_BUTTON_TYPE_UNSHADE’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_SPACER’?
|                    ^~~~~~~~~~~~~~~~~~~~~~~~
|                    META_BUTTON_TYPE_SPACER
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:565:20: error: ‘META_BUTTON_TYPE_UNABOVE’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_CLOSE’?
565 |             return META_BUTTON_TYPE_UNABOVE;
|                    ^~~~~~~~~~~~~~~~~~~~~~~~
|                    META_BUTTON_TYPE_CLOSE
/home/juancri/.cache/pikaur/build/compiz/src/compiz-0.9.14.1/gtk/window-decorator/gwd-theme-metacity.c:567:20: error: ‘META_BUTTON_TYPE_UNSTICK’ undeclared (first use in this function); did you mean ‘META_BUTTON_TYPE_LAST’?
567 |             return META_BUTTON_TYPE_UNSTICK;
|                    ^~~~~~~~~~~~~~~~~~~~~~~~
|                    META_BUTTON_TYPE_LAST
make[2]: *** [gtk/window-decorator/CMakeFiles/gtk-window-decorator.dir/build.make:303: gtk/window-decorator/CMakeFiles/gtk-window-decorator.dir/gwd-theme-metacity.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:4870: gtk/window-decorator/CMakeFiles/gtk-window-decorator.dir/all] Error 2
make: *** [Makefile:182: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...


#### xsilentmurmurx commented on 2020-10-19 05:35 (UTC)

@robson

Thank you that worked!

#### robson commented on 2020-10-18 21:53 (UTC)

The package you are trying to install is the source package. You must install this package https://postimg.cc/GB0MwFDm.

#### xsilentmurmurx commented on 2020-10-18 20:28 (UTC)

I tried to do a pacman -U compiz-0.9.14.1.tar.xz, after I built the package using makepkg -s, and I got this error:

error: missing package metadata in compiz-0.9.14.1.tar.xz error: 'compiz-0.9.14.1.tar.xz': invalid or corrupted package

Please let me know if any other information should be provided so you all can get a better idea of what I am referring to

How do I fix this?

Thanks!

#### firemage78 commented on 2020-08-24 09:00 (UTC)

I apologize for not getting back to anyone due to being offline for family reasons. I just did a system update last night and all went well.

#### piotrv commented on 2020-08-21 09:53 (UTC) (edited on 2020-08-21 10:06 (UTC) by piotrv)

@Chazza

I am using ger.mirror

Whatsoever, the build make error is persistent, unless I use robson's makepkg.conf.

If this is just a local issue at my point, this issue can be closed. However, I am still puzzled and wonder what exactly my similarities are with firemage78..

#### Chazza commented on 2020-08-20 18:27 (UTC) (edited on 2020-08-20 18:40 (UTC) by Chazza)

@piotrv I applied your changes to my /etc/makepkg.conf and was still unable to reproduce your build failure. I should say though, I didn't let my builds progress much past 16% since that's where both you and firemage78 were getting the failure.

EDIT: I let a build progress to 100% with your makepkg.conf configuration. There was no problem.

Did you do a system update just before your successful build? It's possible you guys are using a mirror that's way behind. Check the status of the mirror that you are using here: https://www.archlinux.org/mirrors/status/

#### piotrv commented on 2020-08-19 12:32 (UTC) (edited on 2020-08-19 17:42 (UTC) by piotrv)

@Chazza

Success at last !

The building process does not abort any longer at the warning about missing header fields.

diff makepkg.conf makepkg.my_conf
< CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
< CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
---
> CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
> CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"

< #RUSTFLAGS="-C opt-level=2"

< #MAKEFLAGS="-j2"
---
> MAKEFLAGS="-j$(($(nproc)+1))"

< #DEBUG_RUSTFLAGS="-C debuginfo=2"
< PKGEXT='.pkg.tar.zst'
---
> PKGEXT='.pkg.tar.xz'


I guess the key difference is in MAKEFLAGS. Just my two cents . . .

Built result
-rw-r--r--  1 piotrek piotrek 6689918 Aug 19 14:13 compiz-0.9.14.1-3-x86_64.pkg.tar.zst


Thanks @ robson for providing virgin makepkg.conf.

Now it would be interesting if firemage78 had the same differences in makepkg.conf

#### piotrv commented on 2020-08-19 12:21 (UTC)

@Chazza Success at last !

The building process does not abort any longer at the warning about missing header fields.

diff makepkg.conf makepkg.my_conf

#### piotrv commented on 2020-08-19 12:21 (UTC)

@Chazza Success at last !

The building process does not abort any longer at the warning about missing header fields.

diff makepkg.conf makepkg.my_conf

#### robson commented on 2020-08-18 20:35 (UTC)

Then paste this content into /etc/makepkg.conf this is the original https://pastebin.com/raw/8Rbdy3MZ

#### piotrv commented on 2020-08-18 20:20 (UTC) (edited on 2020-08-18 20:22 (UTC) by piotrv)

I tried old -mtune=x86-64 for CFLAGS and CXXFLAGS, but resolves nothing. back to default, still the same nasty build error . .

#### Chazza commented on 2020-08-18 20:11 (UTC)

Well if you've modified /etc/makepkg.conf then definitely try restoring the default. If you haven't then that won't be the problem.

#### piotrv commented on 2020-08-18 19:14 (UTC) (edited on 2020-08-18 19:16 (UTC) by piotrv)

For what it's worth . . .

%!s(func() string=0x5582c44d2830 and string=0x55b0a1aa7bb0 seems to be string function related. Could it be in differences with the C-compiler flags ?

in my /etc/makepkg.conf:

 #########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j$(($(nproc)+1))"


#### Chazza commented on 2020-08-18 17:08 (UTC)

@piotrv @firemage78 Googling the last line in your build output, I see almost identical looking errors from June of this year but for totally different packages: https://aur.archlinux.org/packages/python-spacy/#comment-751343 https://aur.archlinux.org/packages/pacpl/#comment-751291

The plot thickens... I'll see if I can find out any more.

#### robson commented on 2020-08-18 16:02 (UTC)

Then maybe try to build compiz-git https://aur.archlinux.org/packages/compiz-git/ Maybe you better do.

#### Chazza commented on 2020-08-18 08:57 (UTC)

I have no idea. If I can't reproduce it I can't investigate it unfortunately. robson has confirmed that the package builds OK as well so it seems unlikely to me that it's a packaging issue.

#### piotrv commented on 2020-08-16 17:09 (UTC) (edited on 2020-08-16 17:09 (UTC) by piotrv)

@Chazza I downloaded the snapshot; tried to build it from the PKGBUILD file: exactly the same issue. Might it be related to the intltool package, looking at "warning: header field 'Language' missing in header" for all po files ?

#### robson commented on 2020-08-16 10:32 (UTC)

I just finished building compiz, and it builds fine. I suggest you download the snapshot, unpack it, and go to the compiz directory and run a terminal in it and run makepkg -sirc. And here is the compiz package built. https://i.postimg.cc/wBMnNFTL/Przechwycenie-obrazu-ekranu-2020-08-16-12-25-35.png

#### piotrv commented on 2020-08-16 09:23 (UTC)

@Chazza I cloned the pkg from git , but unfortunately get same issue when building with makepkg, so it seems not yay related . .

#### Chazza commented on 2020-08-16 08:38 (UTC)

@firemage78 @piotrv You both have the same problem but I can't reproduce it at all. I notice you are both building in ~/.cache/yay. Presumably this is the build directory of some AUR helper. Do you still get the error if you just build with makepkg?

#### firemage78 commented on 2020-08-16 05:40 (UTC)

Unable to complete build due to error:

Scanning dependencies of target compiz_gsettings_schema [ 11%] Generating ../generated/glib-2.0/schemas/org.compiz.core.gschema.xml /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/po/hi.po:7: warning: header field 'Language' missing in header /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/build/generated/core.xml:145: parser error : Couldn't find end of Start Tag sho line 145 <sho ^ /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/build/generated/core.xml:145: parser error : EndTag: '</' not found <sho ^ unable to parse /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/build/generated/core.xml make[2]: [metadata/CMakeFiles/compiz_gsettings_schema.dir/build.make:80: generated/glib-2.0/schemas/org.compiz.core.gschema.xml] Error 6 make[1]: [CMakeFiles/Makefile2:7543: metadata/CMakeFiles/compiz_gsettings_schema.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs....

............

[ 16%] Generating zh_TW/LC_MESSAGES/compiz.mo [ 16%] Generating zu/LC_MESSAGES/compiz.mo /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/po/uk.po:7: warning: header field 'Project-Id-Version' still has the initial default value /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/po/uk.po:7: warning: header field 'Language-Team' still has the initial default value /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/po/uk.po:7: warning: header field 'Language' missing in header /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/po/zh_CN.po:7: warning: header field 'Language' missing in header /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/po/zu.po:5: warning: header field 'Language' missing in header /home/joe/.cache/yay/compiz/src/compiz-0.9.14.1/po/zh_TW.po:7: warning: header field 'Language' missing in header [ 16%] Built target nls make: *** [Makefile:182: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... error making: %!s(func() string=0x55b0a1aa7bb0)

#### Chazza commented on 2020-08-15 17:35 (UTC)

@piotrv I'm unable to reproduce that build failure. Sorry.

#### piotrv commented on 2020-08-15 13:09 (UTC) (edited on 2020-08-15 13:19 (UTC) by piotrv)

compilation failure:

CREATED ~/.cache/yay/compiz/src/compiz-0.9.14.1/build/generated/workspacenames.xml
[  7%] Generating ../../generated/glib-2.0/schemas/org.compiz.workspacenames.gschema.xml
[  8%] Linking CXX static library libcompiz_timer.a
[  8%] Built target workspacenames_gsettings_schema
~/.cache/yay/compiz/src/compiz-0.9.14.1/po/as.po:7: warning: header field 'Project-Id-Version' still has the initial default value
~/.cache/yay/compiz/src/compiz-0.9.14.1/po/as.po:7: warning: header field 'Last-Translator' still has the initial default value
~/.cache/yay/compiz/src/compiz-0.9.14.1/po/as.po:7: warning: header field 'Language-Team' still has the initial default value
[  8%] Generating ast/LC_MESSAGES/compiz.mo
[  8%] Generating az/LC_MESSAGES/compiz.mo

. . . . .

[ 16%] Linking CXX static library libcompiz_string.a
[ 16%] Built target compiz_string
[ 16%] Built target nls
make: *** [Makefile:183: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
error making: %!s(func() string=0x5582c44d2830)


#### Chazza commented on 2020-06-26 14:15 (UTC)

@corsaw intltool depends on perl-xml-parser so this should already be installed on your system. I cannot reproduce the problem on my side so I'm pretty sure this is not an issue with the compiz PKGBUILD. I suggest you check that your system is up to date.

#### robson commented on 2020-06-26 13:53 (UTC)

@corsaw For me, DE Xfce compiz builds correctly. All I can offer you is to add the chaotic-aur repo and install compiz-git.

#### warigan commented on 2020-06-26 13:10 (UTC)

Unable to build because of a missing perl moduel (XML::Parser). It works after installing it with cpan.

Scanning dependencies of target compiz-gnome-keybindings
You must have XML::Parser installed to run /usr/bin/intltool-merge

make[2]: *** [gtk/gnome/CMakeFiles/compiz-gnome-keybindings.dir/build.make:82: gtk/gnome/50-compiz-navigation.xml] Error 2
make[1]: *** [CMakeFiles/Makefile2:5006: gtk/gnome/CMakeFiles/compiz-gnome-keybindings.dir/all] Error 2
make: *** [Makefile:183: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...


#### robson commented on 2020-05-17 10:35 (UTC)

@Chazza It's OK now. Thanks.

#### Chazza commented on 2020-05-17 00:05 (UTC)

Thanks for the heads up! This build issue is caused by the update to gcc 10. https://gcc.gnu.org/gcc-10/porting_to.html

I've created a patch for this. Can you try again?

#### robson commented on 2020-05-16 20:40 (UTC) (edited on 2020-05-17 16:32 (UTC) by robson)

I would like to inform you that an error occurs during the construction of gtk-window-decorator, and construction stops.

#### brikler commented on 2020-05-01 19:14 (UTC)

@chazza thank you for this very quick response :) …and your right it was my fault, i added -CMAKE_UNITY_BUILD=TRUE but i forgot the D before CMAKE

#### Chazza commented on 2020-05-01 18:05 (UTC)

The message about coverage reports is not important. To see what your real problem is you need to take a look at that CMakeOutput.log. I just built Compiz on my system and there were no problems so I don't think there's anything wrong with the PKGBUILD.

#### brikler commented on 2020-05-01 15:29 (UTC)

i am not able to start the build process, it breaks with this error message:

-- No coverage report targets set, not generating coverage report
-- Configuring incomplete, errors occurred!
==> ERROR: A failure occurred in build().
Aborting...


how could i set the missing?

#### muktupavels commented on 2020-01-16 06:35 (UTC)

Group plugin is disabled...

#### spawn commented on 2020-01-15 22:44 (UTC)

Switched from compiz-0.8 to compiz-0.9 today, because compiz-0.8 is now F**Ked :(

Does anyone know WHERE is the "Group and Tab" plugin in compiz-0.9? The "Group" plugin is there in the archive and on LaunchPad: https://git.launchpad.net/compiz/tree/plugins/group

However, it doesn't seem to be installed on my system, and I can't find it in CCSM neither. Anyone got it working?

#### robson commented on 2019-12-18 11:34 (UTC) (edited on 2019-12-18 15:26 (UTC) by robson)

@Chazza thanks a lot for rebuilding compiz-git helped. Because I have the chaotic-aur repo added, in which there is the next compiz-git and reinstalling it did not work. Rebuilding compiz-git with PKGBUILD from AUR solved the problem with protobuf. Thanks a lot again.

#### Chazza commented on 2019-12-18 10:57 (UTC)

@robson You don't need to rebuild protobuf, you need to rebuild compiz. There is no need to edit any PKGBUILDs. Simply re-run makepkg.

#### robson commented on 2019-12-18 10:40 (UTC)

@Chazza you write that it is enough to rebuild the protobuf, but where should you edit PKGBUILD?

#### Chazza commented on 2019-11-17 19:18 (UTC)

Thanks for the heads up and the patch! Committed.

#### rharish commented on 2019-11-17 05:30 (UTC) (edited on 2019-11-17 05:31 (UTC) by rharish)

@Chazza I have created a patch to fix the issue that @Techman35 raised. Here are the required files:

This was happening because Python 3.8 removed a deprecated function.

#### Techman35 commented on 2019-11-16 00:59 (UTC)

ccsm wont launch after installing latest update https://pastebin.com/raw/f08ysa3f

#### Chazza commented on 2019-10-29 13:23 (UTC)

@chorriwuarri See my pinned comment.

#### chorriwuarri commented on 2019-10-29 10:26 (UTC) (edited on 2019-10-29 21:31 (UTC) by chorriwuarri)

latest package update protonbuf breaks compiz

edit @Chazza yeah its work, thanks

#### muktupavels commented on 2019-04-07 19:41 (UTC)

I don't know anything about KDE support in compiz. All I know it did not compile and I removed all KDE related things. It seems that KDE support has been removed also from compiz reloaded...

If kdecompat still works then partial revert can be submitted, but it sounds that it does not work or has some problems... So someone needs to do partial or full revert and update to make it fully working with KDE 5.

#### Chazza commented on 2019-04-06 16:27 (UTC)

@denjack I didn't experience the issues that you did but it's possible I didn't test it for long enough.

@muktupavels I tried running Compiz + kdecompat plugin in KDE Plasma 5 in a VM. Unfortunately, not only did kdecompat not work for me, it actually introduced new problems. I wasn't able to open the KDE main menu with kdecompat enabled, it would keep closing immediately until I turned kdecompat off again. It also didn't add taskbar thumbnails although in fairness I wasn't even able to get taskbar thumbnails with the default kwin either. Enabling/disabling blur effect in kdecompat did nothing and I have no idea what "present windows" is so I can't test that. As you say, someone who actually uses KDE needs to test this but as near as I can tell, kdecompat doesn't work in KDE 5.

#### denjack commented on 2019-04-06 06:48 (UTC)

@Chazza: I have tried, the result is.... weird. There is KDE compatibility plugin present in CCSM. So far so good. The weirdness is in DockBarX thumbnails behaviour. It is sometimes there, sometimes not. Sometimes empty frame is shown when mouse pointer is above related dock icon, when it moves to the frame, thumbnail blinks for a while. It is funny when more than one instance of the application is run and so there should be multiple thumbnails shown. Multiple frames are shown and if one slides mouse pointer over them the frames randomly show thumbnails randomly are empty and this status is changing as the pointer moves. Not the thumbnail under the pointer is always shown any of the others can be. Hard to describe, if important i can try to catch it on screenshot.

#### Chazza commented on 2019-04-04 21:25 (UTC)

@denjack Ok great. Now try building Compiz 0.9.14 with this patch: https://pastebin.com/raw/16Fm8cbK

It is just a partial revert of the commit that removes kdecompat. I have tried this myself in my VM with dockbarx and can confirm that thumbnail previews in dockbar work with kdecompat enabled and do not work when it is disabled.

#### commented on 2019-04-03 02:59 (UTC)

@Chazza - Yes that helps, tnx for explaining.

In addition I just want to say how much I appreciate Compiz is still alive. I've been running it standalone for could it be a decade already? Still the best :)

#### denjack commented on 2019-04-01 18:11 (UTC)

@Chazza, muktupavels: checked it on a machine with freshly updated Arch with xfce where no plasma/kde4libs/kwin packages were installed and it was fully working - I have all thumbnails in DockBarX. I don't know how it was possible but the only i needed was to build 0.9.13 version of compiz (as Chazza advised below - git checkout c1a346ae6e69) and use it. Regardless of building it on system missing kde/plasma/kwin there were KDE compatibility option present in CCSM, once selected it all is working as I would expected. So from my point of view as it is causing no problem during building and works there is no reason changing any code and also no reason to remove KDE compatibility plugin from compiz. It would be appreciated by me to keep the pluggin in as I wouldn't need to keep compiz 0.9.13 forever or search for other solution in order to have thumbnails available.

#### muktupavels commented on 2019-03-31 15:01 (UTC)

Someone who use KDE should do the work and test things. If kdecompat works without other parts (actually it could work, as I think it was not disabled with -DBUILD_KDE4=Off) then create partial revert to restore this plugin and test it. If it works, then submit merge request.

#### Chazza commented on 2019-03-29 09:43 (UTC) (edited on 2019-03-31 19:24 (UTC) by Chazza)

Ok well I had a look at the code that was removed. The code for plugins/kdecompat doesn't look like it's using any code from KDE/Qt. The code for plugins/kde on the other hand - which apparently "Integrates the KDE/Qt event loop into Compiz" - has definitely not been ported to KDE5. It's using classes like KApplication and KCmdLineArgs which come from kdelibs4.

So without kdelibs4, plugins/kde won't compile and I would assume that plugins/kdecompat won't work without it. There doesn't look like there's much kdelibs4 specific code; it probably shouldn't be that difficult to replace it, just following the porting guide. But I don't know whether thumbnail previews in dockbarx would work even if the code were ported. It all depends on whether KWin 5 exposes its window thumbnails in the same way the KWin 4 did. Apparently KWin 4 exposed them through dbus [1].

If I get some time at the weekend I'll experiment with this and see if I can get it working but I can't make any promises.

EDIT: I had a go at porting the kde events plugin to Qt5 and got so far but reached a brick wall with the dispatcher. The dispatcher seems to get raw XEvents and then use Qt4 to process them. But in Qt5 the code for handling XEvents has been removed and I don't think it's straightforward to work around that, not without a much more detailed knowledge of X than I have. In any case, I think I was wrong in assuming that kdecompat needs the kde plugin so it's probably not relevant.

#### denjack commented on 2019-03-28 22:01 (UTC) (edited on 2019-03-28 22:12 (UTC) by denjack)

@Chazza, muktupavels: I wiped out kde/plasma from the system (pacman -Q | grep -i kde and pacman -Q | grep -i plasma returns nothing) and rebooted. Then got the source as Chazza advised and here are the answers: - compilation finished without any problem, the same with installation - ccsm now shows KDE compatibility option - DockBarX not surprisingly doesn't show window thumbnails now. I don't know how exactly DockBarX works however as it normally works (on Linux Mint) even if Thumbnail Window Previews option is off in CCSM I would say that functionality is taken from some KDE library (and this is the reason why it needs KDE compatibility ability in Compiz to work) and so I guess once KDE libraries are installed again, window thumbnails would be back - will test it later. Also I will try if plasma (KDE5) libraries are enough to work, in other words if outdated KDE4 libs aren't needed. It is a question if drop KDE compatibility if it works only with KDE4. It seems it is not causing any troubles (no problems with build), the worse that can happen is that it is just doing nothing. So I would say keep it but i'm not decision maker nor compiz developer. And last but not least, I have saved all compilation output to a file using script command. It has 33kB zipped. If useful i can provide it.

EDIT: actually not all thumbnails are gone. Some applications yes, some not. I don't know what causes the difference. xfce terminal emulator and firefox shows thumbnails whereas krusader and skype not... The only what is absolutely sure, if KDE compatibility is deselected in CCSM empty windows are shown instead of thumbnails.

#### Chazza commented on 2019-03-28 19:17 (UTC) (edited on 2019-03-28 19:29 (UTC) by Chazza)

@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?

#### Chazza commented on 2019-03-28 17:28 (UTC) (edited on 2019-03-28 18:39 (UTC) by Chazza)

@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!

#### Chazza 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.

#### Chazza 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

#### commented on 2019-03-18 02:20 (UTC)

@Chazza; are you telling me I'm supposed to keep an eye on every single dependency my AUR packages have and notice myself if an AUR package needs rebuilding??

#### Chazza commented on 2019-03-15 19:17 (UTC)

@Sebversive compiz builds fine here. No idea why your build failed on at 34%. And yes, compiz (and all AUR packages in general) need to be rebuilt when dependencies that they're linked against get updated.

#### commented on 2019-03-15 18:18 (UTC)

Updated my system (last time was 10 days ago) and compiz is broken, doesn't run anymore. Now I tried to reinstall compiz and I get this:

[ 34%] Building CXX object plugins/expo/CMakeFiles/expo.dir/src/expo.cpp.o make[2]: No rule to make target '../plugins/expo/src/glow.cpp', needed by 'plugins/expo/CMakeFiles/expo.dir/src/glow.cpp.o'. Stop. make[1]: [CMakeFiles/Makefile2:9756: plugins/expo/CMakeFiles/expo.dir/all] Error 2 make: *** [Makefile:163: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

Any idea?

Edit: replaced compiz with compiz-git -> everything back to normal..

#### Chazza commented on 2019-02-20 14:43 (UTC) (edited on 2019-02-20 19:48 (UTC) by Chazza)

@ector, once I'm in front of my Arch machine I'll update this package to add the fix from upstream.

Edit: done.

#### ector commented on 2019-02-20 12:51 (UTC) (edited on 2019-02-20 12:54 (UTC) by ector)

Thanks for info @chazza. But can I update or I have to wait for new version compiz? I saw that in ubuntu it was fixed. at the moment I downgraded compiz. Cheers

#### Chazza commented on 2019-02-19 18:05 (UTC)

Great! Thanks alot muktupavels

#### Chazza commented on 2019-02-18 18:10 (UTC)

@ector, that looks like a bug and you need to report it upstream. Techman35 reported something very similar in compiz-git a few days ago, about ccsm struggling with unicode characters. Python 2 and 3 handle unicode differently and CCSM was ported to Python 3 for this release so that could have something to do with it - I can't reproduce this myself. In the meantime,I suggest you downgrade to 0.9.13.1-5.

#### ector commented on 2019-02-18 16:51 (UTC) (edited on 2019-02-20 12:53 (UTC) by ector)

hi, chazza ccsm not start whit new version compiz

[code] ector ~ $ccsm compizconfig - Info: Backend : ini compizconfig - Info: Integration : true compizconfig - Info: Profile : default Traceback (most recent call last): File "/usr/bin/ccsm", line 122, in <module> mainWin = ccm.MainWin(context, plugin, category) File "/usr/lib/python3.7/site-packages/ccm/Window.py", line 55, in init self.MainPage = MainPage(self, self.Context) File "/usr/lib/python3.7/site-packages/ccm/Pages.py", line 1209, in init pluginWindow = PluginWindow(self.Context) File "/usr/lib/python3.7/site-packages/ccm/Widgets.py", line 1642, in init category_box = CategoryBox(context, category, plugins, i) File "/usr/lib/python3.7/site-packages/ccm/Widgets.py", line 1506, in init self._plugins.sort(key=PluginKeyFunc) File "src/compizconfig.pyx", line 943, in compizconfig.Plugin.ShortDesc.get UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 12: ordinal not in range(128) [/code] #### Chazza commented on 2019-02-17 15:32 (UTC) @nfishr The reason that error message appeared at the end of the build was because the Compiz build system tries to call glib-compile-schemas on /usr/share/glib-2.0/schemas at the end of the build. This fails because Arch packages are built as an ordinary user, not root, so glib-schemas-compile does not have write permissions on that directory, hence the permission denied error. But it's a completely harmless error as I said earlier, because we don't need the Compiz build system to trigger a glib schemas recompile as that's handled by a pacman hook at install time. And before we had pacman hooks we had those${pkgname}.install scripts which did the same thing.

The error has been at the end of every Compiz build since before I was maintainer. I never looked into what precisely caused it because it was a non-issue (one can verify that the Compiz gschemas are installed correctly by opening the dconf editor and looking for the org.compiz entries) and nobody ever complained until now.

As to why your build failed earlier, I can only guess because you never showed me the terminal output. But my assumption would be that you're using some sort of AUR helper that somehow picked up on the non-zero exit code of glib-compile-schemas and and interpreted that to mean that the entire packaging process had failed, thus stopping it in its tracks. But that's just a blind guess.

#### nfishr commented on 2019-02-17 11:33 (UTC)

@Chazza thanks for the quick reply. Indeed the error is now gone, and the compilation went through flawlessly. Since you're saying that the error I encountered was not critical, I'm now not sure what caused it to fail the other day.

#### Chazza commented on 2019-02-16 23:08 (UTC) (edited on 2019-02-17 00:33 (UTC) by Chazza)

@nfishr The "Failed to create file “/usr/share/glib-2.0/schemas/gschemas.compiled.QDJCXZ”: Permission denied" error message has been around for ever. It shouldn't halt compilation.

Seeing as a people lately have been complaining about this error, I've added a patch which will silence it. The error isn't actually of any importance - glib schemas automatically get compiled by a pacman hook on installation/upgrade/removal so there's no need for them to be compiled during the package build process. But anyway, its fixed now.

#### nfishr commented on 2019-02-16 23:03 (UTC)

Does not compile for me.

Failed to create file “/usr/share/glib-2.0/schemas/gschemas.compiled.QDJCXZ”: Permission denied

not sure how to fix this

#### Chazza commented on 2019-02-16 21:57 (UTC)

Updated to 0.9.14.0. Any bugs (not related to packaging), please report them upstream to https://bugs.launchpad.net/compiz

If anyone needs to revert 0.9.13.1 for some reason and doesn't have a binary lying around, just check out the previous commit and build with makepkg.

Thanks

#### Chazza commented on 2019-01-28 22:39 (UTC)

@anonymous352 Oh that error message has been around forever. I'm not sure why it complains but it's completely harmless. The Compiz schemas are correctly installed and compiled. No need to worry :)

#### anonymous352 commented on 2019-01-28 13:44 (UTC)

I'm noticing this error message rebuilding compiz recently: 'Failed to create file “/usr/share/glib-2.0/schemas/gschemas.compiled.ZP71VZ”: Permission denied'

#### rharish commented on 2018-09-14 13:57 (UTC)

Protobuf has been updated, so that libprotobuf.so.16 is now libprotobuf.so.17. Now I'm unable to run ccsm. Please fix the package.

#### Techman35 commented on 2018-08-06 13:17 (UTC)

Archlinux lasted update will reset compiz configuration.... rebuilding the package fix the problem.

#### Chazza commented on 2018-07-25 17:11 (UTC)

No, patch is a member of the base-devel group. AUR packages never list base-devel packages as dependencies because it is assumed that you already have base-devel installed.

#### glenntanner3 commented on 2018-07-25 17:05 (UTC)

missing dependency: 'patch'

#### Chazza commented on 2018-07-17 14:52 (UTC)

@Techman35 Yeah, it's a bummer. :( In the past week or two some new commits have been pushed to the Compiz trunk on launchpad.net but it seems to be mainly ccsm related from looking at the commit messages.

#### Techman35 commented on 2018-07-16 13:15 (UTC)

@Chazza i will test version 0.8 to see how it works... by the moment i use compiz 9 cuz it have better performance and no tearing issue. but i miss the blur plugin :(

#### dwellingsoul commented on 2018-05-27 04:11 (UTC)

@Chazza Sorry for the late reply.

I noticed that in order to reproduce the crash you must put something in the "window" field (such as thunar, xfce4-terminal, etc...). Probably it won't crash immediately but it will for sure if you issue compiz --replace or if you re-enable the plugin.

I was referring to this compiz (not compiz-manjaro). Back when I used Manjaro I installed this package and I had the same results with Arch. Since you didn't experience any crashes I think it might be related to my graphics card (nvidia quadro 4000), but who knows. The feature doesn't work anyway, and it might as well crash for other users.

Yeah, I followed your advice and so far, compiz 0.8 is working fine even with Gaussian Blur. That bug report isn't going to receive any support from Canonical. Since Ubuntu 14.04 they pretty much killed compiz, but hey, compiz 0.8 still does the job pretty well. Thanks for the reply.

#### Chazza commented on 2018-05-22 15:01 (UTC)

@dwellingsoul Thanks for your message. I had a look at this and you're right - the Blur Windows plugin does nothing. I wasn't able to reproduce a crash when selecting the Gaussian filter though.

With regards to the Manjaro package, they're not using exactly the same Compiz version. They shadowed a decision of mine back in December of last year to use a development snapshot. I later changed this package back to using the release version because of some issues reported to me. But as far as I'm aware they're still using the dev snapshot.

So that could account for why the Manjaro version crashes and this one does not. However, I did try testing this with compiz-bzr which at the moment is only slightly more recent than the dev snapshot that Manjaro uses (r4143 vs r4138) and I didn't get a crash there either so who knows.

I'm sorry but I don't think there's anything I can do about this right now. :( I've never done OpenGl programming you see, otherwise I would try and fix it myself.

I notice that there's a bug report for the Blur plugin crashing on the launchpad front page [1] so you could try adding to that. But bear in mind that Compiz is not really a priority for Canonical now seeing as Unity 7 is no longer being used in new Ubuntu versions.

Have you tried using a recent version of Compiz 0.8? I've not tried it myself but it has a new upstream on GitHub which has a good deal more development activity than Compiz 0.9 as far as I can tell. You might have more luck with that.

#### dwellingsoul commented on 2018-05-21 00:29 (UTC)

Everything is working fine except for one thing: Blur Windows. Doesn't matter which blur filter is selected, nothing will happen anyway. I don't know if it's just me (which I doubt because everything, even the cheesy animations are working as intended).

In Manjaro if I selected Gaussian filter compiz would crash and selecting the 2 other filters wouldn't do anything at all. Now in Arch it doesn't even crash. It doesn't do anything at all. What can I do?

By the way, thanks for maintaining this.

#### Chazza commented on 2018-03-31 07:50 (UTC)

@ector, I think he runs 'compiz --replace' at startup which means Marco gets started first but is then killed. Whether Compiz then starts emerald or gtk-window-decorator wouldn't affect that.

#### ector commented on 2018-03-31 07:15 (UTC)

he says he uses marco, but I see that he uses emerald in his compiz1. boh

#### RusWolf commented on 2018-03-28 16:31 (UTC)

Chazza, thank you so much !!! Assembled and installed compiz-bzr 4143-1, now there is no problem. Everything works well.

#### Chazza commented on 2018-03-28 08:31 (UTC)

Well I did try with your config but I couldn't reproduce the issue. In order to address this, I've decided to resurrect the old compiz-bzr package [1] that I had deleted from the AUR years ago. So RusWolf (and anyone else who wants or needs to use a development snapshot) please install compiz-bzr.

#### RusWolf commented on 2018-03-27 13:09 (UTC) (edited on 2018-03-27 13:10 (UTC) by RusWolf)

https://pastebin.com/HakKwRqi

I run Compiz by replacing Marco via the autostart Mate.

#### Chazza commented on 2018-03-27 08:20 (UTC)

Hmm, can you send your ~/.config/compiz-1/compizconfig/Default.ini to me? Putting it on pastebin is fine. I need to be able to reproduce the problem at my end if I'm to figure out which commit fixed it for you. Also, how is Compiz getting started on your machine? Are you replacing Marco at login via MATE autostart or did you set Compiz as the default in gsettings?

#### RusWolf commented on 2018-03-26 15:56 (UTC)

After the start of DE Mate, the system panel and the program menu are not active, there is no response to pressing the left mouse button. After starting any program and closing its window, the problem goes away, the program menu and the system menu start responding to the left mouse button click. With Compiz 0.9.13.1.r4138-1, there is no such problem.

#### Chazza commented on 2018-03-24 12:16 (UTC)

@RusWolf I'm not a MATE user but I tested in a VM and I can't see any problem. What exactly do you see?

#### RusWolf commented on 2018-03-24 08:52 (UTC) (edited on 2018-03-24 09:35 (UTC) by RusWolf)

Compiz 0.9.13.1.r4138-1 everything works fine.

With compiz 0.9.13.1-4 returned an old problem. After starting DE Mate, the system tray and application menus are not active.

#### ector commented on 2018-03-15 10:14 (UTC)

I'm compiling now and I have not had any mistakes. my version 5 aur/compiz 0.9.13.1-4 [installed: 0.9.13.1.r4138-1] (138) (0,79) the compilation https://pastebin.com/4P7cT10G

#### ector commented on 2018-03-15 09:50 (UTC)

@Chazza as soon as I have time I try, even if yaourt the other day, gave me no update of compiz, if I remember correctly!

#### Chazza commented on 2018-03-14 11:27 (UTC)

Ok folks, a couple of people now have reported serious issues with the r4138 tarball. I can't reproduce them myself but to be on the safe side I'm rolling back to the 0.9.13.1 release tarball for now.

#### Chazza commented on 2018-01-09 11:18 (UTC)

@yoburtu I've responded to your email.

#### ector commented on 2018-01-09 10:28 (UTC)

hello you have installed: protobuf-c

#### yoburtu commented on 2018-01-09 08:46 (UTC)

@chazza I have installed the r4100 revision and it does not work either. I have installed the 0.9.13.0.r4099-1 and neither.

I can't configure plugins in ccsm. Options of plugins do not appear.

In the mail windows of ccsm all plugins appear in the uncategorized section. if I access a plugin, the empty window appears.

It is very extrange. I sent you a message with the screenshots.

Regards.

#### Chazza commented on 2018-01-08 21:53 (UTC) (edited on 2018-01-09 00:33 (UTC) by Chazza)

@yoburtu Hmmm, I honestly have no idea why your CCSM is playing up like that. It works fine for me. In answer to your question, to get a previous version of the PKGBUILD (and patches) you can clone the repository and checkout a previous commit. Another, potentially easier, option might be to just take the current PKGBUILD and change the revno to r4100. That's essentially equivalent to the 0.9.13.1 release tarball.

EDIT: I later realised I was mixing up your comment with fifi_fifito's comment! Really sorry about that!! I'm tired and I'm trying to juggle multiple tasks at the moment.

#### yoburtu commented on 2018-01-08 21:28 (UTC)

@chazza It's the first thing I've done before writing the post. I have deleted all configuration files in .config/compiz, temporary files in .cache/compiz*, etc. I have rebuilt compiz. I have restarted. But it's still failing.

Regards.

#### Chazza commented on 2018-01-08 15:54 (UTC)

Crikey, it's all systems go for compiz issues today...

So that message you just posted isn't your actual error. It's just a CMake warning that pops up for everyone. You need to post your full build output if I'm to get any idea of what's going wrong. Please, please don't post full build output into a comment by the way. Instead, put it on pastebin and post a link. Thanks.

But before you do that, please try updating your system and rebuilding compiz. Because I can tell you that I rebuilt compiz this morning and there were no issues so I don't think there's anything wrong with the PKGBUILD right now...

#### fifi_fifito commented on 2018-01-08 15:37 (UTC) (edited on 2018-01-08 15:37 (UTC) by fifi_fifito)

Hello, I can not upgrade my compiz, it gives me a mistake Excuse me for the bad english I use a google translator

WARNING: "FindCompiz.cmake" is not found in cmake module directories. It should be installed to allow building of external compiz packages. Call "sudo make findcompiz_install" to install it

#### Chazza commented on 2018-01-08 10:42 (UTC)

@yoburtu I can't reproduce that I'm afraid. CCSM works fine here. Please try making sure your system if fully up-to-date and rebuilding compiz.

#### yoburtu commented on 2018-01-08 09:32 (UTC)

Hi,

ccsm don't works since the last update 0.9.13.1.r4138-1.

I can't configure plugins. The options do not appear. The empty window appears.

Best regards.

#### Chazza commented on 2017-12-18 11:21 (UTC) (edited on 2017-12-18 11:39 (UTC) by Chazza)

Folks, as of today I've switched the Compiz sources over from the release tarballs on launchpad to the pre-release ones. I didn't want to do this but its been thirteen months since the last release tarball and I'm not sure when (if ever) the next one is coming along. I thought it wouldn't be fair to keep everybody on the November 2016 release, potentially forever. So with that in mind, I think the best way of making sure everybody has a reasonably stable and up-to-date version of Compiz is to use the pre-release snapshots that get used in Ubuntu. I'll update the snapshots used at least once a year and more frequently if it's justified. Hope this is acceptable for everybody and have a good Christmas! :)

#### Chazza commented on 2017-12-10 10:25 (UTC) (edited on 2017-12-10 19:09 (UTC) by Chazza)

@japp1egate Hi there. Ah I see, you used a non-standard installer. That explains things. Please would you mention that in the future? I'm still happy to help but that needs to be upfront so that we know where we stand. As for the version number, I sorry I completely forgot to mention. That's a bug that's been there for ages. I think upstream just forgot to update the version reporting function. I could patch it myself but I don't think it's worth making everybody rebuild. So that's nothing to worry about. Anyway, I'm glad you got it working. Let me know if there are further issues.

EDIT: there we go, I fixed the version for you. Looks like upstream already got round to it as well.

#### japp1egate commented on 2017-12-09 21:29 (UTC)

@Chazza:

Solved and sorted! Well...mostly. It would appear that the non-standard repos installed by Zen by default are not properly synchronized with official/AUR, and I was getting a jank-tastic compiz version where ccsm didn't work as a result.

I've just finished rebuilding compiz from AUR, but --version still shows 0.9.13.0. This leaves me mildly befuddled, but at least (in all other ways so far) it's working.

Any ideas why I might still be seeing the old version number?

Sorry for being bothersome.

#### japp1egate commented on 2017-12-09 21:17 (UTC)

@Chazza:

I'm operating under the assumption that I've done something fantastically moronic in using this Zen installer for Arch. There were a couple of questionable repositories in my pacman.conf which I've now commented out (revenge_repo and spooky_aur). I've removed my previous compiz install (which showed --version as being 0.9.13.0) and am now rebuilding from AUR. Will update here with results once the process is complete.

#### japp1egate commented on 2017-12-09 19:42 (UTC)

@Chazza:

1) You are correct, and I apologize for not communicating clearly where my compiz came from. This is a fresh "compiz" install/build from AUR.

2) I'm afraid that "compiz --version" is reporting 0.9.13.0, even though I see on the AUR that the compiz that I apparently have installed should be 0.9.13.1.

3) To the best of my knowledge, libprotobuf.so.13 has never been on this machine. As I mentioned before, this is a fresh Arch install, but it has libprotobuf.so.14 installed. I'm not sure whether it makes any real difference, but I used the Zen installer (used to be OBRevenge). Where/how might I either get the previous version of libprotobuf.so or make compizconfig look for libprotobuf.so.14?

I really appreciate your help, @Chazza!

#### Chazza commented on 2017-12-09 09:43 (UTC)

Hi @japp1egate. A couple of quick things:

1) ''I've gotten past the issue I'd reported by installing the package "compiz" from the repo, rather than "compiz-manjaro"''

You mean you installed compiz from the AUR, right? Neither compiz (this package), nor compiz-manjaro nor any other compiz packages are in the Arch repositories. It would actually be against policy for this package to be in the AUR and the official repositories at the same time.

2) ''Now that I have compiz 0.9.13.0 running''

You should have 0.9.13.1 installed, not 0.9.13.0. I updated this PKGBUILD to point to 0.9.13.1 in November 2016. Was this a typo or are you actually trying to use the older version??

3) ''I cannot launch ccsm.''

So what you've got there is a dynamic linking issue. The compiz you've installed is linked against a particular version of the libprotobuf library. The version it's linked against is no longer on your machine because it was replaced by a newer version in an update. The correct way to resolve this is simply to rebuild compiz against the newer version of libprotobuf.

#### japp1egate commented on 2017-12-09 09:15 (UTC)

@Chazza

You were correct in that this was not an actual Compiz problem. I've gotten past the issue I'd reported by installing the package "compiz" from the repo, rather than "compiz-manjaro" (installed due to sleep-deprivation). This led me to installation of proper nVidia graphics driver, as something had somehow hosed my display. Solved that (not related here).

Now that I have compiz 0.9.13.0 running, I cannot launch ccsm.

$ccsm Traceback (most recent call last): File "/usr/bin/ccsm", line 93, in <module> import compizconfig ImportError: libprotobuf.so.13: cannot open shared object file: No such file or directory</module> Is the compizconfig that it's trying to import a file I can edit, wherein I might change the entry from libprotobuf.so.13 to libprotobuf.so.14, which actually resides on my machine? Thanks! #### japp1egate commented on 2017-12-08 23:12 (UTC) @Chazza I'll investigate those links, but this is a fresh install of Arch, and I did not conciously install Python to any non-standard location. Let me see what I can find at those links you provided. If/when I come to a conclusion, I will post here again to update, in case anyone else has the same problem and thinks it's a Compiz issue. Thanks for helping, @Chazza! #### Chazza commented on 2017-12-08 08:31 (UTC) @japp1egate I've rebuilt Compiz and it builds fine. I couldn't reproduce the error you mentioned. So unless someone else can confirm, I don't think there's a problem with the Compiz PKGBUILD. Looking at that error, I'm wondering whether perhaps you've installed python to a non-standard location? There are a couple of bug reports for this: https://bugs.launchpad.net/compiz/+bug/1204253 https://answers.launchpad.net/compiz/+question/232246 #### Chazza commented on 2017-12-06 21:02 (UTC) @japp1egate Hiya. Nope, never seen that before. Or not that I remember anyway. Yes, you've raised this in the right place. Build issues should be reported to the package maintainer. I'm very, very busy at the moment unfortunately but I will try and fix this tomorrow if I have time, otherwise it might have to wait until the weekend. #### japp1egate commented on 2017-12-06 20:35 (UTC) (edited on 2017-12-07 02:40 (UTC) by japp1egate) /usr/src/compiz-0.9.13.1$ sudo mkdir build

/usr/src/compiz-0.9.13.1$cd build /usr/src/compiz-0.9.13.1/build$ sudo cmake ..

. . .

CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: PYTHON_LIBRARY_LOCAL linked by target "compizconfig_python_module" in directory /usr/src/compiz-0.9.13.1/compizconfig/compizconfig-python

From /usr/src/compiz-0.9.13.1/build/CMakeFiles/CMakeError.log:

CMakeFiles/cmTC_84d35.dir/CheckSymbolExists.c.o: In function main': CheckSymbolExists.c:(.text+0x1b): undefined reference topthread_create' collect2: error: ld returned 1 exit status make[1]: [CMakeFiles/cmTC_84d35.dir/build.make:98: cmTC_84d35] Error 1 make[1]: Leaving directory '/usr/src/compiz-0.9.13.1/build/CMakeFiles/CMakeTmp' make: [Makefile:126: cmTC_84d35/fast] Error 2

... and further toward the bottom of the log:

/usr/bin/ld: cannot find -lpthreads collect2: error: ld returned 1 exit status make[1]: [CMakeFiles/cmTC_b3337.dir/build.make:98: cmTC_b3337] Error 1 make[1]: Leaving directory '/usr/src/compiz-0.9.13.1/build/CMakeFiles/CMakeTmp' make: [Makefile:126: cmTC_b3337/fast] Error 2

As this is my first time attempting to compile Compiz, I am uncertain as to whether I am bringing this issue to the correct folks. @Chazza - since you are the package maintainer, have you encountered this failure in the past?

(edited to clean up formatting a bit.)

#### Chazza commented on 2017-11-12 15:32 (UTC)

@s_root I've rebuilt compiz and I cannot reproduce that error. Please verify that your system is up to date and also try building the package manually instead of using an AUR helper as I've seen those cause problems for people once or twice.

#### s_root commented on 2017-11-12 14:47 (UTC)

Any idea of below error? /home/sr/.cache/pacaur/compiz/src/compiz-0.9.13.1/build/compizconfig/libcompizconfig/src/compizconfig.pb.h: In member function ‘void metadata::Plugin::clear_has_screen()’: /home/sr/.cache/pacaur/compiz/src/compiz-0.9.13.1/build/compizconfig/libcompizconfig/src/compizconfig.pb.h:4995:3: error: ‘_has_bits_’ was not declared in this scope _has_bits_[0] &= ~0x00000002u; ^~~~~~~~~~ /home/sr/.cache/pacaur/compiz/src/compiz-0.9.13.1/build/compizconfig/libcompizconfig/src/compizconfig.pb.h:4995:3: note: suggested alternative: ‘has_info’ _has_bits_[0] &= ~0x00000002u; ^~~~~~~~~~ has_info At global scope: cc1plus: warning: unrecognized command line option ‘-Wno-unused-private-field’ cc1plus: warning: unrecognized command line option ‘-Wno-unused-private-field’ cc1plus: warning: unrecognized command line option ‘-Wno-unused-private-field’ cc1plus: warning: unrecognized command line option ‘-Wno-unused-private-field’ cc1plus: warning: unrecognized command line option ‘-Wno-unused-private-field’ make[2]: *** [compizconfig/libcompizconfig/src/CMakeFiles/compizconfig.dir/build.make:91: compizconfig/libcompizconfig/src/CMakeFiles/compizconfig.dir/compiz.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:5603: compizconfig/libcompizconfig/src/CMakeFiles/compizconfig.dir/all] Error 2 make: *** [Makefile:163: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... :: boost is now an orphan package :: intltool is now an orphan package :: metacity is now an orphan package :: pyrex is now an orphan package :: failed to build compiz package(s)

#### loudmax commented on 2017-10-27 16:08 (UTC)

I hadn't recompiled. I just did and compiz is now working again with protobuf-3.4.1-1. Sorry for false alert and thanks for the tip about checking AUR dependencies.

#### Florian commented on 2017-10-27 11:47 (UTC) (edited on 2017-10-27 11:48 (UTC) by Florian)

Did you try recompiling compiz? Usually when upgrading libraries you should recompile dependent AUR packages, so the new libraries get linked again.

#### loudmax commented on 2017-10-27 11:46 (UTC)

compiz 0.9.13.1-3 failed to start with this error after I updated packages on my laptop: ImportError: libprotobuf.so.13: cannot open shared object file: No such file or directory I was able to fix it by downgrading from protobuf-3.4.1-1 to protobuf-3.3.2-1 pacman -U /var/cache/pacman/pkg/protobuf-3.3.2-1-x86_64.pkg.tar.xz The newer version of protobuf includes libprotobuf.so.14. Can Compiz be updated to work with the newer version?

#### Chazza commented on 2017-05-27 14:53 (UTC)

Thanks Techman35 :) I've tested the patch you linked to and can confirm it addresses the issue so I've added it. As for the other issues, I promise I will look into them as soon as I am able but I am rather busy at present. In any case, upstream should be made aware of these issues if there aren't already existing bug reports.

#### Techman35 commented on 2017-05-26 22:07 (UTC) (edited on 2017-05-26 22:08 (UTC) by Techman35)

@Chanzza i can tell you more if you want :) in screenshot plugin the launch_app is not working, id fix it patching the source code with this screenshotfix.patch that i found on launchpad forum as far as i remember this is the patch link: https://pastebin.com/raw/KWm8a16D and now it works Another plugin is the blur plugin, is not working and if i enable it and select Blur Filter Gaussian compiz crash, and if i select other Filter option nothing happens theres a feature i would like to have in this version of compiz, and is to be able to use dockbarx compiz scale option, it works with version 0.8

#### Chazza commented on 2017-05-26 09:11 (UTC)

@ector thanks, but wrt protobuf, please do NOT symlink new library names to old. This will create a mess. Instead, rebuild compiz. I'll bump the pkgrel in just a moment. @Techman35 thanks for the info. I wasn't aware there was an issue there as I don't use the widget layer. I'll look into this as soon as I can.

#### ckoresko commented on 2016-10-13 01:00 (UTC)

@Chazza: Thanks for the info. I can confirm that rolling back to /metacity-3.20.3-1 cures the compiz build issue.

#### Chazza commented on 2016-10-12 19:05 (UTC)

Thanks for the heads up ckoresko. It looks like some header file has been removed from metacity 3.22. At the moment, please try downgrading metacity to 3.20. Schedule permitting, I'll look more closely at this tomorrow or Friday - otherwise it will have to be the weekend.

#### ckoresko commented on 2016-10-12 11:34 (UTC)

Got a build failure after today's mass of gnome-related updates. The first error in the output was: [ 37%] Building C object gtk/window-decorator/CMakeFiles/gtk-window-decorator.dir/gwd-theme-cairo.c.o [ 37%] Building C object gtk/window-decorator/CMakeFiles/gtk-window-decorator.dir/gwd-theme-metacity.c.o [ 37%] Building C object compizconfig/libcompizconfig/src/CMakeFiles/compizconfig.dir/ccs_config_file.c.o /home/koresko/.cache/pacaur/compiz/src/compiz-0.9.13.0/gtk/window-decorator/gwd-theme-metacity.c:52:5: error: unknown type name ‘MetaButtonLayout’ MetaButtonLayout button_layout; ^~~~~~~~~~~~~~~~

#### Chazza commented on 2016-09-26 16:01 (UTC)

The emerald0.9 and fusion-icon0.9 packages have been removed from the AUR today, as per the pinned notices added to their respective AUR pages last month. Please switch to emerald [1] and fusion-icon [2] if you used emerald0.9 and/or fusion-icon0.9 and you haven't already made the switch. [1] https://aur.archlinux.org/packages/emerald/ [2] https://aur.archlinux.org/packages/fusion-icon/

#### Chazza commented on 2016-08-23 16:43 (UTC)

This update makes the Compiz package provide the individual Compiz components. This has been done with the view of transitioning from the fusion-icon0.9 and emerald0.9 packages to emerald and fusion-icon as the compiz-reloaded folks have added Compiz 0.9 support to both upstream. The fusion-icon package should work as is and I've asked the emerald maintainer to make the necessary changes to the emerald PKGBUILD.

#### Chazza commented on 2016-08-17 07:24 (UTC)

No problem. Thanks for bringing it to my attention. And yes, the last update was to change the ordering. Just in case you don't know, if you click View Changes under Package Actions on the AUR webpage you can see precisely what I've done for each update.

#### ckoresko commented on 2016-08-16 20:44 (UTC)

@Chazza: Thanks for that info. I tried switching the order of the patch commands in the PKGBUILD and got it working. But I see that you've updated the AUR package, so that probably wasn't necessary.

#### Chazza commented on 2016-08-16 17:12 (UTC)

My apologies. I should have reverse applied the r3981 diff first instead of last. Having it applied last was wiping out my previous change to the Window Decoration command - the command with the COMPIZ_BIN_DIR variable doesn't appear to work properly.

#### ckoresko commented on 2016-08-16 16:15 (UTC)

The latest package (compiz-0.9.13.0-4) built and installed fine on my two systems, and it restores the behavior set via CCSM. But gtk-window-decorator doesn't seem to work: the window borders and shadows are not being drawn. Also, attempting to change the window border through the MATE Appearance -> Customize sometimes causes dconf-service (I think) to get stuck beating on the disk and CPU until I kill the Mate control center. I think I have all the relevant packages, including the AUR packages, up to date.

#### Chazza commented on 2016-08-15 09:31 (UTC)

Seeing as these Ubuntu specific config patches are causing all sorts of problems, the expo offset for one thing and the multiple desktop number being set to 1 instead of 4, I've decided to just reverse the all the changes made in r3981 so that we can get back to the old upstream defaults.

#### microdou commented on 2016-08-13 20:10 (UTC)

Multiple desktop number was reset to 1 in 0.9.13. Thanks to @Chazza and @zigo for providing the solution. Hope this will be patched in future release.

#### Chazza commented on 2016-08-12 19:43 (UTC)

Thanks korrode :) I've added fix-expo-offset.patch. The delay was due to me being away on holiday.

#### korrode commented on 2016-08-01 19:56 (UTC)

Hi Chazza, i noticed that Expo now gets offset for what i'd think is the panels in Ubuntu/Unity. I've adjusted it back in the manjaro-defaults.patch in compiz-manjaro, but here it is broken out if you want to change it back also: http://paradoxcomputers.com.au/arch/misc/fix-expo-offset.patch

#### Chazza commented on 2016-07-14 11:28 (UTC)

@talessx No worries. Glad it's working for you now.

#### talessx commented on 2016-07-13 18:14 (UTC)

Thanks a lot Chazza, everything works fine now. I dont' know how also conky and cairo-dock are ok. I'm sure I updated all the system.

#### Chazza commented on 2016-07-12 10:39 (UTC) (edited on 2016-07-12 10:39 (UTC) by Chazza)

@kinoru Excellent. Glad the problem is solved. Note to all. Please do make doubly sure before posting here with a problem that your system is fully up to date (that includes this package). If you're holding back an update on some important piece of infrastructure (like gtk3 for instance) then mention that in your post. I'm quite happy to answer people's questions where I'm able but it really helps me (and others who might want to help as well) if we're starting with the assumption that the system is up to date. Thanks folks

#### kinoru commented on 2016-07-12 09:36 (UTC)

@Chazza You're right! I thought I upgraded compiz to the latest, but it wasn't really 0.9.13. Upgrading to the latest AUR release solved the problem. Thanks a lot!

#### Chazza commented on 2016-07-12 07:44 (UTC) (edited on 2016-07-12 07:56 (UTC) by Chazza)

@talessx expo does work, it's just that the edge binding has been set to none in the latest update. You can change it back yourself to the top left corner (or wherever) in the expo settings. Looking into this, it seems that what's happened is that there were some Ubuntu patches for Compiz that were applied downstream prior to 0.9.13. Now the patches are applied upstream which is why a bunch of default settings have changed. http://bazaar.launchpad.net/~compiz-team/compiz/0.9.13/revision/3981 As for cairo-dock and conky, I have no idea. I don't use those things. I'm afraid you'll have to figure that one out yourself unless somebody else chimes in. @kinoru Are you using Compiz 0.9.13? "org.gnome.metacity theme" is the old key. The new key is "org.gnome.metacity.theme name" (as has already been mentioned). If it's asking for the old key, that makes me think you haven't updated.

#### kinoru commented on 2016-07-12 03:48 (UTC)

The issue is the former - gtk-window-decorator is not running. The windows have no shadows they used to have, and nothing like "gtk-window-decorator" shows up in the result of ps aux. Running gsettings set org.gnome.metacity.theme name "Adwaita" and gsettings set org.gnome.metacity.theme type metacity did not help. gtk-window-decorator won't launch, and the only message it prints out is: (gtk-window-decorator:14913): GLib-GIO-ERROR **: Settings schema 'org.gnome.metacity' does not contain a key named 'theme' Trace/breakpoint trap (core dumped) Downgrading metacity to 3.18.4-1 solves the issue; gtk-window-decorator will launch fine. Any idea? BTW, thanks for your help and patience.

#### talessx commented on 2016-07-11 18:37 (UTC)

I have encountered 3 problems with last upgrade: 1) with cairo-dock: when windows cover the dock it becomes unavailable even trying to go on the appropriate zone with the mouse (the bottom for me) 2) "expo" effect doesn't work (show desktops effetc, for me, moving mouse on the left top corner of the screen) 3) while whatching full-screen flash videos (e.g. youtube) conky applets appear over the screen toghether with non-minimized windows Recompiling and downgrading the packages every works fine. Bye bye Alessandro

#### Chazza commented on 2016-07-11 08:22 (UTC)

The gsettings command: gsettings set org.gnome.metacity.theme name "theme-name" changes which theme metacity uses. The idea is that gtk-window-decorator can read that setting and then also use that theme. This a throwback to the days of GNOME 2 where Compiz could be used as a drop in replacement for Metacity in a GNOME session. A user would want to be able to change the window decoration theme in the GNOME control center and have that setting take effect, no matter whether they were using Compiz or Metacity. That's why gtk-window-decorator reads Metacity's settings. The gsettings command: gsettings set org.gnome.metacity.theme type metacity makes Metacity use Metacity themes instead of GTK+ themes. Since GNOME (3.16?) Mutter stopped using Metacity themes and decided to use GTK+ themes for the window decoration. If I'm reading muktupavels' comment correctly then current Metacity supports both and gtk-window-decorator supports GTK+ themes in GNOME Flashback only and needs Metacity themes in any other session. I hope this clears things up. Now you need to tell us what your problem actually is. Is the problem that you have no window borders whatsoever - in which case gtk-window-decorator probably isn't running - or is the problem that the window borders are not using the theme that you like?

#### muktupavels commented on 2016-07-11 07:16 (UTC)

@kinoru What session are you using? GNOME Flashback (Compiz)? What did you mean with 'None of it enabled running gtk-window-decorator.'?

#### kinoru commented on 2016-07-11 07:12 (UTC)

@Chazza Thanks for the reply. I'm sorry to bug you once again, but I don't really understand the comment you mentioned. "must use these settings" - what settings? Where do I set them? I've tried: gsettings set org.gnome.metacity theme Adwaita and gsettings set org.gnome.metacity.theme name Adwaita gsettings set org.gnome.metacity.theme type gtk and gsettings set org.gnome.metacity.theme type metacity None of it enabled running gtk-window-decorator. Is there a tool or a command I can use to put those "settings" in effect? Sorry for being utterly clueless... I'd greatly appreciate any help.

#### Mautz commented on 2016-07-06 17:40 (UTC)

Hi, yes i still used GTK-3.18, because i had some problems with 3.20. After sorting out all problems it compiled fine. Thanks!

#### muktupavels commented on 2016-07-06 10:14 (UTC)

What GTK+ version are you using to build compiz? *_set_css_name is available only with 3.20.0. So it seems that libwnck has been built with GTK+ 3.20.x, but you are trying to build compiz with older GTK+ version - 3.18.x?

#### Mautz commented on 2016-07-06 10:06 (UTC)

Mh, i get the same output as you.

#### Chazza commented on 2016-07-06 07:50 (UTC)

@Mautz It builds just fine for me. I'm not sure what's happening in your case. objdump /usr/lib/libwnck-3.so -tT | grep gtk_widget_class_set_css_name gives me this: 0000000000000000 DF *UND* 0000000000000000 gtk_widget_class_set_css_name so the symbol definitely does exist.

#### Mautz commented on 2016-07-05 20:02 (UTC)

Hi, i'm getting this error while building compiz: Linking C executable gtk-window-decorator /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/libwnck-3.so: undefined reference to gtk_widget_class_set_css_name' Strange thing is, that i get the same error when i try to build version 0.9.12, which buildt fine the last time. Does anyone else get this error? Thanks.

#### Chazza commented on 2016-07-05 06:39 (UTC)

@kinoru Please see the comment by muktupavels on this. I've pinned it so it won't get lost.

#### kinoru commented on 2016-07-05 04:20 (UTC)

Recent version upgrade of metacity breaks gtk-window-decorator. With the latest metacity-3.20.1-1, executing gtk-window-decorator fails with the following error: (gtk-window-decorator:17026): GLib-GIO-ERROR **: Settings schema 'org.gnome.metacity' does not contain a key named 'theme' gtk-window-decorator works fine with metacity-3.18.4-1, the previous version of metacity. Is it metacity's mistake to not provide org.gnome.metacity.theme? Or should gtk-window-decorator (included in compiz) be fixed?

#### Chazza commented on 2016-07-03 09:06 (UTC)

I don't think it's worth making everybody rebuild at this point, but when this next needs an update, I'll add a patch to make the default 4 again.

#### zigo commented on 2016-07-02 20:23 (UTC)

@Chazza thank you i changed it to 4 and it worked fine now.For those who didn't know how to edit it you open CompizConfig Settings Manager (CCSM) and go to General Options in the last tab you will find Desktop Size and under it you change the horizontal virtual size to 4.

#### Chazza commented on 2016-07-02 19:30 (UTC) (edited on 2016-07-02 19:34 (UTC) by Chazza)

Is you horizontal virtual size set to 4? I've just noticed that the default has become 1 for some reason.

#### zigo commented on 2016-07-02 18:42 (UTC) (edited on 2016-07-02 18:47 (UTC) by zigo)

After updating to compiz 0.9.13.0-2 the Desktop cube & rotate cube isn't working anymore which is the best plugins in compiz any suggestions plz

#### LeCrayonVert commented on 2016-07-01 18:12 (UTC)

@muktupavels @Chazza => everything is back to normal now with gtk-window-decorator. Thanks.

#### Chazza commented on 2016-07-01 12:29 (UTC)

@ozmag Yeah, that was because the r4063 tarball was in the 0.9.12 series temporarily - that's changed now so the link no longer works. Now updated to the 0.9.13.0 release tarball.

#### muktupavels commented on 2016-07-01 11:56 (UTC)

0.9.13.0 now is released. :)

#### javashin commented on 2016-07-01 11:42 (UTC)

Oops! Something broke while generating the page. Please try again in a few minutes, and if the problem persists file a bug at https://bugs.launchpad.net/launchpad and quote OOPS-ID OOPS-2533b3049eda064dfa015ec4235a754d

#### javashin commented on 2016-07-01 11:42 (UTC)

% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 Warning: Transient problem: HTTP error Will retry in 3 seconds. 3 retries Warning: left. 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 Warning: Transient problem: HTTP error Will retry in 3 seconds. 2 retries Warning: left. 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 Warning: Transient problem: HTTP error Will retry in 3 seconds. 1 retries Warning: left. 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 500 Internal Server Error ==> ERROR: Failure while downloading http://bazaar.launchpad.net/~compiz-team/compiz/0.9.12/tarball/4063

#### Chazza commented on 2016-07-01 09:37 (UTC)

Updated to the tarball for revision 4063 which brings us to 0.9.13.0.

#### Chazza commented on 2016-06-28 20:17 (UTC)

Thanks muktupavels :) I'll update this to 0.9.13 at the earliest opportunity then.

#### muktupavels commented on 2016-06-28 20:10 (UTC)

Support for Metacity 3.20 is already added to compiz. New compiz release/tarball (0.9.13.0) most likely will be available tomorrow. Metacity 3.20 stores / reads theme settings from different schema. If you are using GNOME Flashback session then you must use these settings: - org.gnome.metacity.theme name - theme name - org.gnome.metacity.theme type - gtk or metacity If using gtk-window-decorator with MATE session: - org.mate.Marco.general theme - theme name, only metacity type supported If using gtk-window-decorator in other sessions: - org.gnome.desktop.wm.preferences theme - theme name, only metacity type supported --- About theme types - gtk and metacity: metacity type - this is same/old metacity themes that are read from metacity-1 directory. gtk type - this is same theme that is used for client side decorated windows and/or used by mutter. Unfortunately gtk-window-decorator currently does not fully support GTK+ theme. For example with Adwaita theme border is not visible. So any theme that uses box-shadow as border will not work fully. P.S. If you see new bugs/regressions (in gtk-window-decorator) please create bugs in launchpad.net and subscribe me to that bug report.

#### LeCrayonVert commented on 2016-06-28 19:34 (UTC)

Chazza => thx again for maintaining this package. After upgrading metacity from 3.18.4-1 to 3.20.1-1 today, I've had some issues with gtk-window-decorator. I use the following command : gtk-window-decorator --replace --metacity-theme Arc-Darker But the decoration is no longer applied (there is a high contrast decoration theme instead). Any idea ?

#### Xiaoming94 commented on 2015-12-13 16:35 (UTC)

@Chazza yupp, my problem

#### Chazza commented on 2015-12-10 21:38 (UTC)

Thanks for the clarification GaylairdCulbreth.

#### GaylairdCulbreth commented on 2015-12-10 20:27 (UTC) (edited on 2015-12-10 20:36 (UTC) by GaylairdCulbreth)

Protobuf and Mesa inter alia updated today. CCSM won't run: ccsm Traceback (most recent call last): File "/usr/bin/ccsm", line 92, in <module> import compizconfig ImportError: /usr/lib/libcompizconfig.so.0: undefined symbol: _ZNK6google8protobuf7Message11GetTypeNameEv Rebuilding Compiz now... Compiz rebuilt OK ---rebooted. All good now

#### Chazza commented on 2015-12-10 13:06 (UTC)

Compiz builds and runs just fine for me here. Perhaps you could elaborate?

#### Xiaoming94 commented on 2015-12-10 10:15 (UTC)

Looks like this package needs to be patched against the new updated libraries

#### Chazza commented on 2015-11-03 13:24 (UTC)

@nachosduyo Ok. I've re-added ccp to the list. Apologies for the inconvenience.

#### nachosduyo commented on 2015-11-03 12:33 (UTC)

Adding ccp to DCOMPIZ_DEFAULT_PLUGINS fixed the issue.

#### Chazza commented on 2015-11-03 09:42 (UTC)

@korrode, I may be entirely wrong but as I understand it, at the point where "if (initialPlugins.empty () && autoAddCCP)" is evaluated, the intialPlugins list should be empty so ccp should be auto-added. I did indeed try renaming ~/.config/compiz-1 and noticed no issues.

#### korrode commented on 2015-11-03 08:18 (UTC) (edited on 2015-11-03 08:21 (UTC) by korrode)

Also Chazza, did you temporarily rename your ~/.config/compiz-1 folder and restart compiz (and then try to enable more plugins in CCSM) to check what the true default state is?

#### korrode commented on 2015-11-03 08:14 (UTC)

http://bazaar.launchpad.net/~compiz-team/compiz/0.9.12/revision/3951 I'm no C++ coder, but it looks to me like the change to main.cpp in r3951 only auto-activates cpp if the initial plugins list is empty. i.e. only if the configure line is this (or not present at all): -DCOMPIZ_DEFAULT_PLUGINS="" So it could be that Since we provide sane defaults regarding initial plugins, cpp must still be specified.

#### Chazza commented on 2015-11-02 21:49 (UTC)

Thanks for reporting. I haven't noticed this behaviour myself so far. By any chance, is the issue fixed if you add ccp to the -DCOMPIZ_DEFAULT_PLUGINS line in the PKGBUILD and then rebuild Compiz? I removed it because ccp should by loaded by default from r3951 onwards but perhaps this isn't working properly in your case.

#### nachosduyo commented on 2015-11-02 20:28 (UTC) (edited on 2015-11-02 20:29 (UTC) by nachosduyo)

I use LXDE with Compiz instead of Openbox. Upon upgrading 0.9.12.2-7 -> 0.9.12.2-9 there is an issue that on bootup not all plugins are in effect; For example, Wobbly Windows and Commands are not, while Animations and Desktop Cube are. Unchecking and rechecking the first two does nothing. The only way to make them work is to execute openbox --replace, then compiz --replace. Downgrading to 0.9.12.2-7 fixed this issue.

#### Chazza commented on 2015-09-13 14:14 (UTC)

Re to the comment below, I've now added xfce4-panel-compiz which is the standard xfce4-panel package with the patches linked to below. I'll continue to update this until such a time as Xfce upstream fixes these problems upstream. https://aur.archlinux.org/packages/xfce4-panel-compiz/

#### Chazza commented on 2015-09-05 15:33 (UTC)

Does anyone use use Compiz with Xfce? If so, are you affected by either of the following issues? * https://wiki.archlinux.org/index.php/Compiz#Xfce_panel_window_buttons_are_not_refreshed_when_a_window_changes_viewport * https://wiki.archlinux.org/index.php/Compiz#Xfce_workspace_switcher_has_wrong_aspect_ratio If you are, there are now Xfce4 panel patches for both issues.

#### Chazza commented on 2015-09-05 10:29 (UTC)

Note on decorators: I've removed the patch which makes gtk-window-decorator the default. I had originally assumed that the compiz-decorator script from upstream was dodgy, hence the patch, but actually it seems the script is fine – it's the command that starts it that's dodgy. I've now changed the default command to /usr/bin/compiz-decorator. The compiz-decorator script will first try to detect a GNOME or KDE session and if it can't it will then look for emerald, gtk-window-decorator and kde4-window-decorator in that order and start the first decorator it finds. This is good news for emerald users as it means you won't have to change the command to emerald --replace anymore – just installing emerald is enough. It also means that emerald will start cleanly, instead of always replacing gwd. You just need to clear the command field in CCSM -> Window Decoration after updating the package so that it says /usr/bin/compiz-decorator – use the button with the broom icon. Gwd users who have never changed the Window Decoration command don't need to do anything, everything should work just as before. Do let me know if there are any issues.

#### Chazza commented on 2015-09-01 11:17 (UTC)

@SanskritFritz No probs. @korrode, seems to work for me so far. I can't say I've tested it much though, I still won't be parted from emerald. Feel free to do with it what you want, it's all free software after all. :)

#### korrode commented on 2015-09-01 11:11 (UTC)

I somehow didn't conclude that the directory names would be the most reliable source of the theme names (seems obvious now that i think about it), at some point i'll update the Zenity script to use the same method. Thanks Chazza! (...or just leech your python/tk app entirely :P :D)

#### SanskritFritz commented on 2015-09-01 11:04 (UTC)

Ah now I'm blushing, sorry for the noise.

#### Chazza commented on 2015-09-01 11:00 (UTC)

https://wiki.archlinux.org/index.php/Compiz_Configuration#GTK_Window_Decorator Also see the scripts linked to a couple of comments down which provide a user friendly way of accomplishing the same thing.

#### SanskritFritz commented on 2015-09-01 10:55 (UTC)

Ok, gtk works as default, but that decoration is quite ugly. How can I change it? I don't use Gnome or the like, Compiz is standalone.

#### Chazza commented on 2015-09-01 10:52 (UTC)

This package won't provide the KDE decorator as it's disabled in the PKGBUILD options. The reason for that is that you would have to install the entire KDE 4 desktop to compile it. I don't know whether it would compile against the Plasma 5 desktop but I rather doubt it. You can use the GTK Window Decorator however which uses Metacity themes. Indeed, that is the default option for this package. Just make sure the command in the Window Decoration plugin says gtk-window-decorator. If it doesn't, hit the broom icon next to the text field which will reset the preference.

#### SanskritFritz commented on 2015-09-01 10:32 (UTC)

What do I need for another decoration than Emerald? AFAIK I can use gtk or kde decorations?

#### Chazza commented on 2015-09-01 10:02 (UTC)

If that one does cause problems, I made a similar tool a little while back that does themes and also does button orders and fonts: https://github.com/charlesbos/my-scripts/blob/master/mcityconf.py It needs python and tk to run.

#### korrode commented on 2015-09-01 09:09 (UTC)

You can grab the Zenity script from compiz-manjaro that provides a friendly way to change Metacity theme, if you like. https://github.com/manjaro/packages-community/blob/master/compiz-manjaro/compiz-gtk-decorator-theme-selector Though i admit, it's handling of themes with spaces in their name is a little flaky (which is due to inconsistencies within Metacity theme handling).

#### ckoresko commented on 2015-08-31 15:16 (UTC)

@Chazza: Thanks, I've followed your advice and disabled gnome-compat plugin in favor of the MATE equivalent (I'm running MATE here so I probably should have done that anyway) and installed the Ceti-2 theme from the AUR. It seems to be working fine now.

#### Chazza commented on 2015-08-28 18:32 (UTC)

@ckoresko I know there are a couple of plugins which, used in combination with the GSettings backend, case Compiz to crash - namely the gnome-compat plugin. Perhaps that was your problem. Regarding the gtk-window-decorator theme, it's not necessary to be using the GSettings backend in order to change the theme. The backends option only specifies how Compiz store its own configuration. Compiz will read the Metacity gsettings keys no matter what backend is being used. I will edit the Wiki to make this clear.

#### ckoresko commented on 2015-08-28 17:41 (UTC)

I just tried switching from flat-file to gsettings (in ccsm ->Preferences) and it caused compiz to crash. Attempting to restart from the commandline resulted in an error like, no key 'terminal' in org.gnome.settings-daemon.plugins.media-keys or something close to that. Apparently compiz expects that key to be present, but it's not (on my system at least). I understand that it's necessary to edit a schema file and run glib-compile-schemas to add a key. I switched back to flatfile configuration for compiz by manually editing ~/.config/compiz-1/compizconfig/config, and that got compiz working again. The reason I was trying to use gsettings is that according to the Arch wiki https://wiki.archlinux.org/index.php/Compiz_Configuration#GTK_Window_Decorator that should make it possible to select a metacity theme for the decorator by selecting it in gsettings under org.gnome.metacity theme theme-name I don't know how to change decorator themes any other way, except by switching to Emerald, which I've found to be rather unstable.

#### Chazza commented on 2015-07-08 07:58 (UTC)

@hazard I primarily maintain the Compiz 0.9 related stuff (as that's what I actually use on a daily basis) but I would be fine with taking over ccsm 0.8 if you don't wish to continue maintaining it.

#### hazard commented on 2015-07-08 07:42 (UTC)

@Chazza you seem to be maintaining the rest of the compiz packages, would you like to takeover ccsm as well?

#### Chazza commented on 2015-06-18 07:38 (UTC)

That's ok. Glad you got it working. :)

#### I-sty commented on 2015-06-18 05:13 (UTC)

@Chazza Thank you so much! You are the Boss! ;-)

#### Chazza commented on 2015-06-17 18:46 (UTC)

Oh yeah, you can't apply the patches to the same srcdir twice. You need a clean srcdir. run makepkg -Ci instead. The -C option will delete the previous srcdir so you're working from a fresh source.

#### I-sty commented on 2015-06-17 18:42 (UTC)

[isti@istiLaptop compiz]$makepkg -i ==> Making package: compiz 0.9.12.1-5 (Wed Jun 17 21:41:53 EEST 2015) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found compiz-0.9.12.1.tar.bz2 -> Found set-gwd-default.patch -> Found focus-prevention-disable.patch -> Found metacity-3_16.patch -> Found client-frame-api.patch ==> Validating source files with sha256sums... compiz-0.9.12.1.tar.bz2 ... Passed set-gwd-default.patch ... Passed focus-prevention-disable.patch ... Passed metacity-3_16.patch ... Passed client-frame-api.patch ... Passed ==> Extracting sources... -> Extracting compiz-0.9.12.1.tar.bz2 with bsdtar ==> Starting prepare()... patching file plugins/decor/decor.xml.in patching file metadata/core.xml.in patching file gtk/CMakeLists.txt patching file gtk/config.h.gtk.in patching file gtk/window-decorator/cairo.c patching file gtk/window-decorator/CMakeLists.txt patching file gtk/window-decorator/decorator.c patching file gtk/window-decorator/events.c patching file gtk/window-decorator/frames.c patching file gtk/window-decorator/gtk-window-decorator.c patching file gtk/window-decorator/gtk-window-decorator.h patching file gtk/window-decorator/gwd-settings.c patching file gtk/window-decorator/gwd-settings-interface.c patching file gtk/window-decorator/gwd-settings-notified.c patching file gtk/window-decorator/gwd-settings-storage-gsettings.c patching file gtk/window-decorator/gwd-settings-storage-gsettings.h patching file gtk/window-decorator/gwd-settings-storage-interface.c patching file gtk/window-decorator/gwd-settings-storage-interface.h patching file gtk/window-decorator/gwd-settings-writable-interface.c patching file gtk/window-decorator/gwd-settings-writable-interface.h The next patch would create the file gtk/window-decorator/metacity-3-16.c, which already exists! Skipping patch. 1 out of 1 hunk ignored patching file gtk/window-decorator/metacity.c patching file gtk/window-decorator/settings.c patching file gtk/window-decorator/switcher.c patching file gtk/window-decorator/tests/CMakeLists.txt patching file gtk/window-decorator/tests/compiz_gwd_mock_settings_storage.cpp patching file gtk/window-decorator/tests/compiz_gwd_mock_settings_writable.cpp patching file gtk/window-decorator/tests/compiz_gwd_mock_settings_writable.h The next patch would create the file gtk/window-decorator/tests/org.gnome.metacity.gschema.xml, which already exists! Skipping patch. 1 out of 1 hunk ignored patching file gtk/window-decorator/tests/org.gnome.mutter.gschema.xml patching file gtk/window-decorator/tests/test_gwd_settings.cpp patching file gtk/window-decorator/util.c patching file gtk/window-decorator/wnck.c ==> ERROR: A failure occurred in prepare(). Aborting... [isti@istiLaptop compiz]$

#### I-sty commented on 2015-06-17 18:38 (UTC)

CMakeError.log http://pastebin.com/GTYbiXr4 CMakeOutput log http://pastebin.com/vWJwbspb

#### Chazza commented on 2014-08-05 11:22 (UTC)

Ok folks. compiz-core-devel has now been renamed to compiz. This package still provides the release version of Compiz 0.9 like always. As of this latest update a few things have been changed. 1) The pkgbuild has been cleaned up a little. 2) The package has been updated to the latest 0.9.11.2 version on launchpad.net. 3) The plugin ccp is now compiled as a default plugin. This means that compiz no needs to be started with compiz --replace ccp. compiz --replace will suffice. I've edited the wiki to highlight this but I'm posting it here as well for anyone who might miss that.

#### korrode commented on 2014-08-04 05:59 (UTC)

You still haven't fixed the fact that it's out of date, devrs0 ;p Look: https://launchpad.net/compiz Look at the "Series and milestones" thingy, look at the downloads button at the right, we're up to 0.9.11.2. https://launchpad.net/compiz/0.9.11/0.9.11.2/+download/compiz-0.9.11.2.tar.bz2 ...or you're just holding off until the naming convention stuff is sorted?

#### devrs0 commented on 2014-08-04 04:05 (UTC)

This now depends on metacity2. Thanks guys.

#### maxzhurkin commented on 2014-08-03 13:46 (UTC)

must depend from metacity2 in aur instead metacity in community repo

#### korrode commented on 2014-07-31 02:38 (UTC)

This'll no doubt be broken when trying to build against the new Metacity 3.x series that just hit Arch repos. I put Metacity 2.x on AUR, my compiz package now depends on that instead. https://aur.archlinux.org/packages/metacity2/ Also, this package is out of date. https://launchpad.net/compiz/0.9.11 We're up to 0.9.11.2 Sidenotes: Metacity hadn't been updated in ~2 years, then last month we get this big version bump from 2.34 to 3.12, including a swap to GTK3: http://ftp.gnome.org/pub/GNOME/sources/metacity/ http://ftp.gnome.org/pub/GNOME/sources/metacity/3.12/metacity-3.12.0.news I'd wager it's a Canonical/Compiz effort (i notice Sam Spilsbury contributed to it). Looks like they are going GTK3 for Compiz 0.9.12: http://bazaar.launchpad.net/~compiz-team/compiz/0.9.12/revision/3877

#### devrs0 commented on 2014-07-06 01:46 (UTC)

Interesting @Digirium, When I went to update the checksum read: 78400ded4eacb88db20a39901da769ca982e4d7e2755631ea599e946579ffc01 Different from both the PKGBUILD and your comment. This file is skipped for now.

#### Digirium commented on 2014-07-05 20:57 (UTC)

The checksum for compiz-0.9.11.tar.gz is showing as invalid. The following checksum works for the file that is downloaded: 3c5e4c71c15118021e4402fe6277cf8972a3be5dea524a4713e893f4efbe4e74 Did not see a problem with the file, the source appears correct i.e. r3873.

#### devrs0 commented on 2014-07-03 19:15 (UTC)

Updated to 0.9.11. Thanks @korrode.

#### korrode commented on 2014-06-28 12:52 (UTC)

Although their Launchpad landing page is not yet updated to reflect it, 0.9.11 is actually released, so marking this out of date. Release commit: http://bazaar.launchpad.net/~compiz-team/compiz/0.9.12/revision/3873 Source download: http://bazaar.launchpad.net/~compiz-team/compiz/0.9.12/tarball/3873 Despite the "0.9.12" in the URL, it actually is the 0.9.11 final release, as stated in the commit.

#### Samsagax commented on 2014-06-17 17:13 (UTC)

Would it be much of a hazzle to add MATE compatibility like this post suggests? http://forums.mate-desktop.org/viewtopic.php?f=2&t=42 I'm using MATE with compiz 0.9.x and it works better than compiz-core-mate package right now.

#### Chazza commented on 2014-06-11 09:22 (UTC)

Added one more patch, this time to disable focus prevention.

#### Chazza commented on 2014-06-10 23:34 (UTC)

I've added another patch which will set gtk-window-decorator as the default decorator in the Window Decoration plugin.

#### Chazza commented on 2014-06-10 21:39 (UTC)

@dev_rs0 Hiya. Just letting you know that I've applied a patch to compiz-core-bzr which should fix the broken placement mode menu in the place plugin. I won't post the whole thing here but you can find the patch in the compiz-core-bzr tarball.

#### korrode commented on 2014-04-06 06:32 (UTC)

I agree the "core" part should be dropped from the package name.

#### beardedlinuxgeek commented on 2014-04-02 09:25 (UTC)

Our 0.8.x series package compiz-core doesn't come with ccsm and a lot of other features. I'm concerned that calling this compiz-core-devel will confuse the heck out of everyone because they'll assume it only includes compiz-core; the 0.9.x series used to be broken up into separate packages as well. What about merging all the official 0.8.x packages into compiz or compiz-total? Compiz is unusable as a window manager without things like the "move window" plugin installed. And Compiz 0.9.x is abandoned and that happened years after 0.8.x was abandoned. Also 0.9.7 is the current stable release of compiz-core (https://launchpad.net/compiz-core/0.9.7) but I see your point.

#### alucryd commented on 2014-04-02 07:25 (UTC)

devrs0: Thx, packages merged. beardedlinuxgeek: Wrong, the latest stable branch is 0.8.x, the 0.9.x branch is unstable. Now you may want to have a look at our official repositories and see that unstable releases have a -devel suffix. Now, I realize compiz-devel would be a better name since all its parts have been merged, but I think it's nice to have all main compiz packages share the same name with different suffixes (compiz-core, compiz-core-devel, compiz-core-bzr).

#### beardedlinuxgeek commented on 2014-04-02 06:55 (UTC)

If you want to rename the package, it should just be compiz. The latest release is 9.10; this package is for the latest release. Unfortunately because of all the dead compiz-* packages from when they were split up, naming this "compiz" would be confusing. So... compiz-dev is perfect.

#### alucryd commented on 2014-04-01 08:05 (UTC)

Merged quite a few compiz orphans into this one. Can you please upload this as 'compiz-core-devel'? compiz-core is the widely used pkgname for compiz, and -devel is the arch suffix for development packages.

#### Chazza commented on 2014-03-25 22:16 (UTC)

Hi. Could you add the following to the post_install() and post_remove() functions of compiz-dev.install echo " -> Updating icon cache..." gtk-update-icon-cache -q -f -t /usr/share/icons/hicolor That way, ccsm won't have a blank icon when using the gnome icon theme (or other icon themes that use the hicolor icons.

0.9.11 is out

#### devrs0 commented on 2014-01-26 22:04 (UTC)

Updated to enable GTK/Metacity by default as per compiz-bzr

#### Chazza commented on 2014-01-26 13:01 (UTC)

@zhqh100 the comments in the compiz-bzr package suggest that you need metacity installed to build compiz even if metacity support is set to off in the PKGBUILD. As a heads up to all users who may not be aware, the window decoration options in this PKGBUILD are all disabled. If you want compiz-decorator-gtk you will need to set the options below to on: # GTK window decorator support GTKWINDOWDECORATOR="off" # Metaciy theme support for GTK window decorator METACITY="off"

#### zhqh100 commented on 2014-01-26 05:35 (UTC)

fatal error: metacity-1/metacity-private/theme.h: No such file or directory #include <metacity-1/metacity-private/theme.h> ^ How to solve this problem?

#### korrode commented on 2013-11-01 17:49 (UTC)

in compiz-dev.install, there's a number of references to: usr/share/gconf/schemas/$pkgname.schemas which I assume are working anyway, but to be safe/correct should have a prefixed forward-slash: /usr/share/gconf/schemas/$pkgname.schemas

#### 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.

#### 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?

0.9.10 is out

#### LeCrayonVert commented on 2013-07-06 16:43 (UTC)

Same error here. Seems to be related to the boost version....

#### kullfar commented on 2013-05-22 08:47 (UTC)

/tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp: In function ‘bool isPendingRestack(compiz::X11::PendingEvent::Ptr)’: /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp:2964:50: error: ‘shared_static_cast’ is not a member of ‘boost’ compiz::X11::PendingConfigureEvent::Ptr pc = boost::shared_static_cast <compiz::X11::PendingConfigureEvent> (p); ^ /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp:2964:111: error: expected primary-expression before ‘>’ token compiz::X11::PendingConfigureEvent::Ptr pc = boost::shared_static_cast <compiz::X11::PendingConfigureEvent> (p); ^ /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp: In function ‘bool isExistingRequest(compiz::X11::PendingEvent::Ptr, XWindowChanges&, unsigned int)’: /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp:2971:50: error: ‘shared_static_cast’ is not a member of ‘boost’ compiz::X11::PendingConfigureEvent::Ptr pc = boost::shared_static_cast <compiz::X11::PendingConfigureEvent> (p); ^ /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp:2971:111: error: expected primary-expression before ‘>’ token compiz::X11::PendingConfigureEvent::Ptr pc = boost::shared_static_cast <compiz::X11::PendingConfigureEvent> (p); ^ /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp: In member function ‘void PrivateWindow::reconfigureXWindow(unsigned int, XWindowChanges*)’: /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp:3197:7: error: ‘shared_static_cast’ is not a member of ‘boost’ boost::shared_static_cast<compiz::X11::PendingEvent> (compiz::X11::PendingConfigureEvent::Ptr ( ^ /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp:3197:58: error: expected primary-expression before ‘>’ token boost::shared_static_cast<compiz::X11::PendingEvent> (compiz::X11::PendingConfigureEvent::Ptr ( ^ /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp: In member function ‘int PrivateWindow::addWindowStackChanges(XWindowChanges*, CompWindow*)’: /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp:4036:8: error: ‘shared_static_cast’ is not a member of ‘boost’ boost::shared_static_cast<compiz::X11::PendingEvent> (compiz::X11::PendingConfigureEvent::Ptr ( ^ /tmp/yaourt-tmp-kullfar/aur-compiz-devel/src/compiz-0.9.8.6/src/window.cpp:4036:59: error: expected primary-expression before ‘>’ token boost::shared_static_cast<compiz::X11::PendingEvent> (compiz::X11::PendingConfigureEvent::Ptr ( ^ make[2]: *** [src/CMakeFiles/compiz_core.dir/window.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/compiz_core.dir/all] Error 2 make: *** [all] Error 2

#### City-busz commented on 2013-04-21 15:41 (UTC)

No, it works well without Unity, but some plugins need to be enabled manually in CCSM, at least: composite, opengl, window decoration, move window, place windows, resize window.

#### nuc commented on 2013-04-21 15:31 (UTC)

Oh, does this mean this package is for Unity only?

#### City-busz commented on 2013-04-21 15:03 (UTC)

No, because unity 6.0 depends on compiz 0.9.8, and I can't update unity to version 7.0, because it depends on unreleased bamf and libunity versions... So I'm currently waiting for bamf 0.4 and libunity 7.0, and then I update all packages at the same time.

#### nuc commented on 2013-04-21 14:58 (UTC)

Please set https://launchpad.net/compiz-ccsm as upstream URL, so that it can be easily found.

#### nuc commented on 2013-04-21 14:50 (UTC)

Latest devel is v0.9.9.0. Could you please update?

#### ImNtReal commented on 2012-11-26 18:54 (UTC)

Shouldn't this also have a provides array?

0.9.8.4 is out

#### commented on 2012-09-25 17:25 (UTC)

Just to let you know that when you update to 9.8.2 you'll need to add a pyton fix to the PKGBUILD sed -i 's|\spython| python2|g' ${srcdir}/compiz-${pkgver}/compizconfig/ccsm/CMakeLists.txt sed -i 's|\spython| python2|g' ${srcdir}/compiz-${pkgver}/compizconfig/compizconfig-python/CMakeLists.txt A fix has been commited but it's not in the 9.8.2 tarball However It crashes when packaging the schemas (even though I thought '-DCOMPIZ_DISABLE_SCHEMAS_INSTALL=On' is ment to stop them installing automatically? -- Recompiling GSettings schemas in /usr/share/glib-2.0/schemas Failed to create file '/usr/share/glib-2.0/schemas/gschemas.compiled.WO9GLW': Permission denied I've ran out of time and patience (and skilz!) at the mo but i'll have a look again later. Any ideas?

#### ShyPixie commented on 2012-08-01 02:06 (UTC)

please replace provides=('compiz-core') by provides=('compiz-core=0.9.7') otherwise the line is ignored

#### rufflove commented on 2012-04-26 17:58 (UTC)

GCC workaround removed. Schema files now handled properly. GNOME session files removed as there are a number of packages on the AUR which provide a variety of gnome-session configurations involving Compiz. TODO: split the decorators into seperate packages.

#### rufflove commented on 2012-04-10 11:14 (UTC)

Updated. Cheers :)

#### whynothugo commented on 2012-04-10 04:00 (UTC)

I actually disabled the error by adding an argument ("-fpermissive" IIRC) to CXX, and it still built fine, and I use wall all day long without issues :)

#### rufflove commented on 2012-04-10 02:27 (UTC)

Disabled 'Wall' by default until the problem is fixed.

#### whynothugo commented on 2012-04-05 23:30 (UTC)

Dependency "compizconfig-python-dev" is missing.

#### whynothugo commented on 2012-04-05 02:53 (UTC)

Build fails: http://pastebin.com/vW7VanTn Disabling the WALL plugin in PKGBUILD is a workaround, but sadly, wall is one of the plugins I use the most.

#### whynothugo commented on 2012-04-05 01:18 (UTC)

This (and a fix) seems to be reported here: https://bugs.launchpad.net/compiz-core/+bug/972519

#### whynothugo commented on 2012-04-05 01:15 (UTC)

Build fails: http://pastebin.com/qRp4GX37

#### rufflove commented on 2012-03-30 15:56 (UTC)

Version bump. gtk-window-decorator builds OK here, but I have Ubuntu patched libs installed... Will try it on a vanilla setup later, if I get time. Please note that no support for runtime issues will be provided here.

#### SanskritFritz commented on 2012-03-26 08:26 (UTC)

KDE decorator works, don't even try gtk decorator. Beware though, this version of compiz is very buggy and unstable. I used it for a day, and quickly downgraded to 0.8.

#### whynothugo commented on 2012-03-26 08:24 (UTC)

I apologize for the noise (again), but, is there any window decorator you guys use with this vesion of compiz? (I'm considering migrating to it, but I want to be sure first).

#### SanskritFritz commented on 2012-03-26 07:52 (UTC)

AFAIK there isn't.

#### whynothugo commented on 2012-03-26 07:47 (UTC)

Is there a versino of emerald that works with this version of compiz?

#### Janhouse commented on 2012-03-21 14:52 (UTC)

I used this PKGBUILD to get it working and escape the segfault: http://tinyurl.com/78vk7lc It won't build the gtk-window-decorator (it had bugs anyway, at least the git version), so I use kde4-window-decorator instead.

#### rufflove commented on 2012-03-05 03:49 (UTC)

Appears to be broken with newer Gconf versions atm.

#### commented on 2012-01-15 21:00 (UTC)

Also, please make this provide compiz-core=0.9.5.0.

#### commented on 2012-01-15 20:30 (UTC)

Please change the line: install=('compiz.install') to: install='compiz.install' The former doesn't seem to work.

#### ShadowKyogre commented on 2011-11-25 22:00 (UTC)

Other than this is out of date, the makedepend cython needs to be cython2.

#### commented on 2011-10-17 18:53 (UTC)

I can't configure metacity theme (gconftool-2 --set /apps/metacity/general/theme --type string "Theme") for gtk-window-decorator as I was doing with compiz 0.8, i'm using xfce4, anyone knows what could be the problem?

#### rufflove commented on 2011-09-13 12:53 (UTC)

I use gtk-window-decorator and would think most people who use compiz 0.9.x are. It was unpredictably segfaulting with 0.9.5.92 on my desktop so I'm currently using Xiao-Long Chen's git packages but no such problems with 0.9.5 for me.

#### commented on 2011-09-12 01:25 (UTC)

Is anyone else trying to use gtk-window-decorator? If I try to use it, I get segfaults.

#### chenxiaolong commented on 2011-08-27 16:34 (UTC)

For users installing this package, here's a working source package: http://ompldr.org/vYTJ2Nw/compizconfig-backend-gconf-git-20110827-1.src.tar.gz

#### whynothugo commented on 2011-07-23 18:08 (UTC)

Have you tried running compiz ccp --replace? ccp = CompizConfigPlugin. Cheers!

#### commented on 2011-07-23 17:22 (UTC)

Hey rufflove, Thank you for supporting the community with the PKGBUILDs! :) I like your work! However, I'm not able to run compiz under XFCE4 (I've also installed metacity and recompiled all the packages). When I'm trying to run compiz --replace in terminal, I get the following message: compiz (core) - Warn: Value type is not yet set I've set under window-decorator the following command: gtk-window-decorator --replace When I run gtk-window-decorator --replace command in terminal nothing happens. All other effects are not working (I think there is some error with gtk-window-decorator?) I have an intel card (Samsung NC10 NETBOOK) I hope, that you look into my matter and help me soon. Regards, Chris

#### rufflove commented on 2011-07-21 21:44 (UTC)

I'm almost certain libstdc++5 isn't required for wallpaper. I've tested on several machines and I can replicate the wallpaper problem as detailed below (the symptoms you experience are just the result of the plugin not loading and hence the desktop not being redrawn). Unsetting the cmake build type resolved it, hence having rebuilt core, presumably with the new package, it works for you.

#### whynothugo commented on 2011-07-21 05:09 (UTC)

I've tracked down my issue. Installed libstdc++5, rebuild both -core-dev and -plugins-extra-dev, and my wallpapers work again, and everything is pretty again <3 Maybe libstdc++5 should still be a depend? Without it, wallpapers break for me (I get a black background, and windows leave traces on it when I move them around).

#### rufflove commented on 2011-07-21 02:10 (UTC)

The problem arises when CMAKE_BUILD_TYPE is set to "Release". It needs to be left at the default, "Debug". Wallpaper still complains with "Warn: Malformed option" when loading, but it works OK for me.

#### whynothugo commented on 2011-07-21 01:43 (UTC)

Could you clarify a bit more what this change was? Since wallpapers is what's primarily broken on my setup, I'm quite sure that's the issue.

#### rufflove commented on 2011-07-19 15:28 (UTC)

Forgot that'd I'd also set the cmake install type. It seems that it was causing problems with the window snapping and place as well as wallpaper. Sorry about that!

#### whynothugo commented on 2011-07-17 20:47 (UTC)

This should only depend on "compizconfig-python-dev", and not "compiz-core-dev", since the latter is a dependancy of the former (so you don't need to explicitly mention it).

#### whynothugo commented on 2011-07-17 20:46 (UTC)

Well I still have libstdc++5 installed (since it's required for something else), and I don't think "testing=Off" should break it. I'll see if I can see if it's not related to some other dep that was updated the same say.

#### rufflove commented on 2011-07-17 19:42 (UTC)

Grid plugin has moved to main from extra... Changed the plugin options accordingly.

#### rufflove commented on 2011-07-17 17:36 (UTC)

Its seems the deps are partially documented on the package pages e.g. http://wiki.compiz.org/PluginsMain but they are currently incomplete. For starters, desktop wall also requires mouse polling...

#### Unia commented on 2011-07-17 16:03 (UTC)

Ah yes, that's it. Is there a way I can sort these things out myself? :) Thanks!

#### rufflove commented on 2011-07-17 15:00 (UTC)

Those mentioned below (testing set to off) and also the removal of libstdc++5. Let me know if you figure it out.

#### rufflove commented on 2011-07-17 14:45 (UTC)

It looks like you've disabled the text plugin. Some of the plugins are dependant on others. -ltext is referred to libtext.so which should be present under build/text.

#### Unia commented on 2011-07-17 12:34 (UTC)

Hello. I'm getting an error trying to build this: /usr/bin/ld: cannot find -ltext /usr/bin/ld: cannot find -ltext First it threw me the error at the shift plugin, so I tried disabling that. Now it throws it to me at the scale plugin. Any fix?

#### whynothugo commented on 2011-07-17 05:24 (UTC)

The wallpaper plugin no longer works, and I get a realy ugly background (superposition of different windows that passed though a region). What changes were made from 0.9.5.0-1, so I can track it down? Thanks!

#### rufflove commented on 2011-07-16 01:37 (UTC)

Amended dependencies.

#### rufflove commented on 2011-07-15 23:58 (UTC)

Amended dependencies with libxcomposite, libxinerama and libxrandr. Another build option added.

#### rufflove commented on 2011-07-15 11:26 (UTC)

I wouldn't know, I use gtk-window-decorator with metacity theme support myself, apart from using Emerald in Ubuntu when gnome 3 broke gtk-window-decorator. The Emerald project has not been in active development for years and the Compiz team are not encouraging its continued use.

#### whynothugo commented on 2011-07-15 05:53 (UTC)

emerald++ no longer works after the last update. compiz-core++ should not remain in provides, since this is misleading. Any change emerald gets fixed/repackaged to we can have window decorations again? :)

#### rufflove commented on 2011-07-14 15:57 (UTC)

Version bump & .install file fixed.

#### rufflove commented on 2011-07-14 15:28 (UTC)

Version bumped. @grvrulz The previous change was not made to fix your opacity issue. It was to 'fix' metacity integration, if the user neglects to install compizconfig-backend-gconf-dev. Post-installation issues should be raised on the forums, rather than here, tbh. Sorry! :)

#### properlypurple commented on 2011-07-14 11:41 (UTC)

i installed everything again bu ti still get this http://imagebin.org/163070

#### rufflove commented on 2011-07-07 01:12 (UTC)

Updated: The gtk-window-decorator gconf schemas are now installed by this package on a conditional basis. Installing compizconfig-backend-gconf-dev is still advisable for GNOME users.

#### rufflove commented on 2011-06-29 20:01 (UTC)

metacity_theme_active_opacity should be set to '1' to be fully opaque. What values do you have set in the other /apps/gwd/* keys? It think the problem may lie in setting elsewhere.

#### properlypurple commented on 2011-06-28 16:10 (UTC)

i had already installed metacity and gconf before building, and i also installed compizconfig-backend-gconf-dev, then rebooted. Now i have the metacity themes but they are tansparent. I've tried changing the keys apps/gwd/metacity_theme_active_opacity to 100 and 1 but it doesn't change anything.. i get this http://imagebin.org/160403

#### rufflove commented on 2011-06-27 18:15 (UTC)

Assuming you have installed metacity and gconf before building this package, then its because you haven't installed the compizconfig-backend-gconf-dev package, which installs the gwd schema. It may be possible to have gwd pick up the metacity theme without installing the gconf backend. If so, I'll have this package do the fix up, rather than the *-gconf-dev package...

#### properlypurple commented on 2011-06-27 16:09 (UTC)

why doesn't gtk-window-decorator pick up the metacity theme??

#### rufflove commented on 2011-06-17 17:59 (UTC)

Updated to give basic setup pointers and set gtk-window-decorator as default

#### rufflove commented on 2011-06-16 23:23 (UTC)

Added a post-install notice with basic pointers and several build options; you can now omit gtk-window-decorator and/or include a basic configuration for use with gnome-session.

#### haagch commented on 2011-06-12 11:41 (UTC)

Somewhere a notice that it has to be started with "compiz --replace ccp" is needed would be nice. :)

#### rufflove commented on 2011-05-27 23:03 (UTC)

Tested on x86_64. Plugins can be selectively installed by toggling the respective parameters provided in the PKGBUILD.

#### rufflove commented on 2011-05-27 22:59 (UTC)

Tested on x86_64. Plugins can be selectively installed by toggling the respective parameters provided in the PKGBUILD.

#### rufflove commented on 2011-05-27 22:44 (UTC)

Tested on x86_64. Plugins can be selectively disabled by toggling the parameters provided in the PKGBUILD.