From patrick.ohly at gmx.de Tue Feb 8 07:55:53 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Tue, 08 Feb 2011 08:55:53 +0100 Subject: SyncEvolution 1.1.99.2 ready for testing Message-ID: <1297151753.29566.46.camel@pohly-mobl1.ikn.intel.com> 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 -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From pbrobinson at gmail.com Wed Feb 9 22:28:09 2011 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 9 Feb 2011 22:28:09 +0000 Subject: [SyncEvolution] SyncEvolution 1.1.99.2 ready for testing In-Reply-To: <1297151753.29566.46.camel@pohly-mobl1.ikn.intel.com> References: <1297151753.29566.46.camel@pohly-mobl1.ikn.intel.com> Message-ID: Hi Patrick, On Tue, Feb 8, 2011 at 7:55 AM, Patrick Ohly 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? Peter From pbrobinson at gmail.com Wed Feb 9 23:24:24 2011 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 9 Feb 2011 23:24:24 +0000 Subject: [SyncEvolution] SyncEvolution 1.1.99.2 ready for testing In-Reply-To: References: <1297151753.29566.46.camel@pohly-mobl1.ikn.intel.com> Message-ID: On Wed, Feb 9, 2011 at 10:28 PM, Peter Robinson wrote: > Hi Patrick, > > On Tue, Feb 8, 2011 at 7:55 AM, Patrick Ohly 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? 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. Peter From patrick.ohly at gmx.de Thu Feb 10 07:49:19 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Thu, 10 Feb 2011 08:49:19 +0100 Subject: [SyncEvolution] SyncEvolution 1.1.99.2 ready for testing In-Reply-To: References: <1297151753.29566.46.camel@pohly-mobl1.ikn.intel.com> Message-ID: <1297324159.5364.31.camel@pohly-mobl1.ikn.intel.com> 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/syncevolution-1.1.99.2.tar.gz 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. > 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? If you talk about the gdbus in glib [1], that is not the upstream of the code in SyncEvolution. The upstream is the older gdbus from Marcel Holtmann [2] from the Bluez tools. 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. 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. > 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. No, there's no support for gtk3. The sync-ui is the only component using GTK. It's a stand-alone process, so hopefully it'll continue to work even if the rest of the system moves to gtk3. The EDS backends will need some work to cope with API changes in Evolution 3.0 - not done yet, patches welcome :-/ [1] http://library.gnome.org/devel//gio/2.26/gdbus.html [2] http://git.kernel.org/?p=bluetooth/libgdbus.git;a=summary -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From pbrobinson at gmail.com Thu Feb 10 09:44:30 2011 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 10 Feb 2011 09:44:30 +0000 Subject: [SyncEvolution] SyncEvolution 1.1.99.2 ready for testing In-Reply-To: <1297324159.5364.31.camel@pohly-mobl1.ikn.intel.com> References: <1297151753.29566.46.camel@pohly-mobl1.ikn.intel.com> <1297324159.5364.31.camel@pohly-mobl1.ikn.intel.com> Message-ID: On Thu, Feb 10, 2011 at 7:49 AM, Patrick Ohly 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/syncevolution-1.1.99.2.tar.gz > > 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. >> 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? > > If you talk about the gdbus in glib [1], that is not the upstream of the > code in SyncEvolution. The upstream is the older gdbus from Marcel > Holtmann [2] from the Bluez tools. Yes, the one from Marcel is the one I'm talking about (we've had this conversation before and I do remember it). > 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". >> 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. > > No, there's no support for gtk3. The sync-ui is the only component using > GTK. It's a stand-alone process, so hopefully it'll continue to work > even if the rest of the system moves to gtk3. The EDS backends will need > some work to cope with API changes in Evolution 3.0 - not done yet, > patches welcome :-/ > > [1] http://library.gnome.org/devel//gio/2.26/gdbus.html > [2] http://git.kernel.org/?p=bluetooth/libgdbus.git;a=summary > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. From patrick.ohly at gmx.de Thu Feb 10 10:07:39 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Thu, 10 Feb 2011 11:07:39 +0100 Subject: [SyncEvolution] SyncEvolution 1.1.99.2 ready for testing In-Reply-To: References: <1297151753.29566.46.camel@pohly-mobl1.ikn.intel.com> <1297324159.5364.31.camel@pohly-mobl1.ikn.intel.com> Message-ID: <1297332459.5364.58.camel@pohly-mobl1.ikn.intel.com> On Do, 2011-02-10 at 09:44 +0000, Peter Robinson wrote: > On Thu, Feb 10, 2011 at 7:49 AM, Patrick Ohly 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/syncevolution-1.1.99.2.tar.gz > > > > 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. That's of course worthwhile - thanks for testing that. > > 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? I submitted them and Marcel has not responded, that's all. My impression is that the separate Bluez gdbus is dead and will never see a separate, official release. So in Fedora there really is a separate library and gupnp uses it? > 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. I'm not seeing the issue with it not being found during the build. What is your configure line? Regarding the library name clash: I agree, the library name should be different and it should get installed into /usr/lib/syncevolution. I'll check that. > > 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". Yes, of course. Me too, but that's outside of my control. I was thinking of the glib gdbus here. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.