Arch Linux User Repository

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.

@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.

@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...)

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.)

@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?

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

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

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.

@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.

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

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

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: https://github.com/Thulinma/kalu#readme

Great! Thanks again!

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

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!

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

@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!

@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:

source=(git+https://github.com/Thulinma/kalu.git)

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

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.

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

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

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

And I used this source:

source=(git+https://github.com/Thulinma/kalu.git#branch=next)

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.

@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 jjacky.com, 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?

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.

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: https://github.com/Thulinma/kalu/commits/next

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.

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

@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.

@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 - https://sourceforge.net/projects/bluestarlinux/files/extra/kalu-kde/alpm12/kalu-kde/

@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 https://sourceforge.net/projects/bluestarlinux/files/extra/kalu-kde/alpm12/kalu-kde/

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: https://github.com/jghodd/alpm12 - 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) - https://sourceforge.net/projects/bluestarlinux/files/extra/kalu-kde/alpm12/alpm12/ - 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 libalpm12.so.12.0.2 instead of having to rename libalpm.so.12.0.2. 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 https://sourceforge.net/projects/bluestarlinux/files/extra/kalu-kde/alpm12/alpm12

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.

@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.

OK. https://sourceforge.net/projects/bluestarlinux/files/extra/kalu-kde/

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 libalpm12.so.12.0.2 library, please go for it, and remember to change the PKGBUILD accordingly (at the moment, i build libalpm.so.12.0.2 and rename it via the PKGBUILD).

@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.

@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 libalpm.so.12 and libalpm.so.12.0.2, 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.

@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.

@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.

@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.

@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:

ALPM_EVENT_PKGDOWNLOAD_START -> ALPM_EVENT_PKG_RETRIEVE_START ALPM_EVENT_PKGDOWNLOAD_DONE -> ALPM_EVENT_PKG_RETRIEVE_DONE ALPM_EVENT_PKGDOWNLOAD_FAILED -> ALPM_EVENT_PKG_RETRIEVE_FAILED

these 3 have no equivalent:

ALPM_EVENT_RETRIEVE_START ALPM_EVENT_RETRIEVE_DONE ALPM_EVENT_RETRIEVE_FAILED

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:

• ALPM_EVENT_RETRIEVE_ -> ALPM_EVENT_DB_RETRIEVE_

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.

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.

@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.

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

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..?

@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).

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

pacman 6.0 :-(

@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.

$ 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

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

@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 = https://jjacky.com/kalu
    install = kalu.install
    arch = i686
@@ -22,9 +22,11 @@ pkgbase = kalu-kde
    conflicts = kalu
    source = http://jjacky.com/kalu/kalu-4.3.0.tar.xz
    source = statusnotifier.patch
+   source = gcc10.patch
    source = https://github.com/deraffe/kalu/commit/a46975cdcb926ea8508c012d333471c1e1cb8529.patch
    sha1sums = 4e9fc8b311077d3720af8619de04c917c01acbfb
    sha1sums = d58712ff827df6bea9c5eb5a7e3d9034f3cac506
+   sha1sums = 6e02682594c169561fbadbde635053cf47e3a2f1
    sha1sums = 6418c6df072de666873e37240bddb33712ae4aac

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

 pkgname=kalu-kde
 pkgver=4.3.0
-pkgrel=2
+pkgrel=3
 pkgdesc="Upgrade notifier w/ AUR support, watched (AUR) packages, news; supports autohide in KDE Plasma's panel"
 arch=('i686' 'x86_64')
 url="https://jjacky.com/kalu"
@@ -13,10 +13,12 @@ depends=('dbus' 'polkit' 'gtk3' 'pacman>=5.2' 'pacman<5.3' 'curl' 'libnotify'
 makedepends=('perl' 'groff')
 source=(http://jjacky.com/${pkgname%-kde}/${pkgname%-kde}-$pkgver.tar.xz
         statusnotifier.patch
+        gcc10.patch
         https://github.com/deraffe/kalu/commit/a46975cdcb926ea8508c012d333471c1e1cb8529.patch)
 install=kalu.install
 sha1sums=('4e9fc8b311077d3720af8619de04c917c01acbfb'
           'd58712ff827df6bea9c5eb5a7e3d9034f3cac506'
+          '6e02682594c169561fbadbde635053cf47e3a2f1'
           '6418c6df072de666873e37240bddb33712ae4aac')
 provides=(${pkgname%-kde})
 conflicts=(${pkgname%-kde})
@@ -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 {
+     TPL_SCE_UNDEFINED = 0,
+@@ -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;

@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.

[a] https://github.com/jjk-jacky/kalu/issues/73

Why does this depend on pacman version lower than 5.2?

@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.

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

Help?

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

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

Thanks @jghodd. I've pinned your comment.

@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.

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.

@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?

[a] https://aur.archlinux.org/packages/kalu/

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