Re: [Evolution] problem with display of folders
View- layout-show side bar On Sat, 2012-12-08 at 14:18 +1030, Imelda wrote: I no longer have the display of folders such as inbox, drafts, sent, trash etc in the side pane when I call up my emails. The only way I can look at my emails is to do a search on my email address and then they are all displayed as one big folder which I presume is the search folder and the location column shows what folder the emails belong to. How can I recover the former situation where the emails were dropped into various folders located in the side pane. Imelda ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Evolution on Ubuntu many problems - Help required
On Thu, 2012-11-29 at 20:21 +, Pete Biggs wrote: My experience posting questions on this list is that developers are reluctant to take on problems unless you use the last Evo build, That's a bit unfair. Many bugs get fixed, especially from .0 to .1 releases, so in general the first thing to do is to run the most recent version to see if your particular bug is fixed. If your problem is fixed in the latest version, then the solution is to use the latest version. If you can't run the most recent version, then you should still provide valid backtraces so that the problem can be located and, if it is a new bug, reproduced in the most recent version so it can be fixed. P. Pete, The real question is are there any bug fix releases related to bugs found in older releases or only in the current releases? If the answer is only related to the current releases then the observation appears to be correct. If not likeable by some. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Migrating data from Evolution 2.28 to 3.6
Greetings, I am not a regular on this evolution email list but I had a problem much like yours. If you have access to the archives for this list I sent an email describing my procedure that I used on 8/7/2012. I was migrating from a Fedora system with evolution 2.24.5 to another machine using Fedora 17 evolution 3.4.3. My problem was I was doing a sort merge on mail at the same time. But I think it would work for migration as well. I have been told that if you just leave the data as is and start the new version it will convert. I don't have any real reason to believe it. But I did around that time make it work for me. From a machine which appeared to be dying a hardware related death to a new machine. Let me know if I can help. Brian Anderson On Sun, 2012-11-18 at 17:25 -0500, Peter Meyer wrote: All: I am attempting to migrate my evolution mail data from 2.28 (Ubuntu 10.04) to 3.6 (Ubuntu 12.10). Is there a way to migrate the data? Can someone please point me to where the files are located in each release and any suggestions on migration strategies. I've tried using the backup/restore and this does not work. Thoughts? Peter ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] communication with servers has stopped.
Most likely a timeout at the TCP open/connect phase. Nothing that should require the password to be reentered, yet most mail clients feel the need to demand the password be reentered. And Evolution is no exception to this. On Tue, 2012-11-06 at 10:37 +0100, Thomas Prost wrote: Am Freitag, den 02.11.2012, 17:24 -0600 schrieb Brian A Anderson: I have seen this same symptom many a time. After many days of running and successful connections to the servers, all of a sudden Evolution cannot make a connection. It's only conclusion is that the password that it has, that I NEVER changed is suddenly wrong. And that I MUST reenter them immediately. A quick cancel on the current op and x out of evolution. Come back a half hour later and the passwords are miraculously correct. This is a red flag. My interpretation is that the connections went bad because the servers are down. Maybe the connection timed out ? I remember having read that Evolution's default time out is much shorter than the one of Outlook and I don't see a possibility to configure it. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] communication with servers has stopped.
I have seen this same symptom many a time. After many days of running and successful connections to the servers, all of a sudden Evolution cannot make a connection. It's only conclusion is that the password that it has, that I NEVER changed is suddenly wrong. And that I MUST reenter them immediately. A quick cancel on the current op and x out of evolution. Come back a half hour later and the passwords are miraculously correct. This is a red flag. My interpretation is that the connections went bad because the servers are down. Not because the passwords are bad. On Fri, 2012-11-02 at 18:31 -0430, Patrick O'Callaghan wrote: On Thu, 2012-11-01 at 21:06 -0500, Aaron Konstam wrote: This morning evolution worked as it has always worked. Suddenly at 3pm it refused to work by claiming that the passwords to the pop and smtp server were wrong.. This occurred at the same time on 2 machines. I tried to recreate the default account but the same error occurs. What can I do to fix this? Did you check if the passwords were in fact correct? Both giving password errors at the same time is rather a red flag. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Evoltion Backup Corrupted
What version of Evolution were you running on OpenSuse? And what version is to be run on Mint Linux? On Sun, 2012-10-28 at 09:35 -0400, Nayyar Butt wrote: I migrated from OpenSuse to Mint Linux. Before migrating, I made a backup for Evolution. When I restored the backup, some of my config parameters were restored but none of the mail folders were restored. A few emails that were in inbox have error messages. I still have the gz backup file. How do I get my email from the backup archive to the right place in the new system. I am just a linux user, not an expert. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote: Why should the backup not maintain a canonical form of all the aspects of a mail system vs backing up on the way in which the data is stored. A canonical form would have forced all versions to be able to backup and restore with full backwards and forwards compatibility. The canonical form could evolve with versioning of data forms as they get more complex and programs evolve. Sorry, I didn't really address the underlying aspect of what you are saying here. In the dim and distant past email was held in standardised data stores - i.e. mbox files. It was an almost universal standard and no matter what program you used, it could be read and modified and other programs would still be able to work with it. And Evolution used that standard. To all intents and purposes, that was the canonical form. Then some kind person invented MIME and the size of email messages expanded exponentially and all of a sudden the forever canonical form was not good enough - the files became too big, too unwieldy, too slow and things had to change. Similarly with configuration data - in the early days of Unix and a single INBOX on your local system, there was no configuration necessary - then POP, then IMAP, then Exchange all came along and something, somewhere had to remember what the program was supposed to do. There was no standard for such info so every program did its own thing. Evo did have a canonical form of the data, it was in flat files in the Evolution private folders, but that eventually became too slow and too fragile, so they changed to using gconf - which is now being deprecated in favour of dconf. What I'm trying to say is that 20:20 hindsight is a wonderful thing - but it is incredibly difficult to design a data storage format that is totally impervious to future changes and is efficient enough for everyday usage. I'm also fairly certain that if there was a standard for holding or exchanging account information and data between different programs, then Evo would have embraced it. What you said about mbox is not about canonical form. It is a standard way of storing mail info. The proper/canonical way of doing a backup is to read each canonical item from whatever store mechanism you use and to stores it canonically for restoration. The restoration process is the reverse it takes canonical items from a canonically organized store and places that data into whatever storage mechanism is used in this application.Thus each version, more importantly each version that has a different mbox, maildir etc method of storing info would have a different backup and restoration set of routines. Evolution does NOT use a canonical backup. It uses a trivial file backup using tar. At least for the 2.24.5 version that I was worried about getting files from. The Maildir mechanism used currently is not canonical either it is yet another standard way of storing the mail data. Finally, I would just point out that the best way of maintaining email for use on multiple systems and that is fairly impervious to changes in version is to keep your mail on a server and access it using IMAP - that way you don't have to worry about moving data and if the upgrade procedure doesn't work, all you will ever have to do is to re-enter the account configuration. Hindsight is perfect isn't it. I was never really interested in a multiple system environment. It was forced upon me as I was forced to retire a sick and dying machine and replace it with another machine. I do not live in a network hub. MY network here is not as reliable as I would like. Nor is my ISPs mail server. Therefore I must be able to see messages that I have received on my machine even if I don't have networking available. While some models for what a user of a computer or a computer program are may make all users homogenous, I assure you that we are not identical in any way shape nor form. We all have our own needs and methods of work. You may like some and dislike others. But we all use tools differently. In a true office environment at a workplace the IT department can force procedure. I am not in that environ, I must choose by own based upon my experience and lack of interest in version chasing. What made my situation in this scenario weird by how some would view the use of different versions of evolution is that I had data that I finally got via backup off of the dying machine. But before the dying machine actually dies I got the new machine up and running and started using it versus being cut off and not having any mail service at all. Or conversely living on a dying machine while I figrured out how to do a multiple version migration. Thus I wandered helplessly into a merge of data from my old system into data that is/was currently arriving. The process I used was to attempt to perform a backup of the old system using the evolution backup
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Thu, 2012-08-09 at 08:47 -0430, Patrick O'Callaghan wrote: On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote: Finally, I would just point out that the best way of maintaining email for use on multiple systems and that is fairly impervious to changes in version is to keep your mail on a server and access it using IMAP - that way you don't have to worry about moving data and if the upgrade procedure doesn't work, all you will ever have to do is to re-enter the account configuration. +1. In fact since Evo has supported IMAP since the beginning, a migration strategy for widely separated versions is to move the old mail onto an IMAP server, switch Evo versions, then just access it with the new one (or download it again if you really must). Pity this isn't so easy for contacts, tasks, filters etc. poc Again this is not a practical way for me to have solved my problem. I was forced into the situation by having a dying machine. I believed I had minimal time once my system started to fail until it was gone. In the long run an IMAP server is not really a good solution for I have a less than perfect/good ISP. I still need to access mail that arrived both distant past and recent past. Neither happen if either ISP net or ISP's imap server go down. Obviously, I am not using my Linux system in an office building with a real IT team. Perhaps if I had 25 years ago had started with a system like IMAP, I would not have gotten used to using a mail system that loads mail messages into my local space. Isn't hind sight perfect. Another feature that IMAP presents could be support of multiple systems. And again I don't have a real multiple systems usage. I have 2 laptops one old, one new. Old one is dying. IE I am headed to having one laptop. Also I am using Evolution for mail use only and don't really care about calender, contacts etc. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Wed, 2012-08-08 at 09:51 +0200, Patryk Benderz wrote: [cut] I hope this helps others so afflicted. Thank you for sharing Brian. Sadly not many people think about others these days. In my more than 25 years of UNIX, Linux, QNX etc experience , I have encountered a number of folks that hoard information/procedures and how tos like they were magic spells that only a true magician could possess and use. Since I learned much from that type of pseudo guru on my way to gurudom, I decided a while back to pass what I learned onto others so they could benefit. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Wed, 2012-08-08 at 07:35 -0400, Adam Tauno Williams wrote: On Wed, 2012-08-08 at 10:05 +0100, Pete Biggs wrote: On Tue, 2012-08-07 at 13:24 -0600, Brian A Anderson wrote: Begin editorial mode The key things that I learned here are; 1. the two different versions of Evolution had two different mailbox styles. 2. The two versions of Evolution were not compatible. 3. the evolution of Evolution had abandoned those with older systems. Cynical but apparently true. I don't think that's entirely true or fair. Did you give Evolution a chance to upgrade your data structure? Yes, the user posted about their success/failure using backup-and-restore to this list. backup-and-restore is pretty well known to not work across multiple major releases. Again my situation was a bit different as I said in my first paragraph. I was really doing a merge more than a restoration. So some of the suggestions were never going to really work completely. i.e. did you start Evolution with the old files in their original place rather than trying to do it through the backup files? Yes; or at least I believe the poster said that. Backwards compatibility is very important. To a point; but the user is jumping across many major releases. It is unreasonable to expect it to work well, IMNSHO. This is like jumping from Microsoft Access 97 to Microsoft Access 2010; it 'works', but a fair amount of remediation is required. Oh, gawd.. now I'm having flash-backs... First of all the version of a piece of software is merely a way of categorizing a set of procedures it should have no further impact. Consider this; Take for example how we consider travelling. We are all canonical travellers, we are passengers on planes, we have luggage. But none of us need to know what kind of plane, how it works etc. The way in which Ohare, JFK, Logan, SFO, LAX etc all work are slightly different. We don't need to care about those issues. Now look at evolutions data store. Each canonical message under 2.24.5 and 3.4.3 are stored differently. Yet they arrived into their versions of evolution using the same mechanisms. Why should the backup not maintain a canonical form of all the aspects of a mail system vs backing up on the way in which the data is stored. A canonical form would have forced all versions to be able to backup and restore with full backwards and forwards compatibility. The canonical form could evolve with versioning of data forms as they get more complex and programs evolve. So How many users really want to be slaves to version creeping and version hopping? Evolution 2.24 is *old* [circa 2008]. Especially in Evolution time where things seems to sit stagnant at the 2.2x level for a long time and then pulsed forward through 2.3x and now on to the [vastly improved] 3.2 and 3.4 era. But the user did publish notes, so kudos. Might be useful to someone else later on. Evolution is probably one of the best applications I know for upgrading internal storage formats - it is quick, unfussy and accurate. Yep. Some versions may not offer a real reason to migrate. I for one don't want to become a slave to updates like Windows users are a slave to updates. But you *must* install updates for any operating system - they fix bugs and, most importantly, they fix security holes. It just simply should not be optional to install updates. The user certainly doesn't need to rush to update; too many LINUX users are addicted to the next-greatest-patch which is an attitude that seriously impedes real world productivity [hey, let me update first thing Monday morning and break my desktop!]. 'Immediate update' also provides no pragmatic upside [let's be honest - *most* security fixes are pretty obscure and only effect boxes using particular applications/services in a particular configuration]. Name me two security fixes to Linux that fixed publically seen and experienced problems. Not just those that some security geek says are important and are possible. But happened. By the way I used to work in network security. I apply updates once a month; and I typically upgrade my distro a full month after a release [plus a month worth of updates]. This has provided me with a very smooth ride. I try to recommend this policy, but immediately after I say this most users are subscribing to a factory repository and doing a zypper up... sigh. :) I am glad that you have had a good luck with a monthly update. I have in several years attempted only two updates. AND BOTH FAILED TO COMPLETE! The last one left me with a dead system. In that case, with all due respect, why are you using Fedora! If you want stability, then use a RHEL clone such as CentOS or ScientificLinux - they will guarantee support for about 5 years after EoL of a particular version - but you still have to install updates. Agree. If long-term is what the user is looking
Re: [Evolution] Data migration Evolution 2.24.5 to 3.4.3
I believe I have found a procedure to follow to do a migration/merge of data from a backup.tar.gz file from the old 2.24.5 version to the newer 3.4.3 version. The key piece of info that I needed was the format of the two different versions. Since I was only really using evolution as a mail system I could ignore most of the other files. I was only really interested in extracting the mail messages from the old version and saving them. Meanwhile I had started to use 3.4.3 so I had msgs that I did not want to lose so a full restore was out of the question. And the project became a merge of data from the old into the newer version. As I said before the prospect of upgrading the version on the dying machine was not available. I am in the process of writing a summary/procedure of what I did and how it works so that it can be done by those who suffer from the same problem I encountered.I will post those notes to this mailing list. I warn it is a bit long. But I hope it would help some. Thanks to those that responded and provided me the info needed to learn what I learned. Thanks, Brian Anderson On Mon, 2012-08-06 at 09:52 -0600, Brian A Anderson wrote: How do I migrate from one machine running Evolution 2.24.5 to another machine running Evolution 3.4.3. Please note that the older machine (running 2.24.5) is dying a slow hardware death. I tried backup on old machine and restore on new machine. No go. It appears that the data is totally different in organization. Thanks in advance for any help. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
[Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
Attached is the file notes containing my notes about the migration of Evolution data from 2.24.5 to 3.4.3. The basics of this file is the procedure to migrate data (not a complete configuration) from 2.24.5 to 3.4.3. The data can be merged into already existing data running under 3.4.3. The scenario I was under was; 1. I had an older system running Fedora 10 Evolution 2.24.5 that had an apparent hardware failure. 2. A new laptop running Fedora 15 with Evolution 3.4.3 3. I already had the new systems email up and runnning. 4. I was not using calender or other features of the Evolution on the old system. I hope this helps others so afflicted. I would like to thank those that contributed information to my search for a solution. This file is a set of notes about how I solved a problem migrating from an older machine running Fedora 10 with Evolution 2.24.5 to Fedora 15 Evolution 3.4.3. My older machine was dying a hardware death and I considered it unable to be updated or changed in any way. My new machine had arrived and I got connected to my ISP server using Evolution 3.4.3. So it went from a simple migration into a merge. I had mail already present that 3.4.3 new about and mail that was valued from the old machine. While the old machine was working I got Evolution 2.24.5 to perform a backup into a local file evolution-backup.tar.gz That file was moved to the new machine using one of those USB flash drives. What follows is a procedure/dialog about how to get various message folders from the backup of the old 2.24.5 data into the area of the new 3.4.3 system. First some symbols I used OLDEVOL=$HOME/mytest/old/.evolution/mail/local NEWEVOL=$HOME/.local/share/evolution/mail/local TMPEVOL=$HOME/mytest/new Place that backup file in your home dir from my flash drive $HOME/evolution-backup.tar.gz So as to reduce vulnerability I did a backup of 3.4.3 and set it aside. Then I worked in a temporary directory called mytest This area would hold both the backup from the old system and converted folders prior to populating the new evolution tree. mkdir $HOME/mytest cd $HOME/mytest mkdir new old I placed the old mailbox system into old cd $HOME/mytest/old tar xvf $HOME/evolution-backup.tar.gz A quick view of the resulting directory was disappointing at first but I realized that the data was really visible at $OLDEVOL Each working folder for our example OURFolder under the old system was visible as four files OURFolder OURFolder.cmeta OURFolder.ibex.index OURFolder.ibex.index.data The actual email messages were found in OURFolder. As this procedure deals with selective restoration of a folder from the old to the new we will use the name OURFolder. This is the name it would have appeared as under Evolution 2.24.5. And ultimately under 3.4.3. We are going to build a temporary copy of the mail messages in our mytest directory tree. $HOME/mytest/new I used a perl script I found on the internet. The file was mb2md-3.20.pl It came from batleth.sapientia-sat.org/projects/mb2md It needs to have a TimeDate Perl library loaded. I installed a package using RPM. Sorry, but I cannot remember where I found it. I found it using google looking for Perl TimeDate The original mail mbx file is located by $OLDEVOL/OURFolder The new directory in our working Evolution 3.4.3 will be located by $NEWEVOL/.OURFolder/cur Note the . before OURFolder The conversion will go from a single file $OLDEVOL/OURFolder to a directory $NEWEVOL/.OURFOLDER/cur that contains files each with a separate email message. We will place the files in a temporary dir $HOME/mytest/new my nomenclature for this is TMPEVOL perl mb2md-3.20.pl -s $OLDEVOL/OURFolder -d $TMPEVOL/OURFolder The script will kick out some complaints but will do all the messages. No here is a find point to examine. The script uses a procedure to convert. I found it worked for my mail from my ISP. There is a option in the script to do the conversion a bit differently. So it may be necessary to read some of the messages and see if they make sense. Not really likely unless one speaks email header gibberish. take a look at $TMPEVOL/OURFolder/cur There will be many files. One per email message encountered by the conversion perl program. If it looks good. Now remember it is the raw message. evolution will change its appearance. NOW THE MOST IMPORTANT PART enter evolution create a new folder OURFolder Shut evolution down. copy the files from our temp directory to the 3.4.3 directory cp $TMPEVOL/OURFolder/cur/* $NEWEVOL/.OURFolder/cur note the . infront of the OURFolder in the destination directory This means you must get used to using the -a option in ls to see these folder/directories as you work with them. NEXT IMPORTANT PART enter evolution select OURFolder (the name we used) sit and wait select inbox select OURFolder the converted mail messages should be there
[Evolution] Data migration Evolution 2.24.5 to 3.4.3
How do I migrate from one machine running Evolution 2.24.5 to another machine running Evolution 3.4.3. Please note that the older machine (running 2.24.5) is dying a slow hardware death. I tried backup on old machine and restore on new machine. No go. It appears that the data is totally different in organization. Thanks in advance for any help. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Data migration Evolution 2.24.5 to 3.4.3
On Mon, 2012-08-06 at 17:26 +0100, Pete Biggs wrote: On Mon, 2012-08-06 at 09:52 -0600, Brian A Anderson wrote: How do I migrate from one machine running Evolution 2.24.5 to another machine running Evolution 3.4.3. I tried using this procedure but it did not work. I used the backup from the old version 2.24.5 it produced a evolution-backup.tar.gz I moved that file to the new machine then went to the restore from backup selection. Selected the above file and watched while it ran. I could see no information using evolution 3.4.3. THe set of what appears to be 4 files per 2.24.5 folder were present in the new tree. But all the other stuff was gone. Evolution was fundamentally useless at this point. So I killed all the programs and removed all the files in my user space and restarted evolution 3.4.3 on the new machine and downloaded files from my ISP provider. So far so good. But no files from before. You back it up from within Evolution, then restore it in the new version. See http://library.gnome.org/users/evolution/3.4/backup-restore.html.en Please note that the older machine (running 2.24.5) is dying a slow hardware death. I tried backup on old machine and restore on new machine. No go. It appears that the data is totally different in organization. How did you backup the data? And yes the file locations are different, but Evolution is intelligent enough to migrate data if it detects data in the old locations. P. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Data migration Evolution 2.24.5 to 3.4.3
This sounds a bit like I have a mission impossible. Looks like Evolution 3.0 does the conversion. I don't have 3.0. If I follow what you said below, Does this mean that I have to convert 2.24.5 data to 2.32 data and then to 3.4 or is it just one conversion? Is there a utility that someone has that might do this job? Again thanks in advance for any help. Brian. On Mon, 2012-08-06 at 18:23 +0200, Andre Klapper wrote: On Mon, 2012-08-06 at 09:52 -0600, Brian A Anderson wrote: How do I migrate from one machine running Evolution 2.24.5 to another machine running Evolution 3.4.3. Maintenance of 2.24 by upstream Evolution developers basically ended with the release of 2.28 in 2009. Changes that have happened in the meantime: With 2.32, Evolution started to store its data and preferences according to the XDG Base Directory Specification. Evolution 3.0 converted the default format from mbox to maildir. Evolution 3.4 uses GSettings/dconf instead of gconf for storing preferences. I tried backup on old machine and restore on new machine. No go. It appears that the data is totally different in organization. In case you used the Backup/Restore functionality of Evolution: It's very likely untested for such a big change in version numbers. My vague recommendation would be to install 3.0 on a machine and let Evolution pick up your data and settings to convert them, and then do the same again on a 3.4 machine. andre ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
