Arch Linux User Repository

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.

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 :-)

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 :)

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

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.

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.

I reported a bug https://bugs.launchpad.net/compiz/+bug/1927992

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

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

For crash please open bug report https://bugs.launchpad.net/compiz/+filebug and attach stacktrace.

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.

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

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.

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.

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

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

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

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

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
Package '>=', required by 'glib-2.0', not found
Package '3.38.0', required by 'glib-2.0', not found

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?

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

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

Otherwise I'm not too sure.

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?

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.

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

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

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?

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

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?

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

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.

That was fast. Thank you, @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.

AS far as I can see, References to

META_BUTTON_TYPE_SHADE META_BUTTON_TYPE_ABOVE META_BUTTON_TYPE_STICK META_BUTTON_TYPE_UNSHADE META_BUTTON_TYPE_UNABOVE META_BUTTON_TYPE_UNSTICK

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.

@Juancri: Confirmed

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’?
   98 |         case META_BUTTON_TYPE_SHADE:
      |              ^~~~~~~~~~~~~~~~~~~~~~
      |              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’?
  104 |         case META_BUTTON_TYPE_UNSHADE:
      |              ^~~~~~~~~~~~~~~~~~~~~~~~
      |              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’?
  557 |             return META_BUTTON_TYPE_SHADE;
      |                    ^~~~~~~~~~~~~~~~~~~~~~
      |                    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’?
  563 |             return META_BUTTON_TYPE_UNSHADE;
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~
      |                    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...

@robson

Thank you that worked!

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

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!

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.

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

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

@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

@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

@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

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

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

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.

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"

 #-- Compiler and Linker Flags
 # -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))"

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

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

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.

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

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

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

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

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)

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

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
~/.cache/yay/compiz/src/compiz-0.9.14.1/po/as.po:7: warning: header field 'Language' missing in header
[  8%] Generating ast/LC_MESSAGES/compiz.mo
[  8%] Generating az/LC_MESSAGES/compiz.mo

. . . . .

~/.cache/yay/compiz/src/compiz-0.9.14.1/po/zu.po:5: warning: header field 'Language' missing in header
[ 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)

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

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

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
[  3%] Generating 50-compiz-navigation.xml
Merging translations into /home/oscar/aur/compiz/src/compiz-0.9.14.1/build/gtk/gnome/50-compiz-navigation.xml.
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[2]: *** Deleting file 'gtk/gnome/50-compiz-navigation.xml'
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...

@Chazza It's OK now. Thanks.

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?

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

@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

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.

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!
See also "/tmp/makepkg/compiz/src/compiz-0.9.14.1/build/CMakeFiles/CMakeOutput.log".
==> ERROR: A failure occurred in build().
    Aborting...

how could i set the missing?

https://git.launchpad.net/compiz/tree/plugins/CMakeLists.txt#n12

Group plugin is disabled...

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?

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

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

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

Thanks for the heads up and the patch! Committed.

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

• ccsm-escape-fix.patch
• PKGBUILD

This was happening because Python 3.8 removed a deprecated function.

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

@chorriwuarri See my pinned comment.

latest package update protonbuf breaks compiz

edit @Chazza yeah its work, thanks

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.

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

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

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

@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 :)

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

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.

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.

[1] https://bugs.launchpad.net/dockbar/+bug/1329241/comments/1

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.

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

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

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

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.

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

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

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

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

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.

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

@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

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

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

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

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

Edit: done.

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

Great! Thanks alot muktupavels

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1816629

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

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]

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

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

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

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

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

@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 :)

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

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.

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

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.

Please have a read of the wiki page: https://wiki.archlinux.org/index.php/Arch_User_Repository#Prerequisites

missing dependency: 'patch'

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

@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 :(

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

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

[1] https://bugs.launchpad.net/compiz/+bug/1767825

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.

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

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

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

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.

[1] https://aur.archlinux.org/packages/compiz-bzr/

https://pastebin.com/HakKwRqi

I run Compiz by replacing Marco via the autostart Mate.

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?

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.

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

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.

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

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

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.

@yoburtu I've responded to your email.

hello you have installed: protobuf-c

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

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

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

Can I access to previous version?.

Regards.

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

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

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

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.

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! :)

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

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

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

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

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.

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

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

@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

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

/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.)