Hi, Background: I run KDE, so no full Gnome environment is installed on my machine despite some Gnome-based tools. Among those tools is gnome-keyring. I need to access the secret data in the keyrings from python using the bindings provided by the gnome-keyring-python package. Issue: On my KDE / non-Gnome environment, emerging gnome-keyring-python does not build the corresponding Python bindings because configure detects missing dependencies. From config.log: [...] configure:14533: checking for GNOMEKEYRING configure:14541: $PKG_CONFIG --exists --print-errors "gnome-keyring-1 >= 0.5.0 gobject-2.0 >= 2.6.0" Package gnome-keyring-1 was not found in the pkg-config search path. Perhaps you should add the directory containing `gnome-keyring-1.pc' to the PKG_CONFIG_PATH environment variable No package 'gnome-keyring-1' found configure:14545: $? = 1 configure:14560: $PKG_CONFIG --exists --print-errors "gnome-keyring-1 >= 0.5.0 gobject-2.0 >= 2.6.0" Package gnome-keyring-1 was not found in the pkg-config search path. Perhaps you should add the directory containing `gnome-keyring-1.pc' to the PKG_CONFIG_PATH environment variable No package 'gnome-keyring-1' found configure:14564: $? = 1 configure:14578: result: no No package 'gnome-keyring-1' found [...] Reproducible: Always Solution: The issue can be resolved by emerging libgnome-keyring which provides the missing file 'gnome-keyring-1.pc'. Hence, libgnome-keyring should be a build-time dependency of gnome-keyring-python. Georg
Looks like gnome-keyring-python wrongly depends on >=gnome-keyring-0.5 instead of >=libgnome-keyring-0.5 That said, you should NOT use gnome-keyring-python for newly written code. libgnome-keyring and those python bindings are deprecated upstream. You should look into libsecret[introspection] instead, as follows: import gi gi.require_version('Secret', '1') from gi.repository import Secret and then use the libsecret API via "Secret" module. Documentation here: https://lazka.github.io/pgi-docs/#Secret-1 Looking at the C docs might be useful too: https://developer.gnome.org/libsecret/unstable/ That said, this bug is probably valid, in terms of what I mentioned at the start. Just we might want to last rite instead of fixing :)
Hi Mart, thanks for pointing out that gnome-keyring-python is deprecated and pointing me into the right direction of a newer lib. I'll take a look at that. Best regards Georg
CI check in "See Also". Will see based on it (once the hamsters are done) if can last rite soon, or should fix the dep up for the time being.
dev-python/gnome-keyring-python is required by bzr-gtk (that could probably be dropped too) and *optionally* by gajim (use.masking or dropping its gnome-keyring USE flag would be enough)
we can do treecleaning ourselves if and when appropriate. There is no need for treecleaner@ to be CC'ed, especially with some of them taking this CC fact as some sort of a go-ahead when it's not.
Why we cannot proceed with this?
In this case gajim is really the only reverse dep, and it's an optional feature
My idea was simply to ensure that, if we don't treeclean this in gnome side soon, and I got it on next treecleaner round, I could go ahead and handle all the stuff myself. That would also help to starting getting rid of the old gnome2 python bindings (at least starting by this one that looks easy to handle currently as has few reverse deps finally)
I'm not saying we can't clean this; I'm saying we as GNOME team want to look at it and do so; together with whatever other old bindings we can do, not have treecleaners jump the gun (and I don't have you personally in mind). "See Also" field has a CI check report on the other gnome2 python bindings - maybe you can find from there what else we can clean soon together with this. Also keep in mind this gnome-keyring-python is actually a split package out of many from the same tarball, so cleaning this alone doesn't even remove the tarballs from distfile mirrors or anything. Another thing I don't like about treecleaners is that when they remove the package after last rites, they immediately remove the p.mask entry as well. This is not good, the p.mask entry should stick around a couple months longer, as package managers don't tell anything about stale packages installed to their systems without ebuilds in tree, unless there's a p.mask.
Yeah, I saw the See Also field, but it looked to me that we were still too far from being able to treeclean all (specially gnome-vfs and gconf stuff is hard to be killed soon), that was the reason for me to at least start killing this (and the packages that can be killed at present time). That way we also prevent people from adding new packages easily depending on it in the future (it happens from time to time :S) and also people won't expect us to take care of its bugs.
(In reply to Mart Raudsepp from comment #9) [...] > Another thing I don't like about treecleaners is that when they remove the > package after last rites, they immediately remove the p.mask entry as well. > This is not good, the p.mask entry should stick around a couple months > longer, as package managers don't tell anything about stale packages > installed to their systems without ebuilds in tree, unless there's a p.mask. Regarding this, well, we are doing that in treecleaners since... forever? But not only in treecleaners, but most people do it, probably to not have lots of obsolete entries in package.mask I see your point but I think maybe it would be better to bring that to gentoo-dev ML as a more general policy (I mean, for all people and not only targeting treecleaners) for package removals and with a concrete timeout to drop the mask message (3 additional months?). Maybe even the script generating https://qa-reports.gentoo.org/output/invalid-mask.txt could be used (or improved if someone knows who is taking care of it) to show easily the entries older than 3 months to be removed completely.
*** Bug 677064 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=67faffb15bfa371feadd132c45cf88e12aa4fac7 commit 67faffb15bfa371feadd132c45cf88e12aa4fac7 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2019-10-19 20:42:45 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2019-10-21 19:40:45 +0000 profiles: Mask dev-python/gnome-keyring-python for removal Bug: https://bugs.gentoo.org/628938 Signed-off-by: Matt Turner <mattst88@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=24c1fa75d34743c14c5b55fccf86024fdbf7dbc2 commit 24c1fa75d34743c14c5b55fccf86024fdbf7dbc2 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2019-11-26 03:15:19 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2019-11-26 03:16:32 +0000 dev-python/gnome-keyring-python: Remove Closes: https://bugs.gentoo.org/628938 Signed-off-by: Matt Turner <mattst88@gentoo.org> dev-python/gnome-keyring-python/Manifest | 1 - .../gnome-keyring-python-2.32.0-r1.ebuild | 22 ---------------------- dev-python/gnome-keyring-python/metadata.xml | 8 -------- profiles/package.mask | 5 ----- 4 files changed, 36 deletions(-)
