Package Details: kpcli 4.0-1

Git Clone URL: https://aur.archlinux.org/kpcli.git (read-only, click to copy)
Package Base: kpcli
Description: Command line browser of KeePassX database files (*.kdb)
Upstream URL: http://sourceforge.net/projects/kpcli/
Licenses: GPL, PerlArtistic
Submitter: gauthma
Maintainer: SammyPoot
Last Packager: SammyPoot
Votes: 55
Popularity: 0.000003
First Submitted: 2011-01-03 00:41 (UTC)
Last Updated: 2024-03-05 23:27 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

SammyPoot commented on 2020-05-04 15:57 (UTC)

@banana1 All done! Thanks for the heads up on the update. I've also hopefully fixed the problem with the README file not redownloading automatically, too.

banana1 commented on 2020-05-04 09:48 (UTC)

Hi. Release 3.4 of kpcli is out since 2020-04-25. Maybe it could also come here. Thanks and regards.

SammyPoot commented on 2020-02-20 13:40 (UTC)

Ah, no harm done! I'm glad you managed to fix it. I'm not sure if this means that I've messed something up - I had assumed it'd pull down a new README - but I'll have a look.

No problem!

saviola commented on 2020-02-20 12:09 (UTC)

My apologies, as usual the solution pops up as soon as I have asked the question (openly), it seems to have been a pacman caching problem of some sorts, after running yay -Sc it validated properly. Previously I only checked the yay buildDir, maybe passing --redownload would have worked – I guess I was stuck with a broken README back from when the Sourceforge disaster recovery was active?

Still, thanks for your (still pretty quick, imo) answer!

SammyPoot commented on 2020-02-20 11:20 (UTC)

I'm a bit confused, @saviola

I'm installing the package through the helper Yay, which appears to be handling it correctly. I've done a full re-install of the package, just to be sure, and it validates properly.

Could you tell me which package manager this is happening with? I'll try and replicate the problem.

Sorry for the slight delay in answering.

saviola commented on 2020-02-19 08:13 (UTC) (edited on 2020-02-19 09:32 (UTC) by saviola)

For the last several months (since the last update, I guess), the 3.3-1 update fails to install for me, because the README fails the validity check. When I manually download the README from https://iweb.dl.sourceforge.net/project/kpcli/README and run sha256sum, it shows the correct checksum though.

I am using the yay AUR helper. Since kpcli is the only package where something like this has happened I first wanted to ask here if anyone has an idea (or anyone is also using yay and it works for them) what the issue might be and if this could be a problem on my end somehow, before I raise this issue on the yay repository.

jasondaigo commented on 2019-06-15 21:55 (UTC)

thank you very much for advice. installing perl-crypt-rijndael once more works like a charm <3

SammyPoot commented on 2019-06-15 16:15 (UTC)

Hi, @jasondaigo.

Perl has updated to 5.30, but a few AUR packages haven't been re-compiled into the correct directory. pacman -Qqo '/usr/lib/perl5/5.28' will tell you which packages still have files in the old directory - assuming it's the same as my last version. There should be a Pacman hook that warns you about them.

You'll have to reinstall perl-crypt-rijndael and the other outdated packages.

Alternatively, you can install Crypt::Rindael through cpan as a temporary workaround.

jasondaigo commented on 2019-06-15 15:46 (UTC) (edited on 2019-06-15 15:46 (UTC) by jasondaigo)

doesnt work anymore aftzer some base package unpdated.error is:
Can't locate Crypt/Rijndael.pm in @INC (you may need to install the Crypt::Rijndael module) (@INC contains: /usr/lib/perl5/5.30/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/5.30/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/5.30/core_perl /usr/share/perl5/core_perl) at /usr/bin/kpcli line 38. BEGIN failed--compilation aborted at /usr/bin/kpcli line 38.

<deleted-account> commented on 2019-04-04 11:39 (UTC)

Hello, @heichblatt

seems the disaster has been recovered, but the "kent" mirror is not there.

Please update the sources to https://datapacket.dl.source.... (or a different mirror) and it will work again, thanks.

(Also, the README file can have https too now.)