Aarchup a fork from archup

krabat · 2015-03-15 21:07:34

Thanks a lot for your extensive posting which indeed answered all my questions. FYI the particular findings which made me ask can now be found in LXQt #543 (first part).
There are two more things I'd like to ask:

I wonder whether GTK still is an indispensable dependency.
As I understand it Desktop Notifications Specification's workflow is such that the application that wants to have a message displayed hands it to libnotify which in turn hands it to the daemon / server implementation. This should actually mean that the server is the only component that has to interact with those widget toolkits.
Hence I wonder whether the dependency on GTK isn't just a remnant from the times when Galago project's notification daemon which indeed depends on GTK was the only server implementation available.

Did you ever think about adding a means to download pending updates as well?
I mean, aarchup is for Arch Linux which is on the bleeding edge. Hence having to download stuff is rather normal and not the exception.
So using aarchup to download those pending updates would be something nice to have, imho.

aericson · 2015-03-15 23:27:25

krabat wrote:

Thanks a lot for your extensive posting which indeed answered all my questions. FYI the particular findings which made me ask can now be found in LXQt #543 (first part).
There are two more things I'd like to ask:
I wonder whether GTK still is an indispensable dependency.
As I understand it Desktop Notifications Specification's workflow is such that the application that wants to have a message displayed hands it to libnotify which in turn hands it to the daemon / server implementation. This should actually mean that the server is the only component that has to interact with those widget toolkits.
Hence I wonder whether the dependency on GTK isn't just a remnant from the times when Galago project's notification daemon which indeed depends on GTK was the only server implementation available.
Did you ever think about adding a means to download pending updates as well?
I mean, aarchup is for Arch Linux which is on the bleeding edge. Hence having to download stuff is rather normal and not the exception.
So using aarchup to download those pending updates would be something nice to have, imho.

I'm glad I could be of help.

I will look into removing gtk as dependency, it might not be needed. We rely on it also for the key-value file parser but glib might be enough for it instead.

I'm afraid I don't think downloading updates is in the scope of aarchup. It doesn't follow the philosophy of "just doing one thing, but doing it well" as suggested by it's predecessor archup.

Thanks for taking the time to comment on it.

Alad · 2015-09-20 06:40:17

This runs partial upgrades. Yay! Look up how checkupdates works.

aericson · 2015-09-21 00:37:14

Alad wrote:

This runs partial upgrades. Yay! Look up how checkupdates works.

Yea it does . Migrating to doing what checkupdates does would be nice in the future.

Sadly I have no idea when this will come around. I will create a issue at github for it.

Thanks!

Alad · 2015-09-21 12:31:49

It's not as complicated as you think:

https://projects.archlinux.org/pacman.g … .sh.in#n52

mkdir -p "$CHECKUPDATES_DB"
ln -s "${DBPath}/local" "$CHECKUPDATES_DB" &> /dev/null

First it creates a temporary directory to a place the user can write (TMPDIR). Second, it creates a symbolic link to the local pacman database (i.e, information on the installed packages).

fakeroot pacman -Sy --dbpath "$CHECKUPDATES_DB" --logfile /dev/null &> /dev/null
pacman -Qu --dbpath "$CHECKUPDATES_DB" 2> /dev/null | grep -v '\[.*\]'

