No packages pulled on Arch

[ShalokShalom]

Hi there :)

I setup PackageKit by installing and configuring Discover with the PackageKit-Qt implementation.
I set for daily upgrades on reboots.

Sadly, my /var/lib/system-update is empty, and my normal Pacman cache doesnt store any packages that are yet to update either.

So, no upgrade is happening on a reboot.

The implementation for Pacman in Packagekit does not change any default, so I am puzzled what went wrong here: https://github.com/PackageKit/PackageKit/blob/main/backends/alpm/pacman.conf

It seems like Packagekit is simply not pulling any outstanding updates.
Pacman itself can see them just normal.

packagekit-offline-update.service is loaded.

[sidt4]

I'm not sure how actively the alpm backend is being maintained due to https://gitlab.archlinux.org/archlinux/packaging/packages/gnome-software/-/issues/1.

You're welcome to try / cleanup / fix issues in the alpm backend if you're interested in getting KDE Discover work with PackageKit.

Here are a few tips to get started.

You can run the following commands when KDE Discover is talking to PackageKit.

1. Running following command as root gives the PackageKit daemon log.

   # journalctl -xb /usr/lib64/packagekitd

2. pkmon command shows transaction details.

3. pkcon command can be used to directly interact with the PackageKit daemon. If something doesn't work in KDE Discover, it's better to check if the pkcon equivalent client command works. For example, pkcon update --only-download command is the used to only download updates. You can check if this command succeeds before trying in KDE Discover.

[ShalokShalom]

journalctl -xb /usr/lib64/packagekitd

Mai 20 20:30:37 cosmos64 PackageKit[3242]: daemon start
Mai 20 20:30:38 cosmos64 PackageKit[3242]: get-updates transaction /1_babdecab from uid 1000 finished with success after 897ms
Mai 20 20:30:38 cosmos64 PackageKit[3242]: get-updates transaction /2_aacedbee from uid 1000 finished with success after 2ms
Mai 20 20:30:41 cosmos64 PackageKit[3242]: get-updates transaction /3_dcdedceb from uid 1000 finished with success after 1ms
Mai 20 20:35:37 cosmos64 PackageKit[3242]: uid 1000 is trying to obtain org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:>
Mai 20 20:35:37 cosmos64 PackageKit[3242]: uid 1000 obtained auth for org.freedesktop.packagekit.system-sources-refresh
Mai 20 20:35:37 cosmos64 PackageKit[3242]: refresh-cache transaction /4_ccebebbb from uid 1000 finished with success after 1ms
Mai 20 20:35:37 cosmos64 PackageKit[3242]: get-updates transaction /5_aecdcadb from uid 1000 finished with success after 2ms
Mai 20 20:40:43 cosmos64 PackageKit[3242]: daemon quit

This seems like it succeeds pulling them?

pkmon

Transactions:
[none]
daemon connected=0
daemon connected=1
network status=online
Transactions:
1      /1_bbabbcbb
/1_bbabbcbb     allow_cancel 1
/1_bbabbcbb     percentage   -1
/1_bbabbcbb     role         get-updates
/1_bbabbcbb     sender       /usr/lib/DiscoverNotifier
/1_bbabbcbb     status       query

