webkit-patch is no longer able to look up my Bugzilla password from the system keyring, instead prompting me to enter my password each time. I don't know why yet... probably related to r271506, but I need to investigate more.
Debug patch: diff --git a/Tools/Scripts/webkitpy/common/net/credentials.py b/Tools/Scripts/webkitpy/common/net/credentials.py index ef98ee15b3c4..c8781e5d5232 100644 --- a/Tools/Scripts/webkitpy/common/net/credentials.py +++ b/Tools/Scripts/webkitpy/common/net/credentials.py @@ -161,8 +161,8 @@ class Credentials(object): if username and not password and self._keyring and use_stored_credentials: try: password = self._keyring.get_password(self.host, username) - except: - pass + except Exception as e: + print('failed to get password from keyring: {}'.format(str(e))) if not password: password = user.prompt_password("%s password for %s: " % (self.host, username)) It prints: $ webkit-patch upload 220736 Total errors found: 0 in 1 files failed to get password from keyring: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. bugs.webkit.org password for mcatanzaro@gnome.org: So somehow python-keyring is no longer able to use python-secretservice, which is bad.
> So somehow python-keyring is no longer able to use python-secretservice, > which is bad. Er, it's called python-secretstorage. That is required for system keyring integration on Linux. Historically, our autoinstalled python-keyring has been able to use the system copy of python-secretstorage. Maybe the updated version is not? Anyway, if I revert to our previous version of python-keyring, the bug disappears. The bug also goes away if I upgrade to the latest stable version of python-keyring. I'm not sure why exactly version 18.0.1 was selected, but it seems to be a bad version. CC: Jonathan in case this particular version was selected for some important reason.
Created attachment 417891 [details] Patch
Comment on attachment 417891 [details] Patch OK, webkitpy EWS is red. I didn't realize we still support python2. The new version of python-keyring does not support python2. So I need to find an older version that still supports python2, is new enough for the GitHub code to work, and doesn't exhibit this secretstorage bug. Hi Jonathan, can you comment regarding why you upgraded python-keyring? I assume you needed a newer version of the library for... something? What exactly was required? Then I'm not sure what is wrong with the python3 test. ModuleNotFoundError: No module named 'monotonic' immediately after installing python-monotonic. Hm.
(In reply to Michael Catanzaro from comment #2) > I'm not sure why exactly version 18.0.1 was selected This was simply the last version to support python2.
Created attachment 417893 [details] Patch
Created attachment 417894 [details] Patch
Created attachment 417895 [details] Patch
(In reply to Michael Catanzaro from comment #2) > I'm not sure why exactly version 18.0.1 was selected, but > it seems to be a bad version. It seems versions 12 is the first version that is broken. So version 11 is the last version that supports python2 and works properly on Linux. I wonder if this is new enough for Jonathan's GitHub support that landed in r271506.
Created attachment 417897 [details] Patch
webkitpy bot is green. Jonathan, can you please check to ensure I haven't broken your GitHub credentials work?
(In reply to Michael Catanzaro from comment #11) > webkitpy bot is green. Jonathan, can you please check to ensure I haven't > broken your GitHub credentials work? I didn't need to update the library, I assumed (erroneously, clearly), that a newer version would be better. Before we land this change, I'd like to land another change that will help some of our bots out, because otherwise changing the library version on them will require manual intervention. Is it Ok if this change waits a few hours before landing?
Sure. I can't land it now anyway, since commit-queue is taking the day off, and I don't have an SVN account anymore. If you could give r+ when you're ready, that would be great.
(In reply to Michael Catanzaro from comment #13) > Sure. I can't land it now anyway, since commit-queue is taking the day off, > and I don't have an SVN account anymore. yeah, that's the other thing I'm working on right now :) > > If you could give r+ when you're ready, that would be great.
Comment on attachment 417897 [details] Patch Marking this cq- right now so no one accidentally commits it before our infrastructure is ready, in particular, we need https://bugs.webkit.org/show_bug.cgi?id=220744 first.
Committed r271634: <https://trac.webkit.org/changeset/271634> All reviewed patches have been landed. Closing bug and clearing flags on attachment 417897 [details].
<rdar://problem/73382360>
Still borken BTW, when running webkit-patch in the Flatpak SDK runtime...
(In reply to Philippe Normand from comment #18) > Still borken BTW, when running webkit-patch in the Flatpak SDK runtime... What exactly does broken mean in this case? Seems likely it's something about keyring being unable to find some sort of key store.
(In reply to Jonathan Bedard from comment #19) > What exactly does broken mean in this case? Seems likely it's something > about keyring being unable to find some sort of key store. Yup, the problem is python-keyring is totally unable to find the system keyring. It's as if it thinks the system keyring doesn't exist. I did not debug it to figure out why, since the problem I was hitting was definitely fixed in the latest version.
(In reply to Michael Catanzaro from comment #1) > $ webkit-patch upload 220736 > Total errors found: 0 in 1 files > failed to get password from keyring: No recommended backend was available. > Install a recommended 3rd party backend package; or, install the > keyrings.alt package if you want to use the non-recommended backends. See > https://pypi.org/project/keyring for details. > bugs.webkit.org password for mcatanzaro@gnome.org: Looks like it's failing to discover its own backends. It's supposed to use python-secretstorage to talk to gnome-keyring via libsecret, but for whatever reason it doesn't realize python-secretstorage is installed.
I had this error: failed to get password from keyring: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details.
(In reply to Philippe Normand from comment #22) > I had this error: > > failed to get password from keyring: No recommended backend was available. > Install a recommended 3rd party backend package; or, install the > keyrings.alt package if you want to use the non-recommended backends. See > https://pypi.org/project/keyring for details. Oh, I wonder if it checks for the module instead of importing it, which would by-pass our auto-install clever-ness....or the "if sys.platform == 'linux':" is false in webkitscmpy's __init__.py