6:17 a.m.
Hi!
Okay, long time now see, eh, write. Quick recap:
* SyncEvolution 1.0 beta 1 released, development keeps us busy.
1.0 beta 1 turned out to be fairly stable, but there were bug
fixes (see below). Lots of new features in "master", so consider
compiling that if you want to follow what we are doing.
* 0.9.2 released. Ove Kaaven made it available for Maemo,
including a calendar backend that he wrote.
* Went to FOSDEM last weekend and gave two talks. Slides can be
viewed on our site, video of the Lightning Talk will be posted
by FOSDEM later. See
http://syncevolution.org/blogs/pohly/2010/fosdem-2010
Noteworthy new issues potentially affecting users:
* The packages provided by Ubuntu and Debian did not contain
proper timezone support. Use the packages from syncevolution.org
to work around this (Debian bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565720, Ubuntu
bug https://bugs.launchpad.net/bugs/509032)
* 1.0 beta 1 cannot do Bluetooth sync via GUI because transport is
missing in syncevo-dbus-server (MB #9436, patch pending)
* 1.0 beta 1 has an issue with unintentionally enabling sources
created for one peer in another (MB #9329); when configuring
a peer using the "server" shorthand for a
"server@other-context", properties from the default context were
copied into that other context (MB #9338)
* The Horde Groupware server gets confused by our device ID and
applies workarounds for old, broken Funambol clients to us,
which break calendar sync (MB #9347). Using such device IDs was
necessary at one point for Funambol (wouldn't support multiple
instances otherwise), but that no longer is the case, so can be
fixed by renaming the device ID.
Comment for distributors: there's a new README.packagers file. Please,
consider compiling and packaging the GNOME Bluetooth Panel plugin that
is included in the lastest SyncEvolution source code (not yet in 1.0
beta 1).
Development (by week basically, starting end of last year):
* Yongsheng: D-Bus implementation of client/server interaction for
dialogs in the UIs (MB #6376), used for interactive password
requests, database restore (MB #8144), auto-termination of D-Bus
server and tracking of clients (MB #7710), added support for
X-SKYPE (MB# 8948)
* Congwu: finished "super datastore" (= merged calender/todo),
force slow sync on server-side when requested, discussed and
worked on configuration and pairing of phones (MB #7838/7089),
dealt with feedback about phone syncing (Nokia 6600, N900, N85),
analysis of sync stack in Maemo 5/N900, fixes for OBEX
transport, datastore aliases (MB #7871), don't resend initial
message of sync (MB#8758), removed hard dependency on CPPUnit
header files
* Raji: http_proxy env variable support when using libsoup[-gnome]
(MB #8177), recreating full name when lost on server (MB #5664)
* Patrick: implemented handling of unexpected slow syncs in the
client (MB #2416), Android port, some more Oracle testing
* Yongsheng: syncevo-dbus-server automatic termination when idle
(MB #7711), fixed IO spinner support in D-Bus server,
investigated different sync solutions improved D-Bus testing (MB
#9065), fixed handling of normalized config names in logdir code
(MB #8350)
* Congwu: template handling for SyncML clients, searching for
right template via fuzzy LCS string match and custom code,
assist QA with Bluetooth testing, GNOME Bluetooth panel plugin,
presence detection
* Patrick: CPPUnit header file dependencies (MB #9149), code
merging and distribution fixes, configuration option and
infrastructure for handling unexpected slow syncs (MB #9156,
#2416), normalization of config names when saving to disk (MB
#8350), documentation update for 1.0 (MB #8497), more flexible
support for backend-specific XML configs, avoid exceptions
during normal run, fixed reporting of local errors (MB #8757)
and partially successful syncs (MB #7755), improved printing of
report (MB #2069), added Goosync and Oracle templates, timeouts
for unresponsive clients (MB #7710), "syncevolution --status"
local item counts empty (MB #9097)
* Jussi: fixes for unified configuration dialog, slow sync and
emergency handling
* Raji: investigated timezone conversion issues with Outlook
meeting invitations (MB #4815)
* Yongsheng: finished auto-termination of syncevo-dbus-server (MB
#7711), updated test-dbus.py (MB #9065, may still overwrite
developer's data MB #9332), started to provide more information
via D-Bus API (password MB #9169, first sync flag MB #8729)
* Congwu: presence detection for HTTP
* Patrick: command line screwed up shared properties when using a
shorthand notation for peers in the non-default context (MB
#9338, already broken in 1.0 alpha, found to late for 1.0 beta),
adding sources affects other peers in same context (MB #9329,
found by QA in 1.0 beta), fixed --disable-bluetooth (MB #9260),
fixed source code compatibility with libbluetooth2 and 3 (MB
#9289),
* Jussi: several GTK GUI updates, for example restore from backup
* Yongsheng: GetConfig() includes real passwords (MB #9169),
return first-time sync information via GetReports (MB #8729),
fix for test-dbus.py so that it no longer overwrites normal
local databases (MB #9332), GetConfig() support for Bluetooth
peers (MB #9216, some improvements and debugging left to do, see
MB #9576)
* Congwu: presence detection via ConnMan for HTTP and Bluetooth,
GNOME Bluetooth Panel plugin in SyncEvolution
* Patrick: fix for CheckSource() and virtual sources (MB #9535),
fixes for logdir naming, database dumps now use less disk space
thanks to hard-linking, database comparisons are faster,
database comparison is more intelligent about previous dump (all
part of MB #7708), included Congwu's GNOME Bluetooth Panel
plugin in the SyncEvolution distro (MB #7089), split up XML
config into parts which can be extended/replaced by users and
synchronized with Synthesis upstream (MB #7712)
* Jussi: device configuration, lots of fixes and polishing now
that QA is testing the redesigned UI
--
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.
7:06 a.m.
On Tue, 09 Feb 2010 20:17:31 +0100, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
Noteworthy new issues potentially affecting users:
* The packages provided by Ubuntu and Debian did not contain
proper timezone support. Use the packages from syncevolution.org
to work around this (Debian bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565720, Ubuntu
bug https://bugs.launchpad.net/bugs/509032)
This bug is fixed by the 1.0-alpha packages in Debian experimental.
By the way, what do you think I should aim for in Debian squeeze, given
the freeze is in a few months? My current plan is to try for something
from the 1.0 series.
d
7:10 a.m.
On Di, 2010-02-09 at 20:06 +0000, David Bremner wrote:
On Tue, 09 Feb 2010 20:17:31 +0100, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> Noteworthy new issues potentially affecting users:
> * The packages provided by Ubuntu and Debian did not contain
> proper timezone support. Use the packages from syncevolution.org
> to work around this (Debian bug
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565720, Ubuntu
> bug https://bugs.launchpad.net/bugs/509032)
This bug is fixed by the 1.0-alpha packages in Debian experimental.
Thanks for the update. I knew that you had fixed it, but didn't quite
follow up on when this will reach users.
By the way, what do you think I should aim for in Debian squeeze,
given
the freeze is in a few months? My current plan is to try for something
from the 1.0 series.
Yes, definitely. I intend to put out further betas as the code
stabilizes. Until when can you incorporate further updates? A guestimate
is enough.
--
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.
8:19 a.m.
On Tue, 09 Feb 2010 21:10:58 +0100, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> This bug is fixed by the 1.0-alpha packages in Debian
experimental.
Thanks for the update. I knew that you had fixed it, but didn't quite
follow up on when this will reach users.
Experimental is for software that "might lose your data". If you think
it is a good idea, I can upload a beta to unstable where it will get
more testing (and I assume migrate to Ubuntu).
> By the way, what do you think I should aim for in Debian
squeeze, given
> the freeze is in a few months? My current plan is to try for something
> from the 1.0 series.
Yes, definitely. I intend to put out further betas as the code
stabilizes. Until when can you incorporate further updates? A guestimate
is enough.
Aparently the freeze in March is now "highly unlikely", so I should be
able to incorporate fixes into early April.
d
10:08 p.m.
New subject: [SyncEvolution] SyncEvolution on Debian/Ubuntu (was: Re: status 2010-02-09)
Il giorno mar, 09/02/2010 alle 17.19 -0400, David Bremner ha scritto:
On Tue, 09 Feb 2010 21:10:58 +0100, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> > This bug is fixed by the 1.0-alpha packages in Debian experimental.
>
> Thanks for the update. I knew that you had fixed it, but didn't quite
> follow up on when this will reach users.
Experimental is for software that "might lose your data". If you think
it is a good idea, I can upload a beta to unstable where it will get
more testing (and I assume migrate to Ubuntu).
Just for your information:
- for Ubuntu Lucid (out in April), the date for the "Debian Import
Freeze", after which Debian packages are no more automatically imported
from Debian, is unfortunately tomorrow (feb. 11).
- there is another deadline, on the 18th, after which even the "import
on explicit request" mechanism generally stops. Even assuming that the
migration from Debian unstable to testing is as fast as possible (10
days), it's too late, but still, if the package happens to land in
unstable few days after the 18th, I think an exception could be
obtained.
That said, just as a user, I'm a bit confused about the difference
between packages named "syncevolution-evolution" and the ones just named
"syncevolution"... is there any (not considering versions)?
thanks for any clarification
Pietro
11:22 p.m.
New subject: [SyncEvolution] SyncEvolution on Debian/Ubuntu (was: Re: status 2010-02-09)
On Mi, 2010-02-10 at 11:08 +0000, Pietro Battiston wrote:
Il giorno mar, 09/02/2010 alle 17.19 -0400, David Bremner ha
scritto:
> On Tue, 09 Feb 2010 21:10:58 +0100, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
> > > This bug is fixed by the 1.0-alpha packages in Debian experimental.
> >
> > Thanks for the update. I knew that you had fixed it, but didn't quite
> > follow up on when this will reach users.
>
> Experimental is for software that "might lose your data". If you think
> it is a good idea, I can upload a beta to unstable where it will get
> more testing (and I assume migrate to Ubuntu).
Beta 1 might mangle up config data, but only when doing unusual things.
Better wait for beta 2. We just merged a bunch of code into master for
the GUI, so let's give it another week or two to stabilize and getting
tested.
Just for your information:
- for Ubuntu Lucid (out in April), the date for the "Debian Import
Freeze", after which Debian packages are no more automatically imported
from Debian, is unfortunately tomorrow (feb. 11).
- there is another deadline, on the 18th, after which even the "import
on explicit request" mechanism generally stops. Even assuming that the
migration from Debian unstable to testing is as fast as possible (10
days), it's too late, but still, if the package happens to land in
unstable few days after the 18th, I think an exception could be
obtained.
So 1.0 won't make it. Is there a chance to get a 0.9.2 compiled properly
(libical used by libsynthesis) into Lucid? Does that depend on David
updating something or can the Ubuntu team do the update themselves?
0.9.2 is stable and has some worthwhile, albeit not essential
improvements over 0.9.1
That said, just as a user, I'm a bit confused about the
difference
between packages named "syncevolution-evolution" and the ones just named
"syncevolution"... is there any (not considering versions)?
There's no difference at the moment. The reason for picking
"syncevolution-evolution" was that this was SyncEvolution with the
Evolution backend included. There still is the possibility that other
backends will have to be packaged, at which point a "syncevolution"
package should only contain the platform independent core.
--
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.
11:54 p.m.
New subject: [SyncEvolution] SyncEvolution on Debian/Ubuntu (was: Re: status 2010-02-09)
On Wed, 10 Feb 2010 13:22:41 +0100, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
So 1.0 won't make it. Is there a chance to get a 0.9.2 compiled properly
(libical used by libsynthesis) into Lucid? Does that depend on David
updating something or can the Ubuntu team do the update themselves?
Unfortunately I'm not sure who, if anyone, is doing the port to
Ubuntu. It may just be a script.
The current libsynthesis packages in Debian experimental might be
worthwhile for Ubuntu, since they are compiled against libical. If a
few people would test them against syncevolution 0.9.1 or 0.9.2, I could
arrange to have them uploaded to unstable. That would make it plausible
to package 0.9.2, since packaging two versions of libsynthesis is a bit
of a pain, and my goal for Debian at this point is 1.0 betaX.
d
1:30 a.m.
New subject: [SyncEvolution] SyncEvolution on Debian/Ubuntu (was: Re: status 2010-02-09)
Il giorno mer, 10/02/2010 alle 08.54 -0400, David Bremner ha scritto:
On Wed, 10 Feb 2010 13:22:41 +0100, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
>
> So 1.0 won't make it. Is there a chance to get a 0.9.2 compiled properly
> (libical used by libsynthesis) into Lucid? Does that depend on David
> updating something or can the Ubuntu team do the update themselves?
Unfortunately I'm not sure who, if anyone, is doing the port to
Ubuntu. It may just be a script.
It generally is, but since we are late I can take care of the "pressing"
which should get 0.9.2 in anyway (since it does more bugfixing than
adding new features, I think it will be almost straighforward).
The current libsynthesis packages in Debian experimental might be
worthwhile for Ubuntu, since they are compiled against libical. If a
few people would test them against syncevolution 0.9.1 or 0.9.2, I could
arrange to have them uploaded to unstable. That would make it plausible
to package 0.9.2, since packaging two versions of libsynthesis is a bit
of a pain, and my goal for Debian at this point is 1.0 betaX.
I will try.
(Any quick pointer on what is the fastest way?
So far, I only tested syncevolution with scheduleworld but my free
account expired, and setting up a funambol server slightly scares me
out.)
Pietro
1:37 a.m.
New subject: [SyncEvolution] SyncEvolution on Debian/Ubuntu (was: Re: status 2010-02-09)
On Wed, 10 Feb 2010 15:30:15 +0100, Pietro Battiston <toobaz(a)email.it> wrote:
I will try.
(Any quick pointer on what is the fastest way?
So far, I only tested syncevolution with scheduleworld but my free
account expired, and setting up a funambol server slightly scares me
out.)
You can try my.funambol.com
They at least have 90 day trials; afaik my account there is "permanent
until not", but maybe this is some grandfather clause.
d
11:07 a.m.
New subject: [SyncEvolution] SyncEvolution on Debian/Ubuntu (was: Re: status 2010-02-09)
Il giorno mer, 10/02/2010 alle 15.30 +0100, Pietro Battiston ha scritto:
Il giorno mer, 10/02/2010 alle 08.54 -0400, David Bremner ha
scritto:
> On Wed, 10 Feb 2010 13:22:41 +0100, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
> >
> > So 1.0 won't make it. Is there a chance to get a 0.9.2 compiled properly
> > (libical used by libsynthesis) into Lucid? Does that depend on David
> > updating something or can the Ubuntu team do the update themselves?
>
> Unfortunately I'm not sure who, if anyone, is doing the port to
> Ubuntu. It may just be a script.
It generally is, but since we are late I can take care of the "pressing"
which should get 0.9.2 in anyway (since it does more bugfixing than
adding new features, I think it will be almost straighforward).
> The current libsynthesis packages in Debian experimental might be
> worthwhile for Ubuntu, since they are compiled against libical. If a
> few people would test them against syncevolution 0.9.1 or 0.9.2, I could
> arrange to have them uploaded to unstable. That would make it plausible
> to package 0.9.2, since packaging two versions of libsynthesis is a bit
> of a pain, and my goal for Debian at this point is 1.0 betaX.
>
I will try.
OK, tested libsynthesis 3.2.0.35+ds2-1 in Debian sid (against
syncevolution 0.9.1+ds1-1) and in Ubuntu Karmic (against 0.9+ds1-2,
through and without genesis-sync), with addressbook, memos and calendar.
It seems to be working great, just a couple of observations (which, as
far as I can tell, pertain to syncevolution in general):
- the first thing I tried to do was to get all my stuff from
scheduleworld to a Debian where I had never used Evolution: more
precisely, I _had_ started it once and registered an email address, but
I had never used the addressbook. The sync failed giving a "500" error.
All was needed to make it work was to switch to the addressbook view of
Evolution (I didn't even have to create some contact, just visualizing
it was enough) - then, syncs started working. This happened in a Debian
sid: if you are unable to reproduce, I can try to get more informations.
- when I sync (apart from the first time), before starting any network
communication, a perl process spawned by syncevolution starts consuming
all the CPU (a Turion at 2.10 Ghz) for something less than a minute (I
have ~3000 contacts). If it's necessary and known, no particular
problem: though maybe perl is not the perfect language for such
CPU-intensive task, you guys certainly know better than me... still, I
wanted to point it out because for (as far as I know) the same task my 6
years old Nokia E65 takes certainly less time.
But in general, from my view this version of libsynthesis is absolutely
ready for unstable (and beyond!).
Pietro
4:07 a.m.
New subject: [SyncEvolution] SyncEvolution on Debian/Ubuntu (was: Re: status 2010-02-09)
On Sun, 14 Feb 2010 01:07:11 +0100, Pietro Battiston <toobaz(a)email.it> wrote:
But in general, from my view this version of libsynthesis is absolutely
ready for unstable (and beyond!).
libsynthesis 3.2.0.35+ds2-2 was just uploaded to Debian/unstable.
As I think I mentioned before, my next planned upload of syncevolution
is 1.0beta2, when that is ready.
David
5:41 a.m.
New subject: [SyncEvolution] SyncEvolution on Debian/Ubuntu (was: Re: status 2010-02-09)
On So, 2010-02-14 at 00:07 +0000, Pietro Battiston wrote:
It seems to be working great, just a couple of observations (which,
as
far as I can tell, pertain to syncevolution in general):
Correct.
- the first thing I tried to do was to get all my stuff from
scheduleworld to a Debian where I had never used Evolution: more
precisely, I _had_ started it once and registered an email address, but
I had never used the addressbook. The sync failed giving a "500" error.
All was needed to make it work was to switch to the addressbook view of
Evolution (I didn't even have to create some contact, just visualizing
it was enough) - then, syncs started working. This happened in a Debian
sid: if you are unable to reproduce, I can try to get more informations.
I can reproduce it. In fact, it is a known issue and even listed as such
on syncevolution.org ;-) I understand that a better solution inside the
program would be nice, but I'm not sure what to do about it. The system
address book is listed by libebook, but isn't usable unless Evolution
does something to create it.
- when I sync (apart from the first time), before starting any
network
communication, a perl process spawned by syncevolution starts consuming
all the CPU (a Turion at 2.10 Ghz) for something less than a minute (I
have ~3000 contacts). If it's necessary and known, no particular
problem: though maybe perl is not the perfect language for such
CPU-intensive task, you guys certainly know better than me...
The synccompare script is very regex-heavy, so for that Perl was a
better language and more widely available than the corresponding C++
libs. But yes, a rewrite in C++ would be nice, and has been on the list
for a while: http://bugzilla.moblin.org/show_bug.cgi?id=2432
On the other hand, with some changes that I have pending for
SyncEvolution 1.0, synccompare will be a lot faster for most cases
because common item files will not be included in the slow
diff/normalization part.
--
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.
4599
days inactive
4604
days old
syncevolution@synevolution.org
11 comments
3 participants
participants (3)
-
David Bremner -
Patrick Ohly -
Pietro Battiston