Package Details: compiz 0.9.14.1-3

Git Clone URL: https://aur.archlinux.org/compiz.git (read-only, click to copy)
Package Base: compiz
Description: Composite manager for Aiglx and Xgl, with plugins and CCSM
Upstream URL: https://launchpad.net/compiz
Licenses: GPL, LGPL, MIT
Conflicts: ccsm, compiz-bcop, compiz-core, compiz-fusion-plugins-experimental, compiz-fusion-plugins-extra, compiz-fusion-plugins-main, compiz-gtk, compizconfig-python, libcompizconfig, simple-ccsm
Provides: ccsm=0.9.14.1, compiz-bcop=0.9.14.1, compiz-core=0.9.14.1, compiz-plugins-extra=0.9.14.1, compiz-plugins-main=0.9.14.1, compizconfig-python=0.9.14.1, libcompizconfig=0.9.14.1
Submitter: Chazza
Maintainer: Chazza
Last Packager: Chazza
Votes: 158
Popularity: 1.77
First Submitted: 2014-08-04 13:22
Last Updated: 2020-08-15 10:22

Required by (27)

Sources (7)

Pinned Comments

Chazza commented on 2019-02-14 22:34

Anyone here looking for compiz-bzr should install compiz-git instead. Upstream development has moved back to git, making compiz-bzr obsolete.

The compiz-git package is available here: https://aur.archlinux.org/packages/compiz-git/

Chazza commented on 2018-09-14 14:00

When library names like libprotobuf.so.XX change you just need to rebuild compiz. It's not a problem with the PKGBUILD. This is normal for AUR packages. Packages in the official repos also get rebuilt when libraries are updated.

Note that you shouldn't symlink new library names to old. This will create problems for you further down the line.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

firemage78 commented on 2020-08-24 09:00

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

@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

@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

@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

@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

@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

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

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

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

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