Description of problem: When going through the evolution welcome assistant, it will always loop back to the Welcome tab. It can almost seem like the data import failed. Steps to Reproduce: 1. create a evolution backup archive 2. kill the evolution processes and move the ~/.config/evolution folder to another place 3. in the welcome assistant, choose the backup archive Actual results: migration assistant closes and starts again.
I'm using evolution 3.6.2-2.fc18.x86_64
Thanks for a bug report. I think this is related to [1]. Please try also [2], maybe it'll help. Please let me know if it did. [1] https://bugzilla.gnome.org/show_bug.cgi?id=680201 [2] https://mail.gnome.org/archives/evolution-list/2012-November/msg00097.html
ok, you are welcome! in my above description I was wrong. With newly created backup archives of evolution version 3.6.2-2 it doesn't happen actually. But with a evolution archive created with evolution version 3.5.90-1 (I think that's the version I probably used at the time I created the archive) it should be reproducible. When I submitted this bug I thought the data import was succesfull (with the exception that it jumped to the welcome tab), but now I see that it acctually fails. I thought at first it succeeded because, evolution knew the Receiving/Sending server information of my Mail provider. And the fetching process of my ~1500 mails was also quite fast (compared to fetching the mails in clawsmails). If I start evolution from terminal, I get also following lines when the crash happens like in the bug linked in [1]: ** Message: rm /home/wolfi/.local/share/evolution/.running rm: cannot remove ‘/home/wolfi/.local/share/evolution/.running’: No such file or directory ** Message: gdbus call --session --dest org.gnome.evolution.dataserver.Sources0 --object-path /org/gnome/evolution/dataserver/SourceManager --method org.gnome.evolution.dataserver.SourceManager.Reload When I try to open the evolution-backup gui, it results in following error: ** (evolution-backup:4785): CRITICAL **: file evolution-backup-tool.c: line 946 (main): should not be reached I started /usr/libexec/evolution-source-registry in terminal and in parallel opened evolution and tried to restore the archive. When the crash happens and shortly before it shows this output: module-cache-reaper-Message: Scanning data directories (process:7364): module-cache-reaper-WARNING **: Failed to move '/home/wolfi/.local/share/evolution/mail/imap': Target file exists (process:7364): module-cache-reaper-WARNING **: Failed to move '/home/wolfi/.local/share/evolution/mail/1301933210.12084.21': Target file exists module-cache-reaper-Message: Scanning cache directories Server is up and running... Bus name 'org.gnome.evolution.dataserver.Sources0' acquired. Killed
Thanks for an update. I think the initial issue is related to bug [1], with is fixed in 3.5.92, which may explain the issue in 3.5.90-1, I guess. The "Target file exists" is there, because you have left there some files, thus the migration after restore cannot work properly. It's there to avoid unexpected file overwrites. The evolution-backup tool issue, did you actually run it with parameters as I wrote in the above cited mail? The check and printed error suggests you didn't. The tool is a command line tool, it doesn't do any UI interactivity, except of "backup/restore in progress" dialog. [1] https://bugzilla.gnome.org/show_bug.cgi?id=682820
ah now I found the issue I forgot the --restore flag. So finally I used this command "/usr/libexec/evolution/3.6/evolution-backup --gui --restore /home/wolfi/evolution-backup-20120831.tar.gz" Now it just shows the same output like when doing the import evolutions assistant. rm: cannot remove ‘/home/wolfi/.local/share/evolution/.running’: No such file or directory ** Message: gdbus call --session --dest org.gnome.evolution.dataserver.Sources0 --object-path /org/gnome/evolution/dataserver/SourceManager --method org.gnome.evolution.dataserver.SourceManager.Reload () Ups I just double checked if I really created this archive on version 3.5.90-1. But I used Fedora 17, so it must be rather version 3.4.4-1.fc17. On my notebook I still have a Fedora 17 (with evolution-3.4.3-2.fc17), where it behaved exactly the same. It seems like the import of these archives created with evolution 3.4.x fails generally. No matter if I use evoluton 3.4.3 or 3.6.2.
Yes, the evolution-backup process will produce the same output, or similar, if not exactly the same, that's OK. The difference is that no other evolution process will be running, especially evolution-source-registry, during the restore, thus the next time the evolution-source-registry is run, the GConf keys will be transferred into .source files. Which might mean that "Reload" method of evolution-source-registry doesn't work, or at least it doesn't migrate GConf accounts. I'm not sure what you mean with that backup, where it was created. If I got it right, then, basically, restoring backup created on 3.4.x in Evolution 3.6.2 doesn't add mail and other accounts previously configured in 3.4.x. Is this correct? If so, then I guess this is the aforementioned [1]. [1] https://bugzilla.gnome.org/show_bug.cgi?id=680201
I managed to fix this upstream, and I'm currently building evolution-data-server and evolution with patches included. I'll fill an update shortly.
evolution-data-server-3.6.2-2.fc18,evolution-3.6.2-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/evolution-data-server-3.6.2-2.fc18,evolution-3.6.2-3.fc18
I just tested the import with evolution-data-server-3.6.2-2.fc18.x86_64 and evolution-3.6.2-3.fc18.x86_64. good work! Now it works indeed.
Good, thanks for the confirmation. I was testing on a backup from 3.2.3 :)
Package evolution-data-server-3.6.2-2.fc18, evolution-3.6.2-3.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing evolution-data-server-3.6.2-2.fc18 evolution-3.6.2-3.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18794/evolution-data-server-3.6.2-2.fc18,evolution-3.6.2-3.fc18 then log in and leave karma (feedback).
*** Bug 879507 has been marked as a duplicate of this bug. ***
evolution-data-server-3.6.2-2.fc18, evolution-3.6.2-3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 781825 [details] log
Seeing this same error importing a backup file into Evolution 3.8 on Fedora 19, created in Evolution 3.2.3 on Fedora 16. Is this a regression? Log attached in Comment #14 Lana
Your log looks correct, it even doesn't print any error (I do not count "file not found" on the .running file, that one is correct). There can be two reasons, one is that the added timeout was not enough for your machine, and that the gzip uses /tmp internally, but it is limited to ~2GB since F19 by default (I was told so some time ago). I suggest to repeat commands you see in the log in a terminal, only instead of invoking the Reload method close all the evolution processes (ps ax | grep evolution), which can be tricky under gnome-shell, because it restarts them on its own). Also note that after the 'gconftool-2 --load' and 'gsettings-data-convert' it might be good to flush memory data of GConf into a disk, because evolution-source-registry reads data from a disk, not from the memory, thus either wait couple seconds (which the internal restore routine does) or invoke 'gconftool-2 --shutdown', though the command is not meant to be used much. In any case, to let gconf save changes gracefully, you can just log out and then log in, after the 'gsettings-data-convert' call, because all the other commands are just a clean-up from the backup files during the restore of them.