Package Details: bleachbit-cli 1.10-2

Git Clone URL: https://aur.archlinux.org/bleachbit-cli.git (read-only)
Package Base: bleachbit-cli
Description: Deletes unneeded files to free disk space and maintain privacy. CLI version/no GUI.
Upstream URL: http://bleachbit.sourceforge.net/
Licenses: GPL3
Conflicts: bleachbit
Provides: bleachbit=1.10
Submitter: graysky
Maintainer: graysky
Last Packager: graysky
Votes: 15
Popularity: 0.067487
First Submitted: 2011-11-18 19:35
Last Updated: 2016-02-11 20:53

Latest Comments

ansatz commented on 2016-02-11 09:00

==> ERROR: conflicts should be an array

==> ERROR: the build failed
-> Status failed (1): bleachbit-cli

fix:
-conflicts='bleachbit'
+conflicts=('bleachbit')

graysky commented on 2015-12-25 15:52

Try building in a clean chroot. You can use clean-chroot-manager if you don't wanna mess with the Arch scripts.

cli-cker commented on 2015-12-25 15:02

Does anyone know why this error occurs where it fails to build? I've tried building on both "linux" and "linux-grsec" kernel with the same issue each time: https://bpaste.net/raw/825e82fa7096

graysky commented on 2015-12-03 19:56

@JBecker - Actually 1.92 is beta...

graysky commented on 2015-02-01 12:03

Thanks for the detailed explanation. Timely discussion as the dev for another package I maintain, backintime, is doing the same to remove gksu from his code as well... although his .policy file looks a little different that your version[1]. I found your bug report against bleachbit[2], pity they haven't assigned it in over a year. In any case, I don't want deviate from upstream when packaging this since calling via sudo does actually work (but as you pointed out uses /root as the config dir) and since the PKGBUILD itself does not require gksu. I'd say let's wait and see but after a year of inactivity...

1. http://bazaar.launchpad.net/~bit-team/backintime/trunk/view/head:/qt4/net.launchpad.backintime.policy
2. https://bugs.launchpad.net/bleachbit/+bug/1111061

msx commented on 2015-02-01 00:07

Interesting discussion about the differences between pkexec and sudo: https://www.mail-archive.com/kde-frameworks-devel@kde.org/msg20449.html

msx commented on 2015-02-01 00:05

Oh great, I see a couple of typos (on my recent comment), sorry about that, I wish I could just edit the post.

msx commented on 2015-02-01 00:03

Hello and thanks for bringing this up, TBH I needed to do a little research as I was unsure too... Well, in fact I was as puzzled as you; thankfully I started to remember:

a) There are a handful of issues that may arise when running X applications with sudo, namely:
. Depending on how sudo is configured the invoked application may write configuration files into the $USER directories but with root ownership;
. The application can simply default to /root directory and write its configuration files there when invoked with sudo;
- Sudo does not provide a graphical frontend (i.e. for the cases when you want to create launcher, gksudo/kdesudo does that);
- Sudo does not handle the X11 cookie file correctly (gksudo/kdesudo does);
- Anything else?
b) On the other hand about PolicyKit/pkexec:
. I remember I started to learn PolicyKit at that time so it was a nice exercise to just start using it :)
. PolicyKit does handle X applications in a proper way and it seems to be may be not that much but still a bit more flexible than gksudo/kdesudo;
. From what I understand PolicyKit is a cleaner way to escalate privileges than to use sudo - albeit a complicated one;
. The problem I describe above about root owning $USER files when the X application is launched via sudo does not apply to pkexec;
. While both sudo and pkexec have a timeout feature they work slightly different: with sudo the timeout counter is reset every time you invoke it within the window of the timeout, in pkexec the timeout only works on the invoked application; no matter you quit the app within the timeout window if you launch another application pkexec will ask again for the password.

Both sudo/gksu/kdesu and pkexec aim to address the same target so they share a lot of functionality but at the time they are slightly different; IMHO pkexec is a nicer way to escalate some X app privileges and should be preferred over sudo/gksudo, problem is that the PolicyKit rules that enable pkexec to do its magic should be provided by developers or packagers while with a moderately well configured sudo/gksudo you are on your feet w/o since minute zero.

Finally: take this note with a grain of salt. I encourage anybody who reads this and isn't bored to death to do his/her own research and don't take my word as a final one, also if anybody sees anything wrong please be kind to enlighten us!

Cheers.

graysky commented on 2015-01-31 19:31

Forgive my ignorance, but what is the difference between `sudo bleachbit --switch1 --switch2` and pkexec bleachbit --switch1 --switch2`?

msx commented on 2013-01-31 03:54

Hi,
I just stumbled across an issue trying to run Bleachbit with pkexec since the upstream doesn't provide the needed .policy file.
Until they finally add it -they proven to be very diligent on fixing bugs and accepting patches- may be it could be a good idea to add it to it's PKGBUILD.

If you choose to add it, maybe you would like to name it something like 'org.archlinux.pkexec.bleachbit.policy' (I chosen to follow the naming scheme other AUR packagers used).

The file must be installed in /usr/share/polkit-1/actions and it will enable pkexec to launch Bleachbit effectively rendering sudo/gksu/kdesu obsolete.

Grab it here: http://pastebin.com/Nj36aWDw

All comments