7:48 a.m.
Hello!
I've made binaries of the current SyncEvolution development snapshot
available. You can get them from the "experimental" apt repository
(.deb) and http://downloads.syncevolution.org/syncevolution/evolution/
(.rpm).
Instead of the previous "alpha" or "beta" denominators as part of the
version name, I've switched to the rpm method of "next version minus 1
in the last position". So this snapshot is version 1.0.99.6 (> 1.0.x for
any kind of realistic x, < 1.1). The .6 stems from the fact that there
have been earlier snapshots in MeeGo.
This release should be pretty stable, but is not yet quite feature
complete for 1.1.
Full NEWS file below. If possible, I'd like to get feedback from
nudelzebra(a)web.de on issue 4026 and from Frederik on the implementation
of the various D-Bus API improvements.
* Nokia phones: avoid data loss in two-way sync due to X-EVOLUTION-UI-SLOT (MBC #2566)
* Nokia phones: alarm times in UTC, sending PHOTO (BMC #1657, #5860)
* included all phone templates submitted to syncevolution.org Wiki (BMC #5727)
* syncevo-phone-config: set consumerReady in output, more useful for Wiki (BMC #3803)
* workaround for D-Bus timeouts in EDS libecal/libebook (MBC #4026)
* sync-ui (GTK version): app is now listed as "SyncEvolution (GTK)" under
"Office"
* added generic command line options for importing, exporting, updating, listing
and deleting items in the different backends
(http://syncevolution.org/blogs/pohly/2010/manipulate-evolution-kcalextend...)
* added backends for mKCal and QtContacts (MeeGo PIM storage),
meant to be used for manipulating this data on the command line
* enhanced D-Bus interface (BMC #3558, #3559, #3560, #3562, #3563)
* the command line tool now warns when running against a different D-Bus daemon (BMC
#3563)
* creating and configuring sources in a context (without peer-specific
properties) is now supported
* improved documentation: README.rst, man page, and --help output
* fixed some compile issues (MBC #6367), improved nightly testing
--
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:40 a.m.
Hi.
I just tried the builds (deb) and unfortunately got the same error
(10510) as before. If it does make any difference: I even tried a
different server (memotoo) and also tested your pre-release on Ubuntu
Maverick beta with the same result.
Greetings.
Nudelzebra
Am Freitag, den 10.09.2010, 14:48 +0200 schrieb Patrick Ohly:
Hello!
I've made binaries of the current SyncEvolution development snapshot
available. You can get them from the "experimental" apt repository
(.deb) and http://downloads.syncevolution.org/syncevolution/evolution/
(.rpm).
Instead of the previous "alpha" or "beta" denominators as part of
the
version name, I've switched to the rpm method of "next version minus 1
in the last position". So this snapshot is version 1.0.99.6 (> 1.0.x for
any kind of realistic x, < 1.1). The .6 stems from the fact that there
have been earlier snapshots in MeeGo.
This release should be pretty stable, but is not yet quite feature
complete for 1.1.
Full NEWS file below. If possible, I'd like to get feedback from
nudelzebra(a)web.de on issue 4026 and from Frederik on the implementation
of the various D-Bus API improvements.
* Nokia phones: avoid data loss in two-way sync due to X-EVOLUTION-UI-SLOT (MBC #2566)
* Nokia phones: alarm times in UTC, sending PHOTO (BMC #1657, #5860)
* included all phone templates submitted to syncevolution.org Wiki (BMC #5727)
* syncevo-phone-config: set consumerReady in output, more useful for Wiki (BMC #3803)
* workaround for D-Bus timeouts in EDS libecal/libebook (MBC #4026)
* sync-ui (GTK version): app is now listed as "SyncEvolution (GTK)" under
"Office"
* added generic command line options for importing, exporting, updating, listing
and deleting items in the different backends
(http://syncevolution.org/blogs/pohly/2010/manipulate-evolution-kcalextend...)
* added backends for mKCal and QtContacts (MeeGo PIM storage),
meant to be used for manipulating this data on the command line
* enhanced D-Bus interface (BMC #3558, #3559, #3560, #3562, #3563)
* the command line tool now warns when running against a different D-Bus daemon (BMC
#3563)
* creating and configuring sources in a context (without peer-specific
properties) is now supported
* improved documentation: README.rst, man page, and --help output
* fixed some compile issues (MBC #6367), improved nightly testing
1:47 p.m.
On Fri, 2010-09-10 at 17:40 +0100, Nudelzebra wrote:
Hi.
I just tried the builds (deb) and unfortunately got the same error
(10510) as before.
Please run "dbus-monitor >/tmp/dbus.log &" and "dbus-monitor
--profile
/tmp/profile.log" before starting syncevolution, then send me the
files. I'd like to check what the timeouts are.
Also please run "LD_DEBUG=all syncevolution --daemon=no ... >/tmp/ld.log
2>&1" and also send me that.
--
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:19 a.m.
New subject: [SyncEvolution] sync fails with error "(timeout by message bus)" (MBC #4026 was Re: SyncEvolution 1.1 pre-release)
On Fri, 2010-09-10 at 19:47 +0100, Patrick Ohly wrote:
On Fri, 2010-09-10 at 17:40 +0100, Nudelzebra wrote:
> Hi.
>
> I just tried the builds (deb) and unfortunately got the same error
> (10510) as before.
Please run "dbus-monitor >/tmp/dbus.log &" and "dbus-monitor
--profile
>/tmp/profile.log" before starting syncevolution, then send me the
files. I'd like to check what the timeouts are.
Thanks for the logs. They show that the EDS calendar server dies
(combination of monitor and profile log):
mc 1284371457 118043 73 :1.129 /org/gnome/evolution/dataserver/calendar/1671/8 org.gnome.evolution.dataserver.calendar.Cal getObjectList
method call sender=:1.129 -> dest=:1.38 serial=73
path=/org/gnome/evolution/dataserver/calendar/1671/8;
interface=org.gnome.evolution.dataserver.calendar.Cal; member=getObjectList
string "#t"
sig 1284371457 136208 5 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=5
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string "org.gnome.evolution.dataserver.Calendar"
string ":1.38"
string ""
sig 1284371457 144230 16 /org/freedesktop/DBus org.freedesktop.DBus NameOwnerChanged
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=16
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.38"
string ":1.38"
string ""
What this probably means is that 136208 - 118043 = 18ms after receiving
the getObjectList() method call, the e-calendar-factory process
disconnects from D-Bus. It probably crashed.
That libecal turns this error into a "Message did not receive a reply
(timeout by message bus)" error has been extremely helpful :-( Not!
Can you verify this by stopping Evolution completely (exit GUI,
evolution --force-shutdown), then running e-calendar-factory under gdb
(usually installed in /usr/libexec, check with ps while Evolution runs)?
While it runs, start a sync with SyncEvolution. No need for D-Buslogs,
but when the gdb prompt returns, please capture the output of "thread
apply all bt". Doing the same with "valgrind" instead of gdb would also
be useful.
Which version of Evolution do you use?
--
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.
5:01 p.m.
On Fri, Sep 10, 2010 at 1:48 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
Hello!
I've made binaries of the current SyncEvolution development snapshot
available. You can get them from the "experimental" apt repository
(.deb) and http://downloads.syncevolution.org/syncevolution/evolution/
(.rpm).
Instead of the previous "alpha" or "beta" denominators as part of
the
version name, I've switched to the rpm method of "next version minus 1
in the last position". So this snapshot is version 1.0.99.6 (> 1.0.x for
any kind of realistic x, < 1.1). The .6 stems from the fact that there
have been earlier snapshots in MeeGo.
Any reason why there's not a source tar ball to go with the binary releases?
Regards,
Peter
8:09 a.m.
On Fri, 2010-09-10 at 23:01 +0100, pbrobinson(a)gmail.com wrote:
On Fri, Sep 10, 2010 at 1:48 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> Hello!
>
> I've made binaries of the current SyncEvolution development snapshot
> available. You can get them from the "experimental" apt repository
> (.deb) and http://downloads.syncevolution.org/syncevolution/evolution/
> (.rpm).
>
> Instead of the previous "alpha" or "beta" denominators as part
of the
> version name, I've switched to the rpm method of "next version minus 1
> in the last position". So this snapshot is version 1.0.99.6 (> 1.0.x for
> any kind of realistic x, < 1.1). The .6 stems from the fact that there
> have been earlier snapshots in MeeGo.
Any reason why there's not a source tar ball to go with the binary releases?
Ah, caught guilty. The only reason is that I didn't bother, because
anyone interested in source code at this point is better of pulling
directly from the "master" branches in the git repos.
But now there's also a .tar.gz.
--
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.
12:24 p.m.
On Sun, Sep 12, 2010 at 2:09 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Fri, 2010-09-10 at 23:01 +0100, pbrobinson(a)gmail.com wrote:
> On Fri, Sep 10, 2010 at 1:48 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > Hello!
> >
> > I've made binaries of the current SyncEvolution development snapshot
> > available. You can get them from the "experimental" apt repository
> > (.deb) and http://downloads.syncevolution.org/syncevolution/evolution/
> > (.rpm).
> >
> > Instead of the previous "alpha" or "beta" denominators as
part of the
> > version name, I've switched to the rpm method of "next version minus 1
> > in the last position". So this snapshot is version 1.0.99.6 (> 1.0.x
for
> > any kind of realistic x, < 1.1). The .6 stems from the fact that there
> > have been earlier snapshots in MeeGo.
>
> Any reason why there's not a source tar ball to go with the binary releases?
Ah, caught guilty. The only reason is that I didn't bother, because
anyone interested in source code at this point is better of pulling
directly from the "master" branches in the git repos.
But now there's also a .tar.gz.
I maybe going blind as I still don't see one there.
Peter
1:50 p.m.
On Mon, 2010-09-13 at 18:24 +0100, pbrobinson(a)gmail.com wrote:
On Sun, Sep 12, 2010 at 2:09 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Fri, 2010-09-10 at 23:01 +0100, pbrobinson(a)gmail.com wrote:
>> Any reason why there's not a source tar ball to go with the binary
releases?
>
> Ah, caught guilty. The only reason is that I didn't bother, because
> anyone interested in source code at this point is better of pulling
> directly from the "master" branches in the git repos.
>
> But now there's also a .tar.gz.
I maybe going blind as I still don't see one there.
http://downloads.syncevolution.org/syncevolution/sources/syncevolution-1....
The ordering is a bit awkward. Perhaps I should move away the "alpha"
and "beta" releases into a sub-folder "archives" to align the
alphabetically sorted files with release order?
--
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.
4:57 p.m.
On Mon, Sep 13, 2010 at 7:50 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mon, 2010-09-13 at 18:24 +0100, pbrobinson(a)gmail.com wrote:
> On Sun, Sep 12, 2010 at 2:09 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > On Fri, 2010-09-10 at 23:01 +0100, pbrobinson(a)gmail.com wrote:
> >> Any reason why there's not a source tar ball to go with the binary
releases?
> >
> > Ah, caught guilty. The only reason is that I didn't bother, because
> > anyone interested in source code at this point is better of pulling
> > directly from the "master" branches in the git repos.
> >
> > But now there's also a .tar.gz.
>
> I maybe going blind as I still don't see one there.
http://downloads.syncevolution.org/syncevolution/sources/syncevolution-1....
Thanks! To compile on Fedora 13 and later I need the following patch
to compile it and the -gtk.desktop file is missing a ';' at the end of
the category field.
Cheers,
Peter
2 a.m.
On Wed, 2010-09-15 at 22:57 +0100, pbrobinson(a)gmail.com wrote:
On Mon, Sep 13, 2010 at 7:50 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Mon, 2010-09-13 at 18:24 +0100, pbrobinson(a)gmail.com wrote:
>> On Sun, Sep 12, 2010 at 2:09 PM, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
>> > On Fri, 2010-09-10 at 23:01 +0100, pbrobinson(a)gmail.com wrote:
>> >> Any reason why there's not a source tar ball to go with the binary
releases?
>> >
>> > Ah, caught guilty. The only reason is that I didn't bother, because
>> > anyone interested in source code at this point is better of pulling
>> > directly from the "master" branches in the git repos.
>> >
>> > But now there's also a .tar.gz.
>>
>> I maybe going blind as I still don't see one there.
>
>
http://downloads.syncevolution.org/syncevolution/sources/syncevolution-1....
Thanks! To compile on Fedora 13 and later I need the following patch
to compile it
[gtk+-2.0 added to PKG_CHECK_MODULES(LIBNOTIFY...]
On Debian, /usr/lib/pkgconfig/libnotify.pc contains a "Requires:
gtk-2.0" part. That is the correct solution to the problem. Is there a
chance to get that fixed in Fedora soonish? Otherwise I'll apply the
patch as a work around.
and the -gtk.desktop file is missing a ';' at the end of
the category field.
Oh, thanks for pointing that out.
--
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.
2:16 a.m.
On Thu, Sep 16, 2010 at 8:00 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Wed, 2010-09-15 at 22:57 +0100, pbrobinson(a)gmail.com wrote:
> On Mon, Sep 13, 2010 at 7:50 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > On Mon, 2010-09-13 at 18:24 +0100, pbrobinson(a)gmail.com wrote:
> >> On Sun, Sep 12, 2010 at 2:09 PM, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
> >> > On Fri, 2010-09-10 at 23:01 +0100, pbrobinson(a)gmail.com wrote:
> >> >> Any reason why there's not a source tar ball to go with the
binary releases?
> >> >
> >> > Ah, caught guilty. The only reason is that I didn't bother,
because
> >> > anyone interested in source code at this point is better of pulling
> >> > directly from the "master" branches in the git repos.
> >> >
> >> > But now there's also a .tar.gz.
> >>
> >> I maybe going blind as I still don't see one there.
> >
> >
http://downloads.syncevolution.org/syncevolution/sources/syncevolution-1....
>
> Thanks! To compile on Fedora 13 and later I need the following patch
> to compile it
[gtk+-2.0 added to PKG_CHECK_MODULES(LIBNOTIFY...]
On Debian, /usr/lib/pkgconfig/libnotify.pc contains a "Requires:
gtk-2.0" part. That is the correct solution to the problem. Is there a
chance to get that fixed in Fedora soonish? Otherwise I'll apply the
patch as a work around.
We already require gtk2 in Fedora. This started to break with the
introduction of gtk3. Apparently from gnome upstream the patch is the
proper way to fix it (according to upstream) with the introduction of
gtk3.
> and the -gtk.desktop file is missing a ';' at the end
of
> the category field.
Oh, thanks for pointing that out
No probs.
Peter
2:40 p.m.
Hello!
Am Freitag, den 10.09.2010, 14:48 +0200 schrieb Patrick Ohly:
Full NEWS file below. If possible, I'd like to get feedback from
nudelzebra(a)web.de on issue 4026 and from Frederik on the implementation
of the various D-Bus API improvements.
I just came back from my holidays, so I didn’t have a closer look yet.
But I’ll try to dig into that as soon as possible.
* enhanced D-Bus interface (BMC #3558, #3559, #3560, #3562, #3563)
I already built capability checking into Genesis, now I’ll implement the
new methods one by one in a backwards compatible way.
Regards,
Frederik
4:08 p.m.
Hi Patrick and all,
the new DBus API extensions work like charm! I now make use of them in
Genesis when available.
I just ran into one issue: When calling syncevolution from the
commandline, the session methods are not available.
I want to check for session flags, since Genesis should not show sync
result reports for config sessions. And if I understood correctly, the
commandline sets a "no-sync" flag in these cases. But if I run
syncevolution --print-sessions scheduleworld
from the commandline, I get an exception:
DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method
"GetFlags" with signature "" on interface
"org.syncevolution.Session" doesn't exist
(I get the same error for GetConfigName for commandline sessions.)
The same methods work fine when running sessions from Genesis itself.
Maybe you have an idea what’s going wrong here?
Regards,
Frederik
1:56 a.m.
On Wed, 2010-09-15 at 22:08 +0100, Frederik Elwert wrote:
the new DBus API extensions work like charm! I now make use of them
in
Genesis when available.
Good :-)
I just ran into one issue: When calling syncevolution from the
commandline, the session methods are not available.
I want to check for session flags, since Genesis should not show sync
result reports for config sessions. And if I understood correctly, the
commandline sets a "no-sync" flag in these cases. But if I run
syncevolution --print-sessions scheduleworld
from the commandline, I get an exception:
DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method
"GetFlags" with signature "" on interface
"org.syncevolution.Session" doesn't exist
Do you get this exception inside Genesis?
Is it possible that the command line session has already terminated at
the time when Genesis tries to make that call? "dbus-monitor" will show
that.
--
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.
3:10 p.m.
Hi,
Am Donnerstag, den 16.09.2010, 08:56 +0200 schrieb Patrick Ohly:
On Wed, 2010-09-15 at 22:08 +0100, Frederik Elwert wrote:
> the new DBus API extensions work like charm! I now make use of them in
> Genesis when available.
Good :-)
> I just ran into one issue: When calling syncevolution from the
> commandline, the session methods are not available.
>
> I want to check for session flags, since Genesis should not show sync
> result reports for config sessions. And if I understood correctly, the
> commandline sets a "no-sync" flag in these cases. But if I run
>
> syncevolution --print-sessions scheduleworld
>
> from the commandline, I get an exception:
>
> DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method
> "GetFlags" with signature "" on interface
> "org.syncevolution.Session" doesn't exist
Do you get this exception inside Genesis?
Yes, it is inside the StatusChanged handler.
Is it possible that the command line session has already terminated
at
the time when Genesis tries to make that call? "dbus-monitor" will show
that.
That seems to be the problem. There is a race condition between the
session terminating and the StatusChanged callback being executed. I
tried it some times with dbus-monitor running, and sometimes it ran
through, sometimes it threw the exception at the first method call
(GetFlags), sometimes at the second one (GetConfigName).
I don’t really now how to deal with this. This affects all sessions
created by other clients (sync-ui, commandline). When the session sends
the StatusChanged signal "done", I want to get two things: the flags (if
"no-sync", don’t need to report anything) and the config name (to
include it in the sync report). But if the session already terminated at
that point, I cannot request this information.
From Genesis’ side, I could catch the exceptions and ignore them
(i.e.,
act as I did before the new methods were introduced). Should work, but
maybe is not really pretty. Another idea would be to allow other clients
to Attach() to sessions to prevent them from terminating before they are
dealt with. But I don’t know if this is really reasonable.
Maybe I am just overlooking a more obvious solution, so any hints
welcome. :-)
Regards,
Frederik
3:02 a.m.
On Do, 2010-09-16 at 21:10 +0100, Frederik Elwert wrote:
From Genesis’ side, I could catch the exceptions and ignore them
(i.e.,
act as I did before the new methods were introduced). Should work, but
maybe is not really pretty. Another idea would be to allow other clients
to Attach() to sessions to prevent them from terminating before they are
dealt with.
That *is* already allowed :-) Whether it works is a different question,
but it should.
But I don’t know if this is really reasonable.
I think it is. You still have a race condition, though. The Attach()
method itself may arrive too late. In that case it seems reasonable to
me to catch the exception and ignore the session.
I could also introduce a delayed clean up of completed sessions. For
example, keep them around 1 minute after the last client has detached,
just in case that someone is still interested in the session's
attributes.
--
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.
1:58 p.m.
Am Freitag, den 17.09.2010, 10:02 +0200 schrieb Patrick Ohly:
On Do, 2010-09-16 at 21:10 +0100, Frederik Elwert wrote:
> From Genesis’ side, I could catch the exceptions and ignore them (i.e.,
> act as I did before the new methods were introduced). Should work, but
> maybe is not really pretty. Another idea would be to allow other clients
> to Attach() to sessions to prevent them from terminating before they are
> dealt with.
That *is* already allowed :-) Whether it works is a different question,
but it should.
Oh, I missed that. Regarding to [1], there is a Detach() method, but not
Attach(). But maybe that’t not even required.
[1]
http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/sr...
> But I don’t know if this is really reasonable.
I think it is. You still have a race condition, though. The Attach()
method itself may arrive too late. In that case it seems reasonable to
me to catch the exception and ignore the session.
I do now catch the exceptions, but this is not really a final solution.
Ignoring sessions that throw the exception would break result reporting
for sync-ui sessions altogether, and just ignoring the exceptions brings
us to the old situation before the new features were introduced.
I could also introduce a delayed clean up of completed sessions. For
example, keep them around 1 minute after the last client has detached,
just in case that someone is still interested in the session's
attributes.
In my eyes, this sounds like a very simple and good solution. It gives
clients enough time to request session information (or attach to the
session if they need it to exist longer than the built-in interval).
Regards,
Frederik
9:56 a.m.
On Di, 2010-09-28 at 19:58 +0100, Frederik Elwert wrote:
Am Freitag, den 17.09.2010, 10:02 +0200 schrieb Patrick Ohly:
> On Do, 2010-09-16 at 21:10 +0100, Frederik Elwert wrote:
> > From Genesis’ side, I could catch the exceptions and ignore them (i.e.,
> > act as I did before the new methods were introduced). Should work, but
> > maybe is not really pretty. Another idea would be to allow other clients
> > to Attach() to sessions to prevent them from terminating before they are
> > dealt with.
>
> That *is* already allowed :-) Whether it works is a different question,
> but it should.
Oh, I missed that. Regarding to [1], there is a Detach() method, but not
Attach().
There should have been one. I wonder why we didn't implement it, it
definitely was part of the original vision. Never mind, there is such an
Attach() now in 1.0.99.7:
http://bugs.meego.com/show_bug.cgi?id=7761
> I could also introduce a delayed clean up of completed sessions.
For
> example, keep them around 1 minute after the last client has detached,
> just in case that someone is still interested in the session's
> attributes.
In my eyes, this sounds like a very simple and good solution. It gives
clients enough time to request session information (or attach to the
session if they need it to exist longer than the built-in interval).
Implemented, see 1.0.99.7 and http://bugs.meego.com/show_bug.cgi?id=7766
--
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.
1:59 a.m.
On Fri, Sep 10, 2010 at 1:48 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
Hello!
I've made binaries of the current SyncEvolution development snapshot
available. You can get them from the "experimental" apt repository
(.deb) and http://downloads.syncevolution.org/syncevolution/evolution/
(.rpm).
Instead of the previous "alpha" or "beta" denominators as part of
the
version name, I've switched to the rpm method of "next version minus 1
in the last position". So this snapshot is version 1.0.99.6 (> 1.0.x for
any kind of realistic x, < 1.1). The .6 stems from the fact that there
have been earlier snapshots in MeeGo.
This release should be pretty stable, but is not yet quite feature
complete for 1.1.
Compiles on Fedora, but I've not yet tested it. I needed to add the
following patch to get it to compile though. Also the Category in
sync-gtk.desktop is missing a trailing ;
Cheers,
Peter
3772
days inactive
3793
days old
syncevolution@synevolution.org
18 comments
4 participants
participants (4)
-
Frederik Elwert -
Nudelzebra -
Patrick Ohly -
pbrobinson＠gmail.com