[Bug]: Only three accounts supported

[tomirgang]

Describe the bug

I'm using Tuba 0.8.4 from Flathub on VanillaOS 2.
I think I spotted a bug:
I can add more then three accounts, but after every restart only the first three accounts are available.

Steps To Reproduce

1. Install Tuba 0.8.4 form Flathub
2. Add more then three Mastodon accounts
3. Close the app and reopen it.
   Only the first three accounts are available.

Logs and/or Screenshots

No response

Instance Backend

Mastodon

Operating System

VanillaOS 2

Package

Flatpak

Troubleshooting information

No response

Additional Context

No response

[GeopJr]

Thanks for the report!

Tuba securely saves and reads accounts from the secret-service. Sometimes distros and setups have configured it wrong. You can try and see if they are saved correctly using Passwords & Keys (seahorse) and check if there's any errors when running tuba with flatpak run dev.geopjr.Tuba but other than that there's not much I can do.

I'll try VanillaOS in a vm and attempt to re-produce it but from Tuba's side there's no hard-limits and will add as many accounts as the secret-service returns.

[tomirgang]

Hi @GeopJr,

I just found one entry for Tuba in the secret store:

secret-tool search --all --unlock app_id dev.geopjr.Tuba
[/15]
label = 
5�****more binary stuff***
created = 2024-10-30 06:27:53
modified = 2024-10-30 06:27:53
schema = org.freedesktop.Secret.Generic
attribute.app_id = dev.geopjr.Tuba

and no account information at all.

The console log showed some warnings:

tom@Vanilla  ~ $ flatpak run dev.geopjr.Tuba
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `GeeMap'
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `GType'
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `gpointer'
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `gpointer'
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `GType'
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `gpointer'
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `gpointer'
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `GeeSet'
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `GeeCollection'
(dev.geopjr.Tuba:2): Json-WARNING **: 09:48:00.748: Unsupported type `GeeSet'

[mickeymarse]

