This article is a copy of the original developer of Kalu jjacky.
What is kalu ?
kalu (which could stand for “Keeping Arch Linux Up-to-date”) is a small application that will add an icon to your systray and sit there, regularly checking if there’s anything new for you to upgrade. As soon as it finds something, it’ll show a notification to let you know about it. Very classic stuff.
What makes kalu any different?
For starter, it doesn’t need root privileges to do its checking. Not because it doesn’t synchronize databases, since that would make it mostly useless, but because it will create a temporary copy of your sync databases, sync those, and then remove them of course.
The idea is not only not to require root privileges, but more importantly to
avoid putting you in a situation where you’d risk messing up your system, as
you might unknowingly end up basically doing a
pacman -Sy foobar (which is
pretty generally understood to be a bad idea).
Because if kalu did sync your databases, and there were upgrades available, but you did not apply them right away (for one reason or another, e.g. you’re busy, or were AFK when the notification popped up and didn’t see it…) then your next -S operation would really by a -Sy, event though you might not even realize it.
What does it check for?
kalu can check for a few things :
- Arch Linux News. To be sure not to miss an important announcement from Arch Linux’s official website.
- Available upgrades for installed packages. That is, anything from one of
the repos, or what would be upgraded with a
- Available upgrades for non-installed packages. You can define a list of “watched packages”, that is packages for which you’d like to be notified when an upgrade is out, even though they’re not installed. (E.g. packages you repack for yourself to apply a patch or something)
- Available upgrades for AUR packages. All foreign packages (i.e. not found
in any repo, aka
-Qm) can be checked for upgrades available in the AUR. Any and all packages not found in the AUR will also be reported in a separate notifications, allowing you to spot e.g. packages renamed/removed. Of course, if all is fine those packages should be added to the ignore list, not to check the AUR for them any further.
- Available upgrades for watched AUR packages. Just like with “regular” packages, you can have a list of packages in the AUR for which you’d like to be notified when an upgrade is available, even though they’re not installed.
Of course you don’t have to use all of this, and you can define which of those checks kalu should do. Besides maintaining lists of watched (AUR) packages, you can also define a list of foreign packages that kalu should not check the AUR for. Since there’s no reason to check for packages you know aren’t from the AUR (e.g. packages of your own making).
When does it check?
You can define how often kalu should run its automatic checks, from a few minutes to days (or more). You can also, of course, have them run at any time through menu Check for Upgrades.
Automatic checks are good if you’re in front of the screen, so you can see the notifications and act on them (or not). But even if you have your computer on 24/7, chances are you still go to bed at some point.
Since there’s no reason to have kalu keep checking for upgrades then, you can define a “paused period” during which no automatic checks will be performed (e.g. nothing from 11 p.m. till 8 a.m.). And it is also possible to (un)pause kalu on demand.
Whenever something is found, kalu will show a notification. Each check has its own notification, defined using a template.
All templates are made of 3 fields: Title, Package (or News item), and Separator. Title will be the title of the notification. Package (News item) is the text corresponding to one package/news item. It will be repeated for each package/news item, separated using Separator, to make the body of the notification.
Each field can have none, one or more variables. They are not the same for all templates, but basically you have the package name, its old/current version number, the new version number, and (if applicable, i.e. not for AUR packages) the download, installed and net (post-installation difference) sizes. (For a bit more information, check out kalu’s man page.)
Notifications for upgrades & AUR upgrades can also feature a button to start the
corresponding upgrade. This button can be used to simply trigger a process of
your choosing, e.g. you could have it start pacman with something like
sudo pacman -Syu
While for AUR upgrades there is no more option, for upgrades you can decide to use kalu’s own system updater, which does exactly the same, only in a GTK GUI.
Checking is good. Upgrading too.
When a notification is shown, it will feature an action button. This button can
be used to simply trigger a process of your choosing, e.g. you could have it
start pacman with something like
urxvt -e sudo pacman -Syu
However, kalu comes with an integrated system upgrader, which does exactly the same, only in a GTK GUI. Before being able to synchronize your databases (and possibly upgrade the system) the updater needs root privileges, obviously.
The way it works is: kalu itself only contains the GUI, and the part that
does interact with libalpm (to actually upgrade your system) is in a secondary
kalu-dbus). Only this binary will require/use root privileges, and
it will rely on PolicyKit to ensure you are authorized before doing anything.
Obviously this requires you to have PolicyKit installed, but also (assuming
default configuration) a PolicyKit agent (e.g.
polkit-gnome), which is the one
in charge of asking for your/root password and making sure you don’t just press
random keys and whatnot.
You can also define one or more processes to be run after completing a system upgrade (to start e.g. localepurge and/or pkgclip), and kalu will start them after each successful sysupgrade (and an optional confirmation, which for multiple processes will feature the full list so you can specify which (if any) to start).
Note that if you’re not interested in this, you can remove it by specifying
--disable-updater on the
configure command line.
Perform sysupgrade without enterring a password?
Thanks to tips from moonman, kalu now comes with a polkit rule that will allow
any user in the group
kalu to perform a sysupgrade (through kalu, obviously)
without the need for authentication (e.g. being prompted for one’s password).
So if you don’t want to have to enter your password before doing a system
upgrade, simply add yourself to the group
kalu and that’s it.
Note that the group’s name can actually be set on configure time, and it’s also
possible to simply copy
/etc/polkit-1/rules.d and tweak it to your liking.
Preview conflict resolution
Every once in a while, kalu will not be able to tell you what upgrades are available. This isn’t due to a bug, or because there’s something wrong anywhere, it’s simply because there is (at least) one conflict.
A conflict often isn’t a big deal, and handling it is quite simple, but it requires your intervention, and that’s why kalu can’t list the upgrades: because you need to decide whether or not to replace one package with another, for example.
In such cases, it’s not possible to know what packages are part of the pending upgade (even those unrelated to the conflict) unless manually looking for them, or starting the upgrade. Not really the best, and that’s why kalu offers to run a “simulation” of the system upgrade.
System upgrade simulation
When there’s a conflict – preventing kalu to compile the list of packages for which upgrades are available – a button will be featured on the notification: “Run simulation”
A simulation is simply running the first step (i.e. compiling the list of packages in the sysupgrade) of kalu’s updater on a temporary copy of your (synchronized) databases, in order to see what the conflict(s) is (are).
You will be presented with the usual GUI of kalu’s updater, and after answering the questions to resolve (or not) the conflicts, you’ll be able to see the full list of available upgrades.
You can try again with different answers, and see how that affects the resulting package list for the upgrade.
See this post for a little more about this feature and how it works.
Download packages only (w/out needing to sync dbs)
Another interresting use of the simulation is the ability to “pre-download” packages.
From the simulation window you can click a button “Download packages” and, after the usual polkit password prompt (and a final confirmation) downloading of packages will occur.
It uses the temporary databases from the simulation (i.e. your system databases
are not touched/synchronized) and simply download packages into pacman’s cache.
This is about the same as doing a
pacman -Syuw but, again, using a temporary
copy of your databases so your databases aren’t synced, for the same reason as
This can allow you to “pre-download” packages ahead of time, but leaving the actual sysupgrade to later, maybe when you have more time but less bandwidth (noting that some remains required, to sync your databases).
You’ll also find a button “Abort” on the left, so you abort the download process at any time. (Note that this can also be done during an actual sysupgrade.)
FIFO commands, or how to use keyboard shortcuts…
Since v2.4.0 kalu will create a FIFO named
kalu_fifo_XXXX (where XXXX is
kalu’s process ID) under your runtime directory (i.e.
it is possible to send kalu “commands” simply by writing to this FIFO. Commands
are simple text strings, followed by a new-line character (\n).
This can be used e.g. to pause kalu, or have it run its checks either from a terminal, a script, or even via keyboard shortcuts, instead of having to go click on its systray icon/menu.
See this post or the Help/man page to know more about this feature and what you can do with it.
kalu as a CLI application
While kalu is originally a GUI application, it can also be used from the command
line. More than that, it can also be compiled as a CLI-only application, using
When used with either
will run the checks as usual, but the output will be sent to standard output
instead of inside a notification.
Note that kalu doesn’t perform GTK initialization when ran from command line, so
it can be used in script, from tty or in ssh fine. However, unless it was
--disable-gui it still has dependencies/requires GTK+3 to be
kalu supports internationalization, so all it needs to speak your language is a translation. In addition to English obviously, as of 1.4.0 kalu can also speak French, as of 4.1.0 it can also speaks Norwegian Bokmål! and as of 4.2.0 it can speak Spanish as well.
And if you want to help & translate it, please refer to this post for instructions on how do to it. And don’t hesitate to contact me if you have questions.
Tweak kalu’s icons to your liking
kalu uses 4 versions of its icon in the systray, based on its current state. The regular (blue) icon indicates that upgrades were found during the last checks, the gray version indicates that nothing was found; Both versions exists with a pause symbol on top, when kalu is paused.
kalu will now try and load all icons from the current theme, thus allowing you
to override any (and all) of them as you wish. The main icon is
kalu-paused, the gray versions are
So to e.g. use a different gray icon, one could simply put a file
kalu-gray.png in folder
Of course, kalu will still create the gray and/or paused versions as needed, based on loaded icons.
Note that the regular icon is also used elsewhere in kalu, e.g. in buttons or menus.
KDE’s StatusNotifierItem interface
So for those who don’t have a systray anymore, or simply prefer to use KDE’s own notifier interface instead, I should probably mention that it is possible!
A configure option
--enable-status-notifier is required to enable it, adding a
new dependency on statusnotifier, a small library to use KDE’s StatusNotifier
interface easily via GObject.
Then build & install the package as usual, and kalu shall try & register a StatusNotifierItem automatically, only using the systray as a fallback in case that failed (e.g. you don’t have a Watcher running, etc).