Package Details: kalu-kde 4.4.1-1

Git Clone URL: (read-only, click to copy)
Package Base: kalu-kde
Description: Upgrade notifier w/ AUR support, watched (AUR) packages, news; supports autohide in KDE Plasma's panel
Upstream URL:
Licenses: GPL3+
Conflicts: kalu
Provides: kalu
Submitter: Rhinoceros
Maintainer: Rhinoceros (Thulinma, jghodd)
Last Packager: Rhinoceros
Votes: 15
Popularity: 0.000418
First Submitted: 2014-12-30 12:30 (UTC)
Last Updated: 2021-07-03 07:11 (UTC)

Pinned Comments

Latest Comments

Rhinoceros commented on 2021-11-12 09:19 (UTC)

Thanks @Thulinma. Great to hear! Thank you! Also, GitHub issues are now working. I didn't know how it worked, but I always assumed it was when devs didn't want to be bothered! :D

Yes, I see similar behaviour to @emacsomancer. I had been trying to find a way to trigger the problem all the time, but I can't even get it to work now. I'll keep at it and see if I can isolate a 100% reproducible situation.

emacsomancer commented on 2021-11-10 02:02 (UTC)

@Thulinma: It usually doesn't surface straight away, but not long after a reboot, interactions with (or even near - say with another systray application) pull up the kalu menu, even if they shouldn't. And the menu can only be made to disappear by making a selection (I usually click on "About" as a workaround). I think it is definitely a Plasma issue, and an issue with the latest version of Plasma - it didn't happen before the anniversary edition.

Thulinma commented on 2021-11-10 01:10 (UTC)

@Rhinoceros Yeah, I plan to maintain the package from here on forward, at least until the original author reappears (if ever). Disabling issues was not intentional - that may have been a think github did for me without me realizing. I'll re-enable it!

