Error while saving password in preferences

[BHSPitMonkey]

trafficstars

(This happened using the current Stable version released yesterday on Flathub, 6cea8f0c.)

At some point this week, Pithos seemed to forget my Pandora password and would simply do nothing when launched (the UI opens, but with no songs/stations and without displaying the Preferences window).

To fix this, I opened up the Preferences window and re-entered my password. However, when I clicked Apply the update failed, giving the following traceback in the terminal window I launched from:

Traceback (most recent call last):
  File "/app/share/pithos/pithos/PreferencesPithosDialog.py", line 211, in do_response
    if self.last_email != email or self.last_password != password:
AttributeError: 'PreferencesPithosDialog' object has no attribute 'last_password'

This worked on the second try, presumably because last_password was initialized that time.

[TingPing]

Somehow the response is triggering before the dialog is shown which sounds very weird.

[Node815]

I installed Kubuntu 20.04 and it fails to save the credentials s well. This is a fresh install today. Version 1.5.0 from Flatpak. I was able to install it in KDE Neon which is on Ubuntu 18.04 with no issues and login through that so I am not clear if this is related to newer Ubuntu versions or not.

i have tried using seahorse and gnome-keyring and KDE wallet as well. I am not familiar with debugging Flatpack installs but am happy to include a log file if you can point me in the correct direction for this.

I did got to the Wiki article however, and was able to compile it from source and it stored my credentials so.. it's a mystery to me.

[SpaceSaver]

Same thing happening here on Ubuntu 20.04 amd64. Pithos will work until it's closed and then when I go to launch it again, all the menus are empty and when I click apply after re-entering my password in the now blank message field, the same message the OP's getting pops up.

Traceback (most recent call last): File "/app/share/pithos/pithos/PreferencesPithosDialog.py", line 211, in do_response if self.last_email != email or self.last_password != password: AttributeError: 'PreferencesPithosDialog' object has no attribute 'last_password'

I'm running Pithos 1.5.1 and Flatpak 1.6.5. Hope this helps!

[scottsideleau]

Same problem observed on RHEL 7.9 using Flatpak 1.0.9 and the latest Pithos 1.6.0 release from Flathub.

Previously, working fine with Pithos 1.5.x ...

[TingPing]

@scottsideleau Your problem is unrelated. But 1.6.0 switched to using the portal to store secrets (as its better for privacy). However you may need a more up to date xdg-desktop-portal and gnome-keyring than RHEL ships. Unsure. (EDIT: At a glance it was added in xdg-desktop-portal 1.5.0)

[scottsideleau]

@TingPing : Great, thanks for the pointer!

I confirmed (as you expected), that xdg-desktop-portal is locked at v1.0.2_1.el7 on RHEL 7.9 workstation. I also note that the gnome-keyring package is v3.28.2_1.el7 in this configuration.

I reviewed xdg-desktop-portal/releases/tag/1.5.0, as you suggested, and confirm the "Add a secret portal that is meant be used via libsecret inside the sandbox" feature. I reviewed the RHEL 7 release notes for the same package, but do not see evidence of this capability being backported to the v1.0.2_1.el7 release maintained by RH.

More specifically, in reviewing RHEL 8 release of xdg-desktop-portal, which happens to be v1.6.0_5.el8, we see the specific portal capability is included by files:

/usr/share/dbus-1/interfaces/org.freedesktop.portal.Secret.xml
/usr/share/dbus-1/interfaces/org.freedesktop.impl.portal.Secret.xml

These files are not listed in the v1.0.2_1.el7 package.

Sadly, this means that the Flatpak release of Pithos will no longer work in RHEL-7 environments. As such, I have gone about building Pithos natively on RHEL-7 and documented my approach in #688 to enable updating the wiki.

Thanks for your help in tracking down the root cause & for updating the wiki!

(Also, sorry for re-using the wrong thread to capture & resolve this issue; at the surface, the symptoms seemed to match, despite the differing distributions. Sorry, again, for my mistake.)