Package Details: caffeine-ng 4.2.0-1

Git Clone URL: https://aur.archlinux.org/caffeine-ng.git (read-only, click to copy)
Package Base: caffeine-ng
Description: Status bar application able to temporarily inhibit the screensaver and sleep mode.
Upstream URL: https://codeberg.org/WhyNotHugo/caffeine-ng
Keywords: caffeine powersaving screensaver
Licenses: GPL-3.0-or-later
Conflicts: caffeine, caffeine-bzr, caffeine-oneclick, caffeine-systray
Provides: caffeine, caffeine-bzr, caffeine-oneclick, caffeine-systray
Replaces: caffeine-oneclick, caffeine-systray
Submitter: whynothugo
Maintainer: whynothugo (darose)
Last Packager: whynothugo
Votes: 120
Popularity: 1.14
First Submitted: 2014-10-19 05:26 (UTC)
Last Updated: 2023-05-08 10:23 (UTC)

Pinned Comments

whynothugo commented on 2023-05-05 09:34 (UTC)

After an upgrade to Python 3.11, you need to rebuild this package (and all Python packages in the AUR).

Latest Comments

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

whynothugo commented on 2017-01-26 16:05 (UTC)

@manuelschneid3r This is the normal "build". I'll try to make logging configurable (as a feature) when I get a chance.

manuelschneid3r commented on 2017-01-25 16:03 (UTC)

Is this a debug build or is the application printing that much info by default? caffeine pollutes the journalctl

whynothugo commented on 2017-01-19 20:04 (UTC)

@punk0x29a Please read the pinned post.

punk0x29a commented on 2017-01-19 18:22 (UTC)

pkg_resources.DistributionNotFound: The 'caffeine-ng==3.3.8' distribution was not found and is required by the application That's what I get now. Previously I fixed the problem by editing requirements, but now that's something different ( I guess...)

PhotonX commented on 2017-01-18 19:19 (UTC)

Ok, I got the point. In my case it was enough to rebuild caffeine-ng to make it work again. On another system I had to rebuild a dependency (ewmh) as well. In the latter case indeed rebuilding caffeine-ng wouldn't help, in the former it would.

whynothugo commented on 2017-01-18 14:35 (UTC)

The setups in question have python pckages pointing to an absent python, and not accesible by the default python. You might not want to call them broken (it's semantics and poorly relevant), but the rest of the point stands; pushing the pkgrel won't rebuild dependencies. Users should have rebuilt python packages during the python36 update. TBH, I think this should have been an Arch announcement, since it affected too many users/packages. I've just pinned that comment helping them do that because it's relevant here, but there's no way to push a fix to affected users.

PhotonX commented on 2017-01-18 07:54 (UTC)

What do you mean by "broken setups"? I don't consider my setup broken. :) Isn't a rebuild required for everybody after python is updated? Concerning the warning: What does grep -R "$(pwd)/src" pkg/ return if you run in the build directory?

whynothugo commented on 2017-01-18 06:28 (UTC)

> WARNING: Package contains reference to $srcdir. Not sure how to deal with that. Any hints?

whynothugo commented on 2017-01-18 06:27 (UTC)

> why don't you just bump the revision if you realize that a rebuild is necessary? A rebuild of dependencies is necessary only for users with broken setups. Pushing the pkgrel won't rebuild dependencies, and would trigger rebuilds for users who don't need it.

PhotonX commented on 2017-01-17 21:39 (UTC)

Makepkg reports: WARNING: Package contains reference to $srcdir. Check https://wiki.archlinux.org/index.php/makepkg#WARNING:_Package_contains_reference_to_.24srcdir Also, why don't you just bump the revision if you realize that a rebuild is necessary?

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