Add the --news option, which simply allows you to view Arch Linux news.

Est il possible de mettre à jour mes app Rust cargo aussi avec ?

Environment

• Distribution: Arch Linux
• Windows Manager: Bspwm + Polybar
• Arch-Update version: arch-update 2.3.0

Description of the bug

Arch-News do not appear during updates

When a flatpak program uses an outdated runtime, the flatpak update command returns the following warning:

What returns a possible error in arch-update:

This is a problem (for me at least), because I use a waybar module that uses arch-update feedback to show the number of available updates, in this case, even without updates for the flatpak, I receive a false alert for this, due to printed lines that do not correspond to packages.

The recently added features of handling old cached packages and pending kernel update are missing from the help message, both in the script and in the README.

Hello,

I read carefully the readme, but I don't understand exactly how you integrate the .desktop file. I tried to add the app to the cinnamon panel from the menu into the launcher applet. It works except that the icon does not change when there are updates.
Can you please detail the steps you used on your DE to integrate a dynamic icon?

Thanks in advance.

Description

In line with the --gen-config and --show-config options, it would be great to have a arch-update --edit-config option to edit the arch-update.conf configuration file (if it exists). It could default to using $EDITOR and fallback to nano if it is not set.

Motivation and context

This would ease the "manipulation" of the config file as this command will allow to edit the config without having to enter (or even know) the full path. More user friendliness is generally good 😄

Depending on how hard it is to handle, having the systray applet showing the number of pending updates (such as what the Arch Updates Indicator Gnome extension is doing) would be a nice plus!

Retrieving this information from the main script and adding it to the current_state file (for instance) would be trivial. However, the integration of that information within the systray applet itself needs to be studied.

Currently, the possibility to not show version changes during the listing of pending updates is done by editing the script itself.
While this work, it's not so elegant and, more importantly, makes the change not persistent accros update (as the script gets overwritten during install).

Also, with the incoming colorized output feature, it would be great to have an option to get a non-colored output. But providing that option via a flag/argument isn't ideal (as it would imply to modify the .desktop file manually to make use of that option) and modifying the script manually like it is currently done for the "not show version changes" option presents the same issues as above.

The solution would be to have an optional configuration file (under ${XDG_CONFIG_HOME:-$HOME/.config}/arch-update/arch-update.conf for instance) to set those options easily and permanently (by having the script looking for the presence of the file and adapt its behavior depending on its content).

Could be something like:

$ cat ~/.config/arch-update/arch-update.conf
NoColor # Do not colorize output
NoVersion # Do not show version changes when listing pending updates

More options could be added later if needed.

Environment

• Distribution: Arch Linux
• Arch-Update version: 2.1.0

Arch-Update configuration

No configuration

Description of the bug

