flathub / org.gnome.Evolution

https://flathub.org/apps/details/org.gnome.Evolution
8 stars 10 forks source link

Flatpak Evolution forgot it settings (again!) #179

Open mmarjano opened 1 month ago

mmarjano commented 1 month ago

Hello,

I'm using flatpak version of Evolution because the version in my distro's repositories is too old, contains bugs and has a missing feature that I need. I don't care much for the sandboxing nonsense, I simply want it to work without tinkering.

That being said, every now and then it forces me to tinker with it because after updates it sometime forgets it settings. For instance I have set these options:

Now most of these I can go and change again for nth time, but for instance signature delimiter has no setting in the GUI, so It's another pain point. I'd much rather prefer for Evolution not to decide to nuke my settings and force me to redo them every so often.

Thanks!

mcrha commented 1 month ago

Hi, the update should not cause settings reset, definitely not intentionally.

I see the flatpak manifest contains "--metadata=X-DConf=migrate-path=/org/gnome/evolution/", which the upstream manifest does not have. Maybe it's causing the problem, the flatpak tries to sync the settings from the host machine to the sandbox and overrides your in-flatpak settings, because the host machine either has Evolution still installed or there is some left-over settings in the DConf for the Evolution, which contains the data.

Does dconf dump /org/gnome/evolution/ return anything for you, when you run it on the host machine?

mcrha commented 1 month ago

I tried to reproduce this by setting Edit->Preferences->Composer Preferences->Replies and Forwards section in the flatpak and on the host into different values and the first downgrading the flatpak app to a previous version (flatpak update --commit 4e59d6f9f4201780488fbb09917677fcd9afd6d569327df0d46bbc5bc41b9b60 org.gnome.Evolution) and then back to the latest, both once when the flatpak had left running the background evolution-data-server processes (closing the Evolution window does not close the flatpak sandbox) and also when I stopped the process before the flatpak update (flatpak kill org.gnome.Evolution), and it did not reproduce the problem in both cases.

Maybe, is there any auto-cleanup of the ~/.var/app/ or ~/.config/ or any such directory in your system set?

It seems the sandbox saves the GSettings into the ~/.var/app/org.gnome.Evolution/config/glib-2.0/settings/keyfile file by default.

mcrha commented 1 month ago

It seems the sandbox saves the GSettings into the ~/.var/app/org.gnome.Evolution/config/glib-2.0/settings/keyfile file by default.

I just verified the migration with the settings from the host system runs only if the keyfile file does not exist. At least with flatpak-1.15.8

mmarjano commented 1 month ago

Does dconf dump /org/gnome/evolution/ return anything for you, when you run it on the host machine?

It returns quite a lot but by skimming through the returned output, I can see that those are the settings of old Evolution installed on host machine, and they're not different from the state I like. So even if those were copied to the flatpak, it would have been fine.

Also, if it's not clear from my previous message, this doesn't happen during every update. It happened once or twice before, and I've had it installed as a flatpak probably close to a year. Reading my previous message now, I realize that I gave out impression that this happens often, but my wording at that time came out of the fact that I was annoyed :)

Also, I don't know if this is important, but I have previously enabled "All user files" setting through Flatseal, so that part is different than defaults.

Since this happened I've re-applied my desired settings, so it works now as expected, but I'm willing to provide any additional info or command outputs if it will help confirm this issue and detect the cause.

mcrha commented 1 month ago

In that case there probably happened something to that ~/.var/app/org.gnome.Evolution/config/glib-2.0/settings/keyfile file. Whether it's still at that place when you enabled "All user files" I do not know, but I suppose it is.

Could you make a copy of that file and when the issue happens, compare the copy with the current file, both with the content and with the file attributes, like the last modification time? That won't show why it had been changes, it'll only show it had been. I'm afraid there is nothing usable to track certain file changes, to see which process and when touched it; at least I'm not aware of anything for it.

As you have the host system settings similar to what you want, I guess we can safely ignore the migration code.

mmarjano commented 1 month ago

I've backed up my current file, and if this happens again I'll update this issue with a diff. Thank you!

mmarjano commented 1 month ago

Ok it happened again. But now I have a reason to believe that this is not due to package update, since this is present in both backed up and current keyfile:

[org/gnome/evolution]
version='3.54.0'

I'll be reverting back to my backed up configuration, but it would be really nice to get to the bottom of this...

mcrha commented 1 month ago

Do you mean there was no update this time, still the options reset had been triggered? I'd also like to know what causes this, but I've no clue where to look to debug it. Do you keep Evolution running all day or you open/close it multiple times per day without the machine restart? Even when the window is closed, there are left background processes running (thus you can get meeting notifications even without the evolution window).

mmarjano commented 1 month ago

Do you mean there was no update this time, still the options reset had been triggered? I'd also like to know what causes this, but I've no clue where to look to debug it. Do you keep Evolution running all day or you open/close it multiple times per day without the machine restart? Even when the window is closed, there are left background processes running (thus you can get meeting notifications even without the evolution window).

I'm not exactly taking note which app is at what version, but comparing previous and current config, I can see the exact same version specified. I've also checked Help>About screen, and the same version is specified there, so I think that It's very likely that there were no updates.

My Evolution is mostly on - I never turn it off except for system update/restart. It's in my autostart. I also don't turn off my computer at all/ever. I think it was off last time about a year ago when I dusted it, and that's about it. I reboot it weekly for updates.

mcrha commented 1 month ago

Looking into the change log on the flathub.org site (flatpak remote-info flathub org.gnome.Evolution --log), there was no update since 2024-09-25 , thus at least Evolution itself was not updated. The runtime could be updated under the hood, but I see it also did not change for several weeks (the last update had been done on 2024-10-01).

I've been thinking that the reused sandbox could cause some trouble, but if you keep evolution running then it's not it.