Downgrading is still possible. If you plan to do that, make a copy of ~/.config/syncevolution and restore that later. You'll run into slow syncs; resolve these with an explicit slow sync or refresh syncs.

Hi Patrick, On Tue, Feb 8, 2011 at 7:55 AM, Patrick Ohly <patrick.ohly(a)gmx.de&gt; wrote: > Hello! > > I have uploaded binaries and source of 1.1.99.2, a pre-release of the > upcoming 1.2, to syncevolution.org. .debs are available in the > "unstable" repo, .rpms are in the usual location and the source is in > the new "experimental" sub-directory of the "source" download dir. > > This version is not complete enough to replace 1.1.1 in distros, but it > should be stable and ready for testing by adventurous users. I'm using > it myself now. > > Compared to previous updates, this one has several more disruptive > changes, which is why I would like to get feedback from real users > before releasing it. > > The configuration has to be rewritten before it can be used for syncing. > The reasons are a) a format change of the libsynthesis binfiles which > would cause slow syncs after a downgrade and b) renaming configuration > options (evolutionsource/user/password -> database + > databaseUser/Password, type -> > backend/databaseFormat/syncFormat/forceSyncFormat). > > Because I don't want user to unintentionally run this version and then > face issues when downgrading (see below), the configuration explicitly > has to be migrated to the new format. The command line prints > instructions as part of reporting the problem. Basically run "--migrate > @default". The UI shows a new 22005 error code. The final 1.2 release > will automatically migrate configs as needed. > > Downgrading is still possible. If you plan to do that, make a copy of > ~/.config/syncevolution and restore that later. You'll run into slow > syncs; resolve these with an explicit slow sync or refresh syncs. If you > didn't plan to downgrade, then find the "default.old" directory and the > "peers/*.old" directories inside, remove the more recent directories > without that suffix and remove the *.old suffix from the older ones. > Also set "consumerReady=1" in the peer config to have it show up in the > sync UI again. > > Alternatively it is possible to use an older SyncEvolution command line > with the renamed configurations. In the sync UI they won't show up > because "consumerReady" was unset as part of migrating. > > With that out of the way, here's why updating is worthwhile: >      * improved syncevo-http-server (but the script can also be used >        with 1.1.1) >      * improved command line: "syncevolution --configure >        addressbook/database=My_Address_Book >        calendar/database=My_Calendar mobical addressbook calendar" >      * no more confusion about "type" property > > This was discussed in more detail on the list before, see archive. > > Known issues: > https://bugs.meego.com/show_bug.cgi?id=13301 - printing available > databases broke during "type" removal Two issues. First one is easy, is there a source file? :-) Second one is a query about the libgdbus fork. Its causing me a lot of problems in Fedora. There are now a number of packages using the upstream version including gupnp (which is now used by parts of gnome 3) which is causing problems in Fedora and basically makes syncevolution unusable in a lot of cases. What are the plans on getting your patches upstream?

Two issues. First one is easy, is there a source file? :-)

Second one is a query about the libgdbus fork. Its causing me a lot of problems in Fedora. There are now a number of packages using the upstream version including gupnp (which is now used by parts of gnome 3) which is causing problems in Fedora and basically makes syncevolution unusable in a lot of cases. What are the plans on getting your patches upstream?

Oh and does it have the option to use both gtk2 and gtk3 as evolution and e-d-s for gnome3 will require it if you use any of the e-d-s/evo gui components.

On Thu, Feb 10, 2011 at 7:49 AM, Patrick Ohly <patrick.ohly(a)gmx.de&gt; wrote: > On Mi, 2011-02-09 at 22:28 +0000, Peter Robinson wrote: >> Two issues. First one is easy, is there a source file? :-) > > Yes, but I have been hiding it so that people don't start packaging > it ;-) > > http://downloads.syncevolution.org/syncevolution/sources/experimental/syn... > > Seriously, I'd rather have some folks here on this list test that > version before it gets rolled out to some unsuspecting distro users. The > next version should be suitable for an unstable distro again. I'm not planning on pushing it to an "unsuspecting distro user" I push it through my build system and test that it will compile on Fedora rawhide using gcc 4.6 and all the fun things its introducing to give "upstream" details of any issues so that they may review them within a reasonable time.

> Why is the usage of the Bluez gdbus a problem? I thought we had resolved > the name clash by renaming the symbols in the SyncEvolution source code. Why is the submission of patches upstream a problem?

As for chaanges of namespaces as far as I can tell its been shoved it into a sub directory of syncevolution. The readme in the source tells me as much when it documents the script to split out the patches. With it in a sub directory the standard build of syncevolution doesn't find it because its not in the ld path, if you add it to the path it conflicts with the other library if installed.

> If someone has a patch which allows to switch between the Bluez gdbus > and glib gdbus, then I'd be happy to include it. I just don't have time > to do that myself. Personally I'd prefer if the patches were upstream and there was just one of them and we didn't have to worry about hacks to "switch".

On Do, 2011-02-10 at 08:38 +0100, Patrick Ohly wrote: > On Mi, 2011-02-09 at 19:29 +0000, Frederik Elwert wrote: > > Hi Patrick, > > > > Am Dienstag, den 08.02.2011, 08:55 +0100 schrieb Patrick Ohly: > > > Downgrading is still possible. If you plan to do that, make a copy of > > > ~/.config/syncevolution and restore that later. You'll run into slow > > > syncs; resolve these with an explicit slow sync or refresh syncs. > > > > You mean, slow syncs are expected when downgrading? But a normal upgrade > > should not trigger a slow sync? > > > > I ran into a slow sync after migration with the new version, and I don’t > > know if that was to be expected. The commandline gives me: > > > > [INFO] memo: inactive > > [INFO] calendar: resuming slow sync, two-way > > [INFO] todo: resuming slow sync, two-way > > [INFO] addressbook: starting slow sync, two-way > > [INFO] calendar: resumed slow sync done unsuccessfully > > [ERROR] unexpected slow sync (local, status 22000) > > [INFO] todo: resumed slow sync done unsuccessfully > > [ERROR] unexpected slow sync (local, status 22000) > > [INFO] addressbook: slow sync done unsuccessfully > > [ERROR] local, status 10415 > > [ERROR] error code from Synthesis engine local, status 10415 > > A slow sync after a downgrade from 1.1.99.2 -> 1.1.1 is expected, but > not for the upgrade. I need to test this. In my test, no slow sync was needed after the 1.1.1 -> 1.1.99.2 migration. I find it a bit strange that "resuming slow sync" is mentioned above. That sounds a bit like the previous sync before the migration hadn't completed normally. In that case all bets are off. I don't expect the more recent version to be able to resume an older sync, but I don't know for sure.