Arch Linux User Repository

Hope this gets updated for the latest pacman version. I made this bash script in the meantime if anyone cares (requires pacman-contrib, can't check AUR, change inside if statement if you don't use libnotify and replace username and maybe ID if it isn't 1000, I am releasing it as CC0 i.e public domain):

https://paste.dimdev.org/ukuvivoguz.bash

Kalu is broken with pacman 5.2.0: https://github.com/jjk-jacky/kalu/issues/73

@Th30 - its not completely incompatible. in fact, most of it works just fine if you adjust the 'pacman<5.1' dependency to 'pacman<5.2' instead. what's not working at some level is the percentage downloaded and the total size - but not throughout the app. the download progress bar is incrementing correctly and it knows when a download is complete and when all downloads are complete, so those values are correct at some level of the code. it will still perform updates and notifications correctly, even though you may be seeing some specious values being displayed in the text overlays.

kalu 4.2.0-1 is incompatible with pacman 5.1.0-1

No, I believe the issue was due to changes in the download callback from ALPM (and the fact that it can now use -1 as total, whereas in kalu we're using that value as unsigned int, hence the issue). Anyhow, unless I missed something it seems that the changes in dl callback was the only issue re: 5.1; Just pushed a branch pacman-5.1 on github for anyhow who'd like to try.

Let me know how it you catch anything wrong,

@jjacky - part of the issue seems to be in the function rend_pbar_pb. interestingly, your call to gtk_tree_model_get with the UCOL_PCTG parameter is working properly since the progress bar is rendering correctly for the percentage downloaded. however, the "if (is_dl)" code block with your next call to gtk_tree_model_get with the UCOL_CUR_DL_SIZE parameter is broken somehow. you're using the same value in the overlay status that you used for rendering the progress bar, but now it appears as -2147483648 (0x80000000). unit is correct-ish, and dl_size returned for UCOL_CUR_DL_SIZE, and then massaged, is coming up 0. any ideas? it would take me a while to fully wrap my head around your code, but i'm hoping maybe you could point me in the right direction.

@jjacky - 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. otherwise, except that the upper progress indicators are thrown off by the weird size values, everything else is still working as expected. this issue doesn;t appear to affect upgrades. i'd guess that whatever function call gets the percent downloaded and the size of the download has changed. internally, kalu still knows the real size of the download.

This is what makes SemVer etc so useless in practice... A minor version breaks everything and it seems no one really cares anyway...

It's not your fault I just get so frustrated in general with stuff like this.

When do you think you can have a new version out?

No, this restriction is by design, because such a version change in pacman (usually) comes with API change/breakage (in ALPM) and thus requires an update upstream (Notice the soname bump in libalpm).

This is the same for all ALPM-based software (including pacman really, it just happens to be shipped alongside libalpm), and can't be avoided. (For some it might, in that a simple rebuild could be enough, depending on how/the extent to which they use ALPM, but kalu usually requires work.) Note that there's also no need to flag this package out of date: it isn't, as there's no new release (of kalu) as of yet.

For now you need to either remove kalu, or postpone the sysupgrade until a new release for pacman 5.1 compatibility is out. I need to work on this, unfortunately haven't had the time yet... Apologies.