Now it syncs to the temporary (!) path (creating a sync folder with the remote db's in the process). It can do this as a regular user with the magic of fakeroot.

Finally it checks what packages can be "upgraded", and presents it in a nice format.

Or you could just call checkupdates directly.

Last edited by Alad (2015-09-21 12:33:30)

aericson · 2015-09-22 16:21:28

I will try to take a swing at it this weekend. Thanks!

aericson · 2015-09-30 04:00:19

Done, let me know if you have any troubles with it.

krabat · 2015-09-30 21:30:51

noxaarchup.sh as provided by 1.8 doesn't seem to work here

# /usr/share/aarchup/noxaarchup.sh
DEBUG(error): It could have been caused by an enviroment restart.
DEBUG(error): Trying to work around it by reinitin libnotify.

(process:15475): libnotify-CRITICAL **: notify_notification_show: assertion 'error == NULL || *error == NULL' failed

Unfortunately I don't have time to dig into this further right now. At first glance the error messages posted above are from sudo the invocation of which is faulty as the variables in call_aarchup() don't get set properly.
Problem seems to be a regression as I'm pretty sure the script used to work in earlier versions.

aericson · 2015-10-01 03:09:44

krabat wrote:

noxaarchup.sh as provided by 1.8 doesn't seem to work here
# /usr/share/aarchup/noxaarchup.sh
DEBUG(error): It could have been caused by an enviroment restart.
DEBUG(error): Trying to work around it by reinitin libnotify.

(process:15475): libnotify-CRITICAL **: notify_notification_show: assertion 'error == NULL || *error == NULL' failed
Unfortunately I don't have time to dig into this further right now. At first glance the error messages posted above are from sudo the invocation of which is faulty as the variables in call_aarchup() don't get set properly.
Problem seems to be a regression as I'm pretty sure the script used to work in earlier versions.

It is not a regression, it also broke on 1.7.4. Might have been caused by https://www.archlinux.org/news/d-bus-no … ser-buses/ I will take a look.

Last edited by aericson (2015-10-01 03:09:54)

aericson · 2015-10-01 03:49:40

krabat wrote:

noxaarchup.sh as provided by 1.8 doesn't seem to work here
# /usr/share/aarchup/noxaarchup.sh
DEBUG(error): It could have been caused by an enviroment restart.
DEBUG(error): Trying to work around it by reinitin libnotify.

(process:15475): libnotify-CRITICAL **: notify_notification_show: assertion 'error == NULL || *error == NULL' failed
Unfortunately I don't have time to dig into this further right now. At first glance the error messages posted above are from sudo the invocation of which is faulty as the variables in call_aarchup() don't get set properly.
Problem seems to be a regression as I'm pretty sure the script used to work in earlier versions.

Should work now.

krabat · 2015-10-01 18:34:27

aericson wrote:

Should work now.

No, it doesn't. And after having another look in the meantime I think it cannot be expected to as this is what seems to happen: Neither gconf-helper nor dconf-service are running → call_aarchup() gets /proc/self/environ handed over → the latter is lacking environment variables DISPLAY and DBUS_SESSION_BUS_ADDRESS as noxaarchup.sh is run by root → sudo is failing due to faulty invocation.

So I rewrote the script such that it doesn't rely on those configuration tools to detect sessions but on window managers and modified the sudo invocation:

#!/usr/bin/sh

# based on script from https://aur.archlinux.org/packages/batterylife

call_aarchup(){

    AARCHUPUSER=$(grep -Ez '^USER' $1 | sed 's/USER=//')
    DBUS_ADDR=$(grep -Ez '^DBUS_SESSION' $1)

    sudo -u $AARCHUPUSER sh -c "$DBUS_ADDR aarchup --icon /usr/share/aarchup/archlogo.png"
}

wrapper(){
    # look for running X sessions via window manager binaries and launch an aarchup instance
    # in each of them
    called=false
    for p in $(pgrep kwin); do
        call_aarchup /proc/$p/environ
        called=true
    done
    if [ $called = false ]; then
        for p in $(pgrep openbox); do
            call_aarchup /proc/$p/environ
            called=true
        done
    fi
    if [ $called = false ]; then
        for p in $(pgrep xfwm); do
            call_aarchup /proc/$p/environ
            called=true
        done
    fi
    # attempt to catch sessions missed so far
    if [ $called = false ]; then
        for p in $(pgrep session); do
            call_aarchup /proc/$p/environ
        done
    fi
}

wrapper || exit 1

Probably it isn't perfect and e. g. could be complemented with other window managers. But it's working flawlessly on KDE Plasma 5 running KWin, LXDE running Openbox, LXQt running KWin 4 or 5, Openbox or Xfwm4, Xfce 4.12 running Xfwm4 and mere Openbox sessions here and hence seems like the more reliable approach for now.

Last edited by krabat (2015-10-01 20:24:12)

aericson · 2015-10-02 02:02:26

krabat wrote:

....
Probably it isn't perfect and e. g. could be complemented with other window managers. But it's working flawlessly on KDE Plasma 5 running KWin, LXDE running Openbox, LXQt running KWin 4 or 5, Openbox or Xfwm4, Xfce 4.12 running Xfwm4 and mere Openbox sessions here and hence seems like the more reliable approach for now.

I'm afraid that doesn't work for me as I don't run a window manager.
I can add the wm together with the conf tools.

Could you please change the line of your suggested script to:

sudo -u $AARCHUPUSER sh -c "aarchup --icon /usr/share/aarchup/archlogo.png"

and let me know if it works? there shouldn't be a need for DBUS_SESSION_BUS_ADDRESS to be set anymore.

krabat · 2015-10-02 12:41:32

aericson wrote:

I'm afraid that doesn't work for me as I don't run a window manager.
I can add the wm together with the conf tools.

Never using a window manager on a production desktop system (which is what tools like aarchup are basically meant to run on, IMO) seems a bit odd to me but sure, the tests provided right now won't catch your session on a system like that.

If sudo doesn't get handed DBUS_SESSION_BUS_ADDRESS leaving the script as is otherwise the invocation fails with the very same error messages stated in my second to last comment. And again as far as I understood this isn't surprising: D-Bus is transfering environment variable DISPLAY which is crucial as noxaarchup.sh gets launched by root.
It is possible to grep DISPLAY from those /proc/*/environ but I didn't manage to get the sudo invocation working if DISPLAY was stated in 'sh -c [...]' but DBUS_SESSION_BUS_ADDRESS wasn't.
So this looks like D-Bus was mandatory but at the same time working flawlessly. Any particular reason you want to avoid using it?

On a side note I think package sudo should be stated by optdepends in PKGBUILD. Its availability cannot be taken for granted.

Last edited by krabat (2015-10-02 12:43:03)

joffaMac · 2016-10-11 01:00:18

I see it's been a while since anyone asked a question so I assume somethings wrong with the way I'm doing this.
I've read the man pages and am confused - do I need a config file for both looptime and systemd, or just looptime? I assume just looptime.

I installed aarchup by using yaourt. I then want to use the systemd timer option, so in accordance with the man page:
"The most simple setup is for a single user system where you want to check once an hour for updates. In this case just type: $ sudo systemctl start aarchup.timer"
I also run that with the 'enable' option.

I've done that and checked the systemd status for aarchup and it's active, restarted, reinstalled, etc., but so far after a week, nothing. Yet if I run a manual command yaourt -Syua it finds packages to update.

Any suggestions?

krabat · 2016-10-12 00:16:34

systemd unit files aarchup.{service,timer} are relying on script noxaarchup.sh. This script is dysfunctional since quite a while, see discussion started above which among other proposes a fixed version of the script that's working fine here.

As an alternative you may use script aarchupstartup.sh and have it launched according to the XDG Autostart Specification by a file /home/user/.config/autostart/aarchup.desktop. This is described rather well in section "Loop-time" of man 1 aarchup and working here, too.

Configuration file /etc/aarchup.conf is basically just setting some default command line options of binary aarchup. Its usage is optional and independent of the two ways to run aarchup automatically.

A notification daemon according to the Desktop Notifications Specification like notification-daemon, xfce4-notifyd or lxqt-notificationd has to be available. You can check whether it works by binary notify-send which belongs to package libnotify.

Personally I'm not that sure any longer whether tools like aarchup make sense in the first place. We're on a rolling release distribution so updates come in so frequently that it's rather pointless to check whether something's available.
In case you do want a GUI to get informed you may want to have a look at Octopi. It is available in the AUR as well, more feature-rich and under more active development.

Alad · 2016-10-12 04:58:20

In case you do want a GUI to get informed you may want to have a look at Octopi. It is available in the AUR as well, more feature-rich and under more active development.

If by features you mean periodicially running partial updates (by design), then yes, Octopi has more features.

Arch Linux

#76 2015-03-15 21:07:34

Re: Aarchup a fork from archup

#77 2015-03-15 23:27:25

Re: Aarchup a fork from archup

#78 2015-09-20 06:40:17

Re: Aarchup a fork from archup

#79 2015-09-21 00:37:14

Re: Aarchup a fork from archup

#80 2015-09-21 12:31:49

Re: Aarchup a fork from archup

#81 2015-09-22 16:21:28

Re: Aarchup a fork from archup

#82 2015-09-30 04:00:19

Re: Aarchup a fork from archup

#83 2015-09-30 21:30:51

Re: Aarchup a fork from archup

#84 2015-10-01 03:09:44

Re: Aarchup a fork from archup

#85 2015-10-01 03:49:40

Re: Aarchup a fork from archup

#86 2015-10-01 18:34:27

Re: Aarchup a fork from archup

#87 2015-10-02 02:02:26

Re: Aarchup a fork from archup

#88 2015-10-02 12:41:32

Re: Aarchup a fork from archup

#89 2016-10-11 01:00:18

Re: Aarchup a fork from archup

#90 2016-10-12 00:16:34

Re: Aarchup a fork from archup

#91 2016-10-12 04:58:20

Re: Aarchup a fork from archup

Board footer