Package Details: compiz 0.9.14.2-9

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: 166
Popularity: 0.53
First Submitted: 2014-08-04 13:22 (UTC)
Last Updated: 2024-10-31 17:58 (UTC)

Required by (27)

Sources (9)

Latest Comments

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

xiota commented on 2024-10-31 04:26 (UTC) (edited on 2024-10-31 18:00 (UTC) by xiota)

I've undone the sodep change. Those who prefer sodeps may look in the PKGBUILD to see how to enable it.

The preferred way to build packages I maintain is still in a clean chroot.

geoffk commented on 2024-10-31 03:24 (UTC)

Thanks for the help and quick reply.

I have a confession to make--I'm lazy, so I usually just use paru. 8 times out of 10, it works fine and saves me some steps. This turned ot to be one of the exceptions. When I downloaded the snapshot and ran it by hand, it compiled, installed and ran with no issues. It would be nice if paru worked too, but I can't say that the package is actually broken.

Sorry for the slightly bogus complaint. If anyone has issues with an AUR helper, than try running it the offical way and it should work.

xiota commented on 2024-10-30 16:23 (UTC) (edited on 2024-10-30 16:24 (UTC) by xiota)

@geoffk Are you using -s flag with makepkg? (If so, try without.)

geoffk commented on 2024-10-30 16:13 (UTC)

Ok, so I bypassed the dependency with the pacman -dd flag. Now I'm trying to re-build and I get the error:

Error: Failed to prepre for processing (dependencies could not be resolved) :Unmet compiz dependencies because libprotobuf.so=28.1.0-64 cannot be resolved

So, as long as Compiz lists this outdated package as a required dependency, it won't build and is essentially broken.

STG commented on 2024-10-06 16:44 (UTC) (edited on 2024-10-06 16:51 (UTC) by STG)

protobuf should not be included as a dependency since compiz isn't getting updated very often. it's going to need to be rebuilt anyway so no point in having protobuf dependency which is going to break regular updates.

lectrode commented on 2024-10-01 01:18 (UTC) (edited on 2024-10-01 01:38 (UTC) by lectrode)

Use of AUR at all is "unnecessary". Users who choose to do so commit themselves to some "extra steps"

Fair point, but if any AUR package that needs a rebuild is going to block updates until it is removed, that completely negates the purpose of rebuild-detector (which, again, is in the official repos, and that should be a clear indicator of how AUR package rebuilds are expected to be handled).

But that's your call. Anyone who prefers being able to update the system, then rebuild the package when they so choose (without having to remove it first) is welcome to use compiz-easy-patch.

xiota commented on 2024-09-30 20:44 (UTC) (edited on 2024-09-30 20:46 (UTC) by xiota)

shouldn't block security updates

Majority of updates on Arch Linux are not "security updates". Deferring upgrading a few packages is of little consequence.

do not introduce unnecessary extra steps

Use of AUR at all is "unnecessary". Users who choose to do so commit themselves to some "extra steps".

lectrode commented on 2024-09-30 08:03 (UTC) (edited on 2024-09-30 08:07 (UTC) by lectrode)

I maintain a separate variant of this package, so I don't have much skin in this particular decision. That said;

The existence of an AUR package shouldn't block security updates for the rest of the system. This package shouldn't need to be uninstalled every single time a dependency is updated. 'sudo pacman -Syudd' is not a long-term solution - it is a temporary workaround.

Depending on the specific version of a dependency that a package was compiled against should primarily be for packages from the official repos, since those updates are usually provided together and you shouldn't update one without the other.

AUR packages needing a rebuild after the rest of the system is updated is a well-known staple of using packages from the AUR. If someone needs a reminder to recompile something after updating the rest of the system, that's what tools like rebuild-detector (in the official repos) are for.

Please do not introduce unnecessary extra steps for using AUR packages. Please do not prioritize continued functionality of an AUR package over security updates for the rest of the system.

(compiz doesn't even fully stop working after that dependency is updated - it just doesn't read your custom config anymore. these extra steps are even more annoying than just recompiling it after the fact)

xiota commented on 2024-09-26 21:33 (UTC) (edited on 2024-10-31 17:59 (UTC) by xiota)

compiz needs to be rebuilt for library updates. The preferred way to build any package I maintain is in a clean chroot.

kinoru commented on 2024-09-26 18:43 (UTC)

@xiota I'm also having a related issue. This is unfortunately blocking the full system upgrade.

error: failed to prepare transaction (could not satisfy dependencies)
:: installing protobuf (28.2-1) breaks dependency 'libprotobuf.so=28.1.0-64' required by compiz

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