I have not seen this issue yet - can somebody describe it in a way I can reproduce it? Or is it Plasma-specific? (I do not use Plasma myself at all - so that would explain why I don't see it, in that case...)

Rhinoceros commented on 2021-11-08 21:31 (UTC)

Sorry @emacsomancer and @Healing_Hands, yes, I am seeing this occasionally now too. I'm not sure if @thulinma is still interested in further upstream maintenance. That was be much appreciated if possible! (I noticed they had disabled "issues" in the Github repo.)

emacsomancer commented on 2021-11-08 21:06 (UTC)

@Healing_Hands: it's sporadic too. restarts seem to help for a time, but it comes back. I think it may not be specific to kalu, so perhaps something about the new version of plasma more generally?

Healing_Hands commented on 2021-11-08 21:05 (UTC)

@emacsomancer I have the same Problem, so I don't think it's a configuration issue.

Rhinoceros commented on 2021-10-21 03:15 (UTC)

@emacsomancer it seems to work fine for me, also on Plasma 5.23.1.

emacsomancer commented on 2021-10-20 17:51 (UTC)

Under Plasma 5.23.1 it seems like the menu won't disappear unless I double-click things? Maybe it's a local configuration issue, I don't know.

Thulinma commented on 2021-08-12 10:43 (UTC)

@simona: kalu-kde has an extra dependency on statusnotifier, which the normal kalu package does not have (for KDE taskbar icon support). For the rest they are identical. So kalu-kde is a better choice if you have a modern desktop environment that uses SNI for taskbar icons, while the regular kalu package is better for older desktop environments that use xembed instead.

simona commented on 2021-08-12 10:33 (UTC)

what's the difference ex kalu-kde and kalu?

jghodd commented on 2021-07-10 22:18 (UTC)

@Thulinma Nice job, bud. Works like a champ. Took a look at your code changes and, again, nice job.

Thulinma commented on 2021-07-02 12:50 (UTC) (edited on 2021-07-02 12:51 (UTC) by Thulinma)

A quick heads-up: I just released 4.4.1, which adds support for parallel downloading in the updater GUI (and, if I do say so myself, all the progress bars going at the same time makes it look really cool).

Also, I think the statusnotifier.patch is no longer needed, as my fork integrated the original author's update to StatusNotifier 1.00 already. You might want to try without that patch and see how it goes! ^_^

For the record, I keep a list of changes from the original kalu in the README:

Rhinoceros commented on 2021-06-27 14:25 (UTC)

Great! Thanks again!

Thulinma commented on 2021-06-27 14:23 (UTC)

Ah, I didn't realize automake was part of base-devel, heh. Now updated the kalu package to use the tarball as well.

Rhinoceros commented on 2021-06-27 14:01 (UTC)

Thanks @Thulinma! Looks great! I've updated the PKGBUILD. Thank you so much for your updates. It looks like it was quite a lot of work in the end!

Also, a few comments about the PKGBUILD for "kalu" itself. The source can be changed to the tar.gz, which means you can add the checksum too, and remove git. automake doesn't need to be in makedepends, because base-devel is presumed to be installed. Feel free to compare to this PKGBUILD if you like, but I'm also happy to co-maintain if you want. I don't use the other version though, so not necessary either! Thanks again!

Thulinma commented on 2021-06-27 13:41 (UTC)

Derp. I did tag it in git, but forgot to push the tag to github. Done!

Rhinoceros commented on 2021-06-27 13:34 (UTC)

@Thulinma Brilliant! Thank you!

Just regarding the "tag", if you tag the actual commit itself in Github, then we can reference this version/tag in the PKGBUILD(s), rather than just fetching HEAD. It also means that we can source the tar.gz rather than use git. Thanks again!

Thulinma commented on 2021-06-27 12:48 (UTC)

@Rhinoceros Done! Download progress works now, as far as I can tell, and I moved the code to the master branch of the repo, cleaned it up and tagged it as 4.4.0.

That means you'd now simply use:


I also took over the main "kalu" package and updated it to my fork. So that version now finally works again too. ^_^

Rhinoceros commented on 2021-06-27 06:48 (UTC)

Thanks @Thulinma. I don't actually use the built-in updater, so I couldn't test that, but the other parts seem to work great, including --enable-status-notifier! I'll wait a while until you have the final version, then I'll release it. Please let me know when it's ready.

Thulinma commented on 2021-06-26 21:25 (UTC) (edited on 2021-06-26 21:26 (UTC) by Thulinma)

@Rhinoceros Yes, this one works with latest pacman, no alpm12 needed. To create the configure file, just run first. I tested this build function and it worked for me:

build() {
  cd "$srcdir/${pkgname%-kde}"
  ./configure --prefix=/usr

(Using --enable-status-notifier probably works too, but I didn't test that yet)

And I used this source:


Do note that while it totally works, it's not fully finished yet. Download progress is currently invisible, so it starts the download... nothing seems to happen while it downloads, and then it starts installing. Still, better than nothing! That seems to be the only thing not working yet, and if I have some more time tomorrow I'll see if I can get that to work as well.

Rhinoceros commented on 2021-06-26 06:26 (UTC)

@Thulinma Thanks for that! How does this new code differ from @jghodd's hack? Also, I can see that you integrated gcc10.patch and a46975cdcb926ea8508c012d333471c1e1cb8529.patch, but not @jghodd's fix-for-alpm12.patch. Does this mean it doesn't rely on alpm12, just the latest version in pacman?

If you look at the PKGBUILD, you can see it pulls sources from, not the Github repo. There are a few differences. For example, in the Github repo (and your clone) there is no configure file, so the PKGBUILD doesn't work as-is. Is there another way I should be building?

Thulinma commented on 2021-06-25 22:49 (UTC)

Never mind, I couldn't resist checking and after one more commit... it looks like everything "just works" now. It feels a bit hacky, but hey, if it works, it works! Take it for a spin and let me know if it works for you guys too.

Thulinma commented on 2021-06-25 22:05 (UTC)

Hey guys, quick update: I've made some good progress! It compiles (and runs!). I haven't implemented download progress updates yet, but other than that I think it's working (getting a bit late here, going to test more extensively over the weekend).

You can follow along here:

This includes the other patches as well, so it should compile as-is. I plan to polish it a bit more and then get it ready for release.

Rhinoceros commented on 2021-06-22 22:45 (UTC) (edited on 2021-06-22 22:45 (UTC) by Rhinoceros)

@jghodd I just reuploaded alpm12 in the meantime in case it was an error. Hope everything is okay with you.

Rhinoceros commented on 2021-06-11 03:00 (UTC)

@jghodd Thank you! I've tested it and it works brilliantly. I had a look at the patch, and it was epic. Much more to do than I had envisaged, so thank you again for all your work.

jghodd commented on 2021-06-11 01:49 (UTC) (edited on 2021-06-11 01:54 (UTC) by jghodd)

@Rhinoceros - the alpm12 aur project has been created. you can use my patch, and apply the minor PKGBUILD mods (add patch file, add call to patch for new patchfile, and substitute the pacman dependency with alpm12). re-version to whatever makes sense.

for clarity, the PKGBUILD and patch file are located here -

jghodd commented on 2021-06-08 23:38 (UTC) (edited on 2021-06-09 21:24 (UTC) by jghodd)

@Thulinma - np. enjoy. @Rhinoceros - a patch file needs to be generated for the alpm12 version of kalu-kde. i'll take a look at what it'll take. also, if you want to adopt the alpm12 project, you are welcome to it. it's needed to build and run a working kalu-kde from source. the source code for it is included in the alpm12 tar bundle in the alpm12 directory.

@Rhinoceros - i have a patch file for kalu-kde and the modified PKGBUILD. they're at

the PKGBUILD will need minor tweaking to restore checksumming (i replace with SKIP for testing purposes). i've tested the patch and PKGBUILD and it built without any issues. i still have to create a github project for alpm12, which is now a dependency (and make dependency) for kalu-kde.

EDIT2: alpm12 is now a github project: - it has a 1.0.1 tag version available for download. next i have to figure out how to create an AUR project.

EDIT3: go here to find the alpm12 project files (for the AUR) - - the PKGBUILD and alpm12 header files are there (needed for pkgbuild/makepkg). they are complete and will build alpm12-1.0.1, pulling the source from the github project.

there is still some minor work to do on alpm12. although what's there works as expected, some things can be done automatically via make/config on the 'make install' if i can find the right places to modify. it needs to build instead of having to rename it also needs to install alpm12.h and alpm12_list.h from the project source instead of providing them as project extras and doing most of the real install work via PKGBUILD. the make/config files/templates are obviously IDE-generated and more complicated than they need be, so finding the def thread that gets you where you want to be isn;t always obvious. i'll keep on looking for these solutions, but i'm going to slow down a bit. i'm running kalu-kde perfectly right now, built from scratch against the alpm12 (v1.0.1) project build.

i haven't created an AUR project in a couple or more years. i can figure it out all over again, or anyone who wants to can feel free to create the alpm12 project from the files i provided...

EDIT4: fixed one issue in the PKGBUILD and generated the .SRCINFO file. they're all available in

Rhinoceros commented on 2021-06-08 23:15 (UTC)

Thanks again both of you. I've added you both as co-maintainers, so feel free to push changes here when you have a working version.

Thulinma commented on 2021-06-08 22:35 (UTC)

@jghodd Thanks! Downloaded the alpm13 version and will see if I can patch it up to work as soon as I have some free time.

jghodd commented on 2021-06-08 21:53 (UTC) (edited on 2021-06-08 22:32 (UTC) by jghodd)


there are 2 directories there - alpm12 and alpm13.

  • the alpm12 directory contains the packages alpm12 and kalu-kde. these are buildable and installable. and work.
  • the alpm13 directory contains the unfinished source upgrade to alpm13.

right after my last comment, i discovered that someone else has created a libalpm12 aur project. it is incomplete and will not allow the building of kalu-kde. it could probably be used with a pre-existing kalu-kde binary. so... i had to change my original libalpm12 project name to alpm12. this one includes the header files and a correct .pc file. also, the alpm12 project is a significantly pared down version of pacman-5.2.2 - source files removed, make/config files modified. this has not been made into an aur project yet. some of what i've done in the alpm12 project PKGBUILD can most certainly be done via project makefiles - i'll get to that when/if i can. if anybody else cares enough to change the makefile templates to produce a library, please go for it, and remember to change the PKGBUILD accordingly (at the moment, i build and rename it via the PKGBUILD).

jghodd commented on 2021-06-08 19:50 (UTC)

@Thulinma @Rhinoceros - i have a working kalu-kde. i have to tweak a couple of things in my new libalpm12 package, but i'll be able to put together a tar file for y'all soon. i'll also include the source for the aborted attempt to move to alpm-13.

jghodd commented on 2021-06-07 19:56 (UTC) (edited on 2021-06-07 19:59 (UTC) by jghodd)

@Thulinma - i may have gotten further, but i also hit a wall. it's going to take some deep diving to resolve the download callback issue (including the progress numbers). kalu was using the same callback function for both progress and download - the progress callback which, incidentally, still has the same function signature. it's just that you can no longer use the progress callback for the new download callback function. we may be overthinking this. i don't know. i'd kinda like to see what pamac and octopi do to resolve it. the respective developers for those apps are much more familiar with the mechanism(s) and we can follow their lead. so, i decided to stop and take a more expeditious route - i pulled the pacman-5.2.2 code and worked the makefiles and pkgbuild to produce a libalpm12 package which contains only and, and a .pc file for the new package (called alpm12). just finished that last night and will test soon after moving alpm-v12's alpm.h and alpm_list.h into the kalu-kde codebase, and tying those in. that buys time. just make kalu-kde dependent on libalpm12 (as a 4.3.0-x version). if we can fix the kalu code to work with libalpm-13, that, i think, could be a good time to advance the kalu version. i can bundle up what ive done and drop it for you. i'll leave the url here, as an EDIT, whenever i can get it there.

Thulinma commented on 2021-06-04 16:14 (UTC)

@jghodd It sounds like you're further than I was already. Are your changes available somewhere so I can see if I can help figure out the remaining parts?

I'm pretty sure the part you're talking about is used to show the overall download progress bar, which now that pacman supports simultaneous downloads no longer is as trivial as it used to be. We can probably calculate it from the progress callback, or worst case just remove/disable the progress bar altogether.

Rhinoceros commented on 2021-06-04 07:43 (UTC)

@jghodd Thank you so much for all the work you've done so far. A pity these issues seem difficult to overcome. Hopefully you or @Thulinma can come up with something. Thanks again.

jghodd commented on 2021-06-04 05:15 (UTC) (edited on 2021-06-04 05:16 (UTC) by jghodd)

@Rhinoceros - i've been able to address all issues except two - and one of them is a big one. per the pacman README:

[REMOVED] - old TotalDownload implementation - alpm_cb_totaldl - alpm_option_get_totaldlcb() - alpm_option_set_totaldlcb()

[CHANGED] - alpm_cb_download pass event and data

these changes are not simple ones. i won;t be addressing them tonight. i'm going to see if i can come up with a wrapper solution for the alpm_cb_download issue, but thus far i have no idea how to fix the totaldl problem - it's use is important to the current source code, but the means to provide some value has been removed. i'll have to see if i can find some other way to get to the value and how it's now being used. a total rewrite would be difficult, to say the least.

jghodd commented on 2021-06-03 11:38 (UTC) (edited on 2021-06-03 12:29 (UTC) by jghodd)

@Rhinoceros - i was going over the code yesterday and ran into 2 issues. the first is what to do about the context parameter required by the callback functions (e.g. dlcb = download callback), mentioned already by @Thulinma. i can test it with a null context, if i could compile everything else. which brings me to the 2nd issue - kalu-dbus.c references a number of EVENT enumerations, not all of which match the old ones. these 3 i can match up:


these 3 have no equivalent:


the only other with a FAILED status is ALPM_EVENT_DB_RETRIEVE_* and i don;t think it's the same thing. i could be wrong, but i have nothing to provide any useful feedback on this. maybe looking at the alpm source code itself might help if i can find it. that might well resolve the context issue anyway. but, back to the ALPM_EVENTs, when they come in they in turn fire a specific signal, so we need to know exactly how the old and new line up. that's where i'm at so far.

regarding alpm_option_set_dlcb (and all the other callback setters), compiling throws a warning on the second parameter which may or may not be a problem - i won;t be able to tell until i can compile and run. it could be that that parameter simply requires a cast, or it could be that the old callback functions have a different set of parameters than the new ones. either way, i'll know better when i can compile and run everything.

EDIT: i can confirm that the new callback functions do have a difference in their parameters - that context pointer is now required as the first parameter although the other parameters are the same. also, it appears that NULL can be used for the context pointer passed as the last parameter of the callback setter functions (note to @Thulinma). that's how pacman itself uses it. could be it's something planned for future use.

EDIT2: the README from the v6 code shows this as a change:


so, i guess that answers another of my questions.

anyway, i'm hitting the road in an hour or so, and won;t be able to get back into this until much later tonight at the earliest.

Rhinoceros commented on 2021-06-03 01:13 (UTC) (edited on 2021-06-03 13:00 (UTC) by Rhinoceros)

Thanks @jghodd. It's good to know there are potentially two people who can look at this. I've added a link to the package-query patch as a reference.

EDIT: I tried blindly replacing the text as per the package-query patch, but it wasn't enough. There were still errors with alpm_option_set_dlcb.

jghodd commented on 2021-06-02 16:30 (UTC) (edited on 2021-06-02 16:33 (UTC) by jghodd)

@Rhinoceros - thanks for the link. i'd do the patch, but the timing is really bad. i'm going to be out of town for the next 5 days and am not sure if i'll get a chance to dig into the source code. i'll see what i can do. meanwhile, if Thulinma has the time... (i'll keep an eye on any progress made). btw, package-query had similar issues and it's been fixed - might want to also take a look at how the maintainer fixed it. i know the calls to the set_ and get_architecture(s) methods were mended. that'd be a start. meanwhile, i have been able to build new working versions of yaourt, package-query, yay and paru. yaourt with a rebuild, package-query from the github fixes, and yay and paru from aur updates. package-query-1.12 should be available from the aur pretty soon.

Rhinoceros commented on 2021-06-02 00:07 (UTC)

Thanks @Thulinma, that's great. I've pinned your comment.

Thulinma commented on 2021-06-01 23:57 (UTC)

I do know C/C++ and would be more than happy to help patch kalu for pacman 6.0.

I even made a quick attempt a few hours ago (by working off of the existing 5.2 patch). Most of the changes are minor, there are two things that need to be fixed:

  • the system architecture is no longer a single string setting, but a list.
  • Several calls now have an extra parameter for "context", and it is unclear to me what this is for / what it does. I tried to find documentation on this part of libalpm, but it was hard to find after a cursory search.

Neither of these are huge issues. Both are just a matter of putting some time in to learn how they are meant to be used. Right now I don't have that time - but if nobody else picks this up in the next few days I'll probably end up doing it. If somebody else has more knowledge on the new context argument, that would cut most of the time I'd need to put into it and would thus help speed things up considerably. Any takers..?

Rhinoceros commented on 2021-06-01 23:33 (UTC)

@jghodd Yes, I agree. In the pinned comment, I've linked a working patch for alpm_octopi_utils that someone else submitted, which might be useful. I had a brief look at kalu-alpm.c to see if I could make similar changes, but unfortunately I don't understand C++ (the patch) nor C (kalu).

jghodd commented on 2021-06-01 22:23 (UTC)

Looks like the issue is all contained to kalu-alpm.c. Patch, anyone?

simona commented on 2021-06-01 10:17 (UTC)

pacman 6.0 :-(

Rhinoceros commented on 2021-02-18 11:07 (UTC)

@noraj The previous version of plasma-workspace (5.20.5-2) provided notification-daemon, but the new version does not. You'll have to install a new package to provide this dependency instead, e.g. notification-daemon, but there are a few other options.

noraj commented on 2021-02-18 08:31 (UTC)

$ pacman -Syu
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing plasma-workspace (5.21.0-1) breaks dependency 'notification-daemon' required by kalu-kde

Rhinoceros commented on 2020-07-21 04:57 (UTC)

Brilliant. Thank you @dpeukert, that works well. Package updated.

dpeukert commented on 2020-07-20 18:41 (UTC)

@Rhinoceros Here's a patch:

diff --git a/.SRCINFO b/.SRCINFO
index 6fe7764..096caa3 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -1,7 +1,7 @@
 pkgbase = kalu-kde
    pkgdesc = Upgrade notifier w/ AUR support, watched (AUR) packages, news; supports autohide in KDE Plasma's panel
    pkgver = 4.3.0
-   pkgrel = 2
+   pkgrel = 3
    url =
    install = kalu.install
    arch = i686
@@ -22,9 +22,11 @@ pkgbase = kalu-kde
    conflicts = kalu
    source =
    source = statusnotifier.patch
+   source = gcc10.patch
    source =
    sha1sums = 4e9fc8b311077d3720af8619de04c917c01acbfb
    sha1sums = d58712ff827df6bea9c5eb5a7e3d9034f3cac506
+   sha1sums = 6e02682594c169561fbadbde635053cf47e3a2f1
    sha1sums = 6418c6df072de666873e37240bddb33712ae4aac

 pkgname = kalu-kde
diff --git a/PKGBUILD b/PKGBUILD
index b1fcd7c..a81c990 100644
@@ -3,7 +3,7 @@

 pkgdesc="Upgrade notifier w/ AUR support, watched (AUR) packages, news; supports autohide in KDE Plasma's panel"
 arch=('i686' 'x86_64')
@@ -13,10 +13,12 @@ depends=('dbus' 'polkit' 'gtk3' 'pacman>=5.2' 'pacman<5.3' 'curl' 'libnotify'
 makedepends=('perl' 'groff')
+        gcc10.patch
+          '6e02682594c169561fbadbde635053cf47e3a2f1'
@@ -24,6 +26,7 @@ conflicts=(${pkgname%-kde})
 prepare() {
   cd "${pkgname%-kde}-$pkgver"
   patch -p0 -i "$srcdir/statusnotifier.patch"
+  patch -p1 -i "$srcdir/gcc10.patch"
   patch -p1 -i "$srcdir/a46975cdcb926ea8508c012d333471c1e1cb8529.patch"

diff --git a/gcc10.patch b/gcc10.patch
new file mode 100644
index 0000000..43b0fe5
--- /dev/null
+++ b/gcc10.patch
@@ -0,0 +1,31 @@
+diff --git a/src/kalu/kalu.h b/src/kalu/kalu.h
+index 428aea1..1e109d8 100644
+--- a/src/kalu/kalu.h
++++ b/src/kalu/kalu.h
+@@ -134,7 +134,7 @@ typedef enum {
+ } tpl_t;
+ /* template names in config (prefixed w/ "template-") */
+-const gchar *tpl_names[_NB_TPL];
++extern const gchar *tpl_names[_NB_TPL];
+ typedef enum {
+     FLD_TITLE,
+@@ -144,7 +144,7 @@ typedef enum {
+ } fld_t;
+ /* field names in config */
+-const gchar *fld_names[_NB_FLD];
++extern const gchar *fld_names[_NB_FLD];
+ typedef enum {
+@@ -156,7 +156,7 @@ typedef enum {
+ } tpl_sce_t;
+ /* source names in config */
+-const gchar *tpl_sce_names[_NB_TPL_SCE];
++extern const gchar *tpl_sce_names[_NB_TPL_SCE];
+ struct field {
+     const char *def;

Rhinoceros commented on 2019-10-23 23:00 (UTC)

@ZaZam Because upstream hasn't released a new version yet.

@jghodd This package is not out of date. The PKGBUILD version is identical with upstream. True, it doesn't work with the current version of pacman, but that relates to upstream, not this PKGBUILD. You can follow the bug report here [a].

In any case, I've temporarily added the patch that makes kalu(-kde) compatible in the meantime, until upstream updates.


ZaZam commented on 2019-10-23 18:05 (UTC)

Why does this depend on pacman version lower than 5.2?

Rhinoceros commented on 2018-06-06 12:31 (UTC)

@pcmoore I'm not really sure, because I don't use that part of it. Perhaps you could report it upstream? I'd probably test with vanilla kalu too, so it's simpler for upstream to find the bug.

pcmoore commented on 2018-06-06 12:19 (UTC)

Thanks for the update, but I'm having problem when running the graphical updater application:

Error: Could not initiate kalu_updater: Error calling StartServiceByName for org.jjk.kalu: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 127


Rhinoceros commented on 2018-06-05 21:42 (UTC)

@lpc123 Thank you, but I'm afraid you'll have to be more specific. What exactly is the problem?

lpc123 commented on 2018-06-05 21:26 (UTC)

I appreciate the work on this package, but sorry, no luck here with installing 4.3.0-1.

Rhinoceros commented on 2018-05-29 21:53 (UTC)

Thanks @jghodd. I've pinned your comment.

jghodd commented on 2018-05-29 18:38 (UTC)

@Rhinoceros - it seems to be "working" ok with a rebuild, but the progress indicators are showing "-2147483648% of 0 B" during downloads. definitely something needs to be fixed.

Rhinoceros commented on 2018-05-29 10:24 (UTC)

I realise that this package is currently pinned to pacman<5.1, so it's blocking pacman -Syu. However, upstream hasn't addressed this yet. I'll update this package when upstream has a response. In the meantime, I manually removed the restriction from the PKGBUILD, then rebuilt, and it seems to work okay. I won't commit the change yet until I see what upstream does.

Rhinoceros commented on 2018-02-11 22:42 (UTC)

@Potomac Honestly, I don't know. The kalu-kde package is based on kalu [a], except it enables the status notifier. The kalu package also plays with permissions. This is packaged by jjacky, who created the upstream program itself. If you wanted to chase this up, perhaps you could comment on that page?


Potomac commented on 2018-02-11 20:37 (UTC)

Why do you use "chmod" and "chown" commands in PKGBUILD and karu.install files ?

I see also that you have created a new group called "kalu",

it would be interesting to avoid these commands, kalu should be able to run with the current user and existing permissions for /usr/share/polkit-1/rules.d

Rhinoceros commented on 2017-03-13 21:24 (UTC)

@Lysio This should be fixed now.

Rhinoceros commented on 2017-03-12 00:17 (UTC)

@Lysio Yes, I'm getting errors too. Seems to be related to the updated statusnotifier.

Lysio commented on 2017-03-11 13:18 (UTC)

Hello, There is a mistake in the build of this package. I can't install it. Please check

Rhinoceros commented on 2016-07-29 08:59 (UTC)

@fheday Thank you. Do you mean the built-in-upgrader? I don't actually use it, so I can't really comment. You can always create a KDE Plasma window rule for it as a workaround. This package is identical to the "standard" kalu, but built with `--enable-status-notifier`, as recommended by upstream. You should just report bugs there:

fheday commented on 2016-07-29 08:46 (UTC)

Great package. However, the update packages window never shows on top of other windows. Not sure if this is only in kde.

Rhinoceros commented on 2016-03-17 21:07 (UTC)

@jghodd Great, thanks for reporting that!

jghodd commented on 2016-03-17 19:50 (UTC)

@Rhinoceros A fix has been made. Not sure how long before it's officially available, but heads-up...

jghodd commented on 2016-03-14 22:27 (UTC)

@Rhinoceros - thanks, bud. I'll do that. I'm sure it's not a packaging issue. Looks like the line "dl_done = (cur_size + tot_size == dl_size);" from updater.c isn't computing correctly when a retry+resume occurs during the download.

Rhinoceros commented on 2016-03-14 22:24 (UTC)

@jghodd I'm not exactly sure what you mean; I don't use the bundled updater. However, you'd want to file this bug upstream [1]. This PKGBUILD is almost identical to the "official" non-KDE version (`kalu`), just compiled with one additional flag and related dependency. So any issues with kalu-kde are probably not introduced by the package per se. Upstream is very prompt and attentive, and I'm sure they'd be happy to address any issue you file. [1]

jghodd commented on 2016-03-14 21:47 (UTC)

Just a minor bug, but thought I'd give you a heads-up. If a download times out and retries, kalu fails to mark the download blue when complete. Works fine if the download completes without a timeout.

Rhinoceros commented on 2016-02-29 20:55 (UTC)

Thanks, done.

AnAkkk commented on 2016-02-29 15:46 (UTC)

It now says that all local AUR packages have not been found, you need to pass to configure: --with-url-aur-prefix=''

Rhinoceros commented on 2016-02-01 22:41 (UTC)

I was waiting for upstream to merge the pacman-5 branch, and tag a new release [1], but they did that a few hours ago, so I've updated the PKGBUILD. [1]

jghodd commented on 2016-02-01 17:33 (UTC)

The current '-1' version is running into an issue with the latest update of pacman to v5.0. The 'pacman<4.3' dependency is causing the problem. Package-query had the same issue, which was resolved by simply removing that dependency from the PKGBUILD file.