Can somebody please reopen and appropriately mark the following bug for EPEL7, so it doesn't get auto-closed on new Fedora releases? Thanks.
On Fri, Aug 19, 2016 at 12:18 PM, Christopher ctubbsii@fedoraproject.org wrote:
Can somebody please reopen and appropriately mark the following bug for EPEL7, so it doesn't get auto-closed on new Fedora releases? Thanks.
When product is changed to Fedora EPEL, there is no gnome-desktop component option. Only gnome-desktop-sharp. There's also gnome-common.
On Saturday, 20 August 2016 at 01:30, Chris Murphy wrote:
On Fri, Aug 19, 2016 at 12:18 PM, Christopher ctubbsii@fedoraproject.org wrote:
Can somebody please reopen and appropriately mark the following bug for EPEL7, so it doesn't get auto-closed on new Fedora releases? Thanks.
When product is changed to Fedora EPEL, there is no gnome-desktop component option. Only gnome-desktop-sharp. There's also gnome-common.
As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1164414#c2 , gnome-desktop exists in RHEL7/CentOS7 as gnome-desktop3. The report is invalid and should be closed as such.
Regards, Dominik
On Fri, Aug 19, 2016 at 5:37 PM, Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Saturday, 20 August 2016 at 01:30, Chris Murphy wrote:
On Fri, Aug 19, 2016 at 12:18 PM, Christopher ctubbsii@fedoraproject.org wrote:
Can somebody please reopen and appropriately mark the following bug for EPEL7, so it doesn't get auto-closed on new Fedora releases? Thanks.
When product is changed to Fedora EPEL, there is no gnome-desktop component option. Only gnome-desktop-sharp. There's also gnome-common.
As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1164414#c2 , gnome-desktop exists in RHEL7/CentOS7 as gnome-desktop3. The report is invalid and should be closed as such.
Ahh OK, so notabug? Invalid is not an option.
Chris Murphy
On Fri, Aug 19, 2016 at 7:41 PM Chris Murphy lists@colorremedies.com wrote:
On Fri, Aug 19, 2016 at 5:37 PM, Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Saturday, 20 August 2016 at 01:30, Chris Murphy wrote:
On Fri, Aug 19, 2016 at 12:18 PM, Christopher ctubbsii@fedoraproject.org wrote:
Can somebody please reopen and appropriately mark the following bug
for
EPEL7, so it doesn't get auto-closed on new Fedora releases? Thanks.
When product is changed to Fedora EPEL, there is no gnome-desktop component option. Only gnome-desktop-sharp. There's also gnome-common.
As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1164414#c2 , gnome-desktop exists in RHEL7/CentOS7 as gnome-desktop3. The report is invalid and should be closed as such.
Ahh OK, so notabug? Invalid is not an option.
Ah, my mistake. I was under the impression that it was missing, because related to gnome-python2-desktop ( https://bugzilla.redhat.com/show_bug.cgi?id=1177390) which contains gnome-python2-gnomekeyring. Maybe gnome-python2-desktop can be built with gnome-desktop3? Not sure I understand GNOME packaging interdependencies yet, but I miss my old python keyring library.
On Sat, 2016-08-20 at 02:07 +0000, Christopher wrote:
Ah, my mistake. I was under the impression that it was missing, because related to gnome-python2-desktop ( https://bugzilla.redhat.com/show_bug.cgi?id=1177390) which contains gnome-python2-gnomekeyring. Maybe gnome-python2-desktop can be built with gnome-desktop3? Not sure I understand GNOME packaging interdependencies yet, but I miss my old python keyring library.
Hi,
I'd never heard of it before now, but I looked into it briefly out of curiosity. Turns out gnome-python2-desktop (called gnome-python-desktop upstream) contains old-style manual Python bindings to various old GNOME 2 stuff. These have all been obsoleted for a very long time by PyGObject; the upstream git repo was archived five years ago. It's totally unrelated to gnome-desktop3 (called gnome-desktop upstream), which is an important GNOME module that just happens to have a confusingly-similar name.
gnome-python2-gnomekeyring in particular contains old bindings for the gnome-keyring library, which is also long deprecated. The modern way to access the keyring is to use libsecret via PyGObject:
https://lazka.github.io/pgi-docs/#Secret-1
Michael
On Sat, Aug 20, 2016 at 8:16 AM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Sat, 2016-08-20 at 02:07 +0000, Christopher wrote:
Ah, my mistake. I was under the impression that it was missing, because related to gnome-python2-desktop ( https://bugzilla.redhat.com/show_bug.cgi?id=1177390) which contains gnome-python2-gnomekeyring. Maybe gnome-python2-desktop can be built with gnome-desktop3? Not sure I understand GNOME packaging interdependencies yet, but I miss my old python keyring library.
Hi,
I'd never heard of it before now, but I looked into it briefly out of curiosity. Turns out gnome-python2-desktop (called gnome-python-desktop upstream) contains old-style manual Python bindings to various old GNOME 2 stuff. These have all been obsoleted for a very long time by PyGObject; the upstream git repo was archived five years ago. It's totally unrelated to gnome-desktop3 (called gnome-desktop upstream), which is an important GNOME module that just happens to have a confusingly-similar name.
gnome-python2-gnomekeyring in particular contains old bindings for the gnome-keyring library, which is also long deprecated. The modern way to access the keyring is to use libsecret via PyGObject:
https://lazka.github.io/pgi-docs/#Secret-1
Michael
libsecret won't work. It's a higher level abstraction and I need to look at the GnomeKeyring attributes directly. You can do this with the old gnome-python2-gnomekeyring library, but the new GnomeKeyring (python-gobject/python3-gobject) returns a GLib.Array object for the attribute list, and I can't figure out any way to inspect the attributes from that in python (and it looks like I'm not the only one[1]).
On Sun, Aug 21, 2016 at 1:49 AM Christopher ctubbsii@fedoraproject.org wrote:
On Sat, Aug 20, 2016 at 8:16 AM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Sat, 2016-08-20 at 02:07 +0000, Christopher wrote:
Ah, my mistake. I was under the impression that it was missing, because related to gnome-python2-desktop ( https://bugzilla.redhat.com/show_bug.cgi?id=1177390) which contains gnome-python2-gnomekeyring. Maybe gnome-python2-desktop can be built with gnome-desktop3? Not sure I understand GNOME packaging interdependencies yet, but I miss my old python keyring library.
Hi,
I'd never heard of it before now, but I looked into it briefly out of curiosity. Turns out gnome-python2-desktop (called gnome-python-desktop upstream) contains old-style manual Python bindings to various old GNOME 2 stuff. These have all been obsoleted for a very long time by PyGObject; the upstream git repo was archived five years ago. It's totally unrelated to gnome-desktop3 (called gnome-desktop upstream), which is an important GNOME module that just happens to have a confusingly-similar name.
gnome-python2-gnomekeyring in particular contains old bindings for the gnome-keyring library, which is also long deprecated. The modern way to access the keyring is to use libsecret via PyGObject:
https://lazka.github.io/pgi-docs/#Secret-1
Michael
libsecret won't work. It's a higher level abstraction and I need to look at the GnomeKeyring attributes directly. You can do this with the old gnome-python2-gnomekeyring library, but the new GnomeKeyring (python-gobject/python3-gobject) returns a GLib.Array object for the attribute list, and I can't figure out any way to inspect the attributes from that in python (and it looks like I'm not the only one[1]).
I don't suppose anybody here knows how to read the GArray in python to get the attributes list for a keyring item in GnomeKeyring?
devel@lists.stg.fedoraproject.org
-
Chris Murphy -
Christopher -
Dominik 'Rathann' Mierzejewski -
Michael Catanzaro