Package Details: compiz 0.9.14.2-11

Git Clone URL: https://aur.archlinux.org/compiz.git (read-only, click to copy)
Package Base: compiz
Description: Composite manager for Aiglx and Xgl, with plugins and CCSM
Upstream URL: https://launchpad.net/compiz
Licenses: MIT, GPL-2.0-or-later, LGPL-2.1-or-later
Conflicts: ccsm, compiz-bcop, compiz-core, compiz-fusion-plugins-experimental, compiz-fusion-plugins-extra, compiz-fusion-plugins-main, compiz-gtk, compizconfig-python, libcompizconfig, simple-ccsm
Provides: ccsm, compiz-bcop, compiz-core, compiz-plugins-extra, compiz-plugins-main, compizconfig-python, libcompizconfig
Submitter: None
Maintainer: xiota
Last Packager: xiota
Votes: 168
Popularity: 0.001211
First Submitted: 2014-08-04 13:22 (UTC)
Last Updated: 2025-05-01 08:15 (UTC)

Required by (27)

Sources (10)

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 .. 57 Next › Last »

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

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

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 .. 57 Next › Last »