#1 Update to 4.0.6
Merged 10 months ago by music. Opened 10 months ago by music.
rpms/ music/python-pykeepass v4.0.6  into  rawhide

file modified
@@ -7,3 +7,4 @@ 




+ /pykeepass-4.0.6.tar.gz

file modified
+2 -2
@@ -1,5 +1,5 @@ 

  Name:           python-pykeepass

- Version:        4.0.5

+ Version:        4.0.6

  Release:        %autorelease

  Epoch:          1

  Summary:        Python library to interact with keepass databases
@@ -30,7 +30,7 @@ 




- %autosetup -n pykeepass-%{version} -p1

+ %autosetup -n pykeepass-%{version}


  # Convert exact-version pins, which we cannot respect, to lower bounds.

  sed -r -i 's/==/>=/' requirements.txt

file modified
+1 -1
@@ -1,1 +1,1 @@ 

- SHA512 (pykeepass-4.0.5.tar.gz) = d3c079c631fd91a06e376c29a771f2c28a776206ef01c89043b9d5fe2b8cbe071da32a6ae2cb68f8beede4110717cfef63ecc49313ca023c2d79a235b0e0b273

+ SHA512 (pykeepass-4.0.6.tar.gz) = 43f31c1b07dd28afe13fcd58f9e34419338219a46dbaf7c018ba747f1ed1ca4b97d96559e390665bac549f54ac525ebdc075e49abbcd049dec4bd367c393da25

This upstream release simply drops Python 2 support, removing the dependency on python-future. It can be an enhancement update for all releases.


Pull-Request has been merged by music

10 months ago

JFYI: pykeepass required only for secrets app and there is major issues could happened with updating pykeepass in Fedora. Major issues already happened because of that: 1, 2. Upstream unhappy about non-flatpak (Flathub) official build.

What do you think is the right way to maintain pykeepass, then?

Currently, I review the source diff for obvious breaking changes and check that secrets builds from source before updating it. It’s not clear that this would have caught 1, though, especially since the tests are now disabled in secrets.

If I continue to maintain this package, I want to keep it up to date at least in Rawhide, as long as there are no known or obvious incompatibilities. However:

  • I’m happy to transfer python-pykeepass back to you if you’d rather be responsible for it. I picked it up after it was orphaned and don’t have a strong personal interest in it.
  • I could orphan it if you don’t want to maintain secrets anymore either.
  • I could follow a manual test process with secrets, but I don’t want to be responsible for figuring out what it should be.
  • I could update this package in Rawhide only, even for patch releases, hoping that you or someone else will discover any incompatibilities before it reaches a stable release.

Any ideas? Thanks for your input.

As a follow-up to the comment about tests being disabled in secrets, I just tried to get them running again using https://gitlab.gnome.org/World/secrets/-/issues/471#note_1774038, and it worked in that the test suite executes instead of bailing out with ImportError: cannot import name 'const' from 'gsecrets' (unknown location). However, test_element.py fails with killed by signal 5 SIGTRAP.

I think updating pykeepass every new release for Rawhide is OK and good idea. At least once per 6 month Secrets have a new version. Upstream not against non-flathub builds entirely so i just warned you about specifics and pykeepasssecrets. Thanks for help maintain it!