(pkmon:49123): GLib-GIO-CRITICAL **: 20:49:02.046: GTask 0x5f50a3743220 (source object: 0x5f50a3741150, source tag: 0x71b6ec0288e0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program.
updates-changed
Transactions:
[none]
Transactions:
1      /2_dbebedcd
/2_dbebedcd     allow_cancel 1
/2_dbebedcd     percentage   -1
/2_dbebedcd     role         get-updates
/2_dbebedcd     sender       /usr/lib/DiscoverNotifier
/2_dbebedcd     status       download-packagelist

(pkmon:49123): GLib-GIO-CRITICAL **: 20:49:08.382: GTask 0x5f50a3743220 (source object: 0x5f50a3741150, source tag: 0x71b6ec0288e0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program.
Transactions:
[none]

And this seems like, it does not succeed??

[sidt4]

get-updates transaction doesn't download the updates, update-packages transaction does that.

To download updates, run:

$ pkcon update -d

and see the logs. And check which part of KDE Discover invokes the above API. Should be triggered by KDE Discover's Download button ?

[sidt4]

(pkmon:49123): GLib-GIO-CRITICAL **: 20:49:08.382: GTask 0x5f50a3743220 (source object: 0x5f50a3741150, source tag: 0x71b6ec0288e0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program.

pkmon is a bit broken currently due to a regression introduced in 1.2.8, and is being addressed in #756. Ignore these warnings.

[ShalokShalom]

Mai 23 12:47:38 cosmos64 PackageKit[3207]: daemon start
Mai 23 12:47:45 cosmos64 PackageKit[3207]: get-updates transaction /1_eaddbcee from uid 1000 finished with success after 6678ms
Mai 23 12:47:49 cosmos64 PackageKit[3207]: get-updates transaction /2_bdebceda from uid 1000 finished with success after 4270ms
Mai 23 12:47:53 cosmos64 PackageKit[3207]: get-updates transaction /3_dbcbaacc from uid 1000 finished with success after 4361ms
Mai 23 12:52:38 cosmos64 PackageKit[3207]: uid 1000 is trying to obtain org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:>
Mai 23 12:52:38 cosmos64 PackageKit[3207]: uid 1000 obtained auth for org.freedesktop.packagekit.system-sources-refresh
Mai 23 12:52:38 cosmos64 PackageKit[3207]: refresh-cache transaction /4_ddbabbca from uid 1000 finished with success after 1ms
Mai 23 12:52:44 cosmos64 PackageKit[3207]: get-updates transaction /5_dacecbcb from uid 1000 finished with success after 5665ms
Mai 23 12:57:48 cosmos64 PackageKit[3207]: daemon quit
Mai 23 17:16:54 cosmos64 PackageKit[632177]: daemon start
Mai 23 17:16:57 cosmos64 PackageKit[632177]: get-updates transaction /1_ebbebaee from uid 1000 finished with success after 3213ms
Mai 23 17:16:57 cosmos64 PackageKit[632177]: new update-packages transaction /3_ebcbdeeb scheduled from uid 1000
Mai 23 17:17:00 cosmos64 PackageKit[632177]: get-updates transaction /2_eebdcbda from uid 1000 finished with success after 2595ms
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:03 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 9
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:04 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:05 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:05 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:05 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:05 cosmos64 PackageKit[632177]: unknown progress type 7
Mai 23 17:19:05 cosmos64 PackageKit[632177]: update-packages transaction /3_ebcbdeeb from uid 1000 finished with success after 124695ms
Mai 23 17:19:07 cosmos64 PackageKit[632177]: get-updates transaction /4_ceeecbbc from uid 1000 finished with success after 2734ms

/var/lib/system-update is still empty/doesnt exist.

[sidt4]

Packages are downloaded to /var/cache/pacman/pkg/.

[ShalokShalom]

I did a reboot (the packages are there) and its still not applying the updates.
I pulled the updates yesterday (do I need to set some service, to do this automatically?) and set the update schedule to daily and on reboot.

[sidt4]

Please refer following link for how offline update works.

• https://github.com/PackageKit/PackageKit/blob/main/docs/offline-updates.txt

Check at which stage things didn't work as expected. I remember doing an offline update a while back in GNOME Arch with GNOME Software, and it worked fine except for a small issue in the end. I'm not sure about KDE Discover or PackageKit-Qt though as I don't use KDE.

[ShalokShalom]

/var/lib/PackageKit/prepared-update does not exist.

Should I file an issue with systemd?

[sidt4]

/var/lib/PackageKit/prepared-update does not exist.

This file should be created by the client doing the update. (e.g KDE Discover / GNOME Software etc).

[sidt4]

Here is the prepared-update file for today's update on my Arch VM.

$ cat /var/lib/PackageKit/prepared-update 
[update]
prepared_ids=hicolor-icon-theme;0.18-1;any;extra,libcap;2.70-1;x86_64;core,ncurses;6.5-2;x86_64;core,sane;1.3.1-1;x86_64;extra,zstd;1.5.6-1;x86_64;core

Below is the screenshot of GNOME Software update UI on Arch. Here, /var/lib/PackageKit/prepared-update gets created when Restart & Update... button is clicked. So, this should be something similar for KDE Discover.

[ShalokShalom]

I think I understand my confusion now.

Discover ships with a plugin for the system settings:

And once that is set, Discover expects you to update just normal.
I didnt screenshot it pre-update, but it did say just "Update all" and did not mention anything about rebooting at all. Only after applying those updates, it hints on it:

I think this is solved.