I'm having the same issue, but I'm actually limited to only one account. :(

[GeopJr]

Someone on Mastodon helped me debug this further, I just haven't gotten back into FOSS from the holidays :P

If the accounts have the same name, try changing the display name of one you are adding temporarily until you add it and then change it back

[mickeymarse]

No rush at all. Feel free to answer whenever you can.
In my case, accounts have different names and server. No similarities whatsoever.
Happy to check the original thread if you still have the link though.

[GeopJr]

It was mostly a one off message so nothing to really check out. Uhmm, I don't know.

• Are there are any errors right after adding your accounts?
• Do the accounts have any similarities in regards of handle / display name?
• What's your distro (and DE)?
• You do have a libsecret backend installed, right? (Kwallet, gnome-keyring, keepass...)
• Could you make sure the keyring is unlocked with seahorse / Passwords & Keys?
• What backend software do both the accounts run? (Mastodon, Akkoma etc)

Other than that, I'm out of ideas. We do have some hacks around some issues with some setups (we unlock the whole keyring when we shouldn't have to and we don't on GNOME and KDE at least), but I don't think that has anything to do with it since at least one was saved.

From Tuba's side, all it does is ask libsecret to save the account to the keyring, but if that failed there would be at least 2-3 warnings shown :////

I wish I could reproduce it

[wm75]

Just encountered what seems to be the same issue:
I've been migrating my account to a new server using same user and display name.

When I tried adding the new account (as the third account) to Tuba it wouldn't persist across app restarts.
Instead of playing with changing names in any of the accounts I just removed now my old, transferred account from Tuba, added the new one once more and, voilà, it's here to stay :-)

So, apparently, nothing's wrong with my keyring and it seems likely that the duplicate account and/or display name was the issue.

[edit] forgot to add app info:
0.9.1 flatpak version

[GeopJr]

Still can't reproduce it on my end with duplicate account names etc. FWIW, I'll list all I have on it in case anyone passing by can help target it down.

Credentials are saved in the host's keyring. These keyrings have their own unique issues and sometimes need workarounds (e.g. the version of gnome-keyring pureos ships(/ed?) would assume the default keyring was named 'login' and pureos had renamed it or the keepass having issues with the portal).

Tuba and other gnome apps use libsecret to communicate with the secret service (keyrings). On unlocking, there's a workaround for some issues found with some keyrings where we need to lookup everything rather than just dev.geopjr.Tuba.

Tuba's secret entries have two attributes, login which is the unique account handle and version which is 1 (this can be used to invalidate old incompatible logins, e.g. #638)

When adding an account, Tuba generates the secret body, which is a json string that includes some account secrets and info, fills in the attributes and asks libsecret to save it.

https://github.com/GeopJr/Tuba/blob/main/src/Services/Accounts/SecretAccountStore.vala#L217-L235

So far nobody that has experienced this issue has reported any logged errors. If it doesn't succeed it both logs an error in terminal but also displays a dialog with it. If it succeeds, and Tuba is running with G_MESSAGES_DEBUG=Tuba, the following string will be logged in terminal Saved secret for <account handle>.

That only leads me to believe that from Tuba's side everything is done correctly and the problem is on the keyrings. However if the Saved secret for <account handle> string doesn't log either then I have another suspicion.

[wm75]

Thanks for the debugging directions.
I just tried and ran Tuba with the G_MESSAGES_DEBUG=Tuba option and then added my third account back in.
When I connect it, Tuba prints the Saved secret for <account handle> twice for the two existing accounts, but never for the new one and there are no errors (except that none of my accounts has the annual report 2024 api) or warnings along the way.
When I then close Tuba and reopen it with the same debug option, it happily reports that it loaded two accounts, and my freshly added one is gone.

[GeopJr]

Can you try this build? https://github.com/GeopJr/Tuba/actions/runs/12963051619/artifacts/2484703740 - it includes some more logs

(unzip it and install it with flatpak install ./<path to dev.geopjr.Tuba.Devel.flatpak>)

Run it with flatpak run dev.geopjr.Tuba and try adding the account that cant be saved. Then send me back the logs (feel free to redact anything, but make sure the handles can be distinguished between the others)

[wm75]

Can you try this build? https://github.com/GeopJr/Tuba/actions/runs/12963051619/artifacts/2484703740 - it includes some more logs

I tried but it cannot be launched. Error is:

bwrap: execvp ldconfig: Exec format error
error: ldconfig failed, exit status 256

[wm75]

Stupid not to consider this: the test flatpak you're providing is for x86_64, of course, but I've used Tuba exclusively on mobile (aarch64 via postmarketos) so far. Got so used to the fact that this is the mobile client for mastodon that I completely forgot that that's not the only platform to run it on, sorry 🤦

Anyway, I know installed your flatpak on desktop (fedora 42) and it runs just fine. Problem now is that this is a different system than before and I'm not sure whether I'm observing exactly the same issue as before. To recap:
on mobile I had two pre-existing accounts, a1 and a2, and I tried to add a third one, a3, with user account and display name matching a1, and that failed until I removed a1 first.

Now on the desktop I just freshly added a2 (the unrelated account) as the first account, then wanted to add a1, and already that didn't work! The output from that failed attempt looks completely harmless though:

MESA-INTEL: warning: ../src/intel/vulkan/anv_formats.c:782: FINISHME: support YUV colorspace with DRM format modifiers
MESA-INTEL: warning: ../src/intel/vulkan/anv_formats.c:814: FINISHME: support more multi-planar formats with DRM modifiers

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.075: Unsupported type `GeeMap'

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.075: Unsupported type `GType'

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.075: Unsupported type `gpointer'

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.075: Unsupported type `gpointer'

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.075: Unsupported type `GType'

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.075: Unsupported type `gpointer'

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.075: Unsupported type `gpointer'

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.075: Unsupported type `GeeSet'

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.075: Unsupported type `GeeCollection'

(dev.geopjr.Tuba:2): Json-WARNING **: 18:50:15.076: Unsupported type `GeeSet'

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.077: AccountStore.vala:49: While adding, there are 1 accounts

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.077: AccountStore.vala:51: Now, there are 2 accounts

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: AccountStore.vala:53: About to save <a1>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:103: There are 2 accounts

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:105: About to A2S <a2>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:137: Begin A2S for <a2>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:216: Finished building json for <a2>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:222: About to Save keyring for <a2>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:243: Finished A2S for <a2>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:105: About to A2S <a1>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:137: Begin A2S for <a1>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:216: Finished building json for <a1>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:222: About to Save keyring for <a1>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:243: Finished A2S for <a1>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.098: SecretAccountStore.vala:109: Saved 2 accounts

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.206: SecretAccountStore.vala:239: Saved keyring for <a1>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:50:15.206: SecretAccountStore.vala:239: Saved keyring for <a2>

(dev.geopjr.Tuba:2): Tuba-WARNING **: 18:51:18.787: MediaViewer.vala:1175: Error while opening Host's cache: Error opening directory “~/.var/app/dev.geopjr.Tuba/cache/tuba/manual/media”: No such file or directory

The error at the end happens when closing the Tuba window, and seems unrelated here.

I then deleted a1 again and added a2 as the first account, then added a1 again, and then tried a3 - and that just worked.
So after all it doesn't seem to be about a1 and a3 account names/display names, but rather seems to have something to do with the order of accounts getting added?

Is that standard output what you're looking for @GeopJr or do you need the complete debug logs?

[GeopJr]

this is the mobile client for mastodon

Sorry to disappoint, but mobile is an afterthought from my side as I don't have access to a linux mobile device and qemu is painful to use. It goes without saying that I'll fix and prioritize mobile linux issues (like the PureOS one), but unless users raise them I won't be aware they exist at all.

However, the CI builds for aarch64 too, but I only linked the x86_64, my bad! (Though at the time it was failing due to an issue with gcc that has been fixed now on main)

---

Thanks for the logs! It seems really helpful.

I added some more logs, could you try this again with this build (when it finishes building) https://github.com/GeopJr/Tuba/actions/runs/13207402665 - make sure you are running this one after you install it and not the previous one or the release one.

I'd like logs when adding the accounts and logs after you run tuba again and see that the last account is missing.

---

I had started re-writing the account management system in hopes of fixing it there but your logs above show me that none of my speculations are true... The accounts were saved to the keyring as well according to libsecret :/

If that doesn't match the actual state of the keyring, and the logs from the linked build don't show anything out of the ordinary then all I can guess is that it's not something from my side but somewhere else in the platform. It'll be difficult to target it down if I can't reproduce it myself however (and believe me, I tried, I have ~10 accounts added).