Currently, there is nothing preventing to start multiple instance of the systray applet at the same time. This is unconventional, can be confusing to users and could eventually cause performance issues (and someone could theoretically start an infinity of systray applet's instances).

Screenshots / Logs

(Notice that there's 2 Arch-Update systray applet started at the same time).

Additional context

Each systray applet instances are independent from each other, meaning that clicking on one systray applet will only start one instance of Arch-Update, and exiting one systray applet will only close this specific one. So even with multiple systray applet started at the same time, this should not impact the "core" functionalities of Arch-Update.
As said above, this is still unconventional/unexpected though 😸

Add run0 support as a fallback option if neither sudo nor doas are found.

Description

It'd be super nice for other applications to have the ability to query the pending updates at any time (after updates were checked). When --check is run, arch-update could potentially write the update count to a cache file/socket in /tmp or XDG_RUNTIME_DIR. Then, external applications could simply read the last check to retrieve the information they need.

For my use case, I just need the update count, but it might be more useful to cache the full update status and then applications can parse the file as needed.

Motivation and context

It's understandable if this is out of scope for arch-update, but this feature would be extremely convenient - currently, if I want to get the number of pending updates into some other application, I have to have two very similar systemd timers running. Implementing this cache feature would allow me to use arch-update as the only update checking timer on my system.

For context, I've written my own custom desktop widgets with AGS and I need some way to read the number of pending updates to display in my dashboard UI.

As of now, Arch news are printed at each run of the main script. As news are not posted so often and as people may have other ways to check news (Archweb, RSS feed, Mailing List, ...), constantly printing them is irrelevant and useless most of the time.

It would be great to only print Arch news if there's a new one compared to the last run of the script, by using the same logic used by the --check function with state files.

The recently suggested --news option (in #109) would allow people to check Arch news whenever they want regardless of if there's a new one or not.

With that new default behavior the NoNews option in arch-update.conf (suggested in #85 and introduced in #89) will be removed and replaced by the AlwaysShowNews option that will allow to put back the current default behavior (having news shown everytime, regardless of if there's a new one or not).

This has been requested quite a few times as it allows an easy integration within the system regardless of the panel/bar used by any DE/WM (as long as it has systray support, obviously).

It is also way more elegant when it comes to dynamic icon changes (e.g. when there are pending available updates).
Indeed, the way this "dynamic icon changes" has been initially implemented on Arch-Update's side is hacky and do not even work properly for most people (see this comment).

I'm still in favor of keeping the .desktop file anyway (for people that don't have/want a systray) but only using one single "regular/non-changing" icon (as most other applications do).

When it comes to the systray applet specs, here's what I could think of so far:

• Ideally written in a high-level, intelligible and widely used programing language (for instance Python or Rust).
• Can be launched by a systemd-service (or by running a simple command, such as arch-update --applet or arch-update-applet, that one can put in their autostart apps or WM config) to have it running at startup.
• For icons:
  • After a second thought, I'm not sure how relevant some icons are (e.g. the 'checking' and 'installing' icons) and how hard handling them in such an applet would be. So, if anything, we can eventually drop them and only have an "up to date" and an "update available" icons.
  • Depending on how hard it is to handle, having the applet showing the number of pending updates (such as what the Arch Updates Indicator Gnome extension is doing) would be a nice plus!

To be honest, I don't have a precise idea on how to develop such an applet for now. I'm gonna start digging into it as soon as I'll be able to but, obviously, any help would be greatly appreciated! 😄

Restarting services after they are upgraded is a good practice and is recommended to avoid having processes running with outdated libraries.
In some specific cases, not restarting services after they are upgraded can actually cause more or less severe issues (see the recent sshd case for instance).

It would be great if Arch-Update could check if any services need to be restarted after updating and offers to do so (if there are).
The checkservice script (included in the archlinux-contrib package) might be a good help :)

Description

Currently you can only read one news at a time. To allow people reading multiple news in a single arch-update, the question of "Which news do you wanna read" is re-asked until the user selects no news to read.
This is a questionable design that is not so optimized. It would be better if one could select multiple news to read at once (e.g. 1 3 4 to read news 1, 3 & 4).

Motivation and context

The overall motivation is to improve/optimize arch-update execution and output for users. After a second thought, the current behavior is at best unoptimized, at worst unexpected.

Currently the main script shows the 5 most recent Arch news by default.
It would be great to have an option allowing to modify that default number.

This is how I imagine it:

examples below with setting "10" as the default number of news to print

• To modify the default number of news to print, both with the -n/--news option and within the main script, one can set the NewsNum=10 option in arch-update.conf.
• With the -n/--news option, specifying the number of news to print as an argument will overwrite the default number for the current execution, like so: arch-update --news 10

Peut-on faire en sorte que dans le -c ou --check, les anciennes notifications soient supprimées avant d'envoyer la nouvelle ? Ou dans .conf/arch-update/arch-update, mettre une configuration possible avec un nom comme max-notifications pour paramétrer cela, et si la variable n'existe pas, garder le même comportement qu'auparavant.

An option arch-update --noconfirm that activates non-interactive mode for all update commands. This would make it possible to go for a coffee during the update, even if it's not good practice ;)

Environment

• Distribution: Arch-Linux
• Arch-Update version: 2.2.0

Arch-Update configuration

None

Description of the bug

Currently, the "list/read News" feature of Arch-Update makes multiple curl requests to https://archlinux.org in order to extract and parse the list of recent news.
Some of those requests can take a long time on poor network connections (or during network instabilities) and they currently have no default timeout set, meaning they can result in an unexpected "freeze" (it's not actually frozen, just taking a very long time) for some people having a poor network connection (or being subject to network instabilities).

Screenshots / Logs

See this video at 12:54

https://youtu.be/on7iI-0a_Hw?si=2Ug54ZI_-KcUBXB-&t=774

Additional context

Here's a proposal to handle such cases at the Arch-Update level (as best as it can... It cannot fix people's network connection unfortunately 😝):

• Print a message saying that Arch-Update is looking for recent Arch News (to avoid people thinking the script is just stuck in those situations)
• Optimize the requests made to https://archlinux.org within the "News" function of the script by merging them (the first and second curl requests can be merged into one to avoid making multiple requests unnecessarily).
• Add a default timeout to curl requests (--max-time option) to cut out/stop requests if they didn't finished after a reasonable time (30 sec?). In such cases, print a message to users like "Couldn't check for recent news in a reasonable time. Please, check https://archlinux.org/news/ for any recent news".

Hello, I use paru and I have an additional lines:
$ Paru -Sua
$ :: Looking for devel upgrades...
$ :: marked out of date:
$ :: orphans:
there is nothing to do
Image

I think it happens because the .desktop file needs a Categories field,
for example the .desktop file for Plasma System Settings looks like

[Desktop Entry]
Exec=systemsettings
Icon=preferences-system
Type=Application
SingleMainWindow=true
X-DocPath=systemsettings/index.html
StartupNotify=true
X-KDE-Shortcuts=Tools
OnlyShowIn=KDE;
Actions=kcm-lookandfeel;kcm-users;kcm-screenlocker;kcm-powerdevilprofilesconfig;kcm-kscreen;
Name=System Settings
X-DBUS-StartupType=Unique
X-DBUS-ServiceName=org.kde.systemsettings
Categories=Qt;KDE;Settings;
...

Adding detection of the flatpak package and if it is present, add flatpak update to update and flatpak remove --unused to clean.

Since release 1.10.0 of arch-update, it seems my ~/.config/systemd/user/arch-update.timer.d/override.conf which contains :

[Timer]
OnUnitActiveSec=1d

is ignored by arch-update (which runs every hour, like defined in ~/.config/systemd/user/timers.target.wants/arch-update.timer )

Archlinux with KDE,
is possible too have a smaller icon ?
Thanks

arch-update 2.0.1

when left clicking the icon in the system tray (hyprland / waybar) nothing happend

when right clicking the icon an small white line appears just at the base of the arch logo

(for now i have set up a keybind)

The WARNING & ERROR prefix messages are not included in the french translation.

They should respectively be translated to "AVERTISSEMENT" & "ERREUR".

Arch-Update should also look into XDG_DATA_DIRS and XDG_DATA_HOME when searching for translation files (.mo) and when looking for the example config to install with --gen-config option.

Currently, the documentation (README + Man page) explains how to manually edit the systemd timer file to modify the auto-check cycle.
This isn't ideal as the file isn't in the same location depending on if you installed arch-update via the AUR package or from source and, more importantly, the change will not be persistent accros updates as the file gets overwritten during install.

The documentation should point to using systemctl --user edit arch-update.timer instead (which solves both of the issues).

Hello,
In order to migrate from Manjaro Gnome to Archlinux Gnome, I am currently testing in VM an Endeavoursos and an archlinux installed with Archinstall and Architect in post-install. On both systems I use your Arch-update script for updates.
I notice a pending kernel update message on the Endaevoursos system which persists even after reboots. My kernel is indeed the latest (6.6.3-arch1-1). On Archlinux, this message does not appear.
Another small problem on both systems, the "enter" to Quit does not work and indicates at the bottom of the window "read only, the command is completed"
Thank you for your script and any help

Can i help you to have arch-update in french ?
Thanks.

This option would simply display the list of pending updates without the need to launch the actual main script's functions.

That would allow users to get the list of pending updates in a non-interactive way, e.g. scheduled in a cronjob to get the list of pending updates periodically from a remote machine or a headless server for instance (for those using arch-update cli on servers). This would kinda act like checkupdates, except it also includes AUR packages updates (if yay or paru is installed) and flatpak updates (if flatpak is installed).

Closes #122

Add some light coloring to the output (e.g. blue indicator for titles, red indicator for errors, etc...). Eventually base the color code on what's used in libmakepkg.

Would be great if the checkupdates colorized bug could be solved before the next release to a get consistently colorized output accros the whole script. Hopefully, we'll be able to find a fix for that soon-ish.

Salut, j'ai lancé la mise à jours et je me retrouve avec une erreur quand j'ai refusé la mise à jour des flatpaks.

Proceed with these changes to the user installation? [Y/n]: n
/usr/bin/arch-update : ligne 387 :  3154 Erreur de segmentation  (core dumped)flatpak update

Je donne juste l'information au cas où cela n'est pas volontaire

For debug/analyses purposes, it would be great to have a --show-config option that allows to display the current arch-update.conf configuration file (if it exists), so users can easily fill it in their bug report if needed.

Presuming two prefixes isn't enough, ideally we would check for all the places the user has chosen to have .desktop files

(Assign me, for another day)

The -l/--list option introduced in #123 is missing from the shell completions.

It should be put under the -c/--check option in completion files.
Option's description: "Display the list of pending updates"

Currently, Arch-Update primarily look for sudo, then fallback to doas if sudo isn't found and then fallback to run0 if doas isn't found as well.

However, people may have multiple elevation method installed. For instance, run0 comes with systemd >= 256 (so it should be present on all up-to-date Arch installations) and sudo a hard dependency of the base-devel metapkg (which is required to build AUR packages).
In the above example, people may want to be able to use run0 over sudo with Arch-Update. As such, it would be great to add an option in the configuration file to explicitely choose which elevation method to use (sudo, doas or run0).

It would be great to have a right click menu for the systray applet to gracefully quit/close it (instead of requiring people to either manually stop the systemd service or killing the process when needing to re-launch the systray from the terminal to get some logs for instance).

That would ideally imply introducing the translation code so we can have the menu entries in multiple languages.

While we're at it, I guess an entry to actually launch arch-update in the said menu wouldn't hurt :)

Bonjour, serait il possible d'empêcher le prompt des news ? Et si c'est possible d'utiliser Gum cli pour l'interface?

https://github.com/charmbracelet/gum
Ça rendrait le script plus beau.

Serait il possible s'il y a une update d'ouvrir automatiquement le terminal pour mettre le mot de passe directement sans tout ces Yes yes yes yes.

I would like to define some standards for this project's maintenance to ease and/or structure multiple part of it (such as development, contributions, bug reports, change logging,...) from now on.

Here's what I'd like to implement:

• Start using conventional commits
• Create a CONTRIBUTING.md file containing clear guidelines about contributing and reporting bugs
• Create templates for issues (and eventually pull requests as well?):
  - Bug report: Add a "Bug report:" prefix to the title, ask basic info (Distribution used, Arch-Update version, Arch-Update config file, etc...) & set the bug label
  - Feature request: Add a "Feature request:" prefix to the title & set the enhancement label
  - Other (General question/feedback): Nothing (keep it normal)
• Create a CHANGELOG.md file to keep a proper changelog (outside of the GitHub release). git-cliff might be useful to maintain it.
• Create a RELEASE.md file that sums up the required steps to create a new release

Description

I'd like to be able to disable the pacnew feature or maintain a denylist for pacnew files that I never want to handle via arch-update.

Motivation and context

I see 2 reasons:

• In my daily workflow it's rarely used but needs user interaction.
• Users might mess up their config.

As an example in below output, I see /etc/passwd which I certainly want to block from showing up.

Screenshots / Logs

==> No old or uninstalled cached package found

==> Pacnew Files:
/etc/passwd.pacnew
/etc/shells.pacnew
/etc/locale.gen.pacnew
/etc/lightdm/lightdm-gtk-greeter.conf.pacnew
/etc/mkinitcpio.conf.pacnew
/etc/ssh/sshd_config.pacnew
/etc/pacman.d/mirrorlist.pacnew
/etc/systemd/timesyncd.conf.pacnew
/etc/texmf/web2c/fmtutil.cnf.pacsave

-> Would you like to process these files now? [Y/n]

Description

This setting can be changed in the arch-update config file and when activated, after reading all updates' infos, the updates will be applied automaticly. For example 'pacman -Syu' will be run with the '--noconfirm' option

Motivation and context

I think this feature is usefull because when you leave your computer the updates will continue, even flatpaks, AURs, ...

Sorry for my English!

Environment

• Distribution: Arch Linux
• Arch-Update version: 2.2.0

Arch-Update configuration

None

Description of the bug

The -l/--list option is supposed to exit 7 if there's no pending update. However, because of the piped sed command, the exit status code is not honored.

Screenshots / Logs

arch-update --list --debug output:

+ case "${option}" in
+ . gettext.sh
++ test 'X\t' = 'X\t'
++ echo=echo
++ test -z ''
++ case "$0" in
+ export TEXTDOMAIN=Arch-Update
+ TEXTDOMAIN=Arch-Update
+ '[' -f /locale/fr/LC_MESSAGES/Arch-Update.mo ']'
+ '[' -f /home/antiz/.local/share/locale/fr/LC_MESSAGES/Arch-Update.mo ']'
+ '[' -f /locale/fr/LC_MESSAGES/Arch-Update.mo ']'
+ '[' -f /usr/local/share/locale/fr/LC_MESSAGES/Arch-Update.mo ']'
+ config_file=/home/antiz/.config/arch-update/arch-update.conf
+ grep -Eq '^[[:space:]]*NoColor[[:space:]]*$' /home/antiz/.config/arch-update/arch-update.conf
+ grep -Eq '^[[:space:]]*NoVersion[[:space:]]*$' /home/antiz/.config/arch-update/arch-update.conf
+ grep -Eq '^[[:space:]]*AlwaysShowNews[[:space:]]*$' /home/antiz/.config/arch-update/arch-update.conf
+ grep -Eq '^[[:space:]]*NewsNum[[:space:]]*=[[:space:]]*[1-9][0-9]*[[:space:]]*$' /home/antiz/.config/arch-update/arch-update.conf
+ news_num=5
+ grep -Eq '^[[:space:]]*KeepOldPackages[[:space:]]*=[[:space:]]*[0-9]+[[:space:]]*$' /home/antiz/.config/arch-update/arch-update.conf
+ old_packages_num=3
+ grep -Eq '^[[:space:]]*KeepUninstalledPackages[[:space:]]*=[[:space:]]*[0-9]+[[:space:]]*$' /home/antiz/.config/arch-update/arch-update.conf
+ uninstalled_packages_num=0
+ grep -Eq '^[[:space:]]*PrivilegeElevationCommand[[:space:]]*=[[:space:]]*(sudo|doas|run0)[[:space:]]*$' /home/antiz/.config/arch-update/arch-update.conf
+ '[' -z '' ']'
+ bold='\e[1m'
+ blue='\e[1m\e[34m'
+ green='\e[1m\e[32m'
+ yellow='\e[1m\e[33m'
+ red='\e[1m\e[31m'
+ color_off='\e[0m'
+ pacman_color_opt=always
+ statedir=/home/antiz/.local/state/arch-update
+ tmpdir=/tmp/arch-update-1000
+ mkdir -p /home/antiz/.local/state/arch-update /tmp/arch-update-1000
+ '[' -z '' ']'
+ command -v sudo
+ su_cmd=sudo
+ command -v paru
+ aur_helper=paru
++ command -v flatpak
+ flatpak=
++ command -v notify-send
+ notif=/usr/bin/notify-send
+ case "${option}" in
+ list_option=y
+ list_packages
+ sed '${/^$/d;}'
++ eval_gettext 'Looking for updates...\n'
++ gettext 'Looking for updates...\n'
+++ envsubst --variables 'Looking for updates...\n'
++ export PATH
++ envsubst 'Looking for updates...\n'
+ info_msg 'Looking for updates...\n'
+ msg='Looking for updates...\n'
+ echo -e '\e[1m\e[32m==>\e[0m\e[1m Looking for updates...\n\e[0m'
+ '[' -z '' ']'
==> Looking for updates...
++ checkupdates
+ packages=
+ '[' -n paru ']'
+ '[' -z '' ']'
++ paru --color always -Qua
+ aur_packages=
+ '[' -n '' ']'
+ '[' -n '' ']'
+ '[' -n '' ']'
+ '[' -n '' ']'
+ '[' -z '' ']'
+ '[' -z '' ']'
+ '[' -z '' ']'
+ state_up_to_date
+ echo arch-update
+ '[' -z y ']'
+ exit 7

Additional context

This is due to the fact that "each command in a multi-command pipeline, where pipes are created, is executed in its own subshell" (source: https://www.gnu.org/software/bash/manual/html_node/Pipelines.html, see also https://relentlesscoding.com/posts/bash-commands-in-pipelines-subshells/), so it's actually the subshell spawned by the piped sed command that gets exited with code 7.
To fix that we would either need to find a way to exit the parent shell instead or to move the sed part within the list_packages function directly (to avoid piping it into its own subshell).

However, given the debatable usefulness of that sed part, I'm actually in favor of simply dropping it entirely. I'm not sure the very little benefit it brings (namely removing the last blank line of the output for purely aesthetic reason) is worth the hassle.

list_packages | sed '${/^$/d;}'

On some Desktop Environment/Window Managers (e.g. XFCE), enabling the systemd service to start the systray automatically at boot doesn't work (but starting it manually after login works, I assume the graphical-session.target is reached earlier on those DEs/WMs).

Most DEs/WMs implement XDG Autostart which can be used as a workaround. For instance, XFCE has a dedicated "autostart" settings menu to handle autostart app/commands, so one can add the arch-update --tray command in there, which is documented in the systray section of the README.

However, adding the Arch-Update systray to autostart apps can probably be automated at the Arch-Update level fairly easily.
Indeed, shipping a .desktop file for the systray applet and copying it under ${XDG_CONFIG_HOME:-${HOME}/.config}/autostart/arch-update-tray.desktop should enough to add the Arch-Update systray to autostart apps without requiring users to do it themselves manually (at least for DEs/WMs that uses the default XDG Autostart directories).

This can be done via an extra argument to the --tray option, for instance arch-update --tray --enable.

Environment

• Distribution: Arch Linux
• Arch-Update version: 2.1.0

Description of the bug

Tray icons on Plasma can be shown always besides other tray icons or can be shown on the tray icons popup (triggered by the arrow button shown in the picture).

It seems that due to missing arguments on QApplication (at src/script/arch-update-tray.py), the Arch-Update tray icon can not be configured under Plasma.

Screenshots / Logs

Current parameters: QApplication([])

When setting up the first parameter, the icon issue is fixed and the first argument will be used as application title e.g. QApplication(["Arch-Update"])

Sorry to write here, but you don't explain on how I must do to make the integration in the plasma systray (or gnome systray, but I use plasma )

Can you give me the process please?

It will be great adding the process in the readme for everyone.

It's hard to find this information.

Thanks a lot.

I love the new version 2 of arch-update. I want to check for updates after starting Linux only. I enabled arch-update-tray.service and arch-update.timer. Then I want to overwrite the properties of the timer service.

So I added the following into the override.conf:

[Timer]
OnStartupSec=15
OnUnitActiveSec=

I thought, that leaving the second entry empty would only check for updates after starting Linux. But when enabling the service now, I got the following error:

Failed to start arch-update.timer: Unit arch-update.timer has a bad unit file setting.

Isn't it possible to stop arch-update from checking for updates periodically?

Hello Antiz,

I would add a pull request but I actually don't know how it works :(

I added this to the script on my own to clear the cache, I was doing manually after updates.
Feel free to add and improve you want.

# Definition of the clear_paccache function: Remove previous versions of packages from clear_paccache
clear_paccache() {
  cache_old=$(paccache -dk2 | sed -n 's/.*: \([0-9]*\) candidate.*/\1/p')
  [ -z "$cache_old" ] && cache_old=0
  cache_uninstalled=$(paccache -duk0 | sed -n 's/.*: \([0-9]*\) candidate.*/\1/p')
  [ -z "$cache_uninstalled" ] && cache_uninstalled=0
  cache_total=$(($cache_old+$cache_uninstalled))

  if [ $cache_total -gt 0 ]; then
    if [ $cache_total -eq 1 ]; then
      read -rp $'Would you like to remove the older package version stored in cache? [Y/n] ' answer
    elif [ $cache_total -gt 1 ]; then
      echo $cache_total older packages versions are stored in cache.
      read -rp $'Would you like to remove them? [Y/n] ' answer
    fi

    case "${answer}" in
      [Yy]|"")
        "${su_cmd}" paccache -rk2
        "${su_cmd}" paccache -ruk0
      ;;
    esac
  fi
}

Do you want to treat pacnew files ? -> yes
Select an editor :

• [1] vim (default/terminal)
  [2] meld (GUI)

Something like that.

If you choose 2 -> check if meld is installed, if not -> install