Arch Linux User Repository

@kippie The original developer of kalu stopped developing it, and @Thulinma kindly took over some general maintenance. My understanding is that (as per their comment in December last year) they are only fixing broken functionality. Presumably they are open to pull requests, but I expect it would be a massive rewrite unfortunately.

Hello. I'd like to thank all involved in developing & maintaining this lovely little tool. 👍

I've used it for years, & in Plasma X11 sessions it's perfect. Unfortunately though, its functionality is severely restricted in Plasma Wayland sessions, eg, SystemTray icon right-click context menus do not work at all, & even left-clicks fail once updates or news are available & the user tries to click their respective Notifications' OK buttons.

Are there plans to enhance this app for better Wayland compatibility, please?

Thanks for the update @jghodd. Hopefully it stays solid.

@Rhinoceros - apparently, the packagekit + the kalu-kde rebuilds seem to have resolved the crashing issue i was seeing, although i do understand that some other package update may have caused and ultimately resolved it. i've been monitoring the log files for 4 days now (tail -f in an open terminal window) and am seeing no signs that there are any errors related to kalu-kde (other than the plasmashell spam in the logs which i believe is a plasmashell issue - i will open a ticket). do understand that the source i tweaked was local and intended only for testing - the logic actually introduces a bug where other functions, who use the GError** parameter, may fail. i've been running/testing with a version that does not include that source change, just a rebuild (revision 2). so, for now, all is good.

@Thulinma & @Rhinoceros - i did end up making a single source change in kalu-updater.c in kalu_updater_free_alpm, but i consider it inconsequential - just created a local GError* instance, auto-initialized to NULL, and passed the address of the pointer to g_dbus_proxy_call_sync. also, i rebuilt packagekit, libpackagekit-glib, packagekit-qt5/6, then kalu-kde (in that order), and i'm not seeing the crash at this point in time. it's hard to debug since i need updates to run the updater. :-)

@Thulinma - thank you for the offer. i'll do what i can to narrow down where things are getting dodgy, but despite multiple decades as a software engineer (C/C++/Java), there's way more source code in kalu-kde than i can absorb in a few hours, or even days, so assistance from someone who has already been rooting around in there is really helpful. i'm beginning to think that something else in the DE is unstable and causing the problems so i'm monitoring the log files. also, all the latest packagekit packages were released on 12/2, which is approximately when the issues started which would suggest a packagekit bug, or a problem with the interaction with whatever was updated in packagekit.

Edit: i can say that i'm going to have to open a bug report on plasmashell. while kalu is doing anything other than sitting quietly in the system tray, plasmashell spams the system's log files with this message at a rate of 2 per second:

Dec  7 23:13:13 myhost plasmashell[1389]: kde.systemtray: DBusMenu disabled for this application

Thanks @Thulinma. Glad to see you are still around!

I am / are! I'm currently only fixing broken functionality, as I'm still figuring out the structure of the project. 😅 I'm happy to help find the problem and/or accept a patch into my fork, no problem. Just, eh, I don't use the "-kde" version of kalu myself (as I don't use a desktop manager that needs/uses it 🙃), so I might need some assistance verifying when a fix is ready. That's all ^_^

@jghodd Thanks for your investigation.

It had slipped my mind that @Thulinma had forked kalu, and had originally planned to maintain it. I was going to suggest it might be more productive to have a conversation upstream at the GitHub project page, but there doesn't seem to be any response there since the first issue almost a year ago unfortunately. I'm not sure if @Thulinma still intends on maintaining the fork, but if there is substantial modification to the code, you could always re-fork. Or (assuming you find a fix) we could just apply the patch here for now and see if there is any action in the original fork later.

@Rhinoceros - the callback function that catches my eye is btn_close_cb in updater.c

static void
btn_close_cb (GtkButton *button _UNUSED_, gpointer data _UNUSED_)
{
    if (updater->kupdater != NULL)
    {
        free_kupdater (FALSE);
        /*FIXME*/
    }
    else
        kalu_alpm_free ();
    gtk_widget_destroy (updater->window);
}

gotta ask why there's a FIXME comment in there.

if you take a look into free_kupdater(), there's a call to kalu_updater_free_alpm that's a little sketchy without chasing down the source for g_dbus_proxy_call_sync

kalu_updater_free_alpm (updater->kupdater, NULL, NULL, NULL, NULL);

note that the last parameter is NULL. that NULL is being re-passed as a GError pointer-to-a-pointer (can't use the double asterisk because it bolds half the comment) to g_dbus_proxy_call_sync. i don;t know if that's the issue, but a double dereference on NULL, if not handled carefully, could cause a segfault. i need to chase down the source for g_dbus_proxy_call_sync to find out how it handles that GError** parameter.

it is likely that g_dbus_proxy_call_sync does a null check on the error pointer (although i hope it's not "if (*error == NULL)" - the single dereference on error would also cause a segfault).

but, i'd really like to know why that FIXME comment is there in btn_close_cb.

Edit: checked the source for g_dbus_proxy_call_sync and it's check on the GError parameter uses "if ((error == NULL) || (*error == NULL))", so the second condition won;t be checked if the first is false - all good.

still looking around, but also still wondering what that FIXME comment was all about.

Edit2: taking a closer look at packagekit. it was updated 12/2 and the logged errors always seem to mention packagekit. as a bonus, i can downgrade all the packagekit packages and see if that gets things working again.

Edit3: i guess the log entries bothering most are these:

Dec  6 17:57:54 myhost kded5[1396]: packagekitqt.transaction: Unknown Transaction property: "Sender" QVariant(QString, ":1.39")
Dec  6 17:57:54 myhost kded5[1396]: packagekitqt.transaction: Unknown Transaction property: "Sender" QVariant(QString, ":1.39")

@Rhinoceros - it could be an anomalous error. packagekit-qt5 and its non-qt5 corollaries were all updated on 12/2. at the moment, after another reboot after icu was updated, and another subsequent rebuild of kalu-kde, i have yet to experience another segfault (yet). so it might well have been a case of timing - i let you know about "weird" behavior on 12/2 after the packagekit updates, had 2 segfaults more recently, quite possibly after the icu update and before i re-rebuilt kalu-kde. it may have had an out-of-date/sync dependency. however, if it happens again, that'll make it much more likely there's a bug somewhere - perhaps in amongst the build warnings. i'll definitely update here if it happens again.

Edit: am now seeing a couple of log entries i do need to look into - and it's still crashing.

Dec  5 11:54:10 myhost kalu[1515]: gtk_tree_model_get: assertion 'iter != NULL' failed
Dec  5 11:54:10 myhost kalu[1515]: gtk_list_store_set_valist: assertion 'iter_is_valid (iter, list_store)' failed

Edit: interestingly, i'm not seeing the same crash from the kalu package - vs. kalu-kde. so i have to assume the issue is with the kde interaction (which would make sense given that kded5 is crashing). it does rule out the build warnings being at the root of the problem since i'm seeing the same build warnings with kalu (vs kalu-kde).

Edit2: i'm thinking status-notifier may be the issue. not up front, but when the update is complete. that's when the crash occurs. i'm seeing no crashes with kalu without status-notifier enabled.

Edit3: scratch that. kalu just crashed after an update. happened when the Close button was clicked, so i;ll start looking there.