Package Details: compiz 0.9.14.2-5

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
Keywords: ccsm
Licenses: MIT, GPL-2.0-or-later, LGPL-2.1-or-later
Conflicts: ccsm, compiz-bcop, compiz-core, compiz-fusion-plugins-experimental, compiz-fusion-plugins-extra, compiz-fusion-plugins-main, compiz-gtk, compizconfig-python, libcompizconfig, simple-ccsm
Provides: ccsm, compiz-bcop, compiz-core, compiz-plugins-extra, compiz-plugins-main, compizconfig-python, libcompizconfig
Submitter: None
Maintainer: xiota
Last Packager: xiota
Votes: 165
Popularity: 0.63
First Submitted: 2014-08-04 13:22 (UTC)
Last Updated: 2024-03-24 22:06 (UTC)

Required by (27)

Sources (6)

Pinned Comments

<deleted-account> commented on 2018-09-14 14:00 (UTC)

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

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 53 Next › Last »

<deleted-account> commented on 2020-08-20 18:27 (UTC)

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

<deleted-account> 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"

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

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

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 53 Next › Last »