kalu − Keeping Arch Linux Up−to−date
kalu [ OPTION ...]
−a, −−auto−checks
Run automatic checks (no GUI, see NOTES below)
−d, −−debug
Enable debug mode. Debugging messages will then be sent to kalu’s stdout, prefixed with a timestamp.
Specify twice to include messages from ALPM ; three times to include debugging messages from ALPM.
−h, −−help
Show a little help text and exit
−K, −−keep−tmp−dbpath
Keep temporary dbpath upon exit, else kalu removes the directory (and all its content). Keeping it around might be useful to e.g. re-use it later, via −−tmp−dbpath option.
−m, −−manual−checks
Run manual checks (no GUI, see NOTES below)
−T, −−tmp−dbpath PATH
Use PATH as temporary dbpath. If not specified, a temporary directory $TMPDIR/kalu−XXXXXX will be created, where XXXXXX are characters chosen at random.
This might be useful to re-use an existing directory, especially alongside −−keep−tmp−dbpath
−V, −−version
Show version information and exit
kalu is (yet another) upgrade notifier for Arch Linux. Once started, it will add an icon into your systray, and regularly check if any upgrade is available, and if so show a notification to inform you about it.
You can know whether anything was found during kalu’s last check or not by its icon: if gray nothing was found. If blue, you can mouse over it to see (in the tooltip) what was found.
If the icon happens to blink from gray to blue, it means kalu is currently busy.
See ICONS below for more about how icons are created in kalu.
kalu can also be paused, meaning automatic checks will not be ran anymore until automatic checks are resumed, either through manual action, or automatically when then "paused period" ends (see PREFERENCES below).
kalu can check
for a few things, each one resulting in a separate
notification (if something is found) :
* Upgrades
kalu will check for upgrades of any of the installed packages, similarly to what a ‘pacman −Syu‘ would do. To do so, kalu does not requires root privileges to do its checking. In order to determine whether or not upgrades are available, it uses temporary copies of your sync databases and synchronize those copies. (Those are also used when running simulations.)
That way not only can all this be done as user, but it avoids putting you in a situation where you’d risk messing up your system, as you might otherwise unknowingly end up basically doing a ‘pacman −Sy foobar‘ (which is pretty generally understood to be a bad idea).
(Because if your databases were synchronized and upgrades were available, yet you did not upgrade right away − e.g. because you didn’t see the notification or were busy on something − then your next −S operation would really be a −Sy even though you might not even realize it.)
The first time kalu needs temporary databases, it will create a temporary folder and set it up. This folder will then not be removed until kalu ends, thus allowing to re-use those temporary copies for further checks/simulations, reducing bandwidth usage and therefore speeding things a bit.
(Note kalu will actually remove the folder & re-create new temporary copies in a new folder if the DB path for ALPM (e.g. from pacman.conf) changed. Alse note that if for some reason you wanted kalu to recreate copies, you can simply remove the folder, $TMPDIR/kalu−XXXXXX or as specified via −−tmp−dbpath)
* Watched packages
kalu will check for upgrades of packages that aren’t currently installed. This is done by simply maintaining a list of packages (name & version) and checking it against the online repos (after synchronization).
When upgrades are available, you will be able to easily "mark them" − i.e. kalu can auto-update the list with the latest version number. You will of course be able to select which of the packages to update, if any.
If so, and a newer version is available, you will be notified. If you have foreign packages which you know are not in the AUR (and therefore checking for them is useless), you can put them on an ignore list, see PREFERENCES below.
As a special trick, it is possible to specify a package name in the form "repo/package" to have kalu specificaly check for that package in that repo.
For instance, if using testing as repo that comes first, you may want to keep an eye on a package, e.g. pacman, from the core repo. Using core/pacman as package name will allow that.
Note that in that case the name of the package − i.e. $PKG in templates − will remain in the form repo/package to indicate the restriction.
* AUR packages
kalu will compile the list of foreign packages on the system (i.e. not found in any repo, or what you’d have from running ‘pacman −Qm‘) and check to see if they are available in the AUR. If so, it will check whether the AUR version is more recent than the one installed.
You can of course specify a list of packages to ignore, so as not to check the AUR for packages you know won’t be found. kalu will also notify you of any packages not found in the AUR, to alert you that a package might have been renamed/removed.
* Watched AUR packages
Just as with "official" packages, you can maintain a list of non-installed packages that kalu should check the AUR for.
* Arch Linux News
kalu will check the news from the Arch Linux website (<http://www.archlinux.org>) and show a notification whenever something new has been posted.
The notification can only feature titles, but using the button "Show news" will show the complete news. Note that this is done through kalu’s own rendering (i.e. there is no HTML engine used) and as such the rendering might differ. For example, images are not supported.
Links are opened using the command-line specified in PREFERENCES , by default using xdg−open(1) to be opened them in your default browser.
In case your notification daemon doesn’t support action buttons on notifications, you can still easilly mark news read using the menu "Show unread Arch Linux News" from right-clickig on kalu’s systray icon.
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.
If the icon happens to blink from gray to blue, it means kalu is currently busy.
kalu tries to 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", the paused version "kalu-paused", the gray versions are "kalu-gray" and "kalu-gray-paused" respectively.
So to e.g. use a different gray icon, one could simply put a file kalu−gray.png in a folder such as ~/.local/share/icons/hicolor/32x32/apps or similar.
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.
On start, kalu will create a FIFO named kalu_fifo_XXXX (where XXXX is kalu’s process ID ) under the user’s runtime directory ($XDG_RUNTIME_DIR).
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).
Note that it is possible for some commands to, at times, be no-op. For example, sending a command to start a sysupgrade while kalu is running its check will do nothing.
Supported
commands are:
run-checks (or manual-checks)
Run the manual checks, same as using menu "Check for Upgrades..."
auto-checks
Run the automatic checks. This is usually only triggered by kalu and cannot otherwise be triggered manually (except using the −−auto−checks command line argument).
show-last-notifs
Re-show last notifications.
toggle-pause
Pause/resume automatic checks.
sysupgrade
Start a system upgrade. Like using menu "System upgrade..." the actual action (e.g. run kalu’s updater, or start a command line) depends on your preferences.
run-simulation
Start an upgrade simulation. This is mostly useful in case of conflicts, to preview what causes it & how to resolve it prior to any upgrade/database synchronisation.
See UPGRADE SIMULATION below for more.
show-unread-news
Show unread Arch Linux news
show-recent-news
Show recent Arch Linux news
popup-menu
Pops up the systray menu at current mouse pointer position.
Every setting/data kalu stores will be done in folder $XDG_CONFIG_HOME/kalu, all files following a simple format of Key = Value
The following
files are used :
− kalu.conf : your preferences
This files uses [sections], as common in conf/INI files. The main section [options] defines the preferences, other sections define the different templates : [template−upgrades], [template−watched], [template−aur], [template−watched−aur] and [template−news]
Each of those support the same keys: TitleSce, Title, PackageSce, Package, SepSce and Sep See PREFERENCES below for more.
− watched.conf :
the list of watched packages
− watched−aur.conf : the list of watched
AUR packages
A simple list of watched ( AUR ) packages, where keys are the packages names, and values the version numbers.
− news.conf : information about which news you have already read
The news has a key Last containing the title of the last read news. Every news from this one on is considered read. When there are a mix of read & unread news before, the key Read can be specified as many times as needed to indicate read news (using the news title as value as well).
For example:
Last=News 5
Read=News 1
Read=News 3
Will have "News 2" and "News 4" unread.
Preferences are presented under a few tabs. Most of those represent a type of check/notification supported by kalu, and as such include a template definition allowing you to tweak the content of said notifications.
All templates are made of 3 fields: Title, Package (or News item), and Separator. Title will be the title of the notification. Package is the text corresponding to one package/news item. It will be repeated for each package/news item, separated using Sep, to make the body of the notification.
Each field can make use of none, one or more variables. They are not the same for all templates, so they’ll be described in each of them below.
In addition to \n for a new line, you can use some markup tags, but only in the body of the notification (i.e. in the fields Package/News item and Separator but not in Title), such as <b> ... </b> for bold, <i> ... </i> for italic or <u> ... </u> for underline.
Note that though support is recommended, whether or not those will actually be applied on the notifications depends on your notification daemon.
For each of the fields, a "source" to use must be defined. Title fields (TitleSce option) can either use DEFAULT or CUSTOM as source. The former will use an internal default value, the later use whatever is specified as option Title.
For other fields (PackageSce and SepSce options) it can be one of DEFAULT , FALLBACK , CUSTOM or NONE . All those fields have a default and/or a fallback, i.e. not always both.
The fallback source means that the value of the same field from another template will be used. Template fallbacks are recursive and work as such:
− Upgrades : No fall back − Watched : falls back to Upgrades − AUR: falls back to Upgrades − AUR not found : falls back to Upgrades − Watched AUR : falls back to AUR − News : falls back to Upgrades
When a template has a field using FALLBACK as source, the value from its fall back template will be used (which can also come from its own fallback template).
Note that custom values are required. When a field is optional, a source NONE will be available. Obviously, titles are required.
Use NONE as source for Package will result in a notification with only a title (no body/text).
Preferences are presented under the following tabs :
General
Configuration file (pacman.conf)
PacmanConf = /path/to/file
This is the configuration file used to initialize the Arch Linux Package Management ( ALPM ) library (whose most famous front end is no other than pacman).
Icon used on
notifications
NotificationIcon = KALU|NONE|/path/to/file
Specify the icon to be used on notifications. Can be none, kalu’s icon or selecting a file to load it from.
If loading the icon fails, kalu will silently fall back to using it own icon.
Size of the icon used on
notifications
NotificationIconSize = size
Specify the size of the icon used on notifications. The size must be a number between 8 and 48 (both included).
Notifications expire after
(seconds)
Timeout = SECONDS
The delay after which the notification should expire/be automatically closed by the daemon. The left-most value will use the default (from the daemon), while the right-most value will set notifications to never expires, i.e. they will stay opened until either you manually close them, or for notifications with an action button until kalu is closed.
Check for upgrades every
(minutes)
Interval = MINUTES
How often must kalu run its automatic check. Select from the list, or type in what you want.
You can disable auto-checks by specifying 0. Note that in this case, and if you still set a skip period (see below), then auto-checks will still ran at the end of the skip period (or whenever manually unpausing).
Do not check between .. and
..
SkipPeriod = HH:MM−HH:MM
This is e.g. in case you keep your computer on 24/7, yet go to sleep at some point. It would then make sense that you not want kalu to do its checks while you’re sleeping.
When specifying a "paused period" here, kalu will automatically pause its automatic checks at the beginning time, and resume them at end time.
You can obviously "overwrite" the period, e.g. by manually resuming automatic checks during the paused period.
During an automatic check,
check for ..
AutoChecks = [ NEWS ] [
UPGRADES ] [ WATCHED ] [
AUR ] [ WATCHED_AUR ]
Select one or more checks that will be performed during every automatic check, i.e. run on start or at the interval specified above.
During a manual check, check
for ..
ManualChecks = [ NEWS ] [
UPGRADES ] [ WATCHED ] [
AUR ] [ WATCHED_AUR ]
Select one or more checks that will be performed when you start a manual check, i.e. using menu "Check for Upgrades"
News
Command line to open links
CmdLineLink = cmdline
The command line to be executed when a link (on news) is clicked. Use variable $URL as placeholder for the full URL to be opened.
Notification template
Title
$NB : number of news items
News item
$NEWS : the title of the news
Separator
No variables available.
Upgrades
Check for pacman/kalu conflict
CheckPacmanConflict = 0|1
When showing the notification, kalu will check if there’s an upgrade of pacman likely to prevent the system upgrade due to kalu’s dependency to the current version of pacman (i.e. due to API changes in libalpm).
If so, a button will be featured on the notification, to show a little message about the reason for such a conflict, and how to perform the system upgrade.
Show a button "Upgrade
system" on notifications (and on kalu’s menu)
UpgradeAction = KALU|CMDLINE|NONE
Whether or not notifications should feature a button "Upgrade system" and kalu’s menu (right-click on its systray icon) feature an item "System upgrade"
When clicking the button
(see UpgradeAction above)
Clicking the button can either start kalu’s own updater (see PREFERENCES below), or simply run the program of your choice.
Command-line
CmdLine = cmdline
The command line to start when pressing the button "Upgrade system" from the notification. See SYSTEM UPGRADE below.
After completing a system
upgrade, ask whether to start the following
PostSysUpgrade = cmdline
When using kalu’s updater, you can define one or more processes to be ran after a system upgrade was completed. Specify their command-line in the list, and they’ll be started after a successful system upgrade.
You can use $PACKAGES in the command line, which will be replaced by the list of all packages involved in the sysupgrade (i.e. packages upgraded, as well as those added or removed, for instance when a package is replaced by another one).
You can also use $PACFILES in the command line, which will be replaced by the list of all .pacnew files created during the sysupgrade.
The full /path/to/filename will be followed by an extra parameter consisting of the package name & old version.
For example, if
/etc/pacman.conf.pacnew was installed during the
upgrade, while upgrading from 4.1.2−3 to 4.2.0−1
then two parameters will be specified:
/etc/pacman.conf.pacnew pacman−4.1.2−3
The idea here is that this can allow you to e.g. go look in pacman’s cache for the old version of the file, and perform a 3−way merge.
Ask confirmation before
starting anything
ConfirmPostSysUpgrade = 0|1
If enabled, a confirmation will be asked before any process is started after the sysupgrade. In case you specify more than one, the full list will be featured and you will be able to determine which (if any) to start each time.
Notification template
Title
$NB : the number of
packages
$DL : the total download size
$INS : the total installed size
$NET : the total net (post-install difference) size
Package
$PKG : the name of the
package
$DESC : the description of the package
$OLD : the version number of the currently installed
version
$NET : the version number of the version available in
the repo
$DL : the download size
$INS : the installed size
$NET : the net (post-install difference) size
Separator
No variables available.
Watched
Manage watched packages
Does the same as the menu by the same name, that is open the window to manage (add, edit, remove) the list of watched packages. This list is independent from the preferences, its data are saved in a different file, and saving the list will not have an effect on preferences, and vice versa.
Notification template
Title
$NB : the number of
packages
$DL : the total download size
$INS : the total installed size
$NET : the total net (post-install difference) size
Package
$PKG : the name of the
package
$DESC : the description of the package
$OLD : the version number from the list of watched
packages
$NET : the version number of the version available in
the repo
$DL : the download size
$INS : the installed size
$NET : the net (post-install difference) size
Separator
No variables available.
AUR
Show a button "Update AUR packages"
on notifications
If enabled, notifications for AUR packages will feature a button "Update AUR packages" which will start the specified command-line. If not, no button will be featured.
When clicking the button,
run the following
CmdLineAur = cmdline
The command line to start when pressing the button "Update AUR packages" from the notification. See SYSTEM UPGRADE below.
You can use $PACKAGES in the command line, which will be replaced by the list of all packages for which an upgrade is available in the AUR.
Do not check the
AUR for the following packages
AurIgnore = PACKAGE ...
By default kalu determines the list of all foreign packages (i.e. not found in any repo, or what you’d have from running ‘pacman −Qm‘) and check to see if they are available in the AUR.
If you have packages which you know are not there (or simply for which you do not want to be notified), simply add their names to this list.
Notification template
Title
$NB : the number of packages
Package
$PKG : the name of the
package
$DESC : the description of the package
$OLD : the version number of the currently installed
version
$NET : the version number of the version available in
the AUR
Separator
No variables available.
When packages are not found:
Title
$NB : the number of packages
Package
$PKG : the name of the
package
$OLD : the version number of the currently installed
version
Separator
No variables available.
Watched
AUR
Manage watched AUR packages
Does the same as the menu by the same name, that is open the window to manage (add, edit, remove) the list of watched AUR packages. This list is independent from the preferences, its data are saved in a different file, and saving the list will not have an effect on preferences, and vice versa.
Notification template
Title
$NB : the number of packages
Package
$PKG : the name of the
package
$DESC : the description of the package
$OLD : the version number from the list of watched
AUR
packages
$NET : the version number of the version available in
the AUR
Separator
No variables available.
Misc
Show if databases can be synchronized in tooltip
SyncDbsInTooltip = 0|1
An indication of how many databases can by synchronized (i.e. are not up-to-date) will be featured on the tooltip, regardless of whether upgrades are available or not.
When (double/middle)
clicking the systray icon
OnSglClick = ACTION
OnDblClick = ACTION
OnMdlClick = ACTION
OnSglClickPaused = ACTION
OnDblClickPaused = ACTION
OnMdlClickPaused = ACTION
Defines the action to be done when you single/double/middle click on kalu’s systray icon.
You can define actions to be taken when kalu is active (i.e. not paused), and a different set of actions when it is paused.
KDE
users: See KDE STATUSNOTIFIERITEM
SUPPORT section below for more information.
* Same as when active/not paused (
SAME_AS_ACTIVE )
[Only when kalu is paused] Do the same as when kalu is active (defined above).
* Do nothing ( NOTHING )
Does exactly that
* Check for Upgrades ( CHECK )
Start a manual check
* System Upgrade ( SYSUPGRADE )
Start a system upgrade. This will do the same as using menu "System Upgrade" or the button "Upgrade system" on notification; i.e. the specified action done depends on your settings under Upgrades
Note that if no button "Upgrade system" is shown on notification, this option will have the same effect as Do nothing
* Upgrade Simulation ( SIMULATION )
Start an upgrade simulation. This is mostly useful in case of conflicts, to preview what causes it & how to resolve it prior to any upgrade/database synchronisation.
See UPGRADE SIMULATION below for more.
* Hide/show opened windows
(except kalu’s updater) (
TOGGLE_WINDOWS
)
Will hide all opened windows (except for kalu’s updater). If at least one window is hidden, an indication will be featured on the tooltip (" +" next to "kalu") and triggering the action again will then show all hidden windows.
* Re-show last notifications... ( LAST_NOTIFS )
Will re-show all notifications resulting from the last time checks were ran (automatic or manual).
* Toggle pause/resume automatic checks ( TOGGLE_PAUSE )
Will toggle kalu’s paused state, pausing or resuming automatic checks.
* Exit kalu ( EXIT )
Will exit kalu.
A few configuration options do not have GUI (i.e. cannot be set from the Preferences window), but can be set manually. They will, of course, be preserved when saving preferences.
The following
tweaks are supported, and can be used in kalu.conf
(under the [options] section) :
UseIP = 4|6
This will force kalu to use IPv4 or IPv6. This only applies for connections done via kalu, i.e. news & AUR, but doesn’t apply to ALPM.
This could be usefull e.g. if you’re having issue with the AUR timing out when resolving using IPv6.
AutoNotifs = 0
This can be used to disable showing notifications for automatic checks. They can still be shown on demand, using "re-show last notifications".
Notifications will still be shown for manual checks.
NotifButtons = 0
This can be used to not add any buttons to notifications. Can be useful if your notification daemon decides to show notifications with action-buttons as non-expiring windows instead (e.g. notify-osd).
ColorUnimportant =
COLOR
ColorInfo = COLOR
ColorWarning = COLOR
ColorError = COLOR
Allows you to define the colors used in kalu’s system upgrade GUI. Those are used to color log messages of another level than NORMAL. ColorInfo is also used on columns for download & install sizes, to indicate packages that have been downloaded/installed, as well as for completion message. ColorError is also used similarly in case of e.g. download error for a package, or message of system upgrade failure.
The value COLOR will be parsed as a GdkRGBA color, and can therefore be either one of:
− A standard name (Taken from the X11 rgb.txt file)
− A
hexadecimal value in the form ".rgb",
".rrggbb", ".rrrgggbbb" or
".rrrrggggbbbb"
− A
RGB color in the form "rgb(r,g,b)"
(In this case the color will have full
opacity)
− A RGBA color in the form "rgba(r,g,b,a)"
Where "r", "g", "b" and "a" are respectively the red, green, blue and alpha color values. In the last two cases, r g and b are either integers in the range 0 to 255 or precentage values in the range 0% to 100%, and a is a floating point value in the range 0 to 1.
AutoShowLog = 1
This can be used so that the log in kalu’s updater is visible by default; Else the pane is only opened when an important message is added (error, warning or info) or upon manual trigger.
Starting with Plasma Next, KDE doesn’t support the XEmbed systray anymore[1] in favor of their own Status Notifier Specification[2].
KDE users can enable StatusNotifierItem support in kalu by specifying the configure option −−enable−status−notifier which also adds an extra dependency on library statusnotifier[3], for easy support with GObject ( GTK+ ) application.
As a result, kalu will then use this new interface for its icon (only falling back to the systray if it isn’t supported, e.g. no StatusNotifierWatcher is running/registered on the system).
Using KDE ’s StatusNotifierItem interface, kalu doesn’t show/handle the icon, the application acting as StatusNotifierHost does. As a result, kalu doesn’t react to whatever click happen on the icon, but predefined methods being called.
Specifically, kalu will respond to method Activate, where the action assigned to click will be used, and SecondaryActivate, where the action on middle click will be used. Those are likely to be corresponding to the same click events, though it’s actually up to the StatusNotifierHost (i.e. the application showing and handling the icons).
Additionally, kalu’s menu will obviously be shown on method ContextMenu, which is likely to be triggered on right-click.
Also note that the tooltip will be different in its look (since handled by the StatusNotifierHost and not kalu) but also its content, since kalu doesn’t know when it is shown (so it can only include the date/time of last check, not how long ago it was).
References
[1]
http://blog.martin−graesslin.com/blog/2014/03/system−tray−in−plasma−next/
[2] http://www.notmart.org/misc/statusnotifieritem/
[3] https://jjacky.com/statusnotifier/
An item "System Upgrade" on kalu’s menu, as well as a button "Upgrade system" on notifications for available upgrades, can be featured. This button can start a process of your choice, or kalu’s own system upgrader. (See PREFERENCES above.)
Running a
command line (System/AUR upgrade)
You can define a command line for kalu to execute. When
running a command line, whether to perform a system upgrade
or an AUR update, kalu will wait until the
process’ execution is over, meanwhile remaining in
busy state (so no checks can be started while an upgrade is
in progress, as that would be useless, if not slowing things
down).
Once the process has ended, kalu will then automatically run its automatic checks again, to refresh its state. Note that if you started both a system upgrade command line and an AUR update command line at the same time, kalu will remain in busy state until both are done, and only then runs its checks.
Usually, you’ll likely start a terminal emulator within which ‘pacman‘ or an AUR helper will do its work; Once done and the terminal closes, kalu will rerun its checks and everything is done as expected.
Using
kalu’s system updater
You can also use kalu’s own system updater, which will
first synchronize your databases, then upgrade all packages
that are out of date. In other words, it does what a
‘pacman −Syu‘ would do, only in a
GTK GUI.
In order to synchronize databases and upgrades packages, root privileges are obviously required. The way this is handled is as follows: kalu itself only contains the GUI, and therefore can work running under your (user) account.
The part that does interact with libalpm (to actually synchronize databases and upgrade packages) is in a secondary library (kalu-dbus), that is the only one to require root privileges.
This binary will be executed automatically, with root privileges, through DBus when needed, and PolicyKit will be used to ensure that you are authorized to upgrade the system.
By default you probably will be prompted for your password in order to be able to run the system upgrade. Should you want to bypass that, a rule has been installed which will allow members of the group kalu to perform a sysupgrade without extra authentication.
All you need to do to use this feature is add yourself to the group (and re-login).
If you’d rather use another group (e.g. wheel) you can copy the file /usr/share/polkit−1/rules.d/30−kalu.rules to /etc/polkit−1/rules.d and modify it as you wish.
Note that the group used by default can actually be set at compile time, through a configure option.
When upgrading your system with kalu’s updater, your log file (e.g. pacman.log, as defined in pacman.conf) will be updated. kalu adds an entry for each database synchronized, one when starting the upgrade, one after the upgrade was completed, and one after each package operation (installed, upgraded, removed).
Note that a button "Abort" is available during the process. After a confirmation, this will basically do the same as would hitting ^C from your terminal when running pacman.
Which is to say, doing so when e.g. download packages is fine, the operation should be cleanly aborted, and downloads can be resumed later on. However, you probably don’t want to do that while the actual system upgrade is being performed, for obvious reasons.
Every once in a while, kalu might not be able to list the available upgrades, notifying you instead that there is a conflict between some packages. If you then want to know more about this conflict, and still want to know what upgrades are available regardless of the conflict, the extra button "Run simulation" might be of interest to you.
You can also start a simulation at any time from kalu’s menu, FIFO or via its systray icon. If there’s no conflict, the simulation will simply consist of listing the packages to be upgraded, if any.
A simulation is simply running the first step (i.e. compiling packages list) of kalu’s updater on a temporary copy of the (synchronized) databases, in order to see what the conflicts 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 then be able to see the full list of available upgrades.
Of course it stops there, there’s no upgrading. The point of this is simply to see how to resolve the conflict, and see what the upgrades are, as there might be new dependencies to install, old packages to remove/replace, and of course a few other/unrelated packages with available upgrades.
You can easily start over by pressing "Rerun simulation" to have all the questions asked again, so you can try different scenario and see which one works (best) for you.
Once you’re done, press "Close" and all temporary files will be removed. That’s it, your system remains unchanged. If you now want to actually do the upgrade, use "Upgrade system" as usual.
Note that you don’t need to use kalu’s updater for this to work. Even if e.g. you have set things to run ‘pacman −Syu‘ in a new terminal when pressing "Upgrade system", or not have the button at all, the "Run simulation" button/feature will be available.
The only requirement is that kalu’s updater was compiled in, of course, i.e. it won’t work if you compiled kalu using ‘−−disable−updater‘ (or ‘−−disable−gui‘).
Download
packages only
One more thing you can use the simulation for, is to only
download packages for the next sysupgrade (without actually
performing said sysupgrade).
Once a simulation has completed, a button "Download packages" will be available (if there are any packages to upgrade/download). After pressing this button you will need to be authenticated, and after a final confirmation packages will be downloaded into pacman’s cache.
In effect, this is similar to running ‘pacman −Syuw‘ but, again, using a temporary copy of your databases so your databases aren’t synced, for the same reasons previously mentionned.
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).
Command-line options −−auto−checks and −−manual−checks both work without any need for GUI. This means any and all output will be show on stdout/stderr, and there is no need for a DISPLAY to be available.
In other words, you can run kalu using those options from a tty or through SSH, and it will work fine. You can also use kalu in a script that way.
Note that GTK+ and other dependencies are obviously still required, although there is a configure option available to disable all GUI completely during compilation, in order to produce a CLI version of kalu.
They’re probably crawling somewhere in there... if you happen to catch one, (or more) report it and I’ll do my best to squash it.
You can find the latest source code of kalu as well as report bugs and/or suggest features on its GitHub repository, available at <https://github.com/jjk−jacky/kalu>
Olivier Brunel
<jjk AT jjacky DOT com>
Dave Gamble
Pacman Development Team <pacman−dev
AT archlinux DOT org>
Icon by Painless Rob (<https://bbs.archlinux.org/viewtopic.php?id=130839>)