[opensuse-gnome] Evolution 2.22 for Factory
I've opened an Evolution 2.22 repo and made it build on Factory, so those of us who depend on Evo to get work done but are running into showstoppers in 2.23/2.24 can keep using the old one and still dogfood the rest of the distro: BS project: home:hpjansson:evolution-2.22 Note 1: It fakes the newer soversion of /usr/lib/libedataserver.so by just creating a .11.so link to it. This makes all kinds of apps that are linked with the newer version start up successfully (I haven't run into any problems caused by this yet, but it might still happen, so just be aware - I didn't check to see what symbols changed). Note 2: If you ran the newer version of Evolution previously, you should delete the sqlite database it creates before reverting to the old one - otherwise it will think the sqlite database is an mbox and try to index it, which will cause errors. Delete ~/.evolution/mail/local/folders.db*. Apart from that, reverting had no ill effects for me - calendar, addressbook and mailboxes are still there and contain the old data. [ Disclaimer: Always keep recent backups of your data. ] -- Hans Petter -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Hey HPJ, On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
I've opened an Evolution 2.22 repo and made it build on Factory, so those of us who depend on Evo to get work done but are running into showstoppers in 2.23/2.24 can keep using the old one and still dogfood the rest of the distro:
Are there any blocker outstanding? AFAIR, there aren't any blockers apart from dup mails in pop folders, which Federico reported, which I'm trying to duplicate. Rest all should be fixed. Are there any unreported issues? Oh wait, I don't remember, which version factory ships. If it's pre 2.23.92, it may not be a nice experience. But still should work. -Srini -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Fri, 2008-09-19 at 13:52 +0530, Srinivasa Ragavan wrote:
On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
I've opened an Evolution 2.22 repo and made it build on Factory, so those of us who depend on Evo to get work done but are running into showstoppers in 2.23/2.24 can keep using the old one and still dogfood the rest of the distro:
Are there any blocker outstanding? AFAIR, there aren't any blockers apart from dup mails in pop folders, which Federico reported, which I'm trying to duplicate. Rest all should be fixed. Are there any unreported issues?
By showstopper I meant personally - i.e. affecting the reporter and maybe others but probably not everyone. I have at least two (see below).
Oh wait, I don't remember, which version factory ships. If it's pre 2.23.92, it may not be a nice experience. But still should work.
I filed these bugs against 2.23.92+r36353 this week: http://bugzilla.gnome.org/show_bug.cgi?id=552705 http://bugzilla.gnome.org/show_bug.cgi?id=552731 There may be more "hpj-stoppers", but I haven't been able to test it beyond observing the latter bug. I'd like to make it clear that my 2.22 packages are just a stopgap measure, and not in any way a permanent solution - I'll be testing new versions of 2.24 as they come out and switch when it works for me. As long as it doesn't, I'll be reporting bugs. I'm looking forward to using 2.24, especially the new mailer features :) -- Hans Petter -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Fri, 2008-09-19 at 10:22 -0500, Hans Petter Jansson wrote:
On Fri, 2008-09-19 at 13:52 +0530, Srinivasa Ragavan wrote:
On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
I've opened an Evolution 2.22 repo and made it build on Factory, so those of us who depend on Evo to get work done but are running into showstoppers in 2.23/2.24 can keep using the old one and still dogfood the rest of the distro:
Are there any blocker outstanding? AFAIR, there aren't any blockers apart from dup mails in pop folders, which Federico reported, which I'm trying to duplicate. Rest all should be fixed. Are there any unreported issues?
By showstopper I meant personally - i.e. affecting the reporter and maybe others but probably not everyone. I have at least two (see below).
Oh wait, I don't remember, which version factory ships. If it's pre 2.23.92, it may not be a nice experience. But still should work.
I filed these bugs against 2.23.92+r36353 this week:
http://bugzilla.gnome.org/show_bug.cgi?id=552705 http://bugzilla.gnome.org/show_bug.cgi?id=552731
There may be more "hpj-stoppers", but I haven't been able to test it beyond observing the latter bug.
I'd like to make it clear that my 2.22 packages are just a stopgap measure, and not in any way a permanent solution - I'll be testing new versions of 2.24 as they come out and switch when it works for me. As long as it doesn't, I'll be reporting bugs.
I'm looking forward to using 2.24, especially the new mailer features :)
Rumor has it the templating feature in 2.24 is awesome and so is the guy who came up with it, and so are the guys who implemented it. :-) I can't wait for 2.24
-- Hans Petter
-- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
Note 2: If you ran the newer version of Evolution previously, you should delete the sqlite database it creates before reverting to the old one - otherwise it will think the sqlite database is an mbox and try to index it, which will cause errors. Delete ~/.evolution/mail/local/folders.db*.
That - is really bad. Can we not name our db in some way that this doesn't happen ? is there really no solution here ? if not, why are these databases in a place where older versions get confused & start doing stupid things ? - can we not put them somewhere else ? Switching between versions, should work right ? HTH, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
[ Adding evolution-hackers to Cc since this contains potentially useful feedback and some questions ] On Fri, 2008-09-19 at 18:06 +0100, Michael Meeks wrote:
On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
Note 2: If you ran the newer version of Evolution previously, you should delete the sqlite database it creates before reverting to the old one - otherwise it will think the sqlite database is an mbox and try to index it, which will cause errors. Delete ~/.evolution/mail/local/folders.db*.
That - is really bad. Can we not name our db in some way that this doesn't happen ? is there really no solution here ? if not, why are these databases in a place where older versions get confused & start doing stupid things ? - can we not put them somewhere else ?
That's a question for the Evo team, I guess - it looks like it could be trivially fixed by moving the folder.db somewhere else, or calling it folder.index or folder.ibex.index or whatever Evolution traditionally filters out. To Evolution's credit, my 500MB folder.db binary blob didn't cause it to crash - it showed up as a bogus local mail folder after about 15 minutes of disk churn - but it did throw errors whenever it needed to pull data for vfolders. Also, it looks like old summary/index files aren't removed - does it require both the sqlite database and summaries now? It increases disk space consumption quite a bit.
Switching between versions, should work right ?
I don't know if we ever guaranteed spotless downgrading, but yeah, having that work would be a big plus - especially since users may switch between distros but keep their home dirs. -- Hans Petter -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Hello Guys, On Fri, 2008-09-19 at 22:14 -0500, Hans Petter Jansson wrote:
[ Adding evolution-hackers to Cc since this contains potentially useful feedback and some questions ]
On Fri, 2008-09-19 at 18:06 +0100, Michael Meeks wrote:
On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
Note 2: If you ran the newer version of Evolution previously, you should delete the sqlite database it creates before reverting to the old one - otherwise it will think the sqlite database is an mbox and try to index it, which will cause errors. Delete ~/.evolution/mail/local/folders.db*.
That - is really bad. Can we not name our db in some way that this doesn't happen ? is there really no solution here ? if not, why are these databases in a place where older versions get confused & start doing stupid things ? - can we not put them somewhere else ?
Michael, Its n't possible to keep it there still not findable by the old version. AFAICS, { ".msf", ".ev-summary", ".ev-summary-meta", ".ibex.index", ".ibex.index.data", ".cmeta", ".lock" } are the possible extensions that the old version of Evolution ignores. But these have definite meanings and possible they exist as locks, metafiles or old-type-summaries. Naming the new summary that way would probably erase the real data.
That's a question for the Evo team, I guess - it looks like it could be trivially fixed by moving the folder.db somewhere else, or calling it folder.index or folder.ibex.index or whatever Evolution traditionally filters out.
HPJ, the summary can't be named like this, since, its possible that something like this already exists. .ibex.index has a traditional meaning and would be more of abusing it in the newer versions.
To Evolution's credit, my 500MB folder.db binary blob didn't cause it to crash - it showed up as a bogus local mail folder after about 15 minutes of disk churn - but it did throw errors whenever it needed to pull data for vfolders.
But, the old version shouldn't touch the folders.db automatically, meaning the new summary would be safe, unless the user manually deletes or adds mails to it.
Also, it looks like old summary/index files aren't removed - does it require both the sqlite database and summaries now? It increases disk space consumption quite a bit.
That is left purposefully. Incase you are a user switching across versions, probably you would have to recreate summaries every time you do. But first time, we just migrate and don't care later on. So if you aren't a user of that category, a rm of it manually should suffice. [probably some more summaries left on the other accounts]
Switching between versions, should work right ?
Michael, AFAICS, it should work fine, we don't touch old summaries written by old version. If it happens, file a bug (I dont think it happens ):-) Just that the old version reports you of a new folder folders.db. Should we ship a patch for older Evolution versions to ignore folders.db? May be worth for power users of SLEs and RHEs, who might still use older version & new version. -Srini -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Sat, 2008-09-20 at 09:49 +0530, Srinivasa Ragavan wrote:
On Fri, 2008-09-19 at 22:14 -0500, Hans Petter Jansson wrote:
That's a question for the Evo team, I guess - it looks like it could be trivially fixed by moving the folder.db somewhere else, or calling it folder.index or folder.ibex.index or whatever Evolution traditionally filters out.
HPJ, the summary can't be named like this, since, its possible that something like this already exists. .ibex.index has a traditional meaning and would be more of abusing it in the newer versions.
Wouldn't it be possible to use a different directory, e.g. "mail/local-index/folders.db"? That would avoid both problems.
To Evolution's credit, my 500MB folder.db binary blob didn't cause it to crash - it showed up as a bogus local mail folder after about 15 minutes of disk churn - but it did throw errors whenever it needed to pull data for vfolders.
But, the old version shouldn't touch the folders.db automatically, meaning the new summary would be safe, unless the user manually deletes or adds mails to it.
Right. For me, folders.db showed up as having 7 unread mails in it. The mbox parser probably found some satisfactory ^From occurrences. It also made local mail unusable, since it would constantly throw errors and fail to update vfolders (details are a little bit foggy at the moment, but I remember being hindered to the point of not being able to read mail).
Also, it looks like old summary/index files aren't removed - does it require both the sqlite database and summaries now? It increases disk space consumption quite a bit.
That is left purposefully. Incase you are a user switching across versions, probably you would have to recreate summaries every time you do. But first time, we just migrate and don't care later on. So if you aren't a user of that category, a rm of it manually should suffice. [probably some more summaries left on the other accounts]
Ok, if I can just remove the old indexes/summaries, I'm happy :)
Should we ship a patch for older Evolution versions to ignore folders.db? May be worth for power users of SLEs and RHEs, who might still use older version & new version.
I still think relocating folders.db is a better option, since it would work for everyone without necessitating an upgrade. -- Hans Petter -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
HPJ,
HPJ, the summary can't be named like this, since, its possible that something like this already exists. .ibex.index has a traditional meaning and would be more of abusing it in the newer versions.
Wouldn't it be possible to use a different directory, e.g. "mail/local-index/folders.db"? That would avoid both problems.
You end up seeing a new folder local-index in 2.22/older and a folders.db folder under it. :( FWIW, I did give it a try, during the initial phases, but I abandoned it, since I was short of time. -Srini. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Mon, 2008-09-22 at 13:31 +0530, Srinivasa Ragavan wrote:
Wouldn't it be possible to use a different directory, e.g. "mail/local-index/folders.db"? That would avoid both problems.
You end up seeing a new folder local-index in 2.22/older and a folders.db folder under it. :(
Wouldn't that just happen if you had "mail/local/local-index/folders.db"? I was hoping you could place local-index or something equivalent outside the mail/local/ hierarchy entirely - either directly under "~/.evolution/mail/" or, as Ross suggested, in "~/.cache/evolution/" (I like the latter a lot). -- Hans Petter -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Wed, 2008-09-24 at 01:38 -0500, Hans Petter Jansson wrote:
On Mon, 2008-09-22 at 13:31 +0530, Srinivasa Ragavan wrote:
Wouldn't it be possible to use a different directory, e.g. "mail/local-index/folders.db"? That would avoid both problems.
You end up seeing a new folder local-index in 2.22/older and a folders.db folder under it. :(
Wouldn't that just happen if you had "mail/local/local-index/folders.db"? I was hoping you could place local-index or something equivalent outside the mail/local/ hierarchy entirely - either directly under "~/.evolution/mail/" or, as Ross suggested, in "~/.cache/evolution/" (I like the latter a lot).
I'm just trying out a new model, like a single-db for entire evolution-accounts-folders, instead of db-per-accounts/table-per-folder, which forces this. In the new model, ~/.evolution/mail/summary.db could be for entire Evolution. Vfolders would be even more faster, being single table. Anyways, just exploring. Would share when I have things in better shape. -Srini -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Sat, 2008-09-20 at 00:47 -0500, Hans Petter Jansson wrote:
Wouldn't it be possible to use a different directory, e.g. "mail/local-index/folders.db"? That would avoid both problems.
That seems like a great idea to me; at least - if the 'hot' data set of evolution is normally just the summary information, then keeping that in a single directory [ ie. mangle the path names into file names ] would make it rather more likely to be contiguous on disk too which might be nice: ~/.evolution/mail/summaries/local-Inbox-suse-kernel.db # etc. ;-)
I still think relocating folders.db is a better option, since it would work for everyone without necessitating an upgrade.
Sounds best to me, if we can do it that is. Regards, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
participants (4)
-
Bryen
-
Hans Petter Jansson
-
Michael Meeks
-
Srinivasa Ragavan